Thoughtful and useful look at how to sustain Open Source projects at scale by the founder of Drupal (a popular open source website builder/CMS): Balancing Makers and Takers to Scale and Sustain Open Source
Three patterns for long-term sustainable Open Source
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 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 + 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.
While considering the self-governance model he writes:
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 which 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.
On ‘privatisation’, it’s not as bad as it sounds:
Model 2: Privatization of Open Source governance
In this model, Makers are rewarded unique benefits not available to Takers. These exclusive rights provide 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 is in the unique position to make hundreds of millions of dollars from WordPress’ official SaaS service. 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.
Similarly the ‘centralisation’ model, it sounds sensible and effective to me:
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 a defect strategy ( being a Taker ), they are charged a $25 penalty. We can update the pay-off matrix introduced above as follows:
[diagram omitted]
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 as a few 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 2 million people each month) or at Drupal conferences (called DrupalCons, visited by thousands of people each year).
I think with SAFE Network we have a hybrid of ‘privatisation’ and ‘centralisation’ of governance which should allow this open source project to both scale and sustain, under the auspices of the Maidsafe Foundation (a Scottish charity) which has exclusive rights over key parts of Maidsafe Limited’s IP among other privileges.
At the end he includes the following recommendations:
Concrete suggestions for scaling and sustaining Open Source
Suggestion 1: Don’t just appeal to organizations’ self-interest, but also to their fairness principles
If, like most economic theorists, you believe that organizations act in their own self-interest, we should appeal to that self-interest and better explain the benefits of contributing to Open Source.
Despite the fact that hundreds of articles have been written about the benefits of contributing to Open Source — highlighting speed of innovation, recruiting advantages, market credibility, and more — many organizations still miss these larger points.
It’s important to keep sharing Open Source success stories. One thing that we have not done enough is appeal to organizations’ fairness principles.
While a lot of economic theories correctly assume that most organizations are self-interested, I believe some organizations are also driven by fairness considerations.
Despite the term “Takers” having a negative connotation, it does not assume malice. For many organizations, it is not apparent if an Open Source project needs help with maintenance, or how one’s actions, or lack thereof, might negatively affect an Open Source project.
As mentioned, Acquia is a heavy user of Varnish Cache. But as Acquia’s Chief Technology Officer, I don’t know if Varnish needs maintenance help, or how our lack of contribution negatively affects Makers in the Varnish community.
It can be difficult to understand the consequences of our own actions within Open Source. Open Source communities should help others understand where contribution is needed, what the impact of not contributing is, and why certain behaviors are not fair. Some organizations will resist unfair outcomes and behave more cooperatively if they understand the impact of their behaviors and the fairness of certain outcomes.
Make no mistake though: most organizations won’t care about fairness principles; they will only contribute when they have to. For example, most people would not voluntarily redistribute 25-50% of their income to those who need it. However, most of us agree to redistribute money by paying taxes, but only so long as all others have to do so as well.
Suggestion 2: Encourage end users to offer selective benefits to Makers
We talked about Open Source projects giving selective benefits to Makers (e.g. Automattic, Mozilla, etc), but end users can give selective benefits as well. For example, end users can mandate Open Source contributions from their partners. We have some successful examples of this in the Drupal community:
- Pfizer uses Drupal for hundreds of their websites. They work with dozens of digital agencies to build and maintain these sites. As a policy, Pfizer only works with agencies that contribute back to Drupal.
- The State of Georgia started doing the same; they also made Open Source contribution a vendor selection criteria.
If more end users of Open Source took this stance, it could have a very big impact on Open Source sustainability. For governments, in particular, this seems like a very logical thing to do. Why would a government not want to put every dollar of IT spending back in the public domain? For Drupal alone, the impact would be measured in tens of millions of dollars each year.
Suggestion 3: Experiment with new licenses
I believe we can create licenses that support the creation of Open Source projects with sustainable communities and sustainable businesses to support it.
For a directional example, look at what MariaDB did with their Business Source License (BSL). The BSL gives users complete access to the source code so users can modify, distribute and enhance it. Only when you use more than x of the software do you have to pay for a license. Furthermore, the BSL guarantees that the software becomes Open Source over time; after y years, the license automatically converts from BSL to General Public License (GPL), for example.
A second example is the Community Compact, a license proposed by Adam Jacob. It mixes together a modern understanding of social contracts, copyright licensing, software licensing, and distribution licensing to create a sustainable and harmonious Open Source project.
We can create licenses that better support the creation, growth and sustainability of Open Source projects and that are designed so that both users and the commercial ecosystem can co-exist and cooperate in harmony.
I’d love to see new licenses that encourage software free-riding (sharing and giving), but discourage customer free-riding (unfair competition). I’d also love to see these licenses support many Makers, with built-in inequity and fairness principles for smaller Makers or those not able to give back.
If, like me, you believe there could be future licenses that are more “Open Source”-friendly, not less, it would be smart to implement a contributor license agreement for your Open Source project; it allows Open Source projects to relicense if/when better licenses arrive. At some point, current Open Source licenses will be at a disadvantage compared to future Open Source licenses.
). Moreover - in regard to the 1st suggestion - research shows that without (altruistic) punishment, cooperation in collective games tends to fall apart. The third suggestion is probably going to be a part of an ultimate solution.