Balancing makers and takers to sustain open source

Open source and the free-rider problem

How to balance makers and takers to scale and sustain open source projects, companies, and ecosystems (part 3)

Open source and the free-rider problem

In part 2 of this article, I focused on how Takers hurt Makers in open source, as well as how individual actions—no matter how rational they may seem—can have adverse outcomes for open source communities. Now I’ll show how these problems have been solved elsewhere by looking at popular economic theories.

In economics, the concepts of public goods and common goods are decades old, and have similarities to open source.

Public goods and common goods are what economists call non-excludable, meaning it’s hard to exclude people from using them. For example, everyone can benefit from fishing grounds, whether they contribute to their maintenance or not. Simply put, public goods and common goods have open access.

Common goods are rivalrous; if one individual catches a fish and eats it, the other individual can’t. In contrast, public goods are non-rivalrous; someone listening to the radio doesn’t prevent others from listening to the radio.

Open source: A public good or a common good?

I’ve long believed that open source projects are public goods. Everyone can use open source software (non-excludable), and someone using an open source project doesn’t prevent someone else from using it (non-rivalrous).

However, through the lens of open source companies, open source projects are also common goods. Everyone can use open source software (non-excludable), but when an open source end user becomes a customer of Company A, that same end user is unlikely to become a customer of Company B (rivalrous).

Next, I’d like to extend the distinction between “open source software being a public good” and “open source customers being a common good” to the free-rider problem. We define software free-riders as those who use the software without ever contributing back, and customer free-riders (or Takers) as those who sign up customers without giving back.

All open source communities should encourage software free-riders. Because the software is a public good (non-rivalrous), a software free-rider doesn’t exclude others from using the software. Hence, it’s better to have a person use your open source project than your competitor’s software. Furthermore, a software free-rider makes it more likely that other people will use your open source project (by word of mouth or otherwise). When some portion of those other users contribute back, the open source project benefits. Software free-riders can have positive network effects on a project.

However, when the success of an open source project depends largely on one or more corporate sponsors, the open source community should not forget or ignore that customers are a common good. Because a customer can’t be shared among companies, it matters a great deal for the open source project where that customer ends up. When the customer signs up with a Maker, we know that a certain percentage of the revenue associated with that customer will be invested back into the open source project. When a customer signs up with a customer free-rider or Taker, the project doesn’t stand to benefit. In other words, open source communities should find ways to route customers to Makers.

Lessons from decades of common goods management

Hundreds of research papers and books have been written on the governance of public goods and common goods. Over the years, I have read many of them to figure out what open source communities can learn from successfully managed public goods and common goods.

Some of the most instrumental research was Garrett Hardin’s tragedy of the commons and Mancur Olson’s work on collective action. Both Hardin and Olson concluded that groups don’t self-organize to maintain the common goods they depend on.

As Olson writes in the beginning of his book, The Logic of Collective Action:

Unless the number of individuals is quite small, or unless there is coercion or some other special device to make individuals act in their common interest, rational, self-interested individuals will not act to achieve their common or group interest.

Consistent with the prisoner’s dilemma, Hardin and Olson show that groups don’t act on their shared interests. Members are disincentivized from contributing when other members can’t be excluded from the benefits. It is individually rational for a group’s members to free-ride on the contributions of others.

Dozens of academics, Hardin and Olson included, have argued that an external agent is required to solve the free-rider problem. The two most common approaches are centralization and privatization:

  1. When a common good is centralized, the government takes over the maintenance of the common good. The government or state is the external agent.
  2. When a public good is privatized, one or more members of the group receive selective benefits or exclusive rights to harvest from the common good in exchange for the ongoing maintenance of the common good. In this case, one or more corporations act as the external agent.

The widespread advice to centralize and privatize common goods has been followed extensively in most countries. Today, the management of natural resources is typically done either by the government or by commercial companies, but no longer directly by its users. Examples include public transport, water utilities, fishing grounds, parks, and much more.

Overall, the privatization and centralization of common goods has been very successful. In many countries, public transport, water utilities, and parks are maintained better than volunteer contributors would have achieved on their own. I certainly value that I don’t have to help maintain the train tracks before my daily commute to work, or that I don’t have to help mow the lawn in our public park before I can play soccer with my kids.

Community managed common goods

For years, it was a long-held belief that centralization and privatization were the only ways to solve the free-rider problem. It was Elinor Ostrom who observed that a third solution existed.

Ostrom found hundreds of cases where common goods are successfully managed by their communities, without the oversight of an external agent. Her examples range from the management of irrigation systems in Spain to the maintenance of mountain forests in Japan, all successfully self-managed and self-governed by their users. Many have been long-enduring as well. The youngest examples Ostrom studied were more than 100 years old, and the oldest exceeded 1,000 years.

Ostrom studied why some efforts to self-govern commons have failed and why others have succeeded. She summarized the conditions for success in the form of core design principles. Her work led her to win the Nobel Prize in Economics in 2009.

Interestingly, all successfully managed commons studied by Ostrom switched at some point from open access to closed access. As Ostrom writes in her book, Governing the Commons:

For any appropriator to have a minimal interest in coordinating patterns of appropriation and provision, some set of appropriators must be able to exclude others from access and appropriation rights.

Ostrom uses the term appropriator to refer to those who use or withdraw from a resource. Examples would be fishers, irrigators, herders, etc.—or companies trying to turn open source users into paying customers. In other words, the shared resource must be made exclusive (to some degree) in order to incentivize members to manage it. Put differently, Takers will be Takers until they have an incentive to become Makers.

Once access is closed, explicit rules need to be established to determine how resources are shared, who is responsible for maintenance, and how self-serving behaviors are suppressed. In all successfully managed commons, the regulations specify (1) who has access to the resource, (2) how the resource is shared, (3) how maintenance responsibilities are shared, (4) who inspects that rules are followed, (5) what fines are levied against anyone who breaks the rules, (6) how conflicts are resolved, and (7) a process for collectively evolving these rules.

In part 4 of this article, I’ll focus on how to apply these economic theories to open source communities.

A version of this post appeared on Dries Buytaert’s personal blog,


Copyright © 2019 IDG Communications, Inc.

How to choose a low-code development platform