How Open
is Open Source
for the Cloud?
The cloud industry runs on open source code. But who controls it, who profits from it, and how much freedom do users actually have? The answer is more complicated — and more political — than any vendor will tell you.
open source cloud
dominate control
in active use
The cloud is built on open source but rarely run as open source. Most major platforms take community code, wrap it in proprietary services, and call it open. The distinction matters enormously — for cost, control, and sovereignty.
The cloud was built on open source. Just not for you.
Linux powers over 90% of cloud infrastructure. Kubernetes orchestrates almost every major containerized workload. PostgreSQL, Redis, Kafka, Spark — the backbone of modern cloud services is open source code, built by communities, freely licensed, and available to anyone.
So why does it cost so much? Why is it so hard to leave? And why do the companies that contribute the least to open source often profit from it the most?
The answer lies in a critical distinction that the industry deliberately blurs: the difference between open source code and open cloud infrastructure. One is free. The other is a business model.
Open source licenses grant freedom to use, modify, and distribute code. They do not grant freedom from vendor lock-in, proprietary APIs, or the gravitational pull of hyperscaler ecosystems.
AWS runs Kubernetes — but its managed version, EKS, is tightly integrated with IAM, VPC, and dozens of proprietary AWS services. You can take the Kubernetes code anywhere. You cannot easily take the architecture you built around it.
Rating the hyperscalers on true openness
We assessed the three dominant cloud platforms across four dimensions: code contribution, API openness, portability, and governance participation. Click each card to see the full breakdown.
Openness is not binary — it’s a spectrum
Different cloud technologies sit at very different points on the openness spectrum. The chart below shows where key platforms and tools actually fall — from genuinely community-governed to proprietary-in-practice.
Open source washing is the new greenwashing. Vendors wrap proprietary control planes around community code, slap an Apache license on the parts they don’t need you to pay for, and market the whole thing as open.Straithead Analysis — Cloud Platforms 2026
When open source fought back — and mostly lost
Between 2018 and 2023, a wave of foundational open source companies — MongoDB, Redis Labs, Elastic, HashiCorp — changed their licenses to prevent cloud providers from offering their software as managed services without contributing back. The hyperscaler response was swift and decisive.
| Project | Licence Change | Cloud Response | Outcome |
|---|---|---|---|
| Elasticsearch | Apache → SSPL | AWS forked → OpenSearch | Vendor Won |
| MongoDB | AGPL → SSPL | AWS created DocumentDB | Vendor Won |
| Redis | BSD → RSALv2 | AWS/Google forked Valkey | Contested |
| Terraform | MPL → BSL | Community forked OpenTofu | Community Won |
| Kubernetes | Apache 2.0 (held) | CNCF governance protected it | Stayed Open |
The pattern is clear. The only reliable protection is neutral governance, as Kubernetes and the CNCF demonstrated. When a single vendor controls the project, hyperscalers can always out-distribute, out-market, and out-resource the original maintainers.
What practitioners actually need to know
Technically yes, practically often no. The code is portable — Kubernetes runs everywhere, PostgreSQL is PostgreSQL. But the surrounding architecture typically is not. IAM policies, VPC configurations, managed service integrations, and CI/CD pipelines are all built around platform-specific primitives.
A useful rule: if your application can be containerized and its data stored in open formats, portability is achievable in weeks. If it relies on 10+ managed services, migration is a 12–18 month engineering programme.
Open core means the base product is open source, but enterprise features — security, scale, compliance — are proprietary. This model is honest but often misrepresented. The open tier frequently lacks the features needed for production use.
The test: can you run the open-source tier in production for your use case without upgrading? If production security requires the enterprise tier, it is proprietary software with a free trial, not open source software with premium features.
Sovereign cloud addresses data residency and regulatory compliance — not vendor lock-in or portability. You can have data held in a local jurisdiction by AWS and still be completely locked into AWS APIs. Sovereignty and portability are orthogonal concepts that are persistently conflated in policy discussions.
True sovereign cloud requires open standards, open APIs, and the technical ability to exit — not just a data centre in your country operated by the same hyperscaler under a local brand.
Three markers: first, neutral governance — the project is controlled by a foundation (CNCF, Apache, Linux Foundation) not a single vendor. Second, open APIs — you can interact with the service using standard protocols without proprietary SDKs. Third, open data formats — your data can be extracted without vendor tooling.
Projects meeting all three: Kubernetes, PostgreSQL, Apache Kafka, OpenTelemetry. Projects meeting none: AWS Lambda, Azure Service Bus, Google Spanner.
What this means for your cloud strategy
Architect for portability by default. Use Kubernetes rather than proprietary container services where possible. Store data in open formats. Avoid proprietary message queues when open alternatives exist. The marginal cost of portability at architecture time is low; the cost of retrofitting it later is enormous.
Treat managed services as a spectrum, not a binary. Managed Kubernetes on any hyperscaler is far more portable than a proprietary FaaS platform. Managed PostgreSQL is more portable than a proprietary NewSQL service. Make conscious choices, not default ones.
Every proprietary cloud service you adopt is a future negotiation you will lose. The time to preserve optionality is at architecture review — not at contract renewal time.
Support neutral governance. The CNCF model works. Kubernetes remained open while Redis and Elasticsearch did not — and the governance structure was the decisive variable. Organizations that contribute to neutral foundations are investing in the infrastructure commons that their own systems depend on.
The cloud is open source infrastructure inside a proprietary business model. The question is whether you understand which parts are which.
Open source won the cloud infrastructure wars. Linux, Kubernetes, and PostgreSQL are everywhere. But winning the infrastructure layer did not mean winning the business layer. The hyperscalers built proprietary value on top of community foundations, captured the economics, and called it open.
The organizations that navigate this best treat openness as a strategic asset to be designed for — not a vendor claim to be taken at face value. Know what you’re running. Know what owns you. Build accordingly.
- Linux Foundation — State of Open Source Research Report
- CNCF Annual Survey — Kubernetes & Cloud Native Adoption Data
- Red Hat — State of Enterprise Open Source Report
- Elastic — Licence Change Announcement (Apache → SSPL)
- HashiCorp — Business Source Licence Announcement
- OpenTofu — CNCF Fork of Terraform Launch
- AWS — OpenSearch Fork Announcement
- Google Cloud — Open Source Blog