Първоначалният вариант на "Катедралата и базарът" завършваше с мечтата, описана по-горе -- за щастливите орди програмисти/анархисти, съревноваващи се и надвиващи йерархичния свят на традиционния затворен софтуер.
Мнозина скептици обаче не бяха убедени; и въпросите, които те повдигнаха, заслужават съответния ангажимент. Повечето от възраженията срещу базарната теза се свеждат до твърдението, че неговите защитници подценяват ефекта от производителността и мащабируемостта на конвенционалното управление.
Традиционно-настроените координатори на софтуерни проекти често възразяват, че случайността, с която се формират, променят и разпускат групите на проектите в света на отворения код, значително обезсилва очевидното преимущество, което общността на отворения код има като брой хора в сравнение с който и да е разработчик на затворен код. Според техни наблюдения в разработката на софтуер единствените неща, които имат значение, са постоянната работа, и степента, до която клиентите могат да очакват да продължат вложенията си, а не колко души са хвърлили по едно кокалче в гърнето, и са го оставили да къкри.
В този аргумент безспорно има нещо вярно; всъщност във "Вълшебнит котел" аз развих идеята, че ключът към икономиката на софтуерното производство се корени в очакваната стойност на бъдещите услуги.
Тук обаче има и един голям скрит проблем -- приема се по подразбиране, че общността на отворения код не може да осигури такава продължителна работа. Всъщност има проекти с отворен код, които доста дълго продължават да следват съгласувано целите си, и да имат ефективни общности от разработчици без стимулиращите структури или институционални авторитети, които конвенционалното управление счита за основни. Най-добър и назидателен пример за това е разработката на GNU Emacs; той е концентрирал усилията на стотици сътрудници за повече от 15 години в единно архитектурно виждане, въпреки голямото текучество и фактът, че само един човек (авторът му) продължава да е активен през цялото това време. Никой (текстов) редактор не е достигал този рекорд по дълголетие.
Това ни дава причина да се запитаме за предимствата на конвенционално управляваната разработка, които са независими от останалите аргументи в спора на катедралния модел срещу базарния. Ако за GNU Emacs е възможно да изразява съдържателно архитектурно виждане в един период от 15 години, или за една операционна система като Linux да направи същото за осем години, в които технологиите на хардуера и платформите се променят изключително бързо; и ако (какъвто наистина е случаят) има множество добре обмислени проекти с отворен код, които траят повече от 5 години, то ние можем да се почудим какво, ако въобще има такова, ни носи невероятното предимство на конвенционално управляваната разработка.
Каквото и да ни носят, то определено не е нито сигурно пускане в срок, нито побиране в рамките на бюджета, или съблюдаване на всички точки от спецификацията; рядко някой "управляван" проект изпълнява дори едно от тези условия, а да не говорим за всичките три накуп. А очевидно не е и способността за приспособяване към промените в технологичния и икономически контекст по време на "битието" на проекта; общността на отворения код се оказва много по-ефективна в това отношение (както всеки може бързо да провери, например като сравни 30-годишната история на Интернет с късичкия живот на фирмените мрежови технологии; или цената на мигрирането от 16-те към 32-та бита в Microsoft Windows с извършената почти без никакво усилие миграция при Linux през същия период, не само при Intel линията, но и при над дузина други хардуерни платформи, включително 64-битовата Alpha).
Едно от нещата, които мнозина смятат, че традиционният модел ни носи е някой да бъде отговорен пред закона и по възможност да възстанови щетите, ако проектът се обърка. Това обаче е илюзия -- повечето софтуерни лицензи са написани така, че отхвърлят дори гаранцията за надеждност, а да не говорим за производителността; случаите на успешно възстановяване на щети поради непроизводителност на софтуера стават все по-редки. Дори и ако бяха по-често срещани, не би имало смисъл да се чувстваме по-добре, ако имахме кого да съдим. Хората искат не да се съдят, а да имат работещ софтуер.
И тъй, какво ни носи това предимство в управлението?
За разберем това, трябва да проумеем какво смятат, че правят софтуерните мениджъри. Една моя позната, която изглежда е много добра в тази работа, казва, че управлението на софтуерни проекти има пет функции:
Очевидно всички тези цели са важни, но при модела на софтуера с отворен код и в неговия окръжаващ социален контекст, те могат да ни се сторят странно неуместни. Ще ги разгледаме в обратен ред.
Един мой приятел ми каза, че по-голямата част от организирането на ресурсите се състои в защитата -- след като имаш хора, машини и офис пространство, трябва да ги пазиш от съседните мениджъри, които се състезават за същите ресурси, и от по-горните в йерархията, които се опитват по най-ефективен начин да използват ограничените средства.
Разработчиците на софтуер с отворен код обаче са доброволци, и се самоподбират както по интерес, така и заради възможността да допринесат за проектите, по които работят (това остава в сила дори и когато им се плаща, за да хакват отворен код). Доброволческият дух има тенденцията автоматично да се грижи за "атакуващата" страна на организирането на ресурсите -- хората слагат на масата своите собствени ресурси. Така съществува малка или никаква необходимост един мениджър да "играе в защита" в конвенционалния смисъл.
Както и да е, в един свят на евтини персонални компютри и бърз Интернет, почти постоянно виждаме, че единственият наистина ограничаващ ресурс е квалифицираното внимание. Когато проектите с отворен код се провалят, това не става поради желанието за машини или офис-пространство -- те умират само когато разработчиците загубят интерес.
След като случаят е такъв, несъмнено е важно хакерите на отворения код да се организират за максимум производителност чрез самоподбор -- а социалната среда безжалостно подбира по компетентност. Моята позната, запозната както със света на отворения код, така и с големи затворени проекти, смята, че успехът на отворения код отчасти се дължи на това, че неговата култура приема само петте или колкото са там процента най- талантливи от програмистката популация. А моята позната прекарва повечето от времето си в организирането на останалите 95%, така че от първо лице е наблюдавала една известна вариация при фактор 100 в производителността между най-способните програмисти и почти компетентните.
Размерът на тази вариация винаги повдига един неудобен въпрос: дали индивидуалните проекти, а и областта като цяло, биха били по-добре без 50% от по-неспособните? Умните мениджъри отдавна са разбрали, че ако единствената функция на конвенционалното управление беше да превърне най-малко способните от нетна загуба в чиста победа, то значи играта просто не би си струвала.
Успехът на общността на отворения код значително изостря този въпрос, като предоставя доказателства, че често е по-евтино и по-ефективно да се подберат доброволци от Интернет, отколкото да се управляват цели сгради, пълни с хора, които биха искали да се занимават с нещо друго.
Това ни води към въпроса за мотивацията. Равностоен и често срещан начин за излагане гледната точка на моята позната е, че традиционното управление на разработката е необходима компенсация за зле мотивираните програмисти, които иначе не биха свършили добра работа.
Този отговор обикновено се движи с твърдението, че можем да се осланяме на общността на отворения код само ако работата, която трябва да се върши е "секси" или технически готина -- всичко друго остава несвършено (или зле направено), освен ако не е механично изработено от парично мотивирани, затворени в кутийки ратаи с управители, които размахват камшици наоколо им. В моята студия "Да обитаваш ноосферата" говоря за психологическите и социални причини за моя скептицизъм по отношение на това твърдение. Засега обаче смятам, че е по-интересно да посоча изводите от приемането му за вярно.
Ако конвенционалният, със затворен код, тежък за управление стил на софтуерна разработка наистина се защитава само чрез нещо като линия Мажино от проблеми, благоприятстващи скуката, то това ще остане в сила за всяка отделна приложна област единствено до този момент, в който никой не смята тези проблеми за интересни и никой не намира начин да ги заобиколи. Понеже сега има надпревара в общността на отворения код за "отегчителни" програми, клиентите ще знаят, че най-после някой се е захванал да разреши този проблем заради очарованието на самия проблем -- което в програмирането, както и при други видове творческа дейност, е много по-мотивиращо, отколкото парите.
Следователно да имаш конвенционална структура на управление само за мотивация вероятно е добра тактика, но лоша стратегия; краткосрочна победа, но в перспектива почти сигурна загуба.
До тук конвенционалното управление на разработката изглежда лош избор в сравнение с отворения код поради две причини (подреждането на ресурсите, организацията), и като че ли е на доизживяване поради трета (мотивацията). А горкият обсаден конвенционален мениджър няма да получи никакви подкрепления от наблюдаването; най-силният аргумент в полза на отворения код се състои в това, че децентрализираният поглед върху нещата се оказва по-добър от всички конвенционални методи за старание да се осигури да не се изпуснат някакви детайли.
Можем ли да сметнем определянето на целите като оправдание за недостатъците на конвенционалното управление на софтуерни проекти? Може би; но за да направим това, ще ни трябва много важна причина да повярваме, че управителните комитети и корпоративните планове имат по- голям успех при определянето на подходящи и широко споделяни цели, отколкото водачите на проекти и племенните старейшини, които изпълняват аналогична роля в света на отворения код.
Изправени пред него, това е доста труден случай за разрешаване. Но това не е толкова по някаква причина от страна на отворения код (дълголетието на Emacs, или способността на Линус Торвалдс да мобилизира орди от разработчици с разговори за "световно господство"). Това по-скоро се дължи на демонстрираната невъзможност на конвенционалните механизми да дефинират целите на софтуерните проекти.
Една от най-известните фолколрни теореми в софтуерното инженерство гласи, че 60% до 75% от конвенционалните софтуерни проекти или никога не се завършват, или се отхвърлят от потребителите си. Ако тези проценти са близо до верните (а аз никога не съм срещал мениджър с какъвто и да било опит, който да ги оспори), то повечето проекти имат цели, които са или а) реалистично недостижими, или б) съвсем грешни.
Това, повече от всеки друг проблем, е причина в днешния свят на разработка на софтуер самият израз "управителен съвет" да кара чулите го да потръпват -- дори (а може най-вече) ако чулият го е мениджър. Дните, в които единствено програмистите говореха така, отдавна са отминали -- днес над бюрата на изпълнителните директори са окачени комиксите "Дилбърт" [T-DILBERT].
Следователно нашият отговор на мениджърът на традиционна софтуерна разработка е прост -- ако общността на отворения код наистина подценяваше важността на конвенционалното управление, защо толкова много от вас демонстрират презрение към собствените си дела?
Още веднъж успехът на общността на отворения код значително изостря този въпрос -- защото се забавляваме с това, което правим. Нашата творческа игра носи технически, пазарни и интелектуални успехи с невероятно темпо. Ние доказваме не само, че можем да правим по-добър софтуер, но и че удоволствието е предимство.
Две години и половина след първата версия на това есе, най-радикалните думи, с които мога да завърша, вече не са мечтата за доминиран от софтуера с отворен код свят; това, все пак, в наши дни изглежда правдоподобно на мнозина трезви хора с костюми.
По-скоро бих искал да предложа еднa по-обща поука относно софтуера (а вероятно и за всеки друг вид творческа и професионална работа). Човешките същества общо взето изпитват удоволствие от едно задание, когато то попада в областта на оптималното предизвикателство -- не прекалено лесно, за да е отегчаващо, но и не прекалено трудно за постигане. Щастлив програмист е този, който хем не стои без работа, хем не е претоварен от зле формулираните задания и стресиращото търкане на процесите. Удоволствието следва ефикасността.
Следователно ако се отнасяте към вашия собствен работен процес със страх и неохота (дори и по неуместния, ироничен начин с картинките на Дилбърт), то това трябва да се приеме само по себе си за знак, че процесът се е провалил. Удоволствието, хуморът и веселбата наистина са предимства; съвсем не за благозвучие използвах израза "щастливи орди", нито пък е обикновена шегичка, че талисман на Linux е мекичкият, сладък пингвин.
Може да се окаже, че едно от най-важните последствия от успеха на отворения код ще е да ни научи, че играта е икономически най-ефективния начин за творческа работа.