Ерик Реймънд
Катедралата и базарът (4)

Пускай рано. Пускай често

Ранните и чести издания са критична част от модела за разработка на Линукс. По-рано, повечето разработчици (включително и аз) вярваха, че тази политика не върши работа при проекти по-големи от тривиални, защото ранните издания почти винаги са пълни с грешки, а човек не би искал да изчерпва търпението на потребителите си.

Тази вяра подсили общото отдаване на катедралния стил на разработка. Ако най-важното беше потребителите да виждат възможно най-малко грешки, то защо да не пускаш по едно ново издание на всеки шест месеца, а през останалото време да бачкаш като луд по отстраняването на грешките. С ядрото на Еmacs беше разработено по този начин. Lisp библиотеката, по обратния — защото имаше активни Lisp архиви извън контрола на FSF, където човек би могъл да отиде, за да намери нови версии на кода независимо от цикъла на пускане на Emacs^[1].

Най-важният от тях — elisp архивът на щата Охайо, носеше духа и много от характерните черти на днешните големи Линукс архиви. Малцина от нас обаче се замисляха какво правим, или какво точно предполагаше за проблемите в катедралния стил на разработка на FSF самото съществуване на този архив. Около 1992-а направих един сериозен опит формално да вкарам в официалната Emacs библиотека голяма част от кода на Охайо. Заради това обаче имах неприятности от политическо естество и общо взето нямах успех.

Една година по-късно обаче, когато Линукс започна да се откроява все повече, ставаше ясно, че се случва нещо много по-различно и здравословно. Политиката за отворена разработка на Линус беше пълна противоположност на катедралния модел. Архивите Sunsite (след това Metalab, а по-късно и Ibiblio) и tsx-11 се разрастваха, можеха да се намерят множество дистрибуции. И всичко това направлявано от нечувана до този момент честота на пускане на основната система.

Линус се отнасяше към своите потребители като към съразработчици по възможно най-ефективния начин:

7. Пускай рано. Пускай често. И слушай клиентите си.

Откритието на Линус беше не толкова че правеше това (в Unix-света дълго време преди това имаше подобна традиция), колкото в усилването му до степен, еквивалентна на сложността на това, което разработваше. В онези ранни времена (около 1991-а) нерядко му се случваше да пуска ново ядро повече от веднъж на ден! И тъй като той култивираше базата си от съразработчици и използваше Интернет за съвместна работа по-здраво от всеки друг, това сработваше.

Как обаче? И дали беше нещо, което мога да повторя, или се осланяше на някаква уникална гениална черта на Линус Торвалдс?

Не мислех така. Линус наистина е дяволски добър хакер (колцина от нас биха могли да разработят цяло ядро на операционна система с продуктово качество?). Но Линукс не представляваше някаква гигантска стъпка напред в концепцията. Линус не е (поне все още не е) изобретателен гений на дизайна каквито са, да кажем, Ричард Столман или Джеймс Гослинг (създали съответно NeWS и Java). Линус по-скоро ми изглеждаше като гений на инженерството с шесто чувство за избягване на грешките, задънените улици в разработката, и с истински талант да намира най-лесния път от точка А до точка Б. И наистина целият дизайн на Линукс е пропит с това качество, и отразява общо взето консервативния и опростяващ подход на Линус. И така, ако бързите издания и използването на Интернет-средата до максимум бяха не случайни, а неделими части от прозрението на инженерния гений на Линус към пътя, изискващ най-малко усилия, какво усилваше той? Какво изчовъркваше от машинарията?

Изказан по този начин, въпросът е реторичен. Линус постоянно стимулираше и възнаграждаваше своите хакери/потребители — стимулираше ги възможността да свършат някаква част от работата, задоволяваща егото им, а ги възнаграждаваше гледката на постоянното (дори всекидневно) подобряване на работата им.

Линус пряко целеше да увеличи човеко-часовете, хвърлени в отстраняването на грешки, дори и това да стане за сметка на нестабилност на кода и яд у потребителите, ако някоя грешка не може да се проследи. Линус се държеше, като че вярваше в следното:

8. Ако има достатъчно голяма база от бета-изпитатели и съразработчици, почти всеки проблем ще бъде характеризиран бързо, а поправянето му ще бъде очевидно за някой.

Или казано не така формално — „Ако има достатъчно очи, всички грешки се виждат“. Аз го наричам „Законът на Линус“.

Моята първоначална формулировка беше, че всеки проблем ще е „очевиден за някого“. Линус обаче смяташе, че този, който разбере и оправи проблема, не е задължително, нито обикновено същият, който го характеризира. „Някой вижда проблема, казва той, а някой друг го разбира. Продължавам да твърдя, че да откриеш е по-голямото предизвикателство“. Важното е обаче, че и двете неща се случват бързо.

Тук според мен се намира основната разлика между катедралния и базарния стил. В „катедралните“ възгледи за програмирането грешките и проблемите при разработка са тайнствени, коварни, дълбоки феномени. Нужни са месеци усърдна работа от посветените малцина, докато се добие увереност, че всичко е чисто. Оттам идват и дългите интервали между изданията и неизбежните разочарования, когато дългоочакваните издания не са съвършени.

При базарния възглед за нещата, от друга страна, се приема, че грешките общо взето са просто явление, или поне се оказват прости, когато бъдат изложени пред хилядите нетърпеливи съразработчици, които се нахвърлят на всяко ново издание. Съответно се правят по-чести издания, за да има повече поправки, като една от добрите страни на това е, че имаш да губиш по-малко, ако някоя грешка случайно успее да се промъкне незабелязана.

