Slutnoteringar

[JB] I Programming Pearls kommenterar den välkände computer-science aforisten Jon Bentley Brooks observation med "Om du planerar att slänga en, så kommer du att slänga två". Han har nästan säkert rätt. Poängen med Brooks observation, och Bentleys , är inte bara 'att man ska förvänta sig att första försöket är fel', den är också 'att börja om med rätt idé är vanligen bättre än att försöka rädda något som är tilltrasslat'.

[QR] Det har funnits exempel på open-source, eller utveckling enligt basar modellen, före internetexplosionen och orelaterat till Unix. Utveklingen av info-Zip-komprimeringsverktyget omkring 1990-1992 företrädesvis för DOS-maskiner var ett sådant exempel. Ett annat var RBBS bulletin-board-systemet, även detta för DOS, som påbörjades 1983 och satte igång en så stark rörelse att regelbundna utgåvor har kommit ut ända tills nu (mitten 1999) trots den enorma tekniska överlägsenheten hos Internet med dess e-post och fildelning. Medan info-Zip rörelsen delvis var avhängig av Internet e-post, så kunde RBBS utvecklarna skapa en egen on-line kommunitet baserad på RBBS som var helt oberoende av TCP/IP infrastrukturen.

[JH] John Hasler har föreslagit en intressant förklaring till det faktum att 'mångfaldigande av insats' inte tycks vara en bromskloss för open-source utveckling. Han föreslår vad jag kallar 'Haslers Lag': Kostnaden för dubbelarbetet tenderar att skalas upp sub-kvadratiskt med arbetsgruppens storlek - det vill säga långsammare än kostnaden för det planerings- och ledningsarbete som skulle krävas för att eliminera detsamma.

Detta påstående motsäger faktiskt inte Brooks lag. Det kan vara att kostnaden för hantering, komplexitet och sårbarhet för fel växer med kvadraten på arbetsgruppens storlek, men att den kostnaden för dubbelarbetet trots detta är en speciell sak som inte växer lika snabbt.

Det är inte svårt att finna rimliga orsaker till detta. Om man börjar med det otvivelaktiga faktum att det är mycket lättare att göra upp om funktionella gränssnitt mellan olika programmerares kod och sålunda förhindra dubbelarbete, än det är att hindra den sorts oplanerade kopplingar tvärs hela system som ligger bakom flertalet buggar.

Kombinationen av Linus lag och Haslers lag antyder att det finns tre kritiska storleksområden i programmeringsprojekt. Vid små projekt, jag skulle säga en till max tre utvecklare, så behövs ingen ledningsstruktur mer än att utse en ledande programmerare. Och det finns ett sorts mellanområde där kostnaden för traditionell ledning är förhållandevis låg, så fördelarna med att undvika dubbelarbete, feluppföljning och tillsyn att ingenting glöms bort, uppväger kostnaden.

Ovanför detta område, emellertid, så ger kombinationen av Linus lag och Haslers lag att det finns ett område där kostnaden och problemen med traditionell organisation stiger snabbare än kostnaden för dubbelarbetet. Inte minst bland dessa kostnader är oförmågan att mobilisera 'effekten av många ögon' som verkar fungera bättre än traditionell organisation när det gäller att se till att inga fel eller detaljer glöms bort. Sålunda, vid stora projekt, så ger kombinationen av dessa lagar att nettot för traditionell organisation blir noll.

[HBS] Uppsplittringen i experimentella och stabila versioner för Linux har en annan funktion som är relaterad till om än skild från att gardera sig mot risker. Splittringen möter ett annat problem: faran med deadlines. När programmerare skall klara både en oflexibel featurelista och en deadline, åker kvaliteten ut genom fönstret och det blir en kolossal oreda i tillverkningen. Jag är tack skyldig Marco Iansiti och Alan MacCormack från Harvard Business School för att de visade mig på bevis för att om man lättar på endera av dessa krav så kan planering ha en chans att lyckas.

Ett sätt att göra detta är att spika deadline men att låta featurelistan vara flexibel, så att man stryker de delar som inte är färdiga. Detta är strategin för den stabila grenen av Linuxkärnan. Alan Cox (som håller i den stabila grenen) ger utgåvor i ganska regelbundna intervall, men ger inga garantier om när specifika fel kommer att rättas eller när faciliteter från den experimentella kärnan implementeras i den stabila.

Det andra sättet är att spika en önskad featurelista och att inte leverera förrän allt är klart. Detta är väsentligen strategin för den experimentella grenen. De Marco and Lister citerade forskning som visar att denna tidsplaneringspolicy ('väck-mig-när-det-är-klart') inte bara ger den bästa kvaliteten, utan också i medeltal kortare leveranstid än både 'realistisk' och 'aggresiv' tidsplanering.

