The Money: Who Pays for the Infrastructure the World Depends On

Three Sponsors

This is episode forty-three of Git Good.

In December two thousand twenty-one, a critical vulnerability was discovered in Log4j, a Java logging library used by roughly half the internet. The flaw was so severe that security researchers rated it a perfect ten out of ten. Government agencies issued emergency directives. Companies scrambled to patch systems. The incident dominated headlines for weeks.

When reporters went looking for the people who had to fix this, they found a small group of volunteers. Not employees. Not contractors. Volunteers. People who maintained Log4j in their spare time, alongside day jobs, because the Apache Software Foundation does not pay its maintainers. The person who wrote the patch to save half the internet had, at the time, exactly three GitHub Sponsors. Three people in the world were paying this developer anything at all.

Three. For a library embedded in the infrastructure of banks, hospitals, governments, and every major cloud provider on Earth. The entire software industry held its breath for two weeks while unpaid volunteers scrambled to fix a problem in code they gave away for free.

Episode forty of this series told the stories of the invisible maintainers. The people who keep the lights on for an industry that cannot be bothered to learn their names. That episode ended with a question. Who is paying them? This episode is the answer. It is not a comfortable one.

The Geometry of Free

Git is free. It is released under the GNU General Public License, and anyone can download it, use it, modify it, and distribute it without paying a cent. GitHub is free for public repositories. npm is free to publish to and free to download from. PyPI is free. crates.io is free. The entire infrastructure that the global software industry runs on, the tools, the registries, the package managers, the version control systems, is free.

The word "free" is doing an enormous amount of work in that paragraph.

Free means someone else is paying. GitHub is free because Microsoft, which paid seven and a half billion dollars to acquire it in two thousand eighteen, absorbs the cost of running it. npm is free because GitHub, which acquired it in two thousand twenty, absorbs the cost. The registries are free because foundations and corporate sponsors cover the bandwidth, the storage, the moderation. The open source packages are free because individuals write and maintain them on their own time.

A study by Harvard and the Linux Foundation estimated the aggregate value of open source software at eight point eight trillion dollars. That is what it would cost if every company that depends on open source had to build the equivalent from scratch. The people who created that value receive, collectively, a rounding error by comparison. The geometry is simple. Value flows up. Money does not flow down.

In September two thousand twenty-five, the registries themselves started saying so out loud. npm, PyPI, and other package repositories issued a joint statement through the Open Source Security Foundation. The title was blunt. "Open Infrastructure is Not Free." They called for tiered access models, free for hobbyists and open source projects, but with mandatory contributions from high-volume commercial users. The registries that distribute the code were running out of money to keep distributing it.

The costs of bandwidth, storage, staffing, and compliance are ever-growing. The current model, where businesses treat open source repositories as free, infinite infrastructure, is not sustainable.

The statement was polite. The subtext was not. It said, you are using our systems to build trillion-dollar companies, and you are not paying for the pipes.

The Tip Jar

The most visible attempt to fix this problem is also the most modest. GitHub Sponsors launched in May two thousand nineteen, letting anyone send money directly to open source developers through the platform. For the first year, GitHub matched every dollar, doubling every donation. The announcement was greeted with genuine optimism. Finally, the platform that hosts nearly all open source development was making it easy to fund the people who create it.

The numbers have grown. By two thousand twenty-five, more than fifty million dollars had flowed through GitHub Sponsors across over a hundred and twenty regions. Corporate sponsorships were growing forty percent year over year. In two thousand twenty-two, about forty percent of the funding came from organizations, and each corporate sponsorship was worth roughly fifteen times more than an individual donation. Those are real numbers. Real money reaching real developers.

But the success stories reveal the flaw. Caleb Porzio, the creator of Livewire and Alpine.js, crossed one hundred thousand dollars a year on GitHub Sponsors and eventually reached one million dollars in cumulative earnings. He wrote detailed blog posts about how he did it. His strategy involved a popular book, conference talks, a constant online presence, and an "Insiders" program where sponsors got early access to features. He was not just a developer. He was a brand.

