De kathedraal en de bazaar – het verhaal achter Open Source

De kathedraal en de bazaar

Door Eric S. Raymond – 27 maart 1997, 18:52:18

Ik ontleed een succesvol open-source project, fetchmail, dat werd uitgevoerd als een opzettelijke test van een aantal verrassende theorieën over software ontwikkeling die voortkwamen uit de geschiedenis van Linux. Ik bespreek deze theorieën in termen van twee fundamenteel verschillende ontwikkelstijlen; het ‘kathedraal’- model dat in het merendeel van de commerciële wereld in gebruik is versus het ‘bazaar’-model uit de Linux wereld. Ik toon aan dat deze modellen afgeleid zijn van tegenovergestelde aannames betreffende de aard van de taak om fouten binnen software op te sporen. Ik houd vervolgens de vanuit de ervaringen met Linux voortkomende stelling staande: “gegeven dat er voldoende waarnemers zijn, zijn alle fouten oppervlakkig”. Ik suggereer productieve overeenkomsten met andere zelf-corrigerende systemen die worden geleid door zelfzuchtige rentmeesters en sluit af met enige verkenning van de implicaties van deze inzichten voor de toekomst van software.

Inhoud

1. De kathedraal en de bazaar
2. De post moet doorgestuurd
3. Het belang van het hebben van gebruikers
4. Geef vroeg en vaak vrij
5. Wanneer is een roos geen roos?
6. Popclient wordt fetchmail
7. Fetchmail wordt volwassen
8. Nog een paar lessen van fetchmail
9. Noodzakelijke randvoorwaarden voor de bazaar stijl
10. De sociale context van Open Source software
11. Dankbetuigingen
12. Als u meer wilt lezen
13. Epiloog: Netscape omarmt de bazaar!
14. Versie en wijzigingshistorie
15. Aantekeningen van de vertaler

Linux is tegendraads. Wie zou nog geen vijf jaar geleden hebben vermoed dat een besturingssysteem van wereldklasseals door toverkracht kon ontstaan uit de versmelting van in deeltijd verricht programmeerwerk door enige duizenden ontwikkelaars, die over de hele planeet verspreid slechts werden verbonden door de dunne draadjes van het Internet? Ik zeker niet. Toen Linux begin 1993 in mijn gezichtsveld verscheen was ik al meer dan 10 jaar betrokken bij Unix- en Open Source ontwikkeling. Ik was een van de eersten die aan GNU bijdroeg halverwege de jaren 80. Ik had een grote hoeveelheid open source software op het net vrijgegeven, als ontwikkelaar of mede-ontwikkelaar van diverse programma’s (nethack, Emacs VC en GUD modes, xlife, en andere) die tot op de dag van vandaag algemeen in gebruik zijn. Ik dacht dat ik wist hoe je het aan moest pakken. Linux gooide veel van wat ik dacht te weten overhoop. Ik had het Unix evangelie ‘kleine tools, vlot prototypen en evolutionair programmeren’ jarenlang gepredikt. Maar ik geloofde ook dat er een bepaalde kritieke complexiteit bestond, waarboven een meer gecentraliseerde a priori aanpak nodig werd. Ik meende dat de belangrijkste software (zoals besturingssystemen en werkelijk omvangrijke tools als Emacs) overeenkomstig kathedralen gebouwd moesten worden; zorgvuldig gewrocht door individuele tovenaars of kleine groepen magiërs, die in volmaakte afzondering hun werk deden, zonder ooit voortijdig een betaversie uit te brengen. De ontwikkelstijl van Linus Torvalds – geef vroeg en vaak je code vrij, besteed alles uit wat je maar kunt, wees tot in het absurde open over alles – kwam als een verrassing. Hier geen rustig, eerbiedig bouwen van een kathedraal – de Linux gemeenschap leek eerder op een grote leuterende bazaar met niet overeenkomende agenda’s en verschillende aanpak (treffend gesymboliseerd door de Linux archief sites, die inzendingen van iedereen accepteerden), waaruit een coherent en stabiel systeem ogenschijnlijk alleen maar door een opeenvolging van wonderen kon ontstaan. Het feit dat deze bazaar-stijl leek te werken, en zelfs goed werkte, kwam als een klap. Terwijl ik mijn weg hierin leerde vinden werkte ik niet alleen hard aan individuele projecten, maar ook aan het proberen te begrijpen waarom de Linux wereld niet alleen niet in verwarring uiteen spatte, maar zich van het ene pluspunt naar het volgende bewoog en wel met een snelheid die kathedraalbouwers zich niet konden voorstellen, Rond het midden van 1996 dacht ik dat ik het begon te begrijpen. De voorzienigheid reikte me een perfecte methode aan om mijn theoriën te testen, in de vorm van een open source project wat ik bewust probeerde uit te voeren in de bazaar-stijl. Ik deed dit – en het werd een significant succes. In de rest van dit artikel vertel ik het verhaal van dat project en ik gebruik dit om een aantal kernspreuken naar voren te brengen over effectief open source ontwikkelwerk. Niet al deze aforismen heb ik als eerste in de Linux wereld geleerd, maar we zullen zien hoe de Linux wereld ze extra onderstreept. Als ik het bij het rechte eind heb zullen ze u helpen precies te begrijpen wat het is dat de Linux gemeenschap zo’n bron van goede software maakt – en u helpen om zelf productiever te worden.

De post moet doorgestuurd

Sinds 1993 had ik de techniek gedaan voor een kleine, gratis toegankelijke ISP [Internet Service Provider – een organisatie die toegang geeft tot het Internet – vert.], de Chester County InterLink (CCIL) te West Chester, Pennlsylvania, Amerika. (Ik was medeoprichter van CCIL en schreef onze unieke multi-user bulletin board software. Momenteel worden er ongeveer 3000 gebruikers ondersteund met 19 inbellijnen). Deze taak gaf me 24 uur per dag toegang tot het Internet via de 56K lijn die CCIL heeft – in feite was dit praktisch een vereiste! Bijgevolg was ik behoorlijk gewend geraakt aan instant Internet e-mail. Om gecompliceerde redenen was het moeilijk om SLIP aan de praat te krijgen tussen mijn thuismachine (snark.thyrsus.com) en CCIL. Toen ik er uiteindelijk in slaagde vond ik het vervelend om periodiek te moeten telnetten naar locke om mijn mail te controleren. Wat ik eigenlijk wilde was, dat mijn post op snark zou worden afgeleverd, en wel zo dat ik bij aankomst van post zou worden gewaarschuwd en deze kon afhandelen met gebruikmaking van al mijn lokale gereedschappen. Eenvoudig de post door CCIL’s Sendmail laten doorsturen zou niet werken, omdat mijn persoonlijke machine niet altijd aan het net hangt en geen statisch IP adres heeft. Wat ik nodig had was een programma dat over mijn SLIP verbinding de post over kon trekken opdat deze lokaal bezorgd kon worden. Ik wist dat dergelijke programma’s bestonden en ook dat de meesten een eenvoudig protocol gebruikten wat ‘POP’ (Post Office Protocol) heette. En ja hoor, er was zelfs al een POP3 server bij locke‘s BSD/OS besturingssyssteem meegeleverd. Ik had behoefte aan een POP3 client. Dus ging ik het net op en vond er een. Eigenlijk vond ik er drie of vier. Ik maakte een tijdje gebruik van pop-perl, maar het mistte een ogenschijnlijk voor de hand liggend feature; de mogelijkheid om adressen van afgehaalde post te wijzigen, zodat antwoorden correct zouden worden verwerkt. Het probleem was: veronderstel dat iemand met de naam ‘joe’ mij post stuurde vanaf locke. Als ik de post overhaalde naar snark en dan een antwoord probeerde te sturen, zou mijn mailer innig tevreden proberen om het antwoord te versturen naar een niet-bestaande gebruiker ‘joe’ op snark. Het met de hand wijzigen van reply-adressen door er ‘@ccil.org‘ aan vast te plakken werd al snel een ernstig ongemak. Dit was duidelijk iets wat eigenlijk de computer voor mij zou moeten doen. Maar geen van de bestaande POP3 clients wist hoe je dit deed! En dat brengt ons tot onze eerste les:

Misschien zou dit wel voor de hand liggend moeten zijn (het is al lang bekend dat noodzaak de moeder van vindingrijkheid is) maar maar al te vaak brengen software ontwikkelaars hun dagen door met het betaald vossen aan programma’s die zij noch nodig hebben, noch liefhebben. Zo niet in de Linux wereld – wat zou kunnen verklaren waarom de gemiddelde kwaliteit van uit de Linux gemeenschap afkomstige software zo hoog ligt. Brandde ik nu dus onmiddellijk los om met vliegende vaart een splinternieuwe POP3 client te coderen, die met de bestaande zou kunnen concurreren? Van zijn levensdagen niet! Ik keek zorgvuldig naar de bestaande POP toepassingen die ik had liggen, mijzelf de vraag stellend ‘welke komt het dichtst in de buurt bij wat ik wil?’, immers:

