npm's Fix for Unpaid Open Source Is Finally Real. It Still Pays the Wrong Maintainer.

Every app I've shipped this year runs on packages I've never paid a cent for.

Next.js. Tailwind. A dozen small utilities buried three levels deep in node_modules that I couldn't name if you asked.

Somebody maintains those. Most of them do it unpaid, at night, between a day job and everything else.

The whole ecosystem has quietly agreed to pretend that's sustainable.

This week, 13 organizations, including GitHub, Google, IBM, and Microsoft, signed a joint OpenSSF statement admitting it isn't.

"Commercial-scale use without commercial-scale support is unsustainable," they wrote.

Laurie Voss, npm's former CTO, followed it with a specific fix: make the registries themselves force the money through.

I think he's right about the diagnosis. I think he's wrong about who ends up getting paid.

I've read a dozen of these proposals over the years. License changes. Sponsorship tiers. "Open core" pivots that quietly relicense the whole project a year later. Every single one either asked companies to volunteer or asked maintainers to beg. This is the first one that does neither.

That's exactly why the payout formula matters so much. If this is the plan that finally gets adopted, the split it launches with is the split the industry lives with for the next decade.

The Plan: Registries Skim, Maintainers Split

Voss's pitch, laid out on his blog under his old npm handle seldo, is simple compared to a decade of failed alternatives.

Companies already pay for registry-adjacent infrastructure — mirrors, caching, uptime guarantees from vendors like JFrog and Sonatype.

His proposal: package registries like npm, PyPI, Docker Hub, and Maven Central add an enterprise subscription tier priced by usage volume.

A fixed percentage of that revenue gets distributed automatically, pro-rata, down every paying customer's dependency tree.

No grant application. No Patreon page. No maintainer performing gratitude on Twitter to get noticed.

The money just shows up, monthly, without anyone applying for it.

It sidesteps the two things that killed every previous funding push. It doesn't ask companies to change their procurement habits, and it doesn't ask maintainers to do anything except keep publishing.

The urgency isn't abstract either. Registries staffed by two- or three-person teams reviewed 1.8 million malicious packages this year.

Supply chain attacks in the first half of 2026 ran at 2.6 times the total volume of all of 2025.

The people keeping the pipes clean are drowning. Everyone downstream is still acting like npm install is a free resource instead of infrastructure with a maintenance bill nobody's paying.

Where the Formula Breaks

Here's the part that doesn't survive contact with how dependency trees actually look.

Pro-rata by volume rewards whatever shows up most often in a paying customer's tree. That's React. That's Next.js. That's the frameworks with foundations, corporate sponsors, and full-time maintainers already.

Those projects are not the ones the OpenSSF statement was written to save.

The maintainer this is supposed to save is the one who wrote a 200-line date-parsing utility in 2019 and hasn't touched it since. Half the internet's build pipelines break the moment they push a change they don't even remember making.

That package isn't a direct dependency anyone chose. It's buried four levels deep, pulled in by something else, invisible in every dashboard an enterprise customer looks at.

Under a pure volume split, it gets a rounding error. The framework that already raised a Series C gets the check.

I've felt the shape of this problem from the other side. I run n8n self-hosted for client automation work, and the packages I lean on hardest aren't the ones with logos and marketing sites.

They're the small, unglamorous ones that do exactly one job correctly. Under this model, they'd stay exactly as invisible and exactly as unpaid as they are today.

The volume metric doesn't know the difference between popular and load-bearing.

Why I'd Still Take This Deal

None of that means the plan is wrong to try. It means the formula needs work before the first check clears.

Money flowing at all beats the current system, which is zero. I'd rather argue about the split than keep defending a status quo where the answer to "who funds the internet's dependency tree" is "nobody, and we don't talk about it."

A flawed royalty pool that pays the wrong maintainer 70% correctly still beats a sponsorship model that depends on a maintainer's follower count.

The AI angle makes this more urgent, not less. I wrote earlier this year about AI slop pull requests already costing maintainers more than GitHub Sponsors brings in — that problem hasn't gone away. It's compounded.

Valkey reported a 500% jump in submitted lines of code over six months, most of it AI-assisted and uneven. Maintainers are burning review hours on top of earning zero royalties.

Adding automated pay without fixing the review burden just means better-funded burnout.

The Uncomfortable Take

Here's the part most builders reading this don't want to hear: you are one of the freeloaders this statement is about.

If you've ever shipped a paid SaaS product built on free open source infrastructure, and if you're indie hacking in 2026 you have, you are, by the OpenSSF's own definition, commercial-scale use without commercial-scale support.

Not because you're malicious. Because the entire indie-building playbook of the last five years has been "stand on giants' shoulders for free, pay it forward once you're profitable."

Most of us never circle back.

A royalty model that actually worked would eventually reach down to solo builders too, not just enterprise customers pulling from a paying tier. That's the version of this plan nobody's pricing out yet.

It's also the version that would actually change how indie hackers budget for the tools they depend on.

What Would Actually Fix the Formula

Weight the payout by criticality, not volume.

The Sovereign Tech Fund and the OpenSSF's own Scorecard project already produce criticality scores: how many other projects depend on a package, how exposed it is, how thin its maintainer bus factor is.

Feed that into the royalty split instead of raw download counts, and the invisible date-parsing library starts outearning a framework that already has six full-time engineers on staff.

That's a harder problem to ship than "take a cut of enterprise subscriptions." Criticality scoring is fuzzier and slower to build consensus around than a flat percentage.

It also means the registries doing the paying have to admit that some of their most-downloaded packages don't need the money nearly as badly as some of their least-downloaded ones do.

That's an uncomfortable thing for a company to say about its own biggest logos. It's also the only version of this that actually reaches the maintainer the OpenSSF statement claims to be worried about.

But shipping the easy version first and calling the maintainer problem solved is how you get a press release instead of a fix.

Pay the Foundation, Not Just the Framework

Registries forcing companies to pay is the right instinct. I want this to exist.

I want the maintainer holding together the thing three layers under my package.json to get a check that doesn't depend on charity.

But if the formula pays out by traffic instead of by importance, we'll have built an elaborate system to make already-funded projects slightly richer.

The actual load-bearing wall stays exactly as broke as it is today.

Fund the foundation. Not just the logo on top of it.