bojinov.org

USA Bulgaria Freebies Empty World

This is a translation to Bulgarian of the paper "The Cathedral and the Bazaar", written by Eric Steven Raymond. Translation by Hristo Bojinov.

Катедралата и Базарът

Eрик Стивън Реймънд
24 август 2000
Всички права на автора са запазени

Преводач: Христо Божинов
Всички права на преводача са запазени

Като общо правило, разрешава се електронното разпространение на тази статия (и този превод). Отпечатването на хартия се разрешава в малки количества, за лична употреба или образователна цел. Забранено е разпространението с търговска цел без изричното разрешение на автора и преводача.


В тази статия разглеждам един успешен проект с open-source, fetchmail, който бе предприет като проверка на някои изненадващи теории за софтуерното инженерство, които се зародиха от историята на Linux. Обсъждам тези теории на базата на два различни стила за разработка на софтуер: модела на "катедралата", който се използва в комерсиалната разработка на софтуер, и модела на "базара" в света на Linux. Показвам как тези модели произлизат от противоположни хипотези за същността на процеса на дебъгване. После давам сериозни доводи от опита с Linux в подкрепа на твърдението "При достатъчно очи, всички бъгове са очевидни.", давам изразителни аналогии с други самокоригиращи се системи, които се състоят от агенти с лични интереси (т.е. агенти които не работят заради "общото благо"), и завършвам с изследване на възможните последици от тези идеи за бъдещето на софтуера.

1. Катедралата и Базарът

Linux действа подмолно. Дори преди само пет години (1991), кой би помислил че една операционна система от световна класа може да се появи сякаш по магия от разпокъсаните усилия на няколко хиляди програмисти, разпръснати по цялата планета и свързани само със слабите нишки на Интернет?

Не и аз. До момента в който Linux се появи на моя "радар" в началото на 1993, вече бях програмирал за UNIX и open-source проекти в продължение на десет години. Бях един от първите хора, които работиха по GNU в средата на 80-те. Бях публикувал най-различни open-source програми по мрежата, и бях участвал в разработката на продукти които са в употреба и сега (nethack, режимите VC и GUD за Emacs, xlife, и др.). Мислех, че знам как се правят тези неща.

Linux преобърна много от това което мислех че знам. Бях проповядвал евангелието на UNIX и малките помощни програмки, бързото оформяне на прототипи и еволюционното програмиране с години. Но също така вярвах, че отвъд определена критична сложност се налага да бъде прилаган по-централизиран, планов процес. Вярвах, че най-важния софтуер (операционни системи и наистина големи продукти като Emacs) трябва да бъде строен като катедрала, да бъде внимателно разработван от индивидуални "магьосници" или малки групи "магове", които работят в изолация без да избързват с бета-версиите.

Стилът на програмиране на Линус Торвалдс---чести release-ове, отдаване на права върху части от продукта където е възможно на други хора, отвореност към света, граничеща с безразборност---беше неочакван. Никакъв тих строеж на катедрали----по-скоро общността около Linux приличаше на един голям, бъбрив базар от разнородни планове и подходи (подходящо символизиран от архивите на Linux, които приемат кода на всеки който иска да допринесе нещо) от който може да се получи работеща и стабилна система само по чудо.

Фактът, че този базар работи, и то добре, беше шокиращ. Докато се ориентирах в обстановката не само работих усилено по конкретни проекти, но и се опитвах да разбера защо света на Linux не се разпада в объркване, а гради крепост след крепост със скорост немислима за строителите на катедрали.

До средата на 1996 вече мислех, че бях започнал да разбирам. Късметът ми даде отличната възможност да проверя моята теория, във вид на open-source проект, който можех да ръководя съзнателно в стила на "базара". Така и направих---и проекта постигна значителен успех.

Това е историята на този проект. Ще я използвам, за да предложа някои афоризми относно ефективната разработка в open-source. Не всички съм научил от света на Linux, но ще покажа как той им дава особен смисъл. Ако съм прав, те ще ви помогнат да разберете кое точно прави Linux-общността такъв извор на добър софтуер---и може би ще ви помогнат да станете по-продуктивни.

2. Пощата Трябва да Преминава

От 1993 бях ръководил техническата страна на един малък Интернет доставчик за свободен достъп, който се наричаше Chester County InterLink (CCIL) в Уест Честър, Пенсилвания. Бях един от основателите на CCIL и бях написал уникалния BBS софтуер, който използвахме---можете да го разгледате на telnet://locke.ccil.org. Днес той поддържа почти три хиляди потребители на тридесет линии. Работата ми позволяваше достъп до мрежата 24 часа на ден през 56К линията на CCIL---всъщност, на практика го изискваше!

Доста бях свикнал с бързия e-mail в Интернет и ме дразнеше това, че трябва да телнетвам периодично до locke за да си проверявам пощата. Това, което исках беше да получавам пощата си на snark (машината у дома), така че да знам когато пристига и да мога да я обработвам локално.

Оригиналният протокол за препращане на поща в Интернет, SMTP (Simple Mail Transfer Protocol---Прост Протокол за Обмен на Поща), не можеше да помогне, защото работи най-добре когато машините са свързани постоянно, а моят компютър не е винаги свързан с Интернет, и няма постоянен IP адрес. Имах нужда от програма, която да използва непостоянната връзка с Интернет и издърпва пощата, която е пристигнала. Знаех че такива неща съществуват, и че повечето използват прост протокол наречен POP (Post Office Protocol---Пощенски Протокол). POP сега има широка поддръжка от най-често използваните клиенти за поща, но по онова време не беше вграден в mail-клиента ми.

Имах нужда от POP3 клиент. Затова, потърсих по Интернет, и намерих един. Всъщност, намерих три или четири. Използвах един от тях в продължение на известно време, но му липсваше една за мен очевидна функция: възможността да се коригират адресите в донесената поща, така че пощата която изпращам в отговор да пристига на правилното място.

Проблемът беше следният: да предположим, че някой с име "joe" на locke ми прати e-mail. Ако издърпам писмото му на snark, и се опитам да му отговоря, моят клиент ще прати отговора на "joe" на snark. Редактирането на адреси на ръка, и добавянето на "@ccil.org" бързо ми досадиха.

Очевидно, тове беше нещо което компютъра трябва да прави сам, но никой от съществуващите клиенти не го правеше! Това ни довежда до първия урок:

1. Всяка добра програма започва от личната необходимост на някой програмист.

Сигурно това би трябвало да е очевидно (както се казва, "Неволята учи"), но твърде често програмистите прекарват дните си в работа по програми, от които те нямат нужда, и които така или иначе не харесват. Но не и в света на Linux---което може би обяснява защо средното качество на софтуера произлизащ от Linux-общността е толкова високо.

И така, започнах ли незабавно да пиша чисто нов POP3 клиент, който да е по-добър от съществуващите? В никакъв случай! Добре разгледах POP програмите, които имах и си зададох въпроса "Коя е най-близо до това което ми трябва?", защото

2. Добрите програмисти могат да пишат, а Великите програмисти могат да пренаписват (и използват наготово).

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

