Logging in Tasmania

In 1968, Garrett Hardin coined the term "Tragedy of the Commons" to describe the economic mechanism that drives humans to destroy common resources. The tragedy applies whenever a common resource is "subtractable" - that is, if use of a resource subtracts from it, making what's been extracted unavailable to others. While the full benefit of appropriating the resource goes to the user, the cost is shared among everyone. The consequence is that for a self-interested user of the resource, the benefits of increasing use will always outweigh the costs, even if the resource is ultimately destroyed in the process. Central to this is the problem of freeloaders - even if the vast majority of users use a resource sustainably, a small number of opportunistic freeloaders can quickly soak up the common benefit. The conventional economic view - first expressed by Hardin himself - is that there are two ways to solve the commons problem: privatising the resource so an owner with a direct interest can govern its use, or imposing regulation from "outside" the system. It's interesting to see, then, that this year's Nobel Prize in Economics went to Elinor Ostrom, someone who has made a name arguing against this fatalistic conclusion. Ostrom and her collaborators have produced a huge literature studying commons that follow a third path - consensual, self-generated governance that limits use to sustainable levels.

At the heart of Ostrom's work is a simple question - how does self-governance arise? She approaches this problem with a simple equation describing the cost-benefit analysis of an individual considering whether to participate in communal governance. I've modified it slightly for this post - you can find the original in the paper "Reformulating the Commons":

BN > BE + C

BN is the benefit derived under a new (presumably communal) governance strategy, BE is the benefit derived under the existing (presumably non-communal) strategy, and C is the cost associated with switching. It's as simple as that: the benefit of participating has to exceed the cost. In essence, Ostrom's work on the commons explores the panoply of ways in which communities encourage participation in commons governance by modifying this equation through rewards, penalties and social norms. There's no single successful strategy, and the ones that do work rely on concepts like trust, reciprocity, and the types of institutional structures and individuals involved. Additional complexity comes from the interactions between subsets of users - the equation can be different for every user, and coalitions and factions are common. The huge diversity of solutions means that Ostrom's work is dirtier and more empirical than much of economics, and certainly far removed from the world of identical rational actors in Hardin's original analysis.

It's interesting to consider how this line of thought applies to Open Source projects. Software is not a classical common pool resource, because it's not subtractable - there's no cost to the users or developers of a project if I choose to use it. Nonetheless, an Open Source project is definitely a commons, in the sense that it is a community resource that thrives or starves depending on contributions from its members. The participants in this type of commons is the pool of potential contributors, rather than the pool of potential appropriators. In the same way that using a common pool resource applies a shared penalty to everyone, a contribution to the software commons benefits everyone. This type of non-subtractive (additive?) commons has its own version of the freeloader problem - it pays for a contributor to hang back and wait for someone else to add a needed feature, rather than go to the expense of adding it themselves. If the contributor is a company, it might be beneficial to maintain a competitive advantage by not contributing a change back to the community, even if the work has already been done. Open Source projects face an inverted form of the commons problem, which can be expressed in a modified version of Ostrom's commons equation:

BC > BN + C

Here, BC is the benefit of contributing, which has to outweigh the cost of contributing (C) plus the benefit of not contributing (BN). The Open Source world has produced an immensely sophisticated set of norms and institutions around the terms of this equation, resulting in some of the most successful self-governance structures on the planet. I'd argue that most of the institutional work in Open Source over the last few decades have focused on reducing C - a lot of the basic technology and accompanying social norms used in Open Source development (mailing lists, bug trackers, version control systems, communications protocols) is lubrication to reduce the cost of contributing. I think you could even make a plausible case that much of what drives the Internet is just a side-effect of Open Source projects trying to reduce C.

Another interesting train of thought is spurred by the factor BN - the benefit of not contributing. This nicely illuminates the fundamental difference between commercial and individual contributors - for individual contributors without commercial interests, BN is almost always 0. For commercial contributors, however, this term can be large. Consequently, we would expect projects where commercial contribution is important to have measures that aim to reduce BN - penalties that minimise the benefit of not contributing to the project. The outstanding example here is the Linux kernel project, which has followed a very successful two-fold path to reduce BN. The first, of course, is licensing - the GPL imposes stiff penalties (paid in terms of public outcry and possible legal consequences) on those failing to contribute code back to the project under many circumstances. The terms of the GPL do not cover all types of use, however, so there is a second tier of operational penalties for code that is license compliant, but not contributed back to the project. To quote Greg Kroah-Hartman in a recent interview:

Because of our huge rate of change, [drivers] pretty much have to be in the kernel tree. Otherwise, keeping a driver outside the kernel is technically a very difficult thing to do, because our internal kernel APIs change very, very rapidly.

It's interesting to consider whether this last penalty is intentional or not. There are good technical reasons not to make any stability guarantees for internal APIs, but at the same time I'm sure that many kernel hackers are very aware of the fact that a rapidly-changing internal API compels companies to contribute code. I don't think it's a coincidence that the most successful Open Source project in the world has adopted strategies to penalize potential contributors for not donating code to the community. Reducing BN is one of the reasons why Linux has a vastly greater commercial contribution than, say, FreeBSD, and is therefore a much more vibrant and active project.