Что общего между 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.
ссылка на оригинал статьи https://habrahabr.ru/post/314762/
Добавить комментарий