Към текста

Метаданни

Данни

Оригинално заглавие
The Cathedral and the Bazaar, (Пълни авторски права)
Превод от
, (Пълни авторски права)
Форма
Есе
Жанр
  • Няма
Характеристика
  • Няма
Оценка
5,5 (× 2 гласа)

Информация

Корекция и форматиране
Юлиян Йорданов (2014)
Източник
catb-bg.sourceforge.net

Сътрудници на превода: Антон Зиновиев, Христо Божинов

История

  1. — Добавяне

Социалният контекст на софтуера с отворен код

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

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

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

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

В класическата си книга „Психология на компютърното програмиране“, Джералд Уейнбърг показва нещо, което (със закъснение) можем да привидим като живо опровержение на Брукс. При своето разглеждане на „програмирането без его“, Уейнбърг е наблюдавал, че в предприятията, където програмистите не са ревниви спрямо кода си и окуражават другите хора да търсят вътре грешки и възможности за подобрение, подобрението става драматично по-бързо, отколкото където и да било другаде. Анализът на Уейнбърг не бива приет по подобаващ начин, може би заради избраната от него терминология — някой би се усмихнал на идеята хакерите в Интернет да се характеризират като „без его“. Но аз мисля, че днес неговият аргумент изглежда по-силен от всякога.

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

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

Във времето преди евтиния Интернет съществуваха няколко географски компактни общности, където културата окуражаваше програмирането „без его“, в смисъла на Уейнбърг. Там един разработчик можеше лесно да привлече голям брой кадърни кибици и съразработчици. Лабораториите „Бел“, Лабораторията по изкуствен интелект към Масачузетския Технологичен Институт, Калифорнийският Университет в Бъркли — всички те се превърнаха в дом на иновациите, който днес е легендарен и все още плодотворен.

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

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

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

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

„Усилието на голям брой събиращи се воли“ е точно това, което изисква проект като Линукс. И „принципът на командването“ действително е неприложим между доброволците в този анархистки рай, който наричаме Интернет. Хакерите, желаещи да ръководят сътруднически проекти, ако искат ефикасно да работят и да се съревновават, трябва да се научат да вербуват и стимулират заинтересовани общности в стила, неясно формулиран в „принципа на съгласието“ на Кропоткин. Трябва да се научат да използват Закона на Линус[2].

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

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

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

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

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

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

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

И може би не само бъдещето на софтуера с отворен код. Няма разработчик на затворен код, който да се сравни със запаса от таланти, който общността на Линукс може да пусне в действие върху дадена задача. Колцина изобщо биха си позволили да наемат повече от двеста (1999 — шестотин, 2000 — осемстотин) души, които са допринесли с нещо към fetchmail.

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

Бележки

[1] Днес разполагаме с историята на проект, който в много аспекти може да ни послужи като по-показателна проверка на базарната предпоставка, отколкото 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. Така основните Линукс дистрибуции започнаха да се прехвърлят към EGCS.

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

[2] Разбира се, критиката на Кропоткин и Законът на Линус повдигат някои по-общи въпроси относно кибернетиката на социалните организации. Друга фолклорна теорема на софтуерното инженерство подсказва един от тях: Законът на Конуей, най-често гласящ: „Ако разполагате с четири групи, работещи върху един компилатор, ще получите четирипасов компилатор“. Автентичното твърдение е било по-общо: „Организациите, чиито системи за дизайн са обречени да произвеждат дизайни, които са копия на структурите на общуване в тези организации.“ Можем да го дадем малко по-сбито като: „Намеренията определят резултатите“, или дори като „Процесът става продукт“.

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

Равноправният аспект е съществен за удивителната продуктивност на общността. Въпросът за отношенията на сила, който Кропоткин се опитва да посочи, е развит по-нататък от „Принципа SNAFU“[3]: „Истинска комуникация е възможна само между равни, защото подчинените по-систематично биват награждавани за това, че съобщават приятни лъжи на висшестоящите, вместо за това, че съобщават истината.“ Творческата работа в екип съвършено зависи от истинската комуникация и затуй е много сериозно спъвана от наличието на отношения на сила. Бивайки действително свободна от подобни отношения на сила, общността на отворения код ни учи на обратното — колко ужасно много ни струват те във формата на грешки, в понижена продуктивност, и в пропуснати възможности.

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

[3] По време на Втората световна война в армията на Съединените щати е използвана тази абревиатура, образувана от: „Situation Normal, All Fucked Up“, което горе-долу значи: „Положението е нормално, всичко е преебано.“ или по-свободно звучи близко до „Спокойно, моряци, корабът потъва — вода има за всички.“ За повече информация за SNAFU Principle, виж в жаргонния справочник. Уви, авторът не е гледал българския филм „Кит“, където сюжетът е изцяло построен върху подобен принцип. — Бел.прев.