⏱️ Lectura: 12 min
60% of open source project maintainers don’t get paid anything for their work, and that number hasn’t changed in three years: Tidelift measured the same figure in 2021, 2023, and 2024. Redis, Elasticsearch, and HashiCorp tried charging anyway between 2021 and 2024, changing the license of their flagship projects, and all three lost to a free fork in under a year. An essay published on Seldo.com proposes a different way out: forcing payment not through the license, but through the registry that every download passes through.
📑 En este artículo
- TL;DR
- Introduction
- What happened
- Context and history
- Technical details and performance
- How to start paying the open source maintainers you use
- Impact and analysis
- What’s next
- Frequently Asked Questions
- What does it mean for open source to be an evolutionarily stable strategy?
- Why couldn’t Redis, Elasticsearch, and Terraform charge for their code?
- What is Valkey, and why did it beat Redis?
- How can a company start paying the maintainers it relies on?
- What is the Linux Foundation’s Census II?
- Do registries like npm or PyPI already charge for publishing packages?
- References
The proposal isn’t philosophical: it means npm, PyPI, or crates.io would charge a toll to the companies that download the most without giving anything back in return.
TL;DR
- 60% of open source maintainers don’t get paid for their work, the same percentage as in 2023 and 2021, according to Tidelift.
- 136 developers write more than 80% of the code in the 50 most-used open source packages, according to the Linux Foundation’s Census II.
- A Harvard study calculated that replacing all open source software would cost the companies that use it for free 8.8 trillion dollars.
- Just 5% of developers produce 96% of the value generated by open source, according to that same study.
- Facebook relicensed React from BSD+Patents to MIT in 2017, within weeks, after the Apache Software Foundation and WordPress rejected it.
- Elastic closed off Elasticsearch’s license in 2021, Amazon forked OpenSearch, and in 2024 Elastic went back to an open license.
- HashiCorp closed Terraform’s license in 2023, the OpenTofu fork was born under the Linux Foundation, and HashiCorp ended up acquired by IBM.
- Redis closed its license in March 2024, the Valkey fork won over every cloud provider within a week, and Redis went back to AGPL in May 2025.
Introduction
The sustainability of open source maintainers came back into the technical conversation after a string of failed attempts to charge directly through licensing. The pattern has repeated since 2017: a company that sustains an open source project tries to change the terms to stop a cloud provider from reselling its work without contributing anything, the community reacts with a fork under a neutral foundation, and that fork ends up winning the market within months.
The essay on Seldo.com doesn’t stop at the diagnosis. It argues that as long as the license is the only payment mechanism, the outcome will always be the same: free software wins by design, because it competes against closed software that costs money. The alternative it proposes runs along a different track: using the registry, the system that delivers every package to every installation, as the point of payment instead of the license.
What happened
Four projects separately tried closing their license to stop being resold by someone who wasn’t paying for it. All four ended up losing to an open fork, though with different nuances in each case.
| Project | License change | Open fork | Result |
|---|---|---|---|
| React | 2017: Apache Software Foundation bans Facebook’s BSD+Patents license from its projects | No fork: WordPress announced it was dropping React | Facebook relicenses to MIT within weeks |
| Elasticsearch | 2021: Elastic switches to a source-available license to stop Amazon’s managed service | OpenSearch (Amazon, later Linux Foundation) | Elastic returns to an open source license in 2024 |
| Terraform | 2023: HashiCorp switches to Business Source License | OpenTofu, under the Linux Foundation | HashiCorp ends up acquired by IBM |
| Redis | March 2024: Redis Labs switches to a dual license with SSPL and RSALv2 | Valkey, adopted by AWS, Google Cloud, and Oracle within a week | Redis returns to AGPL in May 2025 |
The case of Valkey is the fastest of the four: the foundation took in the fork, brought all three major cloud providers on board within days, and Redis admitted the license change had cost it more than it gained by reverting it in 2025. OpenTofu followed a similar path with Terraform. Today it lives under the Linux Foundation with hundreds of contributors, while HashiCorp ended up in IBM’s hands.
Context and history
The essay on Seldo.com explains this pattern with a game theory model borrowed from evolutionary biology: hawks and doves. In a population competing for a resource, hawks fight for it and doves share it. A population made up entirely of hawks is unstable because everyone ends up hurt; a population made up entirely of doves is also unstable because the first hawk that shows up always wins. The only stable outcome is a mix of both in a proportion where switching strategies doesn’t improve an individual’s outcome. That mix is called an evolutionarily stable strategy (ESS).
💭 Key point: an evolutionarily stable strategy isn’t necessarily the best possible one, it’s simply the one that no individual player gains anything by abandoning. That’s why no company managed to sustain a closed license against a well-organized fork.
Applied to software, closed code is the hawk: it competes, charges high prices, and fights to keep its advantage. Open source is the dove: it cooperates and benefits from everyone else cooperating too. The evolutionarily stable strategy the industry arrived at is very specific: anyone can use the code for whatever they want, including commercially, for free. That’s the promise behind licenses like MIT, BSD, and Apache. Every time a project tried to be a slightly less generous dove, it lost to a project that stayed completely free.
flowchart TD
A["Project opens its code with a permissive license"] --> B["Cloud provider resells it without contributing code"]
B --> C["The maintaining company closes the license"]
C --> D["The community creates an open fork"]
D --> E["The fork migrates to a neutral foundation"]
E --> F["Cloud providers adopt the fork"]
F --> G["The original company reverts to an open license"]That cycle explains why the software market ended up split into two very uneven halves: a huge, free half that almost everyone uses, and a small, expensive half that captures almost all the profit. Android has the volume and iOS has the margin, and both strategies are a success depending on which number you look at. Open source wins on adoption; closed software wins on revenue.
Technical details and performance
The problem isn’t abstract: it falls on a very small group of people. According to the Linux Foundation’s Census II, cited in the essay on Seldo.com, 136 developers write more than 80% of the code in the world’s 50 most-used open source packages. Sonatype reviewed 1.2 million open source projects in 2023 and found that only 11% had active maintenance. Of the unpaid maintainers, 61% work completely alone, without a second pair of hands to cover for them if they get sick, change jobs, or simply burn out.
A Harvard study calculated what would happen if open source disappeared overnight. Replacing it with proprietary or contracted software would cost the companies that use it for free today 8.8 trillion dollars. The same study found that just 5% of developers produce 96% of that value. That’s the technical reason behind the burnout of so many open source maintainers: the load isn’t spread evenly, it’s concentrated in a handful of projects that a large part of the internet depends on.
This is where the registry proposal comes in. Today, a registry like npm knows how many downloads each package gets, which organizations install it, and how often. That telemetry already exists: what doesn’t exist is a mechanism to turn it into a charge. The funding field in package.json, for example, is the current, entirely voluntary version of that idea. A maintainer declares where to send donations, but nothing forces anyone to look at it, let alone pay.
How to start paying the open source maintainers you use
Before thinking about whether a registry should charge a toll, any team can measure how much it currently owes the open source it uses for free. The first step is checking what percentage of its direct dependencies declare a funding channel:
npm fundThis command walks through the current project’s dependency tree and lists the funding links each package declared in its package.json. If you’ve never run it, it’s common for the list to come back empty or nearly empty, even if the project has a hundred dependencies.
If you maintain your own library, declaring where to receive support takes two minutes. Here’s a package.json with the funding field pointing to Open Collective:
{
"name": "componente-interno",
"version": "2.3.0",
"description": "Internal HTTP client with retries and circuit breaker",
"funding": {
"type": "opencollective",
"url": "https://opencollective.com/componente-interno"
}
}To check how many of your direct dependencies already declare that field, without reading them one by one, you can pipe npm’s output through jq:
npm fund --json | jq 'keys | length'That number, compared against the total number of direct dependencies (npm ls --depth=0 --json | jq '.dependencies | keys | length'), is a quick way to see how far your stack is from a model where someone besides the original maintainer covers the cost.
⚠️ Watch out: forcing payment through the registry has a root-level problem. npm, PyPI, and crates.io are themselves projects with tight budgets: asking them to arbitrate which company pays how much adds a layer of governance that doesn’t exist and isn’t funded today, and that someone would have to operate.
Impact and analysis
The idea of moving payment from the license to the registry changes who holds the negotiating power. With a license, the maintainer negotiates alone against every company that uses it, and almost always loses because a free fork is just a git clone away. With a registry, the point of payment is shared infrastructure: everyone has to go through it to install the package, so forking the code isn’t enough, you’d also have to fork the distribution.
That shift in leverage already has partial precedents. Tidelift sets up contracts between companies and curated maintainers. Open Collective and GitHub Sponsors channel one-off donations. Germany’s Sovereign Tech Fund directly funds critical internet infrastructure. None of these mechanisms, however, is mandatory: they depend on a company deciding to pay of its own accord, exactly what 60% of projects fail to get.
The real limitation of the proposal is one of governance, not technology. A registry could, in theory, require a fee past a certain volume of corporate downloads. But defining what counts as corporate use, charging across dozens of countries with different regulations, and resolving disputes over who owes how much is work that neither npm, nor PyPI, nor crates.io currently have the budget or legal mandate to do. They’re foundations or companies with small teams, not regulators.
What’s next
The essay on Seldo.com doesn’t propose a date or a finished implementation, it lays out the direction. In the short term, the pressure will most likely keep coming from mechanisms that already exist, not from a structural change in how registries work. Sovereign Tech Fund, Tidelift, and Open Collective are likely to keep growing, and it’s reasonable to expect more registries to add soft friction, like warnings or rankings of unfunded dependencies, before mandatory charges show up.
The Redis-Valkey case left a lesson that any company relying on a single open source provider should take note of: changing the license doesn’t solve the underlying problem, it just pushes the conflict one step further down the road. As long as the registry has no payment mechanism of its own, the evolutionarily stable strategy will keep rewarding whoever gives their code away and punishing whoever tries to charge for it.
📖 Summary on Telegram: View summary
Try it yourself: run npm fund on the project you have open right now and count how many of your direct dependencies have no funding channel declared.
Frequently Asked Questions
What does it mean for open source to be an evolutionarily stable strategy?
It’s a game theory concept applied to software licensing: it describes the equilibrium point the market reaches, not the ideal one. At that equilibrium, no individual project gains anything by no longer giving away its code, because a free fork always shows up to replace it.
Why couldn’t Redis, Elasticsearch, and Terraform charge for their code?
Because in every case a fork appeared under a neutral foundation (Valkey, OpenSearch, OpenTofu) that kept the original license and quickly brought on board the same cloud providers the original company wanted to stop.
What is Valkey, and why did it beat Redis?
Valkey is the Redis fork that was born in March 2024, when Redis Labs switched to a dual license with SSPL and RSALv2. AWS, Google Cloud, and Oracle adopted it in the first week, before Redis could revert the change in May 2025.
How can a company start paying the maintainers it relies on?
By running npm fund, or the equivalent in its package manager, to see which dependencies declare a donation channel, and by joining platforms like Tidelift, Open Collective, or GitHub Sponsors for the ones it relies on the most.
What is the Linux Foundation’s Census II?
It’s a study that maps out who writes the code for the world’s most-used open source packages. It found that just 136 people write more than 80% of the code in the 50 most-downloaded packages.
Do registries like npm or PyPI already charge for publishing packages?
No. Publishing a public package on npm, PyPI, or crates.io is free and requires no fee. The funding field in package.json is voluntary: it declares where to donate, but doesn’t force anyone to pay.
References
- Seldo.com: the original essay, “Nobody pays for open source. We can force them to.”
- OpenTofu: the open fork of Terraform, now under the Linux Foundation.
- Valkey: the open fork of Redis adopted by the major cloud providers.
- OpenSearch: the open fork of Elasticsearch, originated by Amazon.
- npm documentation: reference for the
fundingfield inpackage.json.
📱 Do you like this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.
0 Comments