In part 1 of this article, I introduced the concept of open source Makers and Takers, and explained why it is important to find new ways to scale and sustain open source communities. Here in part 2, I’ll dive into why Takers hurt Makers, as well as how the “prisoner’s dilemma” affects the behavior of takers.

To be financially successful, many Makers mix open source contributions with commercial offerings. Their commercial offerings usually take the form of proprietary or closed source IP, which may include a combination of premium features and hosted services that offer performance, scalability, availability, productivity, and security assurances. This is known as the open core business model. Some Makers offer professional services, including maintenance and support assurances.

When Makers start to grow and demonstrate financial success, the open source project that they are associated with begins to attract Takers. Takers will usually enter the ecosystem with a commercial offering comparable to the Makers’ but without making a similar investment in open source contribution. Because Takers don’t contribute back meaningfully to the open source project that they take from, they can focus disproportionately on their own commercial growth.

Let’s look at a theoretical example.

When a Maker has $1 million to invest in R&D, they might choose to invest $500k in open source and $500k in the proprietary IP behind their commercial offering. The Maker intentionally balances growing the open source project they are connected to with making money. To be clear, the investment in open source is not charity; it helps make the open source project competitive in the market, and the Maker stands to benefit from that.

When a Taker has $1 million to invest in R&D, nearly all of their resources go to the development of proprietary IP behind their commercial offerings. They might invest $950k in their commercial offerings that compete with the Maker’s, and $50k towards open source contribution. Furthermore, the $50k is usually focused on self-promotion rather than being directed at improving the open source project itself.

Effectively, the Taker has put itself at a competitive advantage compared to the Maker:

In other words, Takers reap the benefits of the Makers’ open source contribution while simultaneously having a more aggressive monetization strategy. The Taker is likely to disrupt the Maker. On an equal playing field, the only way the Maker can defend itself is by investing more in its proprietary offering and less in the open source project. To survive, it has to behave like the Taker to the detriment of the larger open source community.

The example above can be described as a prisoner’s dilemma. The prisoner’s dilemma is a standard example of game theory, which involves 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:

This can be summarized in a pay-off matrix:

Company A contributes

Company A doesn’t contribute

Company B contributes

 A makes $50

 B makes $50

 A makes $60

 B makes $20

Company B doesn’t contribute

 A makes $20

 B makes $60

 A makes $10

 B makes $10

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 in part 3 of this article.

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

This story, "How takers hurt makers in open source" was originally published by InfoWorld.