Open Source Is Dead: What Does That Really Mean?
The phrase “Open Source Is Dead” has become a lightning rod for developers, founders, and enterprise buyers alike. In the widely discussed essay Open Source Is Dead, the author argues that the open source movement is no longer the innovator or industry disruptor it once was. Instead, it’s largely been co-opted by corporate interests, with the lines between truly open and “source-available” software increasingly blurred.To clarify, open source refers to software released with a license that allows anyone to view, modify, and distribute the code, typically under terms approved by the Open Source Initiative (OSI). By contrast, source-available means users can view the code, but restrictions often apply to modification, redistribution, or commercial use.But is open source truly dead—or just evolving? This article digs deep, starting with hands-on examples and production realities, to show where open source stands in 2026.Real-World Examples of Open Source Decline
To understand the meaning of “dead” in this context, let’s examine how the classic open development model has changed in practice:- License Lockdowns: Major projects like Redis and HashiCorp’s Terraform have shifted from permissive open source licenses to more restrictive ones (such as the Business Source License, or BSL), limiting freedom for commercial use. For example, while anyone could previously use and modify these projects, organizations now have to navigate additional legal hurdles if they intend to use them in business settings.
- Cloud Capture: Cloud vendors often take public projects, run them as proprietary services, and contribute little back—leading to stagnation in core development. Amazon’s managed Elasticsearch service is a notable example, where the original open source project saw fewer contributions as the cloud provider profited from hosting it.
- AI and LLMs: The most advanced language models, such as OpenAI’s GPT-4 and Google Gemini, are not open source. Even “open” models are often released under non-commercial or restricted terms, making it difficult for businesses to use or modify them freely. For instance, Llama 2 by Meta labels itself as “open,” but its license restricts certain types of commercial use.
- Source-Available ≠ Open Source: Many modern tools are “source-available,” not open source per the OSI definition. This distinction impacts both legal usage and community contribution. Projects with source-available licenses may look transparent at first glance, but contributors cannot always fork, modify, or monetize the software as they could under classic open source terms.
Code Examples: Modern Open Source Challenges
To illustrate the practical effects of these changes, let’s look at three real-world scenarios developers encounter in 2026.1. Copyleft to Source-Available: Terraform Provider Example
Suppose you automate cloud infrastructure using Terraform (which previously used an MPL license, a type of copyleft license that requires modifications to be released under the same terms). Suddenly, the license changes and commercial terms tighten:# Old way (2024): Using an official Terraform provider
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 4.0"
}
}
}
# This worked in both commercial and personal projects.
# After BSL change (2025+):
# Commercial use may now require a separate agreement or subscription.
# If you continue as before, you may be out of compliance:
terraform init
# Output: "Provider hashicorp/aws uses BSL 1.1 license. Commercial use restrictions apply."
2. AI Model Access: Open vs. Closed LLMs Example
Many production AI workflows now rely on closed APIs. Here’s a comparison using OpenAI and a so-called “open” LLM:# Using OpenAI's GPT-4 API (closed source)
import openai
response = openai.ChatCompletion.create(
model="gpt-4",
messages=[{"role": "user", "content": "Summarize this text..."}],
)
print(response["choices"][0]["message"]["content"])
# Output: (summary from GPT-4)
# Using an "open" LLM like Llama 2 (Meta), but with a restricted license:
# Commercialization may require special permission, and weights may not be modifiable.
3. Forking and Community Fatigue Example
When a project changes license or direction, community forks often arise in response. However, in production environments, this creates headaches:# Example: After Redis switched to a source-available license,
# the Valkey fork was created.
docker run -d --name valkey valkey/valkey:latest
# Output: Valkey server running (fork of Redis)
# But: Ecosystem support, documentation, and integrations lag behind Redis.
Why the Decline of Open Source Matters
The technical and business impact of these changes is significant, affecting both software quality and company risk profiles:- Vendor Lock-In Returns: As more code moves under restrictive licenses or closed APIs, switching costs rise dramatically. For example, a company that builds its stack around a popular “source-available” database may later face high costs or migration pain if license terms tighten further.
- Security Transparency Drops: Closed or source-available code is harder to audit, raising the risk of hidden vulnerabilities. Security researchers can no longer freely inspect or patch code, increasing reliance on the vendor’s internal processes.
- Innovation Slows: Barrier to entry increases for new contributors, and the “commons” that sparked rapid development in the 2000s and 2010s has shrunk. This means fewer new features, slower bug fixes, and less diversity of ideas within critical infrastructure software.
- Legal Complexity: Teams must now navigate a patchwork of licenses, with real risk for companies who get it wrong. Legal reviews become a mandatory part of the development workflow, especially for businesses aiming to avoid compliance pitfalls.
Alternatives and New Models: What’s Filling the Gap?
Given the decline of classic open source paradigms, new distribution and licensing models have emerged to fill the void:- Source-Available Licensing: Projects may show you the code, but commercial use or modification is restricted. For instance, you might be able to audit or learn from the source, but not run it in production without paying fees or seeking permission.
- Commercial Open Core: The “core” is open, but critical features are proprietary add-ons—seen in databases, CI/CD tools, and monitoring stacks. For example, a monitoring tool may provide basic metrics for free, but advanced alerting, integrations, or scalability features are locked behind a paywall.
- Cloud-First Delivery: SaaS is now the default. Even tools with open source roots (like Kubernetes) are mostly consumed as managed services, not self-hosted code. This shift means users rely on the provider for updates and uptime, rather than running their own infrastructure.
- AI Model APIs: As explored in our deep dive on AI agentic engineering, most practical AI development now relies on closed, pay-per-use APIs, not downloadable open models. For example, integrating natural language processing into your app usually means calling a proprietary endpoint and accepting its usage terms.
Comparison Table: Open Source vs. Closed Source in 2026
| Aspect | Classic Open Source (2000-2020) | Closed/Source-Available (2026) |
|---|---|---|
| License | GPL, MIT, Apache 2.0 | BSL, SSPL, custom source-available |
| Code Access | Full access, modifiable, redistributable | Viewable (sometimes), restricted modification |
| Commercial Use | Allowed by default | Often restricted or paywalled |
| Cloud Integrations | DIY/self-hosted | Vendor-managed, pay-per-use APIs |
| Community Contribution | Open PRs, community governance | Corporate control, minimal outside input |
| Security Auditing | Independent, ongoing | Opaque, vendor-controlled |
Lessons from Production: What Developers Should Know
For developers and teams depending on open source or source-available components, the day-to-day workflow has changed significantly. Understanding these practical lessons is crucial for maintaining stability and compliance:- Always Check Licenses Before Upgrading
- Automate license scanning in your CI/CD using tools such as
oss-review-toolkitorfossa, which analyze dependencies and flag problematic licenses automatically. - Watch for “source-available” or BSL/SSPL—these are not OSI-approved and may introduce unexpected constraints. For instance, a previously open dependency could silently update to a commercial license, breaking your build or introducing unplanned costs.
- Automate license scanning in your CI/CD using tools such as
- Expect More “API-Only” Solutions
- Plan for rate limits, pricing changes, and potential API deprecation. For example, if a cloud provider changes their pricing or access terms, your application could become expensive or lose functionality overnight.
- Build abstraction layers to allow future migration if APIs change or disappear. Wrapping API calls in your own interface can help you switch providers or models with minimal code changes when necessary.
- Be Ready for Fork Churn
- When a project changes direction, forks often arise but rarely with equal support or ecosystem maturity. For example, after Redis changed its license, several forks appeared, but only some gained sustained momentum.
- Assess the health of forks (activity, maintainers, ecosystem) before committing in production. Metrics such as number of active contributors, frequency of releases, and availability of documentation can help you avoid dead-end dependencies.
- Security and Compliance Are Your Job
- Do not assume “open” means “safe”—audit dependencies aggressively, especially as codebases fragment. For example, a newly forked project might lack proper security reviews, so integrate regular dependency checks into your release process.
Key Takeaways
Key Takeaways:
- The era of “everything is open source, forever” is over—many flagship projects now use restrictive licenses or closed APIs.
- Source-available ≠ open source: legal, technical, and operational risk is higher than ever.
- Production teams must automate license scanning and build for churn, as dependencies can change terms overnight.
- AI, cloud, and SaaS have accelerated the shift away from classic open source, reinforcing vendor lock-in.
- For a deeper technical dive into how this shift impacts workflows, read our guides on LLMs in software development and agentic engineering.
- The “commons” is shrinking, but there are still pockets of open innovation—choose dependencies with eyes open and a plan for the future.
For a thorough discussion of the argument and further examples, see the original essay on Medium. The bottom line: open source isn’t dead, but its golden age is over. For developers, the only safe bet is to approach every dependency and API as a potential moving target.
Sources and References
This article was researched using a combination of primary and supplementary sources:
Primary Source
This is the main subject of the article. The post analyzes and explains concepts from this source.