Raymond har vært i programvarebransjen siden tidlig på 1980-tallet. Men han trodde ikke noe på verken gratis programvare eller åpen kilde-modellen - der programvare distribueres gratis både kompilert og med kildekoden - før det han selv beskriver som "en sjokkerende opplevelse" i 1993.
- Det var da jeg stiftet bekjentskap med en nordisk Linux-distribusjon på CD-ROM, kalt Yggdrasil. Jeg var svært skeptisk fordi jeg hadde hørt at tusener av programmerere hadde gitt sine bidrag til prosjektet. På den tiden sverget jeg den såkalte Brookes' lov som blant annet sier at tallet på feil i et program øker med kvadratet av tallet på programmerere som bidrar til koden.
Brookes' lov hevder også at leveringstiden øker med tallet på programmerere.
Prinsippene Raymond sverget til på den tiden, gikk følgelig ut på at prosjekter skulle ha så få programmerere som mulig, det måtte være en stram og sentralistisk prosjektledelse, og det måtte gå lang tid mellom hver gang det ble sluppet oppgraderinger.
- Sjokket kom etter hvert som jeg gikk gjennom CD-en og oppdaget både hvor god koden var og hvor mange fine nye verktøy som var lagt ved. Dessuten var jeg imponert over at det ikke fantes kompliserte redskap for å gjenerobre systemet når det krasjet. Det var simpelthen ikke nødvendig.
Det var da Raymond fant ut at han ville slutte seg til Linux-fellesskapet. Han måtte finne ut hvordan modellen virket og hvorfor prinsippene han selv hadde hevdet, tydeligvis var feilaktige. Han skrev et hjelpeverktøy kalt Fetch Mail og la ut kildekoden. Erfaringen ga ham innsikt i tre grunnleggende prinsipper som til sammen danner åpen kilde-modellen.
- Det første prinsippet er at du som prosjektleder må sørge for tilbakemeldinger fra hele verden ved hvert trinn i utviklingen. Ta godt vare på tilbakemeldinger fra både kvalifiserte og ukvalifiserte. De siste er ofte veldig flinke til å oppdage bestemte typer feil. Du øker også sannsynligheten for å få innsiktsfulle tilbakemeldinger fra folk som reagerer ikke bare på detaljer i prosjektet, men også på prosjektets formål og struktur.
Det andre prinsippet er å slippe programmet - med kildekode - tidlig og ofte. Ifølge Raymond kan Linus Torvalds gjerne slippe mer enn én utgave av Linus-kjernen i ett og samme døgn.
- Det tredje er å gi alle som bidrar positivt til prosjektet, den offentlige rosen de fortjener. Ros er den primære motiveringsfaktoren for programmerere. De bygger sitt rykte på dokumentérbar ros.
Raymond valgte to metaforer for å beskrive de to motsatte modellene for programvareutvikling. "Katedral" betegner den hierarkiske og lukkede metoden, mens "basar" viser til den åpne og frie modellen.
Raymond peker på at det å få så mange tilbakemeldinger som mulig fra likemenn er en hevdvunnen metode i vitenskapelig, ingeniørpreget og kreativt arbeid, nettopp for å luke ut menneskelige feil i komplekse prosesser. Det finnes ett unntak: katedralmodellen for programvareutvikling.
- Hva slags programvare er det som har vært utviklet etter basar-modellen helt siden slutten av 1960-tallet, som inngår i komplekse og utstrakte distribuerte systemer, og som har vist seg å være fullstendig pålitelig? Det er nettopp kjerneprogramvaren for Internett. Der har man overkommet regelen om at antall feil øker med kvadratet av antall programmerere ved å ha en svært liten gruppe i kjernen for prosessen, og en ring av kritikere som alle sender sine endringsforslag tilbake til kjernen.
Erfaringen fra arbeidet med Fetch Mail-verktøyet viste at tilbakemeldinger fra et stort antall kritikere gjør det enklere for kjernegruppen å erkjenne at stygg kode gjenspeiler dårlig formulerte problemstillinger, og at den beste løsningen i så fall er å formulere problemet på nytt.
- En gang i blant setter en kritiker fingeren på noe du overhodet ikke har tenkt på. Du ender opp med å gjøre om på hele programmet.
Kunne en stor organisasjon, for eksempel Microsoft, anvende en slags "intern" variant av åpen kilde-modellen?
- I teorien er svaret ja. I praksis vil den kulturelle omveltningen dette medfører, være uoverkommelig. Interne kritikerringer fungerer ikke særlig bra. Motivering er ett problem. Et annet, er at kollegaer gjerne tenker forholdsvis likt. Du får ikke den spredningen i tenkesett som er den åpne modellens store fortrinn. Dessuten er det for lett for utenforliggende hensyn å forkludre prosessen, blant annet konformistisk press og intern rivalisering. I Microsofts tilfelle synes det helt umulig. Der er kulturen knyttet til strenge regler om at alle utviklingsgruppene holder koden sin for seg selv. Det er streng intern sikkerhet, og ideen om et sentralt og internt tilgjengelig oppbevaringssted for all kildekode synes helt utenkelig.
Eric Raymond har skrevet flere banebrytende artikler der disse idéene er presentert mer utførlig. Se blant annet:
Se også digi.nos artikler Det er god butikk å gi bort programvare, sier Eric Raymond og Eric Raymond tar Norge med storm
