Förord
Varför Skriva Denna Bok?
På fester så får jag inte längre stirrande blickar på mig
när jag säger att jag skriver fri mjukvara. "Ah, ja, öppen källkod—
som Linux?" säger dom. Då nickar jag ivrigt i medhåll. "Ja, precis! Det är
vad jag gör." Det är trevligt att inte vara helt i utkanten längre. Förr
i tiden, var nästa fråga oftast ganska förutsägbar: "Hur tjänar du pengar
på det?" För att svara på det, brukade jag summera ekonomin i öppen källkod:
att det finns organisationer vars intressen ligger i att det finns särskild
mjukvara, men att dom inte behöver sälja kopior, dom vill bara vara
säkra på att mjukvaran finns tillgänglig och underhålls, som ett verktyg
istället för en handelsvara.
På senare tid, dock, har nästa fråga inte alltid varit om pengar.
Verksamheten för öppen mjukvaraTermerna "öppen källkod" och
"fri" är egentligen synonymer i detta sammanhang; dessa diskuteras
mer i i
. är inte längre
så mystisk, och många icke-programmerare förstår redan— eller blir
åtminstone inte förvånade—av att det finns folk som jobbar heltid
med det. Istället får jag nu mer och mer ofta höra frågan "
Åh, hur fungerar det?"
Jag hade inte ett tillfredsställande svar redo, och ju mer jag försökte
komma på ett, desto mer insåg jag hur komplext ämne det faktiskt är. Att
sköta ett fritt mjukvaruprojekt är inte precis som att sköta ett företag
(föreställ dig att behöva förhandla över din produkt med en grupp frivilliga,
varav många du aldrig tidigare träffat!). Ej heller, av olika anledningar,
är det som att sköta en idéell förening, eller en regering. Det har likheter
med alla dessa, men jag har så smått kommit till insikt med att fri mjukvara
är sui generis. Det finns många ting som det
kan jämföras mot, men inget som det kan likställas med. Att faktiskt ens
påstå att man kan "driva" ett fritt mjukvaruprojekt är att ta i. Ett fritt mjukvaruprojekt kan startas, och det kan påverkas
av intresserade, ofta väldigt påtagligt. Men dess tillgångar kan inte
tildelas en enskild ägare, och så länge det finns folk någonstans—var
som helst—som är intresserade av att fortsätta, så kan det inte
ensidigt stängas ner. Alla har obegränsad makt; alla är likväl maktlösa.
Det bäddar för en intressant dynamik.
Detta fick mig att vilja skriva denna boken. Fria mjukvaruprojekt
har utvecklat en distinkt kultur, en grundsyn där friheten att få mjukvaran
att göra något man vill är en central grundsats, och ändå är resultatet av
denna frihet inte en splittring av individer som var och en går sin egen
separata väg med koden, utan ett entusiastiskt samarbete. Just kompetens i
att samarbeta är en högt värderad färdighet när det kommer till fri
mjukvara. För att hantera dessa projekt, krävs att man engagerar sig
utomordentligt i ett samarbete, där en förmåga att inte bara samarbeta
med andra utan även komma på nya sätt att arbeta tillsammans, kan resultera
i konkreta fördelar för programvaran. Denna bok försöker beskriva
teknikerna att ta till. Den är på inga sätt komplett, men den är en god
början.
Bra fri mjukvara är ett gott mål i sig, och jag hoppas att läsare
som söker vägar för att åstadkomma detta kommer bli nöjda med vad dom
finner här. Utöver det så hoppas jag även förmedla något av det rena
nöjet man har med att arbeta med ett motiverat team av utvecklare
för öppen källkod, och från interaktionen med användare på det underbart
direkta sätt som öppen källkod uppmuntrar till. Att medverka i ett lyckat
fritt mjukvaruprojekt är kul, och är i slutändan det
som får hela systemet att fungera.
Who Should Read This Book?
This book is meant for software developers and managers who are
considering starting an open source project, or who have started one
and are wondering what to do now. It should also be helpful for
people who just want to participate in an open source project but have
never done so before.
The reader need not be a programmer, but should know basic
software engineering concepts such as source code, compilers, and
patches.
Prior experience with open source software, as either a user or
a developer, is not necessary. Those who have worked in free software
projects before will probably find at least some parts of the book a
bit obvious, and may want to skip those sections. Because there's
such a potentially wide range of audience experience, I've made an
effort to label sections clearly, and to say when something can be
skipped by those already familiar with the material.
Sources
Much of the raw material for this book came from five years of
working with the Subversion project
(). Subversion is an open
source version control system, written from scratch, and intended to
replace CVS as the de facto version
control system of choice in the open source community. The project
was started by my employer, CollabNet
(), in early 2000, and thank
goodness CollabNet understood right from the start how to run it as a
truly collaborative, distributed effort. We got a lot of volunteer
developer buy-in early on; today there are 50-some developers on
the project, of whom only a few are CollabNet employees.
Subversion is in many ways a classic example of an open source
project, and I ended up drawing on it more heavily than I originally
expected. This was partly a matter of convenience: whenever I needed
an example of a particular phenomenon, I could usually call one up
from Subversion right off the top of my head. But it was also a
matter of verification. Although I am involved in other free software
projects to varying degrees, and talk to friends and acquaintances
involved in many more, one quickly realizes when writing for print
that all assertions need to be fact-checked. I didn't want to make
statements about events in other projects based only on what I could
read in their public mailing list archives. If someone were to try
that with Subversion, I knew, she'd be right about half the time and
wrong the other half. So when drawing inspiration or examples from a
project with which I didn't have direct experience, I tried to first
talk to an informant there, someone I could trust to explain what was
really going on.
Subversion has been my job for the last 5 years, but I've been
involved in free software for 12. Other projects that influenced this
book include:
The GNU Emacs text editor project at the Free
Software Foundation, in which I maintain a few small
packages.
Concurrent Versions System (CVS), which I worked on
intensely in 1994–1995 with Jim Blandy, but have been
involved with only intermittently since.
The collection of open source projects known as the
Apache Software Foundation, especially the Apache Portable
Runtime (APR) and Apache HTTP Server.
OpenOffice.org, the Berkeley Database from
Sleepycat, and MySQL Database; I have not been
involved with these projects personally, but have observed
them and, in some cases, talked to people there.
GNU Debugger (GDB) (likewise).
The Debian Project (likewise).
This is not a complete list, of course. Like most open source
programmers, I keep loose tabs on many different projects, just to
have a sense of the general state of things. I won't name all of them
here, but they are mentioned in the text where appropriate.
Acknowledgments
This book took four times longer to write than I thought it
would, and for much of that time felt rather like a grand piano
suspended above my head wherever I went. Without help from many
people, I would not have been able to complete it while staying
sane.
Andy Oram, my editor at O'Reilly, was a writer's dream. Aside
from knowing the field intimately (he suggested many of the topics),
he has the rare gift of knowing what one meant to say and helping one
find the right way to say it. It has been an honor to work with him.
Thanks also to Chuck Toporek for steering this proposal to Andy right
away.
Brian Fitzpatrick reviewed almost all of the material as I wrote
it, which not only made the book better, but kept me writing when I
wanted to be anywhere in the world but in front of the computer. Ben
Collins-Sussman and Mike Pilato also checked up on progress, and were
always happy to discuss—sometimes at length—whatever topic
I was trying to cover that week. They also noticed when I slowed
down, and gently nagged when necessary. Thanks, guys.
Biella Coleman was writing her dissertation at the same time
I was writing this book. She knows what it means to sit down and
write every day, and provided an inspiring example as well as a
sympathetic ear. She also has a fascinating anthropologist's-eye view
of the free software movement, giving both ideas and references that I
was able use in the book. Alex Golub—another anthropologist
with one foot in the free software world, and also finishing his
dissertation at the same time—was exceptionally supportive early
on, which helped a great deal.
Micah Anderson somehow never seemed too oppressed by his own
writing gig, which was inspiring in a sick, envy-generating sort of
way, but he was ever ready with friendship, conversation, and (on at
least one occasion) technical support. Thanks, Micah!
Jon Trowbridge and Sander Striker gave both encouragement and
concrete help—their broad experience in free software provided
material I couldn't have gotten any other way.
Thanks to Greg Stein not only for friendship and well-timed
encouragement, but for showing the Subversion project how important
regular code review is in building a programming community. Thanks
also to Brian Behlendorf, who tactfully drummed into our heads the
importance of having discussions publicly; I hope that principle is
reflected throughout this book.
Thanks to Benjamin "Mako" Hill and Seth Schoen, for various
conversations about free software and its politics; to Zack Urlocker
and Louis Suarez-Potts for taking time out of their busy schedules to
be interviewed; to Shane on the Slashcode list for allowing his post
to be quoted; and to Haggen So for his enormously helpful comparison
of canned hosting sites.
Thanks to Alla Dekhtyar, Polina, and Sonya for their unflagging
and patient encouragement. I'm very glad that I will no longer have
to end (or rather, try unsuccessfully to end) our evenings early to go
home and work on "The Book."
Thanks to Jack Repenning for friendship, conversation, and a
stubborn refusal to ever accept an easy wrong analysis when a harder
right one is available. I hope that some of his long experience with
both software development and the software industry rubbed off on this
book.
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.
Disclaimer
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.