The Invisible Maintainers: The People Holding Up the Internet

The Nebraska Problem

In August two thousand twenty, the webcomic artist Randall Munroe published a drawing. It showed a complicated tower of blocks, carefully balanced and labeled "all modern digital infrastructure." At the very bottom, holding the whole thing up, was one tiny block. It read, "a project some random person in Nebraska has been thanklessly maintaining since two thousand three."

The comic was number two thousand three hundred and forty-seven in his xkcd series, and it went viral because everyone in software recognized it as true. Not approximately true. Not metaphorically true. Literally true. Somewhere, right now, a person you have never heard of is maintaining a piece of code that your bank, your hospital, and your phone all depend on. They are probably not getting paid. They are probably tired. And if they stop, nobody will notice until something breaks.

Four years after that comic was published, something broke. In March two thousand twenty-four, a Microsoft engineer named Andres Freund noticed something strange in the xz compression library. A backdoor had been carefully inserted over two years by someone using the name Jia Tan. They had gained the trust of the sole maintainer, Lasse Collin, partly by exploiting the fact that Collin was burned out and overwhelmed. Sockpuppet accounts had pressured Collin to accept help, complaining about slow response times, pushing him toward handing over control. The xkcd comic had become a prophecy. The random person in Nebraska had been socially engineered.

Episode fourteen of this series told that story in detail. But the lesson worth repeating here is this: the invisible maintainer problem is not just a human cost. It is a security vulnerability. Lasse Collin was alone, exhausted, and grateful when a stranger offered to help. That gratitude was the attack surface.

This is the story underneath the story that the main Git Good series has been telling. Every episode about code, platforms, workflows, and security rests on an assumption so basic that it is almost invisible. Someone is maintaining this. Someone is keeping the lights on. And the question nobody wants to answer honestly is, who is paying them to do it?

Roads and Bridges

In two thousand sixteen, a researcher named Nadia Eghbal published a report through the Ford Foundation. She called it "Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure." It was the first serious attempt to describe a problem that the software industry had been ignoring for decades.

Her argument was elegant and uncomfortable. Physical infrastructure, roads, bridges, water systems, electrical grids, is understood to be a public good. Governments fund it. Companies pay taxes that support it. Citizens expect it to be maintained. When a bridge collapses, there is an investigation. When a water main bursts, there is an emergency response. Nobody expects the person who designed the bridge to also maintain it for free for the next thirty years.

There is a common misconception that the labor for open source projects is well funded. In reality, it is largely created and maintained by volunteers who do it to build their reputations, out of a sense of obligation, or simply as a labor of love.

Digital infrastructure, Eghbal argued, should be treated exactly the same way. The open source code that the internet runs on is public infrastructure. It is used by every Fortune five hundred company. It is embedded in every smartphone. It routes every financial transaction, every medical record, every government communication. And unlike a highway or a power grid, it is funded by almost nobody.

The numbers she found were stark. The vast majority of open source projects had fewer than three active contributors. Many had exactly one. The median open source project had zero funding. Companies worth billions built their products on code maintained by individuals who often worked nights and weekends, unpaid, responding to bug reports from those same companies.

Eghbal went on to write a book in two thousand twenty called "Working in Public," where she dug even deeper. She found that open source had fundamentally changed since its early days. The original model assumed that users would also be contributors, that the community would share the maintenance burden. But as open source became universal, the ratio of users to contributors exploded. A package might have ten million weekly downloads and one person answering issues on GitHub. The community model that was supposed to distribute the labor had collapsed under its own success.

The metaphor of roads and bridges had one more implication that Eghbal was careful to draw out. When a road deteriorates, traffic slows. When a bridge becomes unsafe, it gets closed. The failure is visible. When a piece of software is undermaintained, the failure is invisible until it is catastrophic. There are no potholes in code. There are only zero-day exploits.

The Prisoner and the Polyfill

If you wanted to design a story that captures everything broken about open source maintenance, you could not do better than the story of Denis Pushkarev and core-js.

