Piezīmes

(JB) Programing Pearls, pazīstamais datorzinātnes un aforismu autors Džons Bentlijs (Jon Bentley) Brūka (Brooks) novērojumu komentē šādi "Ja jūs plānojat izmest vienreiz, jūs izmetīsiet divreiz." Viņam ir pilnīga taisnība. Tomēr Brūka un Bentleja novērojums nav par to, ka jums jāuzskata pirmais mēģinājums par nepareizu, bet gan par to, ka sākt no jauna ar pareizu risinājumu ir efektīvāk, nekā mēģināt saglābt nekārtību.

(QR) Ar Unix nesaistīti, veiksmīgi atvērtā koda tirgus modeļa projekti bija jau pirms Interneta eksplozijas. Viens no piemēriem ir info-Zip kompresēšanas rīka izstrāde 1990. — 1992. gados, galvenokārt, DOS mašīnām. Cits piemērs ir RBBS ziņojumu dēļa sistēma (atkal priekš DOS), kas sākās 1983. gadā  un izveidoja pietiekami spēcīgu kopienu ar pietiekami biežiem laidieniem līdz pat mūsdienām (1999. gada vidus) neskatoties uz Interneta vēstuļu un failu koplietošanas milzīgajām tehniskajām priekšrocībām salīdzinot ar lokālām BBS sistēmām. Kamēr info-Zip kopiena diezgan pamatīgi balstījās uz Interneta pastu, RBBS izstrādātāju kultūra spēja nodrošināt tiešsaistes kopienu, izmantojot paši savu RBBS sistēmu, kas bija diezgan neatkarīga no TCP/IP infrastruktūras.

(CV) Tas, ka pārskatāmība un vienranga apskates spēj savaldīt OS izstrādes sarežģītību nebija jaunatklājums. 1965. gadā laikdalības sistēmu ļoti agrā vēsturē, Korbato (Corbató) un Visockis (Vyssotsky), Multics operētājsistēmas līdzautori rakstīja

Paredzēts, ka Multics sistēma tiks publicēta, kad tā būs pietiekami darbotiesspējīga... Šī publikācija ir nepieciešama divu iemeslu dēļ: pirmkārt, sistēmu nepieciešams atrādīt brīvprātīgo interesentu pārbaudei un kritikai; otrkārt, pieaugošās sarežģītības laikmetā, šodienas un nākotnes sistēmu izstrādātāju pienākums ir izstrādāt operētājsistēmu dizainu cik vien iespējams skaidru un pārredzamu, lai būtu iespējams atklāt sistēmas pretrunas un trūkumus.

(JH) Džons Heslers (John Hasler) ieteica interesantu izskaidrojumu, kāpēc atvērtā koda pasaulē darbību dublēšanās nekad nav bijis nopietns kavēklis. Viņš piedāvā (kā es to gribētu saukt) "Heslera likumu": darbību dublēšanās izmaksas pieaug lēnāk kā cilvēku skaita kvadrāts — tas ir, lēnāk, kā plānošanas un pārvaldības izmaksas, kas būtu nepieciešamas lai šādu dublēšanos novērstu.

Patiesībā šī iebilde nav pretrunā ar Brūka likumu. Ir iespējams gadījums, kad kopējās sarežģītības izmaksas un kļūdu ieviešanās iespēja pieaug saskaņā ar komandas lieluma kvadrātu, tomēr dublēto darbību izmaksas ir īpašs gadījums, kas pieaug lēnāk. Nav grūti izdomāt ticamus iemeslus — sākot ar to, ka daudz vieglāk darbību dublēšanos var novērst daži izstrādātāji,  vienojoties par funkcionālajām robežām kodā, kā novērst neplānotu un sliktu sadarbību visā sistēmā, kas ievieš lielāko tiesu kļūdu.

