But it feels like the problem is getting worse, doesn’t it? If a stable system is producing worse outcomes than it used to, one of the inputs moved. The one that moved is speed.
Linux accumulated slowly, so you could maintain a chunk of the kernel on nights and weekends for a decade, because nobody was waiting on you. Then the web happened, and then npm happened, and a million tiny modules appeared in about ten years, any one of which could become load-bearing for somebody’s production system within weeks of being Nights and weekends stopped being enough, and people kept doing it anyway, because they were always going to write the software. Developers write software the way singers sing, which is to say they’d do it if nobody was listening, and that isn’t a problem to be fixed, it’s the thing that makes the whole system work. Any proposed solution that involves developers writing less software, or writing less generously, is a non-starter with me. The problem isn’t that people write software for free. It’s that we’ve arranged things so the people who write the most useful software for free get a second unpaid job as a reward.
This is the depressing bit, and it’s the bit I’ve been putting off for four years, so let’s get through it quickly. Here is what we’ve tried:
Look at what all of these have in common. They’re all voluntary. Companies are asked to give, and some do, and most don’t, and the ones that don’t get exactly the same software as the ones that do. Charity doesn’t scale, and nobody has the authority to issue a mandate. We have been asking companies to pay for open source for thirty years, and I think we can consider asking to be fully tested.
Here’s the thing that made me realize I’d been thinking about this wrong: companies already pay for open source, quite a lot of money in fact, they just don’t pay it to maintainers.
JFrog sells Artifactory, which is a private mirror that sits between your build servers and the public package registries. JFrog had $532 million in revenue in 2025, up 24%. Snyk, which scans your dependencies for vulnerabilities, is at about $326 million a year. Docker, which runs the registry every container image comes from, is at $207 million. Chainguard, which sells hardened versions of open source images, went from about $40 million to a target of $100 million in a year. Sonatype is private, but it both runs Maven Central, the registry every Java build pulls from, and sells Nexus, the mirror you put in front of it; by Sonatype’s own numbers 86% of Maven Central’s traffic comes from cloud providers, which is to say from companies. Add Sonar, which now owns Tidelift, and Socket, and the rest of the supply chain security market, and you’re comfortably over a billion dollars a year.
What is all that money for? Strip off the marketing and every one of these companies is selling the same thing, which is dependable supply of free code. Your builds don’t break when the registry goes down. Your dependencies are cached, scanned, signed, and provably what they say they are. When the next Log4Shell happens you can find out in an hour which of your two thousand services is affected. That’s a real product solving a real problem, and companies buy it enthusiastically, because “the free thing we depend on might be broken or malicious and we can’t tell” is exactly the kind of problem a procurement department knows how to spend money on.
I want to be clear that I don’t think these companies are villains. Several of them are run by people I like. They’re solving the actual problem, which is that companies need to be able to depend on code they didn’t write and can’t inspect. They’re just solving it at the wrong layer. They sell insurance against the maintainer, when the maintainer is the one person in the chain who can actually make the code more secure, and she gets nothing while a company two layers up gets paid to tell you whether she did.
This changed my whole view of the problem. For years I assumed the constraint was the supply of money: companies simply would not pay for open source and no mechanism could make them, and Lorenc’s story fits that. But the JFrog invoice says otherwise: companies will pay for open source, happily, when it shows up as a boring line item labelled “supply chain.” The supply of money was never the problem, the problem is where it gets captured on the way down.
So why doesn’t the ESS apply here? If free always wins, why hasn’t a free mirror eaten JFrog?
Because there are two games going on, and they have different winners. In the code game the resource is the software itself, and free wins every time, because anybody can copy code, so any attempt to charge for it invites a copy that doesn’t. In the supply game the resource is not having to think about where the code comes from, and that game is won by whoever is the default.
Look at the evidence. Nobody has ever successfully forked a registry. Free mirrors of npm, PyPI and Docker Hub exist, are trivial to run, and in some cases are one command away, and companies pay JFrog half a billion dollars a year regardless. Red Hat lost the desktop to Ubuntu, which was funded by a rich guy giving it away, and lost it decisively; the dove won the code game. Red Hat then sold to IBM for $34 billion and makes north of $6 billion a year selling companies supply of the same free code with a phone number attached. Anybody could have had the same code for free, and lots of them did, but a very large number of companies paid Red Hat anyway.
Docker is the clearest example because it happened recently and in public. In November 2020 Docker Hub started rate-limiting anonymous and free pulls. In August 2021 Docker Desktop became a paid product for any company with more than 250 employees or $10 million in revenue, and stayed free for individuals, small companies and open source projects. If free always won, a free alternative should have eaten them, and Podman and containerd exist and are free and are perfectly fine. Instead Docker’s revenue went from roughly $12 million in 2020 to over $50 million in 2021 to $207 million in 2024, with more than a million paid seats. (Docker also tried announcing per-pull consumption charges and then cancelled them in 2025 after developers rioted, which tells you exactly what shape of charge works: bill the company, not the download. Nobody wants a bill that goes up every time CI reruns.)
Free wins the code game, but the supply game is won by whoever is the default, and defaults can charge. The registries are the one place in the whole system where the two games touch, because they are where free code turns into supply, and unlike a license, a registry can’t be routed around by copying, because it’s not a legal restriction, it’s an extremely convenient piece of infrastructure. They don’t want to route around it; routing around it is a pain in the ass worth paying to avoid.
At this point somebody is going to say “hasn’t this been tried?”, and the answer is sort of, and the ways it failed are instructive. I’m going to define “the registry layer” narrowly: whoever owns the domain that everybody is downloading stuff from. By that definition almost nothing on this list counts.
In August 2019 Feross Aboukhadijeh, who maintained a hundred-odd npm packages including Standard, started printing sponsor messages in the terminal during npm install. Developers hated it, the sponsors backed out within days, and Feross wrote it up as a failed experiment. npm’s response was to ban terminal ads in its terms of service and ship npm fund, which prints a list of donation links. That’s the one time the actual registry has intervened in funding, and what it did was take away a way of getting money and replace it with a hyperlink. That is some weak tea. In my time at npm we never had the courage to try anything more extreme, and we should have.
Flossbank, from 2020 to 2022, wrapped npm and yarn, collected small donations or ad revenue, and split it across the whole dependency tree of whatever you installed. That is the payout half of what I’m about to propose, built and working. It shut down, and the founder’s post-mortem is honest about why: it was opt-in, and opt-in dies of “why should I pay if the next guy doesn’t.” Flossbank also wasn’t the registry, it was a thing you installed in front of the registry, which is enough friction that nobody bothers.
Ruby Together, from 2015 to 2022, collected membership fees from companies to fund work on RubyGems and Bundler. It worked, modestly, until it merged into Ruby Central, whose dependence on one big sponsor then produced the 2025 takeover of the RubyGems repositories, a bunch of resignations, and a depleted team facing the worst attack on a registry in years the following spring. That was funding for the registry’s own operations, not for the packages in it, and it was voluntary, and it had one big donor, which is three separate ways to fail.
So the pattern is: everything voluntary died of free riding, and the one thing that wasn’t voluntary (Docker) worked and kept the money for itself. Nobody who owns the domain has ever charged companies for supply and paid the people who make the supply worth having.
So here’s the proposal. There are three parts, none of them new; what’s new is putting them in the same place.
First, the registries meter corporate use and charge for it. They already meter it. npm, PyPI, Docker Hub and Maven Central all have rate limits, authentication and enterprise tiers, and the mirror vendors that sit in front of them bill by the seat. Docker’s rule is the right rule: individuals, small teams, students and open source projects pay nothing and notice nothing. A company above some size gets a subscription, priced the way a JFrog or Docker subscription is priced today, which is to say at a level procurement signs without scheduling a meeting. For most of these companies it isn’t even a new cost, because they’re already paying it; the invoice just gets a new line.
Second, a fixed slice of that revenue is a royalty, and it goes to the packages. Not to the registry, not to a foundation, not to a grants committee with an application form. Pro rata, to every package that shows up in the paying customer’s dependency trees, weighted by how many paying customers depend on it, automatically, every month, with no ceremony and no thank-you email, because the whole point is that nobody has to do anything for the money to move. My 2022 notes have a line about this that I’ll leave unedited: “The money has to go in one end and out the other. You don’t have to use crypto to do this, that would be bad, just use a database.” The payout half is not hard. thanks.dev does pro rata distribution over dependency trees today, and Flossbank did it in 2020. Nobody’s ever connected it to the collection half.
Third, the people who do this are the people who own the domains. There are about a dozen registries that matter. Every maintainer already has an account on the one they care about, with a name attached and a way to get paid either present or one form field away. The billing side is finite: a few thousand large companies, most of whom are already customers of somebody in the supply chain. The two hardest problems in every previous attempt, finding the payers and finding the payees, are already solved, and they’re solved by the same database.
Isaac Schlueter, who created npm, has argued that we should stop charging for support and start charging for access: if you’re a for-profit company, you don’t get the code without paying. I agree with the shape of that, but I’d move the toll booth, because if you put it in the license you get forked, and if you put it at the registry you get JFrog’s revenue. GitHub owns both npm and GitHub Sponsors, has every piece of this in one building, and could turn it on for npm’s enterprise customers this quarter. JFrog and Sonatype already bill companies for supply and could add the line item tomorrow. I ran npm for five years and I promise you the plumbing is not the hard part.
Some will, and it won’t matter, for the same reason it didn’t matter for Docker. Companies who can be bothered to run their own mirror can already do that, today, for free, and instead they pay JFrog, because what they’re paying for is not having to. The customers who leave are the ones who were never going to pay for anything, and they were already free-riding via someone else’s mirror. Docker lost some pulls to mirrors and multiplied its revenue by fifteen.
No, and the difference is the important bit. Tidelift was a separate purchase decision: a new vendor with a new pitch that had to win its own line in the budget. A royalty on the mirror bill isn’t a decision at all. Nobody in procurement will ever see it as one. Tidelift proved companies would pay for exactly this; it just proved it at a layer where they had to be asked.
Yes. This is the Spotify model and it inherits Spotify’s problem: if you pay per stream, people build streaming farms, and if you pay per dependency, people will publish a thousand junk packages that depend on each other and try to get them into somebody’s lockfile. You weight by presence in paying customers’ dependency trees rather than raw downloads, which makes it a lot harder, and then you accept that some fraud is the cost of not having a grants committee. Every payment system in the world has a fraud rate. The current fraud rate of paying maintainers is 100%, because we don’t do it.
The reason I think this can work is that it doesn’t ask the equilibrium to change. Every strategy stays exactly where it is; what changes is what gets measured.
The license doesn’t change, so nothing gets forked and nobody has to argue about what “open source” means. The code game is still won by free, which is the right outcome, and the singers keep singing.
It’s not charity and it’s not a mandate. Nobody’s asked to give, and nobody’s ordered to pay by a law that the most reckless companies were going to ignore anyway. Companies are already paying for supply; the invoice they already pay acquires a line.