Core-js is a JavaScript library that provides polyfills, bits of code that make new JavaScript features work in older browsers. You have almost certainly never heard of it. But if you have used the internet in the past decade, your browser has executed core-js code. It is downloaded over twenty-five million times per week from npm. It is a dependency of React, Angular, Vue, and virtually every major JavaScript framework. Babel, the tool that lets developers write modern JavaScript and ship it to older browsers, depends on core-js so deeply that the two are essentially fused together.

Denis Pushkarev started core-js in two thousand fourteen. He is Russian, based in a small city, and for years he was the sole maintainer of one of the most critical libraries in the JavaScript supply chain. He worked on it full time. He turned down job offers to focus on the project. At his peak, he earned about twenty-five hundred dollars a month in donations. That was for a library used by millions of developers and hundreds of thousands of companies.

Then things got worse. In November two thousand nineteen, Pushkarev lost an appeal to overturn an eighteen-month prison sentence. He had been riding his motorcycle and hit two pedestrians, killing one of them. He was ordered to pay compensation to the victim's family, money he did not have because he had spent years working on free software instead of taking a paying job. He went to prison.

And here is where the story becomes almost unbearable. From prison, Pushkarev continued to maintain core-js. He released version three point six while incarcerated. The JavaScript ecosystem, the one worth billions, the one that powers every startup and every tech giant, continued to depend on code maintained by a man in a Russian prison cell.

He served about ten months before being released early. But the financial damage was done. Russia's invasion of Ukraine in two thousand twenty-two brought international sanctions that cut off many of his remaining donation channels. His monthly income from open source dropped from twenty-five hundred dollars to about four hundred dollars a month. For maintaining code that runs on essentially every website in the world.

In February two thousand twenty-three, Pushkarev published a long, raw, emotional post on the core-js GitHub repository. The title was blunt. He argued that free open source software is fundamentally broken.

Free open source software is fundamentally broken. I am ready to give up open source development because so few people pay for the software upon which they depend.

The post went viral. Donations briefly spiked. Then, as always happens, the attention faded. The donations dropped back down. Core-js is still downloaded over twenty-five million times a week. Pushkarev is still its maintainer. And the gap between the value his code creates and the money he receives for creating it remains astronomical.

I Do Not Know What to Say

The event-stream incident from November two thousand eighteen is the story of what happens when a burned-out maintainer does the most natural thing in the world. They hand over the keys.

Dominic Tarr is a developer from New Zealand who created event-stream, a Node.js utility for working with streams. The package was popular, downloaded about two million times per week, but Tarr had lost interest years earlier. He had not added a meaningful feature in five years. He did not use the package himself. It sat in his GitHub profile like digital property he neither wanted nor could abandon, a module that gave him zero benefit but still carried the weight of responsibility.

If it is not fun anymore, you get literally nothing from maintaining a popular package.

In early September two thousand eighteen, someone using the GitHub handle right9ctrl sent Tarr an email. They said the package had been useful to them and offered to spend a few hours a week maintaining it. Tarr said yes. He later described it as an obvious decision. Someone was volunteering to take over a burden he no longer wanted. Sharing commit access had been a widespread community practice for years. It was how open source was supposed to work.

Right9ctrl went to work. They added a new dependency to event-stream, a small module called flatmap-stream. It looked innocent. It contained obfuscated code, encrypted with AES two fifty-six, designed to target one specific application: Copay, a Bitcoin wallet made by BitPay. The malicious code would activate only if it detected it was running inside Copay, then silently steal the wallet's private keys and send them to a remote server.

For over two months, nobody noticed. The compromised version of event-stream was downloaded nearly eight million times. It was not until November, when a computer science student named Ayrton Sparling at California State University noticed unusual behavior during a build process and opened an issue on GitHub, that the attack was discovered. The title of the issue was, simply, "I don't know what to say."

The issue received over a thousand reactions and six hundred and sixty-six comments. Eight days later, Tarr archived the repository.

When the internet turned its fury on Tarr for handing over the keys to a stranger, his response was remarkable for its honesty. He published a gist on GitHub explaining himself.

