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

• Увод
• Катедралата и базарът
• Пощата трябва да се достави
• Важно е да има потребители
• Пускайте версии рано и често
• Кога розата не е роза?
• Popclient става Fetchmail
• Fetchmail пораства
• Още няколко урока от Fetchmail
• Необходими предпоставки за базарния стил
• Социален контекст на отворения софтуер
• За управлението и линията Мажино
• Благодарности
• Други материали
• Епилог: Netscape прегръща базара
• Бележки
• Версия и история на промените

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

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

Със сигурност не и аз. По времето, когато Linux доплува в обхвата ми в началото на 1993 година, вече бях участвал в разработката на Unix и на отворени продукти в продължение на десет години. Бях един от първите, които писаха за GNU в средата на 80-те. Бях пуснал доста голямо количество отворен софтуер в мрежата, бях разработил или участвал в разработката на няколко програми (nethack, VC и GUD режимите на Emacs, xlife и други), които все още широко се използват днес. Мислех, че знам как се прави.

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

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

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

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

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

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

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

Съответно бях свикнал с мигновената електронна поща в Интернет. Поради най-различни причини ми беше трудно да накарам SLIP да работи между моята машина вкъщи (snark.thyrsus.com) и CCIL. Когато най-накрая успях, намерих необходимостта постоянно да се telnet-вам до locke, за да си проверя пощата, за доста изнервяща. Исках пощата ми да пристига на snark, така че да получавам сигнал, когато е дошла и да мога да я обработвам с локалните си инструменти. Препращането със sendmail не ставаше, защото домашната ми машина не винаги е свързана към мрежата и няма статичен IP адрес. Трябваше ми програма, която да използва SLIP и да изтегля пощата ми на моята машина. Знаех, че има такива програми и че повечето използват прост протокол, наречен POP (Post Office Protocol). Освен това операционната система на 1оске – BSD/OS – естествено включваше POP3 сървър.

Трябваше ми POP3 клиент. Потърсих в мрежата и намерих един. Всъщност, намерих три или четири. Използвах pop-perl за известно време, но на него му липсваше една според мен очевидна възможност – да се променят адресите в изтеглената поща така, че отговорите да отиват на правилното място.

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

Очевидно компютърът трябваше да прави тези работи. Обаче никой от съществуващите РОР клиенти не знаеше как! И това ни води до първия урок:

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

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

И тъй, дали се впуснах веднага в трескаво кодиране на чисто нов POP3 клиент, който да се мери със съществуващите? Естествено, че не! Прегледах внимателно програмите, които имах под ръка и се запитах "коя е най-близо до това, което искам?" Защото

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, pinp, pop-perl, popc, popmail и upop. Първо се спрях на fetchpop от Сюнг-Хонг О. Добавих към него възможността за промяна на адресите в съобщенията, както и различни други подобрения, които авторът вгради във версия 1.9.

Няколко седмици по-късно обаче се натъкнах на кода за popclient от Карл Харис и се оказах изправен пред един проблем. Макар fetchpop да имаше някои добри и оригинални идеи (например неговия режим на "демон"), той можеше да се справя само с POP3 и беше доста аматьорски написан (по това време Сюнг-Хонг беше умен, но неопитен програмист, и това си личеше в кода му). Програмата на Харис беше написана по-добре, доста професионално и стабилно, но й липсваха някои важни и доста хитри за реализиране възможности на fetchpop (включително тези, които добавих аз).

Дали да се спра на fetchpop или да мина на popclient? Ако се прехвърлех, щях да изхвърля кода, който вече бях написал, но пък щях да имам по-добра основа за разработване.

Практически мотив да мина на popclient: беше поддръжката на множество протоколи. POP3 се използва най-често, но не е единственият. Fetchpop и другите конкуренти не се справяха с POP2, RPOP или APOP, а пък аз вече имах смътни мисли за добавяне на IMAP (www.imap.org, Internet Message Access Protocol, най-новият и най-мощен email протокол) просто заради спорта.

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

3. "Планирай да изхвърлиш нещо – тъй или иначе ще се наложи." (Фред Брукс, "The Mythical Man-Month". глава 11).

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

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

След като изпратих първите си допълнения към popclient: на Карл Харис на 25 юни 1996, открих, че той всъщност е загубил интерес към програмата известно време преди това. Кодът беше малко занемарен, тук-там стърчаха грешки. Трябваше да направя много промени и ние бързо се съгласихме, че е логично аз да поема програмата.

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

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

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

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

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

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

И тъй, аз поех popclient. Нещо повече, аз поех и неговите потребители. Потребителите са много хубави неща. не само защото демонстрират че си полезен и правиш нещо добро. Когато се насърчават подходящо, те могат да станат и разработчици.

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

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

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

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

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

