Истина е, че най-добрите програми започват като лични разрешения на всекидневните проблеми на автора, а се разпространяват, понеже се оказва, че проблемът е типичен за широк кръг потребители. Това ни връща към смисъла на правило 1, може би по-добре преформулирано:
18. Ако искаш да разрешиш интересен проблем, първо започни да търсиш проблем, който е интересен за самия теб.
Тъй беше с Карл Харис и наследения popclient, тъй беше с мен и fetchmail. Но това е разбрано много отдавна. Интересният въпрос, въпросът, върху който историите на Linux и fetchmail ни принуждават да се концентрираме, е следващият етап -- развитието на софтуера при наличието на голяма и активна общност от потребители и съразработчици.
В "Митичният човеко-месец" Фред Брукс е забелязал, че програмисткото време не нараства лесно и гъвкаво -- добавянето на програмисти в напреднал софтуерен проект води до забавянето му. Той твърди, че цената на сложността и на комуникацията в един проект се покачва квадратично с броя на разработчиците, докато количеството свършена работа се покачва едва линейно. От тогава насетне това твърдение става известно като "Закон на Брукс" и се възприема като очевидна истина. Но ако всичко се изчерпва със Закона на Брукс, Linux би бил невъзможен.
В класическата си книга "Психология на компютърното програмиране", Джералд Уейнбърг показва нещо, което (със закъснение) можем да привидим като живо опровержение на Брукс. При своето разглеждане на "програмирането без его", Уейнбърг е наблюдавал, че в предприятията, където програмистите не са ревниви спрямо кода си и окуражават другите хора да търсят вътре грешки и възможности за подобрение, подобрението става драматично по-бързо, отколкото където и да било другаде.
Анализът на Уейнбърг не бива приет по подобаващ начин, може би заради избраната от него терминология -- някой би се усмихнал на идеята хакерите в Интернет да се характеризират като "без его". Но аз мисля, че днес неговият аргумент изглежда по-силен от всякога.
Историята на Unix би трябвало да ни е подготвила за това, което научихме от Linux (и което аз експериментално проверих в по-малък мащаб, съзнателно копирайки методите на Линус [EGCS]). А то е, че докато кодирането остава дейност, която се извършва главно в уединение, наистина великите разработки идват от впрягането на умствените способности и вниманието на цели общности. Разработчикът, който използва само своя собствен акъл в един затворен проект, ще изостане зад разработчика, който умее да създаде отворен, еволюционен контекст, в който чрез обратна връзка се изследва пространството на дизайна, дарява се код, посочват се грешки, и други подобрения идват от стотици (може би дори хиляди) хора.
Но няколко фактора попречиха на традиционния Unix свят да развие този подход докрай. Един от тях беше наличието на юридически ограничения на разните лицензи, търговски тайни и комерсиални интереси. Друг (както се оказа в последствие) се състоеше в това, че Интернет все още не беше достатъчно развит.
Във времето преди евтиния Интернет съществуваха няколко географски компактни общности, където културата окуражаваше програмирането "без его", в смисъла на Уейнбърг. Там един разработчик можеше лесно да привлече голям брой кадърни кибици и съразработчици. Лабораториите "Бел", Лабораторията по изкуствен интелект към Масачузетския Технологичен Институт, Калифорнийският Университет в Бъркли -- всички те се превърнаха в дом на иновациите, който днес е легендарен и все още плодотворен.
Linux беше първият проект за съзнателно и успешно използване на целия свят като запас от таланти. Не мисля, че е случайност това, че периодът на бременност на Linux съвпадна с раждането на World Wide Web. И че Linux излезе от детството си през същия период на 1993-1994, който бе свидетел на летящия старт на ISP индустрията и бума на всеобщия интерес към Интернет. Линус беше първият човек, който се научи как да играе по новите правила, които донесе широко разпространеният Интернет.
Докато евтиният Интернет беше необходимо условие за създаването на модела на Linux, той не беше сам по себе си достатъчно условие. Друг жизненоважен фактор беше развитието на стил на водачество и множество обичаи за сътрудничество, които могат да позволят на разработчиците да привличат съразработчици и да извличат максималното от възможностите на средата.
Но какъв е този стил на водачество и какво представляват тези обичаи? Те не могат да бъдат основани на властови отношения -- а дори и да можеха, водачеството чрез принуда нямаше да доведе до резултатите, които наблюдаваме. Уейнбърг цитира автобиографията на руския анархист от 19-ти век Пьотр Алексеевич Кропоткин "Спомените на един революционер", която е в сила за нашия въпрос:
"Като отгледан в семейство на владетел на крепостни селяни, аз влязох в действителния живот подобно на всички млади хора от моето време, твърде убеден в необходимостта от командване, заповядване, хокане, наказване и прочие. Но когато в началото трябваше да управлявам сериозни предприятия и да си имам работа със [свободни] хора, когато всяка грешка можеше изведнъж да доведе до тежки последици, тогава започнах да разбирам разликата между действането на принципа на командването и дисциплината и действането на принципа на общото съгласие. Първото работи чудесно при един военен парад, но не струва нищо там, където е замесен истинският живот, където целта може да бъде постигната само чрез усилието на голям брой събиращи се воли."
"Усилието на голям брой събиращи се воли" е точно това, което изисква проект като Linux. И "принципът на командването" действително е неприложим между доброволците в този анархистки рай, който наричаме Интернет. Хакерите, желаещи да ръководят сътруднически проекти, ако искат ефикасно да работят и да се съревновават, трябва да се научат да вербуват и стимулират заинтересовани общности в стила, неясно формулиран в "принципа на съгласието" на Кропоткин. Трябва да се научат да използват Закона на Линус. [SP]
По-рано аз се позовах на "Делфийския ефект" като възможно обяснение на Закона на Линус. Но неизбежно ми идват наум и по-силни аналогии с адаптивните системи в биологията и икономиката. В много отношения, поведението на Linux света е подобно на свободен пазар или екологична система, където сбор от себелюбиви агенти се опитват да увеличат ползата си до най-голямата възможна степен, в хода на което се получава самокоригиращ се спонтанен ред с по-голяма сложност и ефикасност, отколкото би могло да бъде постигнато от каквото и да било централно планиране. Тъкмо тук трябва да се търси "принципа на съгласието".
"Полезната функция", увеличена до най-голямата възможна степен от Linux хакерите, не е класически икономическа, а е невещественото удовлетворение на собственото им его и репутация сред останалите хакери. (Някой може да нарече мотивацията им "алтруистична", но така не се обръща внимание на факта, че алтруизмът сам по себе си е форма на задоволяване на егото на алтруиста). В действителност, доброволческите култури, които действат по този начин, не са необикновени. Друга такава, в която дълго време съм участвал, е общността на феновете на научната фантастика, където, за разлика от Хакерландия, "гъделът" (увеличаването на нечия репутация всред другите фенове) се признава като основна движеща сила на доброволческата дейност.
Линус показа едно проницателно схващане на "принципа на споделено съгласие" на Кропоткин, успешно поставяйки се като портиер на проект, в който разработката се извършва главно от други хора, подхранвайки интереса към проекта, докато той придобие своя самостоятелност. Този квази-икономически поглед върху Linux света ни позволява да разберем как се прилага това съгласие.
Можем да разглеждаме метода на Линус като начин за създаване на ефикасен пазар в "гъдела" -- себичността на отделните хакери да се свърже колкото се може по-здраво в реализацията на трудни задачи, които могат да бъдат осъществени само при постоянно сътрудничество. С проекта fetchmail аз показах (макар и в по-малък мащаб), че неговите методи могат да бъдат повтаряни, при което се получават добри резултати. Аз дори може би го сторих малко по-съзнателно и систематично от него.
Много хора (особено онези, които политически се съмняват в свободните пазари) биха очаквали, че една култура от самоорганизиращи се егоисти ще е разпокъсана, разделена, прахосническа, потайна и враждебна. Но това очакване е напълно опровергано (да дадем само един пример) от смайващото разнообразие, качество и задълбоченост на документацията за Linux. Свещена истина е, че програмистите мразят писането на документация. Но как тъй Linux хакерите създават толкова много такава? Очевидно, свободният пазар на гъдел в Linux работи по-добре, за да доведе до добродетелно, насочено в друга посока поведение, отколкото при здраво финансираните отдели за документация на комерсиалните производители на софтуер.
И двата проекта -- fetchmail и ядрото Linux -- показват, че чрез прилично възнаграждаване на егото на много хакери, един силен разработчик/координатор може да използва Интернет, за да улови ползите от притежаването на много съразработчици, без проектът да се сгромоляса в пълен миш-маш. И тъй, срещу Закона на Брукс предлагам следното:
19. Когато на координатора на разработката е предоставена среда, поне толкова добра колкото Интернет, и той знае как да ръководи без принуда, тогава повече глави са неизбежно по-добри от една.
Мисля, че бъдещето на софтуера с отворен код все повече ще принадлежи на хора, които знаят как да играят играта на Линус, хора, които изоставят катедралата и се присъединяват към базара. Това не означава, че индивидуалната проницателност и надареност вече няма да са от значение. Напротив, мисля, че острието на софтуера с отворен код ще принадлежи на хора, които започват от индивидуална проницателност и надареност, а после я усилват чрез сполучливото изграждане на заинтересувани доброволчески общности.
И може би не само бъдещето на софтуера с отворен код. Няма разработчик на затворен код, който да се сравни със запаса от таланти, който общността на Linux може да пусне в действие върху дадена задача. Колцина изобщо биха си позволили да наемат повече от двеста (1999 -- шестотин, 2000 -- осемстотин) души, които са допринесли с нещо към fetchmail.
В крайна сметка, може би културата на отворения код ще триумфира не защото сътрудничеството е морално правилно или защото "прикриването" на софтуера е морално неправилно (да приемем, че вярвате в последното -- нещо, с което нито Линус, нито аз сме съгласни), а просто защото светът на затворения код не може да спечели революционната надпревара във въоръжаването с общностите на отворения код, които могат да съсредоточат значително повече квалифицирано време върху даден проблем.