In part 3 of this article, I detailed several economic theories on common goods management. In this part, we’ll explore how to apply these theories to the issue of open source sustainability.
Studying the work of Garrett Hardin (Tragedy of the Commons), the prisoner’s dilemma, Mancur Olson (Collective Action), and Elinor Ostrom’s core design principles for self-governance, a number of shared patterns emerge. When applied to open source, I’d summarize them as follows:
- Common goods fail because of a failure to coordinate collective action. To scale and sustain an open source project, open source communities need to transition from individual, uncoordinated action to cooperative, coordinated action.
- Cooperative, coordinated action can be accomplished through privatization, centralization, or self-governance. All three work—and can even be mixed.
- Successful privatization, centralization, and self-governance all require clear rules around membership, appropriation rights, and contribution duties. In turn, this requires monitoring and enforcement, either by an external agent (centralization and privatization), a private agent (self-governance), or members of the group itself (self-governance).
Next, let’s see how these three concepts—centralization, privatization, and self-governance—could apply to open source.
Model 1: Self-governance in open source
For small open source communities, self-governance is very common. It’s easy for its members to communicate, learn who they can trust, share norms, agree on how to collaborate, etc.
As an open source project grows, contribution becomes more complex and cooperation more difficult. It becomes harder to communicate, build trust, agree on how to cooperate, and suppress self-serving behaviors. The incentive to free-ride grows.
You can scale successful cooperation by having strong norms that encourage other members to do their fair share and by having face-to-face events, but eventually, that becomes hard to scale as well.
As Ostrom writes in Governing the Commons:
Even in repeated settings where reputation is important and where individuals share the norm of keeping agreements, reputation and shared norms are insufficient by themselves to produce stable cooperative behavior over the long run. In all of the long-enduring cases, active investments in monitoring and sanctioning activities are quite apparent.
To the best of my knowledge, no open source project currently implements Ostrom’s design principles for successful self-governance. To understand how open source communities might, let’s go back to our running example.
Our two companies would negotiate rules for how to share the rewards of the open source project, and what level of contribution would be required in exchange. They would set up a contract where they both agree on how much each company can earn and how much each company has to invest. During the negotiations, various strategies can be proposed for how to cooperate. However, both parties need to agree on a strategy before they can proceed. Because they are negotiating this contract among themselves, no external agent is required.
These negotiations are non-trivial. As you can imagine, any proposal that does not involve splitting the $100 fifty-fifty is likely rejected. The most likely equilibrium is for both companies to contribute equally and to split the reward equally. Furthermore, to arrive at this equilibrium, one of the two companies would likely have to go backwards in revenue, which might not be agreeable.
Needless to say, this gets even more difficult in a scenario where there are more than two companies involved. Today, it’s hard to fathom how such a self-governance system can successfully be established in an open source project. In the future, Blockchain-based coordination systems might offer technical solutions for this problem.
Large groups are less able to act in their common interest than small ones because (1) the complexity increases and (2) the benefits diminish. Until we have better community coordination systems, it’s easier for large groups to transition from self-governance to privatization or centralization than to scale self-governance.
The concept of major projects growing out of self-governed volunteer communities is not new to the world. The first trade routes were ancient trackways that citizens later developed on their own into roads suited for wheeled vehicles. Privatization of roads improved transportation for all citizens. Today, we certainly appreciate that our governments maintain the roads.
Model 2: Privatization of open source governance
In this model, Makers are rewarded unique benefits not available to Takers. These exclusive rights give Makers a commercial advantage over Takers, while simultaneously creating a positive social benefit for all the users of the open source project, Takers included.
For example, Mozilla has the exclusive right to use the Firefox trademark and to set up paid search deals with search engines like Google, Yandex, and Baidu. In 2017 alone, Mozilla made $542 million from searches conducted using Firefox. As a result, Mozilla can make continued engineering investments in Firefox. Millions of people and organizations benefit from that every day.
Another example is Automattic, the company behind WordPress. Automattic is the only company that can use WordPress.com, and it is in the unique position to make hundreds of millions of dollars from WordPress’ official SaaS offering. In exchange, Automattic invests millions of dollars in the open source WordPress each year.
Recently, there have been examples of open source companies like MongoDB, Redis, Cockroach Labs, and others adopting stricter licenses because of perceived (and sometimes real) threats from public cloud companies that behave as Takers. The ability to change the license of an open source project is a form of privatization.
Model 3: Centralization of open source governance
Let’s assume a government-like central authority can monitor open source companies A and B, with the goal to reward and penalize them for contribution or lack thereof. When a company follows a cooperative strategy (being a Maker), they are rewarded $25 and when they follow an uncooperative strategy (being a Taker), they are charged a $25 penalty. We can update the pay-off matrix introduced above as follows:
We took the values from the pay-off matrix above and applied the rewards and penalties. The result is that both companies are incentivized to contribute and the optimal equilibrium (both become Makers) can be achieved.
The money for rewards could come from various fundraising efforts, including membership programs or advertising (just two examples). However, more likely is the use of indirect monetary rewards.
One way to implement this is Drupal’s credit system. Drupal’s non-profit organization the Drupal Association monitors who contributes what. Each contribution earns you credits and the credits are used to provide visibility to Makers. The more you contribute, the more visibility you get on Drupal.org (visited by two million people each month) or at Drupal conferences (called DrupalCons, visited by thousands of people each year).
While there is a lot more the Drupal Association could and should do to balance Makers and Takers and achieve a more optimal equilibrium for the Drupal project, it’s an emerging example of how an open source non-profit organization can act as a regulator that monitors and maintains the balance of Makers and Takers.
The big challenge with this approach is the accuracy of the monitoring and the reliability of the rewarding (and sanctioning). Because open source contribution comes in different forms, tracking and valuing open source contribution is a very difficult and expensive process, not to mention full of conflict. Running this centralized government-like organization also needs to be paid for, and that can be its own challenge.
As we’ve seen, the various approaches to sustainable open source have their strengths and weaknesses. In part 5 of this article, I’ll detail some concrete suggestions for scaling and sustaining open source.
A version of this post appeared on Dries Buytaert’s personal blog, Dri.es.