Jag har kommit att misstänka (tidigt 2000) att de tidigare versionerna av denna essä grovt har underskattat vikten av 'väck-mig-när-det-är-klart' anti-dealine policyn för open-source rörelsens produktivitet och kvalitet. Erfarenhet från den forcerade GNOME 1.0 1999 indikerar att trycket att ge ut ofullgångna utgåvor kan neutralisera en del av de kvalitetsfördelar som open-source normalt sörjer för.

Det kan mycket väl visa sig att den transparens som finns i open-source bara är en av tre likvärdiga drivkrafter till dess kvalitet. De två andra skulle vara 'väck-mig-när-det-är-klart' tidsplanen samt självurvalet bland utvecklarna.

[IN] En sak relaterad till frågan om man kan starta ett projekt från noll i basarstilen är huruvida basarstilen är kapabel att stötta verkligt innovativt arbete. Somliga menar att i avsaknad av starkt ledarskap så kan basarstilen endast ta hand om kloning och förbättring av idéer som redan finns inom ingenjörskonsten, men att den inte är kapabel att driva konsten framåt. Detta argument framhölls på ett infamt sätt av Halloween Documents, två pinsamma interna memoranda som handlade om open-source-fenomenet. Författarna jämförde sambandet mellan Linux och ett Unix-liknande operativsystem med att jaga bakljusen och antydde att "så fort projektet har uppnått paritet med teknikfronten, så kommer den ledningsorganisation som krävs för att flytta fram fronten att bli massiv."

Det finns allvarliga faktafel i denna argumentation. Ett avslöjar sig när Halloween-författarna själva senare konstaterar att "forskningsidéer implementeras ofta i Linux innan de finns tillgängliga på andra plattformar"

Om vi läser open-source i stället för Linux, ser vi att detta långt ifrån är ett nytt fenomen. Tidigare i historien var det inte så att open-source rörelsen uppfann Emacs eller World Wide Web eller självaste Internet genom att jaga bakljus eller att vara hårt organiserat. Och nu för tiden är det så mycket innovativt arbete som pågår inom open-source så att man blir bortskämd av alla val. GNOME-projektet, för att ta ett av många, pressar fronten vad gäller grafiska gränssnitt och objektteknik så hårt att det har väckt stort intresse inom datorpressen långt utanför Linuxrörelsen. Det finns oräkneligt fler exempel. Ett besök på Freshmeat vilken dag som helst bevisar detta.

Men det finns ett mer fundamentalt fel i antagandet att katedral-modellen (eller basar-modellen eller vilken som helst organisationsmodell) på något sätt skulle garantera att innovationer kommer fram. Det är nonsens. Grupper har inte genombrytande insikter. Inte ens frivilliga basar-anarkister är vanligtvis kapabla att skapa genuin originalitet. Än mindre företagskommittéer av människor som har överlevnad och status qou för ögonen. Insikt kommer från individer. Det bästa man kan förvänta sig av deras sociala omgivning är att den är lyhörd för deras genombrytande insikter. Att göda och belöna och grundligt testa dem i stället för att slå dem sönder och samman.

Somliga skulle betrakta detta som en romantisk syn, en tillbakagång till den omoderna stereotypen om den ensamme uppfinnaren. Inte alls. Jag påstår inte att grupper inte kan utveckla banbrytande insikter när de väl kläckts. Vi lär oss från "peer-review" processen att sådana utvecklingsgrupper är väsentliga vad gäller att producera resultat med kvalitet. Jag vill snarare påpeka att varje sådan grupps utvecklingsarbete börjar med - är nödvändigtvis igångsatt av - en bra idé i en persons huvud. Katedraler och basarer och andra sociala strukturer kan fånga upp dessa snilleblixtar och raffinera dem, men de kan inte skapa dem på order.

Därför är grundproblemet med innovationer (inom programvara eller inom vilket område som helst) just hur man undviker att krossa dem. Men, ännu mer fundamentalt, det gäller att få fram skaror av människor, som överhuvudtaget har möjlighet att erhålla insikter.

Tanken att katedral-stilen skulle klara det här tricket, medan basarstilen med sina låga inträdesbarriärer och stora informationsflöden inte skulle kunna det, är absurd. Om det som behövs är en person med en bra idé, och sedan en social omgivning där en person snabbt kan dra till sig samarbete från hundra eller tusen andra med denna idé, kommer oundvikligen denne att konkurrera ut innovatörer som först måste göra ett politiskt säljarbete inför en chefshierarki innan han kan arbeta på sin idé utan risk att få sparken.

Och helt klart, om vi tittar historiskt på de programinnovationer som gjorts av organisationer enligt katedralmodellen, så finner vi snart att dessa är sällsynta. Stora företag beror av universitetsforskning för nya idéer. (Därav Halloween-dokumentförfattarnas ängslan över Linux förmåga att ta till sig denna forskning så snabbt.) Eller köper de upp små företag som är uppbyggda kring en innovatör. I ingendera fallet är innovationen född inom katedralkulturen. Faktum är att många importerade innovationer sakta kvävs under den massiva ledningsstruktur som Halloween-dokumentens författare lovprisar.