Hoewel ik niet claim een hele goede programmeur te zijn, probeer ik er een na te doen. Een belangrijke eigenschap van de hele goeien is ‘constructieve luiheid’. Zij weten dat je geen 10 krijgt voor je inspanning, maar voor het resultaat en dat het bijna altijd eenvoudiger is om je te baseren op een goede gedeeltelijke oplossing dan op helemaal niets. Linus Torvalds probeerde bijvoorbeeld helemaal niet om Linux vanuit het niets te schrijven. Inplaats daarvan begon hij met het hergebruik van code en idee-en van Minix, een piepklein Unix-achtig OS voor 386 machines. Op den duur verviel alle Minix code of werd compleet herschreven – maar zolang het er nog in zat, zorgde het voor het schoren van het kindje dat op den duur zou uitgroeien tot Linux. In dezelfde geest ging ik op zoek naar een bestaande POP client die redelijk goed gecodeerd was, om te gebruiken als een uitgangspunt voor ontwikkeling. De traditie binnen Unix om code te delen heeft hergebruik van code altijd in de hand gewerkt (dit is de reden waarom het GNU project Unix als basis OS koos, ondanks ernstige bedenkingen over het OS zelf). De Linux wereld heeft deze traditie voortgedragen tot vrijwel de technische limiet; er zijn terabytes Open Source publiekelijk toegankelijk. Dus is het doorbrengen van wat tijd op zoek naar iemand anders’ “bijna-goed-genoeg” in de Linux wereld een aannemelijker weg naar goede resultaten dan waar dan ook. En het werkte bij mij. Samen met degenen die ik eerder al had gevonden kwam ik na mijn tweede zoekpoging uit op een totaal van negen kandidaten – fetchpop, PopTart, get-mail, gwpop, pimp, pop-perl, popc, popmail en upop. Degeen waar ik initieel voor koos was fetchpop, geschreven door Seung-Hong Oh. Ik stopte er mijn header-rewrite voorziening in en bracht diverse andere verbeteringen aan die de auteur in zijn 1.9 release accepteerde. Een paar weken later echter stuitte ik op de code van pop-client door Carl Harris, en ontdekte dat ik een probleem had. Hoewel fetchpop een aantal goede originele idee-en bevatte (zoals zijn deamon-mode) kon het programma alleen maar POP3 aan en was nogal amateuristisch gecodeerd (Seung-Hong was een slimme maar onervaren programmeur en beide eigenschappen waren zichtbaar). De code van Carl was beter, heel professioneel en solide, maar zijn programma ontbeerde verschillende belangrijke en nogal moeilijk te implementeren fetchpop eigenschappen (inclusief die, die ik zelf had geschreven). Aanhouden of omschakelen? Als ik omschakelde, zou ik mijn reeds geschreven programmeerwerk weggooien in ruil voor een beter uitgangspunt. Een praktisch motief om om te schakelen was de aanwezigheid van multiprotocol ondersteuning. POP3 is de meest algemeen gebruikte variant van de POP server protocollen, maar niet de enige. Fetchpop en andere concurrenten kenden geen POP2, RPOP of APOP en ik had al vage idee-en over het wellicht toevoegen van IMAP (Internet Message Access Protocol, het meest recent ontworpen en meest krachtige ‘post office’ protocol) – gewoon, voor de lol. Maar ik had daarnaast een meer theoretische reden om aan te nemen dat omschakelen goed was, iets wat ik lang voor Linux had geleerd.

Of, om het anders te zeggen: je snapt het probleem vaak niet werkelijk tot je de eerste oplossing hebt uitgevoerd. De tweede keer weet je misschien voldoende om het goed te doen. Dus, als je het goed wilt doen, wees erop voorbereid minstens een keer opnieuw te beginnen. Welnu (zo zei ik tegen mezelf) mijn wijzigingen op fetchpop waren mijn eerste poging geweest. Dus schakelde ik om. Nadat ik op 25 juni 1996 mijn eerste set popclient patches aan Carl Harris toe had gezonden kwam ik er achter dat hij in essentie een tijdje daarvoor de interesse in popclient kwijt was geraakt. De code was wat stoffig, en er hingen wat kleine bugs in rond. Ik had nogal wat wijzigingen die ik wilde maken en we werden het er snel over eens dat het meest logische was dat ik het programma over zou nemen. Zonder dat ik het eigenlijk door had, was het project wat geëscaleerd. Ik was niet langer aan het overwegen om kleine wijzigingen aan te laten brengen op een bestaande POP-client. Ik nam het op me om er een in zijn geheel te gaan onderhouden en er borrelden idee-en in me op waarvan ik wist dat ze waarschijnlijk zouden leiden tot grote wijzigingen. In een software cultuur die het delen van code aanmoedigt is dit de natuurlijke weg waarlangs een project evolueert. Ik verbeeldde de volgende stelling:

Maar de instelling van Carl Harris was nog belangrijker. Hij begreep het volgende

Zonder er ooit discussie over te moeten voeren begrepen Carl en ik dat we een gemeenschappelijk doel hadden, namelijk het naar buiten brengen van de beste oplossing. De enige vraag voor ons beide was of ik kon aantonen dat ik een veilig paar handen was. Toen ik dat eenmaal deed, droeg hij beleefd en vlot over. Ik hoop dat ik het even goed doe als mijn tijd komt.

Het belang van het hebben van gebruikers

En zo erfde ik popclient. Net zo belangrijk: ik erfde popclients gebruikersgroep. Gebruikers zijn heerlijke dingen om te hebben en niet alleen maar omdat ze aantonen dat je in een behoefte voorziet, danwel dat je iets goeds hebt gedaan. Met de juiste zorg kunnen ze namelijk mede-ontwikkelaars worden. Een van de andere sterke kanten van de Unix traditie, een die Linux tot een gelukkig uiterste doorvoert, is dat een groot aantal gebruikers ook programmaschrijvers zijn. Omdat de broncode beschikbaar is kunnen ze ook effectieve programmeurs zijn. Dit kan verschrikkelijk handig zijn bij het verkorten van foutzoek-tijd. Met een beetje aanmoedinging zullen uw gebruikers problemen diagnosticeren, suggesties doen om ze op te lossen, en helpen om de code – veel sneller dan u het ooit zonder hulp had gekund – te verbeteren.