No Linusa un Heslera likumu apvienojuma izriet, ka programmatūras projektiem ir trīs kritiskie lielumi. Mazos projektos (es teiktu viens līdz trīs izstrādātāji) nav nepieciešamas vairāk vadības struktūras, kā vadošā programmētāja izvirzīšana. Virs šī ir diapazons, kurā tradicionālās pārvaldības izmaksas ir pietiekami mazas, lai kopumā darbību dublēšanās novēršana, kļūdu atsekošana un centieni neaizmirst detaļas kopumā, dod pozitīvu rezultātu. 

Un virs tā  ir lielo projektu diapazons, kur tradicionālās pārvaldības izmaksas un problēmas pieaug daudz straujāk, kā dublēto darbību izmaksas. Kā viens no faktoriem darbojas nespēja nodrošināt daudzu skatu efektu, kas (kā mēs redzējām) kļūdu noteikšanā un detaļu pamanīšanā strādā daudz labāk, kā tradicionālām pārvaldības sistēmām. Tā lielu projektu gadījumā, šo divu likumu apvienojums tradicionālo pārvaldības metožu vērtību ātri noved līdz nullei.

(HBS) Linux eksperimentālo un stabilo versiju atdalīšana ir saistīta ar riska samazināšanu, tomēr tai ir arī cita funkcija. Atdalīšana ir vērsta pret vēl vienu problēmu — gala termiņu nemainību. Kad programmētāji tiek turēti gan pie nemainīgu īpašību saraksta, gan pie fiksēta nodošanas datuma, kvalitāte ir pa logu laukā un būvēšana ir viens milzīgs ņudzeklis. Esmu pateicību parādā Marko Jansiti (Marco Iansiti) un Alanam Makkormakam (Alan MacCormack) no Hārvardas Biznesa skolas par pierādījumiem, ka viena šī ierobežojuma atcelšana plānošanu padara darbaspējīgu.

Viena iespēja ir noteikt gala termiņu, bet atstāt īpašību sarakstu mainīgu, ļaujot izmest iespējas, kas nav pabeigtas līdz gala termiņam. Šī ir "stabilā" zara pamatstratēģija — Alans Koks (Alan Cox, stabilā kodola uzturētājs) izlaiž laidienus pietiekami regulāri, bet negarantē, kad būs izlabotas noteiktas kļūdas un kad būs ieviestas noteiktas iespējas no eksperimentālā zara.

Otra iespēja ir noteikt vajadzīgo īpašību, un nodot tikai tad, kad tā ir gatava. Šī ir "eksperimentālā" zara pamatstratēģija. De Marko (De Marco) un Listers (Lister) atsaucas uz pētījumiem parādot, ka viņu plānošanas politika ("pamodiniet mani, kad tas ir izdarīts") nodrošina ne tikai augstu kvalitāti, bet visā visumā arī agrākus nodošanas laikus kā "reālistiska" vai pat "agresīva" plānošana.

Man ir aizdomas (2000. gada sākumā), ka agrākās šīs esejas versijās es nenovērtēju pietiekami nopietni "pamodiniet mani, kad ir izdarīts" faktora  "anti gala termiņu" politiku atvērtā koda kopienu produktivitātē un kvalitātē. GNOME 1.0 izlaiduma pieredze 1999. gadā rāda, ka negatavu laidienu steidzināšana neitralizē daudzus atvērtā koda kvalitātes labumus, ko tas mums piedāvā normālos apstākļos.

Ir labi pamanāms, ka bez "pamodiniet mani, kad tas ir izdarīts" plānošanas un izstrādātāju pašatlases, atvērtā koda kvalitātes trešais dzinējs ir procesa pārskatāmība.

(SU) Ir vilinoši un daļēji arī pareizi saskatīt, ka uz Internetu balstītā kodola un vainaga organizācija atvērtā koda projektos ir līdzīga Brūka rekomendētajai "operatīvās brigādes" organizācijai N kvadrāta problēmas risinājumam, tomēr atšķirības ir milzīgas. Speciālistu lomu plejāde kā, piemēram, "koda bibliotekārs", kuras Brūks iedomājās ap grupas vadītāju patiesībā nav — šīs lomas pilda erudīti, bruņoti ar rīkiem, tikai nedaudz spēcīgākiem, kā tas bija Brūka laikā. Tāpat atvērtā koda kultūra pamatīgi balstās uz tādām Unix tradīcijām kā modularitāte, API un informācijas iekapsulēšana — neviena no tām netika minēta Brūka norādījumos.

