Why Write This Book?

At parties, people no longer give me a blank stare when I tell them I write free software. "Oh, yes, open source like Linux?" they say. I nod eagerly in agreement. "Yes, exactly! That's what I do." It's nice not to be completely on the fringe anymore. In the past, the next question was usually fairly predictable: "How do you make money doing that?" To answer, I'd summarize the economics of open source: that there are organizations in whose interest it is to have certain software exist, but that they don't need to sell copies, they just want to make sure the software is available and maintained, as a tool instead of a commodity.

Lately, however, the next question has not always been about money. The business case for open source software^[1] is no longer so mysterious, and many non-programmers already understand or at least are not surprised that there are people employed at it full time. Instead, the question I have been hearing more and more often is "Oh, how does that work?"

^[1] The terms "open source" and "free" are essentially synonymous in this context; they are discussed more in the section Section 1.1.2 in Chapter 1.

I didn't have a satisfactory answer ready, and the harder I tried to come up with one, the more I realized how complex a topic it really is. Running a free software project is not exactly like running a business (imagine having to constantly negotiate the nature of your product with a group of volunteers, most of whom you've never met!). Nor, for various reasons, is it exactly like running a traditional non-profit organization, nor a government. It has similarities to all these things, but I have slowly come to the conclusion that free software is sui generis. There are many things with which it can be usefully compared, but none with which it can be equated. Indeed, even the assumption that free software projects can be "run" is a stretch. A free software project can be started, and it can be influenced by interested parties, often quite strongly. But its assets cannot be made the property of any single owner, and as long as there are people somewhere anywhere interested in continuing it, it cannot be unilaterally shut down. Everyone has infinite power; everyone has no power. It makes for an interesting dynamic.

That is why I wanted to write this book. Free software projects have evolved a distinct culture, an ethos in which the liberty to make the software do anything one wants is a central tenet, and yet the result of this liberty is not a scattering of individuals each going their own separate way with the code, but enthusiastic collaboration. Indeed, competence at cooperation itself is one of the most highly valued skills in free software. To manage these projects is to engage in a kind of hypertrophied cooperation, where one's ability not only to work with others but to come up with new ways of working together can result in tangible benefits to the software. This book attempts to describe the techniques by which this may be done. It is by no means complete, but it is at least a beginning.

Good free software is a worthy goal in itself, and I hope that readers who come looking for ways to achieve it will be satisfied with what they find here. But beyond that I also hope to convey something of the sheer pleasure to be had from working with a motivated team of open source developers, and from interacting with users in the wonderfully direct way that open source encourages. Participating in a successful free software project is fun, and ultimately that's what keeps the whole system going.