Table of Contents
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, running 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 make decisions on a day-to-day basis, and say nothing about how conflicts are resolved.
This chapter tries to show the structural properties successful projects have in common. I mean "successful" not just in terms of technical quality, but in terms of 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 continue 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[57].
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 use less formal structure, but more personal self-restraint on the part of leaders, 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.
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.[58]
The paradoxical thing is that the possibility of forks is usually a much greater force in free software projects than actual forks are. Actual forks are very rare. Because a fork is usually bad for everyone (for reasons examined in detail in the section called “Forks”), the more serious the threat of a fork becomes, the more willing people are to compromise to avoid it.
The potential for forks is 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" (sometimes softened to "benevolent dictator") in a given open source project. But this kind of dictatorship is special, quite different from our conventional understanding of the word. Imagine a ruler whose subjects could copy her entire territory at any time and move to the copy to rule as they see fit. Would not such a ruler govern very differently from one whose subjects were bound to stay under her rule no matter what she did?
This is why even projects that are not formally organized as democracies are, in practice, democracies when it comes to important decisions.[59] Replicability implies forkability, and forkability implies consensus. It may well be that everyone is willing to defer to one leader,[60] but this is because they choose to do so, in a situation where they really do have freedom of choice.
The nominal "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, that 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 might consider 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.
[57] This is also known as the "Bus Factor", that is, how many participants would have to get hit by a bus (figuratively speaking) for the project to be unable to continue. See https://en.wikipedia.org/wiki/Bus_factor.
[58] Meaning a "hard fork", not the unrelated "development fork" that is often a normal part of the development cycle. See the section called “"Development Forks" versus "Hard Forks"” for more on this crucial distinction.
[59] Though note that this still leaves a lot of room for variety, and the goals of a project's main sponsors usually have a significant effect on the project's structure and operating processes. As mentioned earlier in Chapter 1, Introduction, the report Open Source Archetypes: A Framework For Purposeful Open Source (https://opentechstrategies.com/archetypes), is worth consulting if you want to understand more about this.
[60] The most famous example is probably Linus Torvalds in Linux kernel development.