(RJ) Respondents, kas man norādīja kļūdu atkārtojuma ceļu garuma atšķirību raksturošanas grūtības, prātoja, ka kļūdas ceļu garums vairākiem tās pašas kļūdas simptomiem mainās "eksponenciāli" (ko es domāju kā Gausa vai Puasona sadalījumu, un piekrītu, ka izskatās ticami). Ja šī sadalījuma grafiku ir iespējams iegūt eksperimentāli, tie būtu ļoti noderīgi dati. Garās astes ar praktiski vienādu varbūtības sadalījumu ceļa sarežģītībā mūs vedina domāt, ka pat solo izstrādātāji varētu emulēt tirgus stratēģiju, ierobežojot laiku, ko tie pavada vienas problēmas pētīšanai, pirms tie ķeras pie nākamās. Ne vienmēr neatlaidība ir tikums...

(IN) Jautājums par to, vai iespējams sākt projektus no nulles tirgus stilā, ir jautājums par to, vai tirgus stils ir spējīgs nodrošināt patiesi radošu darbu. Daži iebilst, ka spēcīgas vadības trūkuma dēļ, tirgus var tikai nodrošināt uzlabojumus un tādu ideju klonēšanu, kas jau ir zināmi inženierijas pēdējie sasniegumi, bet tas nevar virzīt pašu sasniegumu radīšanu. Iespējams, šis arguments visapkaunojošāk ir minēts Helovīna dokumentos, divos mulsinošos Microsoft memorandos par atvērtā koda fenomenu. Autori salīdzināja Linux izstrādi ar Unix-veidīgas operētājsistēmas "pakaļējo gaismu tjūnēšanu", un izteica savas domas "(kad projekts ir kļuvis "līdzvērtīgs" pēdējiem sasniegumiem), masīva vadība, kas virzīs uz tālākiem mērķiem, kļūst nenovērtējama.''

Patiesībā šajā apgalvojumā ir nopietnas kļūdas. Viena ir atklāta vēlāk, kur paši autori tālāk norāda — "bieži (...) jaunas pētījumu idejas, pirms tās parādās citās platformās, vispirms tiek implementētas Linux."

Ja "Linux" vietā mēs lasām "atvērtais kods", tad redzam, ka tas ne tuvu nav jauns fenomens. Atvērtā koda kopiena savā laikā neizgudroja Emacs, pasaules tīmekli (World Wide Web) vai Internetu "tjūnejot pakaļējās gaismas" vai pamatīgi vadīt. Un arī tagad atvērtajā kodā tiek ieguldīts tik daudz inovatīva darba, ka izvēle katru var izlutināt. Piemēram, GNOME projekts virza grafiskās saskarnes un objektu tehnoloģiju pietiekami pamatīgi, lai piesaistītu datoru industrijas preses uzmanību arī ārpus Linux kopienas. Citu piemēru ir tūkstošiem, lai par to pārliecinātos, jebkurā brīdī pietiek paskatīties Freshmeat.

Bet vēl fundamentālāka kļūda ir netiešajā pieņēmumā, ka katedrāles modelis (vai tirgus modelis, vai jebkurš cits vadības veids) var droši garantēt izgudrojumus. Tas ir nonsenss. Bandas nerada izgudrojumus — pat atvērtā koda brīvprātīgo anarhistu grupas parasti nav spējīgas uz ģeniālu oriģinalitāti, kur nu vēl korporāciju komitejas ar akciju kontrolpakešu turētājiem. Iedvesma rodas atsevišķos cilvēkos. Maksimums, uz ko var cerēt sociālā mašinērija — būt atsaucīgiem pēkšņai atklāsmei — lolot, atalgot un neredzami pārbaudīt, tā vietā lai apslāpētu.