Това е всичко. И е достатъчно. Ако Законът на Линус не е верен, то всяка друга система, сложна като ядрото на Линукс, и по която „хакерстват“ толкова много ръце както при ядрото на Линукс, би трябвало в един момент да се срине под тежестта на непредвидени лоши взаимодействия и неоткрити „дълбоки“ грешки. Ако обаче е верен, то е достатъчно да обясни относителната липса на грешки в Линукс и продължителното му непрекъснато време на работа, стигащо до месеци и дори години.

Всъщност това може би не трябва да ни изненадва. Още преди години социолозите са открили, че усредненото мнение на група от еднакво учени (или еднакво невежи) наблюдатели е доста по-благонадеждно, отколкото това на един случайно избран наблюдател.

Те наричат това „Делфийски ефект“. Явно Линус показва, че това може да се приложи дори и при разработката на операционна система — че Делфийският ефект може да „укроти“ сложността на разработката дори и при ниво на сложност като това на ядро на операционна система.

Една специфична характеристика на ситуацията с Линукс, която много допринася освен „Делфийския ефект“, е фактът, че работещите по всеки даден проект се самоизбират. Преди си кореспондирах с един човек, който посочи, че контрибуции се получават не от случайно подбрани хора, а от такива, които са достатъчно заинтересувани да използват софтуера, да научат как работи, да се опитат да намерят решения на проблемите, които срещат, и всъщност да направят несъмнено разумна поправка. Всеки, който отговаря на тези условия, е много вероятно да има какво да допринесе.

Задължен съм на моя приятел Джеф Дътки „[email protected]“, задето ми посочи, че Законът на Линус може да бъде перифразиран като „Отстраняването на грешки е паралелизируемо“. Джеф е забелязал, че въпреки необходимостта хората, отстраняващи грешки, да поддържат връзка с някой координиращ разработчик, не е необходима кой-знае каква координация между самите тях. Следователно отстраняването на грешки не изпада в същата квадратична сложност и увеличение на разходите, които правят прибавянето на разработчици проблематично.

На практика теоретичната загуба на производителност поради дублиране на работата почти никога не е проблем в Линукс света. Един от ефектите, следващи политиката „пускай рано и често“ се състои в минимизирането на подобно дублиране чрез бързото разпространяване на върнатите поправки^[2].

Това твърдение всъщност не противоречи на закона на Брукс. Може би общата допълнителна сложност и уязвимостта от грешки расте на квадрат от големината на екипа, но въпреки това цената на дублираната работа е особен случай и нараства по-бавно. Не е трудно да се намерят правдоподобни причини за това, като се започне с несъмнения факт, че е много по-лесно да се постигне съгласие по функционалните граници между кода на отделните разработчици, което ще предотврати дублиране на работата, отколкото да се предотвратят различните видове лошо непланирано взаимодействие в цялата система, които са в основата на повечето грешки.

Комбинацията от законите на Линус и Хеслър подсказва, че всъщност софтуерните проекти биват три вида според размера си. При малките проекти (бих казал такива с не повече от трима разработчици) не е необходима по-сложна структура на управление от тази да се избере водещ програмист. Над тях съществува някакъв среден диапазон, при който разходите на традиционното управление са относително ниски, така че предимствата му от избягването на дублирането на работа, проследяването на грешки и опитите да не се пропускат детайли всъщност се оказват положителни.

Над това обаче комбинацията от законите на Линус и Хеслър подсказва, че има едно ниво на големите проекти, в което разходите и проблемите на традиционното управление се увеличават много по-бързо, отколкото очакваните разходи от дублирането на работа. Не на последно място сред тези разходи е структурната неспособност да се използва „ефекта на многото очи“, който (както вече видяхме) изглежда върши много по-добра работа от традиционното управление при подсигуряването да не се пропускат грешки и подробности. Така при големите проекти комбинацията от тези закони всъщност прави нетната полза от традиционното управление равна на нула.]

Брукс дори е направил импровизирано наблюдение, свързано с това на Джеф: „Общата стойност на поддържането на широко използвана програма обикновено е 40% или повече от стойността на разработката й. Изненадващото е, че тази стойност се влияе силно от броя на потребителите. Колкото повече потребители има, толкова повече грешки откриват те.“

Повечето потребители откриват повече грешки, защото добавянето на още потребители добавя и множество различни начини за изпитване на програмата. Този ефект се усилва, когато потребителите са и съразработчици. Всеки един подхожда към задачата да открие грешки с малко по-различна настройка и аналитичен модел от останалите, с различен ъгъл на проблема. Изглежда „Делфийският ефект“ работи точно именно поради тази разлика. В специфичния контекст на отстраняването на грешки, разликата освен това има тенденцията да намалява дублирането на труда.

Затова добавянето на повече бета-изпитатели може и да не намали сложността на настоящата „най-дълбока“ грешка от гледна точка на разработчиците, но увеличава вероятността нечий инструментариум да пасне на проблема по такъв начин, че грешката да стане очевидна за този човек.

Линус също залага на това. В случай че съдържа сериозни грешки, версията на ядрото на Линукс се определя по такъв начин, че потенциалните потребители могат да избират дали да използват последната версия, определена като „стабилна“, или да се движат по острието на бръснача и да рискуват с грешките за сметка на някои нови функции. Повечето Линукс хакери все още не подражават формално на тази тактика, а може би трябва; фактът, че са достъпни и двата избора ги прави по-привлекателни.