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ëen 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
- De kathedraal en de bazaar
- De post moet doorgestuurd
- Het belang van het hebben van gebruikers
- Geef vroeg en vaak vrij
- Wanneer is een roos geen roos?
- Popclient wordt fetchmail
- Fetchmail wordt volwassen
- Nog een paar lessen van fetchmail
- Noodzakelijke randvoorwaarden voor de bazaar stijl
- De sociale context van Open Source software
- Dankbetuigingen
- Als u meer wilt lezen
- Epiloog: Netscape omarmt de bazaar!
- Versie en wijzigingshistorie
- 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
produktiever 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 - u kunt deze bekijken door te telnetten naar
locke.ccil.org <telnet://locke.ccil.org>.
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[1].
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:
1. |
Elk goed stuk software begint als middel tegen de
persoonlijke jeuk van een programmeur.
|
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:
2.
|
Goede programmeurs weten wat ze moeten schrijven. Hele goede
weten wat ze moeten herschrijven (en hergebruiken).
|
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
<http://www.earthspace.net/~esr/faqs/linus>
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
<http://www.imap.org>
(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.
3.
|
Ga er van uit dat je er een moet weggooien, dat doe je
toch (Fred Brooks, "The mythical Man-Month", hoofdstuk 11).
|
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:
4.
|
Als je de juiste instelling hebt, vinden interessante problemen je.
|
Maar de instelling van Carl Harris was nog belangrijker. Hij begreep
het volgende:
5. |
als je de interesse in een programma verliest is je laatste taak
om het te overhandigen aan een competente opvolger.
|
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.
6.
|
Uw gebruikers behandelen als mede-onwikkelaars is uw meest
ongecompliceerde weg naar snelle verbetering van de code en
naar effectief ontluizen.
|
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
<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:
7.
|
Geef vroeg vrij. Geef vaak vrij. En luister naar je klanten.
|
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:
8.
|
Gegeven een voldoende grote omvang van beta-testers en ontwikkelaars
kan bijna elk probleem snel worden benoemd en is de oplossing ervan
voor iemand voor de hand liggend.
|
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 <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[2].
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:
8.
|
Slimme datastructuren en domme code werken een stuk beter dan
andersom.
|
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:
ik gaf de code veel en vaak vrij (bijna nooit minder dan eens
per 10 dagen; gedurende perioden van intensieve ontwikkeling eens
per dag);
- ik liet mijn beta-lijst groeien door iedereen die me benaderde
over fetchmail er op te zetten;
ik stuurde breedsprakige aankondigingen naar de beta-lijst
wanneer ik code vrijgaf, waarin ik mensen aanmoedigde deel
te nemen;
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:
10.
|
Als je je beta-testers als je meest waardevolle bron behandelt
zullen zij reageren door je meest waardevolle bron te worden.
|
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.
11.
|
Na het zelf hebben van goede ideeën, is het het beste de goede
ideeen van je gebruikers te herkennen. Soms is dat zelfs beter.
|
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.
12.
|
Vaak komen de meest verbluffende en innoverende oplossingen
voort uit de realisatie dat je concept van het probleem fout
was.
|
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:
13.
|
"Perfectie (in ontwerp) wordt bereikt, niet als er niets meer
toe te voegen valt, maar meer als er niets meer weg valt te
halen."
|
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
<http://www.internic.net/rfc/rfc822.txt>
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:
14.
|
Elk gereedschap moet inzetbaar zijn op de manier die je
verwacht, maar een werkelijk groots gereedschap is inzetbaar
op manieren die je niet voor mogelijk hield.
|
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:
15.
|
Als je een of ander soort gateway software schrijft, probeer
dan ten koste van alles om de datastroom zo weinig mogelijk
te verstoren - en gooi NOOIT informatie weg, behalve als de
ontvanger je er toe dwingt.
|
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,
<http://www.internic.net/rfc/rfc1652.txt> 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:
16.
|
Als je taal nog lang niet Turing-compleet is, kan syntactische
suiker je redding zijn.
[5].
|
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:
17.
|
Een beveiligingssysteem is slechts zo goed beveiligd als het
geheim wat eraan ten grondslag ligt. Pas op voor pseudo-geheimen.
|
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:
18.
|
Om een interessant probleem op te lossen dien je te
beginnen met een probleem op te sporen dat jij interessant
vindt.
|
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:
19.
|
Gegeven dat de ontwikkelcoördinator een minstens evengoed
medium als het Internet heeft en weet hoe je leiding moet
geven zonder dwangmiddelen, zijn vele hoofden onvermijdelijk
beter dan 1.
|
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 <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 <nancy@universe.digex.net>
voor haar suggestie Weinberg te emuleren door Kropotkin te citeren.
Perceptieve kritieken waren ook afkomstig van Joan Eslinger
<wombat@kilimanjaro.engr.sgi.com> en Marty Franz
<marty@net-link.net>
die op de "General Technics" lijst staan. Paul Eggert
<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<
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.
Deze geschriften zijn verkrijgbaar op het Web:
<http://www.agorics.com/agorpapers.html>
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
<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
$Id: cathedral-bazaar.sgm, v1.36 1998/03/27 18:53:18 esr Exp $
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 <r.e.wolff@bitwizard.nl> 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 <ijansch@cuci.nl> 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
<www.iaf.nl>. 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 <henk@fortean.org>
Slochteren, 15 juli 1998.
|