Линус Торвалдс (http://www.tuxedo.org/~esr/faqs/linus), например всъщност не се опита да напише Linux изцяло сам. Вместо това той започна с код и идеи от Minix, една малка ОС за PC-та, подобна на UNIX. Постепенно всичкият код от Minix изчезна или бе изцяло пренаписан---но докато още беше там служеше за инкубатор на това което в последствие стана Linux.

В същия дух потърсих съществуваща POP програма, която да е достатъчно чисто написана, за да мога да я използвам за база.

Традицията да се разпространява сорс-код в UNIX винаги е била в подкрепа на използването на вече написан код (по тази причина GNU избра UNIX за основна ОС, въпреки сериозните аргументи срещу самата ОС). Светът на Linux доведе тази традиция почти до нейните технически граници; вече има терабайтове широко достъпен сорс-код. Така че четенето на почти-достатъчно-добрия код на някого в света на Linux може да доведе до по-добри резултати отколкото където и да било другаде.

В моя случай стана точно така. Включвайки тези, които бях намерил по-рано, второто ми търсене даде общо девет кандидата---fetchpop, PopTart, get-mail, gwpop, pimp, pop-perl, popc, popmail и upop. Този, върху който се спрях първо беше "fetchpop" написан от Сюнг-Хонг О. Добавих към него моята функция за поправка на заглавната част, и направих още някои подобрения, които авторът прие в неговата версия 1.9.

Няколко седмици по-късно обаче попаднах на кода на "popclient" от Карл Харис, и установих че имам проблем. Въпреки че fetchpop имаше някои добри първоначални идеи (като режим daemon---във фонов процес), той можеше да се справи само с POP3 и беше написан доста аматьорски (Сюнг-Хонг по онова време беше умен и неопитен---и двете качества си личаха). Кода на Карл беше по-добър, професионално написан и стабилен, но в програмата му липсваха няколко важни и доста трудни за реализиране функции на fetchpop (като включим тези които бях написал самият аз). Да остана, или да се преместя (бел. прев.: към popclient)? Ако се преместя, бих изгубил всичкия код, който вече бях написал, а в замяна бих получил по добра основа за разработка. Една практическа причина да се преместя беше поддръжката на различни протоколи. POP3 е най-широко използваният, но не и единственият. Fetchpop и другите конкуренти не поддържаха POP2, RPOP, или APOP, а аз имах идея да добавя може би и IMAP (http://www.imap.org) (Internet Message Access Protocol---Интернет Протокол за Достъп до Съобщения, най-новия и най-мощен протокол за поща), просто за разнообразие. Но имах и една по-теоритична причина да сменя кода, който използвам за основа, нещо което бях научил много преди Linux:

3. "Планирайте да изхвърлите една; така или иначе---ще го направите." (Фред Брукс, "Митичният Човеко-Месец", Глава 11).

Или, казано по друг начин, често не разбираш проблема наистина преди да напишеш решение за пръв път. Втория път, може би знаеш как да го решиш правилно. Така че ако искаш да напишеш нещо добро, бъди готов да започнеш на ново поне веднъж [1].

Е, казах си, промените във fetchpop бяха първия ми опит. И минах на popclient.

След като пратих първата група корекции за popclient на Карл Харис на 25.06.1996, открих че е загубил интерес в работата по popclient преди известно време. Кодът беше малко "прашен", с някои дребни бъгове. Аз исках да правя доста корекции, и бързо решихме че е логично аз да поема развитието на програмата.

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

В софтуерна общност, която окуражава заимстването на код, това е естествения път за развитие на един проект. Действах по принципа:

4. Ако имаш правилно отношение към нещата, интересните проблеми ще те намерят сами.

Но отношението на Карл Харис беше още по-важно. Той разбираше, че

5. Когато изгубиш интерес в една програма, последното ти задължение е да я предадеш на способен наследник.

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

3. Потребителите са Важни

И така наследих popclient. И което е също толкова важно, наследих потребителите на popclient. Чудесно е да имаш потребители, не само защото това показва че обслужваш някаква нужда, и че си направил нещо правилно. Ако се отнасяш с тях правилно, те могат да помагат в разработката.

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

6. Да се отнасяш към потребителите си като към партньори в разработката е най-лесния път към бързо подобряване на кода и ефикасно дебъгване.

Силата на този ефект може лесно да бъде подценена. Всъщност, общо взето всички от нас в света на open-source подценяваха как той ще може да се запази с увеличаването на броя на потребителите и увеличаването на сложността на системата, докато Линус Торвалдс не ни показа истината.

И наистина, смятам че най-умното и най-значително дело на Линус не беше създаването на ядрото на Linux, а изобретяването на модела за разработка на Linux. Когато веднъж дадох това мнение в негово присъствие, той се усмихна и тихо повтори нещо което често е казвал: "Аз по принцип съм един много мързелив човек, който обича да му бъдат приписвани неща направени от други." Мързелив като лисица, или както Робърт Хайнлайн писа за един от героите си, твърде мързелив за да пропадне.

В ретроспект, един прецедент за методите и успеха на Linux може да бъде открит в разработката на Лисп библиотеката за GNU Emacs, и архивите за код на Лисп. За разлика от катедралния стил на построяване на ядрото на Emacs на C и повечето останали програми в GNU, еволюцията на кода на Лисп беше плавна и движена от потребителите. Идеите и прототипите за режими бяха често пренаписвани три-четири пъти преди да достигнат стабилния си краен вид. Свободното и неформално сътрудничество по Интернет, в стил Linux, беше често срещано.

Наистина, моят най-успешен хак (бел. прев.: hack---програма, или модул, написан за да реши някой конкретен, обикновено малък, проблем) преди fetchmail вероятно беше VC (Version Control) режима за Emacs, едно сътрудничество в стила на Linux с трима други човека, от които до ден днешен съм се срещал само с един (Ричард Столмън, авторът на Emacs и основател на Free Software Foundation (http://www.fsf.org)). Това беше един интерфейс към SCCS, RCS, и по-късно CVS за Emacs, който предлагаше операции за контрол на версиите с "едно кликване". Той се разви от малък, груб sccs.el режим, който някой друг беше написал. Разработката на VC успя, защото за разлика от самия Emacs, кода на Emacs Lisp можеше да преминава през цикли на разпространение/тестване/подобрение много бързо.

4. Нови Версии, Рано и Често

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

Това вярване подкрепяше преобладаващата ориентация към катедралния стил на разработка. Ако главната цел е потребителите да виждат минимален брой бъгове, тогава очевидно трябва да пускаме нови версии веднъж на шест месеца (или по-рядко), а междувременно да работим упорито по коригирането на кода. Ядрото на Emacs (написано на C) бе разработено по този начин. Lisp библиотеката, на практика не---защото имаше активни Lisp архиви извън контрола на FSF, където можеха да се намерят ранни версии на кода, независими от цикъла на разработка на самия Emacs [2].

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

Но до около година по-късно, след като Linux получи широка видимост, стана ясно че съществува нещо различно, и много по-здравословно. Отворената политика за разработка на Линус беше точно обратното на катедралния модел. Интернет архивите на Linux се увеличаваха, и многобройни дистрибуции бяха в обръщение. Всичко това беше подхранвано от нечувана честота на новите версии на системното ядро.

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

7. Нови версии, рано и често. И се вслушвайте в мненията на потребителите.

Новото в подхода на Линус беше не толкова в честите нови версии, които включваха предложения от много потребители (това отдавна беше част от традициите в света на UNIX), колкото в успеха му да усили интензивността на процеса до ниво сравнимо със сложността на системата, която изграждаше. По онова време (около 1991) не беше чудно той да подготви повече от една нова версия на ядрото в даден ден! Понеже той култивира наличното си количество от помощници, и използваше Интернет за сътрудничество повече от всеки друг, това стана възможно.

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

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

И така, ако честите версии и използването на Интернет до край не бяха случайност, а съществена част от виждането на Линус за най-лесния път, то какво максимизираше той? Какво произвеждаше неговата машина?

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

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

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

Или, по-неформално, "При достатъчно очи, всички бъгове са очевидни." Това ще нарека "Закон на Линус".

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

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

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

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

Всъщност, това като че ли не би трябвало да е изненадващо. Преди години, социолозите откриха че осредненото мнение на група от еднакво квалифицирани (или неквалифицирани) наблюдатели е доста по-надеждно от това на случайно избран един от тях. Те нарекоха това ефект "Делфи". Явно Линус демонстрира, че това е вярно и за дебъгването на една операционна система---че ефектът "Делфи" може да контролира сложността за разработка дори на нивото на ОС ядрото.

Едно по-специално условие в ситуацията на Linux, което определено помага заедно с ефекта "Делфи", е фактът, че тези които допринасят по даден проект се избират сами. Един от първите читатели отбеляза, че приносът идва не от хора, които са случайно избрани, а такива които са достатъчно заинтересувани да го използват, да разберат как работи, да се опитат да намерят решения за проблемите, които срещнат и да произведат що-годе добра корекция.

Задължен съм на моя приятел Джеф Дътки (dutky@wam.umd.edu), който посочи че Законът на Линус може да бъде перефразиран като "Дебъгването може да се паралелизира". Джеф забеляза, че въпреки че тестърите трябва да общуват с някой главен програмист, не е необходимо те да общуват помежду си. Като резултат, липсва квадратичната сложност, която прави добавянето на програмисти трудно.

На практика теоритичната загуба на ефективност поради неколкократното извършване на едно и също нещо (бел. прев.: например когато няколко човека поправят една и съща грешка в кода) почти никога не е проблем в света на Linux. Един от ефектите на политиката "Нови версии, рано и често" е че тя минимизира повторенията като бързо прави достъпни новите корекции [3].

Брукс (автор на "Митичният Човеко-Месец") дори направи едно импровизирано наблюдение свързано с това на Джеф: "Общите разходи по поддръжката на една широко използвана програма са обикновено 40% или повече от цената на разработването и. Изненадващо, тази цена зависи много от броя на потребителите. Повече потребители намират повече бъгове." (аз наблегнах на последното изречение).

Повече потребители намират повече бъгове, защото добавянето на потребители води до нови начини за натоварване на програмата. Ефектът се увеличава, когато потребителите също така участват в разработването. Всеки характеризира бъгове по леко различен начин, с различни наблюдения и анализ, различна гледна точка. Ефектът "Делфи" изглежда работи точно заради тези разлики. Конкретно при дебъгването, разликите помагат да се намали дублирането на работа.

И така, добавянето на бета-тестъри може да не намалява сложността на "най-дълбокия" бъг за момента от гледна точка на програмиста, но увеличава верояността похватите на някого да съвпаднат с проблема, така че той да изглежда плитък за този конкретен човек.

Освен всичко това, Линус не рискува много. Ако се окаже че има сериозен бъг, версиите на ядрото на Linux са номерирани, така че потребителите могат да изберат последната "стабилна" версия, или най-новата, с най-много възможности, но и с риск за бъгове. Повечето хакери на Linux още не прилагат тази тактика, но вероятно би трябвало; факта че и двете възможности са на лице прави и двете по-привлекателни [4].

5. Кога Една Роза не Ухае?

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

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

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

Затова, през първия месец просто следвах основния дизайн на Карл. Първата сериозна промяна която направих беше поддръжката на IMAP. За нея просто реорганизирах автоматите за отделните протоколи в общ драйвер и три таблици с методи (за POP2, POP3, и IMAP). Тази и предните промени илюстрират един общ принцип, който програмистите е добре да спазват, особено в езици като C, които не обработват типове данни динамично:

9. Добри структури от данни и лош код работят много по-добре отколкото обратното.

Брукс, Глава 9: "Покажи ми кода си и скрий структурите от данни, и аз ще съм в недоумение. Покажи ми структурите си от данни, и обикновено няма да ми е необходим кода ти; той ще е очевиден." (бел. прев.: това пък аз наричам "Отмъщението на Шишков"; сега, по сериозно---според мен това напоследък не е точно така, може би защото кода и данните са по-близо от всякога: ООП, енкапсулация и т.н., и според мен двете са еднакво важни, в духа на Алгоритми + Структури от Данни = Програми...)

Всъщност Брукс използва термините "блокови диаграми" и "таблици", но ако се съобразим с 30-годишната еволюция на културата и терминологията, смисълът е почти един и същ.

В този момент (началото на септември 1996, около шест седмици след започването) започнах да мисля, че може би е необходима смяна на името---в крайна сметка това вече не беше само POP клиент. Но се колебаех, защотото в дизайна още нямаше нищо ново. На моята версия на popclient все още и предстоеше да си изгради собствена идентичност.

Нещата се промениха, когато fetchmail се научи как да препраща донесената поща към SMTP порта. Ще стигна и до там след малко, но първо: казах по-горе, че реших да използвам този проект, за да проверя моята теория за това, което Линус Торвалдс направи както трябва. Как (може да попитате) постигнах това? По следните начини:

Резултатът от тези прости мерки беше незабавен. Още от началото на проекта получавах доклади за бъгове с качество за което повечето програмисти само могат да мечтаят, често с приложени корекции за тези бъгове. Получавах смислена критика, писма от "феновете си", и интелигентни предложения за нова функционалност. Това ни води то следното:

10. Ако се отнасяш с бета-тестърите си сякаш те са най-важния ти ресурс, те ще ти се отблагодарят като наистина станат най-ценния ти ресурс.

Интересна мярка за успеха на fetchmail е големината на бета-списъка за проекта, fetchmail-friends. Последно (август 2000) списъка има 249 получателя, и се увеличава с 2-3 всяка седмица.

Всъщност, сега като коригирам статията (края на май 1997) списъкът е започнал да намалява от максимума си 300 по една доста интересна причина. Няколко човека ме помолиха да ги махна от списъка понеже са толкова доволни от fetchmail, че нямат нужда вече да следят съобщенията! Вероятно това е част от нормалния жизнен цикъл на един зрял проект в стил базар.

6. Popclient се превръща във Fetchmail

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

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

(Ако не ви интересуват подробностите на пощата в Internet, можете спокойно да пропуснете следващите два абзаца.)

Когато се замислих за SMTP препращането, осъзнах че popclient се опитваше да направи твърде много неща. Той беше създаден да бъде агент за препращане на поща (Mail Transport Agent---MTA), както и агент за локална доставка на поща (Mail Delivery Agent---MDA). Със SMTP препращането можех да се освободя от задължението за локална доставка, и да бъда чист MTA, като давам пощата за локална доставка на други програми---точно както прави sendmail.

Защо да се занимавам със усложнения като конфигуриране на MDA или заключване на файла с поща и писане в него, след като почти всяка платформа, която поддържа TCP/IP, обслужва и порт 25? Особено когато това означава, че изтеглената поща ще изглежда като нормална, получена директно от подателя поща, което всъщност е и целта ни.

(Сега обратно към по-високо ниво на обсъждане...)

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

11. Най-доброто нещо след това човек да има добри идеи, е той да може да разпознава добрите идеи от потребителите си. Понякога второто е по-добро.

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

(Когато говорих на конференцията за Perl през август 1997, необикновенният хакер Лари Уол седеше на първия ред. Когато стигнах до горния ред, той извика с религиозна интонация, "Кажи, кажи им, братко!". Всички се засмяха, защото знаеха че това беше помогнало и на създателя на Perl.)

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

Има още две, по-основни, не политически поуки, които важат за всякакъв вид дизайн.

12. Често най-поразителните, оригинални решения се появяват, когато осъзнаеш, че разбиранията ти за проблема са погрешни.

Когато бях се опитал да разработя popclient като комбинация на MTA и MDA с множество методи за локална доставка, бях се опитал да реша неправилния проблем. Дизайнът на fetchmail трябваше да бъде осмислен наново, основно, като чист MTA, като част от нормалния път на пощата през Интернет и SMTP.

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

Е, аз бях преформулирал задачата. Определено това, което трябваше да се направи беше (1) да се превърне поддръжката на SMTP-препращане в обикновен драйвер, (2) да се направи това режима по подразбиране, и (3) в крайна сметка да се изхвърлят всички други режими за доставка, особено тези за доставка във файл и към стандартния изход.

Известно време се колебаех за стъпка (3), защото се страхувах да не обезпокоя старите потребители на popclient, които зависеха от тези алтернативни начини за доставка. На теория те можеха да изпозват .forward файлове или техните еквиваленти за съответната платформа, със същия успех. На практика, преходът можеше да се окаже труден.

Когато все пак направих тази стъпка, ползата беше огромна. Най-грозните части от кода на драйверите изчезнаха. Конфигурирането се опрости значително---нямаше нужда да се безпокоя дали операционната система поддържа заключване на файловете, или да търся системния MDA и mailbox-файла на потребителя.

Също така, единствената възможност да се изгуби поща изчезна. Ако потребителят зададеше доставка във файл и дискът се запълнеше, в стария вариант пощата се губеше. Това не може да се случи при SMTP-препращането, защото SMTP кода ми не отговаря с OK освен ако съобщението не бъде доставено, или поне записано някъде за по-късна доставка.

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

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

Каква е поуката? Не се страхувайте да изхвърлите стари части от кода, ако можете да го направите без загуба на ефективност. Антоан дьо Сан-Екзюпери (който е бил пилот и дизайнер на самолети в моментите когато не е писал класически детски книги) е казал:

13. "Перфектността (в дизайна) е постигната не когато няма какво повече да се добави, а когато няма какво повече да се махне."

Когато кодът ти става едновременно по-добър, и по-прост, знаеш, че е наред. Едновременно с това, fetchmail беше придобил собствена самоличност, различна от тази на popclient.

Беше време за смяна на името. Новият дизайн повече приличаше на аналог на sendmail отколкото popclient беше приличал; и двата бяха MTA-и, но ако sendmail изпраща и доставя, новия popclient получава (издърпва) и доставя. И така, след два месеца го преименувах на fetchmail.

Още един урок свързан с това как fetchmail започна SMTP доставка. Не само дебъгването може да се паралелизира, а също така и разработката (до изненадваща степен) и изследването на пространството от възможни дизайни. Когато режимът ти на разработка е силно итеративен, разработката и подобренията могат да се разглеждат като частен случай на дебъгване---поправка на "липси" в оригиналния код, или дизайн.

Дори на по-виоко ниво на дизайн е полезно човек да има на разположение капацитета на множество помощници, които изследват пространството с дизайни, заобикалящо продукта. Един пример е начинът по който водата намира накъде да изтече, или по-скоро начинът по който мравките намират храна: изследване чрез дифузия, последвано от консумация посредством механизъм позволяващ масивни комуникации. Този метод работи доста добре; както в случая с Хари Хокхайзер, някой от скаутите ти може да намери нещо голямо съвсем наблизо---нещо което не си видял защото си много съсредоточен върху самия продукт.

7. Fetchmail Пораства

И така, имах чист и оригинален дизайн, код за който знаех, че работи добре понеже го използвах всеки ден, и растящ бета-лист. Малко по малко ми "просветна", че това вече не беше тривиален, личен хак, който е полезен и за други хора. В ръцете си държах програма, от която всеки хакер с UNIX машина и SLIP/PPP връзка към пощата наистина се нуждаеше.

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

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

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

Резултата беше доста добър така или иначе---всъщност, точно успеха, за който всеки хакер живее! И това означаваше, че ще трябва още повече да завиша стандартите си. За да направя fetchmail толкова добър, колкото си го представях че може да стане, трябваше да пиша не само за собствените си нужди, но и да добавям и поддържам функционалност, която е нужна на останалите (но иначе извън сферата на интересите ми). И едновременно с това да се грижа програмата да остане проста и стабилна.

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

Реших да добавя тази функция отчасти защото потребителите го искаха, но отчасти защото мислех, че това ще изчисти някои бъгове от кода за доставка до един потребител, като ме накара да се справям с адреси в общ вид. Така и излезе. Правилната обработка на адресите според RFC 822 (http://info.internet.isi.edu:80/in-notes/rfc/files/rfc822.txt) ми отне забележително дълго време, не защото отделните елементи бяха сложни, а защотото имаше сложни зависимости между тях.

Оказа се, че и тази нова добавка беше отлично решение в дизайна. Ето как разбрах това:

14. Всеки инструмент би трябвало да е полезен по очаквания начин, но великият инструмент има възможности които никога не си очаквал.

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

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

15. Когато пишеш софтуер, който има функцията на посредник, прави минимални промени в потока данни---и *никога* не изхвърляй информация, освен ако получателя не те принуждава!

Ако не бях спазил това правило 8-битовата MIME поддръжка щеше да бъде трудно осъществима, и да съдържа много бъгове. А така, трябваше само да прочете MIME стандарта, RFC 1652 (http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1652.txt), и да добавя тривиална логика за генериране на заглавни части (header-и).

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

8. Още Няколко Поуки от fetchmail

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

Синтаксисът на контролният файл rc включва незадължителни ключови думи ("шум"), които парсъра изцяло игнорира. Така, синтаксисът позволява файла да е много по-четлив от традиционните двойки име-стойност, които се получават при премахването на излишните думи.

Всичко това започна като експеримент, който проведох късно през нощта. Забелязах, че декларациите в rc файла започват да приличат на императивен мини-език. (Затова и смених ключовата дума server с poll в оригиналния popclient.)

Изглеждаше ми сякаш езикът е по-лесен за използване, когато прилича на английски. Сега, въпреки че съм убеден привърженик на тенденцията "направи го като език" (която се проявява в Emacs и HTML, както и в много бази от данни), по принцип не съм голям любител на синтаксиси подобни на английския.

Традиционно програмистите са били в подкрепа на компактни контролни граматики, които не съдържат никакъв излишък. Това е културно наследство от времето, когато ресурсите са били скъпи, и етапът на парсването е трябвало да бъде оптимизиран. По онова време, английският език с около 50% излишък е бил лош избор.

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

Има сериозни причини за предпазливост. Една от тях е сложността на парсването---не би било добре то да бъде усложнено до степен, в която то ще бъде източник на бъгове или объркване за потребителите. Другата е, че за да прилича граматиката на естествен език, обикновено трябва езика, който тя генерира да бъде доста "изкривен", до толкова, че повърхностната прилика с естествен език е толкова объркваща, колкото би бил един традиционен език. (Може да видите този дефект в много т. нар. "езици от четвърто поколение", и комерсиални езици за заявки към бази от данни.)

Изглежда, че контролният синтаксис на fetchmail избягва тези проблеми, защото езикът там е много ограничен, и въобще не се доближава до език с общо предназначение; нещата, които той казва не са много сложни и няма опасност за объркване при прехода между малко подмножество на английския и самия контролен език. Мисля, че тук има по-общ урок:

16. Когато езикът е далеч от Тюринг-пълен, "синтактичната захар" (бел. прев.: syntactic sugar---синтактични конструкции които улесняват използването на езика, без да го правят по-мощен) може да бъде полезна.

Другият урок е свързан със сигурността постигната чрез неясност. Някои потребители на fetchmail ме помолиха да пазя паролите в rc файла в кодиран вид, така че те да не могат да бъдат видяни от други хора.

Не го направих, защото това всъщност не носи по-голяма сигурност. Ако някой има възмойност да чете rc файла ви, той може да пусне и fetchmail от ваше име---и ако му трябват паролите ви, той ще може да използва декодера на fetchmail за да ги получи (бел. прев.: проблемът е че fetchmail трябва да прати парола в чист вид на сървъра, за да получи пощата; това означава, че fetchmail в даден момент ще притежава въпросната парола в чист вид; малко ловкост с GDB, и паролата е в лоши ръце).

Това, което кодирането на паролите във .fetchmailrc щеше да донесе е само погрешно усещане за сигурност в хората, които не мислят много. Тук общото правило е:

17. Една система за сигурност е толкова сигурна, колкото е тайна. Пазете се от псевдо-тайните.

9. Необходими Условия за Базарния Модел

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

Ясно е, че кода не може да се зароди като резултат от базарна разработка [5]. Кода може да бъде тестван и подобряван по този начин, но би било много трудно проекта да бъде започнат така. Линус не се опита да направи това. Нито пък аз. Твоята общност от програмисти трябва да има нещо работещо, с което да си играе.

Когато започнеш да изграждаш една общност, трябва да можеш да и дадеш някакво правдоподобно обещание. Няма нужда програмата да работи съвсем добре. Може да бъде груба, пълна с бъгове, непълна и лошо документирана. Но това, което трябва тя да може е (а) да върви и (б) да убеди потенциалните потребители, че може да се развие в нещо наистина добро в близкото бъдеще.

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

Но Линус използва дизайна на UNIX. Аз започнах с popclient (въпреки че после го промених значително, повече от Linux, ако го разглеждаме пропорционално на големината). И така, трябва ли наистина водача на проекта да бъде талантлив дизайнер, или е достатъчно да може да използва чуждия талант?

Не мисля, че координатора трябва да бъде изключително оригинален в дизаините си, но е абсолютно необходимо да има възможността да разпознава добрите идеи на останалите.

И Linux, и fetchmail могат да бъдат доказателство за това. Линус, не до там велик дизайнер (говорихме за това по-рано), демонстрира силно умение да разпознава добрия дизайн и да го използва в ядрото на Linux. Вече описах как най-добрата идея в дизайна на fetchmail (SMTP препращането) получих от друг човек.

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

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

Вярвам, че fetchmail успя защото потиснах естественото си желание да бъда "хитър"; това най-малкото означава, че оригиналността не е съществен фактор за успеха на базарните проекти. Да разгледаме Linux. Ако Линус Торвалдс се беше опитал да внесе фундаментално нови елементи в операционната система по време на разработката, щеше ли ядрото да бъде толкова стабилно и успешно, колкото е сега?

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

Има още нещо, което нормално не се свързва с разработката на софтуер, но смятам че е също толкова важно, колкото оригиналността---ако не и по-важно. Координатора на един базарен проект трябва да има умението да общува добре с хората.

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

Не случайно Линус е приятен тип, когото хората харесват, и на когото искат до помогнат. Не е случайно и това, че съм енергичен екстроверт, на когото е приятно да работи с хора и има някои от чертите на комик. За да работи базарният модел, добре е да имаш поне малко умение да очароваш хората.

10. Социалният Контекст на Open-Source Софтуера

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

18. За да решиш някой интересен проблем, започни като намериш проблем който ти е интересен.

Така и беше в случая на Карл Харис и popclient, както и на мен и fetchmail. Но това отдавна е било разбрано. Интересният момент, върху който историята на Linux и fetchmail ни кара да се замислим, е следващият етап---еволюцията на софтуера при наличието на голямо общество от потребители и съмишленици.

В "Митичният Човеко-Месец", Фред Брукс забеляза че времето за програмиране не е заменяема вещ; добавянето на програмисти към проект, който изостава, кара този проект да изостане още повече. Той се обоснова с това, че сложността и разходите за общуване на проекта се увеличават с квадрата на броя програмисти, докато извършената работа расте линейно. Това твърдение стана известно като "Закон на Брукс", и често се смята за истина. Но ако това беше абсолютната истина, Linux не би съществувал.

Класическата книга на Джерълд Уейнбърг "Психология на Програмирането" отбеляза една важна корекция на твърдението на Брукс. В обсъждането си на "програмиране без его", Уейнбърг обърна внимание на това, че във фирми, където програмистите споделят кода си и окуражават останалите да го разглеждат и поправят, развитието на кода е много по-бързо от колкото на което и да било друго място.

Изборът на термини на Уейнбърг верятно попречи на анализа му да добие популярността, която заслужава---идеята, че хакерите на Интернет са "без его" изглежда смешна. Но аз мисля, че неговите аргументи днес изглеждат по-силни от всякога.

Историята на UNIX трябваше да ни подготви за това, което научаваме от Linux (и което проверих експериментално в по-малък мащаб като копирах методите на Линус [6]). Т.е., докато писането на код до голяма степен остава индивидуално занимание, най-великите програми са резултат от вниманието и умствените усилия на цели общества. Програмистът, който използва само личните си възможности в затворен проект неизбежно ще изостане зад този, който успее да създаде отворен, еволюционен контекст, в който мнения за пространството от дизаини, код, корекции на бъгове и други подобрения идват от стотици (може би хиляди) хора.

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

Преди евтиният Интернет, съществуваха няколко географски компактни общества, където културата поощряваше програмирането "без его" на Уейнбърг, и един програмист можеше лесно да намери много и квалифицирани зрители и съавтори. Bell Labs, ИИ лабораторията към MIT, Бъркли---те станаха източници на много легендарни открития, които са все още живи и полезни.

Linux беше първият проект, който направи съзнателно и успешно усилие да впрегне целия свят като източник на талант. Не мисля, че времето по което Linux се разви и раждането на WWW съвпаднаха случайно, нито това, че Linux напусна "детските" си години през 1993-94, когато ISP индустрията (бел. прев.: Интернет доставчиците) се заздрави и масите проявиха интерес към Интернет. Линус беше първият човек, който се научи да играе по новите правила, които създаде масовият достъп до Интернет.

Докато евтиният достъп до Интернет беше необходимо условие да се развие модела на Linux, мисля че той не беше достатъчно условие. Друг важен фактор беше развитието на ръководен стил и набор от правила, които позволяват на авторите да намират съавтори и да получат максимална полза от създадената среда.

Но какъв е този ръководен стил, и какви са тези правила? Те не могат да са основани на надмощие---и дори да бяха, нямаше да доведат до резултатите които виждаме. Уейнбърг цитира автобиографията "Мемоари на Един Революционер" на руския анархист от 19-ти век Пьотр Алексеевич Кропоткин:

След като бях отрасъл в семейство, което притежаваше крепостници, навлязох в живота като всички останали младежи от времето си---с много вяра в необходимостта от команди, заповеди, порицания, наказания, и т.н. Но когато скоро ми се наложи да ръководя сериозни начинания, и да работя със [свободни] хора, и когато всяка грешка можеше да доведе до тежки последици, започнах да разбирам разликата между командване и дисциплина, и принципите на общото разбирателство. Първото работи отлично при военен парад, но не струва нищо в реалния живот, когато целта може да се постигне само чрез волята на много съсредоточени съмишленици.
Тази "воля на много съсредоточени съмишленици" е точно това, което проект като Linux изисква---и "принципът на командване" е на практика невъзможен сред доброволците в анархистичния рай, който наричаме Интернет. За да работят и да се съревновават ефективно, хакерите които искат да водят отворени проекти трябва да се научат как да "вербуват" и поощряват ефективни и заинтересувани общества по начин загатнат от "принципите на общо разбирателство" на Кропоткин. Трябва да се научат да използват Закона на Линус. [7]

По-рано говорих за ефекта "Делфи" и едно възможно обяснение на Закона на Линус. Но съществуват и по-мощни аналогии с адаптиращи се системи в биологията и икономиката. Светът на Linux се държи, в известен смисъл, като свободен пазар, или екосистема, общество от агенти със собствен интерес, които се стремят да максимизират ползата, което от своя страна води до самозараждащ и самокоригиращ се ред, по-добър и ефикасен от този, който централното планиране би постигнало. Тук, следователно, трябва да търсим "принципите на общо разбирателство".

Функцията на "ползата", която хакерите на Linux максимизират не е класически икономическа, а неосезаема смес от задоволяване на егото и репутация сред останалите хакери. (Някой може да нарече мотивацията им "алтруизъм", но алтруизмът сам по себе си е вид задоволяване на егото на алтруиста). Доброволческите общества, които работят по този начин не са нещо ново; едно друго такова е обществото на любители на научна фантастика, където за разлика от хакерското общество "его-засилването" (засилването на нечия репутация сред останалите любители) е отдавна признато за основна движеща сила на доброволния труд.

Линус демонстрира доброто наблюдение на Кропоткин за "принципите на общо разбирателство", като зае ролята на страж на проект в който разработката се води предимно от други хора, и подхранваше интереса в този проект докато в един момент той не започна сам да се поддържа. Този квази-икономически поглед върху света на Linux ни дава възможност да видим как работи това разбирателстово.

Можем да разглеждаме метода на Линус като начин да се създаде ефикасен пазар на "его-засилване"---да се свърже личния интерес на отделни хакери в едно, за да бъдат постигнати цели, недостъпни за самостоятелни хора. С проекта fetchmail аз показах (въпреки и в по-малък мащаб), че тези методи могат да бъдат повторени успешно. Вероятно дори аз ги приложих малко по-систематично и съзнателно от него.

Много хора (особено тези, които не вярват с свободните пазари) очакват една култура от егоисти водени от лични интереси да бъде фрагментирана, разделена, неефективна, потайна, и враждебна. Изобилната, качествена и разнообразна документация на Linux (например) опровергава това очакване. Общоприето е мнението, че програмистите мразят да документират; как тогава хакерите на Linux успяха да напишат толкова документация? Очевидно свободният пазар на "его-засилване" в Linux култивира добри практики по-добре от силно парично обезпечените отдели за документация на комерсиални продукти.

Ядрото на Linux и fetchmail показват, че като възнаграждава егото на многото други хакери, добрият програмист/координатор може да използва Интернет за да извлече полза от съавторите си без да позволи на проекта да се срине хаотично. И така, имам следното предложение в отговор на Закона на Брукс:

19. Ако координаторът на разработката има среда поне толкова добра, колкото Интернет, и знае как да води без да заповядва, няколко глави са неизбежно по-добри от една.

Мисля че бъдещето на open-source софтуера все повече и повече ще принадлежи на хора, които знаят как да играят играта на Линус, хора изоставили катедралата, и обърнали се към базара. Това не значи, че индивидуалната мисъл и умения вече няма да бъдат от значение; по-скоро смятам, че предните редици на open-source ще бъдат водени от хора, които започват от индивидуални идеи и възможности, и ги усилват като създават доброволни общества с определен интерес.

Това вероятно не е само бъдещето на open-source софтуера. Никой самостоятелен програмист не може да се сравнява с уменията на цялото Linux общество. И много малко фирми могат да си позволят да наемат тези повече от двеста (1999: шестстотин, 2000: осемстотин) хора, които имаха принос във fetchmail!

Може би най-накрая културата на open-source ще спечели не защото взаимопомощта е морално по-добрият вариант, или пък "пазенето" на софтуера морално лошо (ако въобще някой вярва в това---нито аз, нито Линус вярваме), но просто защото затвореният свят не може да спечели еволюционната надпревара с отворените общества, които могат да посветят с няколко порядъка по-големи сили на всеки даден проблем.

11. За Мениджмънта и Линията на Мажино

(бел. прев.: Линията на Мажино е известно укрепление на границата между Франция и Германия, построено през Първата световна война от Франция; след като устоява на немските атаки, то е развито и подсилено значително; през Втората световна война ролята му е минимална, защото немците нахлуват през Белгия)

Оригиналната статия "Катедралата и Базарът" от 1997 година завърши с горното пророчество---описващо весели орди програмисти/анархисти, свързани в мрежа и побеждаващи йерархичния свят на затворения софтуер.

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

Традиционно-мислещите мениджъри в разработката на софтуер твърдят, че лекотата, с която групите работещи по различни проекти с open-source се променят и разпадат неутрализира численото превъзходство на open-source движението. Те забелязват, че при разработката на софтуер от значение са по-скоро продължителната инвестиция на време за изграждането на даден продукт, както и вярата на клиентите, че тази инвестиция ще продължи в бъдещето, отколкото броят на хората които са хвърлили кокал в гърнето и са го оставили да ври.

В този аргумент има нещо вярно, наистина; всъщност, аз разработих идеята, че очакваната стойност на бъдещите услуги е ключа към икономиката на софтуерната разработка в "Магическото Гърне" (http://www.tuxedo.org/~esr/writings/magic-cauldron/).

Но в този аргумент също така се крие и един проблем; той неявно приема, че open-source не може да даде такова продължително участие (т.е. инвестиция на време от стабилна група хора). Всъщност, имало е open-source проекти, които са поддържали постоянна посока и ефикасно общество от поддръжници и програмисти в продължение на много време, без помощта на поощренията и контрола, които конвенционалния мениджмънт намира за съществени. Разработката на редактора GNU Emacs е един краен и много поучителен пример; той е получил усилията на стотици програмисти в продължение на 15 години, като при това е запазил единна архитектура, въпреки честата смяна на хората, които го поддържат и факта, че само един човек (авторът) е бил активен участник през цялото време. Никой редактор със затворен код не е достигнал този рекорд по дълголетие.

Това дава причина да се съмняваме в предимствата на разработката под конвенционален медиджмънт, която е независима от останалите аргументи в спора между катедралата и базара. Ако е възможно GNU Emacs да има кохерентна архитектура в продължение на 15 години, или една операционна система като Linux да направи същото нещо в продължение на 8 години, при бързо променящи се хардуер и платформи; и ако е имало много open-source проекти, които са издържали повече от 5 години (какъвто е случаят)---тогава можем да се запитаме каква полза оправдава огромните разноски по мениджмънта.

Каквато и да е тази полза, тя със сигурност не е надеждното изпълнение и спазването на крайните срокове, или пък бюджета; рядко проекти "с мениджмънт" успяват да постигнат и една от тези цели, а какво остава за всичките три. Също така, изглежда че ползата не е в лекотата на адаптация към промени в технологиите и икономиката по време на проекта; отвореното общество доказа, че е далеч по-ефективно в тази насока (това всеки може да види, например като сравни 30-годишната история на Интернет с късите периоди на полуразпад на различните затворени мрежови технологии---или цената на прехода на Microsoft Windows от 16-битови машини на 32-битови с почти безпроблемната миграция на Linux по същото време, и то не само в гамата процесори на Intel, а и в повече от дузина други хардуерни платформи, които включват и 64-битовия Alpha).

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

И така, какво ни дават разходите за мениджмънт?

За да разберем това, трябва първо да разберем какво софтуерните мениджъри мислят че правят. Една моя позната, която изглежда разбира от тази работа, казва че мениджърите на проекти имат пет функции:

Очевидно това са добри цели; но в модела на open-source, и обграждащия го социален контекст те започват да изглеждат странно ненужни. Ще ги атакуваме в обратен ред.

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

Но програмистите в open-source са доброволци, самоизбрани заради интереса и умението си да допринесат нещо в проектите, по които работят (и по принцип това остава вярно, дори когато им се плаща някаква заплата за това). Доброволското общество автоматично се справя и началното получаване на ресурси; хората участват със собствените си ресурси. И почти никога няма нужда от мениджър, който да "играе в защита"---в традиционния смисъл.

Както и да е, в света на евтините компютри и бързия Интернет, почти неизменно установяваме, че единственият наистина ограничен ресурс е квалифицираното участие на хората. На практика, отворените проекти никога не пропадат поради липса на компютри, липса на Интернет, или липса на офиси; те замират когато участниците изгубят интерес.

При това положение, още по-важно е хакерите на open-source да се самоорганизират за максимална продуктивност, чрез самоизбиране----и тук компетентността играе голяма роля. Моята позната, която е запозната и с двата свята, вярва че open-source движението успява, защото то допуска само най-добрите 5% в редиците си. Тя прекарва повечето си време в това да организира останалите 95%, и така има лични наблюдения за стократната разлика между уменията на най-добрите и тези на просто способните.

Тази огромна разлика постоянно повдига следния неудобен въпрос: не би ли било по-добре за проектите, ако бъдат махнати от тях хората, които се намират в долните 50%? Умните мениджъри отдавна са наясно, че ако единствената функция на мениджмънта е да превърне най-малко способните от чиста загуба в символична печалба, то това е труд хвърлен на вятъра.

Успехът на open-source общността изостри този въпрос значително, като даде доказателство за това, че понякога е по-евтино и по-ефективно да бъдат завербувани самоизбрани доброволци от Интернет, отколкото да бъдат управлявани сгради пълни с хора, които по-скоро биха се занимавали с нещо друго.

И това леко ни довежда до въпроса с мотивацията. Еквивалентен, и често срещан начин да бъде перефразирана идеята на познатата ми е че традиционният мениджмънт компенсира немотивираните програмисти, които иначе не биха вършили добра работа.

Това често идва заедно с твърдението, че програмистите на отворен код могат само да вършат работа която е привлекателна или технически интересна; всичко друго би останало недовършено (или лошо свършено) ако не бяха робите от офисите, мотивирани от пари и от мениджъри с камшици. В "Заселването на Ноосферата" дискутирам психологическите и социалните причини за това да нямам доверие на това твърдение. За сега обаче, мисля че е по-интересно да отбележим последствията, ако приемем че твърдението е вярно.

Ако конвенционалният, затворен, силно контролиран стил на разработка на софтуер е наистина защитен само от една своеобразна линия на Мажино, едно укрепление от отегчителни проблеми, то той ще остане жизнен в дадена сфера на приложения само докато не се намери някой, който смята че тези проблеми са наистина интересни или никой не може да намери заобиколен път. Защото в момента, в който има open-source инициатива за написването на някой "отегчителен" продукт, клиентите ще знаят, че най-накрая той е написан от хора, които наистина са решили да се преборят с проблема, защото той им е интересен---което в софтуера, както и в други видове творчество е много по-ефикасен мотиватор от парите.

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

До тук видяхме, че софтуерният мениджмънт губи по два показателя (осигуряване на ресурси, организация), и само временно води по третия (мотивация). И горкият мениджър със сигурност няма да може да се наложи в показателя следене; най-силният аргумент на отворената разработка е предимството на децентрализираната проверка на кода от съмишленици пред останалите традиционни методи да се провери "дали нещо не липсва".

Можем ли тогава да кажем, че дефинирането на цели е оправданието за сериозните разходи, които се правят за мениджмънта? Може би; но тогава ще трябва да покажем убедително, че ръководните отдели и фирмените планове могат да дефинират значими и популярни цели по-добре от водачите на проекти и "старейшините" които имат аналогична роля в света на open-source.

Това ще бъде доста трудно, и то не заради величието на отворената разработка на софтуер (дълголетието на Emacs, умението на Линус Торвалдс да мобилизира цели орди програмисти с речи за "превземане на света"), а заради неумението на традиционните механизми да дефинират цели за софтуерните проекти.

Една от най-известните популярни теореми за софтуерното инженерство гласи, че между 60% и 75% от конвенционалните софтуерни проекти или никога не биват завършени, или биват отхвърлени от потенциалните потребители. Ако тези числа са близо до истината (а аз никога не съм срещал мениджър с опит, който да ги отхвърли), то повечето софтуерни проекти имат цел, която е (а) практически непостижима, или (б) просто неправилна.

Това е най-голямата причина изразът "ръководна група" произнесен с света на софтуерното инженерство да изправя косите на всеки, който го чуе---дори (или особено) ако той е мениджър. Отдавна са отминали дните, когато само програмистите се оплакваха от това; сега комиксите с Дилбърт висят по стените на големите шефове.

Тогава нашият отговор към традиционноя мениджър може да бъде---ако open-source обществото наистина подценява стойността на конвенционалният мениджмънт, защо толкова много от вас не вярват в работата която вършите?

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

Две и половина години след първате версия на това есе, най-радикалната мисъл, която мога да предложа за завършек вече не е пророчество за свят доминиран от отворен софтуер; в крайна сметка, това днес звучи правдоподобно да доста трезви хора в костюми.

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

Когато се отнасяш към работата си със страх и омраза (дори по различния, ироничен начин изразен в окачването на комикси с Дилбърт в офиса), това би трябвало да бъде знак, че процесът се е провалил. Веселието, хуморът, и игривостта са наистина предимства; не заради израза "весели орди" по-горе, или като шега знакът на Linux е дружелюбният, общителен пингвин.

Нищо чудно да се окаже, че най-важният ефект на open-source е да ни научи, че развлечението е икономически най-ефективният начин за вършене на творческа работа.

12. Благодарности

Тази статия беше подобрена в резултат от разговорите с много хора, които помогнаха тя да бъде изчистена от грешки. Особени благодарности дължа на Джеф Дътки (dutky@wam.umd.edu), който предложи формулировката "дебъгването може да се паралелизира", и помогна да развием анализа, който произлиза от нея. Също и на Ненси Лебовиц (nancyl@universe.digex.net) за това, че посочи как наподобявам на Уейнбърг като цитирам Кропоткин. Критика с разбиране получих от Джоан Еслинджър (wombat@kilimanjaro.engr.sgi.com), и Марти Франц (marty@net-link.net) от списъка General Technics. Глен Ванденбург (glv@vanderburg.org) посочи колко важно е участниците в обществото на даден проект да бъдат самоизбрани, и даде полезната идея, че такъв начин на разработка коригира бъговете, които са породени от липсваща функционалност в кода; Дениъл Апър (upper@peak.org) даде естествените аналогии за това. Благодаря на членовете на PLUG, user-групата на Linux от Филаделфия, за това че бяха първата пробна публика за първата версия на тази статия. Пола Матузек (matus00@mh.us.sbphrd.com) ме просвети относно практиките в софтуерния мениджмънт. Фил Хъдзън (phil.hudson@iname.com) ми напомни за това, че социалната организация на хакерската култура наподобява организацията на нейния софтуер, както и обратното. И накрая, коментарите на Линус Торвалдс бяха полезни, а ранната му подкрепа---много окуражаваща.

13. Допълнителна Литература

Цитирах няколко части от класическата книга на Фредерик Брукс "Митичният Човеко-Месец", защото в много отношения неговите идеи са останали верни до сега. Горещо препоръчвам изданието на Addison-Wesley (ISBN 0-201-83595-9) по случай 25-тата годишнина от първото публикуване, в което е добавена статията "Няма Сребърен Куршум", написана през 1986 г.

Новото издание е обвито с поглед от перспективата "20 години по-късно", в който Брукс признава малкото твърдения от оригиналния текст, които не са устояли на времето. Прочетох този поглед назад след като първата публикувана версия на тази статия беше почти завършена, и бях изненадан да установя, че Брукс приписва практика в стил базар на Microsoft! (Оказа се обаче, че това не е вярно. През 1998 научихме от Документите от Празника на Вси Светии (Halloween Documents---http://www.opensource.org/halloween/), че обществото от програмисти вътре в Microsoft е силно балканизирано (бел. прев.: т.е. разкъсано; интересна и поучителна е употребата на думата "balkanized" на това място, но това е тема за цяла друга статия може би), като общият достъп до код, нужен за поддържането на базар е дори невъзможен.)

Книгата на Джерълд Уейнбърг "Психологията на Програмирането" (Ню Йорк, Van Nostrand Reinhold 1971) въведе концепцията за "програмиране без его"---израз, който за съжаление не придоби известност. Въпреки, че той не беше първият човек, който разбра безполезността на "командването", вероятно пръв се досети, и обоснова, че то е безполезно в програмирането.

Ричърд Гейбриъл, в разсъжденията си за UNIX-културата в ерата преди Linux, с нежелание показа предимствата на един примитивен базарен модел в статията си от 1989 г. "Лисп: Добри Новини, Лоши Новини, и Как да Спечелим". Въпреки, че е остаряло в някои отношения, това есе все още е на почит сред феновете на Лисп (сред които съм и аз). Един мой кореспондент ми напомни, че частта озаглавена "По-лошо е По-добре" звучи като пророчество за Linux. Статията е достъпна на http://www.naggum.no/worse-is-better.html.

Книгата "Peopleware: Продуктивни Проекти и Групи" (Ню Йорк, Dorset House, 1987, ISBN 0-932633-05-6) на Де Марко и Листър е неоценен бисер, който, както с удоволствие забелязах, Фред Брукс цитира в ретроспективния си анализ. Въпреки че малко от това, което авторите казват е свързано директно с Linux или open-source обществата, тяхното разбиране за условията необходими за творческа работа е ясно и полезно за всеки, който се опитва да внесе някои от предимствата на базарния модел в комерсиална среда.

Най-накрая трябва да призная, че за малко щях да нарека тази статия "Катедралата и Агората", където второто е гръцката дума за отворен пазар или обществено място за събирания. Основополагащите статии за "agoric systems" на Марк Милър и Ерик Дрекслер, описвайки свойства от по-висок ред в подобните на пазар изчислителни екологии, ми помогнаха да се подготвя да мисля по-ясно за аналогичните явления в open-source културата, в които Linux ми натри носа 5 години по-късно. Тези статии могат да бъдат намерени на Web-а на http://www.agorics.com/agorpapers.html.

14. Епилог: Netscape Обгръща Базара

Странно е усещането, когато разбереш, че действията ти имат историческо значение...

На 22 януари, 1998, приблизително седем месеца след като за пръв път публикувах "Катедралата и Базарът", Netscape Communications, Inc. съобщи за плановете си да направи достъпен кода на Netscape Communicator (http://www.netscape.com/newsref/pr/newsrelease558.html). Нямах ни най-малката представа за това в деня преди съобщението.

Скоро след това, Ерик Хан, изпълнителен вице-президент и технически директор в Netscape, ми изпрати следния e-mail: "От името на всички в Netscape, бих искал да Ви благодаря, че ни помогнахте да достигнем до този момент. Вашите разсъждения и статии бяха основен източник на вдъхновение за нашето решение."

Следващата седмица взех самолета до Силициевата Долина по покана на Netscape, за да участвам в еднодневна стратегическа конференция (на 4 февруари, 1998) с някои от техните висши директори и технически персонал. Заедно създадохме стратегията на Netscape по освобождаването на сорс-кода и отворените права върху него.

Няколко дни по-късно написах следното:

Netscape се готви да ни предложи реална и мащабна проверка на базарния модел в комерсиалния свят. Културата на open-source е в опасност; ако опитът на Netscape не проработи, концепцията за отворен сорс може да бъде дискредитирана до там, че комерсиалния свят да не иска да има нищо общо с нея в следващите десет години.

От друга страна, това е една зрелищна възможност. Първите реакции на Wall Street и други финансови среди при това действие бяха реакции на предпазливо удобрение. Това е шанс за нас да се докажем. Ако Netscape си възвърне значителна част от пазара след този ход, това може да даде началото на революцията в софтуерната индустрия, която отдавна чакаме.

Следващата година би трябвало да е много поучителна и интересна.

Така и стана. За сега, в средата на 1999 година, разработката на продукта по-късно наречен Mozilla е само частично успешна. Тя постигна първоначалната цел да попречи на Microsoft да стане монополист в пазара на Интернет браузъри, и освен това имаше няколко успешни резултата (като например разработването на новата версия на машината за рендърване Gecko). (бел. прев.: Gecko наричат тази част от кода на Mozilla, която се грижи за това как заредения документ да бъде "нарисуван"---къде да бъдат разположени отделните елементи, и т.н.; от своя страна Mozilla и браузъра на Netscape не са едно и също нещо---Netscape използва кода от Mozilla като основа за продукта си.)

Все още обаче Mozilla не е получил масивния принос от общността, на който основателите се надяваха. Тук изглежда проблема е, че дълго време дистрибуцията на Mozilla нарушаваше едно от основните правила в базарния модел; тя не беше нещо, което потенциалните участници могат лесно да пуснат и видят работещо. (В продължение на повече от година след започването на проекта, компилирането на Mozilla изискваше наличието на "затворената" библиотека Motif.)

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

И наистина, не е. Дългосрочната прогноза за Mozilla сега (август 2000) изглежда има драматично подобрение в сравнение с тази по времето, когато Джейми Зауински напусна---но той беше прав, като посочи, че отварянето на кода само по себе си няма да спаси проект, който страда от зле-дефинирани цели, объркан код, или друга хроническа болест на софтуерното инженерство. Mozilla едновременно показа как един отворен проект може да успее, и да се провали.

Междувременно, обаче, идеята за отворения код отбеляза други успехи, и намери подкрепа другаде. През 1998 и 1999 интересът към този модел нарастна, и това беше тенденция причинена от успеха на Linux, и едновременно с това подпомагаща този успех. Тази тенденция, до която Mozilla се докосна, продължава и се усилва.

15. Заключителни Бележки

[1] В "Programming Perls", бележитият софтуерен афорист Джон Бентли коментира наблюдението на Брукс: "Планирай да изхвърлиш една, така или иначе ще изхвърлиш поне две.". Той почти със сигурност е прав. Това, което и двамата искат да кажат не е просто че се очаква първия опит да е погрешен, а че да започнеш на ново с добра идея е обикновено по-ефикасно от това да се опитваш да спасиш вече съществуващата, но объркана реализация.

[2] Известни са примери за отворен код и базарен стил на разработка от преди разрастването на Интернет, които не са свързани с традициите в UNIX и Интернет. Разработката на програмата за компресиране info-Zip през 1990-1992 (http://www.cdrom.com/pub/infozip/), най-вече за DOS-машини, беше един такъв пример. Друг пример е разработката на системата RBBS (отново за DOS), която започна през 1983 и създаде достатъчно силна общност, за да има редовно нови версии и до този момент (средата на 1999) въпреки огромните технически преимущества на пощата в Интернет, и публикуването на файлове на локални BBS-и. Докато общността на info-Zip разчиташе до известна степен на Интернет-пощата, RBBS обслужваше голям брой потребители, които бяха изцяло независими от TCP/IP инфраструктурата.

[3] Джон Хеслър предложи интересно обяснение на факта, че извършването на една и съща работа (бел. прев.: т.е. случая, когато повече от един човек направи дадена корекция в кода) не е голям проблем в разработката с отворен сорс код. Ще го нарека "Закон на Хеслър": цената на повторената работа расте субквадратично като функция на броя програмисти---т.е. по-бавно от планирането и мениджмънта, които са нужни за предотвратяването и.

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

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

Отвъд тази големина комбинацията на Закона на Линус и Закона на Хеслър предполага, че цената и проблемите в традиционния мениджмънт се увеличават много по-бързо, отколкото очакваното увеличение в разходите по повторно извършената работа. Част от тази цена е структурната невъзможност да се извлече полза от "ефекта на многото зрители", който (както видяхме) изглежда е много по-добър начин да се провери, че всички бъгове са коригирани и всички необходими функции са налични. И така, в случая на голям проект комбинацията от тези закони на практика прави печалбата от традиционния мениджмънт да клони към нула.

[4] Разделянето на стабилните и експериментални версии в Linux има и друга функция, която е свързана с намаляването на риска, но е различна от него. Разделянето атакува и друг проблем: крайността на крайните срокове. Когато на програмистите им бъдат дадени едновременно непроменяем списък с необходими свойства (функции) на продукта, и фиксирана крайна дата, качеството пада драстично и вероятно се очакват проблеми. Задължен съм на Марко Янсити и Алън МакКормак от Харвардското Бизнес-Училище за това че ми показаха доказателства, че отслабването на което и да е от тези ограничения може да направи планирането възможно.

Един начин за това е да се фиксира крайния срок, но списъкът с възможности на продукта да остане гъвкав, за да бъде възможно някои възможности да бъдат махнати, ако не бъдат завършени до крайния срок. Това като цяло е стратегията на "стабилната" версия на ядрото; Алън Кокс (човекът, който поддържа стабилното ядро) пуска нови версии на сравнително равномерни интервали, но не дава гаранция кога дадени грешки ще бъдат коригирани, или кога нови възможности ще бъдат прехвърлени от експерименталния вариант.

Другия начин да бъде направено възможно планирането е да се фиксират нужните възможности и да бъде публикувана нова версия само когато те са налице. Това е стратегията на "експерименталната" версия на ядрото. Де Марко и Листър цитират изследвания, които показват, че тази дисциплина на планиране ("събуди ме, когато е готово") дава не само най-качествения код, но и средно разработка в по-кратки срокове отколкото при "агресивното" или "реалистичното" планиране.

Напоследък подозирам (в средата на 2000), че предните версии на тази статия сериозно подцениха важността на политиката "събуди ме, когато е готово" (срещу крайните срокове) за производителността и качеството постигнати от общността на open-source . Опитът с прибързания GNOME 1.0 през 1999 показва, че натискът за преждевременни версии може да унищожи много от предимствата в качеството, които отворения код по принцип носи.

[5] Един въпрос свързан с това дали може един проект да бъде започнат в базарен стил от нулата е дали базарният стил е способен да поддържа наистина изследователска работа. Някои твърдят, че без силно водачество базарът може само да клонира и подобрява идеи, които вече съществуват в инженерния свят, но не може да предизвиква нови постижения. Този аргумент беше даден най-скандално в Документите от Деня на Вси Светии (бел. прев.: Halloween Documents) (http://www.opensource.org/halloween/), два документа, вътрешни за Microsoft, относно явлението open-source, предизвикали доста неудобство. Авторите сравняват разработката в Linux на операционна система подобна на UNIX със "следване на задните светлини", и твърдят, че "(когато проекта се изравни с текущото ниво на науката), количеството мениджмънт необходимо за да се постигнат нови успехи става огромно."

Този агрумент съдържа сериозни фактически грешки. Една от тях излиза наяве, когато авторите по-късно сами отбелязват "често [...] новите изследователски идеи първо биват реализирани и налични в Linux преди да бъдат налични / включени в други платформи."

Ако в това изречение заменим Linux с open-source, виждаме едно далеч не ново явление. Исторически, open-source общността не изобрети Emacs, нито World Wide Web, нито пък Интернет като следваше това, което е вече изобретено, или с масивен мениджмънт---и в момента в общността има толкова много новаторска работа, че на чосек му е трудно да избере пример. Проектът GNOME (да изберем един от многото) до толкова стимулира развитието в областта на GUI и обектните технологии, че привлече значително внимание от компютърната преса доста извън Linux общността. Има цял легион други примери, в което всеки може да се убеди ако посети Freshmeat (http://freshmeat.net).

Но самото неявно предположение, че катедралния модел (или базарния модел, или който и да е вид организационна структура) може надеждно да предизвика новаторство е грешно. Това са глупости. Групите нямат революционни идеи---дори доброволческите групи от базарни анархисти обикновено не са способни на чиста оригиналност, а да не говорим за фирмените съвети от хора, които имат голям интерес в това да се запази статуквото. Идеите идват от индивиди. Единственото, на което обкръжаващата ги социална машина може да се надява да направи е да отговаря на революционните идеи---да ги подхранва, поощрява, и тества усърдно, вместо да ги потиска.

Някои ще сметнат, че това е романтична гледна точка, възобновяване на остарелите стереотипи за самотния изобретател. Това не е така; не твърдя, че групите не са в състояние да разработят идеите, когато те се "излюпят"; наистина, от процеса на "преглеждане от партньори" (бел. прев.: когато вашите колеги могат да прегледат вашия код, и да го критикуват) научихме, че работните групи са съществени за постигането на качествен резултат. По-скоро искам да кажа, че груповата разработка се подклажда от една добра идея родена от главата на един човек. Катедралите, базарите, и другите социални структури могат да хванат и впрегнат светкавицата, но не могат да я създадат.

И така, основният проблем при изобретенията (в софтуера или където и да било другаде) е как те да не бъдат потиснати, или по-фундаментално как да създадем много хора, които имат идеи.

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

И наистина, ако разгледаме историята на софтуерните изобретения в организации използващи катедралния модел, бързо установяваме, че те са доста редки. Големите фирми разчитат на изследванията в университетите за да получават нови идеи (и от там неспокойствието на авторите на Halloween Documents във връзка с възможностите на Linux да използва тези изследвания по-бързо). Или купуват по-малки фирми, построени около идеята на някой новатор. В никой от тези случаи идеята не произлиза от катедралната култура; и всъщност много нови идеи биват внесени само за да бъдат задушени под "огромният мениджмънт", който Halloween Documents толкова възхваляват.

Това обаче е отрицателен пример. На читателите ще е по-полезно положителното доказателство. Предлагам следния експеримент:

В деня, когато написах това, във Freshmeat се появиха 22 съобщения, от които 3 изглежда имаха потенциала да допринесат за развитието на нови технологии. Това беше един от "бавните" дни на Freshmeat, но бих се изненадал ако някой от читателите докладва за 3 новаторски идеи в продължение на месец в който и да било източник за новини, за произволна затворена ОС.

[6] Вече имаме историята на един проект, който по няколко начина може да служи за по-добра проверка на базарната идея от fetchmail; EGCS (http://egcs.cygnus.com/), Експериментална Компилаторна Система за GNU.

Този проект бе обявен през средата на август 1997 като съзнателен опит да бъдат приложени идеите от ранните публикувани версии на "Катедралата и Базарът". Основателите на проекта смятаха, че разработката на GCC, GNU Компилатор на C е в застой. В продължение на 20 месеца след това GCC и EGCS продължиха да съществуват успоредно---и двата използваха усилията на същата група участници в Интернет, и двата започнаха с кода на GCC, със същите помощни програми за UNIX и същите развойни системи. Разликата беше само в това, че EGCS съзнателно се опитваше да приложи базарните тактики, които бях описал, докато GCC запази катедрало-подобната си организация със затворена група програмисти и редки нови версии.

Това беше възможно най-добре контролираният експеримент, който някой би пожелал, и резултатите бяха драматични. В рамките на месеци версиите на EGCS бяха значително по-напред по възможности; по-добри оптимизации, по-добра поддръжка на FORTRAN и C++. Много хора установиха, че работните копия на EGCS са по-надеждни от последната стабилна версия на GCC, и основни дистрибуции на Linux започнаха да се ориентират към EGCS.

През април 1999, Фондацията за Свободен Софтуер (официалният спонсор на GCC) разпусна първоначалната работна група на GCC и официално предаде контрола върху проекта на ръководната група на EGCS.

[7] Разбира се, критиката на Кропоткин и Законът на Линус повдигат по-широки въпроси за кибернетиката на социалните организации. Една друга популярна теорема в софтуерното инженерство показва един от тях; Законът на Конуей---често изричан "Ако имаш четири групи, който работят по един компилатор, ще получиш четири-пасов компилатор". Оригиналният изказ е по-общ: "Организациите, които планират системи са принудени да създават дизайни, които са копия на комуникационните структури в тези организации." С други думи, "Начинът определя резултата", или дори "Процесът се превръща в продукт".

Съответно, струва си да отбележим, че в open-source общността организационната форма и функцията съвпадат на много нива. Мрежата е всичко и навсякъде: не само Интернет, но и хората образуват разпределена, необвързана мрежа с директен достъп между всеки двама участници, която дава много излишък и деградира плавно. И в двете мрежи даден елемент е важен до толкова, до колкото останалите искат да работят с него.

Директната връзка е съществена за високата продуктивност на общността. Идеята на Кропоткин за командването намира развитие в принципа "SNAFU": "Истинското общуване е единствено възможно между равни, защото подчинените биват поощрявани да казват на началниците си приятни лъжи вместо истината." Съзидателната работа в група зависи изцяло от доброто общуване и е сериозно затруднена от взаимоотношения, които включват власт на един над друг. Open-source общността, която е на практика освободена от такива взаимоотношения, показва колко много струват те в смисъл на бъгове, ниска продуктивност и пропуснати възможности.

Също така, принципът "SNAFU" предвижда, че в организациите основани на власт разстоянието между тези, които взимат решения и реалността ще се увеличава постоянно, понеже все повече и повече от информацията, която те получават ще бъде просто приятни лъжи. Начинът, по който това се отразява на конвенционалната разработка на софтуер е ясен; подчинените имат сериозни причини да крият, пренебрегват и умаловажават проблемите. Когато този процес се превърне в продукт, софтуерът е боклук.

©1992-2015 Hristo Bojinov. Contact: hristo-at-bojinov-dot-org. This address is subject to change.


We will not be liable for any damages anyone suffers because of using this information. While we believe all we write is correct, there may be errors. The contents of this site are provided without any expressed or implied warranty of fitness for any purpose. Use your judgement, and use at your own risk.