Par pārvaldību un Mažino līniju ¹

Sākotnējais Katedrāle un tirgus dokuments 1997. gadā beidzās ar iepriekšējo vīziju — kā priecīgi tīklotās anarhistisko programmētāju ordas izkonkurē un pārņem hierarhisko slēgtā koda pasauli.

Tomēr diezgan daudzi skeptiķi nenoticēja, un jautājumi, ko viņi uzdeva, izpelnījās lielu interesi. Vairums  iebildumu pret tirgus modeli bija par to, ka tā aizstāvji ir par zemu novērtējuši tradicionālās pārvaldības produktivitātes pieauguma efektu.

Tradicionāli domājoši programmatūras izstrādes vadītāji bieži iebilst, ka vieglums, ar kādu atvērtā koda pasaulē izveidojas, mainās un pazūd projekta grupas, iznīcina lielāko daļu no iespējamām priekšrocībām, ko varētu dot atvērtā koda kopienas lielums attiecībā pret vienu slēgtā koda izstrādātāju. Viņi norāda, ka programmatūras izstrāde ir ilgstoša piepūle, un piepūles apjoms daudz vairāk ietekmē lietotājiem sniegto rezultātu, kas tas, cik kaulu pametuši novārtā, un cik to palikuši vārot.

Šajā iebildumā ir daļas taisnības. Patiesībā es pat esmu izvirzījis domu, ka nepieciešamais nākotnes atbalsts ir programmatūras izstrādes ekonomikas pamatakmens esejā Burvju katls.

Bet šis arguments slēpj vienu kļūdu — tas ir pieņēmums, ka atvērtā koda izstrāde nevar nodrošināt šādu ilgstošu piepūli. Patiesībā ir bijuši atvērtā koda projekti, kas saskaņoti un efektīvi ir uzturēti pietiekami ilgu laiku, bez jebkādām kontroles institūcijām, ko tradicionālie vadītāji uzskata par būtiskām. GNU Emacs redaktora izstrāde ir viens no spilgtākajiem un pamācošākajiem šādiem piemēriem — tas ir uzkrājis simtiem atbalstītāju darba augļu vienotā arhitektūras vīzijā vairāk kā 15 gadus, neskatoties uz lielo atbalstītāju mainību, un to, ka nepārtraukti aktīvs tajā ir bijis tikai viens cilvēks (tā autors). Neviens slēgtā koda redaktors nevar sacensties ar šādu ilgmūžības rekordu.

Te nu mums rodas jautājums par citiem labumiem, kādi varētu būt katedrāles un tirgus izstrādes pieejām. Ja jau GNU Emacs ir iespējams izteikt vienotā arhitektūras vīzijā vairāk kā 15 gadus, Linux operētājsistēmu ar mainīgajām aparatūras platformām — vairāk kā 8 gadus, un, ja daudzi labi izstrādāti atvērtā koda projekti ilgst vairāk kā 5 gadus (un tā tas tiešām ir), mums jājautā — kas  mūs varētu saistīt tradicionāli pārvaldītās izstrādes milzīgajās izmaksās?

Jebkurā gadījumā, tā nav uzticama izpilde plānotajā datumā, paredzētajā budžetā vai visas specifikācijā minētās īpašības — rets tradicionāli "pārvaldīts" projekts sasniedz vienu no šiem mērķiem, kur nu vēl visus trīs. Arī iespēja pielāgoties tehnoloģiju izmaiņām projekta dzīves laikā tā noteikti nav — atvērtā koda kopiena ir pierādījusi ka tā ir daudz efektīvāka šajā jomā (piemēram, katrs to var pārbaudīt salīdzinot Interneta 30 gadu vēsturi ar īsajiem patentēto tīkla tehnoloģiju mūžiņiem, vai arī Microsoft Windows pārejas izmaksas no 16 bitiem uz 32, un praktiski nemanāmo Linux augšupeju tajā pašā laikā, ieskaitot ne tikai Intel, bet vairāk kā duci platformu attīstību, ieskaitot 64-bitu Alpha versiju).

Daudzus cilvēkus piesaista tas, ka kāds uzņemas likumīgas saistības  un potenciāli iespējams atgūt zaudējumus, ja projekts noiet galīgi greizi. Bet tā ir ilūzija — vairumā programmatūras licenču ir rakstīts, ka tās noliedz pat prasītās garantijas, piemēram, veiktspēju. Un tādu gadījumu, kad līdzekļi ir atgūti neapmierinošas veiktspējas dēļ, praktiski nav. Pat ja tie būtu bieži, justies apmierinātam par iespēju tiesāties, nozīmē aizmirst mērķi. Jūs taču negribat tiesāties — jūs gribat darbojošos programmu.

Ko dod pārvaldības izmaksas?

Vispirms mums ir jāsaprot, ko programmatūras izstrādes vadītāji domā, ko viņi dara. Man pazīstama dāma, kura (man šķiet) savu darbu dara teicami, norāda, ka programmatūras izstrādes projekta vadītājam ir jāveic piecas funkcijas:

