Karl Fogel wrote:These days, people no longer show a blank stare when someone tell them that he or she writes free softwares. People even no longer question the economics of doing open source projects or how to make money doing that. The business case for open source software 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.

Running a free software project is not exactly like running a business. 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 the conclusion is that free software is sui generis.

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 the reason why this book was written. Free software projects have evolved a distinct culture, an ethos in which the liberty to make the software does 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.

Intended Audience:

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 an 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.