Ранній реліз або витриманий?

Що спільного між
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 7 Oct 2007 MPlayer-1.0rc2.tar.bz2
57 7 Oct 2007 MPlayer-1.0rc2.tar.bz2.md5
65 7 Oct 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 2011 23 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 name Release
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, так що апгрейди повинні бути узгоджені та синхронізовані в часі.
Використані матеріали
  1. Why and How Should Open Source Projects Adopt Time-Based Releases?
  2. Time-Based Release Management in Free and Open Source (FOSS) Projects
  3. Lessons learned from applying social network analysis on an industrial Free/Libre/Open Source Software ecosystem
  4. Вікі сторінка OpenStack


Книга у російському перекладі. В оригіналі ця фраза звучить: release often, release early.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.