Към текста

Метаданни

Данни

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

Информация

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

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

История

  1. — Добавяне

Необходими предварителни условия за базарния стил

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

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

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

В този аргумент се съдържат сериозни фактологични грешки. Едната си проличава по-късно, когато авторите на Halloween сами забелязват, че „често […] нови изследователски идеи се прилагат и са достъпни първо в Линукс, преди да се включат в други платформи“.

Ако четем „отворен код“ вместо „Линукс“, ще видим, че този феномен съвсем не е нов. В исторически план общността на отворения код не е открила Emacs или World Wide Web или Интернет сама като гони влаковете по перона или като бъде масивно управлявана — и понастоящем няма много откривателска работа, протичаща в общността на отворения код, която да подлежи на избор. Проектът GNOME (ако изберем един от многото) достатъчно усилено се движи по ръба на най-новите разработки в областта на графичните интерфейси и обектната технология, за да привлече вниманието на компютърната търговска преса, която е доста далеч от Линукс обществото. Има хиляди други примери, както веднага би показало едно посещение във Freshmeat, в който и да е ден.

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

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

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

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

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

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

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

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

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

4. 30 дни по-късно сумирайте и сравнете двете числа.

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

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

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

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

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

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

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

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

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

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

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

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