How takers hurt makers in open source

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

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.

How Takers hurt Makers

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:

  • The Taker takes advantage of the Maker’s $500k investment in open source contribution while only investing $50k themselves. Important improvements happen “for free” without the Taker’s involvement.
  • The Taker can out-innovate the Maker in building proprietary offerings. When a Taker invests $950k in closed-source products compared to the Maker’s $500k, the Taker can innovate 90% faster. The Taker can also use the delta to disrupt the Maker on price.

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.

Open source contribution 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 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:

  • 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:

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.

Join the newsletter!

Or

Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

More about

Show Comments
[]