The skills that made Porzio successful on GitHub Sponsors, marketing, community building, content creation, public speaking, have almost nothing to do with the skills that make someone a good open source maintainer. A quiet developer who writes flawless code in a compression library that the entire internet depends on but who does not stream on Twitch or post threads on social media, that person gets nothing. GitHub Sponsors rewards visibility, not criticality.

The Tidelift model tried to fix this directly. Founded in two thousand eighteen, Tidelift sold subscriptions to companies, roughly one hundred to one hundred fifty dollars per developer per year, and distributed the money to maintainers of the open source packages those companies actually used. The idea was elegant. Instead of hoping companies would donate out of goodwill, Tidelift made it a business transaction. Companies got security guarantees and maintenance commitments. Maintainers got paid.

The execution was harder than the idea. Tidelift raised forty-two million dollars in venture capital and signed up real customers. But the payments to individual projects remained 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 every three months. For libraries that power pharmaceutical research, climate modeling, and financial systems used by every major bank.

In two thousand twenty-five, Sonar, a code quality company, announced it would acquire Tidelift. Whether that acquisition strengthens the model or absorbs it into a larger corporate product remains to be seen. But the fact that the most sophisticated attempt to create a marketplace for open source maintenance needed to be acquired to survive tells you something about how hard this problem is.

Open Collective took a different approach. Founded in two thousand fifteen, it offered transparent fiscal hosting, letting projects receive donations and grants with full public visibility into how the money was spent. The transparency was the point. Donors could see exactly where their dollars went. The model works for projects that have a community willing to donate. For the thousands of critical packages maintained by individuals who have no community, no audience, and no marketing skills, it changes nothing.

And then there is thanks dot dev, which tried to automate the whole problem away. You connect your GitHub account, it scans your dependency tree three levels deep, and it spreads your donation across every project you actually depend on. The math is precise to eight decimal places. The amounts are often tiny. But the logic is sound. If every company using open source allocated even a small budget and distributed it proportionally across their actual dependencies, the money would reach the quiet libraries four levels deep that no other funding model touches.

The early adopters included Sentry, Cash App, and Sourcegraph. The donations remained modest.

The Pledge

In October two thousand twenty-four, Chad Whitacre stood on a stage and made an argument that was either obvious or radical, depending on who you asked. Whitacre, the head of open source at Sentry, proposed a simple formula. Every company that uses open source should pay at least two thousand dollars per year per developer on staff. Not as charity. As a cost of doing business.

We have been doing this at Sentry for three years. Our budget this year is seven hundred and fifty thousand dollars for a hundred and twenty-nine engineers. That works out to about five thousand eight hundred dollars per developer. It has grown fifty percent every year. And it works.

He called it the Open Source Pledge. Twenty companies signed on at launch, collectively committing nearly one point three million dollars. Sentry took out billboard advertisements in San Francisco, calling out tech companies by name for not paying for the open source software they depend on. The billboards were provocative by design. The message was simple. You are using this. Pay for it.

The math behind the pledge is instructive. Two thousand dollars per developer sounds modest. But if you multiply it across the industry, the numbers get large fast. A company with a thousand engineers would owe two million dollars a year. The ten largest tech companies alone, if they all signed the pledge, would contribute hundreds of millions annually. That is real money, more than enough to fund every critical dependency in the open source supply chain. Almost none of them signed.

The companies that joined the pledge were mostly small to mid-sized firms already sympathetic to open source. The trillion-dollar companies, the ones with tens of thousands of engineers building products on open source foundations, were conspicuously absent. Two thousand dollars per developer is nothing to a company worth a trillion dollars. It is also, apparently, too much to ask.

The Government Model

While the software industry debated whether voluntary donations could ever scale, Germany tried something different. In two thousand twenty-two, the German government launched the Sovereign Tech Fund, built on a premise that would have seemed radical in Silicon Valley but was entirely conventional in Berlin. Open source software is public infrastructure. Public infrastructure should be funded by the public.

The fund started with a budget of thirteen million euros. By its second year, it had grown to twenty-two million. By late two thousand twenty-four, it had invested approximately twenty-three and a half million euros across more than sixty open source projects. The portfolio read like a list of the invisible foundations underneath the internet. cURL, the tool that transfers data on twenty billion devices. OpenSSH, the protocol that secures remote connections to nearly every server on Earth. systemd, the init system that starts up most Linux machines. GNOME, the desktop environment. And Log4j, the library whose vulnerability had exposed the crisis in the first place.

