Rug pulls, forks, and open-source feudalism

Power dynamics

Since the beginning of history, Foster began, those in power have tended to use it against those who were weaker. In the days of feudalism, control of the land led to exploitation at several levels. In the open-source world, the large cloud providers often seem to have the most power, which they use against smaller companies. Contributors and maintainers often have less power than even the smaller companies, and users have less power yet.

We have built a world where it is often easiest to just use whatever a cloud provider offers, even with open-source software. Those providers may not contribute back to the projects they turn into services, though, upsetting the smaller companies that are, likely as not, doing the bulk of the work to provide the software in question in the first place. Those companies can have a power of their own, however: the power to relicense the software. Pulling the rug out from under users of the software in this way can change the balance of power with regard to cloud providers, but it leaves contributors and users in a worse position than before. But there is a power at this level too: the power to fork the software, flipping the power balance yet again.

Companies that control a software project have the power to carry out this sort of rug pull, and they are often not shy about exercising it. Single-company projects, clearly, are at a much higher risk of rug pulls; the company has all the power in this case, and others have little recourse. So one should look at a company's reputation before adopting a software project, but that is only so helpful. Companies can change direction without notice, be acquired, or go out of business, making previous assessments of their reputation irrelevant.

The problem often comes down to the simple fact that companies have to answer to their investors, and that often leads to pressure to relicense the software they have created in order to increase revenue. This is especially true in cases where cloud providers are competing for the same customers as the company that owns the project. The result can be a switch to a more restrictive license aimed at making it harder for other companies to profit from the project.

A rug pull of this nature can lead to a fork of the project — a rebellious, collective action aimed at regaining some power over the code. But a fork is not a simple matter; it is a lot of work, and will fail without people and resources behind it. The natural source for that is a large company; cloud providers, too, can try to shift power via a fork, and they have the ability to back their fork up with the resources it needs to succeed.

A relicensing event does not always lead to a popular fork; that did not happen with MongoDB or Sentry, for example. Foster said she had not looked into why that was the case. Sometimes rug pulls take other forms, such as when Perforce, after acquiring Puppet in 2022, moved its development and releases behind closed doors, with a reduced frequency of releases back to the public repository. That action kicked off the OpenVox fork.

Looking at the numbers

Foster has spent some time analyzing rug pulls, forks, and what happens thereafter; a lot of the results are available for download as Jupyter notebooks. For each rug-pull event, she looked at the contributor makeup of the project before and after the ensuing fork in an attempt to see what effects are felt by the projects involved.

In 2021, Elastic relicensed Elasticsearch under the non-free Server Side Public License (SSPL). Amazon Web Services then forked the project as OpenSearch. Before the fork, most of the Elasticsearch contributors were Elastic employees; that, unsurprisingly, did not change afterward. OpenSearch started with no strong contributor base, so had to build its community from scratch. As a result, the project has been dominated by Amazon contributors ever since; the balance has shifted slowly over time, but there was not a big uptick in outside contributors even after OpenSearch became a Linux Foundation project in 2024. While starting a project under a neutral foundation can help attract contributors, she said, moving a project under a foundation's umbrella later on does not seem to provide the same benefit.

Terraform was developed mostly by Hashicorp, which relicensed the software under the non-free Business Source License in 2023. One month later, the OpenTofu fork was started under the Linux Foundation. While the contributor base for Terraform, which was almost entirely Hashicorp employees, changed little after the fork, OpenTofu quickly acquired a number of contributors from several companies, none of whom had been Terraform contributors before. In this case, users drove the fork and placed it under a neutral foundation, resulting in a more active developer community.

In 2024, Redis was relicensed under the SSPL; the Valkey fork was quickly organized, under the Linux Foundation, by Redis contributors. The Redis project differed from the others mentioned here in that, before the fork, it had nearly twice as many contributors from outside the company as from within; after the fork, the number of external Redis contributors dropped to zero. All of the external contributors fled to Valkey, with the result that Valkey started with a strong community representing a dozen or so companies.

Looking at how the usage of these projects changes is harder, she said, but there appears to be a correlation between the usage of a project and the number of GitHub forks (cloned repository copies) it has. There is typically a spike in these clones after a relicensing event, suggesting that people are considering creating a hard fork of the project. In all cases, the forks that emerged appeared to have less usage than the original by the "GitHub forks" metric; both branches of the fork continue to go forward. But, she said, projects that are relicensed do tend to show reduced usage, especially when competing forks are created under foundations.

What to do

This kind of power game creates problems for both contributors and users, she said; we contribute our time to these projects, and need them to not be pulled out from under us. There is no way to know when a rug pull might happen, but there are some warning signs to look out for. At the top of her list was the use of a contributor license agreement (CLA); these agreements create a power imbalance, giving the company involved the power to relicense the software. Projects with CLAs more commonly are subject to rug pulls; projects using a developers certificate of origin do not have the same power imbalance and are less likely to be rug pulled.

One should also look at the governance of a project; while being housed under a foundation reduces the chance of a rug pull, that can still happen, especially in cases where the contributors are mostly from a single company. She mentioned the Cortex project, housed under the Cloud Native Computing Foundation, which was controlled by Grafana; that company eventually forked its own project to create Mimir. To avoid this kind of surprise, one should look for projects with neutral governance, with leaders from multiple organizations.

Projects should also be evaluated on their contributor base; are there enough contributors to keep things going? Companies can help, of course, by having their employees contribute to the projects they depend on, increasing influence and making those projects more sustainable. She mentioned the CHAOSS project, which generates metrics to help in the judgment of the viability of development projects. CHAOSS has put together a set of "practitioner guides" intended to help contributors and maintainers make improvements within a project.

With the sustained rise of the big cloud providers, she concluded, the power dynamics around open-source software are looking increasingly feudal. Companies can use relicensing to shift power away from those providers, but they also take power from contributors when they pull the rug in this way. Those contributors, though, are in a better position than the serfs of old, since they have the ability to fork a project they care about, shifting power back in their direction.

Hazel Weakly asked if there are other protections that contributors and users might develop to address this problem. Foster answered that at least one company changed its mind about a planned relicensing action after seeing the success of the Valkey and OpenTofu forks. The ability to fork has the effect of making companies think harder, knowing that there may be consequences that follow a rug pull. Beyond that, she reiterated that projects should be pushed toward neutral governance. Dirk Hohndel added that the best thing to do is to bring more outside contributors into a project; the more of them there are, the higher the risk associated with a rug pull. Anybody who just sits back within a project, he said, is just a passenger; it is better to be driving.

Foster's slides are available for interested readers.

[Thanks to the Linux Foundation, LWN's travel sponsor, for supporting my travel to this event.]