Til fester, er reaktionen når jeg fortæller at jeg udvikler fri software ikke længere bare et stift blik ud i rummet. "Åh, ja, open source—ligesom Linux?" siger de. Jeg nikker ivrigt. "Ja, præcis! Det er det jeg beskæftiger mig med." Det er rart ikke at være komplet på kanten(!) mere. Før i tiden var det næste spørgsmål normalt rimeligt forudsigeligt: "Hvordan tjener du penge på det?". Som svar, ville jeg så kort ridse økonomien omkring open source op: at der er visse organisationer hvis interesse det er at noget bestemt software eksisterer, men at de ikke nødvendigvis behøver at sælge kopier af det, men bare vil være sikker på at softwaren er tilgængelig og bliver vedligeholdt, mere som værktøj end som en handelsvare. På det sidste, har det næste spørgsmål dog ikke altid været om penge. Forretningsmetoden(!) for open source software Betegnelserne "open source" og "fri" er i denne sammenhæng i det væsentligste synonymer; de behandles yderligere i i . er ikke længere så mystisk, og mange ikke-programmører forstår, —eller er i det mindste ikke overaskede over—at der er folk der arbejder med det på fuld tid. Istedet er spørgsmålet jeg hører mere og mere "Okay, hvordan virker det så?" Jeg havde ikke et tilfredsstillende svar klar, og jo mere jeg forsøgte at finde et, jo mere måtte jeg indse hvor komplekst emnet virkelig er. At drive et frit software projekt er ikke det samme som at drive en forretning (forestil dig konstant at skulle forhandle om dit produkts indhold med en gruppe frivillige, hvoraf de fleste er nogen du aldrig har mødt!). Af forskellige årsager er det heller ikke præcis som at drive en traditionel ikke-for-profit(!) forening, eller en statsadministration(!). Det har lighedspunkter med alle disse, men jeg er lige så langsomt kommet til den konklusion at fri software er sui generis. Der er mange ting det kan sammenlignes med, men ingen det kan ikke sidestilles helt med. Selv antagelsen at et fri software projekt kan "drives" er lidt af en tilsnigelse. Et frit software projekt kan startes , og det kan påvirkes af interesserede parter, ofte temmelig stærkt. Men projektets værdier kan ikke skifte ejerskab til en enkelt ejer, og så længe der er folk et eller andet sted —et hvilket som helst sted—som er interesserede i at fortsætte det, kan det ikke lukkes af en enkelt part. Enhver har uendelig magt; enhver har ingen magt. Det giver en interessant dynamik. Derfor ønskede jeg at skrive denne bog. Fri software projekter har udviklet en (distinct culture) unik kultur(!), et ethos(!) hvori friheden til at få software til at gøre præcis hvad man vil en en central tese(!), og dog er resultatet af denne frihed ikke en spredning af individer der arbejder i hver deres retning med koden, men entusiastisk samarbejde. Ja, blot kompetencen i samarbejde i sig selv, er en af de mest værdsatte evner indenfor fri software. At styre disse projekter er at kaste sig ud i en slags hypertrofi abnorm forstørrelse af kropsdel eller organ-ramt samarbejde, hvor ens evne til, ikke blot at arbejde med andre, men også at finde på nye måder at arbejde sammen, kan resultere i betydelige fordele for softwaren. Denne bog forsøger at beskrive teknikker hvormed dette kan gøres. Den er på ingen måder komplet, men den er i det mindste en begyndelse. God fri software er et værdigt mål i sig selv, og jeg håber at læsere som søger efter måder at opnå det på, vil blive tilfreds med hvad de finder her. Men udover det, håber jeg også at kunne viderebringe noget af den rene glæde det bringer at arbejde med et motiveret hold af open source udviklere, og af at interagere med brugere på den herligt direkte måde som open source tilskynder. At deltage i et successfuldt fri software projekt er sjovt, og det er i sidste ende præcis det der holder hele systemet kørende. Denne bog er skrevet til softwareudviklere og ledere som overvejer at starte et open source projekt, eller som har startet et og nu er bekymret for hvordan de kommer videre. Den vil nok også kunne hjælpe folk der bare vil deltage i et open source projekt, men aldrig har gjort det før. Læseren behøver ikke at være programmør, men bør kende til grundlæggende koncepter indenfor software udvikling, såsom kilde kode, kompilere og lapper til kilde kode (patches, herefter kaldet lap). Forhåndserfaring med open source software, hverken som bruger eller udvikler er ikke nødvendig. De som har arbejdet i fri software projekter før vil nok opfatte dele af bogen som en smule indlysende, og vil måske kunne springe disse dele over. Da der er så stort et spænd i læsernes potentielle erfaringer, har jeg gjort meget ud af at navngive bogens sektioner så de antyder hvilket erfaringsniveau de er henvendt til, samt at fortælle når noget kan springes over af dem der er bekendt med stoffet på forhånd. Det meste af råmaterialet til denne bog er opstået ud af fem års arbejde med Subversion projektet (). Subversion er et open source versions kontrol system, skrevet helt fra bunden af, med intentionen om at erstatte CVS som de facto valget for versions kontrol systemer i open source fællesskabet. Projektet blev startet af min arbejdsgiver, CollabNet (), tidligt i år 2000, og heldigvis forstod CollabNet lige fra starten at drive det som en ægte kollaborativ, distribueret opgave(!)(effort). Vi fik tidligt en masse frivillige udviklere koblet på projektet, og i dag er der nogen og halvtreds aktive udviklere, heraf er kun et fåtal CollabNet medarbejdere. Subversion er på mange måder et klassisk eksempel på et open source projekt, og jeg endte med at referere mere til det i denne bog, end jeg oprindeligt forventede. Dette til dels af bekvemmelighedsgrunde, når jeg skulle bruge et eksempel på et bestemt fænomen, dukkede der som regel et fra Subversion op i mit hoved som det første. Men også for at kunne være helt sikker på mine kilders pålidelighed. Selvom jeg er involveret i andre fri software projekter i forskellige grader, og snakker med venner og bekendte der er involveret i mange andre, indser man hurtigt at når man skriver til tryk, skal enhver antagelses sandhed verificeres. Jeg ville ikke udtale mig om hændelser i andre projekter, baseret på hvad jeg kunne læse i deres offentlige post-liste arkiver. Hvis nogle gjorde det med Subversion, ved jeg at de ville have ret omkring halvdelen af tiden, og tage fejl den anden halvdel. Så når jeg hentede inspiration eller eksempler fra et projekt jeg ikke havde direkte erfaring med, prøvede jeg først at finde en meddeler derfra, én som jeg kunne stole på ville kunne forklare hvad der virkelig skete. Subversion har været mit job i de sidste 5 år, men jeg har været involveret i fri software i 12. Andre projekter der har influeret denne bog er: GNU Emacs tekst editor projektet hos Free Software Foundation, i hvilket jeg vedligeholder nogle få små pakker. Concurrent Versions System (CVS), som jeg arbejdede intenst på i 1994–1995 sammen med Jim Blandy, men som jeg kun har været sporadisk involveret i siden. Samlingen af open source projekter kendt som Apache Software Foundation, specielt Apache Portable Runtime (APR) og Apache HTTP Server. OpenOffice.org, Berkeley databasen fra Sleepycat, og MySQL databasen har jeg ikke personligt været involveret, men har observeret dem, og i nogle tilfælde snakket med folk derfra. GNU Debugger (GDB) (som ovenstående). The Debian Project (som ovenstående). Dette er selvfølgelig ikke en komplet liste. Som de fleste open source programmører, skæver jeg løbende til mange forskellige projekter, bare for at have en fornemmelse af deres generelle tilstand. Jeg vil ikke liste dem alle her, men de er nævnt i teksten ved lejlighed. Denne bog tog fire gange længere tid at skrive end jeg troede, og det meste af den tid føltes det som om jeg havde et større klavermøbel svævende over hovedet hvorend jeg bevægede mig. Uden hjælpen fra mange mennesker, ville jeg ikke have været i stand til at færdiggøre den, og stadig være ved mine sansers fulde fem. Andy Oram, min redaktør hos O'Reilly, var en forfatters drøm. Bortset fra hans intime kendskab til området (han foreslog mange af emnerne), har han den sjældne egenskab at kunne gennemskue hvad man gerne ville have sagt, og hjælpe en til at finde den rette måde at sige det på. Det har været en ære at arbejde med ham. Tak skal også gå til Chuck Toporek for at styre mig i Andys retning da jeg kun havde ideen til bogen. Brian Fitzpatrick læste korrektur på næsten alt materialet mens jeg skrev, hvilket ikke bare gjorde bogen bedre, men holdt mig i gang med at skrive når jeg ønskede at være alle andre steder end foran computeren. Ben Collins-Sussman og Mike Pilato fulgte også bogens fremskridt, og var altid villige til at diskutere—nogen gange længe—det emne jeg nu lige forsøgte at dække den uge. De lagde også mærke til det når jeg gik ned i tempo, og stak forsigtigt til mig når det var nødvendigt. Tak gutter. Biella Coleman skrev hendes disputats samtidigt med at jeg skrev denne bog. Hun ved hvad det betyder at sætte sig ned hver dag for at skrive, og var et inspirerende eksempel såvel som et sympatisk øre. Hendes fascinerende antropologiske indgansvinkel til fri software bevægelsen, gav både ideer og referencer som jeg kunne bruge i bogen. Alex Golub—endnu en antropolog med en fod indenfori fri software verdenen, som også færdiggjorde hans disputats samtidigt—gav en ekseptionel støtte tidligt i forløbet, hvilket var en stor hjælp. Det lykkedes Micah Anderson at fremstå upåvirket af hans eget skrive-job, hvilket var inspirerende på en sådan lidt syg, misundelses-skabende måde, men han var altid klar med venskab, samtale og (ved mindst en lejlighed) teknisk support. Tak Micah! Jon Trowbridge og Sander Striker bidrog med både opmuntring og konkret hjælp—deres brede erfaringsgrundlag indenfor fri software gav materiale jeg ikke kunne have fået på andre måder. Tak til Greg Stein, ikke kun for venskab og vel-placeret opmuntring, men for at vise Subversion projektet, hvor vigtigt regelmæssige kode gennemgange er i opbygningen af et programmerings-fællesskab. Tak skal også gå til Brian Behlendorf, som taktfuldt fik vigtigheden af at diskussioner skulle foregå offentligt trommet ind i vores hoveder. Jeg håber det princip er afspejlet gennem hele bogen. Tak til Benjamin "Mako" Hill og Seth Schoen, for adskillige samtaler om fri software og dets politikker. Til Zack Urlocker og Louis Suarez-Potts for at tage tid ud af deres travle kalendre for at blive interviewet. Til Shane på Slashcode listen for at tillade mig at citere hans meddelelse, og til Haggen So for hans enormt hjælpsomme sammenligning af canned hosting(!) sider. Tak til Alla Dekhtyar, Polina, og Sonya for deres unflagging(!) og tålmodige opmuntring. Jeg er meget glad for at jeg ikke længere er nødt til at afslutte (eller rettere, forsøge uden held at afslutte) vores aftener tidligt for at gå hjem og arbejde på "Bogen". Tak til Jack Repenning for venskab, samtale, og for stædigt at nægte at acceptere en nem forkert analyse, når der er en svær men rigtig tilgængelig. Jeg håber at noget af hans store erfaring med software- udvikling og software-industrien er smittet af på denne bog. CollabNet was exceptionally generous in allowing me a flexible schedule to write, and didn't complain when it went on far longer than originally planned. I don't know all the intricacies of how management arrives at such decisions, but I suspect Sandhya Klute, and later Mahesh Murthy, had something to do with it—my thanks to them both. The entire Subversion development team has been an inspiration for the past five years, and much of what is in this book I learned from working with them. I won't thank them all by name here, because there are too many, but I implore any reader who runs into a Subversion committer to immediately buy that committer the drink of his choice—I certainly plan to. Many times I ranted to Rachel Scollon about the state of the book; she was always willing to listen, and somehow managed to make the problems seem smaller than before we talked. That helped a lot—thanks. Thanks (again) to Noel Taylor, who must surely have wondered why I wanted to write another book given how much I complained the last time, but whose friendship and leadership of Golosá helped keep music and good fellowship in my life even in the busiest times. Thanks also to Matthew Dean and Dorothea Samtleben, friends and long-suffering musical partners, who were very understanding as my excuses for not practicing piled up. Megan Jennings was constantly supportive, and genuinely interested in the topic even though it was unfamiliar to her—a great tonic for an insecure writer. Thanks, pal! I had four knowledgeable and diligent reviewers for this book: Yoav Shapira, Andrew Stellman, Davanum Srinivas, and Ben Hyde. If I had been able to incorporate all of their excellent suggestions, this would be a better book. As it was, time constraints forced me to pick and choose, but the improvements were still significant. Any errors that remain are entirely my own. My parents, Frances and Henry, were wonderfully supportive as always, and as this book is less technical than the previous one, I hope they'll find it somewhat more readable. Finally, I would like to thank the dedicatees, Karen Underhill and Jim Blandy. Karen's friendship and understanding have meant everything to me, not only during the writing of this book but for the last seven years. I simply would not have finished without her help. Likewise for Jim, a true friend and a hacker's hacker, who first taught me about free software, much as a bird might teach an airplane about flying. The thoughts and opinions expressed in this book are my own. They do not necessarily represent the views of CollabNet or of the Subversion project.