Det är emellertid en negativ sak. Läsaren är bättre förtjänt av en positiv synpunkt. Så jag föreslår följande som ett experiment.

1. Välj ut ett kriterium för originalitet som du anser kan användas konsekvent. Om din definition blir "jag känner igen det när jag ser det", så duger det nog i det här testet.
2. Välj ett 'closed-source' operativsystem, vilket som helst, som konkurrerar med Linux, och den bästa källan med information om pågående utvecklingsarbeten.
3. Följ upp denna källa och Freshmeat i en månad. Räkna ihop antalet utgåvor som du anser vara 'originella' arbeten. Använd samma definition på 'original' på annonseringarna för det andra operativsystemet och räkna även dem.
4. Summera dessa listor trettio dagar senare.

Den dag jag skrev detta, var det tjugotvå meddelanden om utgåvor på Freshmeat, varav tre verkade vara banbrytande på ett eller annat sätt. Det var en lat dag på Freshmeat, men jag skulle bli förvånad om någon läsare rapporterar om så många som tre potentiella innovationer på en månad från en 'closed-source' kanal.

[EGCS] Vi känner nu ett projekt, som på många sätt kan ge oss ett bättre test på basar-premissen än fetchmail; EGCS, the Experimental GNU Compiler System.

Detta projekt lanserades i mitten av augusti 1997 som ett medvetet försök att använda idéerna från den tidiga publicerade versionerna av 'Katedralen och basaren'. Instiftarna av projektet menade, att utvecklingen av GCC, GNUs C-kompilator, hade stagnerat. I de följande tjugo månaderna fortsatte GCC och EGCS som parallella projekt -- bägge drog till sig samma grupp av utvecklare på Internet, bägge startade med samma GCC kodbas, bägge använde i stort sett samma Unix-vektyg och utvecklingsmiljö. Projekten skiljde sig endast i att EGCS medvetet försökte att använda basar-taktiken, som jag tidigare beskrivit, medan GCC behöll en mera katedral-liknande organisation med en sluten utvecklargrupp och mer lågfrekventa utgåvor.

Det var väl så nära ett kontrollerat experiment man kunde komma, Och resultaten blev dramatiska. Inom några månader hade EGCS versionen dragit ifrån väsentligt vad gäller innehåll. Bättre optimering, bättre stöd för FORTRAN och C++. Många fann utvecklingsutgåvor av EGCS mer tillförlitliga än de senaste stabila utgåvorna av GCC, och stora Linuxdistributioner började gå över till EGCS.

I april 1999 upplöste Free Software Foundation (den officiella sponsorn för GCC) den ursprungliga GCC-utvecklingsgruppen och överlämnade officiellt ansvaret för projektet till EGCS ledningsgrupp.

[SP] Självklart reser Kropotkins kritik och Linus lag några bredare frågor om teorin för sociala organisationer. Ett annat folkligt teorem om programmeringens ingenjörskonst antyder en av dem; Conways lag -- som normalt lyder 'Om man har fyra grupper, som arbetar på en kompilator, får man en fyrpasskompilator'. Originalformuleringen var mer generell: 'Organisationer, som designar system, är begränsade till att göra konstruktioner som är kopior av kommunikationsstrukturen inom dessa organisationer'. Vi kan uttrycka det mer koncist som: 'Medlen avgör resultatet' eller till och med 'Processen blir till produkt'.

Därför är det värt att konstatera, att organisationsform och funktion i open-source matchar varandra på många plan. Nätverket är allt och finns överallt. Inte bara Internet, utan människorna som gör jobbet formar ett distribuerat, löst kopplat nätverk av jämställda, som tillhandahåller mycket redundans och som åldras med grace. I båda nätverken är den enskilda noden kritisk endast till den grad andra noder vill samarbeta med den.

Granskning gjord av jämställda är en väsentlig orsak till samhällenas förvånansvärt höga produktivitet. Kropotkins poäng om maktrelationer finns vidareutvecklad i "SNAFU-principen". Riktig kommunikation är endast möjlig jämställda emellan, eftersom underordnade blir mer belönade av att säga behagliga lögner till sina överordnade än av att tala sanning. Kreativt arbete är ytterligt beroende av uppriktig kommunikation, och hindras således effektivt av maktrelationer.

Open-source-rörelsen, som är helt fri från sådana relationer, visar per kontrast hur mycket de kostar i form av fel, minskad produktivitet och förlorade möjligheter.

Dessutom förutsäger SNAFU-principen att i auktoritära organisationer bildas en gradvis avskärmning mellan beslutsfattare och verkligheten, eftersom mer och mer av input till beslutsfattare tenderar att bli behagliga lögner. Det sätt som detta verkar inom konventionell programmering är lätt att se. Det finns starka incitament för underordnade att gömma, ignorera och förminska problem. När denna process blir till produkt, blir programvaran en katastrof.