Scaling and Sustaining Open Source, Part 2: OS Contributions and the Prisoner's Dilemma

DZone 's Guide to

Scaling and Sustaining Open Source, Part 2: OS Contributions and the Prisoner's Dilemma

Despite open source being widely adopted and more than 30 years old, scaling and sustaining open source projects remains challenging.

· Open Source Zone ·
Free Resource

Prisoner's Dilemma

Here's a closer look at open source and the Prisoner's Dilemma

To scale and sustain open-source ecosystems in a more efficient and fair manner, open-source projects need to embrace new governance, coordination, and incentive models.

In many ways, open source has won. Most people know that open-source provides better quality software, at a lower cost, without vendor lock-in. But despite open source being widely adopted, and more than 30 years old, scaling and sustaining open-source projects remains challenging.

You may also like:  How to Participate in Open Source Projects

Not a week goes by that I don't get asked a question about open-source sustainability. How do you get others to contribute? How do you get funding for open-source work? But also, how do you protect against others monetizing your open-source work without contributing back? And what do you think of MongoDBCockroach Labs, or Elastic changing their license away from open source?

This series talks about how we can make it easier to scale and sustain open-source projects, open-source companies, and open-source ecosystems. I will show that:

  • Small open-source communities can rely on volunteers and self-governance, but as open-source communities grow, their governance model most likely needs to be reformed so the project can be maintained more easily.
  • There are three models for scaling and sustaining open-source projects: self-governanceprivatization, and centralization. All three models aim to reduce coordination failures but require open-source communities to embrace forms of monitoringrewards, and sanctions. While this thinking is controversial, it is supported by decades of research in adjacent fields.
  • Open-source communities would benefit from experimenting with new governance models, coordination systems, license innovation, and incentive models.

In our last article, we focused on defining Makers and Takers. In this installment, we will focus on open-source contributions and the Prisoner's Dilemma.

Open-Source Contributions and the Prisoner's Dilemma

The example above can be described as a Prisoner's Dilemma. The Prisoner's Dilemma is a standard example of game theory, which allows the study of strategic interaction and decision-making using mathematical models. I won't go into detail here, but for the purpose of this article, it helps me simplify the above problem statement. I'll use this simplified example throughout the article.

Imagine an open-source project with only two companies supporting it. The rules of the game are as follows:

  • If both companies contribute to the open-source project (both are Makers), the total reward is $100. The reward is split evenly and each company makes $50.
  • If one company contributes while the other company doesn't (one Maker, one Taker), the open-source project won't be as competitive in the market, and the total reward will only be $80. The Taker gets $60 as they have the more aggressive monetization strategy, while the Maker gets $20.
  • If both players choose not to contribute (both are Takers), the open-source project will eventually become irrelevant. Both walk away with just $10.

This can be summarized in a pay-off matrix:

Company A contributesCompany A doesn't contribute

In the game, each company needs to decide whether to contribute or not, but Company A doesn't know what company B decides; and vice versa.

The Prisoner's Dilemma states that each company will optimize its own profit and not contribute. Because both companies are rational, both will make that same decision. In other words, when both companies use their "best individual strategy" (be a Taker, not a Maker), they produce an equilibrium that yields the worst possible result for the group: the open-source project will suffer, and as a result, they only make $10 each.

A real-life example of the Prisoner's Dilemma that many people can relate to is washing the dishes in a shared house. By not washing dishes, an individual can save time (individually rational), but if that behavior is adopted by every person in the house, there will be no clean plates for anyone (collectively irrational). How many of us have tried to get away with not washing the dishes? I know I have.

Fortunately, the problem of individually rational actions leading to collectively adverse outcomes is not new or unique to open source. Before I look at potential models to better sustain open-source projects, I will take a step back and look at how this problem has been solved elsewhere.

Open Source: Public Good or Common Good?

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.

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).

For end-users, open-source projects are public goods; the shared resource is the software. But for open-source companies, open-source projects are common goods; the shared resource is the (potential) customer.

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 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 user for your open-source project than having that person use 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 contributes 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.

Both volunteer-driven and sponsorship-driven open-source communities should encourage software free-riders, but sponsorship-driven open-source communities should discourage customer free-riders.

Lessons From Decades of Common Goods Management

Hundreds of research papers and books have been written on public good and common good governance. 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 shows 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, argued that an external agent is required to solve the free-rider problem. The two most common approaches are (1) centralization and (2) 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 wide-spread advice to centralize and privatize common goods has been followed extensively in most countries; today, the management of natural resources is typically managed by either 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 have been very successful; in many countries, public transport, water utilities, and parks are maintained better than volunteer contributors would have 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.

For years, it was a long-held belief that centralization and privatization were the only way 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. From the management of irrigation systems in Spain to the maintenance of mountain forests in Japan - all have been successfully self-managed and self-governed by their users. Many have been long-enduring as well; the youngest examples she studied were more than 100 years old, and the oldest exceed 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 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.

Further Reading

How to Participate in Open Source Projects

DZone's Guide to Open Source: Democratizing Development

Making Money From Open Source Software: The Dichotomy

contributions ,open source ,open source projects ,os ,os contributions ,prisoner's dilemma

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}