Product Description

The corporate market is now embracing free, "open source" software like never before, as evidenced by the recent success of the technologies underlying LAMP (Linux, Apache, MySQL, and PHP). Each is the result of a publicly collaborative process among numerous developers who volunteer their time and energy to create better software. The truth is, however, that the overwhelming majority of free software projects fail. To help you beat the odds, O'Reilly has put together "Producing Open Source Software", a guide that recommends tried and true steps to help free software developers work together toward a common goal. Not just for developers who are considering starting their own free software project, this book will also help those who want to participate in the process at any level. The book tackles this very complex topic by distilling it down into easily understandable parts. Starting with the basics of project management, it details specific tools used in free software projects, including version control, IRC, bug tracking, and Wikis. Author Karl Fogel, known for his work on CVS and Subversion, offers practical advice on how to set up and use a range of tools in combination with open mailing lists and archives. He also provides several chapters on the essentials of recruiting and motivating developers, as well as how to gain much-needed publicity for your project. While managing a team of enthusiastic developers - most of whom you've never even met - can be challenging, it can also be fun. "Producing Open Source Software" takes this into account, too, as it speaks of the sheer pleasure to be had from working with a motivated team of free software developers.

Product Details

• Amazon Sales Rank: #171462 in Books
• Published on: 2005-10-07
• Original language: English
• Number of items: 1
• Binding: Paperback
• 279 pages

From the Publisher
This comprehensive guide offers several tried and true steps to help you successfully manage the complex process of developing free software. Topics include project management, developer motivation, technical infrastructure to support collaboration, and project promotion. Producing Open Source Software is ideal for developers starting their own free software projects, or people who simply want to participate in the process.

About the Author
In 1995, Karl Fogel co-founded Cyclic Software, a company offering commercial CVS support. In 1999 he added support for CVS anonymous read-only repository access, inaugurating a new standard for access to development sources in open source projects. That same year, he wrote "Open Source Development With CVS" (published by Coriolis), now in its third edition via Paraglyph Press. Since early 2000, he has worked for CollabNet, Inc, managing the creation and development of Subversion, a version control system written from scratch by CollabNet and a team of open source volunteers, and meant to replace CVS as the de facto standard among open source projects. He also participates in various other open source projects as a module maintainer, patch contributor, and documentation writer.

Excerpted from Producing Open Source Software by Karl Fogel. Copyright © 2005. Reprinted by permission. All rights reserved.
Chapter 4 Social and Political Infrastructure

The first questions people usually ask about free software are "How does it work? What keeps a project running?Who makes the decisions?"I ’m always dissatisfied with bland responses about meritocracy,the spirit of cooperation,code speaking for itself, etc. The fact is,the question is not easy to answer.Meritocracy,cooperation, and running code are all part of it,but they do little to explain how projects actually run on a day-to-day basis,and say nothing about how conflicts are resolved.

This chapter tries to show the structural underpinnings successful projects have in common. I mean "successful "not just in terms of technical quality, but also operational health and survivability. Operational health is the project ’s ongoing ability to incorporate new code contributions and new developers, and to be responsive to incoming bug reports. Survivability is the project ’s ability to exist independently of any individual participant or sponsor —think of it as the likelihood that the project would continue even if all of its founding members were to move on to other things. Technical success is not hard to achieve, but without a robust developer base and social foundation, a project may be unable to handle the growth that initial success brings, or the departure of charismatic individuals.

There are various ways to achieve this kind of success.Some involve a formal governance structure, by which debates are resolved,new developers are invited in (and sometimes out),new features planned,and so on.Others involve less formal structure, but more conscious self-restraint,to produce an atmosphere of fairness that people can rely on as a de facto form of governance.Both ways lead to the same result: a sense of institutional permanence,supported by habits and procedures that are well understood by everyone who participates.These features are even more important in self-organizing systems than in centrally controlled ones,because in self-organizing systems, everyone is conscious that a few bad apples can spoil the whole barrel,at least for a while.

Forkability

The indispensable ingredient that binds developers together on a free software project, and makes them willing to compromise when necessary,is the code ’s forkability :the ability of anyone to take a copy of the source code and use it to start a competing project, known as a fork .The paradoxical thing is that the possibility of forks is usually a much greater force in free software projects than actual forks, which are very rare. Because a fork is bad for everyone (for reasons examined in detail in "Forks "in Chapter 8),the more serious the threat of a fork becomes,the more willing people are to compromise to avoid it.

