What If Open Source Worked Like Music Royalties?
A whitepaper on addressing the Tragedy of the Commons in open source software
Abstract. Open source software underpins virtually all modern digital infrastructure, yet the maintainers who build and sustain it are overwhelmingly uncompensated — a textbook tragedy of the commons playing out in code. The consequences are predictable and recurring: burnout, project abandonment, and critical security vulnerabilities in foundational code. Existing funding mechanisms — voluntary donations, per-project fees, commercial intermediaries, and blockchain-based licensing — each address fragments of the problem but fail to provide systemic, scalable infrastructure. This paper proposes a fundamentally different approach: an Open Source Collecting Society modeled on the performing rights organizations (ASCAP, BMI, PRS) that have sustained music creators since 1914. Under this model, maintainers voluntarily register their projects; companies pay a micro usage fee scaled to actual production consumption; and royalties are distributed proportionally based on measured deployment data, tracked through existing dependency graphs and Software Bills of Materials (SBOMs). The usage fee is immaterial for any individual company — even at very large scale — but becomes meaningful to maintainers through economies of scale, the same mechanism that sustains songwriters through millions of individual plays. This paper examines the structural parallels between the early 20th-century music industry and today’s open source ecosystem, evaluates existing sustainability efforts, addresses the ethical tension with free software philosophy, and outlines the technical, legal, and governance requirements for implementation.
In November 2025, the Kubernetes community announced it was retiring Ingress NGINX — the ingress controller running in 41% of internet-facing Kubernetes clusters [1]. The reason wasn’t technical. It wasn’t outdated. It wasn’t replaced by something better.
It was maintained by two people. Working nights and weekends. For free.
When users protested, Kubernetes maintainer Tim Hockin responded: “I am going to ask you once to please drop the entitlement. The people who currently work on ingress-nginx do so FOR FREE. In the two years this has been a topic, almost nobody has stepped up to help.” [3]
This isn’t an isolated incident. It’s a pattern.
The pattern we keep ignoring
In 2014, the Heartbleed vulnerability in OpenSSL exposed a terrifying reality: the encryption layer protecting most of the internet’s traffic was maintained by a single full-time developer, funded at roughly $2,000 per year in donations. Companies worth hundreds of billions relied on his work. Nobody paid.
In 2021, the Log4Shell vulnerability in Log4j — a Java logging library embedded in virtually every enterprise Java application on earth — revealed the same story. Volunteer maintainers. Zero funding. Critical infrastructure.
There’s an xkcd comic that captures this perfectly: all of modern digital infrastructure, a towering stack of dependencies, balanced on a tiny block labeled “a project some random person in Nebraska has been mass-maintaining since 2003.”
It’s funny. It’s also a structural failure of the software industry.
The tragedy of the commons, in code
The economics here aren’t complicated. They’re a textbook tragedy of the commons.
Open source software is a shared resource. Anyone can use it. Nobody is required to maintain it. Every company that depends on a project assumes someone else is funding the maintainers. So nobody does.
The incentives are perfectly misaligned. Cloud providers would rather sell you their proprietary alternatives. Companies like F5 are happy to let community projects die because they have commercial versions to sell [14]. And the enterprises building billion-dollar platforms on top of free software? They allocated exactly $0 in their budget for the dependencies holding everything together.
The maintainers, meanwhile, burn out. They feel a sense of duty — people depend on their work — but duty doesn’t pay rent. One by one, they step away. And then we get Heartbleed. We get Log4Shell. We get critical infrastructure quietly rotting from the inside.
What’s been tried so far
The OSS sustainability crisis isn’t news, and several approaches have emerged to address it. Each solves part of the problem, but none provides the systemic infrastructure the ecosystem needs.
Voluntary pledges and donations. GitHub Sponsors, Open Collective, and Patreon let individuals and companies tip maintainers. The Open Source Pledge, launched in late 2024, gathered 20 companies pledging a collective $1.3 million [11]. These are welcome, but they’re charity — unpredictable, unscalable, and dependent on goodwill. Donations are like bonuses: nice to receive, impossible to plan around.
Per-project maintenance fees. In early 2025, Rob Mensching introduced the Open Source Maintenance Fee for the WiX Toolset — a small monthly fee ($10-60 based on company size) required for binary downloads and issue access, while keeping the source code fully open [5]. Within two months, 64 sponsors had signed up, including Microsoft [6]. It’s a promising model, but it requires each maintainer to individually enforce their own fee structure. It doesn’t scale across thousands of projects.
Commercial intermediaries. Tidelift acts as a paid bridge between companies and maintainers, compensating developers for “boring but important” maintenance tasks. Their top maintainers earn six-figure incomes [9]. But Tidelift is a for-profit company taking a commercial cut, not a collective representing the ecosystem.
Blockchain-based licensing. The Open Compensation Token License (OCTL) uses NFTs and smart contracts to track code ownership and distribute royalties for commercial use [13]. It’s technically interesting but introduces enormous complexity — gas fees, tax implications, wallet management — for a problem that doesn’t require blockchain to solve.
Employment pledges. At FOSDEM 2026, just days ago, an Igalia engineer proposed that for every 20 developers a company employs, it should dedicate half of one person’s time to open source development [10]. A thoughtful idea, but it addresses labor contribution, not financial sustainability for independent maintainers.
Each of these approaches tackles a symptom. What’s missing is the structural plumbing — a centralized, non-profit collecting society with automated usage tracking and proportional distribution. The music industry solved this exact problem over a century ago.
How the music industry solved this exact problem
This isn’t a new problem. It’s not even unique to software.
In the early 20th century, musicians faced the same crisis. Radio stations played their music. Restaurants and venues used it to attract customers. Nobody paid the composers. The music was just... there, and everyone assumed it was free to use.
The solution was collecting societies: ASCAP (founded 1914), BMI (1939), and their equivalents around the world [15]. These organizations don’t require every bar owner to negotiate directly with every songwriter. Instead, they operate on a simple model:
Creators register their works voluntarily
Venues pay a small usage fee — a predictable, scaled amount
The society distributes royalties based on usage tracking
The fee is negligible for any individual business, but meaningful in aggregate
A coffee shop pays a few hundred dollars a year. A major radio network pays more. The songwriter whose track gets played 100,000 times receives a real income. The system isn’t perfect, but it works well enough that musicians can actually sustain themselves.
Software needs the same thing.
The model: micro-royalties for open source
Here’s the proposal. An Open Source Collecting Society — call it OSCS, or whatever name sticks — operating on the same principles:
For maintainers:
Register your project voluntarily. Not every open source project needs to participate — this is opt-in, not a mandate
Continue licensing however you want. MIT, Apache, GPL — the royalty layer sits alongside your existing license, not on top of it
Receive micro-royalties proportional to usage in production environments
For companies:
Pay a micro usage fee based on your scale — headcount, revenue, or deployment count
The fee is immaterial at any scale. We’re talking fractions of a cent per dependency per production deployment per month
In return, you get a clean, auditable record of compliance — increasingly important as software supply chain regulations tighten
For the ecosystem:
The collecting society handles tracking, collection, and distribution
Usage data comes from existing infrastructure: SBOMs (Software Bills of Materials), dependency manifests (
package.json,go.mod,Cargo.toml, Docker image layers), and build-time telemetryDistribution follows a transparent formula weighted by usage
The math works
Let’s run the numbers on Ingress NGINX as a concrete example, using a usage fee of $0.001 per production deployment per month — one tenth of a cent.
Ingress NGINX ran in an estimated 41% of internet-facing Kubernetes clusters [1]. With over 50,000 companies using Kubernetes globally [17] and enterprises typically running 5-50+ clusters each, conservative estimates put total production deployments of Ingress NGINX in the hundreds of thousands. Here’s what the usage fee looks like across company tiers:
The cost is so immaterial it wouldn’t survive rounding errors in any company’s cloud bill. Amazon’s AWS infrastructure costs are estimated at over $10 billion annually. A $300/year usage fee for Ingress NGINX represents 0.000003% of that spend. A Fortune 500 bank paying $50,000/month on cloud hosting wouldn’t even notice $1.20/year.
Now flip the perspective to the maintainers:
Estimated total deployments Monthly revenue Annual revenue Full-time maintainers funded (at $150k/yr) 200,000 (conservative) $200 $2,400 0 — not viable at $0.001 200,000 at $0.01/deploy $2,000 $24,000 0 — barely covers part-time 200,000 at $0.10/deploy $20,000 $240,000 1-2 full-time maintainers 200,000 at $0.50/deploy $100,000 $1,200,000 5-8 full-time maintainers
The sweet spot appears to be somewhere between $0.10 and $0.50 per production deployment per month. Even at $0.50, the cost to an Amazon-scale company with 25,000 deployments would be $12,500/month — still utterly immaterial against their cloud spend, but now generating $1.2M annually for the project. That’s a fully staffed, sustainable open source team.
For context: at $0.50 per deployment, a Fortune 500 bank running 100 clusters pays $50/month — less than a single Datadog seat. A 5-person startup pays $0.50/month — less than a cup of coffee.
The ingress-nginx project died because two volunteers working for free couldn’t sustain infrastructure used by 41% of the internet’s Kubernetes clusters [1][3]. The math shows that a usage fee invisible to every company in the table would have fully funded the project with money to spare. This is the power of economies of scale working for maintainers instead of against them.
But Ingress NGINX was already massive when it collapsed. The harder question is: does the model work for a project on its way up?
The growth case: Fastify
Fastify is a Node.js web framework created by Matteo Collina in 2016 as a side project. It grew steadily from obscurity to powering production backends at companies including Microsoft, with 22 maintainers and over 5 million weekly npm downloads today [16]. Here’s an approximate growth timeline, using $0.25/production deployment/month — the midpoint of the sweet spot above:
(Note: production deployments are estimated conservatively at ~1% of weekly downloads, since the vast majority of npm downloads are CI/CD, development, and transitive installs — not unique production services.)
The numbers tell a compelling story even for a growing project. In the early years, the revenue is negligible — as it should be. Nobody’s paying meaningful fees for a project with 50 production users, and 50 production users aren’t generating meaningful fees. The system is self-calibrating: the fee only becomes material when the project becomes material.
But notice the inflection. By 2020, when Fastify was gaining serious production adoption, the model generates $15,000/year — enough to meaningfully compensate a maintainer’s time and signal that the project has economic value. By 2022, it’s $45,000 — a real salary in many parts of the world. By today, it’s enough to sustain a small team.
Compare this to what actually happened: Fastify’s lead maintainer, Matteo Collina, eventually co-founded a company (Platformatic) partly to create a sustainable business around the framework. That worked for Fastify — Collina is exceptionally entrepreneurial. But most maintainers aren’t founders, and they shouldn’t need to be. The collecting society model would have provided a growing revenue stream that tracked naturally with the project’s adoption, without requiring anyone to start a company or negotiate with sponsors.
This is the critical insight: the usage fee doesn’t need to fund a project from day one. It needs to start paying out right around the time the maintainer’s volunteer capacity runs out — which is exactly when production adoption accelerates. The economics of scale do the work automatically.
The ethical question: is this compatible with free software?
This is where it gets uncomfortable.
The free software movement, going back to Richard Stallman and the GNU project, is built on four freedoms: the freedom to run, study, modify, and distribute software. “Free as in freedom, not as in beer” — though in practice, it’s usually been both.
Adding a royalty layer feels, to many in the community, like a betrayal of those principles. If software should be free, charging for it — even fractions of a cent — violates the ethos.
But here’s the thing: the current model is also a betrayal. It just betrays different people.
When we say open source is “free,” we mean free for the user. For the maintainer, it’s unpaid labor. The four freedoms protect the rights of everyone except the person actually writing the code. Freedom to use someone’s work without compensating them isn’t liberty — it’s exploitation dressed up in idealist language.
A well-designed royalty model can preserve every one of Stallman’s four freedoms while adding a fifth: the freedom of the maintainer to sustain their work.
The key is that participation is voluntary on both sides:
Maintainers choose whether to register with the collecting society. Plenty of developers will continue releasing completely free software because that’s what they want. The option to earn royalties doesn’t remove the option not to
The source code remains open. Registration doesn’t change the license. You can still fork it, study it, modify it, distribute it. The royalty applies to production commercial use, not to the code itself
Individual developers and non-commercial users pay nothing. The model targets companies using OSS in production for profit — the entities that can afford pennies and currently pay zero
This isn’t “making open source proprietary.” It’s making open source sustainable. There’s a crucial difference.
The infrastructure already exists
This isn’t a technically impossible dream. The pieces are already falling into place, driven by security concerns rather than sustainability ones:
SBOMs are becoming mandatory. The US Executive Order on Cybersecurity (2021) requires software vendors selling to the federal government to provide Software Bills of Materials. The EU Cyber Resilience Act extends similar requirements. Companies are already cataloguing every dependency in their stack for compliance. That same catalogue is a royalty ledger.
Dependency graphs are solved. Every package manager already knows the complete tree. npm ls, pip freeze, go mod graph — the data is there. Container registries track image layers. Kubernetes knows what’s running in every pod.
Build-time and deploy-time telemetry is standard. CI/CD pipelines already report what they’re building and deploying. Adding a royalty-reporting step is no different from adding a security scan — and most companies already do those.
The technical challenge isn’t tracking usage. It’s building the governance, legal framework, and trust infrastructure around a collecting society. That’s hard. But it’s a solved problem in other industries.
Counter-arguments
“This will kill open source adoption.” A micro usage fee of $50-100/month for an enterprise won’t even register against their cloud bill. Companies already pay more than that for a single SaaS monitoring tool. The resistance isn’t economic — it’s cultural. And culture shifts when infrastructure keeps collapsing.
“Companies will just fork and avoid registered projects.” They can already do that. They don’t, because maintaining a fork is expensive. The whole point of using open source is that someone else maintains it. If you fork to avoid micro-royalties, congratulations — you’ve just hired yourself as the maintainer.
“Who decides how royalties are distributed?” The collecting society, using transparent formulas based on measured usage. This is exactly how ASCAP and BMI work [15]. It’s not perfect, but it’s better than zero.
“This adds friction to the developer experience.” Only for production commercial deployments. Development, testing, personal projects, education, non-profits — all exempt. npm install stays free. Deploying to production at a company making revenue is where the meter starts.
“Some open source licenses explicitly prohibit this.” That’s why participation is voluntary and the royalty layer sits alongside the existing license. Maintainers who want their software used without any commercial obligation continue as before. This is an additional option, not a replacement.
What needs to happen
Someone builds the collecting society. A non-profit entity with transparent governance, modeled on existing collecting societies but adapted for software. This is the hardest part — it requires legal infrastructure, trust, and neutrality.
Package registries add opt-in royalty metadata. A field in
package.jsonorCargo.tomlthat says “this package participates in OSCS.” Nothing changes for packages that don’t opt in.Enterprise compliance tools integrate royalty reporting. Companies already run dependency audits for security and license compliance. Adding royalty calculation to existing tools is incremental, not revolutionary.
Regulatory tailwinds help. As SBOM requirements expand, the infrastructure for tracking dependencies in production becomes universal. The jump from “we track our dependencies for security” to “we also compensate the maintainers” is a small one.
Early adopters set the norm. If a few major companies voluntarily participate — the way some already sponsor individual projects — it creates social pressure. Nobody wants to be the company that refuses to pay $100/month for infrastructure they depend on while their competitors are doing the right thing.
The alternative is what we have now
Two volunteers maintaining infrastructure for 41% of the internet’s Kubernetes clusters [1]. A single developer securing most of the world’s encrypted traffic. Catastrophic vulnerabilities discovered in code that nobody funded anyone to audit.
Every few years, something breaks spectacularly, and the industry briefly panics. Money flows to the affected project for a few months. Then attention fades, and we go back to the same extractive model.
We can keep doing this. Or we can build the plumbing for a sustainable open source economy.
The music industry figured this out a century ago. It’s time software caught up.
Ylli Prifti, Ph.D., writes about software sustainability, open source, and engineering culture at ylli.prifti.us.
If you’re interested in exploring this idea further — whether as a developer, a policy maker, or someone who wants to help build the collecting society — connect on LinkedIn or reach out.
References
[1] Kubernetes SIG Network. “Ingress NGINX Retirement: What You Need to Know.” Kubernetes Blog, November 11, 2025. https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/
[2] Kubernetes Steering Committee. “Ingress NGINX: Statement from the Kubernetes Steering.” Kubernetes Blog, January 29, 2026. https://kubernetes.io/blog/2026/01/29/ingress-nginx-statement/
[3] Vaughan-Nichols, Steven J. “Users scramble as critical open source project left to die.” The Register, December 2, 2025. https://www.theregister.com/2025/12/02/ingress_nginx_opinion/
[4] Stoychev, Hristo. “Ingress-NGINX Controller End-of-Life: 2026. Alternatives and Architecture.” Medium, February 2026. https://medium.com/@h.stoychev87/nginx-ingress-end-of-life-2026-f30e53e14a2e
[5] Mensching, Rob. “Introducing the Open Source Maintenance Fee.” RobMensching.com, February 26, 2025. https://robmensching.com/blog/posts/2025/02/26/introducing-the-open-source-maintenance-fee/
[6] Mensching, Rob. “Open Source Maintenance Fee Two Months In.” RobMensching.com, May 12, 2025. https://robmensching.com/blog/posts/2025/05/12/open-source-maintenance-fee-two-months-in/
[7] Open Source Maintenance Fee. https://opensourcemaintenancefee.org/
[8] Orosz, Gergely. “Creative ways to fund open source projects.” The Pragmatic Engineer, August 2025. https://blog.pragmaticengineer.com/creative-ways-to-fund-open-source-projects/
[9] “Open Source Needs Maintainers. But How Can They Get Paid?” The New Stack, November 2024. https://thenewstack.io/open-source-needs-maintainers-but-how-can-they-get-paid/
[10] Gain, B. Cameron. “Is open source in trouble?” The New Stack, February 9, 2026. https://thenewstack.io/is-open-source-in-trouble/
[11] “How open-source software devs got corporations to pledge $1.3M for their tools.” Technical.ly, October 2024. https://technical.ly/software-development/open-source-pledge-developer-pay/
[12] “Open Source at a Crossroads: The Future of Licensing Driven by Monetization.” arXiv, 2025. https://arxiv.org/html/2503.02817v2
[13] “NFTs for Open-Source and Commercial Software Licensing and Royalties.” IEEE Xplore, 2023. https://ieeexplore.ieee.org/document/10024941/
[14] NGINX Community Blog. “The Ingress NGINX Alternative: Open Source NGINX Ingress Controller for the Long Term.” https://blog.nginx.org/blog/the-ingress-nginx-alternative-open-source-nginx-ingress-controller-for-the-long-term
[15] ASCAP. “Who ASCAP Collects From.” https://www.ascap.com/help/royalties-and-payment/payment/whocollect
[16] Fastify v5 Release Announcement. OpenJS Foundation, September 2024. https://openjsf.org/blog/fastifys-growth-and-success
[17] Kubernetes Statistics. Octopus Deploy, 2025. https://octopus.com/devops/ci-cd-kubernetes/kubernetes-statistics/