I was working as a dishwasher, and got promoted to cook. This was only a fifty cents an hour pay rise, but massively more responsibility.

The analogy landed because it was precise. A module like event-stream is digital property, a right that can be transferred, but you receive no benefit from owning it. You keep the responsibility. The community expected Tarr to guard a package he did not use, did not enjoy, and was not paid for. When he failed to be a perfect unpaid security guard, they blamed him.

Tarr proposed two solutions in his statement, and the tension between them defined the entire debate that followed. The first was straightforward: pay the maintainers. If the industry depends on this code, fund the people who write it. The second was more radical: when you depend on something, you should take part in maintaining it. Do not treat open source as a free product. Treat it as a shared responsibility.

The industry heard both proposals. It implemented neither.

The Curl of Silence

Daniel Stenberg has maintained curl since nineteen ninety-eight. Curl is the command-line tool for transferring data with URLs. It ships with every operating system. It runs on more devices than any other software in human history, somewhere north of twenty billion installations. Stenberg has been its primary author and maintainer for over twenty-seven years.

He is one of the rare maintainers who has managed to make a living from open source, working for Wolfssl, which sponsors his curl work. But even with corporate backing, the emotional labor is relentless. Stenberg has written extensively about the messages he receives. Users who demand immediate fixes. Companies worth billions filing issues written as though he owes them something. People who clearly have not read the documentation, the readme, or even the error message they are reporting.

I spend significant time each week just responding to support requests that could have been solved by reading the documentation. The emotional labor is crushing.

He is not alone. Every maintainer who has written publicly about their experience describes the same pattern. The notifications start as a trickle. A genuine bug report here. A polite feature request there. Then the project gets popular, and the trickle becomes a flood. GitHub notifications become a constant stream of demands from strangers, many of them employees of companies that use the software commercially and pay nothing. Some are polite. Some are aggressive. A surprisingly large number are written in a tone that suggests the user believes they are filing a support ticket with a company, not asking a volunteer for help.

The emotional labor is not just about responding. It is about deciding what not to respond to. Every issue is a small decision. Is this a real bug or a misunderstanding? Is this feature request reasonable or a rabbit hole? Is this person genuinely confused or being deliberately hostile? Should I spend my Saturday afternoon explaining why this pull request does not follow the contributing guidelines, or should I just close it and deal with the angry reply? Every decision costs energy. And the queue never empties.

Now add AI to that equation. On one side, AI tools can help maintainers: automatically triaging issues, drafting responses to common questions, reviewing pull requests for obvious mistakes. Some maintainers have started using them exactly this way, and the relief is real. On the other side, the same tools are generating pull requests. Developers who would never have bothered to submit a contribution now run a prompt and hit send. The volume of incoming pull requests is rising, and a growing fraction of them are AI-generated, confidently written, sometimes subtly wrong, and indistinguishable from human contributions without careful review. The maintainer who used to spend Saturday afternoon reviewing code written by humans now spends Saturday afternoon reviewing code written by humans and code written by machines, with no reliable way to tell the difference. The queue is the same queue. It just refills faster.

A research study published at the International Conference on Software Engineering in two thousand twenty confirmed what maintainers already knew. Open source maintenance is associated with significant stress and burnout. The study found that the main drivers were not technical. They were social. Hostile interactions, unrealistic expectations, and the feeling of being exploited, of creating enormous value for an industry that refuses to acknowledge the debt.

The Funding Mirage

In May two thousand nineteen, GitHub launched Sponsors, a feature that lets users send money directly to open source developers. For the first year, GitHub matched every dollar. The announcement was greeted with genuine enthusiasm. Finally, the platform that hosts almost all open source development was making it easy to fund the people who create it.

The early numbers looked promising. GitHub reported that over thirty-three million dollars had been invested in open source through the platform. Some individual success stories were remarkable. Caleb Porzio, the creator of Livewire and Alpine.js, hit a hundred thousand dollars a year on GitHub Sponsors, then eventually crossed one million dollars in cumulative earnings. He wrote a detailed blog post about how he did it.

I just hit a hundred thousand dollars a year on GitHub Sponsors.

