Why Open Source's Big Funding Fix Won't Pay Maintainers

The headline out of the Linux Foundation this month sounds like good news for open source: more than a dozen major tech companies just pledged new money to keep software registries alive. The catch in this open source maintainer funding push is that the money is earmarked for servers and security scanners, not for the people who actually write the code those registries hand out for free.

Key takeaways

More than a dozen companies, including GitHub, Google, IBM and Microsoft, signed a September 2026 OpenSSF statement calling the current registry funding model "no longer sustainable."
Security researchers logged over 1.8 million malicious packages across registries in 2026, already topping the full-year total for 2025, according to the statement.
The proposed fix is enterprise subscription tiers for registries like npm and PyPI, not automatic payments to the maintainers whose packages those registries distribute.
A separate, unofficial proposal from former npm co-founder Laurie Voss would route a cut of that enterprise revenue directly to maintainers, pro rata, every month, with no application required.

The Numbers Behind the Open Source Maintainer Funding Crisis

The statement, coordinated by OpenSSF's Sustaining Package Registries Working Group and published in mid-September 2026, was signed by Arm, Datadog, Dell Technologies, Ericsson, GitHub, Google, IBM, Kusari, Microsoft, Red Hat, the Rust Foundation and Sonatype, according to reporting from SD Times and IT Pro. Both outlets cite the same core figures, which is worth noting given how often single-source statistics get repeated uncritically online.

Download volumes across major registries, npm, PyPI, Maven Central, crates.io, RubyGems and NuGet, are growing 30 to 50 percent year over year. Security teams found more than 1.8 million malicious packages in 2026 alone, already surpassing the total for all of 2025. And the signatories expect a three-to-fivefold surge in package publish events, driven largely by AI tools that discover (and sometimes fabricate) vulnerabilities faster than small teams can review them. Many of the registries carrying this load run on staffs of two or three people, funded mostly by donated infrastructure credits.

Metric	Figure	Source
Malicious packages found in 2026	Over 1.8 million	OpenSSF statement, via SD Times and IT Pro
Registry download growth	30-50% year over year	SD Times and IT Pro
Expected publish-event surge	3x to 5x	SD Times and IT Pro
Typical registry team size	2 to 3 people	SD Times and IT Pro

Who Actually Signed and What They Agreed To

What the companies agreed to is narrower than the framing suggests. The statement pushes registries toward enterprise usage tiers, mirrored distribution frameworks and commercial service agreements aimed at large corporate consumers of open source, while individual developers, hobbyists and small organizations keep free access. That funds better infrastructure: caching, artifact signing, malware scanning and incident response with actual service-level agreements, the kind of operational maturity a two-person team cannot provide today.

What it does not do, according to both outlets' reporting on the statement, is create any mechanism that routes money to the maintainers whose packages generate that enterprise traffic in the first place. A company paying npm for a support contract is paying npm, not the person who wrote the logging library buried six layers deep in its dependency tree.

Will Any of This Money Reach Individual Maintainers?

Not directly, and not soon. The signed statement is about keeping registries themselves solvent and secure, which is a real and separate problem from maintainer compensation. Registries could eventually choose to redirect some of that new enterprise revenue toward the people who supply the packages, but nothing in the current agreement commits them to it, and no registry has announced a timeline for doing so.

The Alternative No Big Company Has Signed Onto

That gap is exactly what Laurie Voss, a developer and writer who co-founded npm, argues should happen instead. In a personal blog post published this month, Voss proposes that registries take the enterprise subscription fees they are already moving toward and carve out a fixed royalty percentage, then distribute it automatically and monthly to every package that shows up in a paying customer's dependency tree, weighted by how many paying customers depend on it. No maintainer applies, no maintainer even has to know it is happening; the payment just arrives.

✦ Free Newsletter ✦

Never miss a story

Tools, tutorials and AI deep-dives - straight to your inbox, every week.

Rows of illuminated server racks in a data center

It's a compelling idea specifically because it needs no cooperation from the ten thousand companies that consume open source, only from the handful of registries that sit in the middle of every transaction. But Voss is candid that this is her own proposal, not an official plan, and that similar schemes, Flossbank and Ruby Together among them, failed to gain lasting traction. Automated pro-rata payouts sound simple until you ask who counts as "the maintainer" of a package with forty contributors, or how a monthly check gets taxed across a hundred countries.

Money Alone Would Not Have Saved curl's Bug Bounty

The funding conversation also skips a second, arguably worse problem: volume of low-quality labor demands, not just lack of money. The curl project, one of the most widely used pieces of software on the internet, shut down its HackerOne bug bounty program in early 2026 after AI-generated reports overwhelmed its security team. Maintainer Daniel Stenberg wrote on his own blog that curl's confirmed-vulnerability rate, historically above 15 percent of submissions, had fallen below 5 percent, and stopped accepting new paid HackerOne submissions as of February 1, 2026.

Stack of coins resting beside a computer keyboard

curl is a well-funded, high-profile project with corporate backing, and money did not fix its problem. What burned it out was triage load: sorting real vulnerabilities from confident-sounding AI slop takes the same senior judgment whether the report is good or garbage. A royalty check would not have reduced that queue by a single ticket. This is worth reading alongside the broader pattern of AI narrowing the gap between finding and exploiting bugs, which is accelerating both legitimate security research and the noise around it.

The Honest Counterpoint: Enterprise Tiers May Be the Realistic First Step

The steelman case for the industry's approach is straightforward: a registry that goes down, or gets flooded with malware because it cannot afford scanning, hurts every single downstream project at once. Fixing that shared infrastructure is a more tractable, fundable problem today than solving the much harder question of fairly compensating millions of individual maintainers, some of whom maintain packages nobody has thought about updating in a decade. Enterprise tiers are also something companies already understand how to buy, which makes them far more likely to actually launch than a novel automated royalty system with no precedent of working at scale.

Digital padlock icon overlaid on a screen of code

That argument has real weight, and it is probably why the big signatories chose it. The honest response is that "more tractable" is not the same as "solves the stated problem." The OpenSSF statement itself frames the crisis in terms of maintainer strain, two- and three-person teams unable to keep up, yet the remedy it commits to spends money entirely on infrastructure the registries operate, not on the people writing the software those registries carry. Both things can be true: registries need the infrastructure money urgently, and that money still will not touch the maintainer sustainability problem the statement opens with.

Who Should Pay Attention, and What to Watch

This matters most to engineering leaders who manage open source dependency risk, security teams evaluating supply-chain exposure, and maintainers themselves deciding whether to keep volunteering their time. It matters less to end users of consumer apps who never interact with a package registry directly, though they benefit from the software staying secure. If you fall into the first group, a short checklist helps separate signal from noise as this plays out over the next year:

Check whether your organization already sponsors its top ten most-used open source dependencies directly, through Tidelift, GitHub Sponsors or Open Collective, rather than assuming registry fees will cover it.
Watch whether any registry actually launches a paid enterprise tier with public terms, since the OpenSSF statement commits to intent, not a shipped product or pricing.
Track whether any registry adopts a maintainer payout mechanism like the one Voss describes; if none does within a year, treat the "funding crisis" framing as still unresolved for maintainers specifically.
If you maintain a widely used package, budget for AI-generated report triage as an ongoing cost, not a temporary spike, regardless of how the registry funding debate resolves.