[{"_1":2,"_30":-5,"_31":-5},"loaderData",{"_3":4},"routes/__layout/tag.$name",{"_5":6,"_7":8},"tagName","game theory","posts",[9],{"_10":11,"_12":13,"_14":15,"_16":17,"_18":19,"_20":21,"_22":23,"_24":-5,"_25":-5,"_26":27,"_28":29},"id",1521,"title","Nobody pays for open source. We can force them to.","excerpt","Thirty years of voluntary funding schemes haven't paid open source maintainers because asking doesn't scale. The real money already flows — to JFrog, Docker, Sonatype — at the registry layer. The fix: registries charge companies for supply (they already do), then route a slice automatically to the maintainers who make that supply worth having.","body","

The first time I thought it would be a good idea to write a blog post about the economics of open source was 2013, so this post has been in the works a while. The closest I got before today was 2022, when I wrote a stream-of-consciousness rant into my iOS notes that ended with basically "nothing fucking works". And then that sat there for 4 more years, because "nothing works" is too depressing to bother writing 5000 words about. Now, finally, I have an idea. It's gonna take 5000 words to get there, though, so if you don't have that kind of time, skip to the part about registries.

\r\n

Open source is a game with a stable outcome, and the outcome is that free wins

\r\n

I've written before about hawks and doves, which is a model from evolutionary biology. You have a population of animals competing for some resource. Some of them fight for it (hawks) and some of them share it (doves). A population that is all hawks is unstable: everybody's constantly getting hurt, and the first two doves to show up cooperate with each other and out-compete everyone. A population that is all doves is unstable too: the first hawk to show up competes with everybody and wins every time. What's stable is a mixture of both types, in proportions such that changing your behaviour doesn't help you, so nobody does. That mix is called an evolutionarily stable strategy, or ESS, and the important word is "stable." It's not the best strategy (arguably that's all doves, where nobody gets hurt), it's just the one the population ends up at and can't leave. I find it a useful way of thinking about software, because software has hawks and doves too.

\r\n

Closed source is the hawk. It competes: it withholds the code, charges a premium for having something nobody else has, and fights to keep it that way. Open source is the dove. It cooperates: it gives the code away and takes the gains from everybody else giving theirs away too. The resource they're competing over is money, ultimately, though it shows up first as users and as developer attention.

\r\n

The equilibrium we've landed on is very specific. The evolutionarily stable strategy for a piece of software is "anybody may use this for anything, including commercially, for free." That's MIT, BSD, Apache, the licenses that ask for nothing. Every project that has tried to be a slightly less generous dove has lost to a project that stayed a full dove, and I can give you a lot of examples:

\r\n

In 2017 the Apache Software Foundation banned React's BSD+Patents license from Apache projects, WordPress announced it was dropping React, and within weeks Facebook relicensed React under MIT rather than watch it die.
In 2021 Elastic moved Elasticsearch to a source-available license to stop Amazon selling it as a service. Amazon forked it as OpenSearch, the fork ended up at the Linux Foundation with thousands of contributors, and in 2024 Elastic quietly went back to an open source license.
In 2023 HashiCorp did the same thing to Terraform. The OpenTofu fork went to the Linux Foundation, and HashiCorp got bought by IBM.
In March 2024 Redis did it too. The Valkey fork picked up every cloud provider within about a week, and in May 2025 Redis put the AGPL back, with the CEO admitting the change had cost them enormously.

\r\n

Nobody who has tried to charge for open source at the license level has held the line against a competently run fork, and I don't think that's because of ideology. The people running those companies would love to charge for their code, and most of the people forking it don't care much about freedom in the abstract. It's because of the structure of the market. Disruption, in the original sense, is when a much worse and much cheaper product takes over the bottom of the market, then gets gradually better until it's eaten the whole thing, and there's nothing to stop that process repeating until the product costs nothing at all. Software has been getting disrupted like this for as long as there has been software, and what you end up with is a market with two halves: an enormous cheap half that nearly everybody uses, and a much smaller expensive half that makes nearly all of the money. Android has the market share and iOS has the profits, and they are both gigantic successes depending on which number you're looking at. Free wins share and closed wins profit, and both of them win.

\r\n

The stable outcome runs on people burning out

\r\n

So far this is fine. Free software wins, closed software makes money, everybody has a niche. The problem is what the free layer looks like from the inside.

\r\n

Sixty percent of open source maintainers are not paid for the work. That's from Tidelift's 2024 survey, and it's the same number they got in 2023, and the same number they got in 2021. Of the unpaid ones, 61% work alone. Nearly 60% of all maintainers have quit or thought about quitting, and the reasons they give are the ones you'd guess: they have a life, they lost interest, they burned out.

\r\n