De kracht van dit effect is snel te onderschatten. In feite onderschatten wij uit de Open Source wereld bijna allemaal dramatisch hoe het effect toe zou nemen met het aantal gebruikers en de complexiteit van het systeem zou afnemen, totdat Linus Torvalds ons het anders liet zien. In feite denk ik dat Linus’ slimste en meest gevolgrijke ‘hack’ niet de constructie van de Linux-kernel zelf was, maar veel meer het uitvinden van het Linux ontwikkelmodel. Toen ik deze mening eens uitte in zijn aanwezigheid, glimlachte hij en herhaalde rustig wat hij zo vaak heeft gezegd: “Ik ben in aanleg een heel lui persoon die er van houdt om de eer op te strijken van wat in feite andermans werk is.” Lui als een vos. Of, zoals Robert Heinlein zou kunnen hebben gezegd: te lui om te falen. In retroperspectief kan een voorloper van de methoden en het succes worden gezien in de ontwikkeling van de GNU Emacs Lisp bibliotheek en de Lisp code archieven. In tegenstelling tot de kathedraal-bouwers stijl van de Emacs C kern en de meeste andere FSF [Free Software Foundation – vert.] tools, was de evolutie van de Lisp code pool vloeiend en zeer gebruikers-gedreven. Ideeën en prototypen van modes werden vaak drie of vier keer herschreven voor ze een stabiele vorm bereikten. En los-vaste samenwerkingen die mogelijk werden door het Internet, a la Linux, kwamen veelvuldig voor. Sterker, mijn eigen meest succesvolle ‘hack’ die aan fetchmail vooraf ging was waarschijnlijk emacs’ VC mode, een Linux-achtige samenwerking middels e-mail met drie andere mensen, waarvan ik er tot op de dag van vandaag slechts een heb ontmoet (Richard Stallman, de auteur van Emacs en oprichter van de FSF [lt]http://www.fsf.org>). Het was een front-end voor SCCS, RCS en later CVS vanuit Emacs dat ‘one-touch’ versie controle bewerkingen mogelijk maakte. Het ontwikkelde zich uit een kleine, ruwe sccs.el mode die iemand anders had geschreven. En de ontwikkeling van VC lukte omdat, in tegenstelling tot Emacs zelf, de Emacs Lisp code heel snel door generaties van de cyclus vrijgeven/testen/verbeteren kwam. Een onverwacht nevenaspect van FSF gedragslijn om code juridisch te binden aan de GPL [GNU Public Licens – vert.] is dat het procedureel moeilijker wordt voor de FSF om de bazaar ontwikkelstijl te gebruiken, omdat men daar gelooft dat men een copyright moet laten toewijzen aan elke individuele bijdrage van meer dan 20 regels om de code onder GPL te beschermen tegen aanvechtingen onder de copyright wetten. Mensen die hun rechten beschermen door de BSD- en MIT Consortium licenties te gebruiken hebben dit probleem niet; ze proberen geen rechten te reserveren die iemand er toe zou kunnen brengen ze aan te vechten.

Geef vroeg en vaak vrij

Vlotte en frequente vrijgave van code zijn een kritiek deel van het Linux ontwikkelingsmodel. De meeste ontwikkelaars (mijzelf niet uitgezonderd) geloofden dat dit een slechte praktijk was voor alle niet triviale projecten, omdat vroege versies bijna per definitie versies met veel fouten zijn en je het geduld van je gebruikers niet voortijdig wilt verbruiken. Deze aanname bevorderde de algemene toewijding aan een kathedraal- ontwikkelstijl. Als het allesverdringende doel was dat de gebruikers zo weinig mogelijk fouten te zien zouden krijgen, nou, dan zou je niet vaker dan eens per half jaar (of zelfs nog minder) code vrijgeven en tussen de vrijgave van je code als een slaaf werken op het ontluizen ervan. De Emacs C kern was op die manier ontwikkeld. De LISP bibliotheek feitelijk niet – omdat er actieve LISP archieven bestonden die niet onder de controle van de FSF vielen, en waar je naar toe kon gaan om nieuwe versies en ontwikkelversies te vinden die onafhankelijk waren van de vrijgavecyclus van Emacs. De belangrijkste hiervan, het elisp archief van de Ohio State University, anticipeerde op de geest en veel van de eigenschappen van de hedendaagse omvangrijke Linux archieven. Maar er waren maar weinigen onder ons die werkelijk stevig nadachten over wat we aan het doen waren of over wat alleen het bestaan van dat archief al suggereerde over de problemen in FSF’s kathedraal-bouwers ontwikkelmodel. Ik deed ergens in 1992 een serieuze poging om heel veel van de Ohio code formeel samen te voegen met de officiele Emacs LISP bibliotheek. Ik liep tegen politieke moeilijkheden op en had grosso modo geen succes. Maar ongeveer een jaar later, toen Linux in brede kring zichtbaar werd, was het duidelijk dat er daar iets totaal verschillends en veel gezonders aan de hand was. Het open ontwikkelbeleid van Linus was sterk het tegenovergestelde van kathedraalbouwen. De sunsite en tsx-11 archieven bloeiden op, diverse distributies werden losgelaten. En dit alles werd voortgedreven door een ongekend hoge frequentie van releases van het kern-systeem. Linus behandelde zijn gebruikers als mede-ontwikkelaars op de meest efficiente wijze:

De innovatie van Linus zat niet zo zeer in wat hij deed (iets dergelijks was al heel lang een traditie in de Unix wereld) maar in het opschalen naar een niveau van intensiteit wat overeenkwam met de complexiteit van hetgeen hij aan het ontwikkelen was. In deze vroege periode (ongeveer 1991) was het voor hem niet te doen ongebruikelijk meer dan eens per dag (!) een nieuwe kernel vrij te geven. Omdat hij zijn groep medeontwikkelaars cultiveerde en het Internet meer dan wie ook als hefboom gebruikte om tot samenwerking te komen, werkte dit. Maar hoe werkte het? En was het iets dat ik kon nabootsen, of hing het af van een of andere geniale eigenschap van Linus Torvalds? Ik vermoedde van niet. Toegegeven, Linus is een verdraaid goeie programmeur (hoevelen onder ons zijn in staat om een volledige kernel van een besturingssysteem van productiekwaliteit in elkaar te zetten?). Maar Linux vertegenwoordigde niet een of andere gigantische conceptuele stap voorwaarts. Linus is niet (tenminste: nog niet) een innovatief ontwikkelgenie zoals, zeg, Richard Stallman of James Gosling (die van NeWS en Java) dat zijn. Eerder lijkt Linus me een genie op het vlak van engineering, met een zesde zintuig voor het voorkomen van bugs en doodlopende ontwikkelstegen, met een werkelijk talent om de weg van de minste inspanning tussen A en B te vinden. Sterker, het hele ontwerp van Linux ademt deze kwaliteit en spiegelt Linus’ in essentie behoudende en vereenvoudigende ontwerpaanpak. Dus, als vlot opeenvolgende releases en het opkrikken van het gebruik van het medium Internet overduidelijk geen toevalligheden waren, maar integrale delen van Linus’ geniale ingenieursinzicht in de weg naar de minste inspanning, wat optimaliseerde hij dan? Wat zwengelde hij uit de machine? Zo gesteld beantwoordt de vraag zichzelf. Linus zorgde ervoor dat zijn gebruikers/hackers constant werden gestimuleerd en beloond – gestimuleerd door het vooruitzicht dat ze een ego-bevredigend onderdeel van de gebeurtenissen uitmaakten, beloond door het zicht op constante (zelfs dagelijkse) verbetering van hun werk. Linus richtte zich direct op het maximaliseren van de persoonsuren die in het zoeken naar fouten en ontwikkeling werden gestoken, zelfs als dit mogelijk ten koste ging van de stabiliteit van de code of het afbranden van de gebruikersgroep als een of andere serieuze fout hardnekkig bleek te zijn. Hij gedroeg zich alsof hij ongeveer het volgende geloofde:

Of, wat minder formeel: “gegeven voldoende ogen zijn alle fouten oppervlakkig”. Ik noem dit ‘de wet van Linus’. Mijn oorspronkelijke stelling was dat elk probleem ‘doorzichtig [dus benoemdbaar en oplosbaar -vert.] is voor iemand’. Linus wierp tegen dat de man die het probleem begrijpt en het oplost niet noodzakelijk, nee zelfs niet gewoonlijk, de persoon is die het probleem benoemd. “Iemand vindt het probleem,” zegt hij, “en iemand anders begrijpt het. En ik wil vastgelegd zien dat ik stel dat het vinden van het probleem de grotere uitdaging is.” Maar het punt is dat beide zaken ernaar neigen vlot plaats te vinden. Hier, dunkt me, vinden we de kern van het verschil tussen de grondslagen van de kathedraal-bouwers en bazaar-stijl. In de visie die de kathedraalbouwer op programmeren heeft zijn bugs en ontwikkelproblemen netelige, verraderlijke en diepgelegen fenomenen. Het kost maanden van kritisch onderzoek door een aantal toegewijden om de zekerheid op te bouwen dat je ze er allemaal uit hebt weten te peuteren. Vandaar de lange perioden tussen de releases en de onvermijdelijke teleurstelling als de langverwachte releases niet perfect blijken te zijn. Binnen de bazaarvisie daarentegen neem je aan dat fouten in het algemeen aan de oppervlakte liggen – of tenminste, dat ze spoedig aan de oppervlakte komen als ze worden blootgesteld aan de duizenden gretige mede-ontwikkelaars die op elke nieuwe release zwoegen. Dienovereenkomstig geef je veel en vaak vrij om meer correcties te verkrijgen en als een prettig neveneffect heb je minder te verliezen als er af en toe eens een bricolage de deur uitgaat. En dat is het. En dat is genoeg. Als ‘de wet van Linus’ fout is, dan zou elk systeem zo complex als de Linux kernel, en zo vaak omgevormd door zo veel handen als de Linux kernel, op een gegeven moment in moeten zijn gestort onder het gewicht van onvoorziene slechte interacties en onontdekte ‘diepgelegen’ bugs. Als hij daarentegen klopt, voldoet hij om Linux’ relatief gebrek aan softwarefouten te verklaren. En misschien zou het niet zo’n verassing moeten zijn geweest, als je er over nadenkt. Sociologen hebben jaren geleden ontdekt dat de gemiddelde mening van een massa van gelijk kundige (of gelijk onkundige) waarnemers bepaaldelijk betrouwbaarder als voorspelling kan worden gebruikt dan die van een willekeurig gekozen waarnemer. Men noemde dit het “Delphi effect”. Het lijkt erop dat wat Linus heeft aangetoond is dat dit zelfs opgaat voor het ontluizen van een besturingssysteem – dus dat het Delphi effect ontwikkel- complexiteit kan bedwingen, zelfs de complexiteit van het niveau van de kern van een besturingssysteem. Ik sta in het krijt bij Jeff Dutky [lt]dutky@wam.umd.edu> die mij er op heeft gewezen dat de wet van Linus anders geformuleerd kan worden als “foutzoeken is parallelizeerbaar”. Jeff observeert dat, hoewel foutzoeken vereist dat foutzoekers met een of andere coördinerende ontwikkelaar communiceren, significante communicatie tussen foutzoekers niet vereist is. Zodoende valt deze werkwijze niet ten prooi aan dezelfde kwadratische complexiteit en beheerskosten die het toevoegen van ontwikkelaars problematisch maakt. In de praktijk blijkt het theoretische verlies aan efficiency, te wijten aan het dupliceren van het werk van foutzoekers, bijna nooit een zaak van belang te zijn binnen de Linux wereld. Een effect van de beleidslijn “geef vroeg en vaak vrij” is het minimalizeren van dergelijke dupliceringen door de vlotte terugkoppeling van oplossingen. Brooks maakte zelfs terloops een opmerking die met die van Jeff is verwant: “De totale kosten die gemoeid zijn met het onderhouden van een in brede kring gebruikt programma zijn typisch 40 procent of meer van de kosten om het te ontwikkelen. Verrassend genoeg worden deze kosten sterk beïnvloed door het aantal gebruikers. Meer gebruikers vinden meer fouten” (mijn cursief). Meer gebruikers vinden meer fouten, want het toevoegen van meer gebruikers voegt meer manieren toe om het programma onder druk te zetten. Dit effect wordt versterkt als de gebruikers ook de mede-ontwikkelaars zijn. Ieder van hen benadert de taak van het foutzoeken met iets verschillende percepties en analytische werktuigen, een andere invalshoek op het probleem. Het “Delphi effect” lijkt juist door deze variaties te werken. In de specifieke context van het foutzoeken leidt deze variatie ook nog tot het reduceren van duplicatie van inspanning. Dus: het toevoegen van meer beta-testers mag de complexiteit van de huidige ‘meest verscholen’ fout dan wel niet reduceren vanuit de optiek van de ontwikkelaar, maar het doet de waarschijnlijkheid toenemen dat iemands gereedschapsset zo bij het probleem past dat de fout oppervlakkig lijkt voor die persoon. Linus wedt ook graag op twee paarden. Als er serieuze fouten optreden, worden de Linux kernels zo genummerd dat de potentiële gebruikers de keus hebben om ofwel de laatste versie die als ‘stabiel’ is gemarkeerd te gebruiken of op het snijvlak van de ontwikkelingen het risico van fouten te lopen, maar wel de nieuwste voorzieningen te hebben. Deze taktiek wordt nog niet formeel geïmiteerd door de meeste Linux hackers, maar misschien zou dat wel zo moeten zijn; het feit dat allebei de keuzen er zijn maakt beiden aantrekkelijker.

Wanneer is een roos geen roos?

Nadat ik het gedrag van Linus had bestudeerd en een theorie had ontwikkeld waarom dit gedrag succesvol was, nam ik een welbewuste beslissing om deze theorie op mijn nieuwe (en toegegeven: veel minder complexe en ambitieuze) project uit te testen. Maar het eerste wat ik deed was het uitgebreid reorganiseren en vereenvoudigen van popclient. Carl Harris’ implementatie was bijzonder solide, maar vertoonde een soort onnodige complexiteit die je veel ziet bij C-programmeurs. Hij behandelde de code als de spil en en de gegevensstructuren als ondersteunend aan de code. Het resultaat was dat de code beeldschoon was maar het ontwerp van de datastructuren was ad-hoc en nogal lelijk (althans in de ogen van deze oude LISP-hacker). Ik had echter nog een bedoeling met het herschrijven, naast het verbeteren van de code en de gegevensstructuren. Dat was om het in iets om te zetten dat ik volledig begreep. Het is niet erg leuk om verantwoordelijk te zijn voor het verhelpen van fouten in een programma dat je niet begrijpt. Gedurende de eerste maand of daaromtrent volgde ik simpelweg de implicaties van Carls’ basisopzet. De eerste serieuze wijziging die ik aanbracht was het toevoegen van IMAP ondersteuning. Ik deed dit door de protocol-machines om te vormen in een generieke besturingsmodule en drie methode-tabellen (POP2, POP3 en IMAP). Dit, en de eerder genoemde wijzigingen illustreren een generiek principe wat programmeurs goed in gedachten moeten houden, zeker bij talen als C die niet van nature aan dynamische types doen:

Brooks, hoofdstuk 9: “laat me uw [code] zien en verberg uw [data structuren], en ik blijf verward. Laat me uw [data structuren] zien en ik zal over het algemeen geen behoefte aan uw [code] hebben, die zal voor de hand liggen.” Hij zei eigenlijk ‘stroomdiagrammen’ en ‘tabellen’. Maar met inachtname van 30 jaren verschuiving in terminologie en cultuur is het bijna hetzelfde punt. Op dit punt aangekomen (begin september 1996, ongeveer zes weken na de start) begon ik te denken dat een naamswijziging op zijn plaats zou kunnen zijn – immers, het was nu niet alleen meer een POP-client. Maar ik aarzelde want er was nog niet veel echt nieuw aan het ontwerp. Mijn versie van popclient moest nog een eigen identiteit ontwikkelen. Dat veranderde, radicaal, toen fetchmail leerde hoe je mail kon doorsturen naar de SMTP poort. Ik kom daar straks op terug. Maar eerst: ik zei hiervoor al dat ik besloot om dit project te gebruiken om mijn theorie te testen omtrent de dingen die Linus Torvalds goed had gedaan. Hoe (zou u kunnen vragen) deed ik dat? Op deze manieren:

1. ik gaf de code veel en vaak vrij (bijna nooit minder dan eens per 10 dagen; gedurende perioden van intensieve ontwikkeling eens per dag);
2. ik liet mijn beta-lijst groeien door iedereen die me benaderde over fetchmail er op te zetten;
3. ik stuurde breedsprakige aankondigingen naar de beta-lijst wanneer ik code vrijgaf, waarin ik mensen aanmoedigde deel te nemen;
4. en ik luisterde naar mijn beta-testers, raadpleegde hen over ontwerp-beslissingen en aaide ze over hun bol wanneer ze wijzigingen en terugkoppeling toestuurden.

De beloning voor deze eenvoudige maatregelen kwam onmiddellijk. Vanaf het begin van het project kreeg ik foutrapporten van een kwaliteit waar de meeste ontwikkelaars een moord voor zouden plegen, vaak met goede oplossingen er aan gekoppeld. Ik ontving bedachtzame kritieken, ik kreeg fan-mail, ik kreeg intelligente suggesties voor nieuwe voorzieningen. Wat me brengt tot:

Een interessante maatstaf voor het succes van fetchmail is louter al de omvang van de beta-lijst van het project, fetchmail-friends. Ten tijde van schrijven had deze 249 leden en werden er 2 a 3 per week aan toegevoegd. [De volgende alinea heeft Eric er later aan toegevoegd -vert.] Momenteel, nu ik dit stuk reviseer aan het eind van mei 1997, begint de lijst leden te verliezen na zijn top van bijna 300 en wel om een interessante reden. Verschillende mensen hebben me gevraagd hen van de lijst te halen omdat fetchmail zo goed zijn werk voor hen doet dat ze de behoefte niet meer hebben om het verkeer op de lijst onder ogen te krijgen! Wie weet is dit onderdeel van de normale levencyclus van een volwassen bazaar-stijl project.

popclient wordt fetchmail

Het echte keerpunt in het project kwam toen Harry Hocheiser me wat wegwerpcode stuurde om mail naar de SMTP poort van de machine te kunnen sturen. Ik realiseerde me vrijwel onmiddellijk dat een betrouwbare implementatie van deze voorziening alle andere aflevermethoden zo goed als overbodig zou maken. Gedurende vele weken had ik fetchmail nogal stapsgewijs gekneed onderwijl het gevoel hebbend dat het ontwerp van de koppelvlakken onderhoudbaar maar wel smoezelig was – niet elegant en met teveel onbeduidende mogelijkheden die er aan alle kanten uitstaken. Met name de mogelijkheden om de opgehaalde post in een mailbox bestand te dumpen of naar standaard output te sturen zaten me dwars, maar ik kon niet uitvogelen waarom. Wat ik inzag toen ik nadacht over SMTP forwarding was dat popclient geprobeerd had om te veel dingen te doen. Het was opgezet om zowel een e-mail distributiesysteem te zijn (een mail transport agent, MTA) als een locale mailer (een mail delivery agent, MDA). Met SMTP forwarding eraan toegevoegd kon het programma zich terugtrekken uit de MDA-business en een pure MTA worden, die post doorgaf aan andere programma’s, zoals Sendmail dat ook doet. Waarom rommelen met alle complexiteit van het configureren van een lokale mailagent of met het opzetten van een lock-and-append op een lokale mailbox wanneer poort 25 op vrijwel elk platform met TCP/IP ondersteuning gegarandeerd toch al beschikbaar is? Zeker wanneer dit inhoudt dat de mail die je hebt opgehaald er uitziet als normale, door de afzender geïnitieerde SMTP post, wat immers werkelijk is wat we willen. Hier zijn meerdere lessen te leren. Ten eerste was het idee om SMTP-forwarding te gebruiken de grootste beloning die ik had gekregen door te proberen Linus’ methoden te gebruiken. Het was een gebruiker die me dit fantastische idee had gegeven – alles wat ik moest doen was de implicaties ervan te begrijpen.

Interessant genoeg zul je er spoedig achterkomen dat, als je er volledig en zonder jezelf te ontzien eerlijk over bent hoeveel je aan anderen te danken hebt, de wereld je over het algemeen behandelt alsof je elk stukje van de uitvinding zelf hebt gedaan en je je slechts bescheiden opstelt waar het je overduidelijke genialiteit betreft. We kunnen allen waarnemen hoe goed dit voor Linus heeft gewerkt! (Toen ik deze lezing gaf tijdens de Perl conferentie in augustus 1997, zat Larry Wall op de voorste rij. Toen ik bij de laatste regel van de vorige alinea aan was geland, riep hij luid uit, in de stijl van de Pinkstergemeente: “Tell it! Tell it, brother!”. Het hele publiek lachte omdat zij begrepen dat dit principe ook had gewerkt voor de uitvinder van Perl). Na slechts een paar weken het project in dezelfde geest geleid te hebben begon ik gelijksoortige loftuitingen te ontvangen, niet alleen van mijn gebruikers maar ook van andere mensen naar wie het nieuws was uitgelekt. Ik heb wat van die e-mail veilig opgeborgen; ik zal er nog eens naar kijken als ik me ooit af begin te vragen of mijn leven de moeite wel waard is geweest 🙂. Maar er zijn nog twee fundamentele, niet politieke lessen te leren die voor allerlei soorten ontwerp opgaan.

Ik had geprobeerd het verkeerde probleem op te lossen door door te gaan met het ontwikkelen van popclient als een gecombineerde MDA/MTA met allerlei fraaie lokale aflevermethoden. Fetchmails ontwerp moest opnieuw door worden gedacht, van meet af als pure MTA, als een onderdeel van de normale weg die e-mail op het Internet neemt: met gebruikmaking van het SMTP protocol. Als je tegen een muur oploopt tijdens de ontwikkeling – wanneer je merkt dat je het moeilijk hebt om voorbij de volgende stoplap te denken – is het vaak tijd om niet zozeer de vraag te stellen of je wel het goede antwoord hebt, maar meer of je de goede vraag wel stelt. Misschien moet het probleem opnieuw in beeld gebracht worden. Welnu, ik had mijn probleem opnieuw in beeld gebracht. Overduidelijk was het juist om (1) ondersteuning voor SMTP forwarding in de generieke besturingsmodule op te nemen, (2) dit de standaard werkwijze te maken en (3) uiteindelijk alle andere aflevermethoden buiten te smijten, met name de methode om naar een bestand te schrijven en de methode om naar standard output te schrijven. Ik aarzelde enige tijd betreffende de derde stap, uit angst dat ik langjarige gebruikers van popclient, die afhankelijk waren van de alternatieve aflevermethodes, van hun stuk zou brengen. In theorie konden ze onmiddellijk overgaan naar het gebruik van .forward bestanden of hun niet-Sendmail equivalenten en hetzelfde effect bereiken. In de praktijk zou de overgang wel eens rommelig kunnen worden. Maar toen ik het deed bleken de voordelen zeer groot te zijn. Het grootste deel van de besturingsmodule verdween. Het configureren werd een stuk eenvoudiger – niet meer rondfrutten op het systeem op zoek naar de lokale mailagent (MDA) of naar de mailbox van de gebruiker, geen zorgen meer of het onderliggende besturingssysteem wel filelocking ondersteunde. Ook verdween de enige manier waarop je mail kwijt kon raken. Als je eerder aflevering in een bestand had opgegeven en de schijf raakte vol, ging je post verloren. Dit kan niet gebeuren als je gebruik maakt van SMTP forwarding omdat de SMTP server niet ‘OK’ teruggeeft behalve als de boodschap kon worden bezorgd of tenminste in een wachtrij kon worden gezet voor latere bezorging. Ook ging de prestatie vooruit (alhoewel niet zoveel dat je het merkte bij een enkelvoudige uitvoering van het programma). En nog een niet onbetekenend voordeel van deze wijziging was dat de gebruikershandleiding [een Unix manual page -vert.] een stuk eenvoudiger werd. Later moest ik de lokale bezorgingswijze terug laten komen om het afhandelen van een aantal obscure situaties te verzorgen die te maken hadden met dynamische SLIP. Maar ik vond een veel eenvoudiger manier om het te doen. De moraal? Aarzel niet om overjarige voorzieningen weg te gooien als je het kunt doen zonder verlies van effectiviteit. Antoine de Saint-Exupery (die luchtvaartpionier en ontwerper van vliegtuigen was als hij tenminste niet bezig was met het schrijven van klassieke kinderboeken) zei:

Als uw code zowel beter als eenvoudiger wordt – dat is het moment wanneer u weet dat het goed zit. En gedurende het proces verwierf het fetchmail ontwerp een eigen identiteit, die verschilde van de voorouderlijke popclient. Het werd tijd voor de naamswijziging. Het nieuwe ontwerp leek meer op een dubbel van Sendmail dan de oude popclient; beide zijn MTA’s, maar waar Sendmail post overduwt en dan aflevert, trekt de nieuwe popclient post over en levert dan af. Dus, twee maanden na dato hernoemde ik het ‘fetchmail‘.

fetchmail wordt volwassen

Daar stond ik nu, met een leuk en innovatief ontwerp, code waarvan ik wist dat ze goed werkte omdat ik die elke dag gebruikte, en een uitpuilende beta lijst. Het werd me geleidelijk aan duidelijk dat ik niet langer betrokken was bij triviaal persoonlijk programmeer- werk dat misschien wel nuttig zou kunnen zijn voor een paar andere mensen. Ik had een programma onder handen wat elke hacker met een Unix doos en een SLIP/PPP verbinding werkelijk nodig heeft [3]. Door de toepassing van SMTP forwarding nam het voldoende voorsprong op de competitie om in aanleg een ‘category killer’ te worden, een van die klassieke programma’s die zijn functie zo kundig vervult dat de alternatieven niet alleen weg worden gedaan, maar zelfs bijna geheel worden vergeten. Ik denk dat je niet echt kunt richten of plannen op een dergelijk resultaat. Je moet er naar toe worden gezogen door ontwerpideeën die zo krachtig zijn dat naderhand de resultaten nu eenmaal onvermijdelijk, natuurlijk, ja zelfs voorbestemd lijken te zijn. De enige manier om op dergelijke ideeën te komen is: kunnen beschikken over veel ideeën – of door het hebben van het ingenieursoordeel dat de goede ideeën van andere mensen verder draagt dan de bedenkers ooit voor mogelijk hielden. Andrew Tanenbaum had het originele idee om een eenvoudige, simpele eigen Unix voor de 386 te schrijven, om als onderwijsgereedschap in te zetten. Linus Torvalds stuwde het Minix-concept verder voort dan naar alle waarschijnlijkheid Andrew voor mogelijk hield – en het ontwikkelde zich tot iets wonderschoons. Op dezelfde manier, (zij het op kleinere schaal), pikte ik wat ideeën van Carl Harris en Harry Hocheiser en stuwde ze met kracht voort. Geen van ons allen was ‘origineel’ op de romantische manier die mensen als geniaal zien. Maar anderzijds wordt het meeste ingenieurs- en ontwikkelwerk niet door een origineel genius gedaan, in tegenstelling tot wat de hacker-mythologie leert. De resultaten waren niettemin tamelijk onstuimig – in feite precies het soort succes waar elke hacker voor leeft! En dit betekende dat ik mijn standaard zelfs nog hoger moest stellen. Om fetchmail zo goed te maken als ik nu inzag dat het kon zijn, zou ik niet alleen meer moeten schrijven om in mijn eigen behoeften te voorzien, maar moest ik ook voorzieningen aanbrengen en ondersteunen die voor mensen buiten mijn kring nodig waren. En onderwijl het programma simpel en robuust houden. De eerste en verreweg meest belangrijke voorziening die ik schreef nadat ik me dit realiseerde was ondersteuning voor ‘multidrop’ – de mogelijkheid om elektronische post op te halen uit postbakjes waarin alle post voor een groep gebruikers was verzameld om dan elk mailtje naar de individuele ontvanger door te sturen. Ik besloot deels om multidrop te ondersteunen omdat sommige gebruikers er luidkeels om riepen, maar vooral omdat ik meende dat dit fouten uit de ‘single-drop’ code zou verjagen, omdat ik gedwongen werd me met het volledige veld rond adressering bezig te houden. En dit bleek waar te zijn. Het correct implementeren van het parsen conform RFC822 kostte me een opmerkelijk lange tijd, niet omdat elk individueel deel ervan moeilijk is, maar omdat er een berg onderlinge afhankelijkheden en wazige details mee waren gemoeid. Maar ook de ondersteuning van multi-drop bleek een uitmuntende ontwerpbeslissing te zijn. Dit is hoe ik er achter kwam:

De onverwachte inzet voor multidrop fetchmail bestaat eruit dat je mailing lists kunt gebruiken, waarbij de lijst word onderhouden en de alias expansie wordt uitgevoerd aan de ontvangende kant van de SLIP/PPP verbinding. Dit houdt in dat iemand die een persoonlijke machine heeft met toegang tot een ISP een mailing list kan onderhouden zonder toegang tot de alias lijst van de ISP [4]. Een andere belangrijke wijziging die door mijn beta-testers was aangevraagd was ondersteuning voor 8-bit MIME verwerking. Dit was tamelijk eenvoudig te doen omdat ik er voor had gewaakt de code ‘8 bit clean’ te houden. Niet omdat ik had verwacht dat deze mogelijkheid gevraagd zou gaan worden, maar meer gehoor gevend aan een andere regel:

Als ik me niet aan deze regel had gehouden zou de ondersteuning van 8 bits MIME moeizaam en vol fouten zijn geweest. Maar zoals het er nu voor stond hoefde ik alleen RFC 1652 maar te lezen, en een triviale hoeveelheid logica toe te voegen die zich bezig hield met de generatie van de headers. Een aantal Europese gebruikers viel me net zo lang lastig tot ik een optie inbouwde die de hoeveelheid boodschappen die je per sessie op kon halen beperkte (opdat ze de kosten van hun dure telefonienetwerken onder controle kunnen houden). Ik heb dit lange tijd tegen gehouden en ik ben er nog steeds niet helemaal gelukkig mee. Maar als je voor een wereldpubliek schrijft, moet je naar je klanten luisteren – ook als ze je niet geldelijk belonen.

nog een paar lessen van fetchmail

Voor we terugkeren bij de meer algemene zaken aangaande het bouwen en ontwerpen van software zijn er nog een paar specifieke lessen te trekken uit de ervaringen met fetchmail. De rc-bestandssyntax bevat optionele ‘ruis’ sleutelwoorden, die volledig worden genegeerd door de parser. De Engels-achtige syntax die dit toestaat is aanmerkelijk leesbaarder dan de traditionele beknopte sleutelwoord/waarde paren die je krijgt wanneer je de ruis er uit zou wegstrepen. Dit begon als een middernachtelijk experiment, toen ik bemerkte hoe zeer de rc-declaraties op een mini-commando-taal begonnen te lijken (dit is ook de reden waarom ik het originele sleutelwoord ‘server’ van popclient wijzigde in ‘poll’). Het leek me dat een poging om die mini-commando-taal meer op Engels te laten lijken het gebruik zou vereenvoudigen. Maar, hoewel ik een overtuigd aanhanger ben van de ‘maak er een taal van’ stroming binnen de ontwerpschool, met als voorbeelden Emacs en HTML en veel database kernsystemen, ben ik normaliter geen grote aanhanger van de ‘Engels-achtige’ syntaxen. Traditionele programmeurs negen er altijd toe om de voorkeur te geven aan controletalen die heel precies en beknopt waren en geen enkele redundantie kenden. Dit is een culturele erfenis uit de tijd dat verwerkingscapaciteit duur was, dus de onderdelen die zich bezig hielden met het parsen zo goedkoop en eenvoudig mogelijk moesten zijn. Engels, met zijn bij benadering 50% redundantie leek in die tijd een zeer slecht bruikbaar model. Dit is niet mijn reden om normaliter Engels-achtige structuren te vermijden; ik noem het hier alleen maar om het te kunnen ondermijnen. Nu we over goedkope verwerkingskracht en geheugen beschikken dient beknoptheid geen doel op zich meer te zijn. Het is heden ten dage belangrijker voor een taal om gemakkelijk in het gebruik te zijn voor mensen dan goedkoop voor de computer. Er zijn desalniettemin goede redenen om op je hoede te blijven. Een ervan zijn de nadelen van de complexiteit van de parsercode: je wil deze niet opvoeren tot het punt waar deze op zich al een significante bron van fouten en verwarring bij de gebruiker wordt. Een andere reden is dat een poging om een taal op Engels te laten lijken vaak vereist dat het ‘Engels’ wat er wordt gesproken ernstig uit zijn model wordt gebogen, en wel zozeer dat de kunstmatige gelijkenis met de natuurlijke Engelse taal net zo verwarrend is als de traditionele syntax zou zijn geweest. (Je ziet dit veel bij zogenaamde “vierde-generatie” en commerciële database uitvraagtalen.) De controlesyntax van fetchmail lijkt deze problemen te omzeilen omdat het taaldomein extreem beperkt is. Het komt niet in de buurt van een algemeen inzetbare taal; de dingen die je er mee kunt zeggen zijn eenvoudigweg niet erg gecompliceerd, dus is er weinig potentieel voor verwarring wanneer je je mentaal tussen een beperkte subset van het Engels en de eigenlijke controletaal beweegt. Ik vermoed dat hier een algemenere les te trekken is:

Een andere les gaat over veiligheid door verborgenheid. Een aantal fetchmail gebruikers vroegen me de software zo te wijzigen dat de wachtwoorden versleuteld in het rc bestand zouden worden opgeslagen, opdat snuffelaars niet in staat zouden zijn om deze zo maar te zien. Ik deed dit niet, omdat het feitelijk geen bescherming toevoegt. Een ieder die de permissies heeft om je rc bestand te lezen kan fetchmail toch al onder je identiteit opstarten – en als men achter uw wachtwoord aan zou zitten zou men in staat zijn om de noodzakelijke decoder zo uit de fetchmail decoder te plukken om er achter te komen. Het enige waar wachtwoordversleuteling binnen fetchmail toe zou hebben geleid zou een vals gevoel van veiligheid zijn bij mensen die niet zo goed nadenken [6]. De generieke regel hier luidt:

Noodzakelijke randvoorwaarden voor de bazaarstijl

De eerste redacteuren en het testpubliek voor dit geschrift wierpen consistent vragen op over de randvoorwaarden om tot succesvol ontwikkelen volgens de bazaarstijl te komen, inbegrepen zowel de kwalificaties van de projectleider als de staat waarin de code zich bevind op het moment dat je publiek gaat en je probeert een gemeenschap van medeontwikkelaars op te zetten. Het is tamelijk duidelijk dat je niet van meet af in bazaarstijl kunt coderen. Men kan testen, ontluizen en verbeteren in bazaarstijl, maar het zou heel moeilijk zijn om een project te beginnen in de bazaarstijl. Linus probeerde het niet. Ik ook niet. Je ontluikende ontwikkelgemeenschap heeft behoefte aan iets wat al loopt en wat je kunt testen om mee te spelen. Als je begint met het opbouwen van een gemeenschap, dien je te beschikken over een redelijke belofte. Je programma hoeft niet bijster goed te werken. Het mag ruw opgezet zijn, vol fouten zitten, incompleet zijn en slecht gedocumenteerd. Het mag echter niet falen om potentiële medeontwikkelaars er van te overtuigen dat het kan evolueren naar iets heel aardigs in de afzienbare toekomst. Linux en fetchmail gingen beiden publiek met sterke, aantrekkelijke basisontwerpen. Veel mensen die nadenken over het bazaarmodel zoals ik het heb gepresenteerd hebben dit terecht als kritisch gezien, om dan tot de conclusie te komen dat een hoge mate van ontwerpintuitie en slimheid van de projectleider onmisbaar is. Maar Linus verkreeg zijn ontwerp van Unix. Ik kreeg het mijne oorspronkelijk van de voorouderlijke popclient (al zou dit later nogal wijzigen, in verhouding veel meer dan Linux deed). Dus, moet de leider van een inspanning in de bazaarstijl werkelijk een uitzonderlijk ontwerptalent hebben of kan hij zich ook redden door het ontwerptalent van anderen als hefboom te gebruiken? Ik meen dat het niet kritiek is dat de coördinator in staat is om ontwerpen uit te denken van uitzonderlijke briljantie, maar het is absoluut noodzakelijk dat de coördinator in staat is om goede ontwerpideeën van anderen te herkennen. Zowel het Linux- als het fetchmail project leveren hier bewijs voor. Linus, die (zoals eerder besproken) dan wel niet een bijzonder spectaculair oerontwerper is, heeft laten zien dat hij er krachtig slag van heeft om goed ontwerp te herkennen en te integreren in de Linux kernel. En ik heb al beschreven hoe het meest krachtige ontwerpprincipe in fetchmail (SMTP forwarding) afkomstig was van iemand anders. De eerste lezers van dit stuk complimenteerden me door te suggeren dat ik er last van heb originaliteit in bazaarstijl projecten onder te waarderen omdat ik er zelf veel van heb en het dus voor lief neem. Daar kan wel iets inzitten; ontwerp (in tegenstelling tot programmeren of foutzoeken) is zeker mijn sterkste kant. Maar het probleem met slim zijn en oorspronkelijk in je softwareontwerp is dat het een gewoonte wordt – je begint in een reflex dingen ‘leuk’ en complex te maken waar je er beter aan deed het robuust en simpel te houden. Ik heb projecten zien neerstorten (op mij) omdat ik die fout maakte, maar ik kreeg het voor elkaar dat niet bij fetchmail te doen. Dus neem ik aan dat het fetchmail project deels lukte omdat ik mijn neiging om een slimmerik te zijn onderdrukte; dit spreekt (tenminste) tegen de noodzaak dat je ontwerp origineel moet zijn binnen een in bazaarstijl uitgevoerd project. En kijk eens naar Linux. Veronderstel dat Linus Torvalds had geprobeerd om het voor elkaar te krijgen dat er fundamentele innovaties in het ontwerp zouden komen tijdens de ontwikkeling; komt het u dan enigermate plausibel voor dat de resulterende kernel zo stabiel en succesvol zou zijn als die die we nu hebben? Een basale ontwerp- en codeervaardigheid is uiteraard vereist, maar ik verwacht dat bijna iedereen die er over denkt om een bazaartype inspanning te lanceren al boven dat minimum zit. De interne markt van de Open Source gemeenschap heeft de reputatie dat er subtiele druk wordt uitgeoefend op mensen om geen ontwikkelinspanningen te initiëren als ze niet competent zijn om het zelf bij te benen. Dit lijkt tot nu toe heel aardig gewerkt te hebben. Er is nog een soort vaardigheid die normaliter niet wordt geassocieerd met de ontwikkeling van programmatuur, maar waarvan ik meen dat deze net zo belangrijk is voor een bazaarstijl project als een slim ontwerp – en het zou wel eens belangrijker kunnen zijn. De coördinator van een bazaarstijl project moet goed met mensen overweg kunnen en goed kunnen communiceren. Dat zou voor zichzelf moeten spreken. Om een ontwikkelgemeenschap op te bouwen moet je mensen aantrekken, ze interesseren in wat je aan het doen bent en hen tevreden houden over de hoeveelheid werk die ze moeten verzetten. De technische prikkeling zorgt er grotendeels voor dat je dit voor elkaar krijgt, maar het is beslist niet het hele verhaal. De persoonlijkheid die je laat zien doet er ook toe. Het is geen toeval dat Linus een aardige kerel is die ervoor zorgt dat mensen hem mogen en hem willen helpen. Het is geen toeval dat ik een energieke extrovert ben die er van houdt om zijn publiek te bespelen en die in presentatie en instinct lijkt op een straatkomiek. Om het bazaar model te laten werken, helpt het enorm als je minstens een beetje talent hebt om mensen voor je in te nemen.

De sociale context van open source software

Het staat geschreven en gedrukt dat de beste programma’s beginnen als persoonlijke oplossingen voor de dagelijkse problemen van de auteur en zich verder verspreiden omdat het probleem typisch blijkt te zijn voor een grote groep gebruikers. Dit brengt ons terug bij de inhoud van regel 1, opnieuw geformuleerd op een denkelijk meer zinvolle wijze:

Zo ging het met Carl Harris en de voorouderlijke popclient, en zo verging het mij met fetchmail. Maar dit werd al lange tijd zo gezien. Het interessante punt, het punt waar de geschiedenissen van Linux en fetchmail onze aandacht op lijken te willen vestigen is het volgende stadium – de ontwikkeling van programmatuur in de nabijheid van een grote en actieve gemeenschap van gebruikers en mede-gebruikers. In “The Mythical Man-Month” neemt Fred Brooks waar dat de tijd van een programmeur niet te vervangen is; het toevoegen van meer ontwerpers aan een vertraagd softwareproject laat het later eindigen. Hij argumenteerde dat de complexiteit en de kosten voor communicatie van een project kwadratisch toenamen met het aantal ontwikkelaars, terwijl het werk wat wordt verzet slechts lineair toeneemt. Deze uitspraak is sedertdien bekend geworden als “de wet van Brooks” en in brede kring wordt geaccepteerd dat er een kern van waarheid in schuilt. Maar als de wet van Brooks het complete plaatje zou vormen, zou Linux niet mogelijk kunnen zijn. Een paar jaar later voorzag Gerald Weinberg’s klassieker “The Psychology Of Computer Programming” in wat we naderhand beschouwd kunnen zien als een essentiële correctie op het werk van Brooks. In zijn beschouwing over “egoless programming” [egoloos programmeren – vert.] nam Weinberg waar dat bij bedrijven waar de programmeurs niet op hun code zitten en andere mensen aanmoedigen om erin op zoek te gaan naar fouten en mogelijke verbeteringen, deze verbeteringen dramatisch sneller tot stand komen dan elders. Weinberg’s keuze van terminologie heeft wellicht voorkomen dat zijn analyse de acceptatie verkreeg die deze verdiende – het werkt wel wat op de lachspieren als iemand Internet hackers als ‘egoloos’ omschrijft. Maar ik denk dat het punt dat hij maakt vandaag de dag meer dan ooit tot de verbeelding spreekt. De geschiedenis van Unix zou ons moeten hebben voorbereid op wat we van Linux leren (en wat ik experimenteel op een kleinere schaal heb geverifieerd door opzettelijk Linus’ methoden te kopieëren). Namelijk dat, hoewel het coderen een voornamelijk solitaire activiteit blijft, de werkelijk goede programma’s voortkomen uit het kunnen vasthouden van de aandacht en denkkracht van een hele gemeenschap. De ontwikkelaar die alleen zijn eigen brein gebruikt in een gesloten project zal achterraken op de ontwikkelaar die weet hoe je een open, evolutionaire context schept waarin het opmerken van fouten en het aanbrengen van verbeteringen door honderden mensen wordt gedaan. Maar de traditionele Unix wereld werd door diverse factoren gehinderd deze aanpak tot haar limiet te drijven. Een hiervan werd gevormd door de legale beperkingen die zijn verbonden aan de diverse licenties, handelsgeheimen en commerciële belangen. Een andere (in retroperspectief) was dat het Internet nog niet voldoende goed was. Voor de dagen van het goedkope Internet waren er al wat geografisch dicht bijeengelegen gemeenschappen waar de cultuur Weinbergs’ “egoloos programmeren” stimuleerde en waarin een ontwikkelaar makkelijk een groot aantal geschoolde toeschouwers en medeontwikkelaars kon aantrekken. Bell laboratorium, het MIT AI laboratorium, de universiteit van Califoria Berkeley werden de thuishaven voor innovaties die legendarisch zijn en tot op de dag van vandaag potentie hebben. Linux was het eerste project dat een gewetensvolle en succesvolle poging deed om de hele wereld als haar bron van talenten te gebruiken. Ik geloof niet dat het toeval is dat de vormingsperiode van Linux samenviel met de geboorte van het World Wide Web en dat Linux de kinderschoenen ontgroeide gedurende dezelfde periode in 1993-1994 die getuige was van de opkomst van de bedrijfstak van de Internet Service Providers en de explosie van de algemene interesse in het Internet. Linus was de eerste mens die leerde hoe je het spel moest spelen volgens de nieuwe regels die mogelijk werden door het zich doorzettende Internet. Alhoewel goedkoop Internetten een noodzakelijke randvoorwaarde was voor het Linux model om zich te ontwikkelen, meen ik dat dit op zichzelf niet de enig noodzakelijke randvoorwaarde was. Een andere factor van belang was de ontwikkeling van een leiderschapsstijl en een stelsel van gebruiken rond samenwerking dat ontwikkelaars in staat konden stellen mede-ontwikkelaars aan te trekken en die zo het maximale uit het medium konden halen. Maar waaruit bestaat deze leiderschapsstijl en waaruit bestaan die gebruiken? Ze kunnen niet gebaseerd zijn op gezagsverhoudingen en zelfs als ze dat waren, zou een op dwangmatige samenwerking gebaseerde leiderschapsstijl niet de resultaten kunnen opleveren die we zien. Betreffende dit onderwerp haalt Weinberg met succes de autobiografie van de 19e eeuwse Russische anarchist Piotr Alexeyvich Kropotin aan (“Memoires van een Revolutionair”): “Opgegroeid in een familie die lijfeigenen bezat begon ik mijn bewuste leven, zoals alle jonge mannen van mijn tijd, met een groot vertrouwen in de noodzaak tot commanderen, orders geven, schelden, straffen en dergelijke. Maar toen ik al vroeg serieuze bedrijven moest leiden en moest leren werken met (vrije) mannen, en toen elke vergissing onmiddellijk zou leiden tot serieuze consequenties, begon ik het verschil te waarderen tussen het acteren op het principe van commando en discipline en het acteren op basis van gedeelde inzichten. Het eerste werkt bewonderenswaardig in een militaire parade, maar is niets waard waar het het werkelijke leven aangaat; het doel kan alleen bereikt worden middels de aanzienlijke inspanning van vele samengebalde willen.” Deze “aanzienlijke inzet van vele samengebalde willen” is precies wat is vereist voor een project als Linux – en het “principe van commando” is effectief onmogelijk toe te passen op vrijwilligers in dat anarchistisch paradijs wat we “het Internet” noemen. Om effectief te kunnen opereren en concurreren dienen programmeurs die goed samenwerkende projecten willen leiden te leren hoe je effectieve interesse-gemeenschappen werft en van energie voorziet op de manier die enigszins wordt gesuggereerd door Kropotkin’s “principe van gedeelde inzichten”. Ze moeten leren hoe ze de wet van Linus moeten gebruiken. Eerder refereerde ik aan het “Delphi effect” als een mogelijke verklaring voor de wet van Linus. Maar nog krachtiger analogieën met adaptieve systemen in de biologie en de economie dringen zich onweerstaanbaar op. De Linux wereld gedraagt zichzelf in veel opzichten als een vrije markt of ecosfeer, een verzameling van zelfzuchtige rentmeesters die proberen de bruikbaarheid te maximaliseren, wat er gelijktijdig voor zorgt dat er een zichzelf corrigerende spontane rangorde ontstaat die meer uitgebreid en efficiënt is dan welke hoeveelheid gecentraliseerde planning ooit bereikt zou kunnen hebben. Welnu, hier is de plaats om te zoeken naar het “principe van gedeelde inzichten”. De “bruikbaarheids functie” die door Linux programmeurs tot het uiterste wordt gevoerd is niet op de klassieke wijze economisch, maar is onontwarbaar verstrikt met de bevrediging van hun ego en hun reputatie bij andere hackers. (Je kunt hun motivatie best “altruïstisch” noemen, maar dat gaat voorbij aan het feit dat altruïsme op zichzelf een vorm van bevrediging voor het ego van de altruïst is). Op vrijwilligheid gebaseerde culturen die op deze wijze werken zijn in werkelijkheid niet ongebruikelijk; een andere waar ik sedert lang in participeer is die van de science fiction aanhangers, waar in tegenstelling tot de cultuur van de hackers de “egoboo” [ego boost -vert.] (het uitbouwen van de eigen reputatie onder andere fan’s) expliciet wordt erkend als de basale drijfkracht achter de vrijwilligersactiviteiten. Door zichzelf met succes op te werpen als de poortwachter van een project waarin de ontwikkeling merendeels door anderen wordt gedaan, en door de aandacht voor het project op te voeren tot het project zichzelf kon onderhouden, heeft Linus een acuut begrip van Kropotkin’s “principe van gedeelde inzichten” getoond. De kwasi-economische zienswijze van de Linuxwereld stelt ons in staat om te begrijpen hoe dit inzicht toe wordt gepast. We kunnen Linus’ methode beschouwen als een manier om een efficiënte “egoboo”-markt te scheppen – het egoïsme van de individuele programmaschrijvers zo stevig mogelijk onderling te verbinden om moeilijke doelen te bereiken die uitsluitend bereikt kunnen worden door voortdurende samenwerking. Met het fetchmail project heb ik (zij het op kleinere schaal) aangetoond dat zijn methoden gedupliceerd kunnen worden met goede resulaten. Wellicht heb ik het zelfs wat bewuster en meer systematisch gedaan dan hij. Veel mensen (met name degenenen die vrije markten wantrouwen vanuit een politieke visie) zouden verwachten dat een cultuur van op zichzelf gerichte egoïsten gefragmenteerd zou zijn, territoriaal, verspillend, geheimzinning, en vijandig. Maar deze verwachting wordt duidelijk ontkrachtigd door, om maar eens wat te noemen, de verbijsterende variëteit, kwaliteit en diepte van de Linux documentatie. Het is een geheiligd gegeven dat programmeurs de pest hebben aan documenteren; hoe kan het dan dat de Linux hackers er zoveel aan doen? Het is duidelijk dat de vrije Linux “egoboo”-markt beter werkt als het gaat om het produceren van deugdzaam, op anderen gericht gedrag dan de massief met middelen ondersteunde documentatie-afdelingen van commerciële softwarebouwers. Zowel het fetchmail project en het Linux kernel project tonen aan dat, door het naar behoren belonen van de ego’s van vele andere hackers, een sterke ontwikkelaar/coördinator het Internet kan gebruiken om het voordeel te hebben van vele medeontwikkelaars zonder een project in een choatische rommel te laten ontaarden. Dus stel ik de volgende anti-stelling op de wet van Brooks voor:

Ik denk dat de toekomst van de open-source software in toenemende mate in de handen zal komen te liggen van mensen die weten hoe je Linus’ spel moet spelen, mensen die de kathedraal achter zich laten en de bazaar omhelzen. Dit wil niet zeggen dat de visie en briljantie van het individu er niet langer toe doen: ik denk veeleer dat het snijvlak van de open source software toebehoort aan mensen die beginnen vanuit hun individuele briljantie en visie, om die vervolgens te versterken middels de constructie van vrijwilligersgemeenschappen van belang. En mogelijk niet alleen de toekomst van open source software. Geen commercieel ontwikkelaar kan op tegen de vloedgolf van talent die de Linux gemeenschap los kan laten op een probleem. Slechts zeer weinigen kunnen zich zelfs veroorloven om de meer dan tweehonderd mensen in te huren die bij hebben gedragen aan fetchmail! Wie weet zal de open source cultuur uiteindelijk overwinnen, niet zozeer omdat coöperatie moreel correct is, of het op je software “zitten” moreel incorrect (er van uit gaande dat je het laatste gelooft, wat noch Linus, noch ik doen), maar eenvoudigweg omdat de commerciële wereld een evolutionaire wapenwedloop met de open-source gemeenschap – die immers vele malen meer geschoolde tijd in een probleem kan steken – niet kan winnen.

Dankbetuigingen

Dit werk verbeterde door de gesprekken met een grote hoeveelheid mensen die hielpen bij het foutzoeken. In het bijzonder dank ik Jeff Dutky [lt]dutky@wam.umd.edu>, die de formulering “foutzoeken is parallelizeerbaar” voorstelde en die hielp bij het opzetten van de analyse die er uit voortkomt. Ook Nancy Lebovitz [lt]nancy@universe.digex.net> voor haar suggestie Weinberg te emuleren door Kropotkin te citeren. Perceptieve kritieken waren ook afkomstig van Joan Eslinger [lt]wombat@kilimanjaro.engr.sgi.com> en Marty Franz [lt]marty@net-link.net> die op de “General Technics” lijst staan. Paul Eggert [lt]eggert@twinsun.com> merkte het conflict tussen de GPL en het bazaar model op. Ik ben de leden van de PLUG dankbaar, de Philadelphia Linux Users Group, dat zij het eerste testpubliek voor de eerste versie van dit geschrift leverden. Tenslotte waren Linus Torvalds’ commentaren behulpzaam en zijn vroegtijdige aanmoedigingen zeer bemoedigend.

Als u meer wilt lezen

Ik heb diverse stukken geciteerd uit Frederick P. Brooks’ klassieker “The mythical Man-Month”, omdat, in veel opzichten, zijn inzichten nog steeds niet zijn overtroffen. Ik beveel de 25-jarige jubileumsuitgave van harte aan, welke verscheen bij Addison-Wesley (ISBN 0-201-83595-9) en waaraan zijn in 1986 verschenen artikel “No Silver Bullet” werd toegevoegd. De nieuwe editie wordt afgesloten door een van onschatbare waarde zijnde terugblik-na-20-jaren, waarin Brooks grif toegeeft dat er een aantal beoordelingsfouten in de oorspronkelijke tekst voorkwamen die de tand des tijds niet konden doorstaan. Ik las deze nabeschouwing pas nadat ik dit geschrift grotendeels had voltooid en was verrast dat Brooks bazaar-achtige kenmerken toeschrijft aan Microsoft! Gerald M. Weinbergs’ “The Psychology Of Computer Programming” (New York, Van Nostrand Rheinhold 1971) introduceerde het nogal ongelukkig geformuleerde concept van het “egoloos programmeren”. Hoewel hij zeker niet de eerste was die zich de nutteloosheid van het “principe van commando” realiseert, was hij waarschijnlijk de eerste die dit punt herkende in verbinding met de ontwikkeling van programmatuur. Richard P. Gabriel, de Unix cultuur van voor het Linux-tijdperk beschouwend, pleitte aarzelend voor de superioriteit van een primitief bazaar-achtig model in zijn geschrift uit 1989 “Lisp, Good News, Bad News and How To Win Big”. Hoewel wat gedateerd in een aantal opzichten wordt dit werk nog steeds met reden door Lisp-aanhangers (waaronder ik) gevierd. Iemand waarmee ik schrijf herinnerde me er aan dat het deel met de titel “Worse is Better” bijna leest als een anticipatie op Linux. Dit geschrift is via het World Wide Web toegankelijk: >http://www.naggum.no/worse-is-better.html[lt] De Marco en Listers’ “Peopleware: Productive Projects and Teams” (New York; Dorset House, 1987; ISBN 0-932633-05-6) is een ondergewaardeerd juweeltje waarvan ik met verrukking constateerde dat Fred Brooks het aanhaalt in zijn nabeschouwing. Hoewel weinig van hetgeen de schrijvers te zeggen hebben direct van toepassing is op de Linux- of Open Source gemeenschappen, zijn de inzichten van de auteur in de randvoorwaarden om creatief werk te kunnen verzetten actueel en de moeite waard voor een ieder die probeert om iets van de deugden van het bazaarmodel in een meer commerciële context in te zetten. Tenslotte moet ik toegeven dat ik dit werk bijna “De Kathedraal en de Agora” had genoemd, welke laatste term Grieks is voor een open markt of een publiek toegankelijke ontmoetingsplaats. De veelbelovende geschriften over “agorische systemen” door Mark Miller en Eric Drexler, waarin de eigenschappen van opkomende markt-achtige computerecologieën werden beschreven, hielpen me bij de voorbereiding om helder te kunnen nadenken over overeenkomende verschijnselen in de Open Source cultuur toen ik daar door Linux vijf jaar later met mijn neus op werd gedrukt.

Epiloog: Netscape omarmt de bazaar!

Het voelt vreemd als je je realiseert dat je meehelpt geschiedenis te schrijven.. Op 22 januari 1998, bij benadering 7 maanden nadat ik dit werk voor de eerste keer had uitgebracht, kondigde Netscape Communications Inc. aan dat ze plannen had om de broncode van de Netscape communicator weg te geven. Zie [lt]http://www.netscape.com/newsref/pr/newsrelease558.html>. Ik had geen idee dat dit zou gaan gebeuren tot op de dag van de aankondiging. Eric Hahn, uitvoerend onderpresident en hoofd technologie bij Netscape, stuurde me kort daarop een e-mailtje wat als volgt luidde: “Namens iedereen bij Netscape wil ik u danken om ons te helpen zelfs maar op dit punt aan te landen. Uw gedachten en geschriften waren fundamentele inspiratiebronnen voor onze beslissingen.” De week daarop vloog ik naar Silicon Valley, op uitnodiging van Netscape, voor een strategische conferentie van een dag (4 februari 1998) met een aantal van hun hoogste leidinggevenden en toptechneuten. We stelden samen Netscape’s vrijgave beleid en hun licentie op en broedden meer plannen uit waarvan we hopen dat ze uiteindelijk verstrekkende en positieve gevolgen zullen hebben op de Open Source gemeenschap. Terwijl ik dit schrijf is het nog wat te vroeg om meer specifiek te zijn, maar de details zouden binnen enkele weken bekend moeten worden. Netscape staat op het punt om ons te voorzien van een test op grote schaal van het bazaar model, die in de werkelijke wereld plaats zal vinden. De Open Source cultuur ziet nu een gevaar onder ogen; als de uitvoering van Netscape niet werkt zou het Open Source concept zo in diskrediet gebracht kunnen worden dat de commerciële wereld er voor zeker nog een decennium niet aan wil. Anderzijds biedt het ook een spectaculaire kans. De eerste reacties op het besluit op Wall Street en elders waren gematigd positief. We krijgen ook de kans om ons te bewijzen. Als Netscape door dit besluit substantieel wint aan marktaandeel zou dit wel eens al lang noodzakelijke revolutie in de computer industrie kunnen veroorzaken. Het komende jaar zou een heel instructieve en interessante tijd moeten zijn.

Versie en wijzigingshistorie

I gave 1.16 at the Linux Kongress, May 21 1997.
I added the bibliography July 7 1997 in 1.20.
I added the Perl Conference anecdote November 18 1997 in 1.27.
I changed “free software” to “open source” February 9 1998 in 1.29.
I added “Epilog: Netscape Embraces the Bazaar!” on February 10 1998 in 1.31.
Other revision levels incorporate minor editorial an markup fixes.
Eerste concept van de Nederlandse vertaling voltooid op 15 juli 1998.
Redactie en eerste publicatie van de Nederlandse vertaling 19 augustus 1998.
Rogier Wolff wees me er op dat de door mij toegevoegde voetnoot (oorspronkelijk genummerd ‘[6]’) betreffende eenwegsversleuteling van het password vanuit een foute aanname was opgesteld. Deze voetnoot is door mij verwijderd – met dank aan Rogier – 30 october 1998.
Ivo Jansch wees er op dat ik Eric’s naam hier en daar fout spelde als ‘Erik’. Dank je, Ivo 🙂 – 10 november 1998.
Uiteindelijk kwam Hans Bezemer met een veel betere vertaling van de “Turing-complete” zin. Opgenomen en daar ook voetnoot 5 aangepast – 27 april 2004.
Gerard Havik ontdekte nog een hinderlijke tikfout in de URL die zou moeten wijzen naar “Worse is Better” – hersteld op 5 november 2005.

Aantekeningen van de vertaler

Dit stuk is door mij vertaald in het Nederlands omdat ik meen dat de optiek van Eric voor wat betreft de ontwikkelingsmethodiek die hij beschrijft juist en waardevol is. En uiteraard omdat ook ik gevoelig ben voor “egoboo” 🙂 Het deel van het Nederlandse publiek wat in deze materie is geïnteresseerd is over het algemeen goed in staat om ook het originele Engelse geschrift te lezen, iets wat ik u overigens aan kan raden. Maar ervaring leert me dat een vertaling in de eigen taal wat makkelijker wegleest, met name in treincoupe’s of ‘s avonds op de bank, de plaatsen waar de managers van deze wereld vaak nog hun laatste stukken van die dag doornemen. Verder wordt dit stuk nu ook toegankelijk voor degenen wier kennis van de (technische) Engelse taal (net) ontoereikend is. Ik heb geprobeerd om de schrijfstijl van Eric zo veel mogelijk in stand te houden, al heeft dat in mijn eigen ogen als nadeel dat de zinnen af en toe wat wollig zijn geworden. Eric heeft de typisch Amerikaanse gewoonte om veel gebruik te maken van bijvoegelijke naamwoorden en hij maakt hele lange zinnen – leest u bijvoorbeeld de eerste alinea van deze vertaling maar eens. Ik sta zeer open voor suggesties om dit stuk te verbeteren, maar vraag u wel vriendelijk om, indien u deze suggesties doet, het originele stuk als uitgangsmateriaal te gebruiken, om te voorkomen dat de vertaling te ver gaat afwijken van het origineel. Tenslotte: veel van mijn aantekeningen hieronder gaan niet over Eric’s theorieën over softwareontwikkeling, maar over puur technische zaken, waar ik als system engineer van mening verschil met Eric, of waar ik een alternatieve oplossing voor een technisch probleem denk te kunnen suggereren. Ik hoop dat Eric het me niet al te zeer kwalijk neemt dat ik op deze details inga, maar het was sterker dan ik 😉 [1] zelf maak ik in deze situatie gebruik van UUCP. UUCP is ook vrij verkrijgbaar en werkt naadloos samen met Sendmail. Het is mogelijk om UUCP over TCP/IP te gebruiken. Uiteraard moet de ISP dan wel het UUCP protocol ondersteunen, in Nederland zijn er gelukkig nog diverse providers die dit doen, e.g. IAF . De problemen die Eric hieronder verder beschrijft treden bij het gebruik van UUCP in combinatie met Sendmail niet op. [2] Eric stelt dat hij de broncode eenvoudiger moest maken, want die was te complex. In de volgende paragraaf wordt echter Eric’s ‘echte’ doel van dit herschrijven duidelijk: het gaat er om dat hij de code kon begrijpen. [3] zie [1] [4] Inderdaad, het zou wat uitzonderlijk zijn dat een klant van een ISP toegang kreeg tot de alias files van die ISP. ISP’s hebben wel vaak een dienst waarmee je bij de ISP een mailinglist op kunt zetten. Maar voor degenen die toch al een Unix machine hebben geïnstalleerd en ook nog voldoende kennis en ervaring hebben om de PPP verbinding met de ISP werkend te krijgen is het geen enkel probleem om UUCP te implementeren en een eigen Sendmail configuratie te onderhouden. Ik houd staande dat het in die situatie het eenvoudigst is om post per UUCP over te halen, deze post dan in de lokale Sendmail in te voeren en dus het eigen alias file te gebruiken om ‘mailinglists’ te onderhouden. Maar dan ben je er nog niet: je wilt bij voorkeur ook dat mensen zelf kunnen bepalen of ze wel of niet op je mailinglijst staan, daar wil je als lui maar efficiënt mens geen werk aan hebben. Er zijn hiervoor diverse mailinglist programma’s die naadloos met Sendmail integreren, bijvoorbeeld ListProcessor van Anastasios Kotsikonas. Een bijkomend voordeel van het gebruik van UUCP is trouwens ook dat je het protocol veel breder kunt inzetten dan alleen maar voor elektronische post. Gegeven dat je ISP dit ondersteund, kun je het ook gebruiken om Usenet news over te halen (in feite elk soort file trouwens). Verder is het protocol zeer efficient: er zijn bi-directionele werkwijzen ge-implementeerd, waardoor je dus gelijktijdig kunt zenden en ontvangen. Dit limiteert de verbindingstijd tot het minimale – heel belangrijk als je niet zo’n snel modem hebt of als je een heel beperkt budget hebt. Als je alleen maar behoefte hebt aan news en e-mail is het gebruik van UUCP zonder PPP/SLIP zelfs zeer aan te raden: dit is een gegarandeerd veilige manier om met het Internet verbinding te maken. [5] de zin luidt origineel: ‘When your language is nowhere near Turing-complete, syntactic sugar can be your friend’. Ik kon geen goede vertaling vinden en had er van gemaakt “Als je taal de volledigheid van een Turing machine niet benadert, kan syntactische suiker een vriend zijn”. Bah. Gelukkig kwam Hans Bezemer met een veel betere vertaling, waarvoor mijn hartelijke dank. [6] ik verschil van mening met Eric over deze uitspraak. Zelfs als iemand met moeite achter het wachtwoord van iemand anders kan komen, is dat in mijn ogen altijd nog een stuk beter dan het plaintext opslaan van de wachtwoorden in een – in ieder geval voor de superuser – leesbaar bestand. Henk Klöpping Slochteren, 15 juli 1998.