Open source reached a breaking point in 2026. A $50 billion market runs on unpaid volunteers, with 60% of maintainers receiving no compensation and 44% burned out. This unsustainable model forced major projects to abandon traditional open-source licenses. Redis, HashiCorp Terraform, and Elasticsearch switched to restrictive “source-available” licenses between 2021-2024, triggering Linux Foundation forks and ecosystem fragmentation that every developer now navigates.
The Source-Available Shift
Three critical infrastructure projects changed their licensing to restrict commercial use. Elasticsearch and Kibana moved from Apache 2.0 to Elastic License plus SSPL in 2021. HashiCorp switched Terraform from Mozilla Public License to BSL 1.1 in August 2023. Redis abandoned BSD for RSALv2 and SSPLv1 in March 2024.
These new licenses are not open source. The Business Source License (BSL) allows code access but prohibits production use without permission, eventually converting to open source after four years. The Server Side Public License (SSPL) requires releasing all service source code if you offer the software as a service. Neither BSL nor SSPL is OSI-approved. They’re “source-available,” not “open source.”
Why the change? Redis stated it bluntly: “Large cloud providers were repackaging open-source software into proprietary services without providing enough value back.” AWS ElastiCache and similar services monetized Redis without contributing. The license restrictions aimed to force cloud providers to either pay or fork.
For developers, this creates legal uncertainty. Can you use Redis in production? Does your deployment violate SSPL Section 13? License restrictions now affect everyday tooling choices, and fork fragmentation is real: OpenTofu versus Terraform, Valkey versus Redis, OpenSearch versus Elasticsearch.
The Linux Foundation Forks Back
Every major license change triggered a Linux Foundation fork maintaining true open source. When HashiCorp switched Terraform to BSL in August 2023, the community responded within days. The OpenTF Manifesto dropped August 15th. OpenTF announced the fork August 25th. By September 20th, the Linux Foundation accepted it as OpenTofu. Production-ready release shipped January 10th, 2024—just five months later. The fork maintains MPL 2.0 with command-line compatibility, backed by 140+ corporations, 600+ individuals, and 18 full-time engineers.
Redis’s SSPL move spawned Valkey, forked from Redis 7.2.4 under BSD license. AWS, Google Cloud, Oracle, Ericsson, and Snap support it. Elasticsearch’s 2021 license change created OpenSearch, forked from version 7.10.2, maintaining Apache 2.0 under community governance.
Elastic’s founder later admitted the license change worked: “Amazon is fully invested in their fork, market confusion resolved, and our AWS partnership is stronger than ever.” The intended goal—forcing cloud providers to fork—succeeded. But success came at a cost: ecosystem fragmentation and community damage. Redis lost every non-employee contributor. Before the fork, 12 non-employees made 54% of commits. After the license change? Zero non-employees with more than five commits.
The Root Cause: Maintainer Burnout
License restrictions are symptoms. The disease is unsustainable funding. The 2024 Tidelift State of the Open Source Maintainer Report documents the crisis: 60% of maintainers remain unpaid. Only 4,200 corporations sponsor open source through GitHub Sponsors—out of 300 million companies using it. That’s 1.4% participation funding a $50 billion ecosystem.
The human cost manifests as critical security incidents. Kubernetes announced Ingress NGINX retirement in March 2026 due to maintainer burnout. One of the most widely deployed Kubernetes components receives no security patches after March 2026. The XZ Utils backdoor in September 2024 demonstrated how maintainer burnout creates exploitable vulnerabilities. The pattern repeats: Log4Shell, Heartbleed, XZ Utils—all traced to under-resourced maintenance.
Compliance demands amplify the pressure. The September 11, 2026 vulnerability reporting deadline pushes companies to extract information and support from maintainers without compensation. The Libxml2 maintainer halted embargoed security reports in 2025, stating flatly: “I am not a supplier.” But enterprises treat volunteers exactly as suppliers, building critical infrastructure on their unpaid labor.
The Counter-Movement
Not every project chose restrictions. COCOS 4 game engine went fully MIT licensed in January 2026, removing all commercial clauses. The announcement emphasized complete developer freedom, including permission to “create an entirely new engine if desired.” It’s the opposite path from Redis, Terraform, and Elasticsearch.
Recent enforcement shows license violations still matter. FFmpeg filed a DMCA against Rockchip’s Linux MPP repository on December 18, 2025. Rockchip copied thousands of lines from FFmpeg’s libavcodec—H.265, AV1, and VP9 decoders—stripped copyright notices, claimed authorship, and redistributed under Apache instead of LGPL. After nearly two years of requests to fix the violation, FFmpeg acted. GitHub disabled the repository in January 2026.
The license landscape isn’t one-directional. Major projects like Linux kernel, Python, PostgreSQL, and Node.js remain truly open. The question for 2026: Which philosophy wins?
What Developers Should Do
First, audit your dependencies. Use tools like FOSSology, FOSSA, Qodana, or Black Duck to scan for BSL, SSPL, or custom commercial restrictions. Check indirect dependencies—transitive dependencies hide restrictions deep in your dep tree. Watch for license changes between versions. Some libraries start with one license and switch later, so knowing “we use library X” isn’t enough. You need the exact version and its specific license.
Second, evaluate commercial compatibility. Can you use this dependency in production? Does your use case violate the “Additional Use Grant”? If you’re offering software-as-a-service, SSPL Section 13 might require releasing your entire stack. That’s not hypothetical—it’s the license’s explicit purpose.
Third, make fork decisions strategically. OpenTofu versus Terraform? OpenTofu has 18 full-time engineers and 140+ corporate backers. Valkey versus Redis? AWS and Google Cloud support Valkey. OpenSearch versus Elasticsearch? Both remain viable with different governance models. Community momentum matters. The fork with stronger backing wins long-term.
Set up continuous monitoring. License changes ship with version updates. Configure alerts for dependency changes and document your license compliance for inevitable audits. The question isn’t “will our dependencies change licenses?” It’s “when will they change, and are we ready?”
2026: The Defining Moment
Open source enters 2026 as core enterprise infrastructure, with mounting pressure around sustainability, governance, funding, and licensing. The volunteer model that built a $50 billion market cannot sustain it. Projects face a choice: restrict licenses and risk forks, or stay open and risk burnout. Developers face uncertainty: audit dependencies, watch for license changes, evaluate forks, and hope the ecosystem finds sustainable funding before more critical infrastructure collapses.
The optimistic take? Funding experiments are emerging. HeroDevs launched a $20 million Sustainability Fund offering $2,500-$250,000 grants. The Open Source Pledge asks companies for $2,000 per year per full-time developer. Open Source Endowment models permanent principals with 5% annual returns. These might work.
The realistic take? We’re at an inflection point. License proliferation fragments ecosystems. Maintainer burnout creates security holes. Only 1.4% of companies financially support the open source they depend on. 2026 will determine whether open source fixes its funding model or fractures under the weight of its own success.
