Karl Fogel - Producing Open Source Software

Copyright 2005-2019 Karl Fogel, under the CreativeCommons Attribution-ShareAlike (4.0) license.

Version: 2.3214

Home site: https://producingoss.com/

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

The next question is not always about money, though. Thebusiness case for open source software is no longer somysterious, and even non-programmers already understand or atleast are not surprised that there are people employed at itfull time. Instead, the next question is often " Oh, what'sthat like? "

I didn't have a satisfactory answer ready, and the harder Itried to come up with one, the more I realized how complex a topic itreally is. Running a free software project is not exactly likerunning a business (imagine having to constantly negotiate the natureof your product with a group of random people of diverse motivationsand interests, most of whom you've never met!).Nor, for various reasons, is it exactly like running atraditional non-profit organization, nor a government. It hassimilarities to all these things, but I have slowly come to theconclusion that free software is suigeneris . There are many things with which it can beusefully compared, but none with which it can be equated. Indeed,even the assumption that free software projects can be "run" is astretch. A free software project can be started ,and it can be influenced by interested parties.But its assets cannot be made the property of any single owner, and aslong as there are people somewhere anywhere interested incontinuing it, it can never be unilaterally shut down. Everyone hasinfinite power; everyone has no power. It's an interestingdynamic.

That is why I wanted to write this book in the first place, and,a decade later, wanted to update it. Free software projects haveevolved a distinct culture, an ethos in which the liberty to make thesoftware do anything one wants is a central tenet. Yet the result ofthis liberty is not a scattering of individuals each going their ownseparate way with the code, but enthusiastic collaboration and frequent compromise. Indeed,competence at cooperation itself is one of the most highly valuedskills in free software. To manage these projects is to engage in akind of hypertrophied cooperation, where one's ability not only towork with others but to come up with new ways of working together canresult in tangible benefits to the software and the community that develops it. This book attempts todescribe the techniques by which this may be done. It is by no meanscomplete, but it is at least a beginning.

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

This book is meant for managers and software developers who areconsidering starting an open source project, or who have started oneand are wondering what to do now. It should also be helpful forpeople who just want to participate in an open source project but havenever done so before.

The reader need not be a programmer, but should know basicsoftware engineering concepts such as APIs, source code, compilers, andpatches.

Prior experience with open source software, as either a user ora developer, is not necessary. Those who have worked in free softwareprojects before will probably find at least some parts of the book abit obvious, and may want to skip those sections. Because there'ssuch a potentially wide range of audience experience, I've made aneffort to label sections clearly, and to say when something can beskipped by those already familiar with the material.