Kāds to nosauks par romantisku skatu, atgriešanos pie novecojušiem vientuļo izgudrotāju stereotipiem. Nepavisam ne — es neapgalvoju, ka grupas nav spējīgas izstrādāt  izcilus atklājumus, kad tas jau ir noķerts. Drīzāk mēs redzam, ka vienranga apskašu procesā šādas izstrādes grupas sasniedz augstas kvalitātes rezultātu. Es norādu uz to, ka katrā grupā izstrāde sākas (un noteikti ir iedvesmota) ar vienu labu ideju, kas radusies viena cilvēka galvā. Katedrāle un tirgus ar to sociālajām struktūrām var noķert šo ideju un bagātināt to, bet nevar izdarīt to uz pieprasījuma.

Tāpēc galvenā izgudrojumu problēma (programmatūrā un visur citur) patiesībā ir kā to neapslāpēt — un būtībā — kā savākt pēc iespējas vairāk cilvēku, kas pirmkārt ir spējīgi uz atklāsmi.

Pieņemt, ka katedrāles izstrādes stils to nodrošina, bet tirgus ar tā vienkāršajām pievienošanās iespējām un procesa mainību — nē, būtu absurds. Jo tā taču piedāvā sociālo vidi, kurā viens cilvēks ar labu ideju var ātri piesaistīt sadarbībā simtus un tūkstošus citu, un neatkarīgi no tā, ko viņš bija darījis pirms tam, viņš var strādāt ar savu ideju, nebaidoties, ka tiks atlaists.

Un patiesi, ja mēs skatāmies uz programmatūras izgudrojumu vēsturi, mēs ātri vien pamanīsim, ka organizācijās ar katedrāles stilu tie ir reti gadījumi. Lielas korporācijas balstās uz idejām, kas iegūtas universitāšu pētījumos (tādējādi Helovīna dokumentu autori pauž satraukumu par Linux spēju iekļaut pētījumu rezultātus ātrāk). Vai arī tās nopērk mazākas kompānijas, kas ir izveidojušās ap kāda izgudrotāja smadzenēm. Un nevienā gadījumā izgudrojumi nav bijuši dabīgi katedrāles kultūrai — patiesībā daudzi izgudrojumi ir klusi nožņaugti ar "masīvo vadības līmeni" ko Helovīna dokumentu autori tik ļoti slavina.

Tas tomēr ir negatīvs skats. Lasītājam labāk varētu patikt pozitīvs piemērs. Es kā eksperimentu iesaku sekojošo:

• Izvēlieties oriģinalitātes kritēriju, kuru jūs spējat konsekventi pielietot. Ja jūsu definīcija ir "Es to zinu, kad es to redzu", tas nav šķērslis šīs pārbaudes veikšanai.
• Izvēlieties kādu slēgtā koda operētājsistēmu, kas konkurē ar Linux, un labākos avotus, kas raksturo tās izstrādes gaitu.
• Vērojiet šo izvēlēto avotu un Freshmeat vienu mēnesi. Katru dienu saskaitiet laidienu ziņojumus Freshmeat, kurus jūs uzskatāt par "oriģināliem" darbiem. Pielietojiet tos pašus "oriģinalitātes" kritērijus izvēlētajai operētājsistēmai un saskaitiet tos.
• Pēc trīsdesmit dienām saskaitiet kopējos rādītājus abām pusēm.

Dienā, kad es to rakstīju, Freshmeat izplatīja divdesmit divus laidienu ziņojumus, no kuriem trīs varētu virzīt modernos sasniegumus dažās jomās. Freshmeat tā bija klusa diena, bet es būtu pārsteigts, ja kāds lasītājs ziņotu par trijiem jauniem izgudrojumiem mēnesī kādā no slēgtā koda kanāliem.

(EGCS) Tagad mums ir projekta vēsture, kas dažādos veidos var piegādāt daudz zīmīgākus faktus tirgus pieņēmumiem kā fetchmail — EGCS (eksperimentāls GNU kompilators).