Всъщност моят най-голям успех преди fetchmail беше може би режимът VC за Emacs, съвместна разработка по електронната поща в стил на Linux с трима други програмисти, само един от които (Ричард Столман, авторът на Emacs и основател на FSF – (http://www.fsf.org) съм срещал до ден-днешен. Това беше потребителски интерфейс за достъп до SCCS, RCS, а по-късно и CVS от средата на Emacs. който предлагаше лесен контрол на операциите с различните версии на изходния код. Той се разви от малка, грубо написана от някой друг програмка за scss.el. И разработката на VC успя, защото, за разлика от самия Emacs. Кодът на Lisp може да минава през цикъла пускане-тестване-подобряване много бързо.
 

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

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

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

Но една година по-късно, когато Linux стана широко известна, беше ясно, че с нея става нещо различно и много по-приемливо. Отворената стратегия за разработка на Линус беше точно противоположна на катедралния стил. Архивите на Sunsite (сега Metalab – http://metalab.unc.edu) и tsx-11 набъбваха стремително, нароиха се най-различни дистрибуции. И всичко това се предизвикавше от нечуваната честота на новите версии на основната операционна система.

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

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

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

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

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

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

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

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

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

Казано по друг начин, "Ако гледат достатъчно очи, всички грешки са очевидни." Наричам това "Закон на Линус".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9. Комбинацията от добра структура на данните и тъпичък код работи по-добре от обратното.

Брукс, глава 9: "Ако ми покажеш кода си без структурата на данните, няма да разбера нищо. Ако ми покажеш данните си, обикновено няма да има нужда от кода; той ще бъде очевиден."

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

В този момент (началото на септември 1996-а, около шест седмици след като започнах от нулата) се замислих дали да не сменя името – все пак, вече нямах само POP клиент. От друга страна се колебаех, защото в програмата нямаше нищо съществено ново. Моята версия на popclient: трябваше тепърва да развие собствена индивидуалност.

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

1. Пусках нови версии отрано и начесто (почти никога по-рядко от всеки десет дни, а в периодите на усилена разработка – по веднъж на ден).

2. Разширявах списъка на бета-тестерите с всички, които се заинтересуваха от fetchmail.

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

4. Вслушвах се в бета-тестерите си, питах ги, когато трябваше да взема важни решения относно дизайна на програмата и ги хвалех, когато изпращаха patch-ове и коментари.

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

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

Една интересна мярка за успеха на fetchmail е дължината на списъка с бета-тестери, "фенове" на fetchmail. По времето, когато писах тази статия, той включваше 249 души и всяка седмица се включваха по двама-трима нови.

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

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

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

Когато се замислих за препращане на съобщенията към SMTP, разбрах, че popclient се опитва да прави твърде много неща. Беше проектиран да бъде както програма за транспортиране на поща (mail transport agent, MTA), така и програма за локална обработка на пощата (local delivery agent, LDA). Ако използвах препращане към SMTP, можех да се отърва от цялата работа с MDA и да направя програмата само MTA, като подавам пощата на други програми за локална обработка, точно както sendmail.

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

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

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

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

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

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

Има обаче още два основни урока, които са общи за всякакъв вид начинания.

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

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

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

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

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

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

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

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

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

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

13. "Съвършенство (в проектирането) не се постига, когато няма какво да се добави, а когато няма какво повече да се махне."

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

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

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

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

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

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

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

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

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

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

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

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

Неочакваната полза в случая се оказа възможността за поддръжка на mailing list като самия списък и alias-файловете се пазят върху клиентската страна на SLIP/PPP връзката. Това означава, че някой с лична машина, свързана към ISP, може да поддържа mailing list без да му се налага непрекъснато да се обръща към alias-файловете на доставчика.

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

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

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

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

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

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

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

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

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

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

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

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

16. Ако правите език, който далеч не е еквивалентен на машина на Тюринг, може да си позволите разточителство в синтаксиса му.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Linux беше първият проект, който направи сериозен и успешен опит да използва целия свят като източник на талант. Не мисля, че е съвпадение факта. че раждането на Linux стана по времето, когато се роди World Wide Web, и че Linux напусна детството си в същия период през 1993-1994, когато се разви ISP индустрията и интересът към Интернет нарасна експлозивно. Линус беше първият човек, който се научи как да играе по новите правила, които вездесъщата Интернет направи възможни.

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

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

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

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

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

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

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

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

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

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

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

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

А може би и не само бъдещето на отворения код. Никой затворен производител на софтуер не може да се сравнява с таланта, който общността на Linux може да отдаде за решаването на даден проблем. Много малко могат дори да си позволят да наемат повече от 200-те (а през 1999-та и 600) души, които допринесоха за разработката на fetchmail.

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

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

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

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

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

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

Това подсказва, че има причина да се оспорват предимствата на конвенционално управляваната разработка на софтуер, която причина е независима от останалите аргументи на базарния срещу катедралния стил. Ако е възможно GNU Emacs да запази постоянна архитектура за повече от петнайсет години, или пък операционна система като Linux да прави същото за повече от осем години на бързо сменящи се хардуер и платформени технологии, и ако (какъвто наистина е случаят) има много отворени проекти с добра архитектура, просъществували повече от пет години – тогава можем да се запитаме каква ни е ползата от огромните трудности при конвенционалната разработка на софтуер, ако изобщо има някаква полза.

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

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

Тогава каква е ползата от тъй наречения мениджмънт?

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

1. Да дефинира целите и да държи всички ориентирани в една и съща посока.

2. Да наблюдава внимателно разработката и да се увери, че няма да се пропуснат критични подробности.

3. Да мотивира хората да вършат скучна, но необходима черна работа.

4. Да организира нещата така, че да се постигне максимална производителност.

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

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

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

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

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

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

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

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

Обикновено този отговор върви заедно с твърдението, че на отворени проекти може да се разчита само, ако трябва да се върши привлекателна и интересна работа; всичко друго би останало настрана (или недоправено), освен ако не се изстиска от парично мотивирани пионки, с мениджъри, размахващи камшик над тях. Психологичните и социалните причини, които ме карат да се отнасям скептично към това твърдение, съм изложил в "Homesteading the Noosphere". За настоящите ни цели обаче, мисля че е по-интересно да видим какви биха били следствията, ако го приемем за вярно.

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

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

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

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

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

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

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

Тогава нашият отговор към традиционния мениджър на софтуерни разработки е прост – ако отворената общност наистина подценява ползата от конвенционален мениджмънт, защо толкова много от вас показват презрение към работата си?

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

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

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

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

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

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

Цитирах няколко откъса от класическата книга на Фредерик П. Брукс "Митичният човекомесец" (Frederick P. Brooks, 'The Mythical Man-Month"), защото в много отношения неговите прозрения тепърва ще се подобряват. Сърдечно препоръчвам юбилейното издание на Addison-Wesley(ISBN 0-201-83595-9), което включва и неговото съчинение "Без сребърен куршум" (No Silver Bullet) от 1996 година.

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

"Психология на компютърното програмиране" на Джералд М. Уайнбърг (Gerald M. Weinberg, "The Psycology of Computer Programming", New York, Van Nostrand Reinhold 1971) въвежда доста неудачно формулираната концепция за "самоотвержено програмиране". Макар той да не първият човек, осъзнал безполезността на "принципа на командване", вероятно той е първият, който свързва този въпрос с разработката на софтуер.

Ричард П. Гейбриъл, който разглежда Unix културата отпреди времето на Linux, с нежелание признава превъзходството на примитивен базарен модел в своето съчинение "Lisp: добри новини, лоши новини и как да спечелим много" (Lisp: Good News, Bad News And How to Win Big) от 1989 година. Макар да е остаряло в някои отношения, това есе все още се радва на популярност сред много почитатели на Lisp (включително и мен). Един мой кореспондент ми напомни, че секцията, озаглавена "По-лошото е на добре" изглежда почти като предсказание за Linix. Този документ е достъпен по WWW на адрес http://www.naggum.no/worse-is-better.html.

"Peopleware: Продуктивни проекти и екипи" на Де Марко и Листер (De Marco and Lister, " Peopleware: Productive Projects and Teams", New York, Dorset House, 1987, ISBN 0-932633-05-6) е недооценено бижу и бях доволен, че Фред Брукс го цитира в ретроспекцията си. Макар малка част от това, което пише вътре, да е директно приложимо към Linux или отворения код, прозренията на авторите за условията, необходими за творческа работа, са особено ясни и полезни за всеки, който се опитва да пренесе част от предимствата на базарния стил в комерсиален контекст.

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

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

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

Ерик Хан, изпълнителен вицепрезидент, и главен технологичен директор на Netscape, ми изпрати малко след това писмо, в което пишеше: "от страна на всички в Netscape бих искал първо да ти благодаря, че ни помогна да стигнем до тук. Твоят начин на мислене и твоите статии бяха основният източник на вдъхновение, за да вземем нашето решение."

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

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

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

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

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

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

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

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

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

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

[JB] В "Програмистки бисери" известният компютърен афорист Джон Бентли коментира забележката на Брукс по следния начин "Ако мислите да изхвърлите нещо, ще изхвърлите две." Почти със сигурност е прав. Смисълът на забележката на Брукс, както и на Бентли, не е просто, че би трябвало да се очаква първият опит да е грешен, а че започването наново с правилната идея обикновено е по-ефективно от опита да се спаси една каша.

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

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

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

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

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

[IN] Един въпрос, свързан с това дали един проект може да започне от нулата в базарен стил, е дали базарният стил може да подържа наистина творческа работа. Някои твърдят, че при липсата на силно ръководство, базарният стил може да се справи само с клонирането и подобряването на идеи, които вече са известни и използвани, но не е способен да развие нови. Този аргумент е може би най-известно формулиран в документите от Хелоуийн (http://www.opensource.org/halloween/), два смущаващи вътрешни меморандума на Microsoft: за отвореното разработване. Авторите сравняват разработката на Linux с непрекъсната гонитба, защото "(след като един проект се е изравнил с най-новите разработки в областта), нивото на управление, необходимо за постигането на нови хоризонти, става огромно."

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

Ако заместим "Linux" с "отворен код", ще видим, че това далеч не е ново явление. Исторически погледнато, отворената общност не е измислила Emacs или Word wide Web или самата Интернет като е подражавала на други или като е имала солидно ръководство. А понастоящем има толкова много нови идеи, разработвани под формата на отворен код, че човек да се чуди кое да избере. Проектът GNOME (да вземем един от многото за пример) разширява границите на понятието "графичен интерфейс" и има достатъчно солидна обектноориентирана технология, за да привлече значително внимание в пресата извън общността на Linux. Други примери има със шепи, както би показало едно посещение на Freshmeat (http://freshmeat.net) в който и да е момент.

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

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

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

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

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

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

1. Изберете си критерии за оригиналност, който смятате, че ще можете да прилагате обективно. Ако дефиницията ви е "като го видя, ще го позная" това не е проблем за целите на настоящия тест.

2. Изберете си някоя операционна система със затворен код, която е конкурент на Linux, както и най-добрият източник на новини за текущата работа по нея.

3. Наблюдавайте този. код и Freshmeat! в продължение на един месец. Всеки ден бройте съобщенията във Freshmeat, които според вас са "оригинална" работа. Приложете същата дефиниция на "оригинален" към съобщенията за другата операционна система и ги пребройте.

4. След трийсет дни съберете общите суми.

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

[EGCS] Вече имаме проект, който по няколко начина може да се окаже по-добър тест на базарната практика отколкото fetchmail. Това е EGCS (http://egcs.sygnus.com/). Experimental GNU Compiler System – експерименталният компилатор на GNU.

Проектът беше обявен в средата на август 1997 като съзнателен опит да се приложат идеите от ранните публични версии на "Катедралата и базарът". Основателите на проекта чувстваха, че разработката на GCC, C-компилаторът на GNU, е в застой. За около двайсет месеца след това GCC и EGCS продължиха като паралелни продукти – и двата черпеха от една и съща база разработчици по Интернет, и двата започваха от изходните кодове на GCC, и двата използваха до голяма степен едни и същи Unux инструменти и среда за разработка. Проектите се различаваха само това. че GCC запази по-катедрална организация със затворена група разработчици и не толкова чести нови версии.

Това беше един контролиран експеримент, доколкото изобщо е възможно, и резултатите бяха драматични. Само за няколко месеца версиите на EGCC бяха напреднали доста по отношение на характеристики – по-добра оптимизация, по-добра поддръжка на Фортран и C++. Много хора намериха EGCC за по-надежден от последните стабилни версии на GCC, и основни Linux дистрибуции започнаха да преминават към EGCC.

През април 1999 Free Software Foundation (официалните спонсори на GCC) разпуснаха първоначалната група по разработката на GCC и официално предадоха проекта на екипа, отговарящ за EGCC.

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

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

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

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

$Id: cathedral-bazaar.sgml, v 1.46 1999/08/08 02:21:32 esr Exp $

Изнесох версия 1.16 на Конгреса на Linux, 21 май 1997.

Добавих библиографията на 7 юли 1997 във версия 1.20.

Добавих анекдота за конференцията на Perl на 18 ноември 1997 във версия 1.27.

Промених "безплатен софтуер" на "отворен код" на 9 февруари 1998 във версия 1.29.

Добавих "Епилог: Netscape прегръща базара" на 10 февруари 1998 във версия 1.31.

Махнах графиката на Пол Егърт за GPL срещу базара в отговор на убедителни аргументи от RMS, на 28 юли 1998.

Добавих корекция на Брукс, базирана на документите Хелоуийн, на 20 ноември 1998 във версия 1.40.

Добавих секцията "За управлението и линията Мажино", някои размисли за ползата от базарния стил по отношение на програмната архитектура, и значително подобрих епилога във версия 1.44, в края на юли 1999.

Добавих бележките за принципа на Snafu, (пред) историческите примери за базарни разработки, и за оригиналността при базарния стил във версия 1.45 на 8 август 1999.

Другите ревизии включват дребни редакции и поправки на текста.