Scaling and Sustaining Open Source, Part 3: Three Patterns for Sustainable Open Source
Scaling and Sustaining Open Source, Part 3: Three Patterns for Sustainable Open Source
Nourish and nurture open-source with these three patterns for success.
Join the DZone community and get the full member experience.Join For Free
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.
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 MongoDB, Cockroach 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-governance, privatization, and centralization. All three models aim to reduce coordination failures but require open-source communities to embrace forms of monitoring, rewards, 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 parts last one and two, we focused on defining Makers and Takers, as well as optimizing open-source contributions and dealing with the Prisoner's Dilemma. In this final installment, we will focus on three patterns for creating long-term, sustainable open source. Let's get started.
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.
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. And 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 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.
Model 2: Privatization of Open-Source Governance
In this model, Makers are rewarded with 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 a 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.
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:
Company A contributes. Company A doesn't contribute.
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).
While there is a lot more the Drupal Association could and should do to balance its 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.
Concrete Suggestions for Scaling and Sustaining Open Source
If you 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 the 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 an 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 a 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 percent 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.
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:
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.
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 is 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.
As open-source communities grow, volunteer-driven, self-organized communities become harder to scale. Large open-source projects should find ways to balance Makers and Takers or the open-source project risks not innovating enough under the weight of Takers.
Fortunately, we don't have to accept that future. However, this means that open-source communities potentially have to get comfortable experimenting with how to monitor, reward, and penalize members in their communities, particularly if they rely on a commercial ecosystem for a large portion of their contributions. Today, that goes against the values of most open-source communities, but I believe we need to keep an open mind about how we can grow and scale open source.
Making it easier to scale open-source projects in a sustainable and fairway is one of the most important things we can work on. If we succeed, open source can truly take over the world — it will pave the path for every technology company to become an open-source business, and also solve some of the world's most important problems in an open, transparent and cooperative way.
Opinions expressed by DZone contributors are their own.