Forks,or rather the potential for forks,are the reason there are no true dictators in free software projects.This may seem like a surprising claim,considering how common it is to hear someone called the "dictator "or "tyrant "in a given open source project.But this kind of tyranny is special,quite different from the conventional understanding of the word.Imagine a king whose subjects could copy his entire kingdom at any time and move to the copy to rule as they see fit.Would not such a king govern very differently from one whose subjects were bound to stay under his rule no matter what he did?

This is why even projects that are not formally organized as democracies are, in practice, democracies when it comes to important decisions.Replicability implies forkability; forkability implies consensus.It may well be that everyone is willing to defer to one leader (the most famous example being Linus Torvalds in Linux kernel development), but this is because they choose to do so,in an entirely non-cynical and non-sinister way.The dictator has no magical hold over the project.A key property of all open source licenses is that they do not give one party more power than any other in deciding how the code can be changed or used.If the dictator were to suddenly start making bad decisions,there would be restlessness,followed eventually by revolt and a fork. Except,of course,things rarely get that far,because the dictator compromises first.

But just because forkability puts an upper limit on how much power anyone can exert in a project doesn ’t mean there aren ’t important differences in how projects are governed. You don ’t want every decision to come down to the last-resort question of who is considering a fork.That would get tiresome very quickly,and sap energy away from real work.The next two sections examine different ways to organize projects such that most decisions go smoothly. These two examples are somewhat idealized extremes; many projects fall somewhere along a continuum between them.

Benevolent Dictators

The benevolent dictator model is exactly what it sounds like:final decision-making authority rests with one person,who by virtue of personality and experience, is expected to use it wisely.

Although "benevolent dictator "(or BD)is the standard term for this role,it would be better to think of it as "community-approved arbitrator "or "judge ".Generally, benevolent dictators do not actually make all the decisions, or even most of the decisions. It ’s unlikely that one person could have enough expertise to make consistently good decisions across all areas of the project,and anyway, quality developers won ’t stay around unless they have some influence on the project ’s direction. Therefore, benevolent dictators commonly do not dictate much. Instead, they let things work themselves out through discussion and experimentation whenever possible. They participate in those discussions themselves, but as regular developers, often deferring to an area maintainer who has more expertise. Only when it is clear that no consensus can be reached, and that most of the group wants someone to guide the decision so that development can move on, do they put their foot down and say "This is the way it ’s going to be."Reluctance to make decisions by fiat is a trait shared by virtually all successful benevolent dictators;it is one of the reasons they manage to keep the role.

Customer Reviews

Destined to become a classic
This book is excellent, for the following reasons.

1. It provides a lot of very useful, non-obvious advice that I don't think is available in other books. At least, I have read 5 or 6 other books on open-source software, and none of them cover much of the material in this book.

2. The writing style is clear and conversational, which makes it easy to read.

3. The book is short, which makes a welcome change from the bloated 800+ page books that are so common in the computer industry.

I am currently writing some software that I hope to release under an open-source license. I am confident that I have sufficient skills to write the software and even document it. However, there is much more to releasing open-source software than that, and this book has educated me about loads of issues that I am likely to face.

Excellent guide for open source maintainers and contributors
Karl Fogel does a fantastic job of covering everything you need to know about open source projects. It contains everything you need to know about contributing to an open source projects: how to interact with other contributors, working with version control, contributing code, etc. He also provides an excellent guide for running an open source project. The book covers a great deal of ground, giving excellent advice on a wide range of topics: selecting a license; maintaining a mailing list, defect tracking system and version control repository; providing a website; interacting with committers; dealing with technical people; gathering consensus; and understanding important project management concepts. Karl is a veteran of several highly visible and widely used open source projects, and clearly draws on his extensive experiences (both positive and negative). The style is pleasantly conversational, and it's clear that he really knows what he's talking about and is speaking from a position of authority.

(Full Disclosure: I was a technical reviewer for this book, and was thoroughly impressed with it while reviewing it.)

Distilled and practical wisdom
I've just finished reading this book. I've never run an open source project, but having read this I feel like I could have a go - at least I'd know where to start and understand a lots of the issues and pitfalls.
There's clearly the wisdom and experience of a lot of years distilled into this book - both about the technology, and the people issues.
Highly recommended.