MongoDB (2009-2024): the open-source-to-enterprise database journey and the SSPL license change that reshaped industry economics

Where MongoDB was as an open-source company in 2017

MongoDB’s 2017 IPO followed nearly a decade of open-source community building. The AGPL-licensed MongoDB Community Server had been downloaded tens of millions of times; thousands of companies used the open-source version in production; thousands more had paid relationships with MongoDB for the commercial Enterprise Advanced product. The open-source-and-commercial business model worked: the open-source product built developer adoption; the commercial Enterprise Advanced product captured revenue from large customers who wanted production support; the MongoDB Atlas cloud-managed service captured revenue from developers who wanted to skip the operational complexity.

The strategic threat that emerged through 2017-2018 was that the hyperscaler cloud providers (AWS, Microsoft Azure, Google Cloud) could offer managed-MongoDB services on their own platforms without paying MongoDB for the underlying software. Under the AGPL license, hyperscalers were technically required to share back any modifications they made to MongoDB code, but they could offer the unmodified open-source MongoDB as a managed service without owing MongoDB any direct compensation. AWS’s January 2019 launch of DocumentDB (a MongoDB-API-compatible managed service that used AWS-developed underlying storage rather than the actual MongoDB code) made the competitive threat explicit: AWS could offer customers a managed-MongoDB-like service that directly competed with MongoDB Atlas.

The SSPL license change

MongoDB’s October 2018 license change replaced AGPL with the new Server Side Public License (SSPL). The SSPL’s key innovation: section 13 required that any entity offering MongoDB as a service to third parties must release the entire stack of software used to provide the service (the operating system, the orchestration tooling, the management software, etc.) under the SSPL. The intent was to make it commercially impractical for hyperscalers to offer managed MongoDB services because they would have to open-source their entire cloud-management infrastructure.

The community reaction was substantial and lasting. The Open Source Initiative (the principal organization that certifies whether licenses comply with the Open Source Definition) refused to certify SSPL as open source. In January 2021 the OSI formally declared SSPL does not comply with the Open Source Definition. The major Linux distributions (Debian, Red Hat Enterprise Linux, Fedora) removed MongoDB from their main repositories. Many developers within the open-source community publicly criticized the change as a betrayal of open-source values, even as they acknowledged the underlying competitive challenge with AWS. MongoDB’s position has been that SSPL is open source in spirit (the source code remains fully available) but that the broader open-source community has emphasized the OSI certification as the authoritative standard.

The broader industry pattern

MongoDB’s SSPL change in 2018 was followed by similar license changes at multiple other open-source-foundation companies over 2018-2024. Confluent (October 2018) introduced the Confluent Community License with anti-managed-service restrictions. Redis (2018, then 2019, then 2024) made multiple license changes; the 2024 change to a dual-license SSPL+RSAL produced sustained community backlash and the Linux Foundation announced the Valkey fork of Redis. Elastic (January 2021) changed Elasticsearch from Apache 2.0 to dual SSPL+ELv2 licensing; AWS responded by forking Elasticsearch into OpenSearch. HashiCorp (2023) changed Terraform and other products from MPL 2.0 to BUSL (Business Source License); the OpenTofu fork emerged. MariaDB (2024) made similar BSL-style changes.

The pattern across these companies is similar: open-source-foundation businesses face competitive pressure from hyperscaler-managed-service offerings of their products. License changes attempt to limit the hyperscaler-managed-service threat. Community backlash produces forks and distribution-distribution removals. The companies retain commercial control of their flagship product but lose some open-source community goodwill. The OSI and Linux distributions take an increasingly explicit position that these new licenses are not open-source. The economic model of open-source-with-commercial-services has been substantially reshaped over the 2018-2024 period.

How RGM thinks about open-source-business-model strategy

When clients in infrastructure software ask about how to think about open-source-business-model strategy in the hyperscaler era, the MongoDB SSPL case is the structural reference. Three structural lessons. First, the open-source-foundation business model that worked through 2000s-2010s does not work cleanly in the hyperscaler-managed-service era. Open-source companies that release products under traditional open-source licenses face risk that hyperscalers will offer managed services using the open-source code without compensating the open-source-company. The economic disconnect between the open-source-company and the hyperscaler-managed-service is real and structural. Second, license changes can address the hyperscaler-managed-service threat but at the cost of open-source-community alignment. Companies that change licenses face community backlash, distribution removals, and OSI rejection. The strategic tradeoff is real: protecting against hyperscaler competition costs open-source-community-goodwill, and the company has to decide which is more valuable. Third, the structural alternative is the cloud-managed-service model (like MongoDB Atlas) that produces revenue directly from the company’s own managed service rather than from open-source-community downloads. Companies that build strong cloud-managed-service businesses (MongoDB Atlas at 68% of revenue) can support more aggressive license changes because the cloud-business produces the revenue regardless of community reaction. Companies without strong cloud businesses are more dependent on the open-source-community-goodwill and have less ability to absorb the community backlash.

The pattern is generalizable to other open-source-foundation business categories. Companies considering license changes need to evaluate: (a) the size and strategic value of the hyperscaler-managed-service threat, (b) the strength of the company’s own cloud-managed-service business, and (c) the open-source-community goodwill that the license change would cost. We tell clients in open-source-foundation positions to think about these tradeoffs explicitly rather than to treat license changes as routine business decisions.

Frequently asked questions

Related