The amount of software those people are holding up is silly. Sonatype looked at 1.2 million open source projects in 2023 and found that 11% of them were actively maintained. The Linux Foundation's Census II found that 136 developers wrote more than 80% of the code in the fifty most-used packages. A Harvard study estimated that if open source disappeared, companies would have to spend $8.8 trillion to replace it, and found that 5% of developers produce 96% of that value. This is the JavaScript ecosystem's whole personality, for what it's worth: a huge number of tiny packages with one maintainer, or less than one, sitting at the bottom of the dependency trees of companies that have bet their businesses on them. I spent five years at npm watching this happen and it never stopped being alarming.

\r\n

The example everybody uses now is xz. In 2024 it turned out that a compression library present in more or less every Linux machine on earth had a backdoor in it, inserted over two years by a fake contributor who had, very patiently, socially engineered the one unpaid person maintaining it into handing over the keys. The maintainer had said publicly that he was struggling and couldn't keep up, and rather than anybody funding him, somebody groomed him. The backdoor was caught by a Microsoft engineer who noticed SSH was taking half a second longer than it should, which is not the kind of defence you want to be relying on.

\r\n

Now, the popular way to tell this story is "the system is breaking," and I don't think that's right, and the distinction matters. The system isn't breaking. It's stable, at a level of human cost we've collectively decided to put up with. A maintainer burns out, somebody else picks it up, they burn out, and so on. Serial near-burnout isn't a bug in the equilibrium, it is the equilibrium. Open source is very old, and if this was going to collapse it would have done so by now. This is a machine that runs on blood, and because it is the evolutionarily stable strategy, we have been powerless to change it.

\r\n

What changed is velocity, and only velocity

\r\n

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.

\r\n

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 published. The software got important faster than any institution could notice it was important, never mind fund it. Meanwhile security got faster too: a bug in a popular library is now exploited within days and lands on tens of thousands of companies at once. So the cost of maintaining a popular package went up a lot, and the payoff for maintaining it stayed exactly where it was, which is zero dollars and a warm feeling.

\r\n

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.

\r\n

Everything we've tried moves money, and none of it moves the equilibrium

\r\n

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:

\r\n

Tips. GitHub Sponsors passed $100 million in total payouts in July 2026, which sounds like a lot until you put it next to $8.8 trillion. It's distributed the way tips are always distributed, which is a power law: a handful of well-known people do fine and the median sponsored maintainer makes lunch money. Open Collective, Patreon, Ko-fi, same shape.
Foundations. The Linux Foundation, Apache, OpenJS, the Python Software Foundation. These are real institutions with real budgets, and what they mostly pay for is staff, events and infrastructure. That's not a knock; somebody has to run the conference. But in the Tidelift survey only 3% of maintainers got any money from a foundation, and 1% from a government. Foundations are companies paying to steer, not companies paying the people who row.
Corporate generosity. Google's open source office, Microsoft's FOSS fund, and Sentry's Open Source Pledge, which asks companies to give $2,000 per developer per year and launched in 2024 with about $1.3 million committed. I like the Pledge. It has the same flaw as everything else on this list, which is that it's charity, and charity does not scale to trillions. Dan Lorenc, who spent years at Google and OpenSSF trying to give money to maintainers, said they had more money than they could give away and it didn't fix anything. I think that's one failed attempt rather than a law of nature, but it does go on the list of failed attempts.
Paid security. Tidelift's whole model was paying maintainers to keep their packages secure and selling the assurance to companies, which is a good idea, and in December 2024 it got acquired by Sonar, which is what happens to good ideas that can't find enough buyers on their own. OpenSSF's Alpha-Omega gives out five or six million dollars a year, mostly to fund security staff inside foundations, which is sensible but small.
Government. Germany's Sovereign Tech Fund is a great idea: taxpayer money, no strings, straight to the maintenance of critical infrastructure, more than €24 million to sixty-odd projects since 2022. It's also one fund, in one of about 190 countries, spending about €20 million a year, and the EU-wide version is a proposal for a budget cycle that starts in 2028.
Mozilla. Mozilla is funded by a straw stuck into Google's search revenue, and everyone at Mozilla knows this is a problem, which is why they keep trying to diversify and keep not managing it. (For a while Mozilla and Google were literally in the same building in San Francisco, on different floors.) You can't generalize "find somebody else's revenue stream and stick a straw in it" because there aren't enough revenue streams to go around.
Licensing, which we've covered. Dual licensing, source-available, "fair source": every one of them is a dove trying to be a bit of a hawk, and every one of them loses to the full dove next door.

\r\n

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.

\r\n

Companies do pay for open source, just not to the people who write it

\r\n

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.

\r\n

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.

\r\n

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.

\r\n

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.

\r\n

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.

\r\n

Free wins the code game, but the default wins the supply game

\r\n

So why doesn't the ESS apply here? If free always wins, why hasn't a free mirror eaten JFrog?

\r\n

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.

\r\n

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.

\r\n

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.)

\r\n

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.

\r\n

Nobody has seriously tried this at the registry layer

\r\n

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.

