Översättarens kommentarer

Detta är en översättning av Eric S. Raymonds The Cathedral and the Bazaar. Det amerikanska originalet finns på
http://catb.org/~ esr/writings/cathedral-bazaar/.

Baserad på Revision 1.51 24 Augusti 2000 Översättning November 2000

Översättare: <sven.wilhelmssonNOSPAMswipnet.se>

Kommentarer och rättelser till översättningen välkomnas.
Se även ordförklaringar. Tack till alla bidragande!

Permission is granted to copy, distribute and/or modify this document under the terms of the Open Publication License, version 2.0.


Katedralen och basaren

av Eric S. Raymond

Jag analyserar ett framgångsrikt open-source projekt, fetchmail, som medvetet kördes som en test av några överraskande teorier om utveckling av programvara, som kommer från Linux historia. Jag diskuterar dessa teorier utifrån två fundamentalt olika utveklingsmodeller, 'katedral-modellen', som flertalet i den kommersiella världen använder, kontra 'basar-modellen' från Linuxvärlden. Jag visar, att dessa modeller emanerar från motstridiga ansatser om felsökningens natur gällande programvara. Jag ger sedan en underbyggd argumentation för att Linuxerfarenheten "med ett tillräckligt antal ögon blir alla fel ytliga" visar analogi med andra självkorrigerande system av själviska agenter, och avslutar med en utredning om vad denna insikt betyder för programmeringskonstens framtid.


  1. Katedralen och basaren
  2. Posten skall ut
  3. Vikten av att ha användare
  4. Ge ut tidigt, ge ut ofta
  5. När är en ros inte en ros?
  6. Popclient blir till Fetchmail
  7. Fetchmail växer upp
  8. Några fler lektioner från Fetchmail
  9. Nödvändiga förutsättningar för basarmetoden
  10. Open-source's sociala sammanhang
  11. Om ledning och om Maginotlinjen
  12. Tillerkännanden
  13. Vidare läsning
  14. Epilog: Netscape går till basaren
  15. Slutnoteringar

1. Katedralen och basaren

Linux är omstörtande. Vem kunde bara för fem år sedan (1991) tänka att ett operativsystem av världsklass kunde utkristalliseras som av magi genom deltidspulande av några tusen utvecklare utspridda över planeten, sammanflätade enbart av Internets smala trådar.

Absolut inte jag. Vid den tiden då Linux flöt in på min radarskärm i början av 1993, hade jag redan varit involverad i Unix och utveckling av öppen källkod i tio år. Jag var en av de första bidragande till GNU i mitten av 1980-talet. Jag hade givit ut en hel del open-source program på nätet, utvecklat eller deltagit i flera projekt (nethack, VC och debugger-moder till Emacs, xlife med flera) som använts i stor utsträckning. Jag trodde jag visste hur man gjorde sådant.

Linux kullkastade mycket av det jag trodde jag visste. Jag hade predikat Unix evangelium om små verktyg, snabba prototyper och evolutionär programutveckling i flera år. Men jag hade också trott att det fanns en kritisk komplexitet där ett mer centraliserat och grundligt angreppssätt var nödvändigt.

Jag trodde att den viktigaste programvaran (operativsystem och stora verktyg som Emacs) behövde byggas som katedraler, noggrant utformade av individuella mästare och små grupper av vise män som fick arbeta i fred och där inga arbetsutgåvor skulle ges i förtid.

Linus Torvalds utvecklingsmodell - tidiga och frekventa utgåvor, delegera allting du kan, visa öppenhet på gränsen till promiskuitet - kom som en överraskning. Inget tyst och vördnadsfullt katedralbyggande här inte. Snarare tycktes Linuxrörelsen likna en stor babblande basar med varierande utgångspunkter och sätt att närma sig målet (benäget symboliserat av Linux arkivplatser, som accepterar bidrag från vem som helst). Att det ur detta skulle framträda ett sammanhängande och stabilt operativsystem tycktes endast kunna ske genom en serie mirakler.

Det faktum att denna basarstil tycktes fungera, och fungera väl, kom som en chock. Då jag försökte begripa detta, arbetade jag hårt inte bara med egna individuella projekt, utan även med att försöka förstå varför Linuxvärlden inte flög isär i missförstånd, utan verkade göra framsteg med en fart som katedralbyggare knappt kan föreställa sig.

I mitten av 1996 trodde jag att jag började förstå. Turen gav mig ett perfekt sätt att testa min teori med av ett projekt med open-source som jag medvetet skulle försöka driva i basarstilen. Jag gjorde så - och det blev en betydande framgång.

Detta är historien om detta projekt. Jag använder det till att föreslå några aforismer om effektiv utveckling av open-source. Jag lärde mig inte alla dessa inom Linuxvärlden, men vi kommer att se hur Linux ger dem en särskild prägel. Om jag har rätt, kommer de att hjälpa dig att förstå vad som gör Linuxrörelsen till en sådan fontän av god programvara - och kanske hjälper de dig att själv bli mer produktiv.

2. Posten skall ut

