Open source decisions are strategic economic weapons. When Google open sourced Kubernetes, they were attacking AWS‘s infrastructure moat. When MongoDB changed its license to SSPL, it was fighting for survival against cloud providers commoditising their product.
You’re facing these decisions now. When to open source versus keep proprietary. When to change licenses defensively. When to accept commoditisation and when to fight it.
This guide is part of our comprehensive series on game theory for technical leadership, where we explore the strategic dynamics behind major technology decisions.
There’s a principle that explains most major open source moves—”commoditise your complement.” Understanding this framework can prevent expensive strategic mistakes. In this article we’re going to look at the strategic economics behind open source decisions using real-world cases—Google’s offensive play with Kubernetes, MongoDB and Elastic‘s defensive licensing responses, and the decision frameworks you need when facing similar choices.
What does “commoditise your complement” mean in the context of open source?
Here’s the basic idea: when complementary products get cheaper, demand for your core offering increases. Gas gets cheaper, people drive more, which means they buy more cars.
In software, this plays out through open source. You release software that strengthens demand for your actual revenue-generating product.
Joel Spolsky articulated this back in 2002 in his Strategy Letter V. “Smart companies try to commoditise their product’s complements,” he wrote.
Microsoft licensing PC-DOS non-exclusively in the 1980s is the classic example. The goal was to commoditise the PC hardware market. PCs became commodities with decreasing prices. That increased demand for their complement—MS-DOS.
This is why commercial companies contribute heavily to open source. IBM contributes because they’re an IT consulting company. Consulting complements enterprise software. So commoditising enterprise software drives demand for consulting services.
Google open sourced TensorFlow to commoditise machine learning frameworks. Free ML frameworks increase demand for the complement—cloud compute infrastructure. When Google announced TensorFlow as completely open source, they were making infrastructure the revenue layer and frameworks the commodity layer.
Open source works better for commoditisation than physical goods because software has zero marginal cost of replication. You identify which layer generates revenue and which layer you make free to increase that revenue.
Why did Google open source Kubernetes instead of keeping it proprietary?
AWS dominated cloud infrastructure through proprietary services that created vendor lock-in. Lock-in meant high switching costs. Customers who built on AWS-specific APIs were stuck there. Google needed to weaken AWS’s infrastructure moat to compete.
Kubernetes became the weapon. Open source container orchestration enables multi-cloud deployments. By making orchestration free and standardised, Google reduced AWS’s advantage. Customers could build portable infrastructure, which reduced their commitment to AWS.
Google Cloud Platform benefits as one option for running standardised Kubernetes workloads. It was a calculated move to reposition the market.
Google donated Kubernetes to the Cloud Native Computing Foundation in 2015, followed by over $9 million in infrastructure commitments. Neutral governance enabled broader adoption than a Google-controlled project would achieve. Projects under foundation control signal independence from single vendor interests, which drives adoption across competing organisations. AWS’s proprietary ECS remained niche. Kubernetes won through openness.
Google made 128,000 code contributions in a 12-month period—10 times more than any other public cloud provider. They were investing heavily in commoditising the orchestration layer so they could sell cloud services above it.
The results validate the strategy. Google Anthos is built on Kubernetes and is designed for multi-cloud deployments across GCP, AWS, and Azure. The orchestration layer is commodity. The managed services, integration, and enterprise features above it are where Google competes.
How does commoditising complements create strategic advantage?
Commoditising complements reshapes markets in your favour, leveraging strategic dynamics that shift competitive advantages. Here’s how it works.
First, it removes price-based competition in layers where you don’t monetise. Your competitors can’t undercut free. They either match your open offering or lose relevance.
Second, it forces competitors to match, which reduces their differentiation. When everyone runs Kubernetes, proprietary orchestration becomes a liability. Vendor-agnostic deployment options like Kubernetes and Terraform become the standard, not the exception.
Third, it increases total market size by lowering barriers to entry. More companies can adopt container orchestration when it’s free. That grows the total market for cloud infrastructure services above it.
Fourth, it shifts value capture from the commodity layer to your proprietary differentiation. Customers can’t pay you for orchestration—it’s free. But they’ll pay for managed services, security, compliance features, and integration.
Fifth, ecosystem effects amplify your move. Others build on your free commodity foundation. Training, tooling, consulting, and adjacent products all reinforce your commodity layer as the standard.
Sixth, you set standards and influence industry direction. Leading development of the commodity layer lets you shape how the entire stack evolves.
The strategy works best when you have strength in the primary product layer. Commoditising orchestration only helps if you can compete in cloud infrastructure. Timing matters too. Commoditise early and you preempt competitors from establishing proprietary lock-in. Commoditise late and you might be fighting from weakness.
The risk is commoditising the wrong layer. Accidentally commoditise your revenue source and you’ve destroyed your own business model. That’s why stack analysis matters. Map the value chain, identify complements, and understand which layers are commodities versus differentiation.
What was the real strategic reason behind MongoDB’s license change?
These advantages work offensively. Defensively, commoditisation creates different challenges.
MongoDB originally used AGPL—a permissive copyleft license. This worked fine until AWS challenged the model.
In 2017, AWS launched Amazon DocumentDB with a MongoDB-compatible API. AWS captured revenue from managed MongoDB without contributing back. They weren’t violating the license. They were following it while undermining MongoDB’s business.
MongoDB faced a direct threat. The cloud provider was commoditising their core product. This wasn’t about complements. This was a direct attack on their revenue layer.
In October 2018, MongoDB changed the license to Server Side Public License (SSPL). The new license requires anyone offering MongoDB as a service to open source their entire service stack. As Stratechery described it, “The MongoDB SSPL is like the AGPL on steroids.”
AWS responded with DocumentDB, designed to be compatible with MongoDB 3.6 API by emulating expected responses. DocumentDB doesn’t use any MongoDB SSPL code—it uses the Apache 2.0 MongoDB APIs from pre-SSPL versions.
The license change is controversial. SSPL isn’t OSI-approved open source. Debian, Red Hat Enterprise Linux, and Fedora dropped MongoDB from their repositories.
Trade-off accepted: protection from cloud providers versus community fragmentation. MongoDB maintains its own managed Atlas service as its primary revenue driver. The license change bought time to build a differentiated cloud offering.
This signals a broader industry pattern—defensive licensing against hyperscaler threat. When cloud providers commoditise your product, defensive licensing is one response. It comes with costs, but it can work when you move fast enough.
What happened in the conflict between Elasticsearch and AWS?
Elastic created a popular search and analytics engine under Apache 2.0 license. Then AWS entered the market.
AWS launched Amazon Elasticsearch Service—a managed offering using Elastic’s work. AWS captured market share in managed search services. Elastic faced the same threat as MongoDB.
In 2021, Elastic changed the license from Apache 2.0 to dual licensing under SSPL and Elastic License. Both prevent cloud providers from offering a managed service.
AWS’s response differed from DocumentDB. AWS forked Elasticsearch version 7.10.2 and launched OpenSearch, keeping it under Apache License V2. This created an ecosystem split: Elasticsearch (Elastic’s proprietary) versus OpenSearch (AWS’s fork).
AWS made a substantial commitment beyond symbolic opposition. AWS handed OpenSearch governance to Linux Foundation in September 2024, establishing the OpenSearch Foundation. That signals commitment to community-driven development.
Different outcome than MongoDB because AWS committed more heavily to the search market. The cost of forking and maintaining OpenSearch was acceptable because search is strategic to AWS’s service portfolio.
Elastic maintains commercial features and Elastic Cloud as revenue. Elastic added AGPLv3 license in late 2024 alongside SSPL and ELv2, partially addressing community criticism while maintaining cloud provider protection.
Defensive licensing can force forks and fragmentation. Success depends on whether you can innovate ahead of the fork and whether the forker commits resources.
How do open source licenses differ strategically beyond legal terms?
Understanding license strategies leads to a practical question: when should you open source?
Licenses are strategic choices that enable or prevent specific business models. Legal terms matter, but strategic implications matter more.
Permissive licenses like MIT and Apache maximise adoption by placing few restrictions on usage. MIT allows use in proprietary projects without source code disclosure. It maximises adoption while accepting commercial derivatives. Apache License 2.0 contains patent license provisions protecting companies from patent infringement. These work well for larger organisations managing contributors who don’t care about commercialisation.
Strategic permissive use: when ecosystem growth and standard-setting matter most. TensorFlow uses Apache 2.0. Kubernetes uses Apache 2.0. Maximum adoption, maximum ecosystem development, maximum influence over industry direction.
GPL requires derivative works stay open under GPL—copyleft that prevents proprietary forks. Companies adopting GPL software must work out whether they’ll release other software integrating with it under GPL. Some companies have blanket policies against GPL because of copyleft requirements.
Strategic copyleft use: when preventing proprietary competition is the priority. Linux uses GPL. You can modify it, but you can’t make a proprietary fork without releasing your modifications.
AGPL closes the network loophole in GPL—GPL 3.0 doesn’t require source release for modified software run across a network, but AGPL does. Strategic use: protecting against cloud providers running your software as a service without contributing back.
Source-available licenses like SSPL protect against specific threats. MongoDB created SSPL specifically for the cloud provider threat. It’s not OSI-approved, which fragments the community, but it achieves the strategic goal.
HashiCorp switched Terraform from open source to Business Source License (BUSL). BUSL restricts commercial use initially, converting to open source after a time period. Response: OpenTofu forked as an open source alternative joining the Linux Foundation with the goal of joining CNCF.
License choice signals intent. Permissive signals community-first, maximum adoption. Copyleft signals protection against proprietary capture. Source-available signals defensive positioning against specific threats, usually cloud providers.
Permissive often wins in infrastructure because companies need to integrate without viral licensing concerns. Copyleft works for applications where preventing proprietary forks matters more than maximising adoption.
Changing licenses post-adoption is risky. MongoDB and Elastic faced criticism. OpenTofu emerged from Terraform’s change. Make the right choice early or accept the costs later.
When should you open source versus keep proprietary?
Open source when you’re commoditising a complement to your revenue-generating layer. Keep proprietary when the component is your differentiation and revenue source. Understanding these strategic technology decisions requires mapping your value chain and competitive landscape.
Open source infrastructure layers to build an ecosystem and set standards. Kubernetes commoditises orchestration—the complement to cloud services. TensorFlow commoditises ML frameworks—the complement to cloud compute. Docker donated containerd to CNCF in March 2017 to commoditise container runtime—the complement to orchestration and tooling.
Keep proprietary features that solve customer-specific problems requiring support. Red Hat open sources everything but sells expertise, certification, support, and enterprise-grade quality assurance. They harden security, fix bugs, patch vulnerabilities, and contribute improvements back. Then they sell the vetted, enterprise-ready version with support. The $34 billion IBM acquisition of Red Hat in 2019 validated this approach. The model works mainly for software requiring operational support and is challenging for smaller companies.
Open source to preempt competitors from establishing proprietary lock-in. Google didn’t wait for AWS to lock down container orchestration. They commoditised it first, preventing AWS from using orchestration as differentiation.
Keep proprietary when you lack the ability to monetise through services or higher layers. If the software is your product and you can’t charge for support, managed services, or complementary offerings, keeping it proprietary makes sense.
Consider timing. Early open source builds adoption. Later open source can weaken established competitors. Timing mattered for Google—too early and they’d lack credibility, too late and AWS might have established a proprietary standard.
Hybrid open core works for many businesses. Open source commodity functionality. Keep advanced features proprietary—enterprise capabilities, compliance, analytics. Test the split with customer feedback.
Map your value chain, identify complements, assess competitive dynamics. Which layer do customers pay for? Which do they expect free? Where can you differentiate?
Network effects evaluation matters. Will your ecosystem create more value than direct sales? If yes, open source. If no, stay proprietary. Open source alternatives provide procurement leverage by giving enterprises bargaining power and technical options beyond any single vendor.
Defensive consideration: what happens if someone else open sources competing functionality? If they commoditise your layer before you do, you’re fighting from weakness. Sometimes open sourcing first is defensive positioning.
What are defensive open source strategies when competitors commoditise your product?
When competitors commoditise your product, you need defensive strategies.
Defensive licensing: change to restrictive licenses that prevent competitive managed services. MongoDB and Elastic adopted SSPL. It protects against cloud providers but risks forks. Move fast—delay strengthens competitors.
Build your own cloud offering before commoditisation completes. MongoDB Atlas and Elastic Cloud emphasise authenticity and integrated features. Original maintainers have advantages in managed service quality.
Focus innovation on proprietary extensions and managed service differentiation. Advance features faster than commodity implementations. Build enterprise capabilities and compliance features cloud providers won’t prioritise.
Donate to a neutral foundation to maintain governance influence despite commoditisation. Foundation governance ensures you have a voice in technical decisions even as others adopt your commodity layer.
Strategic partnerships with non-threatening cloud providers for distribution. Partner with Azure or Google Cloud against AWS when AWS is the threat.
Accept commoditisation and compete on execution, support, and integration quality. Red Hat’s embrace of commodity Linux shows this can work.
Each strategy has costs and trade-offs. A multi-strategy approach works best. Combine defensive licensing with your own cloud offering and feature velocity for resilience.
FAQ Section
Can I change my open source license after initial release?
Yes, but it comes with significant complexity and risks. Copyright holders can relicense their own code. If you’ve accepted external contributions, you need a contributor agreement that permits relicensing, or you’ll need to rewrite the contributed code. MongoDB and Elastic successfully changed licenses but faced community criticism. Existing users typically get grandfathered under the old license. You’ll need to consider your communication strategy, community impact, and the risk of forks before changing licenses.
Does open sourcing always lead to more adoption than proprietary alternatives?
Not automatically, but open source generally increases adoption by removing price barriers and enabling evaluation. Success depends on product quality, documentation, community engagement, and ecosystem development. Proprietary tools can win with superior features, better support, or strong sales channels. Kubernetes succeeded partly because it was open; AWS ECS remained niche despite AWS’s market power. Open source is necessary but not sufficient for adoption.
How do I choose between MIT, Apache, and GPL licenses?
MIT: Maximum adoption, simplest terms, allows commercial derivatives.
Apache: Patent protection, foundation compatibility, common for infrastructure.
GPL: Prevents proprietary forks, requires derivatives stay open, but some companies ban GPL outright.
It’s a strategic decision that depends on your business model, competitive positioning, and whether you’re commoditising or protecting. If you’re building an ecosystem to strengthen a separate commercial offering, use permissive. If the project is your offering, consider copyleft protection.
Can I make money from open source without restricting licenses?
Yes, through several models: enterprise support and services (the Red Hat model), managed cloud services (MongoDB Atlas, Elastic Cloud), open core with proprietary extensions, consulting and implementation services, training and certification programs, or commercial use licensing separate from community use. Success depends on whether customers value your additional offerings beyond the code itself. This works best when software requires expertise to operate, has enterprise compliance requirements, or benefits from managed operations.
