Clouds, Code, and Control: The New Open Source Power Struggle
Since the beginning of time, those in power have often used their authority to exploit or dominate those with less influence. This dynamic isn’t limited to historical examples; it can also be seen clearly in modern contexts like technology and software development, particularly in open source projects.
Feudalism is a classic example, where the powerful ruling class controlled the land, leading to oppression and exploitation of the people doing the hard work of farming and protecting the land. With feudalism, power was mainly consolidated in the hands of a few, with the king and the church having the most power. Much of this power was delegated to nobles and lords who administered the land and often provided protection through military services. Still, they served under the king, who could take away this power. These lords and nobles then held power over the peasants who worked the land and had little to no power or autonomy, despite doing most of the real work. So, most of the power was held by the king and church, with nobles and lords having some power, and peasants and serfs holding little to no power while doing most of the work.
Large cloud providers hold the most power, with smaller companies holding some power and individual contributors and users holding little power. The lines are fuzzier, and the consequences less extreme, but with the rise in popularity of large cloud providers, the open source power dynamics might feel similar. In the case of open source, we have ways to flip these power dynamics.
With many of our applications moving into the cloud, it’s become easy to use many of the services provided by these cloud providers. They can offer these services for open source projects, whether they contribute back to these projects or not. When they don’t contribute enough to these open source projects, friction occurs with some smaller companies, which are often the driving force behind open source projects. In some, but not all, cases, those smaller companies might have the power to relicense an open source project, which can flip the balance of power between the smaller company and the cloud provider. However, this power play from the smaller companies puts the maintainers, contributors, and users in a position of even less power. It creates friction around the project that was just relicensed. Within open source projects, those with the least power can then fork the project to flip the power dynamics again, but this is a lot of work and may or may not be successful.
Cloud Providers and the Battle for Open Source Power
These power dynamics are not as simple as I’ve made them sound. Many of these companies fit into multiple categories. For example, cloud providers are also users, contributors, and maintainers of various open source software projects. Companies also need to answer to their investors, boards, and other stakeholders in a position of power over that company, whether a small company or a very large cloud provider.
Lately, some companies have experienced a lot of pressure from VCs, shareholders, or other investors to relicense their open source projects to generate more license revenue, mainly when a vendor’s revenue streams rely solely or primarily on an open source project. This can be compounded if other companies (often large cloud providers) compete for the same customers and profit from the open source project that the vendor has put substantial resources into developing. These concerns about profitability lead to pressure from investors to put the open source project under a new license with more restrictions than would be possible under an open source license. These restrictions often make it more difficult for cloud providers or other companies to profit from the newly relicensed open source project.
This flips the power dynamic and increases the power associated with the smaller company while decreasing the power of the cloud providers. However, this isn’t the end of the power dynamic flip. This is where forks come into play as a form of collective action that flips the power dynamics again and allows those with less power to take control of our destiny as a fork, where we control the governance of this newly formed project. However, it’s not quite as simple as that. Forks are hard work, so while you often hear people say that anyone can fork a project and run with it, it takes a significant number of people and resources to become successful. I mentioned that a smaller company can relicense an open source project to flip the power dynamic and regain power from the cloud providers. Still, those cloud providers can flip the power dynamic again by forking a project and gaining their power back from these smaller companies, and this works pretty well because these big cloud providers can often put a significant number of people and other resources into making a fork successful.
In an earlier TNS blog post, I shared data about three case studies of projects where relicensing led to a fork (Elasticsearch / OpenSearch, Terraform / OpenTofu, and Redis/Valkey). One thing that’s interesting to note is that in all three of these cases, the forks that result from these relicensing events tend to have more organizational variation than the original projects, especially when the forks are created under a neutral foundation, like the Linux Foundation, rather than being forked by a single company. Due to these forks, Redis and Elasticsearch have added the AGPL V3 license to become open source again, but it might be too late to make much difference, given the traction that the forks have been getting.
Protecting Contributors and Maintaining Project Sustainability
These power dynamic shifts can create significant issues for those who use and contribute to these projects. As maintainers, contributors, and even users of open source, we devote our most precious resource to these projects: time. We need the projects we spend time on to be sustainable over the long term to avoid wasting this precious resource. There is no way to predict which projects will be sustained over time vs. those that might experience a relicense or other rug pull, but there are some warning signs, and things we can think about before deciding to spend too much time on a particular project.
- Contributor License Agreements (CLAs): These create a power imbalance within open source communities. The power is tilted toward the company that owns the project and controls the CLA, giving the company more power than other contributors. It may allow companies to relicense a project.
- Neutral Foundations: Projects are much less likely to experience rug pulls if they are under neutral, well-run foundations (instead of individual companies) because those foundations encourage governance structures that create a level playing field where people from different companies can work together as equals to create something that benefits everyone.
- Governance: Rug pulls can and do still happen to foundation projects, usually when all or most of the development comes from a single company’s employees. Projects with neutral governance where leadership positions and maintainers come from various organizations with a fair and transparent process for selecting those leaders are less likely to experience these types of disruptions.
- Contributor Sustainability: Does the project have enough contributors to sustain it over time and replace the existing maintainers when they move on to something else? For the open source projects we rely on, are there enough contributors that if one of them retired on a beach tomorrow with no notice, the project could continue with minimal disruptions?
This leads directly to how companies can help the open source projects that are important to them. I’ve talked a lot about the power dynamics. Still, companies also have the power and resources to make real improvements, and corporate involvement can positively impact the sustainability of our open source projects, including the forks. Companies can allocate employee time to contribute to projects or provide funding and other resources to help sustain open source projects. Having your employees working within a project also enables you to understand the power dynamics that might be at play and better understand the strengths and weaknesses of that project while also being able to influence the project from within.
With the rise in popularity of large cloud providers, the open source power dynamics are looking kind of similar to the feudalism example I talked about at the beginning of this blog post, but in the open source case, what’s different is that we have ways to shift or flip the power dynamics. A smaller company deciding to move a project away from an open source license can flip the power dynamic and gain power back from those large cloud providers. Still, they also shift the balance of power even further away from contributors and users at the same time when they decide to relicense that project. This encourages those with less power to take collective action to fork a project, flipping the power dynamic in favor of the contributors and users, often including the cloud providers as users. Within the open source world, we are better off than the peasants and serfs because we have certain freedoms that allow us to take collective action to regain power by forking projects when others abuse their power.