1. Jānosaka mērķus un jānodrošina, ka visi darbojas vienotā virzienā.
2. Jāpārrauga un jānodrošina, ka netiek aizmirstas kritiskas detaļas.
3. Jāmotivē cilvēkus veikt nogurdinošu un garlaicīgu, bet vajadzīgu darbu.
4. Jāorganizē cilvēki, lai tie strādātu ar visaugstāko produktivitāti.
5. Jānodrošina resursi, kas nepieciešami projekta ilgtspējai.

Visu šo mērķu svarīgums ir acīmredzams, bet atvērtā koda pieejā un tās apkārtējā sociālajā kontekstā tie sāk izskatīties nedaudz nevietā. Mēs tos apskatīsim pretējā secībā.

Kā teic mana paziņa, resursu nodrošināšana pamatā ir aizstāvēšanās — kad tev ir savs ofiss, datori un cilvēki, tev tie ir jāaizsargā no citiem līdzvērtīgiem vadītājiem, kas cīnās par tiem pašiem resursiem, un arī no augstākstāvošiem, kas cenšas iegūt maksimumu no pieejamā daudzuma.

Bet atvērtā koda izstrādātāji ir brīvprātīgie, kam ir gan vēlme, gan iespēja piedāvāt savu darbu projektam, kurā tie strādā (un parasti tas paliek spēkā pat tad, kad viņiem sāk maksāt algu, lai viņi ķimerētu atvērto kodu). Brīvprātīgo pārliecība nodrošina resursus automātiski — viņi paši sevi piedāvā resursu sarakstā. Un vajadzība "spēlēt aizsardzību" tās tradicionālajā izpratnē ir ļoti maza, vai nav vajadzīga vispār.

Jebkurā gadījumā, lētu PC un ātra Interneta pasaulē, mēs praktiski nepārtraukti atklāsim, ka vienīgais limitējošais resurss ir zinātāju uzmanība. Ja nogrimst kāds atvērtā koda projekts, tas pilnīgi noteikti nenotiek datoru, ofisa telpu vai sakaru dēļ — tas nomirst tikai tad, kad izstrādātāji zaudē par to interesi.

Un tieši tāpēc, ir divkārt svarīgi, ka atvērtā koda hakeri paši sevi piedāvā un paši sevi organizē, lai iegūtu maksimālu produktivitāti — bet sociālā vide nesaudzīgi izvēlas kompetenci. Mana paziņa pārzina gan atvērtā koda, gan slēgtā koda projektus, un uzskata, ka atvērtais kods ir veiksmīgs daļēji tāpēc, ka tā kultūra pieņem tikai talantīgākos 5% no visu programmētāju populācijas. Lielāko daļu sava laika viņa pavada organizējot atlikušos 95%, un tāpēc praktiski ir novērojusi labi zināmo simtkārtīgo produktivitātes atšķirību starp visspējīgākajiem un vienkārši kompetentiem programmētājiem.

Atšķirības lielums vienmēr rada nepatīkamu jautājumu: vai viens projekts un nozare kopumā būs labāks, ja tam atņems vairāk kā 50% nespējīgāko? Apdomīgi vadītāji jau sen ir sapratuši — ja tradicionālās programmatūras izstrādes vadītāja vienīgā funkcija būtu tīro zaudējumu pārvēršana minimālā peļņā, spēle nav to vērta.

Atvērtā koda kopienas veiksme šo jautājumu saasina vēl vairāk, pierādot, ka ir daudz lētāk un efektīvāk savervēt pašmotivētus brīvprātīgos Internetā, kā pārvaldīt pilnu māju ar cilvēkiem, kas labāk vēlētos darīt ko citu.

Un tas mūs labi noved pie nākamā jautājuma par motivāciju. Atbilstošs un bieži dzirdēts manas paziņas viedokļa izklāsts ir, ka tradicionālajā izstrādē vadība ir nepieciešamā kompensācija vāji motivētiem programmētājiem, kas pretējā gadījumā nestrādās pietiekami labi.

Šī atbilde parasti saistīta ar norādi,  ka atvērtā koda kopienā var paļauties tikai uz tādu darbu, kas ir "modē" vai tehniski patīkams; viss cits paliks nepadarīts (vai tiks paveikts ļoti vāji) līdz to neizdarīs ar naudu motivēti un vadītāju skubināti laboratoriju algādži. Psiholoģiskos un sociālos cēloņus detalizēti esmu norādījis Homesteading the Noosphere. Tomēr šībrīža vajadzībām interesantāk ir norādīt sekas, pieņemot to kā patiesību.

Tradicionālajā, spēcīgi vadītajā slēgtā koda programmatūras izstrādes stilā garlaicīgās kļūdas tiek aizsargātas ar Mažino līniju — ikvienā programmā tās paliek tik ilgi tāpēc, ka nevienu šīs problēmas patiesībā neinteresē un neviens nemeklē veidu, kā ar tām tikt galā. Atvērtajā kodā norit sacensība pēc "apnicīga" programmas gabala, lietotāji uzzina, ka kāds ir uzņēmies tās risināšanu, jo viņu interesē pati problēma — kas programmatūras izstrādē, tāpat kā jebkurā citā radošā darbā ir daudz efektīvāks motivētājs par naudu.

