You Get What You Pay For: The Case for Actually Funding Open-Source Work

Somewhere right now, a developer is merging pull requests, triaging GitHub issues, and writing documentation for a library that gets downloaded 40 million times a week. They're doing it at midnight, after their day job, because the software they built became critical infrastructure for half the Fortune 500 — and none of those companies are paying them a dime.

This isn't a fringe situation. It's basically the operating model of the modern internet.

The open-source world has a money problem. Not a lack-of-money problem — there's plenty of money sloshing around in tech. The problem is that the culture of "free" has become so entrenched that even the most resource-intensive, mission-critical projects are expected to survive on vibes and volunteer hours. And that expectation is quietly breaking the whole system.

The "Free" Myth Is Costing Everyone

When the Log4Shell vulnerability dropped in late 2021, it sent security teams across the world into a full-scale panic. The affected library — Log4j — was embedded in enterprise software everywhere. The people responsible for patching it and pushing fixes were a handful of unpaid volunteers who suddenly had the entire tech industry breathing down their necks.

That's not an edge case. That's the norm.

The Apache Software Foundation, the Linux Foundation, the maintainers of curl, OpenSSL, and thousands of other projects that your company's infrastructure depends on — these are largely held together by people who are either doing it for love, doing it because their employer lets them, or slowly grinding themselves into dust because they feel too responsible to quit.

The Silicon Valley myth that "free" equals "better" made sense as a growth hack. It doesn't make sense as a long-term economic model for maintaining the foundational layer of global software infrastructure.

The Funding Models That Actually Work

The good news is that the community has been experimenting, and some real patterns are emerging. None of them are perfect, but all of them are better than hoping maintainers stay motivated forever out of sheer dedication.

Sponsorship platforms like GitHub Sponsors and Open Collective have lowered the friction for individuals and companies to throw money at the projects they rely on. It's not transformative revenue for most maintainers, but it's something — and it signals that the community actually values the work. The challenge is discoverability and the awkwardness of asking. Maintainers who are great at writing code often feel weird asking for money, and that hesitation leaves a lot on the table.

Tiered open licensing is a more structural approach. Projects like HashiCorp (before its controversial BSL pivot), Elasticsearch, and others have experimented with models where the core is open but commercial usage above a certain scale requires a paid license. Done right, this lets individuals and small teams use the software freely while asking large enterprises — who are extracting real economic value — to contribute financially. Done wrong, it fractures communities and creates resentment. The key is clarity and consistency from day one.

Consulting and support tiers are maybe the oldest model and still one of the most honest. If you know the software better than anyone, sell that knowledge. Red Hat built a multi-billion dollar company on exactly this premise. For smaller projects, even a "priority support" tier or paid onboarding service can generate enough revenue to justify dedicating serious time to maintenance.

Foundations and grants are underutilized, especially for projects that don't fit neatly into a commercial model. The NLNet Foundation, the Sovereign Tech Fund (out of Germany but increasingly relevant globally), and various open-source arms of major tech companies all have money to deploy. Writing a grant isn't glamorous, but for the right project, it can buy a maintainer six months of focused work without requiring them to compromise the project's direction.

The Governance Angle

Funding isn't just about money — it's about decision-making power. One of the reasons so many maintainers resist monetization is the very real fear of losing control of something they've built. When a corporate sponsor starts cutting checks, they often start expecting input. When a foundation holds the purse strings, they sometimes hold the roadmap too.

This is where decentralized governance models become genuinely useful. Projects that distribute decision-making through transparent processes — voting mechanisms, RFC systems, multi-stakeholder boards — are better positioned to accept funding without handing over the keys. Money flows in, but no single funder gets veto power over the project's direction.

The Hive Project approach to this is pretty straightforward: build the governance structure before you need the money. Once you're scrambling for funding, you're negotiating from a weak position. If you've already established how decisions get made and who has standing in the community, you can evaluate funding offers against that framework instead of just taking whatever's available.

What Companies Need to Hear

If your engineering org depends on open-source software — and it does — you have a responsibility here that goes beyond filing bug reports. That means actually paying for the projects you rely on, whether through direct sponsorship, employing maintainers, or supporting foundations that fund the work.

This isn't charity. It's supply chain management. The log4j situation should have made this obvious: when critical infrastructure is maintained by exhausted volunteers, the risk doesn't disappear just because the software is free. It just gets externalized onto the maintainers — and eventually onto you, when something breaks.

The open-source ecosystem is one of the most remarkable collaborative achievements in the history of software. It deserves an economic model that doesn't require the people building it to choose between their financial wellbeing and their community commitments.

Free is great. Sustainable is better.