Sedan 1993 hade jag haft hand om det tekniska på en liten 'Internet Service Provider' som hette Chester County InterLink (CCIL) i West Chester, Pennsylvania. Jag var med och startade CCIL och skrev vår unika programvara för fleranvändar bulletin-board. Du kan pröva den genom att telnetta till locke.ccil.org (telnet://locke.ccil.org). Numera servar vi nästan tretusen användare på trettio linjer. Jobbet gav mig tillgång till nätet dygnet runt via CCILs 56K linje - ja, egentligen var detta nära nog vad jobbet krävde!

Jag hade blivit tämligen van vid direktsnabb Internet e-post. Jag märkte att det blev besvärande att ständigt var tvungen att telnetta till locke för att se om där fanns e-post. Vad jag behövde var att få e-posten levererad till snark (min egen hemdator) så att jag blev meddelad när den kom och kunde hantera den med mina egna lokala verktyg.

Internets eget e-postbefordrings-protokoll, SMTP (Simple Mail Transfer Protocol), skulle inte passa så bra eftersom det fungerar bäst om maskinerna är fast anslutna till nätet, medan min egen maskin inte alltid är uppkopplad och saknar statisk IP adress. Vad jag behövde var ett program som kunde nyttja min intermittent uppkopplade uppringda förbindelse och hämta hem min e-post och leverera den lokalt. Jag visste, att det fanns sådana saker, och att flertalet av dem använde ett enkelt 'application protocol' som kallades POP (Post Office Protocol). POP har numera stöd hos flertalet vanligt förekommande e-post klienter, men på den tiden fanns det inte inbyggt i den e-post läsare som jag använde.

Jag behövde en POP3 klient. Så jag gick ut på nätet och hittade en. Ja, egentligen fann jag tre eller fyra. Jag använde en ett tag, men den saknade en naturlig finess, nämligen att plocka ut adressen ur hämtad e-post så att ett besvarande fungerade korrekt.

Problemet var följande: antag att någon som hette 'joe' på locke skickade mig ett e-brev. Om jag hämtade brevet på snark och sedan försökte besvara det, skulle mitt program glatt försöka skicka det till en icke existerande 'joe' på snark. Att editera adresserna för hand blev snart nog en pina.

Detta var något som datorn borde göra åt mig. Men ingen av de befintliga POP klienterna kunde! Detta ger oss vår första läxa:

1. Ett gott arbete börjar med att man kliar sin egen klåda.

Kanske skulle detta vara en självklarhet (det har läge sagts "Nödvändigheten är uppfinningarnas moder"), men alltför ofta använder programmerare sina dagar till att fila för sin lön på program som de varken behöver eller gillar. Men icke så i linuxvärlden - vilket kan förklara varför medelkvaliteten på programvara med ursprung i linuxvärlden är så hög.

Så kastade jag mig då in i en yster programmeringsyra för att koda upp en skinande ny POP3 klient för att tävla med de redan befintliga? Aldrig i livet! Jag undersökte noggrant alla de funktioner jag redan hade och frågade mig själv -vilken av dessa ligger närmast det jag vill ha? Därför att

2. Duktiga programmerare vet vilken kod som behöver skrivas. De framstående vet vad som finns att återanvända.

Jag låtsas inte att vara en framstående programmerare, men jag försöker imitera en sådan. Ett väsentligt drag hos de riktigt stora är konstruktiv lättja. De vet, att man inte får högsta betyg bara för att man anstränger sig, utan därför att man når ett bra resultat. Och att det är nästan alltid lättare att börja från ett gott ämne än från ingenting alls.

Linus Torvalds (http://catb.org/~esr/faqs/linus) till exempel, började inte med att skriva Linux från noll. Nej, han började med att återanvända kod och idéer från Minix, ett litet Unixliknande operativsystem för PC kloner. Så småningom blev all kod från Minix ersatt eller totalt omgjord, men medan den fanns där var den som en byggnadsställning för det som senare skulle bli Linux.

I samma anda letade jag efter en befintlig POP programvara som var någorlunda väl kodad, för att användas som en utvecklingsplattform.

Traditionen inom Unix-världen är att dela med sig av källkod och att vara välvillig till återvinning av kod (det är skälet till att GNU-projektet har valt Unix som sin plattform, trots reservationer om operativsystemet som sådant). Linuxvärlden har dragit denna tradition till sin gräns; den har terabyte av öppen källkod tillgänglig för envar. Så att använda tid till att leta upp någon annans nästan-tillräckligt-bra-kod ger sannolikt bättre resultat i Linuxvärlden än någon annanstans.

Det gjorde det för mig. Tillsammans med de jag redan hade funnit, gav min andra sökning nio kandidater - fetchpop, PopTart, get-mail, gwpop, pimp, pop-perl, popc, popmail och upop. Den som jag först fastnade för var fetchpop av Seung-Hong Oh. Jag lade in en 'header-rewrite' funktion i programmet, och gjorde en del andra förbättringar som dess författare accepterade i sin 1.9 utgåva.

Ett par veckor senare snubblade jag över koden för 'popclient' av Carl Harris, och såg att jag hade ett problem. Även om fetchpop hade en hel del originella tankar inbyggda (som dess möjlighet att köra som demon i bakgrunden), kunde den endast hantera POP3 och var ganska amatörmässigt kodad. (Seung-Hong var vid det laget en klipsk men oerfaren programmerare, och båda dessa drag syntes.) Carls kod var bättre, professionell och solid, men hans program saknade en del viktiga funktioner som fanns i fetchpop och som var ganska svåra att implementera (inklusive de jag hade kodat själv).

Stanna eller byta? Om jag bytte skulle jag slänga bort det kodningsarbete jag redan hade gjort i utbyte mot en bättre bas för den framtida utvecklingen.

Ett skäl att byta var att det fanns stöd för flera protokoll. POP3 var det vanligast förekommande bland protokoll för e-postservrar, med inte det enda. Fetchpop och de övriga konkurrenterna hanterade inte POP2, RPOP eller APOP, och jag hade redan en förhoppning om att kunna lägga till IMAP (http://www.imap.org) (Internet Message Access Protocol, det senaste och mest kapabla bland e-post protokoll), mest på skoj.

Men jag hade också en mer teoretisk anledning till ett byte, något jag hade lärt mig långt tidigare än Linux.

3. "Planera för att kasta en; det kommer du ändå att göra." (Fred Brooks, "The Mythical Man-Month", kapitel 11).

Eller, för att säga det på ett annat sätt, man förstår oftast inte riktigt problemet förrän man först har fått till en lösning. Andra gången kanske man vet tillräckligt för att göra det rätt. Så om man vill ha det rätt, måste man vara beredd på att börja om från början minst en gång [JB].

Så jag intalade mig att ändringarna i fetchpop var mitt första försök. Och så bytte jag.

Efter att jag skickat iväg min första sändning patchar till Carl Harris den 25 Juni 1996, fick jag veta att han hade tappat intresset för popclient vid det laget. Koden var en smula dammig, med vissa mindre buggar som hängde kvar. Jag ville göra många ändringar och vi kom snart överens om att det mest logiska var att jag tog över programmet. Utan att jag riktigt hade märkt det, så hade mitt projekt trappats upp. Nu grubblade jag inte bara på små patchar till en befintlig POP klient. Jag hade fått ansvaret för att underhålla en hel sådan, och jag hade idéer bubblande i skallen som jag kände skulle leda till väsentliga förändringar.

I en programmerarkultur som uppmuntrar till att man delar med sig av kod, är detta ett naturligt sätt för ett projekt att utvecklas. Jag tillämpade följande princip:

4. Har du rätt attityd, kommer intressanta problem att hitta dig.

Men Carl Harris attityd var väl så viktig. Han förstod att

5. Om man tappar intresset för ett program, så är ens sista plikt att lämna över det till en kompetent efterföljare.

Utan att ens behöva diskutera saken, visste både Carl och jag att det var ett mål för oss båda att den bästa lösningen skulle finnas därute på nätet.

Frågan var bara om jag kunde övertyga honom om att mina två händer var säkra händer. När jag väl hade lyckats med det, agerade han snabbt och med heder. --- Jag hoppas att även jag kommer att göra så i min tur.

3. Vikten av att ha användare

På det sättet ärvde jag popclient. Och väl så väsentligt, jag ärvde popclients användarbas. Användare är fantastisk att ha, inte bara för att visa att man tillfredsställer ett behov och att man har gjort någonting rätt. Rätt behandlade blir de också ens medutvecklare.

Ytterligare en kraft i Unix-traditionen, som i Linux drivs till en lycklig extrem, är att även många användare är hackare. Och eftersom källkod är tillgänglig kan de dessutom bli konstruktiva hackare. Detta kan vara enormt användbart för att förkorta tiden för avlusning. Får de bara en litet stycke uppmuntran, kommer ens användare att diagnostisera problem, föreslå rättelser och hjälpa till med att förbättra koden betydligt snabbare än vad som vore möjligt utan denna hjälp.

6. Att behandla sina användare som medutvecklare är den snabbaste vägen till kodförädling och effektiv avlusning.

Kraften i detta är lätt att underskatta. Ja, faktum är att nästa alla inom 'the-open-source-world' drastiskt har underskattat hur bra den skalar upp med antalet användare och hur den möter ökad systemkomplexitet, till dess att Linus Torvalds visade oss.

Jag tror att Linus klipskaste och mest betydelsefulla hack inte var byggandet av själva Linuxkärnan, utan snarare införandet av Linux utvecklingsmodell. När jag uttryckte denna åsikt i hans närvaro, log han och upprepade något som han ofta har sagt: "I grunden är jag en latmask som gillar att få beröm för saker som andra har gjort." Lat som en räv. Eller som Robert Heinlein berömda karakterestik över en av sina figurer: för lat för att misslyckas.

Tittar man tillbaka ser man en föregångare till Linux framgångsrika utvecklingsmodell i utvecklingen av GNU Emacs Lisp Library och Lisps kodarkiv. I motsats till den katedralbyggarstil som gällde för Emacs C-kärna och flertalet andra GNU verktyg, så var utvecklingen av Lisps kodpool mycket flytande och användardriven. Idéer och prototyper skrevs om tre eller fyra gånger innan de fann sin slutliga form. Och löst hopknutna samarbeten möjliggjorda av Internet var inte ovanliga.

Ja, faktisk, mitt eget mest framgångsrika enskilda hack innan fetchmail var förmodligen Emacs VC (version control) mod, ett Linuxliknande samarbete via e-post med tre andra personer, varav jag till dags dato fysiskt träffat bara en (Richard Stallman, författaren till Emacs och grundare av Free Software Foundation (http://www.fsf.org)) Det var en 'front-end' till SCCS, RCS och senare CVS där man inifrån Emacs kan göra tryck-på-knappen operationer för versionshantering. Den utvecklades från den lilla enkla sccs.el mod som någon hade skrivit. Och utvecklingen av VC lyckades tack vare att Emacs Lisp kod, till skillnad från Emacs själv, kunde gå igenom cykler av utgivning/provning/förbättring mycket snabbt.

4. Ge ut tidigt. Ge ut ofta.

Tidiga och frekventa utgåvor är en kritisk del i Linux utvecklingsmodell. De flesta utvecklare (jag med) trodde att detta var en dålig princip för större projekt än trivialt små. Detta eftersom tidiga versioner nästan per definition är behäftade med fel, och man ju inte vill fresta på användarnas tålamod. Detta tänkesätt befäste en allmän anslutning till katedralbyggarstilen. Om det överskuggande målet är att användarna skall se så få buggar som möjligt, då ger man ut en ny version var sjätte månad eller så och sliter som en hund inför utgåvorna. Emacs C kärna utvecklade på detta sätt. Men inte Lisp biblioteket, eftersom det fanns aktiva Lisp arkiv utanför FSFs kontroll, där man kunde hitta nyutvecklad kod oberoende av Emacs utgåvocykler. [QR].

Det viktigaste av dessa, 'the Ohio State elisp archive', föregrep andan och många av egenheterna i dagens stora Linuxarkiv. Men inte många av oss tänkte då så mycket på detta och på att blotta existensen av dessa arkiv antydde problem med FSFs katedralbyggarstil till utvecklingsmodell.

Jag försökte omkring 1992 få en stor del av Ohio-koden formellt inkorporerad i Emacs officiella Lisp biblioteket. Men jag stötte på svårigheter av politisk natur och misslyckades.

Ett år senare, när Linux började synas lite varstans, stod det klart att något annat och med större livskraft pågick därute. Linus öppna utvecklingsfilosofi var något helt annorlunda än katedralbyggande. Linux internetarkiv började blomma ut, många distributioner flöt omkring. Och allt detta drevs med en utgåvofrekvens som ingen dittills ens hade hört talas om.

Linus behandlade sina användare som medutvecklare på bästa tänkbara sätt.

7. Ge ut tidigt. Ge ut ofta. Och lyssna till dina kunder.

Linus innovation var kanske inte så mycket att göra snabba utgåvecykler och att ta till sig återkoppling från användarna, (sådant hade länge varit tradition inom Unix-världen), men att skala detta till en intensitetsnivå som matchade komplexiteten i det som han utvecklade. I början, omkring 1991, var det inte otänkbart för honom att ge ut en ny linuxkärna mer än en gång om dagen! Eftersom han gödde sin bas av medutvecklare och utnyttjade Internets kommunikationspotential till gränsen, så fungerade detta.

Men hur fungerade det? Och var det något jag kunde ta efter, eller berodde det på någon unik begåvning hos Linus Torvalds?

Jag trodde inte det. Det skall erkännas att Linus är en suverän hackare. Hur många av oss skulle kunna konstruera ett helt operativsystem med produktions-kvalitet utifrån nästan ingenting? Men Linux var inget jättekliv framåt vad avser fundamentalt nytänkande. Linus är inte (eller, inte ännu) ett innovativt geni på samma sätt som t.ex. Richard Stallman eller James Gosling (för NeWS och Java) är. Snarare verkar Linus mer vara genialisk i konsten att implementera, med ett sjätte sinne för att undvika buggar och återvändsgränder, och med speciell förmåga att hitta lättaste vägen mellan A och B. Ja, faktiskt, hela Linux konstruktion andas denna egenskap och avspeglar Linus konservativa och förenklande sätt att konstruera.

Så om snabb utgivning och utnyttjande av Internet till det yttersta inte var tillfälligheter utan var väsentliga delar av Linus ingenjörsmässiga insikt om den lättaste vägen, vad var det som han lyckades maximera? Vad var det som han vevade fram ur maskineriet?

Med frågan så ställd, besvarar den sig själv. Linus höll sina hackare/användare ständigt stimulerade och belönade - stimulerade av känslan att vara delaktiga, belönade av att deras arbete ledde framåt. Linus kunde på så sätt maximera antalet mantimmar som ägnades åt avlusning och utvecklingsarbete, även om det skedde med risk för instabil kod och att användarna brände ut sig om någon allvarlig felaktighet skulle visa sig vara omöjlig att rätta till. Linus betedde sig som om han trodde så här:

8. Med tillräckligt många betatestare och medutvecklare blir varje problem kvickt identifierat och dess lösning blir alltid självklar för någon.

Eller med andra ord:

"Med tillräckligt många ögon, blir alla buggar synliga" Jag dubbar detta till "Linus Lag".

Min ursprungliga formulering av detta var att varje problem "kommer att vara uppenbart för någon". Linus invände att den person som förstår och löser problemet inte nödvändigtvis, ja till och med inte vanligtvis, är den person som först formulerar det. "någon hittar problemet," säger han, "och någon annan förtår det. Och jag blir bemärkt för att säga att hitta det är den stora utmaningen." Men grejen är den att båda sakerna tenderar att ske snabbt.

Här har vi, tänker jag, kärnpunkten som skiljer katetralbyggar- och basarmodellen. I katedralbyggarens syn på programmering är buggar knepiga, lömska och djupa fenomen. Det tar månader av granskning av ett antal utvalda kvalificerade experter för att man skall känna tilltro till att alla fel är borta. Alltså långa intervall mellan utgåvorna och en oundviklig besvikelse när det visar sig att den länge efterlängtade utgåvan trots allt inte är perfekt.

Basarmodellens utgångspunkt, å andra sidan, är den att buggar och fel är ytliga fenomen - eller, åtminstone, att de kvickt blir ytliga när de exponeras inför tusentals ivriga medutvecklare som hänger på låset inför varje ny utgåva. Följaktligen ger man ut ofta i syfte att få många korrigeringar, och som sidoeffekt så har man inte så mycket att förlora även om det skulle hända att ett och annat klantverk smiter ut.

Och det är grejen. Det räcker. Om "Linus lag" är fel, så skulle varje system så komplicerat, och där så många fingrar har petat, som Linuxkärnan, vid något tillfälle ha kollapsat under trycket av oförutsedda dåliga kopplingar och oupptäckta "djupa" fel. Om det är sant, å andra sidan, kan det förklara Linux relativa frihet från buggar och dess tillförlitlighet med månader och år mellan haverierna.

Men det kanske inte är någon stor överraskning. Sociologer har sedan länge observerat att medelvärdet av uppfattningen hos ett stort antal observatörer av lika expertis (eller lika okunniga) är bra mycket mer tillförlitligt än uppfattningen hos en enda slumpvis utvald observatör. De kallar detta för "Delphi effekten". Det verkar som om Linus har visat att detta är tillämpligt även då det gäller att avlusa ett operativsystem. Att Delphi effekten kan tämja komplexiteten på den nivå som utvecklingen av kärnan i ett operativsystem kräver.

En speciell egenhet i Linuxfallet som klart hjälper upp situationen vid sidan om Delphieffekten är att de som deltar i ett givet projekt själva väljer att deltaga. Bidragen kommer inte från slumpvist utvalda människor, utan från sådana som är tillräckligt intresserade för att använda programvaran, lära sig hur den fungerar, försöka hitta svar på problem de stöter på och att i praktiken få fram en rimlig lösning. En som passerar alla dessa filter har sannolikt möjlighet att bidra med något användbart.

Jag är tack skyldig min vän Jeff Dutky (dutky@wam.umd.edu) för hans påpekande att Linus lag kan formuleras: "Avlusning är parallelliserbart". Jeff noterar, att även om avlusningsarbetet kräver att deltagarna kommunicerar med en koordinator, så krävs ingen omfattande kommunikation mellan deltagarna. De blir alltså inte offer för någon kvadratisk komplexitets- och ledningskostnad, som eljest kan göra det problematiskt att lägga till fler medutvecklare.

Den teoretiska effektivitetsförlusten med att avlusningsarbetet dubbleras tycks i praktiken inte vara något problem i Linuxvärlden. En konsekvens av 'ge-ut-tidigt-och-ofta-metoden' är att dubbelarbetet minimeras genom att rättade buggar återkopplas snabbt [JH].

Även Brooks (författaren till "The Mythical Man-Month") gjorde en iakttagelse av samma slag som Jeffs. "Kostnaden att underhålla ett program med stor spridning är typiskt 40 procent eller mer av utvecklingskostnaden." Märkvärdigt nog påverkas den starkt av antalet användare. "Fler användare hittar fler fel."

Fler användare hittar fler buggar därför att fler användare betyder fler sätt att belasta programmet. Detta gäller speciellt om användarna är medutvecklare. Var och en närmar sig problemet med sitt eget annorlunda sätt att tänka och med sina egna verktyg. Han får sitt eget perspektiv på problemet. "Delphi effekten" verkar fungera med precision just på grund av denna variation. När det gäller att avlusa program tenderar denna variation kompensera den förlust som orsakas av dubbelarbete.

Så att lägga till fler betatestare måhända inte minskar svårighetsgraden i den knepigaste buggen som utvecklaren ser den, men det ökar sannolikheten att någons verktyg råkar stämma med problemet och att felet på så sätt blir enkelt just för honom.

Men Linus garderar sig också. Skulle det hända att det finns allvarliga fel, så är Linuxkärnans versioner numrerade så att användaren kan välja om han vill använda den senaste stabila versionen, eller om han vill köra en utvecklingsversion på frontlinjen och riskera att stöta på problem med nya finesser. Denna taktik används ännu inte av alla Linux hackare, även om de kanske borde göra det. Det faktum att båda möjligheterna finns gör dem också båda mer attraktiva [HBS].

5. När är en ros inte en ros?

Efter att ha studerat hur Linus har gått till väga och efter att ha funderat ut en teori om varför hans metod blev så framgångsrik, beslutade jag mig för att pröva teorin på ett nytt, låt vara betydligt mindre komplicerat och mindre ambitiöst, projekt.

Men först ville jag omorganisera och förenkla popclient en hel del. Carl Harris utformning var sund, men visade den sorts onödiga komplexitet som är vanligt förekommande hos många C programmerare. Han betraktade koden som central och datastrukturerna som ett bihang. Resultatet var att koden blev vacker, men att datastrukturerna var ad-hoc och ganska eländiga. I varje fall jämfört med den höga standarden hos denne gamle LISPhackare.

Jag hade emellertid också en annan avsikt med att skriva om programmet förutom att förbättra koden och datastrukturerna. Det var att ändra det till något som jag förstod fullt ut. Det är inte roligt att ha ansvar för, och att rätta fel i, ett program som man inte förstår.

Så de första månaderna följde jag helt Carls grundläggande konstruktion. Den första större förändring jag gjorde var att lägga till stöd för IMAP. Jag gjorde detta genom att göra om protokollmaskinerna till en generisk drivrutin med tre metodtabeller (för POP2,POP3 och IMAP) Detta och de tidigare ändringarna illustrerar en generell princip för bra programmering att ha i minnet. i synnerhet i ett språk som C som inte på ett naturligt sätt har stöd för dynamisk programmering:

9. Smarta datastrukturer och dum kod fungerar bättre än tvärtom.

Brooks, kapitel 9: "Visa mig din [kod] och göm dina [datastrukturer], och jag kommer att vara förbryllad alltjämt. Visa dina datastrukturer och jag behöver inte se din [kod], den kommer att var självklar."

Egentligen sade han "flödesschema" och "tabeller". Men med ett trettio år senare språkbruk så är det samma andemening.

Vid denna tidpunkt (tidigt i september 1996, sex veckor från noll) började jag tänka att ett namnbyte skulle lämpa sig. Det var ju inte bara en POP klient längre. Men jag tvekade, för det var ju inte något genuint nytt i konstruktionen. Min version av popclient hade ännu inte någon egen identitet.

Detta ändrades radikalt när fetchmail lärde sig att leverera e-post till en SMTP port. Jag kommer strax till detta. Men först: Jag sade ovan att jag hade beslutat använda detta projekt för att pröva min teori om hur Linus Torvalds hade lyckats. Hur gjorde jag det? På följande sätt:

  1. Jag gav ut tidigt och ofta. Nästan aldrig mindre än var tionde dag och under intensiva perioder dagligen.
  2. Jag lät min lista av betatestare växa och lade till alla som kontaktade mig om fetchmail.
  3. Jag annonserade i betatestlistan inför varje utgåva, och uppmanade folk att delta.
  4. Och jag lyssnade på mina betatestare, frågade om råd om utformningen och strök dem medhårs närhelst de sände in patchar och gav återkoppling.

Dessa enkla åtgärder lönades omedelbart. Från första början fick jag felrapporter av en kvalitet som de flesta utvecklare knappt kan drömma om, ofta med bra lösningar medskickade. Jag fick genomtänkt kritik, beundrarpost och insiktsfulla råd om nya faciliteter.

Vilket leder till:

10. Om man behandlar sina betatestare som ens mest värdefulla tillgång, besvaras detta med att de blir ens mest värdefulla tillgång.

Ett intressant mått på fetchmails framgång är projektets lista av betatestare. Fetchmail-vännerna. Vid tiden för den senaste revisionen, (Augusti 2000) var den 249 och den växte med två eller tre i veckan.

Faktiskt, som jag minns det från Maj 1997 så började listan förlora medlemmar från sin höjdpunkt på nära 300 av ett intressant skäl. Några personer bad att bli avskrivna eftersom de tyckte att fetchmail fungerade så bra att de inte längre behövde följa listan! Detta är kanske en normalt sätt att mogna för ett projekt i basarstilen.

6. Popclient blir till Fetchmail.

Den stora vändpunkten i projektet var när Harry Hochheiser skickade mig sin kod för att befordra e-post till klientmaskinens SMTP-port. Jag förstod nästan med en gång att en tillförlitlig implementering av denna finess skulle göra övriga befordringssätt nära nog överspelade.

I flera veckor hade jag ältat fetchmail i små steg och det kändes som om gränssnittets utformning var hanterbart men kletigt. Klumpig med alltför många betydelselösa möjligheter som hängde med. Möjligheten att dumpa hämtad e-post till en postboxfil eller till standard output grämde mig utan att jag riktigt förstod varför.

(Om du inte bryr dig om teknikaliteter om Internetburen e-post, är det riskfritt att hoppa över följande två stycken)

Det jag insåg när jag tänkte igenom SMTP-postbefordran var att popclient försökte göra alltför många saker. Den hade blivit konstruerad för att bli både en "mail transport agent (MTA)" och en "local delivery agent (MDA)". Med "SMTP forwarding", så kunde den lämna MDA sidan och bli enbart MTA, och lämna över till andra program att göra lokal utdelning såsom sendmail gör.

Så varför krångla till det med att konfigurera en "mail-delivery- agent" eller att sätta upp "lock-and-append" på en brevlåda när port 25 nästan säkert finns på varje plattform med TCP/IP stöd överhuvud taget? Speciellt som detta betyder att emottagen e-post redan garanterat ser ut som normal avsändarinitierad SMTP mail, vilket är vad vi vill ha i vilket fall.

(tillbaka till den högre nivån...)

Även om du inte hängde med i ovanstående tekniska jargong, så finns det flera viktiga läxor här. Först, idén med "SMTP-forwarding" var det största enskilda återbäring jag fick genom att efterlikna Linus metod. En användare gav mig denna fantastiska idé - allt som behövdes var att inse dess följder.

11. Det näst bästa efter att ha goda idéer är är att känna igen goda idéer från användarna. Ibland är det senare bättre.

Intressant nog så märker man att om man är självrannsakande och helt uppriktig om hur mycket man är skyldig andra, så kommer världen i stort ändå att behandla en som om man har gjort alla uppfinningar själv och att man bara visar blygsamhet om sin genialitet. Vi kan alla se hur bra detta fungerade för Linus!

(När jag talade på Perl konferensen i augusti 1997, satt hacker-extraordinaire Larry Wall på främsta raden. När jag kom till slutet i stycket ovan skrek han ut i närmast religiös hänförelse: "tala ut, tala ut, broder!". Hela auditoriet skrattade, de visste att detta hade fungerat även för Perls upphovsman.)

Efter att ha kört projektet några veckor i denna anda, började jag själv få liknande lovprisningar inte bara från användare utan även från andra som hade fått nys om saken. Jag gömde undan en del av denna e-post, så jag kan ta fram den någon gång om jag börjar fundera även om huruvida mitt liv har varit meningsfullt :-).

Men här finns två ännu mer fundamentala, ickepolitiska lärospån som är giltiga i alla sorters designarbeten.

12. Ofta kommer de mest slående och innovativa lösningarna ur insikten om att ens föreställning om problemet har varit felaktig.

Jag hade försökt lösa fel problem genom att hålla på att utveckla popclient som en kombinerad MTA/MDA med alla sorters leveransmoder. Fetchmails design behövde tänkas igenom från grunden som en ren MTA, som en del av den normala SMTP-talande sättet för e-post på Internet.

När man har gått väggen i utvecklingsarbetet - när man märker att man inte kan tänka bortom nästa patch - då är det dags att fråga sig, inte om man har rätt svar, men om man ställer sig rätt fråga. Problemet kanske måste formuleras om.

Ja, jag ställde om mitt problem. Det stod klart att det gällde att (1) hacka in SMTP stöd i den generiska drivrutinen, (2) att göra det till förvald mod, och (3) avslutningsvis slänga ut alla andra moder, i synnerhet skriv-på-fil och skriv-på-standard-output optionerna.

Jag tvekade vad det gällde steg 3 en tid, av rädsla att det skulle ställa till det för användare som länge använt popclient och som var beroende av dessa alternativ. Teoretiskt skulle de omedelbart kunna byta till .forward filer i sina icke-sendmail ekvivalenter för att få samma effekt. I praktiken skulle kanske övergången bli besvärlig.

Men när jag gjorde det så visade sig fördelarna vara kolossala. De knepigaste delarna av driver-koden försvann. Konfigurationen blev betydligt enklare - inget mer harvande med MDA och users mailbox. Inga mer bekymmer om huruvida det underliggande operativsystemet stödde fillåsning.

Det enda sättet att förlora e-post försvann. Om man begärde leverans till fil och disken blev full, så försvann e-posten. Detta kan inte ske med SMTP forwarding eftersom SMTP lyssnaren inte kommer att kvittera OK om inte meddelandet kan levereras eller åtminstone 'spoolas' för senare leverans.

Det gick också snabbare (även om man inte märkte det vid ett enstaka tillfälle). En annan icke obetydlig fördel var att manualen blev mycket enklare.

Senare blev jag tvungen att sätta tillbaka möjligheten att leverera via en användarspecificerad lokal MDA, för att kunna hantera en del obskyra situationer med dynamisk SLIP. Men jag kom på ett betydligt enklare sätt att göra detta.

Sensmoralen? Tveka inte att slänga bort utrangerade funktioner som man kan undvara utan att förlora i effektivitet. Antoine de Saint-Exupéry (som var pilot och flygplanskonstruktör när han inte skrev barnböcker) sade:

13. "Fulländning (i utförande) har man inte uppnått då inget mer finns att lägga till, utan snarare när det inte längre finns något att ta bort."

När ens kod blir såväl bättre som enklare, det är då man vet att den är rätt. Det var i den processen som fetchmail förvärvade en egen identitet som skilde sig från föregångaren popclient.

Tiden för namnbyte var inne. Det nya utförandet såg mer ut som en motsvarighet till sendmail än sin föregångare popclient. Båda är MTAer, men sendmail transporterar bort först och levererar sedan, medan den nya popclienten transporterar hem först och levererar sedan.

Så efter två månaders avvaktan ändrade jag namnet till fetchmail.

Det finns en mer allmän lektion i den här historien om hur SMTP blev till fetchmail. Det är inte bara att avlusning kan göras parallellt; även utvecklingsarbetet och (kanske i förvånande grad) utforskningen av designrummet. När ens utvecklingsstil är snabbt iterativ, så kan utveckling och utvidgning bli till specialfall av avlusning. Att rätta 'utelämningsfel' i programmets ursprungliga funktionalitet eller dess ursprungsidé.

Även på en högre nivå i designarbetet kan det vara värdefullt att ha tänkande från en mängd medutvecklare som går slumpvis igenom designrummet för produkten. Tänk på hur en vattenpöl hittar sin dränering, eller hur myrorna hittar mat: utforskning väsentligen genom diffusion följd av bearbetning förmedlad av en skalbar kommunikationsmekanism. Detta fungerar mycket bra, som mellan Harry Hochheiser och mig. Det kan mycket väl hända att en av ens spejare hittar ett stort och vinstgivande fynd som man själv är för närsynt för att se.

7. Fetchmail växer upp.

Där satt jag med en nätt och innovativ design. Kod som jag visste fungerade bra eftersom jag använde den var dag, och en svällande betatestarlista. Det uppdagades gradvis för mig att jag inte längre höll på med ett litet trivialt hack som möjligen kunde vara användbart för andra. Jag ansvarade för ett program som varenda hackare med en Unixlåda och en SLIP/PPP uppkoppling verkligen behövde.

Med 'SMTP forwarding feature', drog den ifrån konkurrenterna tillräckligt mycket för att bli en "kategori killer", ett ev de klassiska program som fyller sin nisch så totalt att alternativen inte bara läggs undan utan nära nog glöms bort.

Jag tror inte att man kan planera för ett sådant resultat. Man får dras in i det av idéer som är så klara att det efteråt framstår som att de är oundvikliga, naturliga och förutbestämda. Det enda sättet att söka efter sådana idéer är att ha många idéer - eller att ha förmågan att bedöma andras goda idéer och att ta dem längre än vad upphovsmannen trodde var möjligt.

Andy Tanenbaum fick den originella idén att bygga ett enkelt UNIX för IBM PC, för att använda som ett undervisningshjälpmedel (Han kallade det för Minix). Linus Torvalds förde konceptet längre än vad Andy troligen trodde att det skulle komma - och det växte ut till någonting fantastiskt. På liknande sätt, fast i mindre skala, tog jag idéer från Carl Harris och Harry Hochheiser och pressade dem framåt. Ingen av oss var 'originella' på det romantiska sätt som folk betraktar genier. Men vetenskap, teknik och programutveckling görs inte av originella genier, hackermytologin till trots.

Men resultaten var i vilket fall rätt häftiga - ja, just den sorts framgång varje hackare lever för! Och det betyder att jag måste sätta mina ribbor ännu högre. För att göra fetchmail så bra som jag  såg att det nu skulle kunna bli, behövde jag skriva inte bara för mina egna behov, utan också inkludera och underhålla inslag som andra utanför min egen krets behövde. Och att göra detta och samtidigt hålla programmet enkelt och robust.

Det första och absolut viktigaste inslag jag skrev efter att ha insett detta var "multidrop support" - dvs förmågan att hämta e-post från e-brevlådor som hade ackumulerat all e-post från en grupp användare, och sedan sända varje e-brev till dess egen adressat.

Jag beslutade att lägga till "multidrop support" delvis därför att en del användare ropade efter det, men mest för att jag tänkte att det skulle skaka fram buggar ur "single-drop" koden genom att tvinga mig att hantera adressering i full generalitet. Och så visade det sig vara. Att få RFC822 (http://info.internet.isi.edu:80/in-notes/rfc/files/rfc822.txt) 'adress parsing' rätt tog mig anmärkningsvärt lång tid. Inte för att någon del är särskilt svår, utan därför att det innehöll en hel hög av suddiga detaljer som var ömsesidigt beroende. Men "multidrop adressing" visade sig vara en "excellent design decision" det också.

Därför att jag vet att

14. Varje verktyg skall vara användbart för sitt ändamål, med de verkligt fina låter sig användas till oanade områden.

Den oväntade användningen av "multi-drop fetchmail" är att köra e-post-listor , och en aliasexpansion gjord på klientsidan av Internet.

Detta betyder att en som kör en persondator med ett ISP-abonnemang kan administrera en e-postlista utan att kontinuerligt ha tillgång till ISPns aliasfiler.

En annan viktig skillnad som betatestarna krävde, var stöd för 8-bitars MIME (Multipurpose Internet Mail Extensions). Detta var ganska lätt att göra eftersom jag hela tiden hade varit noga med att hålla mig till 8 bitar i programkoden. Inte för att jag trott att det skulle finnas efterfrågan på 8-bitars MIME, utan snarare för att hålla mig till en annan regel:

15. När man skriver "gateway software" av något slag, skall man anstränga sig att störa dataströmmen så lite som möjligt - och att aldrig kasta bort information såvida man inte tvingas därtill av mottagaren!

Om jag inte hade följt denna regeln, så hade 8-bitars MIME-stöd varit besvärligt och felbehäftat. Som det nu var, behövde jag bara läsa MIME standarden (RFC 1652 (http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1652.txt)) och lägga till lite trivial "header-generation logic". (Programdelar för att generera brevhuvuden)

Några europeiska användare lurade mig till att lägga in en valmöjlighet att begränsa antalet e-brev per session (så att de kunde ha kontroll på kostnaden för sina dyra telefonförbindelser). Jag stod emot detta länge, och jag är fortfarande inte så glad för det. Men om man skriver för världen så får man lyssna till sina kunder - detta gäller även om de inte betalar med pengar.

7. Några fler lektioner från fetchmail

Innan vi går tillbaka till allmänna frågor om programvaruutformning, så finns ett par specifika läxor från erfarenheten med fetchmail att fundera över. Icke tekniskt intresserade läsare kan hoppa över detta stycke.

Initieringsfilens (rc-filens) syntax inkluderar "optional noise" nyckelord som ignoreras av parsern. Den engelsk-liknande syntaxen som dessa tillåter gör texten avsevärt mer läsbar än den traditionella och korta 'nyckelord-värde par' text som man får om man stryker dem.

Detta började med sena kvällsexperiment när jag märkte hur rc-filens deklarationer började likna ett imperativt minispråk. (Det är också orsaken till att jag ändrade popclients ursprungliga nyckelord 'server' till 'poll').

Jag föreställde mig att om jag kunde göra detta imperativa minispråk mer likt engelska skulle det kanske bli lättare att använda. Men, även om jag är anhängare till gör-det-till-ett-språk skolan inom programkonstruktion som till exempel Emacs och HRML och många databas motorer, så är jag vanligtvis ingen anhängare till 'English-like' syntax.

Traditionella programmerare har tenderat att föredra syntaxer som är precisa och kompakta och helt saknar redundans. Detta är ett arv från den tiden då datorns resurser var dyra, så att 'parsing'-steget skulle vara så enkelt och billigt som möjligt. Engelskan, som har 50% redundans, tycktes då inte alls vara någon lämplig förlaga.

Detta är inte mitt skäl för att undvika engelskliknande syntaxer: Jag nämner det bara här för att krossa den idéen. Med billiga klockcykler och minne, bör inte litenhet vara ett mål i sig. Numera är det viktigare att ett språk är bekvämt för människan än billigt med avseende på datorns resurser.

Det återstår emellertid goda skäl att tänka sig för. Ett är komplexitetskostnaden för parsersteget - man vill inte dra det till en nivå där det i sig själv är en källa till fel och förvirring bland användarna. Ett annat skäl är att om man försöker göra syntaxen för språket engelskliknande blir det i praktiken så att den "engelska" datorn talar blir så allvarligt deformerad att den ytliga likheten med det naturliga språket blir lika förvirrande som en traditionell syntax skulle ha blivit. (Man kan se denna effekt i många så kallade "fjärde generationens-" kommersiella språk för sökning i databaser.)

Styrspråkets syntax i fetchmail tycks undgå dessa problem eftersom språkets domän är extremt begränsad. Det är långt ifrån ett språk med allmän tillämpning; de saker det uttrycker är inte särskilt komplicerade, så det finns inte så mycket utrymme för förvirring i att gå mentalt mellan en liten delmängd av naturlig engelska till ett styrspråk. Jag tror det kan finnas en sensmoral här:

16 När ens språk är långt ifrån fullständigt (Turing-komplett) kan syntaktiskt socker (syntactic sugar) vara till hjälp.

En annan läxa är den om 'säkerhet genom oklarhet' (security by obscurity). En del användare bad mig ändra programmet så att lösenordet skulle sparas i krypterad form i rc-filen, så att snokare inte skulle komma att se dem. Jag gjorde inte det, därför att det inte ger något extra skydd. Vem som helst som har läsrättigheterna till din rc-fil kan köra fetchmail lika väl som du - och om de är ute efter ditt lösenord så kan de rycka loss dekodern ur fetchmailkoden och få fram det. Det enda en .fetchmailrc lösenordskryptering skulle ha gjort är att ge en falsk känsla av säkerhet till människor som inte tänker så långt. Den generella regeln är:

17. Ett säkerhetssystem är inte säkrare än dess hemliga nycklar. Tag dig i akt för pseudohemligheter.

9. Nödvändiga förutsättningar för basarstilen.

Tidiga läsare av denna artikel ställde frågor om förutsättningarna för ett framgångsrikt utvecklingsarbete enligt basarmodellen, inklusive projektledarens kvalifikationer och om tillståndet på den programkod då man publicerar och börjar bygga upp en kommunitet av medutvecklare.

Det står rätt klart att man inte kan bygga kod från första början i basarstilen [IN]. Man kan testa, debugga och förbättra i basarstilen, men det skulle vara svårt att starta helt från noll. Linus försökte inte detta. Inte heller jag. Ens nytillkomna samhälle av medutvecklare måste ha något körbart att testa och leka med.

När man börjar bygga sitt samhälle, så behöver man också kunna presentera ett trovärdigt framtidslöfte. Programmet behöver inte fungera särskilt väl. Det kan vara grovt, buggigt, ofullgånget och dåligt dokumenterat. Men det måste kunna (a) köras, och (b) övertyga potentiella medhjälpare att det kan utvecklas till något verkligt bra inom överskådlig tid.

Både Linux och fetchmail lades ut med starka och attraktiva grundkoncept. Många personer som funderar på basarmodellen såsom jag har presenterat den, har med rätta ansett detta vara fundamentalt, och därifrån dragit slutsatsen att intuition och klurighet hos projektledaren är en nödvändig förutsättning.

Men Linus fick sin design från Unix. Jag fick min från föregångaren Popclient (även om den senare skulle komma att ändras en hel del, mycket mer än Linux proportionellt sett). Så vad betyder detta för ledaren/koordinatorn för ett projekt i basarstilen? Måste han själv ha en exceptionell begåvning eller kan han lyfta sig med andras talanger?

Jag tror inte att det är kritiskt att koordinatorn är begåvad med en exceptionell briljans, men att det är absolut nödvändigt att han känner igen och förstår goda designidéer hos andra.

Både Linux och fetchmail-projekten visar detta. Linus är, som tidigare diskuterats, inte någon spektakulärt originell designer, men han har visat ett gott handlag i konsten att känna igen bra saker och integrera dessa i Linuxkärnan. Och jag har redan beskrivit hur den bästa enskilda design idéen i fetchmail (SMTP forwarding) kom utifrån.

Tidiga läsare av denna essä smickrade mig med att antyda att jag tenderar underskatta originalitet i basarprojekt eftersom jag själv äger mycket av denna gåva och sålunda tar mycket för givet. Det kan vara någon sanning i detta, eftersom design, till skillnad från kodning och felsökning, är min starkare sida.

Men problemet med att vara klurig och originell i mjukvarudesign är att det blir till en dålig vana. Man börjar reflexmässigt med att göra saker tjusiga och komplicerade, när man istället borde göra dem robusta och enkla. Jag har kraschat projekt med dylika misstag, men lyckades undvika detta med fetchmail.

Jag tror att fetchmail-projektet lyckades delvis därför att jag lade band på min tendens att vara klurig. Detta talar emot att designoriginalitet skulle vara väsentligt för ett lyckat basarprojekt. Och tänk på Linux. Antag att Linus Torvalds hade försökt att att driva fram fundamentala innovationer inom operativsystemdesign; är det då särskilt sannolikt att den resulterade kärnan hade blivit så stabil och lyckad som den är?

En viss basnivå på skicklighet i design och kodning är naturligtvis nödvändig, men jag tror att nästan alla som på allvar funderar på att sjösätta ett projekt i basarstilen redan ligger över denna miniminivå. Open-source rörelsens interna marknad för anseende utövar ett subtilt tryck på folk att inte sätta igång utveckligsarbeten som de inte är kapabla att fullfölja. Detta tycks ha fungerat bra hittills.

Det finns en annan sorts förmåga som vanligtvis inte associeras med med programutveckling som jag tror är väl så viktig för basarprojekt som designkunnande - ja, kanske viktigare. En ledare för ett basarprojekt måste ha god hand med folk och kunna kommunicera.

Detta torde vara uppenbart. För att bygga upp ett utvecklingssamhälle måste man attrahera människor, intressera dem för det man gör och få dem att känna sig tillfreds med den del av arbetet som de utför. Tekniskt briljans går långt i detta, men det är inte hela sanningen. Den personlighet man uppvisar betyder också mycket.

Det är ingen tillfällighet att Linus är en trevlig kille som väcker sympati och får folk att vilja hjälpa honom. Det är ingen tillfällighet att jag är en utåtriktad person som tycker om att bearbeta en publik och har stå-upp-komikerns instinkter. För att få ett basarprojekt att fungera, så hjälper det enormt om man har lite av förmågan att charma människor.

10. Open-sources sociala sammanhang.

Det är sant som det är skrivet: de bästa hacken börjar som en personlig lösning till upphovsmannens vardagsproblem, och sprider sig eftersom problemet visar sig vara typiskt för en större grupp användare. Detta för oss tillbaka till innehållet i regel 1, omformulerat till ett kanske mer användbart teorem:

18. Vill man lösa ett intressant problem, ska man börja med ett som är är av intresse för en själv.

Så var det med Carl Harris och föregångaren Popclient, och med mig och fetchmail. Och det har länge varit känt. Det intressanta, som berättelserna om Linus och fetchmail kräver att vi koncentrerar oss på, är nästa steg - evolutionen av programvara inom ett stort och aktivt samhälle av användare och medutvecklare.

I "The Mythical Man-Month", konstaterar Fred Brooks att programmerartid inte är utbytbar; att lägga till utvecklare i ett sent skede i ett programvaruprojekt skapar ytterligare försening. Hans argumentation går ut på att komplexiteten och kommunikationskostnaden i ett projekt ökar med kvadraten på antalet utvecklare, medan nyttigt arbete endast ökar linjärt. Detta förhållande har sedermera blivit känt som "Brooks lag" och är en allmänt accepterad självklarhet. Men om Brooks lag vore hela sanningen, skulle Linux vara en omöjlighet.

Gerald Weinbergs klassiska "The Psychology Of Computer Programming" lade till i efterhand att man kan se en väsentlig korrektion till Brooks. I sin diskussion om "egoless programming", observerade Weinberg att på arbetsplatser där det saknas revirtänkande och där programmerarna uppmuntrar andra att leta efter fel och att föreslå förbättringar, där sker förbättringar också avsevärt snabbare än på andra ställen.

Weinbergs terminologi har kanske hindrat hans analys från att få den acceptans den förtjänar - man kan le åt hans beskrivning av internethackare som "egoless", men jag tycker att hans argument är mer oumbärliga idag än någonsin.

Unix historia torde ha förberett oss på vad vi nu lär oss av Linux (och som verifierats experimentellt i mindre skala genom att man plagierat Linus metod [EGCS]). Det vill säga, att medan programmering fortfarande väsentligen är en ensamaktivitet, så kommer de verkligt stora hacken när man mobiliserar uppmärksamhet och hjärnkraft från hela samhällen. Den utvecklare som endast använder sin egen hjärna i ett slutet projekt kommer att hamna efter den utvecklare som förstår att skapa en öppen och evolutionär miljö där återkoppling undersöker designrummet och där kodbidrag, felpåpekanden och andra förbättringar kommer från hundratals eller kanske tusentals individer.

Men den traditionella Unixvärlden hindrades av flera orsaker att använda detta arbetssätt fullt ut. Det fanns legala begränsningar i licenser, affärshemligheter och kommersiella intressen. En annan orsak vi kan se i efterhand var att Internet inte fanns eller var tillräckligt bra.

Före det billiga Internet, fanns det ett antal geografiskt avgränsade samhällen där kulturen uppmuntrade Weinbergs "egoless" programmering, och där utvecklare lätt kunde attrahera gott om skickliga belackare och medutvecklare. Bell Labs, MIT AI lab, UC Berkeley - dessa blev innovationsscentra som är legendariska och fortfarande aktiva.

Linux blev det första projektet där man gjorde en medveten och framgångsrik ansträngning att använda hela världen som en talangpool. Jag tror inte att det var en tillfällighet att beredningsperioden för Linux sammanföll med 'World Wide Web's tillkomst, och att Linux lämnade sitt småbarnsstadium samma period 1993-1994 som ISP-industrin (internetleverantörerna) startade och allmänhetens intresse för Internet exploderade. Linus var den förste som lärde sig att spela efter de nya regler som en allmän tillgänglighet till Internet medgav.

Emedan ett billigt Internet var en nödvändig förutsättning för att Linuxmodellen skulle uppstå, så tror jag inte att det var en tillräcklig förutsättning. En annan väsentlig faktor var framväxten av en ledarstil och en uppsättning kooperativa seder som kunde attrahera medutvecklare och på så sätt få ut maximal hävstångseffekt ur detta medium.

Men vad består denna ledarstil av och vilka är dessa seder? De kan inte baseras på maktrelationer - och även om så skulle vara, så skulle inte ledarskap genom tvång kunna producera de resultat vi ser. Weinberg citerar den ryske 1800-tals anarkisten Pyotr Alexeyvich Kropotkins självbiografi "En anarkist minnen" för att belysa ämnet:

"Jag, som blivit uppfostrad i en godsägarfamilj som ägde ett antal "själar", inledde liksom alla andra unga män av min generation mitt verksamma liv med en viss kolartro på nödvändigheten av att kommendera, ge order, förebrå, bestraffa och liknande. Men sedan jag på ett rätt tidigt stadium hade fått leda omfattande företag och syssla med människor, och när jag lärt mig att varje misstag kunde få ödesdigra konsekvenser fick jag snart en uppfattning om skillnaden mellan att handla enligt principen om befallningar och disciplin och att handla på basis av ömsesidig förståelse. Det förra systemet fungerar förträffligt på en militär parad, men det är värdelöst i det verkliga livet där målet endast kan nås genom många samordnade viljors gemensamma ansträngningar."

Just "många samordnade viljors gemensamma ansträngningar" är vad som behövs i ett projekt som Linux - Och "principer om befallning" är absolut omöjligt att tillämpa på det anarkisternas paradis som kallas Internet. Om det skall fungera effektivt, så måste hackare som vill leda samarbeten lära sig hur man rekryterar och motiverar intressegemenskaper på det sätt som ges av Kropotkins "principer om ömsesidig förståelse". De måste lära sig att använda Linus lag. [SP]

Tidigare refererade jag till "Delphi effekten" som en möjlig förklaring av Linus lag. Men det finns mer träffande analogier med adaptiva system inom biologi och ekonomi som oemotståndligen tränger sig på. Linuxvärlden beter sig på många sätt som en fri marknad eller ett ekologiskt system, en samling av själviska agenter som försöker maximera nyttigheter och som i denna process skapar en självkorrigerande spontan samordning som är mer fulländad och mer effektiv än vad någon centralplanering skulle kunna åstadkomma. Här är rätta platsen att söka efter "principer om ömsesidig förståelse".

Den 'nyttighetsfunktion' Linux hackare maximerar är inte klassisk ekonomi, utan det abstrakta i deras ego-tillfredsställelse och ryktbarhet inför andra hackare. (Man skulle kunna beskriva deras motivation som 'altruistisk', men då glömmer man att altruism är en form av ego-tillfredsställelse bland altruister). Frivillighetskulturer som fungerar på detta sättet är inte ovanliga; en sådan som jag själv har deltagit i är "science fiction fandom" , vilken till skillnad från "hackerdom" länge uttryckligen har erkänt 'egoboo' (ego-boosting, eller att göra sig ett namn hos andra i gruppen) som den grundläggande drivkraften bakom frivilliga aktiviteter.

Linus, som framgångrikt placerade sig som gatekeeper i ett projekt där utvecklingsarbetet huvudsakligen görs av andra, och som drev fram projektet tills det blev självgående, har visat prov på skarpsinnig insikt i Kropotkins "princip om ömsesidig förståelse". Denna kvasiekonomiska syn på Linuxvärlden får oss att se hur denna "förståelse" tillämpas i verkligheten.

Man kan se Linus metod som ett sätt att skapa en verkansfull marknad för egoboo - att koppla samman själviskhet hos enskilda hackers så hårt som möjligt för att nå mål som är så svåra att de endast kan nås med uthålligt samarbete. Med fetchmail-projektet har jag visat (om än i mindre skala) att metoden kan plagieras med gott resultat. Kanske har jag gjort det en aning mer medvetet och systematiskt än han.

Många människor, särskilt de som misstror den fria marknaden, skulle nog tro att en kultur av självständiga egoister är fragmenterad, territoriell, slösaktig, full av hemlighetsmakeri och fientlighet. Men denna misstro är klart motbevisad av den förbluffande mångfald av Linuxdokumentation med kvalitet och djup. Det är en helig fördom att programmerare hatar att dokumentera. Hur kommer det sig då att Linuxhackers genererar så mycket av detta? Tydligen är det så att Linux fria marknad av 'egoboo' är bättre på att skapa ett sedesamt och utåtriktat beteende, än de kommersiella mjukvaruproducentarnas penningslukande dokumentationsfabriker.

Både fetchmail- och Linuxprojekten visar att man genom att på rätt sätt belöna 'egot' hos många hackare, så kan en stark utvecklare/koordinator använda Internet för att fånga in fördelarna med att ha många medutvecklare utan att projektet kollapsar i ett kaos. Så i motsats till Brooks lag föreslår jag följande:

19. Förutsatt att koordinatorn har ett medium minst lika bra som Internet, och förstår att leda utan tvång, är många hjärnor oundvikligen bättre än en.

Jag tror att framtiden för öppen källkod kommer att tillhöra dem som kan spela Linus spel, de som lämnar katedralmodellen bakom sig och omfamnar basarmodellen. Det betyder inte att individens visioner och briljans har spelat ut sin roll, snarare tror jag att frontlinjen inom öppen mjukvara tillhör människor som startar med visioner och briljans, och sedan förstärker dessa genom att bygga upp samhällen av frivilliga som delar deras intresse.

Kanske gäller detta inte bara open-source programvara. Ingen 'closed source'-utvecklare kan mäta sig med den talangpool som Linux-rörelsen kan uppbåda för att möta ett problem. Väldigt få kan ens ha råd att anställa de tvåhundra (1999:sexhundra, 2000:åttahundra) personer som har bidragit till fetchmail!

Kanske kommer open-source kulturen slutligen att triumfera, inte därför att samarbete är moraliskt rätt och programvaruhamstring moraliskt fel (förutsatt att du tycker det senare, vilket varken Linus eller jag gör), utan helt enkelt därför att den slutna världen (close-source-word) inte kan vinna den evolutionära kampen med open-source rörelserna, vilka kan lägga magnituder av mer kvalificerad arbetskraft och tid på ett problem.

11. 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.

12. Tillerkännanden

Denna essä har bättrats genom samtal med ett stort antal personer som har hjälpt mig att hitta fel. Speciellt tack till Jeff Dutky <dutky@wam.umd.edu> som föreslog formulerningen "debugging is parallelizable" , och även hjälpte mig att utveckla analysen som följer därur. Även till Nancy Lebovitz <nancyl@universe.digex.net> för hennes förslag att i Weinbergs efterföljd citera Kropotkin. Kritik med perspektiv kom också från Joan Eslinger <wombat@kilimanjaro.engr.sgi.com> och Marty Franz <marty@net-link.net> från General Technics lista. Glen Vandenburg <glv@vanderburg.org> pekade på vikten av självgallring i bidragsgivarnas skara och föreslog den fruktbara idéen om hur mycket utvecklingshjälp reder ut "bugs of omission"; Daniel Upper <upper@peak.org> föreslog naturliga analogier kring detta. Jag tackar medlemmar i PLUG, the Philadelphia Linux Users group, för deras insats som testpublik för den första publika versionen av denna essä. Paula Matuszek <matusp00@mh.us.sbphrd.com> som upplyste mig om praktiken om ledning av mjukvaruprojekt. Phil Hudson <phil.hudson@iname.com> påminde mig om hur hackerkulturen sociala organisation speglar hur dess mjukvara är organiserad. Slutligen, Linus Torvalds kommentarer var värdefulla och hans tidiga stöd var uppmuntrande.

13. Vidare läsning

Jag har tagit många citat från Frederick P. Brooks klassiska "The Mythical Man Month" därför att ur många aspekter så har hans insikter ännu inte överträffats. Jag rekommenderar hjärtligt 25th Anniversary edition från Addison-Wesley (ISBN 0-201-83595-9), som även innehåller hans essä "No Silver Bullet".

Den nya utgåvan innehåller en ovärderlig retrospektiv 20 år senare, där Brooks rakt ut erkänner de få bedömningar i originaltexten som inte har stått emot tidens tand. Jag läste först retrospektiven efter det att den första offentliga utgåvan av hans skrift var färdig, och förvånades av att upptäcka att Brooks tillskriver Microsoft basarliknade arbetsmetoder! (Emellertid har det visat sig att detta tillskrivande var ett misstag. 1998 fick vi lära från Halloween Documents, att Microsofts interna utvecklarkår är starkt splittrad, och att den sorts allmänna tillgång till källkod som krävs för att driva en basar, inte är möjlig.

Gerald M. Weinbergs 'The Psychology Of Computer Programming' (New York, Van Nostrand Reinhold 1971) introducerar begreppet med den rätt olyckligt valda etiketten "egoless programming". Han var inte i närheten av att vara den förste att förstå fåfängligheten med "principle of command", men han var nog den förste att argumentera för denna sak i samband med programutveckling.

Richard P. Gabriel betraktar Unixkulturen före Linux, argumenterar motvilligt för överlägsenheten i en primitiv basarliknande modell i sin essä från 1989 Lisp: Good News, Bad News, and How To Win Big. Om än föråldrad på vissa punkter, hyllas denna fortfarande med rätta bland Lispanhängare (inklusive mig). En brevskrivare påminde mig om att ett avsnitt med titeln "Worse Is Better" nästan är en profetia om Linux. Artikeln finns tillgänglig på WWW http://www.naggum.no/worse-is-better.html.

De Marco och Listers 'Peopleware: Productive Projects and Teams' (New York; Dorset House, 1987; ISBN 0-932633-05-6) är en pärla som jag med förtjusning såg att Fred Brooks citerade i sin retrospektiv. Även om det författarna säger inte är direkt tillämpbart på Linux och open-source rörelsen, så är författarnas insikter om förutsättningarna för kreativt arbete skarpsinniga och värdefulla för envar som försöker anamma basarmodellens välsignelser i ett kommersiellt sammanhang.

Slutligen måste jag erkänna att jag nästan kallade denna essä för "The Cathedral and the Agora", där den senare termen är grekiskans öppet torg eller allmän mötesplats. De seminala skrifterna "agoric systems" av Mark Miller and Eric Drexler, hjälpte mig att tänka klart om likartade företeelser inom open-source kulturen när Linux gjorde dem aktuella för mig fem år senare. Dessa skrifter finns tillgängliga på nätet på http:/www.agorics.com/agorpapers.html.

14. Epilog: Netscape går till basaren

Det är en märklig upplevelse att känna att man är med om att skapa historia....

Den 22:e januari 1998, cirka sju månader efter det jag först publicerade "The Cathedral and the Bazaar" annonserade Netscape Communications, Inc. att de skulle ge ut källkoden till Netscape Communicator Jag hade ingen aning om detta förrän det annonserades ut.

Eric Hahn, Executive Vice President och Chief Technology Officer hos Netscape skickade mig ett e-brev kort därefter som löd: Å alla på Netscapes vägnar vill jag tacka dig för att du hjälpt oss att överhuvud taget komma fram till denna punkt. Dina tankar och dina skrifter var av fundamental betydelse och inspirerade oss till detta beslut.

Veckan som följde flög jag till Silicon Valley på Netscapes inbjudan för en dagslång strategikonferens (Den 4:e Feb 1998) med några av deras toppchefer och tekniskt folk. Vi arbetade tillsammans ut Netscapes strategi för utgivning av källkod och för deras licenser.

Några dagar senare skrev jag följande:

Netscape kommer att ge oss ett storskaligt test av basarmodellen i den kommersiella världen. Open-source kulturen står nu inför en ny fara. Om Netscapes försök inte fungerar, kommer open-source konceptet att råka i sådant vanrykte att den kommersiella världen inte vill ta i det igen förrän nästa årtionde.

Å andra sidan är det också ett lysande tillfälle. Den omedelbara reaktionen på börsen (Wall Street med flera) var försiktigt positiv. Vi har också fått en chans att visa vad vi går för. Om Netscape återfår en substantiell marknadsandel genom detta drag, kan det få igång en länge fördröjd revolution inom programvaruindustrin.

Det kommer att bli ett lärorikt och intressant år.

Och det blev det verkligen. När jag skriver detta i mitten av 1999 hade utveckligen av det som senare skulle kallas Mozilla bara blivit en begränsad framgång. Man uppnådde det ursprungliga målet, vilket var att förhindra att Microsoft skulle få monopol på marknaden för nätbläddrare. Man har även fått några succéer som utgåvan av nästa generationens renderingsmaskin Gecko.

Man har emellertid inte ännu fått det massiva utvecklingsstöd utifrån som grundarna av Mozilla hade hoppats. Problemet tycks vara att Mozilla-distributionen bröt mot en fundamental regel i basarmodellen. De levererade inte något som potentiella bidragare lätt kunde köra och få att fungera. Intill mer än ett år efter publiceringen av den första utgåvan, så krävdes det licens för det proprietära Motif-biblioteket.

Det mest negativa ur omvärldens synpunkt är att Mozilla-gruppen ännu inte givit ut en bläddrare med produktionskvalitet. Och en av de ledande inom projektet skapade sensation genom att säga upp sig. Han klagade på dålig ledning och usla framtidsutsikter. "Open-source", sa han, helt korrekt, "är inget magiskt trollpulver."

Det är det verkligen inte. Långtidsprognosen för Mozilla ser betydligt bättre ut nu (augusti 2000) än vad den gjorde vid tiden för Jamie Zawinskis avskedsbrev - men han hade rätt i att befrielse av koden inte med säkerhet kan rädda ett projekt som lider av dåligt ställda mål eller spagettikod eller någon annan av programmeringskonstens kroniska sjukdomar. Mozilla har gett oss ett exempel som på samma gång visar hur open-source kan lyckas och hur det kan misslyckas.

Under tiden har emellertid open-source idéerna räknat hem succéer och vunnit stöd på annat håll. 1998 och 1999 har intresset för open-source modellen för programutveckling exploderat. En trend som både driver och drivs av den pågående succén för Linux operativsystem. Den trend som Mozilla satte igång fortsätter i accelererad fart.

15. 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.