The Sovereign Tech Fund did something that no corporate funding model had managed. It directed money based on criticality, not visibility. The projects it funded were chosen because they were important, not because they were famous. A quiet library that secures every SSH connection in the world got funded for the same reason a highway gets maintained. Because the infrastructure matters, regardless of whether anyone notices it.

In August two thousand twenty-four, the fund announced a fellowship program for individual maintainers, recognizing that some critical open source work is done not by projects but by people. Single developers maintaining critical code on their own time. The fellowship was an acknowledgment that the Nebraska problem from the xkcd comic was not a metaphor. It was a staffing crisis.

The demand for the fund far outstripped its capacity. Over five hundred applications were submitted, requesting a combined one hundred and fourteen million euros in funding. The fund had a fraction of that to give. But the model proved something. When you treat open source as infrastructure and fund it like infrastructure, the money goes where it is needed, not where it is visible.

The European Union took notice. An EU-level Sovereign Tech Fund began taking shape, inspired by Germany's example. Other governments started exploring similar models. The idea that open source is a public good, deserving public funding, was no longer radical. It was policy.

The License Escape

Not everyone was willing to wait for governments or corporate goodwill. Some companies tried to solve the funding problem by changing the terms.

In August two thousand twenty-three, HashiCorp announced that Terraform, its widely used infrastructure automation tool, would move from the Mozilla Public License to the Business Source License. The new license allowed anyone to view and use the code, but restricted competitors, specifically cloud providers, from offering it as a managed service without a commercial agreement. HashiCorp's argument was straightforward. Cloud companies were taking Terraform, wrapping it in a service, and selling it back to customers. HashiCorp built the tool. The cloud companies captured the revenue.

The community response was immediate and furious. Within weeks, a manifesto appeared demanding that HashiCorp revert the license change. It gathered thirty-three thousand stars on GitHub. Nearly one hundred and forty companies and seven hundred individuals pledged their support. When HashiCorp did not budge, the community forked the project. OpenTofu, backed by the Linux Foundation, shipped its first stable release in January two thousand twenty-four.

The same pattern had played out before. Redis changed its license to restrict cloud providers. Amazon forked it as Valkey. Elasticsearch went restrictive. Amazon forked it as OpenSearch. MongoDB tightened its terms. Each time, the response was identical. The moment a company tried to capture value from open source by restricting freedom, the community routed around the restriction. The code that had already been released under the old license could not be taken back. The fork inherited the community. The original company was left with a license change that generated hostility but not much revenue.

Episode forty of this series called it the license trap. The licenses are designed to maximize freedom. Freedom means anyone can use the code without paying. You cannot solve a funding problem by restricting something that was defined, from its origin, as free.

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

The AI Amplification

And then artificial intelligence made everything worse, in ways that the existing funding models were completely unprepared for.

AI companies trained their large language models on billions of lines of open source code hosted on GitHub. The code was public. The licenses, mostly MIT and Apache, permitted commercial use. The AI companies were, technically and legally, within their rights. But the result was a new layer of extraction that dwarfed everything that came before.

A company using an open source library at least runs the library. The maintainer's code does the actual work. An AI model trained on that code absorbs the patterns, the idioms, the solutions, the years of accumulated expertise, and then generates new code that competes with the original. The maintainer's knowledge has been consumed. The output is sold for billions. And the maintainer receives nothing, not even attribution, because the model does not remember where any particular pattern came from.

The fairness question that had simmered for decades suddenly boiled over. It was one thing for a company to use your library for free. That was the social contract of open source, uncomfortable but understood. It was another thing entirely for a company to train a model on your life's work, sell the model for billions, and offer you nothing. Not a donation. Not a sponsorship. Not even a thank you.

Some argued that AI created a funding opportunity. If AI tools could help maintainers triage issues, review pull requests, and write documentation, maybe the burden would lighten even without more money. Others pointed out that the same tools were generating a flood of low-quality pull requests that made the burden heavier. The queue was the same queue. It just refilled faster.

