You’ve seen this xkcd comic — the one where the entire internet runs on a project some random developer has been thanklessly maintaining since 2003. It’s funny because it’s true. And in [insert current year here], it’s still true.
I’m Georg, a data scientist turned software engineer working mostly in the JavaScript/TypeScript ecosystem. I wanted to fix the problem behind the comic — or at least find those invisible maintainers holding up the ecosystem with duct tape and caffeine. You probably depend on their work every day. I definitely do.
But here’s what happened instead: I found thousands of useless npm packages, a blockchain protocol gone wrong, and a lesson in why noble goals aren't enough. Let’s talk about good intentions, bad incentives, and why your code — and your career — are built on a house of cards.
The search for JavaScript’s invisible maintainers
If you ask, “Who here deserves funding for their open-source work?” everyone raises their hand. That’s the problem. The loudest voices — or the savviest marketers — aren’t always the ones keeping your code from collapsing. After all, most open-source maintainers have better things to do than self-market, like fixing bugs, reviewing PRs, and keeping the lights on.
So I tried something simple: ignore the noise. Instead of listening to who was asking for money, I wanted to see what the ecosystem actually depended on. JavaScript’s dependency graphs are public, after all. How hard could it be?
I downloaded npm’s metadata dump — every package, every dependency, every maintainer — and ran the numbers. The goal: find projects with high dependents but low visibility. Think libraries like ipaddr.js, a utility for manipulating IP addresses with 44 million weekly downloads, or long, a library for working with 64-bit integers with 28 million weekly downloads. These tools are everywhere, but their maintainers often go unnoticed — working quietly behind the scenes to keep the ecosystem running.
The logic was sound. If a package has thousands of dependents but just one maintainer and almost no contributors, that’s probably our famous Nebraskan. If it’s a transitive dependency — something your code uses indirectly, three layers deep — even more so.
At first, it worked. I did not only find well-known packages but also others like anakjalanan, nitroteh, and acertea — each with thousands and thousands of dependents, a single maintainer, and names I’d never heard of. These had to be the unsung heroes.
Then I checked the repositories.
Some led me to completely empty codebases. Others only contained bootstrapped Next.js or Node.js applications without any additional functionality. They weren’t just unmaintained. They were literally useless.
What’s going on here? Why would thousands of projects depend on empty repositories and abandoned forks?
But then I noticed that all those repositories had one thing in common: a file called tea.xyz.
This is why we can't have nice things
Meet the tea Protocol — a blockchain-based attempt to fix open-source funding. Their goal was similar to what I was trying to do, but with a cryptocurrency on top: use the dependency graph to measure a package’s impact and automatically reward maintainers with tokens. Simple.
Too simple.
tea’s “Proof of Contribution” model tied funding to dependency counts. The more projects that depend on you, the more you earn. Sounds fair — until you realize how easy it is to fake a dependency.
Suddenly, those empty repositories made sense. Spammers flooded npm with trivial packages, each containing a tea.xyz file. By artificially inflating their dependency counts, they could trick the protocol into paying them for “impact.”
Even worse, some scammers tried to sneak their own tea.xyz file into widely used open-source packages, like node-bin-gen, via a pull request. The maintainers shut it down, but not before uncovering countless similar PRs targeting other established repositories. The same abuse appeared in other package registries like PyPI and RubyGems, with useless packages clogging up the ecosystem.
To tea’s credit, they reacted quickly. By mid-2024, they added mandatory registration and guardrails against spam. npm uploads returned to normal. But the damage was already done: the NPM registry is still littered with those packages.
Good intentions, bad incentives
Goodhart’s Law states: “When a measure becomes a target, it ceases to be a good measure.” In simpler terms, the moment you tie money to a metric — like GitHub stars, dependency counts, or downloads — you create an incentive to optimize for the metric, not the underlying value.
tea Protocol learned this the hard way. And keep in mind, when this happened, tea wasn’t even a major funding allocator yet. Imagine the chaos if large organizations had poured hundreds of thousands of dollars into the system.
Fix one loophole, and another emerges. This isn’t unique to tea — Gitcoin’s quadratic funding battles Sybil attacks, App Store rankings get manipulated constantly, and even academic citation metrics are gamed. Platforms like GitHub Sponsors and thanks.dev take a different approach, enabling companies to fund projects they depend on — even transitive dependencies. While less prone to manipulation, they’re not immune; developers can still game the system by fragmenting code into shallow dependencies. Any funding model based on automation will eventually be exploited.
But let’s assume, for a moment, that you find the perfect metric after all. Let’s say you invent the ungameable tea Protocol 2.0. Now what?
Where does the money come from?
tea’s tokenomics hinge on the price of its cryptocurrency. But if the token’s only utility is to be paid out to maintainers — not to be spent — there’s no real demand. Its effective value is zero. The only way to keep the price above that is to artificially counterbalance the excess supply with enforced staking and built-in deflation, creating demand through financial speculation.
But sustainable, long-term open-source funding can’t be built on speculation. At the end of the day, someone has to open their wallet and pay. Collectively, we seem to agree that it should be those who profit financially from open-source work. But that system has a major flaw.
Why aren't companies funding?
Let me rephrase the question: Why should they? From a company’s perspective, the current system isn’t perfect, but it mostly works (👀 log4j), and best of all, it’s free. As a rational actor, there are only two reasons you’d fund open source:
- The open-source project is core to your commercial product. But in this case, why fund it when you could just hire the maintainer? That way, you gain influence over the project and ensure it aligns with your business strategy.
- Your product targets developers, and funding open-source projects is good PR. Sponsoring a trendy library or framework can win hearts in the developer community, which is great for hiring and marketing.
Don’t get me wrong — both are valid reasons. Funding with a personal incentive is still infinitely better than not funding at all. But neither scenario solves the Nebraska problem. Critical but unsexy projects stay underfunded.
So, what now?
The xkcd comic endures because it’s not a joke — it’s a reflection of reality. We’ve tried donations (too small), corporate sponsorships (too selective), and blockchain experiments (too gameable). None scale.
Maybe the answer isn’t technical. Maybe it’s a cultural shift — a recognition that open-source infrastructure is as vital as roads or electricity, and that we cannot neglect it in a time when the functioning of our entire modern world depends on it. Or maybe we’re stuck here, forever stacking yet another block on top of our Jenga tower.
What’s your take? Have you seen a funding model that actually works for invisible projects?
Let me know in the comments.
Top comments (0)