Что общего между mutt, mplayer и gzip помимо того, что это качественные проекты с открытым кодом? В качестве подсказки даю наводящий вопрос: вы можете точно назвать месяц выхода очередной версии Debian Linux, до официального объявления на вебсайте?
Все эти программы имеют одну особенность — относительно длинный и непредсказуемый цикл разработки и релиза. Между тем все более популярным становится предсказуемый и относительно короткий цикл релиза, строго по графику. Какая стратегия разработки более выигрышная и каковы условия добиться перехода на оптимальную стратегию? Об этом мы поговорим в данной статье.
Релизы почаще, да пораньше
Так переводится знаменитый тезис Эрика Раймонда, автора книги The Cathedral and the Bazaar[1]. В этой книге он сравнивает старый стиль разработки в среде Unix с кафедральным собором, который находится в резком контрасте с тем, как осуществляется разработка Linux.
Меня потрясло, что этот базарный стиль работает и работает хорошо. Я не только участвовал в разработке индивидуальных проектов, но также пытался понять, почему в мире Linux'a не только не возникает беспорядка, но напротив он движется вперед со скоростью, которой строители собора могут только позавидовать.
Эта философия отлично характеризует разработку самого ядра Linux, однако многие проекты с открытым кодом не вполне оценили ее по достоинству и придерживаются стратегии ad-hoc релизов. Так мы будем называть стратегию развития проекта, при которой новую версию выкатывают по готовности, когда определенный набор фич воплощен в коде и стабилизирован.
Этот подход обладает существенными недостатками, часто ad-hoc становится долгостроем, как первая стабильная версия Mplayer-a.
8414213 Oct 22 2006 MPlayer-1.0rc1.tar.bz2
57 Oct 22 2006 MPlayer-1.0rc1.tar.bz2.md5
3453 Oct 22 2006 MPlayer-1.0rc1.tar.bz2.torrent
9338201 Oct 7 2007 MPlayer-1.0rc2.tar.bz2
57 Oct 7 2007 MPlayer-1.0rc2.tar.bz2.md5
65 Oct 7 2007 MPlayer-1.0rc2.tar.bz2.sha1
3707 Oct 11 2007 MPlayer-1.0rc2.tar.bz2.torrent
9650074 May 29 2010 MPlayer-1.0rc3.tar.bz2
538 May 29 2010 MPlayer-1.0rc3.tar.bz2.asc
57 May 29 2010 MPlayer-1.0rc3.tar.bz2.md5
65 May 29 2010 MPlayer-1.0rc3.tar.bz2.sha1
12134661 May 29 2010 MPlayer-1.0rc3.tar.gz
538 May 29 2010 MPlayer-1.0rc3.tar.gz.asc
56 May 29 2010 MPlayer-1.0rc3.tar.gz.md5
64 May 29 2010 MPlayer-1.0rc3.tar.gz.sha1
10351350 Jan 29 2011 MPlayer-1.0rc4.tar.bz2
538 Jan 30 2011 MPlayer-1.0rc4.tar.bz2.asc
57 Jan 29 2011 MPlayer-1.0rc4.tar.bz2.md5
65 Jan 29 2011 MPlayer-1.0rc4.tar.bz2.sha1
12979618 Jan 23 2011 MPlayer-1.0rc4.tar.gz
538 Jan 30 2011 MPlayer-1.0rc4.tar.gz.asc
56 Jan 29 2011 MPlayer-1.0rc4.tar.gz.md5
64 Jan 29 2011 MPlayer-1.0rc4.tar.gz.sha1
11202492 May 5 2013 MPlayer-1.1.1.tar.xzПопулярная платформа для верстки Scribus недавно выпустила версию 1.4.6, в то время как 1.4.0. вышла еще в самом начале 2012-го. Когда выйдет 1.5.0 вообще неизвестно. Почтовик mutt — основной рабочий инструмент мейнтейнера стабильной ветки Linux ядра GKH, пробыл в версии 1.5.X сколько другие за особо тяжкие получают. И даже gzip протянул 13 лет, с 1993 по 2006, между версиями 1.2.X и 1.3.X.
В то же время более крупные проекты давно уже перешли на временной график, и как правило, интервал между релизами не превышает полгода. Вот список некоторых крупных проектов, временные интервалы и время выбора новой стратегии развития проекта.
Дебиан стоит особняком и является некоторым гибридным сочетанием двух стратегий. Как видим, дебиановцы таки-придерживаются графика, но цикл разработки слишком долгий, для того, чтобы воспользоваться преимуществами стратегии с предсказуемым циклом производства. Довольно часто сроки выпуска новой версии откладываются.
Любопытный факт, в KDE Plasma 5 патчи после версий .0 выходят по четвергам, в недели последовательности Фибоначчи.
Plasma .0 tags on Frameworks release Thursdays and release on following Tuesday. Beta tag/release on Thursday 2 weeks before. Bugfix tag/releases are on Tuesdays after .0 release in a Fibonacci sequence of weeks, 1, 1, 2, 3, 5 after initial.
Рассмотрим теперь причины долгостроя приверженцев ad-hoc стратегии, преимущества предсказуемого короткого цикла производства и возможность поменять первое на второе.
Дисциплина имеет значение
Когда команда ждет включения в код и стабилизации определенного набора фич, для того чтобы выпустить новую версию, чаще всего происходит следующее. В какой-то момент они осознают, что добавить все желаемые нововведения не получится, так как многие энтузиасты проекта работают недавно и раньше не сталкивались с новыми концепциями. Тогда волевым усилием объявляют предполагаемую дату релиза, которая для всех становится шоком. Далее следует шквал патчей и суета-сует, ведь многие релиза уже лет дцать как не видели и не знают, как это делается.
То ли дело GitLab, разработчики выкатывают новую версию каждый месяц 22-го числа — как швейцарские часы. По словам основателя и руководителя проекта Дмитрия Запорожца, не надо ждать, пока все будет идеально.
At GitLab we believe you shouldn’t wait for something to be perfect: Release what you have and do it on a scheduleПредсказуемый график и кратковременный интервал между релизами имеет следующие преимущества.
- Мейнтейнеры, перестают яростно подгонять рядовых разработчики. Работа ведется в деловом, но не авральном режиме. Это как нестись сломя голову, чтобы сесть в отъезжающий поезд в метро, можно ведь и подождать следующего.
- В течении года даже новые члены команды успевают набить руку, релиз новой версии перестает быть для них источником стресса и неожиданностей. В случае ГитЛаба этот срок в разы короче.
- Когда новая версия задерживается, повышается вероятность фрагментации исходного кода, некоторые разработчики начинаю форкать код, добавлять свои наработки и сосредотачиваться в дальнейшем на них. Четкий график и непродолжительный интервал выпуска очередной версии убирает подобный разброд и шатания в команде.
- Проект продолжает развиваться. Когда в проекте с открытым кодом случается долгострой, пользователи, волонтеры, а затем и разработчики, из него уходят. Именно в таком порядке, так как с уходом из проекта пользователей, размывается его база. Ведь как устроена пирамида? Всегда, определенный процент пользователей не только пользуются программой, но и помогают развивать ее: кто багрепортами, кто переводом, кто бета-тестами, а кто и патчами. Без пользователей проект загнивает.
- Когда до новой версии еще далеко, все труднее становится вербовать бета-тестеров, для них это интересно, только в преддверии выхода стабильной версии. При ранних релизах обратная связь между пользователями и разработчиками не затухает.
- Апгрейды не такие зубодробительные.
- Для пользователей, так же как и для дистрибьюторов открытого ПО проще планировать переход на новую версию программы.
Особенно благоприятно переход с ad-hoc стратегии на график повлиял на GNOME. Тут бы следовало добавить фотожабу, то есть Gimp-обработку, картины Васи Ложкина «Жизнь с бородой», но к сожалению, не могу красиво написать нужные слова аркой.
Невероятно масштабный и сложный комплекс проектов с открытым кодом OpenStack имеет полугодовой цикл выпуска, однако изначально новые версии выпускались каждые три месяца.
Release date Release name
Oct 21st, 2010 Austin
Feb 3rd, 2011 Bexar
Apr 15th, 2011 Cactus
Sep 22nd, 2011 Diablo
Apr 5th, 2012 Essex
Sep 27th, 2012 Folsom
Apr 4th, 2013 Grizzly
Oct 17th, 2013 Havana
Apr 17th, 2014 IcehouseДавайте посмотрим вкратце, что такое OpenStack в цифрах.
- Размер рынка — 1.7 млрд. долл. США в 2016 г.
- В проекте участвуют более 500 компаний.
- Поддержка разных платформ и архитектур.
- 17,020 участников сообщества
- 100,000 проверок кода
- 1,766,546 строк кода
Изюминка этого колоссального начинания в том, что основные участники конкурируют друг с другом на рынке, одновременно сотрудничая в рамках проекта. HPE конкурирует с Mirantis и Rackspace, IBM с Intel, VMWare с Cisco, RedHat с Canonical, но когда дело касается OpenStack, все становятся белыми и пушистыми.
Представим себе на минуточку, как мог бы развиваться данный проект, полагаясь на длинный цикл разработки и релиза. Что если бы, выход очередной версии происходил по мере готовности набора новых фич, вместо того, чтобы придерживаться предсказуемых и четких графиков времени? Думаю, в таком случае участники элементарно не смогли бы ни о чем договориться, и проект бы заглох на ранней стадии.
Qui bono?
Означает ли все вышесказанное, что для всех проектов без исключения переход со стратегии ad-hoc релизов на предсказуемый график является благом?
Первое, что приходит на ум — контр-примеры. Есть же vim или GNU Coreutils, которые редко или не очень предсказуемо релизятся, но у которых тем не менее все хорошо с развитием и с пользовательской базой. Вся штука в том, что для успешных проектов с открытым кодом нет никаких весомых причин менять стратегию развития, ради того, чтобы отдать дань новым веяниям. Это мудрость известна всем админам: работает — не трогай.
Точно так же, нет причин перехода с ad-hoc релизов на предсказуемые, если коммитов было всего ничего. Должна накопиться критическая масса изменений.
Нет никакой линейной зависимости между упомянутыми двумя стратегиями и качеством кода, что было показано на примере FireFox. Согласно проведенному исследованию, до и после перехода на предсказуемый короткий цикл производства количество багов после выхода стабильной версии было практически одинаково.
Важно четко понимать в каком пользовательском сегменте находится ваш продукт. Одно дело компилятор gcc, если выкатить его пораньше и сыроватым, программисты смогут напильниками довести его до ума. Совсем другое дело, веб сервер Apache, выпустить раньше времени стабильную версию — чревато.
Резюмируя все вышесказанное. График предпочтительнее чем ad-hoc в тех случаях когда:
- вы начинаете крупный проект с открытым кодом, в котором будет множество разработчиков и добровольцев,
- ваш проект имеет коммерческую ценность для вендоров ПО или активно конкурирует на рынке с другими программами,
- ваш проект выдыхается, пользователи и разработчики разбегаются ввиду слишком длинного и непредсказуемого цикла разработки и релиза.
- ваш проект критически важен для партнеров, как GNOME для Ubuntu, так что апгрейды должны быть согласованы и синхронизированы по времени.
Использованные материалы
- Why and How Should Open Source Projects Adopt Time-Based Releases?
- Time-Based Release Management in Free and Open Source (FOSS) Projects
- Lessons learned from applying social network analysis on an industrial Free/Libre/Open Source Software ecosystem
- Вики страница OpenStack
^ Книга в русском переводе. В оригинале эта фраза звучит: release often, release early.
Комментарии (10)
hurtavy
11.11.2016 09:59+4Новые версии должны исправлять ошибки и привносить новые функции, а не выходить по графику
Ruckus
11.11.2016 10:35+1Не поспоришь. Вопрос в том, что в один релиз часто пытаются напихать слишком много, иногда имеет смысл отдавать это по кускам по готовности каждой фичи/набора багфиксов.
temujin
11.11.2016 11:33+1А почему или-или? Все это, но также придерживаться графика. Убунту — 6 месяцев, Гном — 6 месяцев, KDE — 5 месяцев, и т. д. Для крупных проектов, так целесообразнее, а когда работа не велась, то и релизить нечего. Никто не предлагает, чтобы ping обновлялся каждые 3 месяца.
NeverIn
11.11.2016 20:45Большое значение играет внешний или внутренний заказчик. Внешнему заказчику важны сроки для планирования своих бизнес-задач.
776166
Если бы разработчик gzip, следуя в фарватере моды, приделывал кнопку «поделиться с друзьями только что заархивированным файлом», тогда релизы были бы частыми. Но т.к. это просто инструмент, то там просто нечего часто релизить.
temujin
Я в выводах написал, что основная выгода от частых релизов для крупных проектов, в которых может быть коммерческий интерес у третьих сторон. Опять же есть оговорка, что когда мало изменений — график релиза не имеет смысла. И все же, тот же gzip иногда по несколько лет не давал о себе знать:
Вполне возможно, что это как раз был один из таких кризисов слишком длинного цикла релиза.
776166
gzip и кризис? :) Думаю, что по миру gzip в секунду запускается чаще, чем вносится коммитов во все репозитории.
Скорее всего, там максимум рефакторинг и специальные патчи, связанные с обновлениями ОС.
Я имел в виду, что есть законченные рабочие продукты, у которых «цикл разработки» не предусмотрен и/или носит ситуационный характер.
temujin
Я против этого и не спорю, всего лишь пытаюсь понять, где можно провести границу, за которой частые релизы помогают проекту.
776166
Скорее всего, вы не найдёте правильного решения: модель сложная. Надо учитывать очень много факторов от типа команды, её управления, личности владельца, до особенностей самого продукта и аудитории. И статистику для хоть какого-то анализа собрать сложно.
Хотя, безусловно, очень хотелось бы видеть серьёзные исследования на эту тему.
temujin
Такие исследования есть, но их крайне мало. Из них пара в ссылках. Выводы — за график, практика тоже — за график, крупные Open Source проекты в своей массе релизят именно так. Для небольших прикладных Unix-way утилит, вполне сойдет ad-hoc. Но где-то существует предел сложности проекта, когда пора менять стратегию. Граница линейкой не прочерчена, но она где-то проходит.
Вы знаете крупный OpenSource проект, в котором релизы не по оговоренному графику? Для меня только Apache веб-сервер непонятно как релизится а остальные — по расписанию.