The deeper problem was structural. AI did not create the funding crisis. It revealed how severe the crisis had always been. The entire value chain, from open source code to AI training data to commercial AI products, rested on a foundation of unpaid labor. AI just made the extraction visible at a scale that was impossible to ignore.

The Uncomfortable Math

Here is the arithmetic that nobody in the software industry wants to do.

The Tidelift State of the Open Source Maintainer Report for two thousand twenty-four found that sixty percent of open source maintainers are unpaid. Not underpaid. Unpaid. They receive nothing for their work.

The total amount flowing through all funding mechanisms combined, GitHub Sponsors, Open Collective, Tidelift, corporate sponsorships, government funds, all of it, is in the low hundreds of millions of dollars per year globally. The total value of the software those maintainers produce is measured in trillions. The ratio is not close. It is not even in the same universe.

Every proposed solution has the same structural flaw. Voluntary funding depends on goodwill, and goodwill does not scale. License changes get forked around. Government funding is promising but small relative to the problem, and subject to political cycles. The German coalition negotiations in two thousand twenty-five put the Sovereign Tech Fund's budget in question, a reminder that what politics gives, politics can take away. Corporate employment of maintainers is the most reliable model, but it makes the maintainer dependent on their employer's priorities. When Google lays off its open source team, the projects those people maintained do not disappear. They just lose their funding.

The Open Source Endowment, a new nonprofit launched in two thousand twenty-five, is trying yet another model. It works like a university endowment. Donations are invested, and the returns fund grants to critical open source projects in perpetuity. The permanent capital base means funding does not disappear when a sponsor loses interest or a government changes priorities. The first grant round is planned for the second quarter of two thousand twenty-six. Whether it reaches meaningful scale remains to be seen.

Here is what is not being tried. Nobody is requiring payment. Every model, from GitHub Sponsors to the Open Source Pledge to the Sovereign Tech Fund, is voluntary. The companies that benefit most from open source, the ones worth trillions, can participate or not. They mostly choose not. And because the licenses guarantee that the software remains free regardless of whether anyone pays, there is no mechanism to compel contribution.

The problem is not that there is no money. The problem is that there is no obligation. The money exists. The will to spend it does not.

Roads Without Toll Booths

Nadia Eghbal called it the roads and bridges problem in two thousand sixteen. She was right, but the metaphor needs updating. Roads have toll booths. Bridges have maintenance budgets. Water systems have utility bills. Physical infrastructure has mechanisms, imperfect ones, sometimes unjust ones, but mechanisms to ensure that the people who use it contribute to its upkeep.

Digital infrastructure has no toll booths. It has tip jars. And tip jars do not keep bridges from collapsing.

The most honest answer to the question this episode has been asking, who pays for the infrastructure the world depends on, is that almost nobody does. A handful of governments are starting to. A handful of companies have pledged to. A handful of individuals donate. A handful of maintainers have turned themselves into brands and built sustainable incomes through sheer force of personality and marketing skill. But the vast majority of the code that runs the global economy is maintained by people who are either unpaid or drastically underpaid, working out of obligation, passion, or habit, while the companies that profit from their work treat it as a natural resource that requires no investment.

This is not a problem that better tools will solve. It is not a problem that a new platform or a cleverer funding model will solve. It is a problem that requires the software industry to accept a premise it has resisted since Richard Stallman first published the GPL. Software is infrastructure. Infrastructure costs money. If you use it, you should pay for it.

That premise is slowly, grudgingly, beginning to take hold. The Sovereign Tech Fund exists because a government accepted it. The Open Source Pledge exists because twenty companies accepted it. The registries' joint statement exists because the people who run the pipes accepted it. The question is whether acceptance spreads fast enough, before the next Log4j, the next xz-utils, the next overworked maintainer who hands the keys to a stranger because nobody else was willing to help.

Episode forty told you about the invisible maintainers. Now you know what happens when you follow the money. It barely exists. And the people holding up the internet are still, mostly, doing it for free. That was episode forty-three of Git Good.

Git log, with the oneline flag, piped to word count. It counts every commit in the repository. Each line in that output represents work. Someone wrote that code. Someone reviewed it. Someone merged it. Whether any of them were paid for it is the question this industry keeps refusing to answer.