But Porzio's story illustrates the problem as much as it does the solution. His success came from being an exceptional self-promoter. He had famous code, popular repositories, a successful book, conference talks, and a constant online presence. He was not just a developer. He was a brand. The skills that made him successful on GitHub Sponsors, marketing, content creation, community building, had almost nothing to do with the skills that make someone a good open source maintainer. A quiet genius who writes flawless code in a compression library that the entire internet depends on but who does not stream on Twitch or write blog posts, that person gets nothing.

Around the same time, other funding models were taking shape. Open Collective, founded in two thousand fifteen, offered transparent fiscal hosting for open source projects, letting them receive donations and grants with full visibility into how the money was spent. Tidelift, launched in two thousand eighteen, tried a different approach entirely. Companies would pay a subscription, and Tidelift would distribute the money to maintainers of the open source packages those companies actually used, in exchange for the maintainers meeting certain maintenance standards. The idea was to create a marketplace where the value exchange was explicit, not charitable.

The results were mixed. Tidelift raised forty-two million dollars in venture capital and signed up some significant customers. But the payments to individual maintainers were modest. Public records on Open Collective show Tidelift distributing about a thousand dollars per quarter to major scientific Python projects like SciPy and scikit-learn. A thousand dollars a quarter. For libraries that power pharmaceutical research, financial modeling, and climate science.

Corporate open source program offices, known as OSPOs, emerged as another piece of the puzzle. Google, Microsoft, Amazon, and other tech giants created dedicated teams to manage their open source engagement, contributing code, sponsoring projects, and in some cases, hiring maintainers outright. Linux Foundation studies showed that by two thousand twenty-three, about half of all companies using open source had some form of OSPO. But the funding remained concentrated. The projects that received corporate attention were the ones corporations already used visibly, Linux, Kubernetes, TensorFlow. The quiet dependencies four levels deep in the supply chain, the ones that actually hold everything together, continued to get nothing.

The uncomfortable truth about every funding model that has been tried is that they all share the same flaw. They are voluntary. Nobody is required to pay. And in a market where the product is free by definition, voluntary funding will always flow toward visibility, not criticality. The maintainer with ten thousand Twitter followers will always outearn the maintainer whose library is buried inside a library inside a library inside your banking software. The question of who should pay, and how the payment should be structured, is where this series ends up. Episode forty-three is where that argument finally gets its full hearing.

The License Trap

Here is the structural problem that none of these funding experiments can solve. Open source licenses are designed to maximize freedom. The MIT license, the most popular in the world, says you can use this code for anything, you can modify it, you can sell it, you can put it in a product worth billions, and the only requirement is that you include a copy of the license text. Not a payment. Not even an acknowledgment in your product. Just a text file in your source code that nobody reads.

The GPL family of licenses adds one constraint: if you modify the code and distribute the modified version, you must also make your modifications open source. This requirement, called copyleft, was Richard Stallman's attempt to ensure that freedom is preserved. But even the GPL creates no obligation to fund, maintain, or support the original project. You can take GPL code, build a billion-dollar product on it, contribute nothing back, and be in full legal compliance as long as you publish your modifications.

This is not a bug. This is the entire point. Open source licenses were designed in an era when the users of open source code were also developers, people who understood the code, contributed fixes, and shared the maintenance burden. The license reflected a community norm: we all contribute, and the commons grows. It worked when the community was small and the users were also builders.

The problem is that open source won. Software ate the world, and open source ate software. Now the users of open source are not just developers. They are banks, hospitals, militaries, governments, and every company with a website. The community norm of shared contribution was never designed for this scale. A license that says "you can use this for free" works beautifully when a hundred people are using it and ten of them send patches. It collapses when ten million people are using it and zero of them send anything at all.

Open source thrives on human rather than financial resources. Money alone will not fix the problem.

Some maintainers have started pushing back. In two thousand twenty-four, Redis changed its license from the permissive BSD license to a dual license that restricted cloud providers from offering Redis as a managed service without paying. The Linux Foundation immediately forked it as Valkey. The message was clear: the moment you try to restrict the freedom that open source grants, the community will route around you. You can change your license, but you cannot change the code that has already been released under the old one.

