Billion-Dollar Companies Are Running on Code Written by People Who Never See a Dime

There's a running joke in developer circles that goes something like this: somewhere deep inside every major bank's infrastructure, holding up billions of dollars in daily transactions, is a library maintained by a single exhausted person in Nebraska. The joke lands because it's basically true.

Open source software is everywhere. It's in your phone, your car, your hospital's patient management system, and the cloud platforms that Fortune 500 companies pay millions to run on. But the developers who write and maintain that code? A huge portion of them aren't collecting a paycheck for it. Not from the companies using their work, anyway.

So how does any of this actually stay running? That's the question we went digging into — and the answers are more complicated, more human, and more fragile than most people realize.

The Invisible Economy Underneath Your Tech Stack

When developers talk about the "open source ecosystem," they're describing something that functions a lot like public infrastructure. Roads, bridges, water systems — nobody builds those expecting to turn a personal profit, but everyone depends on them. Open source works the same way, except the government isn't footing the bill.

Instead, you've got a patchwork of funding models that range from genuinely sustainable to quietly desperate.

Some projects land corporate sponsorships. Organizations like the Linux Foundation, the Apache Software Foundation, and the Open Source Collective exist specifically to channel money from companies back into the projects those companies depend on. GitHub Sponsors and Open Collective let individual developers accept donations directly. A handful of high-profile projects — curl, OpenSSL, webpack — have managed to build something resembling a real funding base.

But for every well-funded project, there are dozens running on fumes. Maintainers who squeeze in commits between their actual day jobs. Developers who've been meaning to step back for years but can't find anyone willing to take over. Projects that are one burned-out contributor away from going dark.

The Dual Licensing Tightrope

One of the more interesting survival strategies that's emerged over the past decade is dual licensing — releasing software under a free open source license for personal or community use, while requiring commercial users to pay for a separate license.

It sounds elegant in theory. Companies that build products on top of your code contribute financially. Individuals and nonprofits keep getting it for free. Everyone wins.

In practice, it's messier. When HashiCorp switched Terraform to a Business Source License in 2023, the backlash was immediate and loud. The community forked the project and launched OpenTofu within weeks. When Elastic made a similar move with Elasticsearch, Amazon responded by maintaining their own fork. The message was clear: companies that have built entire business lines on top of your open source project will fork it before they'll pay you.

That dynamic puts maintainers in an impossible position. Stay fully open and watch corporations extract unlimited value from your unpaid labor. Try to capture some of that value and risk fracturing your community — or worse, watching a well-resourced competitor take your own code and outcompete you with it.

What Maintainers Actually Say

Talk to the people in the middle of this long enough and a few themes keep coming up.

First, there's the exhaustion. Not just the technical work — the support tickets, the feature requests, the GitHub issues from enterprise users who treat a free project like a paid SLA. One maintainer of a popular JavaScript utility described spending more time managing expectations than writing code. "I built this thing on a weekend because I needed it," they said. "Now I've got companies telling me their production deployments depend on it. That's a lot of weight for a hobby project."

Second, there's the genuine idealism — and it's not naïve. A lot of open source developers are deeply committed to the idea that software should be free, in both senses of the word. They're not opposed to making money. They're opposed to making money in ways that compromise the project's accessibility or its community. That's a real distinction, and it shapes every decision about sponsorships, licensing, and governance.

Third, there's the growing awareness that the current situation isn't sustainable. The 2014 Heartbleed vulnerability — a critical bug in OpenSSL, a piece of software used by roughly two-thirds of all web servers at the time — was a wake-up call. OpenSSL was maintained by a tiny team with minimal funding. The fallout prompted the creation of the Core Infrastructure Initiative, which eventually became the OpenSSF. It was progress. But it took a global security crisis to get there.

The Sponsorship Paradox

Corporate sponsorship is the solution everyone points to, and it does help — but it comes with its own complications.

When a major tech company writes a check to an open source project, they're not usually doing it out of pure altruism. They have interests. Sometimes those interests align with the project's community. Sometimes they don't. Maintainers who've navigated this describe a constant low-level tension between staying independent and staying funded.

There's also the concentration problem. Sponsorship money tends to flow toward the most visible projects — the ones with big GitHub star counts and recognizable names. The unglamorous but critical stuff, the obscure parsing library that half the internet depends on, often goes unfunded precisely because nobody knows it exists until something breaks.

So What Actually Fixes This?

Honestly? There's no clean answer, and anyone who tells you otherwise is selling something.

Better tooling for maintainers to accept payments helps at the margins. Platforms like GitHub Sponsors have made it easier for individuals to support developers they rely on, and that matters. More companies taking their open source dependencies seriously — actually auditing what they're using and contributing back — would make a real difference. The SBOM (Software Bill of Materials) push in recent federal cybersecurity policy is a step toward forcing that kind of accountability.

Some developers are experimenting with "open core" models, where the core product stays free but premium features or hosted services generate revenue. Others are leaning into consulting and support contracts. None of these are perfect. All of them involve tradeoffs.

What's clear is that the current arrangement — where a handful of exhausted volunteers maintain infrastructure that trillion-dollar companies depend on, largely for free — is a bet that keeps paying off until it doesn't. The open source community has gotten lucky more than once. Heartbleed didn't cause a catastrophic breach. The Log4Shell vulnerability in 2021 was ugly, but recoverable.

Eventually, luck runs out.

The companies building their empires on free software probably know this. Whether they're willing to do anything about it before the next crisis is the real question. And right now, the people with the most skin in the game — the developers writing the code — are mostly just hoping the answer is yes.