[JB] В "Програмистки бисери", бележитият афорист на компютърните науки Джон Бентли коментира наблюдението на Брукс така: "Ако планираш да пропилееш едно, ще пропилееш две". Той е почти напълно прав. Със своето наблюдение, Брукс, както впрочем и Бентли, не иска просто да каже, че трябва да очакваш, че първият ти опит ще бъде погрешен, а че обикновено е по-сполучливо да започнеш отначало с правилната идея, отколкото да се опитваш да оправиш един бълвоч.
[QR] Съществуват примери за успешна разработка с отворен код в базарен стил, предхождащи Интернет експлозията и несвързани с традиците на Unix и Интернет. Един такъв през 1990-1992 е разработката на инструмента за компресиране (предимно върху DOS машини) info-Zip. Друг е системата за обмен на съобщения RBBS (отново за DOS), която започна през 1983 и разви достатъчно силна общност, за да има сравнително редовни издания до момента (средата на 1999), въпреки огромните технически предимства на пощата и обмена на файлове по Интернет спрямо местните BBS-и. Докато info-Zip общността се осланяше до известна степен на Интернет пощата, разработчиците на RBBS успяха да установят една он-лайн общност върху RBBS, която е напълно независима от инфраструктурата на TCP/IP.
[JH] Джон Хеслър предложи интересно обяснение на факта, че дублирането на усилията не изглежда да е нетна загуба при разработката на отворен код. Той предложи нещо, което ще нарека "Закон на Хеслър": цената на дублираната работа има тенденцията да нараства по-малко от квадратично спрямо големината на екипа -- т.е. по-бавно от допълнителното планиране и управление, необходимо за отстраняването им.
Това твърдение всъщност не противоречи на закона на Брукс. Може би общата допълнителна сложност и уязвимостта от грешки расте на квадрат от големината на екипа, но въпреки това цената на дублираната работа е особен случай и нараства по-бавно. Не е трудно да се намерят правдоподобни причини за това, като се започне с несъмнения факт, че е много по-лесно да се постигне съгласие по функционалните граници между кода на отделните разработчици, което ще предотврати дублиране на работата, отколкото да се предотвратят различните видове лошо непланирано взаимодействие в цялата система, които са в основата на повечето грешки.
Комбинацията от законите на Линус и Хеслър подсказва, че всъщност софтуерните проекти биват три вида според размера си. При малките проекти (бих казал такива с не повече от трима разработчици) не е необходима по-сложна структура на управление от тази да се избере водещ програмист. Над тях съществува някакъв среден диапазон, при който разходите на традиционното управление са относително ниски, така че предимствата му от избягването на дублирането на работа, проследяването на грешки и опитите да не се пропускат детайли всъщност се оказват положителни.
Над това обаче комбинацията от законите на Линус и Хеслър подсказва, че има едно ниво на големите проекти, в което разходите и проблемите на традиционното управление се увеличават много по-бързо, отколкото очакваните разходи от дублирането на работа. Не на последно място сред тези разходи е структурната неспособност да се използва "ефекта на многото очи", който (както вече видяхме) изглежда върши много по-добра работа от традиционното управление при подсигуряването да не се пропускат грешки и подробности. Така при големите проекти комбинацията от тези закони всъщност прави нетната полза от традиционното управление равна на нула.
[IN] Един проблем, свързан с това дали могат да се наченат проекти от нулата в базарен стил, се състои в това дали базарния стил може да поддържа наистина творческа работа. Някои твърдят, че тъй като липсва силно водачество, базарът може да се справи само с клонирането и усъвършенстването на идеи вече съществуващи в последната дума на инженерството, но не може да разработва нови. Това твърдение е може би най-известно от позорните документи Halloween, два обезпокоителни вътрешни меморандума на Microsoft, в които се говори за феномена на отворения код. В него авторите наричат Линусовата разработка на Unix-подобна операционна система "да гониш влака по перона", и изказват мнение, че "(веднъж щом проектът е достигнал последната дума на технологията) необходимото ниво на управление за преодоляване на нови бариери става огромно".
В този аргумент се съдържат сериозни фактологични грешки. Едната си проличава по-късно, когато авторите на Halloween сами забелязват, че "често [...] нови изследователски идеи се прилагат и са достъпни първо в Linux, преди да се включат в други платформи".
Ако четем "отворен код" вместо "Linux", ще видим, че този феномен съвсем не е нов. В исторически план общността на отворения код не е открила Emacs или World Wide Web или Интернет сама като гони влаковете по перона или като бъде масивно управлявана -- и понастоящем няма много откривателска работа, протичаща в общността на отворения код, която да подлежи на избор. Проектът GNOME (ако изберем един от многото) достатъчно усилено се движи по ръба на най-новите разработки в областта на графичните интерфейси и обектната технология, за да привлече вниманието на компютърната търговска преса, която е доста далеч от Linux обществото. Има хиляди други примери, както веднага би показало едно посещение във Freshmeat в който и да е ден.
Но има и една още по-фундаментална грешка в имплицитното допускане, че катедралният модел (или базарният, или който и да е друг вид управленческа структура) може благонадеждно да прави нововъведения. Това е безсмислица. Бандите не получават внезапни прозрения -- дори на доброволческите групи от базарни анархисти обикновено им липсва истинска оригиналност, а да не говорим за корпоративните комитети от хора със залог за оцеляване в някакво положение quo ante. Прозрението идва от личностите. Най-многото, което може да се надява някога да направи тяхната окръжаваща социална машинария, е да бъде отзивчива на внезапни прозрения -- да ги поддържа, възнаграждава и сурово да ги изпитва, вместо да ги мачка.
Някои ще определят това като романтично схващане, като връщане към остарелите стереотипи за самотния изобретател. Не е така -- аз не твърдя, че групите не могат да доразвиват внезапни прозрения, щом веднъж са се излюпили; и наистина, ние се учим от гледания отстрани процес, че такива групи разработчици са жизнено важни за получаването на висококачествени резултати. По-скоро посочвам, че разработката на всяка една такава група започва -- дори задължително се начева -- от една добра идея в нечия глава. Катедралите, базарите и другите социални структури могат да впрегнат тази мълния и да я усъвършенстват, но това не става по поръчка.
Следователно наистина основният проблем на иновацията (в софтуера, както и навсякъде другаде) е как да не я мачкаш; но дори още повече как да развиваш много хора, които на първо място да имат прозрения.
Би било абсурдно да предположим, че катедралният стил на разработка владее този трик, а ниските входни точки и плавността на процесите на базарния -- не. Ако беше необходим само един човек с добра идея, то тогава социалната среда, в която един човек може бързо да привлече за сътрудници стотици или хиляди други с тази си добра идея, ще трябва неминуемо да "от-изобретява" всяка от тях, в която човекът ще трябва да се занимава с политически продажби в йерархия, преди да може да работи по идеята си без да има опасност да го уволнят.
И наистина, ако погледнем историята на софтуерните нововъведения в организации, използващи катедралния модел, бързо ще открием, че това става твърде рядко. За нови идеи големите корпорации разчитат на университетски изследвания (оттук и опасенията на авторите на документите Halloween от способността на Linux по-бързо да развиват тези изследвания). Или пък купуват малки компании, изградени около нечий изобретателски мозък. В нито един от случаите изобретението не е присъщо на катедралната култура; наистина, много от вложените по този начин изобретения свършват тихо задушени под "масивното ниво на управлението", които авторите на документите Halloween така възхваляват.
Това обаче е негативна позиция. Читателят би ме разбрал по-добре от положителна такава. Като експеримент аз предлагам следното:
В деня, в който написах това, във Freshmeat имаше 22 обяви за нови издания, от които три изглеждаха, като че могат в някакво отношение да подтикнат напред технологията. За Freshmeat това беше слаб ден, но бих се учудил, ако някой читател съобщи за повече от три изобретения месечно в който и да е канал за затворен код.
[EGCS] Днес разполагаме с историята на проект, който в много аспекти може да ни послужи като по-показателна проверка на базарната предпоставка, отколкото fetchmail. Това е EGCS (Experimental GNU Compiler System), Експерименталната система от компилатори на GNU.
Този проект бе обявен в средата на август 1997, като съзнателен опит да се приложат идеите от ранната публична версия на "Катедралата и базарът". Основателите на проекта почувстваха, че разработката на GCC (Gnu C Compiler), C компилатора на GNU, е в застой. За около 20 месеца след това, GCC и EGCS продължиха като паралелни продукти -- и двата добивани от едно и също население от Интернет разработчици, и двата започнати от един и същ основен изходен код на GCC, и двата използващи съвсем едни и същи Unix инструменти и среда за разработка. Проектите се различаваха само по това, че EGCS съзнателно се опитваше да приложи базарната тактика, която описах по-горе. Докато GCC остана като една подобна на катедрала организация със затворена група от разработчици, която рядко пускаше нови версии.
Това дотолкова наподобяваше един контролиран експеримент, че едва ли някой би могъл изобщо да желае повече. И резултатите бяха вълнуващи. За няколко месеца, версиите на EGCS дръпнаха съществено напред във възможностите си -- по-добра оптимизация, по-добра поддръжка за FORTRAN и C++. Много хора откриха, че работните "снимки" на EGCS бяха по- надеждни от последната стабилна версия на GCC. Така основните Linux дистрибуции започнаха да се прехвърлят към EGCS.
През април 1999, Free Software Foundation (Фондацията за свободен софтуер, официалните спонсори на GCC) разпуснаха първоначалната работна група на GCC и официално връчиха контрола върху проекта на екипа, направляващ EGCS.
[SP] Разбира се, критиката на Кропоткин и Законът на Линус повдигат някои по-общи въпроси относно кибернетиката на социалните организации. Друга фолклорна теорема на софтуерното инженерство подсказва един от тях: Законът на Конуей, най-често гласящ: "Ако разполагате с четири групи, работещи върху един компилатор, ще получите четирипасов компилатор". Автентичното твърдение е било по-общо: "Организациите, чиито системи за дизайн са обречени да произвеждат дизайни, които са копия на структурите на общуване в тези организации." Можем да го дадем малко по-сбито като: "Намеренията определят резултатите", или дори като "Процесът става продукт".
Значи на всеки е ясно, че в общността на отворения код организационната форма и функция съвпадат на много нива. Мрежата е всичко и навсякъде -- не само Интернет, но самите работещи хора образуват разпределена, свободно свързана и равноправна мрежа, която дава сложно изобилие и се снижава много елегантно. И в двете мрежи, всеки възел е важен само доколкото останалите възли желаят да си сътрудничат с него.
Равноправният аспект е съществен за удивителната продуктивност на общността. Въпросът за отношенията на сила, който Кропоткин се опитва да посочи, е развит по-нататък от "Принципа SNAFU" [T-SNAFU]: "Истинска комуникация е възможна само между равни, защото подчинените по-систематично биват награждавани за това, че съобщават приятни лъжи на висшестоящите, вместо за това, че съобщават истината." Творческата работа в екип съвършено зависи от истинската комуникация и затуй е много сериозно спъвана от наличието на отношения на сила. Бивайки действително свободна от подобни отношения на сила, общността на отворения код ни учи на обратното -- колко ужасно много ни струват те във формата на грешки, в понижена продуктивност, и в пропуснати възможности.
По-нататък, принципът SNAFU предрича на авторитарните организации едно все по-задълбочаващо се прекъсване на връзката между онези, които взимат решения и реалността, като все повече и повече от входната информация за тези, които решават, клони към превръщане в приятна лъжа. Всеки може да види как се разиграва това в традиционното разработване на софтуер; за подчинените съществуват силни стимули да крият, пренебрегват, или омаловажават проблемите. Когато този процес стане продукт, софтуерът е бедствие.
[T-DILBERT] Повече информация за комиксите с Дилбърт има този адрес. (бел. прев.)
[T-SNAFU] По време на Втората световна война в армията на Съединените щати е използвана тази абревиатура, образувана от: "Situation Normal, All Fucked Up", което горе-долу значи: "Положението е нормално, всичко е преебано." или по-свободно звучи близко до "Спокойно, моряци, корабът потъва -- вода има за всички." За повече информация за SNAFU Principle, виж в жаргонния справочник. Уви, авторът не е гледал българския филм "Кит", където сюжетът е изцяло построен върху подобен принцип. (бел. прев.)