Cloud providers are making billions from open source software. The maintainers who built that software are struggling to keep the lights on. This is the “freeloading” accusation at the heart of one of tech’s biggest fights.
This guide is part of our comprehensive Open Source Licensing Wars – How HashiCorp, Redis and Cloud Economics Are Reshaping Infrastructure Software resource, where we examine the economic tensions driving the most significant shift in open source history.
[AWS ElastiCache, Azure Cache for Redis, and Google Memorystore are high-margin managed services](https://thenewstack.io/forks-clouds-and-the-new-economics-of-open-source-licensing/) that are generating way more revenue than the companies that built the underlying databases ever did. But cloud providers aren’t paying those maintainers a cent.
Cloud providers say they’re following the licence terms and contributing code back to projects. Maintainers fire back that the biggest users—the cloud providers—are killing off the enterprise support contracts that fund development.
Why does this matter to you? Because it affects how you evaluate managed services versus self-hosting, how you assess vendor lock-in risks, and which projects you bet your business on. The 1% conversion problem is why maintainers are switching to restrictive licensing. PostgreSQL is proof that sustainable open source is possible, but only under specific conditions.
What Is “Cloud Provider Freeloading”?
Cloud providers take permissively-licensed projects like Redis or PostgreSQL, package them up as managed services, and capture the majority of commercial value. The maintainers get zero revenue from these deployments.
AWS offers RDS for PostgreSQL, ElastiCache for Redis, and DocumentDB as MongoDB-compatible. These are some of the highest-margin products cloud providers sell.
Sure, cloud providers contribute code and patches. But critics say it’s disproportionate to revenue captured—often 0.1% contribution for 80% of the revenue.
Why “freeloading” is contested comes down to how you read the licence. Apache 2.0, MIT, and BSD licences explicitly allow commercial use without payment. Cloud providers argue they’re just exercising rights the maintainers granted them.
But here’s where it gets controversial. 96% of organisations maintained or increased open source use in 2025. When millions of deployments happen via managed services, cloud provider revenue completely dwarfs what maintainers can generate through support contracts.
How Do Cloud Providers Make Money from Open Source Software?
The managed service model eliminates operational burden. You don’t hire database administrators who specialise in PostgreSQL tuning. Integration with the cloud ecosystem means monitoring, backups, and networking just work.
Industry estimates suggest 60-80%+ gross margins on managed services. Maintainers selling direct support see 20-40%. That gap is the whole story.
Lock-in effects increase customer lifetime value. Proprietary APIs, monitoring tools, and networking create switching costs that make leaving expensive. Once you’ve built around AWS RDS PostgreSQL’s extensions, moving becomes a serious headache.
Cloud providers sell open source alongside compute, storage, and networking, capturing more of your infrastructure spend. This is why managed services are so profitable—they’re selling convenience, integration, and scale that individual maintainers simply can’t match.
The Cloud Provider Perspective – We Follow the Licence
Permissive licences explicitly allow commercial use without payment. Apache 2.0, MIT, and BSD were chosen by the maintainers themselves. Cloud providers are just exercising rights the maintainers granted.
The Open Source Definition makes this pretty clear. Open source must grant all rights without restrictions on use. When maintainers release under Apache 2.0, they’re making a choice.
Cloud providers point to their contributions. AWS employs PostgreSQL committers, contributes security patches, funds Linux Foundation projects, and maintains OpenSearch. Google funds Kubernetes. Microsoft contributes to .NET and VS Code.
And they argue that managed services make open source accessible to companies that couldn’t otherwise adopt it. That expands the ecosystem and benefits maintainers who see broader adoption.
There’s also the open source preservation angle. When maintainers switch licences, providers fork to keep code open. Valkey emerged as a BSD fork backed by AWS after Redis changed licences. OpenSearch was AWS’s Elasticsearch fork. OpenTofu forked Terraform when HashiCorp moved to BSL. These forks represent a pattern explored throughout our open source licensing wars analysis.
The Maintainer Perspective – We Can’t Sustain Development
Here’s the economic reality: 99% of users never convert to paying customers, yet they all demand features, patches, and support.
Maintainer revenue comes from enterprise support. But cloud providers eliminate this need by offering managed alternatives. When AWS runs your PostgreSQL database, you don’t pay EDB or Crunchy Data.
Without revenue from largest users, maintainers can’t hire engineers for maintenance and innovation. Security patching and new features require full-time engineers, not weekend warriors.
Cloud providers capture billions while paying nothing. When they do fork projects, commercial forks create divergence and split developer activity.
Maintainers are stuck with lousy options: Restrictive licensing alienates community, venture funding means unsustainable burn, or acquisition means loss of independence.
The 1% Conversion Problem and Open Source Economics
Industry estimates suggest only 1-2% of users convert to paying customers through support contracts or managed services.
Permissive licences provide full functionality for free. There’s no incentive for customers to pay. Why pay for PostgreSQL support when you can just use it for free?
PostgreSQL has millions of users but only a fraction pay for commercial support. The gap between users and paying customers is absolutely massive.
Projects typically start as side projects, get popular, then face an unsustainable support burden. As one maintainer put it: “Despite adoption and success, I couldn’t make it sustainable. Good intentions don’t pay bills”.
Venture capital distorts the model. VC-funded companies burn cash building free software, hoping to capture users later. Most fail before finding sustainable revenue.
Corporate sponsorship funding is unpredictable and subject to shifting priorities. What happens when those priorities change?
Economic models that work do exist. Red Hat built a business on support. Confluent offers managed Kafka. GitLab uses open-core. But these require conditions most projects can’t replicate.
Alternative Business Models That Avoid Restrictive Licensing
Open-core provides free core with proprietary premium features. GitLab, Grafana, and Mattermost use this approach. The challenge is drawing the line—what goes in core versus premium?
Managed service with value-add means maintainer-operated offerings with features cloud providers don’t match. Confluent Cloud offers Kafka governance AWS doesn’t provide. Databricks adds lakehouse features beyond managed Spark.
Dual licensing gives you a choice. Use AGPLv3 for free if you’re happy sharing modifications, or pay for a commercial licence. AGPLv3 is OSI-approved copyleft requiring network service providers to share modified code. Many developers misunderstand it—they believe it requires open sourcing their entire application, but it doesn’t.
Support contracts provide enterprise agreements with SLAs. Red Hat, SUSE, and Canonical built entire businesses on this.
Foundation funding through multi-company sponsorship works for projects like PostgreSQL and Kubernetes. But this requires broad appeal and established adoption.
Now here are the nuclear options. SSPL requires anyone offering software as a service to open-source all infrastructure code—management software, APIs, automation, monitoring, backup, storage, hosting, the lot. It’s based on AGPLv3 but replaces Section 13 with requirements so broad that cloud providers simply can’t comply.
BSL is source-available with commercial restrictions for 3-4 years, then converts to Apache 2.0. HashiCorp’s BSL allows production use except in products competitive with HashiCorp.
Vendor Lock-In – Managed vs Self-Hosted Comparison
Vendor lock-in means switching costs that make changing vendors prohibitively expensive.
Managed service lock-in comes through proprietary APIs, backup formats, and monitoring integrations. AWS-specific optimisations like Aurora PostgreSQL don’t exist in vanilla open source. If you build on those features, migration becomes really hard.
Self-hosted lock-in includes custom configurations, operational knowledge, and team expertise. Your team’s PostgreSQL knowledge doesn’t transfer to MySQL. Your backup scripts don’t work with managed services.
Cost comparison gets complicated fast. Managed pricing can escalate as usage grows. Self-hosted has engineering costs—salaries for specialists, infrastructure, monitoring—that aren’t immediately obvious.
Managed services reduce need for specialised database administrators; self-hosted requires deep expertise. Do you have that expertise in-house? Can you hire it?
Aurora PostgreSQL delivers better performance than standard PostgreSQL. If your application relies on that performance, self-hosting might not even be viable.
No deployment is perfectly portable. Lock-in mitigation includes infrastructure-as-code, containerisation, and abstraction layers.
Both approaches create lock-in through different mechanisms. The question is which trade-offs make sense for your operational maturity and risk tolerance.
PostgreSQL – Proving Sustainable Open Source Is Possible
PostgreSQL thrives with permissive licensing similar to MIT/BSD. It’s proof that sustainable open source is actually possible.
The governance model centres on the PostgreSQL Global Development Group with distributed maintainership. No single vendor controls the project.
The commercial ecosystem includes multiple vendors—EDB, Crunchy Data, Timescale, Supabase—that coexist. AWS, Azure, and Google offer managed PostgreSQL while maintainer companies also offer competing services.
Development funding is sustained by companies employing PostgreSQL committers—Microsoft, Amazon, EDB, Fujitsu, Google all pay core developers.
Extensions like PostGIS, TimescaleDB, and pgvector create differentiation without fragmenting the core. Commercial vendors compete on extensions and support quality, not by controlling the core database.
Why does it work? It comes down to specific conditions. Strong governance established early. A mature codebase with 30+ years of development. A diverse commercial ecosystem. Strategic importance to multiple large companies.
Neutral governance, multi-vendor ecosystem, and strategic corporate alignment enable sustainability. But newer projects don’t have these preconditions.
The model is replicable for strategically important infrastructure projects that can attract multi-vendor investment. For projects without that broad importance, PostgreSQL’s path simply isn’t available.
Conclusion – Navigating the Economics
Cloud providers and maintainers both have economically rational perspectives. Providers follow licence terms and contribute to projects. Maintainers can’t sustain development when 99% never pay and cloud providers eliminate support revenue.
All technology choices involve trade-offs between cost, control, convenience, and risk. Managed services provide convenience but create lock-in. Self-hosting provides control but requires expertise. Permissive licences ensure freedom but create sustainability challenges. Restrictive licences fund development but fragment communities.
PostgreSQL proves that sustainable open source is possible under specific conditions—neutral governance, multi-vendor ecosystem, strategic importance to multiple companies. But most projects can’t replicate those conditions.
Restrictive licensing solves immediate funding problems but creates new issues. MongoDB reported revenue growth after SSPL adoption. But HashiCorp’s BSL triggered immediate backlash and the OpenTofu fork. Redis’s licence change prompted Valkey, a well-funded competitor backed by AWS and Google.
The future looks like continued fragmentation. More maintainers will adopt BSL or SSPL to protect their commercial interests, triggering community forks. Cloud providers will maintain open alternatives. Enterprises will face confusion choosing between original projects and forks. To understand how this pattern has evolved from MongoDB to Redis, examine the historical timeline that reveals predictable warning signs.
The 1% conversion problem remains unsolved. Until open source economics fundamentally change, expect more licensing wars, more forks, and more uncertainty.
So what do you do? Evaluate managed versus self-hosted based on your operational maturity and risk tolerance. Understand that sustainability concerns affect project viability long-term. Choose vendors and projects with governance models that reduce licence change risk.
Understanding these economic forces helps you navigate the open source sustainability crisis that’s reshaping enterprise technology decisions. For a complete overview of how licensing changes are affecting infrastructure software decisions, see our comprehensive Open Source Licensing Wars resource.
FAQ
Are cloud providers really “freeloading” on open source projects?
“Freeloading” is contested. Cloud providers follow permissive licence terms (Apache 2.0, MIT, BSD) that explicitly allow commercial use without payment. They contribute code, employ maintainers, and expand the market. Maintainers counter that contributions are disproportionate to revenue captured (often 0.1% contribution for 80%+ revenue). Both perspectives are economically rational but conflicting.
What percentage of open source users actually pay for support or services?
Industry estimates suggest 1-2% of open source users convert to paying customers through support contracts, commercial licences, or managed services. PostgreSQL has millions of users but only thousands of paying enterprise customers. This low conversion creates the sustainability crisis: maintainers can’t fund development when 99% never pay, especially when cloud providers offer competing managed services.
How do managed database services compare to self-hosting in terms of vendor lock-in?
Both create lock-in through different mechanisms. Managed services lock you into proprietary APIs, backup formats, and cloud-specific optimisations (AWS Aurora). Self-hosted creates lock-in through operational knowledge, custom configurations, and team expertise. Your team’s PostgreSQL knowledge doesn’t transfer to MySQL. Your backup scripts don’t work with managed services. Neither is perfectly portable. Evaluate switching costs realistically: data migration effort, application changes, re-training. Use infrastructure-as-code and abstraction layers to mitigate lock-in.
Can open source projects be financially sustainable without restrictive licensing?
Yes, but under specific conditions. PostgreSQL thrives with permissive licensing through neutral governance, diverse commercial ecosystem (EDB, Crunchy Data, AWS, Azure), and strategic importance to multiple large companies. Alternative models include open-core (GitLab), managed services with value-add (Confluent Cloud), support contracts (Red Hat), foundation funding (CNCF), and dual licensing with AGPLv3. Success requires strong governance, commercial differentiation, and a multi-vendor ecosystem.
What’s the difference between SSPL, BSL, and AGPLv3 licences?
AGPLv3 is OSI-approved copyleft requiring network service providers to share modified code with users. SSPL (Server Side Public Licence) is non-OSI, requiring anyone offering the software as a service to open-source all infrastructure code—it’s designed to prevent cloud re-hosting. BSL (Business Source Licence) is source-available with commercial restrictions for 3-4 years, then converts to Apache 2.0. AGPLv3 is legitimate open source; SSPL and BSL are “source-available” and often trigger enterprise licence policy rejections.
Why did Redis, HashiCorp, and Elastic change their licences?
Economic pressure from cloud providers offering managed services without contributing revenue. AWS ElastiCache competed with Redis Inc. AWS managed Elasticsearch competed with Elastic. Cloud providers planned managed Terraform threatening HashiCorp’s business. These companies switched to SSPL or BSL to prevent commercial re-hosting. The changes triggered backlash and forks (Valkey from Redis, OpenTofu from Terraform, OpenSearch from Elasticsearch), fragmenting ecosystems but protecting maintainer revenue.
How much do cloud providers actually contribute back to open source projects?
It varies significantly. AWS employs PostgreSQL committers, contributes security patches, funds Linux Foundation projects, and maintains OpenSearch. Google funds Kubernetes development. Microsoft contributes to .NET, TypeScript, and VS Code. Critics argue contributions are disproportionate to revenue (0.1% contribution for 80% revenue capture). Supporters note code commits don’t reflect total value: infrastructure, security research, compliance certifications, and market expansion. There’s no industry-standard metric for “fair contribution.”
Is PostgreSQL the exception or the model for sustainable open source?
Both. PostgreSQL proves sustainable open source is possible under permissive licensing, but it requires specific conditions: neutral governance, strategic importance to multiple large companies, a mature codebase with 30+ years of development, and a diverse commercial ecosystem where vendors differentiate through extensions and services. Newer projects lack these preconditions. PostgreSQL’s model is replicable for strategically important infrastructure projects that can attract multi-vendor investment, but it’s not universally applicable.
What should you consider when choosing between managed services and self-hosting?
Evaluate: (1) Total cost over 5 years including engineering time and infrastructure; (2) Operational maturity—do you have DBAs and infrastructure engineers?; (3) Lock-in risks—can you migrate if needed?; (4) Compliance requirements—do you need SOC2, ISO27001, HIPAA certifications?; (5) Performance needs—do cloud-specific optimisations provide advantages?; (6) Team expertise—will managed services enable focus on your core business?; (7) Sustainability concerns—does the licence restrict your use case?
How can open source maintainers build sustainable businesses without alienating the community?
Avoid restrictive licences if possible. Consider: (1) Open-core with clear premium features (GitLab, Grafana); (2) Managed service with value-add cloud providers don’t match (Confluent Cloud’s Kafka governance); (3) Dual licensing with AGPLv3 + commercial option; (4) Enterprise support contracts with SLAs; (5) Foundation governance preventing single-vendor control (PostgreSQL model); (6) Corporate sponsorship from multiple companies; (7) Development services (consulting, custom features). Success requires commercial differentiation beyond the core project.
What are the long-term implications of the open source licensing wars?
Expect continued fragmentation: More maintainers adopting BSL/SSPL to protect commercial interests, triggering community-led forks (the OpenTofu, Valkey, OpenSearch pattern). Cloud providers will maintain open source alternatives to avoid restrictive licences. Enterprises face confusion choosing between original projects and forks. PostgreSQL-style neutral governance may become more attractive. The OSI definition of “open source” is under pressure. The 1% conversion problem remains unsolved, so the economic tension will persist.
Does using restrictive licences actually improve open source sustainability?
Mixed results. MongoDB reported revenue growth after SSPL adoption. HashiCorp’s BSL adoption triggered immediate community backlash and the OpenTofu fork, fragmenting the Terraform ecosystem. Elastic’s SSPL adoption protected against AWS competition but alienated some enterprise users. Redis’s licence change prompted the Valkey fork backed by major tech companies, creating a well-funded competitor. Restrictive licences solve immediate revenue problems but risk community fragmentation, fork competition, and enterprise adoption barriers.