Izmantot motivācijai tikai tradicionālos vadības veidus, varbūt arī ir laba taktika, bet slikta stratēģija — īslaicīgs ieguvums ilgākā termiņā ir drošs zaudējums.

Līdz šim mēs redzējām, ka tradicionālās izstrādes vadītāji zaudē atvērtajam kodam divos punktos (resursu nodrošināšana un organizēšana), un rādās, tas jau pārāk ilgi turas uz trešā (motivācijas) rēķina. Izskatās, nabaga aplenktais tradicionālais vadītājs negūst nekādu palīdzību arī pārraudzības jomā — spēcīgākais atvērtā koda kopiena arguments ir decentralizētā vienranga pārbaude, kas pārspēj jebkuru tradicionālo metodi, neļaujot aizmirst detaļas.

Vai mēs varam attaisnot tradicionālo programmatūras izstrādes projektu izmaksas ar mērķu noteikšanu? Iespējams, bet lai to darītu mums jāpārliecinās, ka noderīgu un kopēju mērķu noteikšanā vadītāju komitejas un korporatīvās perspektīvas ir veiksmīgākas par projektu līderiem un cilšu vecākajiem, kas veic analogas funkcijas atvērtā koda pasaulē.

Šis nu ir grūts uzdevums. Par to liek domāt ne tik daudz atvērtā koda svaru puse (Emacs ilgmūžība, vai Linusa Torvaldsa spēja mobilizēt programmētāju ordas ar runām par "pasaules vadīšanu"), bet drīzāk gan ellīgi grūtais programmatūras mērķu izstrādes tradicionālais mehānisms.

Viena no plaši zināmām programmatūras izstrādes teorēmām vēsta, ka 60% līdz 75% tradicionālo izstrādes projektu vai nu nekad nav pabeigti, vai tos ir noraidījuši iecerētie lietotāji. Ja šie skaitļi ir tuvu patiesībai (un es neesmu saticis vadītāju, kas tam iebilstu), tad vairums projektu ir virzīti uz mērķi,  kas:

1. patiesībā nav sasniedzami, vai
2. ir absolūti nepareizi.

Tas ir galvenais cēlonis, kāpēc šodienas programmatūras izstrādes pasaulē izdzirdot frāzi "vadības komiteja" mugurai pāriet drebuļi, pat (vai — it īpaši) ja dzirdētājs pats ir vadītājs. Laiki, kad par to drebēja parasti kodētāji, ir pagātnē — Dilberta karikatūras tagad ir arī uz vadošo darbinieku galdiem.

Mūsu atbilde tradicionālajam programmatūras izstrādes vadītājam ir vienkārša — ja atvērtā koda kopiena tradicionālās pārvaldības lomu ir novērtējusi pār zemu, tad kāpēc tik daudzi no jums noniecina paši savu procesu?

Un atkal atvērtā koda pasaule šo jautājumu saasina — jo mums patīk tas, ko darām. Mūsu radošā spēle ir veiksmīgi iekarojusi tehnisko, tirgus un domāšanas daļu ar pārsteidzošu rezultātu. Mēs pierādām, ka ne tikai spējam radīt labāku programmatūru, bet arī to, ka prieks ir vērtība.

Divarpus gadus pēc šīs esejas pirmās versijas, trakākā doma, ar ko es varēju beigt, bija vīzija par atvērtā koda programmatūras dominanci pasaulē. Šodien tas šķiet pamatoti arvien vairāk nosvērtiem cilvēkiem uzvalkos.

Drīzāk es varētu ieteikt vēl plašāku mācība par programmatūru (un varbūt par jebkuru radošu vai profesionālu darbu). Cilvēki gūst prieku no uzdevumiem, kas ir optimālā izaicinājuma zonā — ne pārāk viegli, lai būtu apnicīgi, ne pārāk grūti — lai sasniegtu. Laimīgs ir tas programmētājs, kas nav nedz neizmantots, nedz nospiests ar slikti izvirzītiem mērķiem, domstarpībām vai saspīlētu notikumu gaitu. Efektivitāti nosaka baudījums.

Jūsu pašu procesa saistība ar bailēm un naidu (kā tas, piemēram, ir attēlots ironiskajās Dilberta karikatūrās) jau pati par sevi ir zīme, ka process nav pareizs. Prieks, humors un rotaļīgums ir patiesās vērtības, un augstāk minētās "laimīgas ordas" nav tikai vārdu spēle, un tas nav tikai joks, ka Linux talismans ir mīļš pusaugu pingvīns.

Iespējams, atvērtā koda veiksmes lielākais rezultāts būs tas, ka mēs iemācīsimies — visefektīvākais veids radoša darba darīšanai ir spēle.

1. ^ Mažino līnija bija gara pastāvīga Franču aizsardzības līnija pret Vāciju un Itāliju 2. pasaules karā.