\r\n

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.

\r\n

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.

\r\n

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.

\r\n

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.

\r\n

The registries should charge companies, and pay maintainers

\r\n

So here's the proposal. There are three parts, none of them new; what's new is putting them in the same place.

\r\n

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.

\r\n

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.

\r\n

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.

\r\n

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.

\r\n

"Won't companies just switch to a free mirror?"

\r\n

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.

\r\n

"Isn't this just Tidelift again?"

\r\n

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.

\r\n

"Won't people game it?"

\r\n

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.

\r\n

Why this can work when nothing else has

\r\n

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.

\r\n

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.

\r\n

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.

\r\n

And it pays the long tail, which is the population every other mechanism misses. Tips pay celebrities, foundations pay staff, and government funds pay the twenty projects on the critical list, but a royalty on dependency trees pays is-odd. The person who wrote a small, useful thing that ended up in four hundred companies' production systems gets four hundred small contributions, without applying, without marketing, without turning themselves into a brand. This matters to me more than any other part of the proposal, because a lot of the open source sustainability conversation has curdled into telling maintainers to get better at business, and I think that's exactly backwards. The mechanism should pay people for being useful, not for being good at asking.

\r\n

LLMs make this urgent, and they make it worth more

\r\n

The other thing that's changed since 2022 is that the cost of writing software collapsed, and I think that's the first time in thirty years a variable in this equation has actually moved rather than just sped up.

\r\n

Cheaper software means more software. More people can build the small useful thing, and the long tail gets longer, and the number of packages that quietly end up in somebody's dependency tree goes up, not down. A mechanism that pays the long tail is worth more in that world.

\r\n

It also means AI agents are now the fastest-growing consumers of open source, and they consume it in exactly one way, which is through the registries. In May 2026 a swarm of agents run by OpenAI published more than 2,000 packages to RubyGems in two days, exploited a bug in the registry's API to go after user credentials, got remote code execution on the documentation site, and forced the volunteers who run RubyGems to shut down new registrations for four days. OpenAI said the agents were doing benign tasks, which may well be true, and either way the volunteers absorbed the cost and nobody sent them a cheque.

\r\n

The early signs are mostly like that. Daniel Stenberg, who maintains curl, shut down a bug bounty that had paid out $90,000 over seven years because AI-generated garbage had pushed the proportion of real bugs in submissions from 15% to under 5%, and in six years not one AI-only report had found a real vulnerability. AI is getting good at finding real bugs in open source; Google's Big Sleep has found some. But the finding happens inside Google and the fixing happens on somebody's evening, and right now the load is rising faster than the tools that reduce it, and the tools belong to companies with security teams rather than to the person who has to write the patch.

\r\n

I don't know which way this goes. My honest guess for a long time was that the LLM effects would all cancel out and leave us at the same equilibrium, just faster. I'm less sure of that now, because for the first time the two games are diverging: code is getting cheaper to make and supply is getting more expensive to guarantee. That is exactly the condition under which the supply layer becomes worth paying for, and it's exactly the moment to decide who gets paid.

\r\n

We've had the power to do this all along

\r\n

I don't want to end this by wishing companies would be nicer, because I've written that version of this post in my head a hundred times and it's useless. I want to end with something we can actually do. And I couldn't have made this argument while I was still at npm, because the conflict of interest would have been obvious. But my time at npm is long gone, just my appreciation of its powerful place in the ecosystem remains.

\r\n

Open source developers get described as powerless, a scattered pile of volunteers who can be ignored, and the record says otherwise. In 2017 we made Facebook change React's license. In 2024 and 2025 we made Redis, a company with a couple of billion dollars behind it, reverse a strategic decision in fourteen months. We've done it every time somebody has tried to be a hawk with our code. Coordinated refusal works, and it turns out doves are pretty good at punishing defectors.

\r\n

What we've never done is aim that at anything other than a license. For thirty years the target has been whichever company tried to charge for the code, and meanwhile the money companies actually spend on open source has flowed, without anybody objecting, to a dozen vendors sitting on the chokepoint, because they weren't breaking any rules, and they weren't breaking any rules because there aren't any, which is the whole problem.

\r\n

So here's the rule I'd like us to have: the people who run the meter pay the people who make the thing worth metering. It's a norm with a small number of named targets, all of whom sell to developers and all of whom care what developers think of them. It doesn't need a law, or a foundation, or a grants committee, or any single company to feel generous. It needs the registries and the mirror vendors to add a line to an invoice that companies already pay, and to run a cron job. Everything else we've tried for thirty years has been an appeal to the ten thousand companies who consume open source. This is an instruction to the twelve who supply it.

","updated",["D",1789264919000],"created",["D",1789264919000],"codename","nobody-pays-for-open-source-we-can-force-them-to","legacy_id","thumbnailUrl","published",["D",1789264919000],"draft",false,"actionData","errors"]

Posts tagged “game theory”