Šis projekts tika izziņots 1997. gada augusta vidū,  kā apzināts mēģinājums pielietot agrākajās Katedrāles un tirgus versijās publicētās idejas. Projekta dibinātāji juta, ka GCC (Gnu C) kompilatora izstrāde ir sākusi stagnēt. Pēc tam apmēram divdesmit mēnešus GCC un EGCS turpināja pastāvēt kā paralēli produkti — abi nākuši no Interneta izstrādātājiem, abi sākušies no kopīga GCC pirmkoda, abi izmantoja ļoti līdzīgus Unix rīkus un izstrādes vidi. Vienīgā atšķirība bija, ka EGCS nepārtraukti mēģināja piekopt tirgus izstrādes taktiku, kuru es pirmīt aprakstīju, kamēr GCC turpināja katedrālei līdzīgu organizāciju ar slēgtu izstrādātāju kopu un retiem laidieniem.

Tas bija tik tuvs apzinātām eksperimentam, cik vien varēja vēlēties, un rezultāti bija dramatiski. Dažu mēnešu laikā EGCS versijas pamatīgi pavirzījās uz priekšu ar dažādām iespējām — labāku optimizāciju, labāku FORTRAN un C++ atbalstu. Daudzi cilvēki EGCS izstrādes būvējumus atzina par labākiem un stabilākiem kā GCC stabilās versijas, un vairums Linux distributīvu sāka pāriet uz EGCS.

1999. gada aprīlī, Free Software Foundation (GCC oficiālie sponsori) likvidēja sākotnējo GCC izstrādes grupu un oficiāli pārņēma EGCS darba grupas vadību.

(SP) Protams, Kropotkina kritika un Linusa likums izraisa daudz plašākās pārdomas par kibernētiku un sociālajām grupām. Cita programmatūras izstrādes folklora ir t.s. Konveja (Conway) likums, parasti izklāstīts kā: "Ja jums ir četras grupas, kas izstrādā kompilatoru, jūs iegūsiet četru pakāpju kompilatoru". Oriģinālais traktējums bija vispārīgāks: "Organizācijas, kas izstrādā produktus, ir ierobežotas, tāpēc tās izstrādā produktus, kuru dizains kopē organizācijas komunikācijas struktūras." Ko mēs varam pateikt kompaktāk kā "Līdzekļi nosaka robežas" vai pat "Process nosaka produktu".

Attiecīgi ir vērts pieminēt atvērtā koda organizatoriskās un tehniskās struktūras daudzējādo līdzību. Tīkls ir viss un visur: ne tikai Internets, bet arī cilvēki, kas dara darbu sadalītā, vāji saistītā vienranga tīklā, nodrošinot daudzkāršu pārpalicību un traucējumnoturību. Abos tīklos katrs mezglpunkts ir tikai tik svarīgs, cik ļoti citi mezglpunkti vēlas ar to sadarboties.

Vienranga savienojumi ir būtiski kopienas pārsteidzošajā produktivitātē. Princips, ko Kropotkins mēģināja pateikt par spēka attiecībām tālāk tika izstrādāts kā "SNAFU princips": "Patiesa saskarsme ir iespējama tikai starp vienlīdzīgiem, jo vadītājs pakļauto biežāk atalgo par jaukiem meliem nekā par rūgtu patiesību". Radošs komandas darbs ir absolūti atkarīgs no patiesas saskarsmes un tāpēc tiek nopietni kavēts ar spēka attiecībām. Atvērtā koda kopiena māca mums, cik briesmīgi daudz maksā kļūdas, pazemināta produktivitāte, un pazaudētas iespējas, ja neesam brīvi no šādām spēka attiecībām.

Turklāt pēc SNAFU principa autoritārās organizācijās arvien vairāk pieaug plaisa starp lēmumu pieņēmējiem un realitāti, jo lēmējiem arvien vairāk tiek piedāvāti patīkami meli. Veids, kā tas notiek tradicionālajā programmatūras izstrādē ir labi redzams — padotie tiek mudināti slēpt, ignorēt un minimizēt problēmas. Kad šis process kļūst par produktu, programmatūra ir beigta.