Om ledning och om Maginotlinjen

I ursprungsversionen av "Cathedral and Bazaar" (1997) avslutades med ovanstående vision - den att glada horder av internetanslutna programmerare/anarkister skulle konkurrera ut den hierarkiska världen av konventionell och sluten programvara.

Många skeptiker var emellertid inte övertygade om detta, och invändningarna de reser förtjänar ett hederligt bemötande. De flesta protester mot basarargumentationen kommer fram till att dess företrädare underskattar den produktivitetshöjande effekten som finns i en konventionell organisation.

Traditionellt tänkande organisatörer av programutveckling invänder ofta att det är tillfälligheter som skapar, omformar och upplöser open-source projekt, och att detta suddar ut en stor del av de fördelar i numerär som open-source-rörelsen har i förhållande till enskilda 'closed-source'-utvecklare. De menar att i mjukvaruutveckling är det kontinuerligt arbete under lång tid och den grad av utveckling kunden kan förvänta att det investeras i produkten som räknas. Inte hur många som slänger ett köttben i grytan.

Det finns något i denna argumentation. Jag har utvecklat denna tanke om förväntad-framtida-service-värde som en nyckel till ekonomin i programvaruproduktion i "The Magic Cauldron" (http://catb.org/~esr/writings/magic-cauldron/).

Men det finns ett dolt problem i denna argumentation. Här förutsättes att open-source utveckling inte kan ge denna kontinuerliga uppföljning. Faktum är att det har pågått open-source projekt som har behållit en samstämmig ledning och en aktiv underhållarkår under lång tid utan de incitamentstrukturer och den institutionella styrning som konventionella företagsgsledningar betraktar som nödvändiga. Utvecklingen av GNU Emacs är ett extremt och instruktivt exempel. Den har absorberat mödan från hundratals bidragare i femton år till en enhetlig arkitektur, trots hög omsättning och det faktum att bara en person, dess författare, har varit kontinuerligt aktiv hela tiden. Det finns ingen 'closed-source' editor som kan matcha detta åldersrekord.

Detta antyder en orsak att ifrågasätta fördelarna med konventionellt ledd programvaruutveckling som är oberoende av den övriga argumentationen om katedral- kontra basarstilen. Om det är möjligt för GNU Emacs att uttrycka en sammanhållen arkitektonisk vision i över femton år, eller för ett operativsystem som Linux att göra det samma över åtta år av snabbt föränderlig hårdvaruteknik, och om (vilket är fallet) det har funnits många välritade open-source projekt med mer än fem års uthållighet - då är det berättigat att ställa frågan om vad den stora överbyggnad som finns i konventionellt ledd programvaruutvecklig egentligen ger oss.

Vad det än är, så innefattas inte tillförlitlighet genom deadline, kostnad-inom-budgetramar eller innehåll-enligt-specifikation. Det är sällan konventionellt ledda projekt uppnår ens ett av dessa mål, och lång mindre alla tre.

Det verkar inte heller vara förmågan att anpassa sig till teknikförändring eller förändring av ekonomiska förutsättningar under projektets livstid. Open-source samhällena har visat sig vida överlägsna i denna gren. Vilket man lätt kan visa genom att t.ex. jämföra Internets 30-åriga historia med med de korta halveringstider som funnits hos firmaspecifika nät-tekniker, eller kostnaden för Microsoft Windows för övergång från 16 till 32 bitars maskiner, jämfört med den nästan omärkbara anpassning som Linux gjorde under samma tid, inte bara för Intel-linjen utan för mer än ett dussin andra hårdvaruplattformar inklusive 64-bitars Alpha.

En sak som en del människor tror att man köper i den traditionella moden är någon att hålla rättsligt ansvarig för att kunna få ersättning om projektet går fel. Men detta är en illusion. De flesta mjukvarulicenser är skrivna för att frånsäga sig ansvar, till och med för säljbarhet och än mindre för prestanda. Och det finns försvinnande få fall av ersättning för icke fungerande mjukvara. Ävn om detta vore vanligt, skulle den ljuva känslan av att ha någon att stämma, vara att missa poängen. Meningen var väl inte att hamna i en juridisk process, utan att ha ett fungerande program.

Så vad är det som överbyggnaden tillför?

För att förstå detta behöver vi veta vad ledningar för mjukvaruprojekt anser att de gör. En kvinna som jag känner och som förefaller vara framgångsrik i sitt värv menar att projektledning har fem funktioner:

1. Att definiera mål och få alla att gå åt samma håll.
2. Att övervaka och se till att inga viktiga detaljer glöms bort.
3. Att motivera människor att göra tråkigt men nödvändigt slavarbete.
4. Att organisera människor för att uppnå bästa möjliga produktivitet.
5. Att plocka fram de resurser som krävs för att underhålla projektet.

Uppenbart viktiga mål alla dessa, men i open-source modellen och i dess sociala sammanhang, kan de synas märkligt irrelevanta. Låt oss ta dem i omvänd ordning.

Vännen säger att en hel del av resurs mobiliseringen i grunden är defensiv. När man har sina resurser, människor, maskiner och kontorsutrymme, måste man försvara dem från andra projektledare som konkurrerar om samma resurser, och från högre chefer som försöker styra för att få ut mesta möjliga från en begränsad pool.

Men open-source utvecklare är frivilliga. Självutvalda utefter både intresse och förmåga att bidra till projektet. Detta gäller också de som har betalt för att hacka open-source. Volontärernas lynne tar automatiskt hand om resursmobiliseringen. Folk lägger sina egna resurser på bordet. Och det finns inget behov av att försvara sina resurser.

Hur som helst, i en värld av billiga datorer och snabba internetförbindelser, ser man genomgående att den enda begränsande resursen är uppmärksamhet från tillräckligt kvalificerade människor. När open-source projekt förliser, gör de det aldrig på grund av brist på maskiner, nätförbindelser eller kontorsutrymme. De dör endast när utvecklarna själva tappar intresset.

När det är så, är det dubbelt viktigt att open-source hackare organiserar sig för maximal produktivitet genom 'self-selection' - och den sociala miljön väljer hänsynslöst efter kompetens. Min vän, som är insatt i både open-source världen och stora slutna projekt, tror att open-source har blivit framgångsrik därför att dess kultur endast accepterar de mest begåvade 5% eller så av alla de som programmerar. Hon använder det mesta av sin tid till att samordna de övriga 95%, och har direkt observerat den väl kända variansen på en faktor hundra i produktivitet mellan de duktigaste och de nätt och jämt kompetenta programmerarna.

Variansens storlek har alltid rest en otäck fråga: Skulle enskilda projekt, och branschen i sin helhet, klara sig bättre utan de 50% minst begåvade? Tankfulla projektledare har länge förstått att om konventionella projektledningens enda funktion vore att konvertera de minst kompetenta från en nettoförlust till en marginell vinst, skulle spelet inte vara mödan värt.

Open-source rörelsens framgångar skärper denna fråga avsevärt, genom att den bevisar att det ofta är både billigare och effektivare att rekrytera självutvalda volontärer från Internet än att ha hand om byggnader fulla av folk som hellre vill göra något annat.

Vilket direkt för oss till frågan om motivation. Ett likvärdigt och ofta upprepat sätt att uttrycka vännens synpunkt är att traditionell ledning av utveckling är en nödvändig kompensation för dålig motivation hos programmerare som detta förutan inte skulle prestera något bra jobb.

Svaret kommer vanligen tillsammans med påståendet att open-source rörelsen endast kan betros att göra de jobb som är sexiga eller tekniskt läckra, allt annat kommer att lämnas ogjort, eller dåligt gjort. Såvida det inte blir framtvingat av pengamotiverade kontorsdrängar med chefer som knäcker sina piskor på deras ryggar. Jag behandlar de psykologiska och sociala skälen för att vara skeptisk mot dettas påstående i 'Homesteading the Noosphere'. Just här tror jag emellertid att det är mer intressant att peka på följderna av att acceptera påståendet som sant.

Om den konventionella, slutna och hårt styrda stilen för mjukvaruutveckling i verkligen endast försvaras med en sorts Maginotlinje av problem ledande till uttråkning, då kommer det att äga giltighet inom varje enskilt ämne så länge som ingen finner dess problem intressanta och ingen hittar en väg att kringgå dem. Därför att i det ögonblick det finns open-source konkurrens för en 'tråkig' bit mjukvara, kommer kunden att veta att detta har slutligen tacklats av någon som valt detta problem på grund av fascination över problemet självt. Vilket, såväl inom mjukvara som inom andra slag av kreativt arbete, är ett mycket starkare motiv än enbart pengar.

Så att ha en konventionell ledningsstruktur enbart i syfte att motivera, är troligen en bra taktik men dålig strategi. Det ger en kortsiktig vinst, men på lång sikt en säker förlust.

Så långt, konventionell ledning av utveckling ser ut att vara ett dåligt val i jämförelse med open-source på två punkter (resurstilldelning och organisation) och lever på lånad tid vad gäller den tredje (motivation). Den stackars belägrade konventionelle ledaren kommer inte att få någon hjälp från övervaknings-argumentet. Det starkaste argumentet open-source rörelsen har är att decentraliserad granskning övertrumfar alla konventionella metoder att garantera att inga detaljer glöms bort.

Kan man då säga att definiera mål är något som rättfärdigar den överbyggnad som finns inom konventionell projektledning? Kanske, men för att göra detta behöver man ett gott skäl att tro att ledningskomittéer och verksamhetsplaner är bättre på att definiera värdiga och brett accepterade mål än de projektledare och stam-äldste som har motsvarande roller i open-source världen.

Detta är en svår sak att avgöra. Och det är inte så mycket open-source sidans vågskål (Emacs långa livslängd, Linus Torvalds förmåga att mobilisera horder av utvecklare genom att tala om "världsdominans") som gör saken svår. Snarare är det den avskyvärda mekanism som demonstreras vid måldefinitionen inom konventionella mjukvaruprojekt.

En av de mest välkända folkliga teorierna om mjukvarans ingenjörskonst är att 60 till 75% av mjukvaruprojekten aldrig blir fullbordade eller förkastas av dess förmodade användare. Om den uppgiften ligger någonstans i närheten av sanningen, och jag har aldrig mött någon erfaren chef eller projektledare som ifrågasätter den, betyder det att flertalet projekt blir riktade mot mål som antingen inte är realistiska eller helt enkelt fel.

Detta, mer än något annat problem, är orsaken till att i den värld där dagens programmerare befinner sig sänder blotta frasen 'ledningskommitté' kalla kårar längs ryggraden - kanske speciellt om den som hör frasen är chef. De dagar då endast programmerarna jämrade sig över detta är sedan länge förbi. Seriefiguren 'Dilbert' hänger numer även över chefers skrivbord.

Så vårt svar till den traditionella utvecklingsledaren, är enkelt - om open-source-rörelsen har underskattat värdet av traditionellt ledarskap, varför klagar då så många av er på er egen process?

Återigen skärper existensen av open-source rörelsen denna fråga betänkligt - därför att vi har roligt när vi gör det vi gör. Vår kreativa lek har genererat tekniska framgångar, marknadsandelar och allmänkunskap med en förbluffande hastighet. Vi har visat att vi inte bara kan göra bättre mjukvara, utan också att glädjen är en ingrediens.

Två och ett halvt år efter den första versionen av denna essä är den mest radikala tanke jag avslutningsvis kan ge inte längre bara en vision inom den open-source dominerade världen, den ter sig numera rimlig även för många eleganta människor i kostym.

Snarare vill jag föreslå något som kan vara en bredare lektion angående mjukvara, och förmodligen gäller alla sorters kreativt eller professionellt arbete. Människor tar sig an en uppgift med glädje när den befinner sig i en sorts zon av optimal svårighetsgrad. Inte så enkel att den blir tråkig, inte så svår att den blir omöjlig att klara av. En lycklig programmerare är en som varken är understimulerad eller pressad av illa formulerade mål eller friktion i processen. Glädje förebådar effektivitet.

Att se på din egen arbetsprocess med rädsla och avsky (om även på ett distanserat, ironiskt sätt som att hänga upp Dilbertserier) kan därför ses som ett tecken på att processen har misslyckats. Glädje, humor och lekfullhet är förvisso tillgångar. Det var inte bara för att det var en alliteration som jag skrev glada horder (eng. "happy hordes") ovan, och det är inte bara ett skämt att Linux maskot är en gosig och neotenisk pingvin.

Det kan gott visa sig att en av de viktigaste följderna av open-source rörelsens framgångar är att den visar oss att leken är den mest effektiva typen av kreativt arbete.