Redis abandoned its open source license. HashiCorp locked down Terraform. A lone, burned-out maintainer nearly let attackers backdoor half the internet's Linux servers. If you've been paying attention to the open source sustainability crisis over the past two years, you've probably felt the same uneasy question I have: is the foundation we've all been building on starting to crack?
I don't think open source is dying. But the economic and social model that sustained it for three decades is under real, structural pressure. And if we keep pretending the old bargain still works, we're going to lose something irreplaceable.
What Is the Open Source Sustainability Crisis?
The open source sustainability crisis refers to the growing gap between the enormous commercial value extracted from open source software and the resources available to the people who actually maintain it. Companies worth billions run on libraries maintained by volunteers who receive little or no compensation. When those maintainers burn out, switch licenses, or simply walk away, the consequences ripple across the entire software industry.
This stopped being theoretical a while ago. In 2024 and into 2025, a string of high-profile incidents turned that background anxiety into something nobody could ignore.
Why Did Redis Change Its License?
In March 2024, Redis made a move that rattled the entire developer ecosystem. Under CEO Rowan Trollope, the company switched from the permissive 3-Clause BSD License to a dual-license model: the Server Side Public License (SSPL) and the Redis Source Available License (RSAL). By the Open Source Initiative's definition, Redis was no longer open source.
The business logic was hard to fault. Cloud providers — AWS, Google Cloud, Azure — had been offering managed Redis services for years, pulling in serious revenue from the project without contributing much back to development. Redis Labs was doing the expensive, unglamorous work of building and maintaining the software while hyperscalers captured the upside.
I've seen this pattern play out in smaller ways throughout my career. You build an internal tool, it becomes critical infrastructure, and suddenly a dozen teams depend on it while nobody wants to fund the team maintaining it. Now scale that dynamic to the entire internet.
Redis wasn't the first to make this move, but it was the most visible. The message was blunt: the "build it open, let anyone profit" model has a ceiling.
What Happened With HashiCorp and OpenTofu?
HashiCorp's license change was, in some ways, even more consequential. In August 2023, Armon Dadgar, Co-Founder and CTO of HashiCorp, announced that all HashiCorp products — Terraform, Vault, Consul, Nomad — would move from the Mozilla Public License (MPL 2.0) to the Business Source License (BSL 1.1). The BSL explicitly restricts competitors from offering HashiCorp's software as a competing commercial service.
The community response was immediate and fierce. Within weeks, a coalition of companies and developers forked Terraform to create what became OpenTofu, now managed under the Linux Foundation. It was the open source equivalent of a union vote: the community decided that if the stewards changed the rules, they'd take the code and govern it themselves.
Having worked with Terraform extensively in production, I watched this unfold with a mix of admiration and concern. The fork proved the resilience of the open source model — the code can't be taken away if it was freely licensed. But it also proved that the relationship between commercial sponsors and community contributors is way more fragile than anyone wanted to admit.
Here's what gets lost in the outrage: HashiCorp's position wasn't entirely unreasonable. As one TechTarget analysis noted, the new license still allows most use cases — it's the competitive commercial hosting that's restricted. For the vast majority of developers and companies using Terraform internally, nothing changed. But the principle changed. And in open source, principles are the whole point.
How Do Open Source Maintainers Make Money?
Here's the uncomfortable truth at the center of all this: most don't.
A Tidelift survey found that 46% of open source maintainers are unpaid volunteers. Not underpaid. Unpaid. They maintain software running in production at Fortune 500 companies, powering critical infrastructure, processing billions of dollars in transactions. They do it in their spare time, for free.
The maintainers who do get paid often earn a fraction of what their work is worth. Some receive sponsorships through GitHub Sponsors or Open Collective, but these rarely amount to a living wage. Others work at companies that allow some percentage of their time for open source — discretionary budget that's easily cut during downturns. A lucky few work at places like Red Hat or Canonical where open source maintenance is the business model.
I've contributed to open source projects over the years, and I've also been on the other side — depending heavily on libraries where I had no idea who maintained them or whether they'd still exist next year. If you've ever run npm install and watched 400 transitive dependencies scroll by, you've implicitly trusted hundreds of strangers to keep doing unpaid work indefinitely. That's a supply chain built on goodwill, not guarantees. It echoes the same fragility I've written about in the context of NPM supply chain attacks.
What Was the xz Utils Backdoor?
If the licensing debates were a slow-burning economic crisis, the xz Utils backdoor was an emergency that should have scared the hell out of everyone.
In March 2024, a Microsoft engineer named Andres Freund noticed unusual slowness in SSH connections and traced it to a deliberately planted backdoor in xz Utils, a compression library used by virtually every Linux distribution. The backdoor was sophisticated — it would have allowed remote code execution on affected systems, potentially compromising millions of servers worldwide.
The attack vector wasn't a zero-day or a novel vulnerability. It was social engineering aimed at a burned-out maintainer. The original maintainer of xz Utils, Lasse Collin, had been maintaining the project essentially alone for years. A contributor using the pseudonym "Jia Tan" spent roughly two years building trust, making legitimate contributions, and gradually gaining commit access. Other accounts pressured Collin to hand over maintainer responsibilities, citing his slow response times. Textbook social engineering, targeting someone who was clearly overwhelmed.
This is what open source sustainability looks like when it fails catastrophically. A single person, unpaid and unsupported, maintaining a critical piece of internet infrastructure, targeted precisely because they were alone and exhausted. CISA and Red Hat both issued emergency advisories. The backdoor was caught essentially by luck — Freund got curious about a 500-millisecond latency regression.
The xz incident isn't an anomaly. It's the logical endpoint of a system where critical software depends on individual volunteers with no institutional support. It should terrify anyone who builds on open source. Which is everyone. It's the same class of risk I explored when looking at how AI-generated slop is degrading open source quality, but with far more immediate consequences.
Is Open Source Actually Dying?
No. And framing it that way misses the point entirely.
Open source as a development methodology is stronger than ever. More code is being written, shared, and collaboratively maintained than at any point in history. Linux, Kubernetes, PostgreSQL, and thousands of other projects continue to thrive. The model works.
What's breaking is the economic bargain underneath it. The implicit deal was always: developers contribute code freely, and in return they get reputation, community, and the satisfaction of building something used by millions. For a long time, that was enough. It's not anymore.
The reasons are structural. Open source won. It became the default infrastructure layer for virtually all software. And when something becomes critical infrastructure, the volunteer model doesn't scale. You can't run the world's databases, web servers, and security libraries on the same model you use for a weekend side project.
Senior Contributing Editor Steven J. Vaughan-Nichols at The New Stack captured this tension well when covering the wave of license changes — the companies building on open source have created enormous value, but the distribution of that value has become untenable.
What I think we're actually seeing is a split. Large, well-funded projects with strong corporate backing — Linux, Kubernetes, Chromium — will keep operating under traditional open source licenses. Smaller projects, especially those maintained by individuals or small teams, will increasingly experiment with source-available licenses, dual licensing, or sponsorship models. And commercial open source companies will keep tightening their licenses to protect against cloud provider arbitrage.
I've seen this pattern before. When a system grows beyond its original design constraints, you don't throw it away. You refactor it. Open source licensing is getting refactored. Like most refactors, it's messy, contentious, and necessary. The same dynamic plays out with tools like VeraCrypt, where open source projects survive and thrive precisely because their community governance model is sound.
What Comes Next
The open source sustainability crisis isn't going to resolve itself through good vibes and GitHub stars. It needs structural solutions.
Some are already emerging. The Sovereign Tech Fund in Germany is directly funding open source infrastructure maintenance. The Linux Foundation's work with projects like OpenTofu shows that community governance can work at scale. Companies like Sentry have pioneered the "functional source license" — a compromise between fully open and fully proprietary that converts to open source after a set period.
But the most important change is cultural. If you run a company that depends on open source — and you do — funding the maintainers of your critical dependencies isn't charity. It's supply chain management. The xz Utils backdoor should have made that obvious.
The real crisis isn't that open source is dying. It's that we've been treating a critical piece of global infrastructure like a hobby, and the maintainers who held it together are telling us, in every way they can, that they can't keep doing this alone.
I think we'll look back at 2024-2025 as the period when open source grew up. The idealism isn't gone — it's just being supplemented with pragmatism. The next generation of open source won't be less free. It'll be more honest about what freedom costs to maintain.
If you're a developer, audit your dependency tree this week. Find the one-person projects your production systems rely on. Figure out what it would take to make sure those projects are still maintained next year. That's not pessimism. That's engineering.
Originally published on kunalganglani.com
Top comments (0)