The same pattern has played out with Elasticsearch, MongoDB, and other projects that tried to find a middle ground between open and commercial. Every time, the response is the same. Forks appear. The community moves on. The original maintainers are left with a licensing change that generated hostility but not revenue.

This is the trap. Open source licenses grant freedom that cannot be taken back. The social contract between maintainers and users is entirely informal. And informal contracts break down at the exact moment they are most needed, when the project is critical, the maintainer is exhausted, and the users number in the millions.

Twenty Years in the Quiet

If you have listened to the main Git Good series, you know the name Junio C Hamano. He has been the lead maintainer of Git since two thousand five, when Linus Torvalds handed him the role after building Git in a two-week sprint. That was twenty years ago. Junio has been quietly maintaining the most important developer tool in the world for two decades. He reviews patches. He manages releases. He resolves disputes on the mailing list. He does this with a patience and consistency that borders on superhuman.

Junio is one of the lucky ones. He is employed by Google, which has sponsored his Git maintenance since two thousand eleven. His work is not unpaid. But it is still largely invisible. Ask a hundred developers who maintains Git and most of them will say Linus Torvalds. Ask them who Junio Hamano is and most will shrug. The person who built the thing gets the fame. The person who has maintained it for four times as long gets anonymity.

Junio is an anomaly. He has institutional support, a temperament suited to the work, and a project important enough that a major corporation considers it worth funding. Most maintainers have none of those things.

What makes Junio's case instructive is not that it is a model for how maintenance should work. It is that even in the best case, with corporate funding and a talented maintainer and a project everyone uses, the work is still invisible. If the best-case scenario is twenty years of quiet, thankless, meticulous labor, what hope is there for the average maintainer of a library four dependency levels deep that nobody has heard of?

The Question That Has No Answer

Open source won. This is not debatable. It powers the internet, the cloud, every smartphone, every car with a computer in it, every medical device, every financial system. The victory is total. The software commons that Richard Stallman imagined in the nineteen eighties, a world where code is shared freely and everyone benefits, came true beyond anyone's wildest projections.

But the people who built it are losing. Denis Pushkarev maintains code used by billions and earns four hundred dollars a month. Dominic Tarr handed off a package because the burden was unbearable and a stranger used it to steal cryptocurrency. Daniel Stenberg has spent twenty-seven years on curl and still fields demands from companies that treat him like an unpaid contractor. Nadia Eghbal mapped the crisis in two thousand sixteen and the industry read her report, praised it, and changed almost nothing.

The funding experiments are real and some of them help at the margins. GitHub Sponsors has moved thirty-three million dollars, and that is not nothing. Tidelift has created a model where maintenance is compensated. Corporate OSPOs are hiring some maintainers. But the scale of the mismatch is enormous. The open source software that the global economy depends on generates trillions of dollars in value. The people who maintain it receive, collectively, millions. The ratio is off by a factor of a thousand.

And here is the question that sits at the bottom of all of it, the one that Eghbal raised and nobody has answered. Is this a problem that can be solved, or is it built into the structure of how open source works? The licenses grant freedom. Freedom means anyone can use the code without paying. If anyone can use the code without paying, then funding will always be voluntary. If funding is voluntary, it will always be insufficient. The logic is airtight. Every proposed solution, donations, sponsorships, dual licensing, corporate engagement, is an attempt to work around the fundamental fact that open source defined itself as free, and free means free.

The xkcd comic got one thing slightly wrong. The tower of blocks is not resting on a project that some random person in Nebraska has been maintaining since two thousand three. It is resting on thousands of projects, maintained by thousands of people, in dozens of countries, in every time zone. Some of them are in prison. Some of them have burned out and walked away. Some of them are still there, answering issues at midnight, reviewing pull requests on weekends, keeping the lights on for an industry that cannot be bothered to learn their names.

The next time you run npm install or pip install or apt-get, think about the people on the other end of those packages. They built the infrastructure you are standing on. And most of them are invisible.