Managed Service, Severed Loop

Seen from above, the cloud computing landscape of the mid-2010s reveals a subtle but decisive shift in how technology markets mature: the moment a cloud provider’s dashboard listed a fully-managed, proprietary service named after a popular open-source project was not a triumph of adoption but a signal of a broken economic feedback loop. Descend to the ground level and you will find the individual developer, logging into the Amazon Web Services console in late 2015, searching for a database solution.

Among the offerings was “Amazon Elasticsearch Service”—a turnkey, operationalized version of the open-source Elasticsearch search engine. AWS handled the scaling, security, and backups; the user paid for convenience. This was not merely use.

It was the wholesale commercial repackaging of a community-built tool as a core, profitable product line by a hyperscale entity that contributed no direct revenue to that community’s primary steward, Elastic NV. The very standardization and efficiency that open source had achieved—the universal container, the predictable API—made its products trivially easy for cloud providers to bundle and sell. The idealism of shared creation collided with the capital logic of infrastructure-as-a-service, and the legal frameworks designed to guarantee freedom were suddenly powerless to ensure sustainability.

The tripartite negotiation among idealism, commerce, and law entered a new phase where traditional permissive licenses proved insufficient against commercial capture in a cloud-native world.

The cloud providers’ business was not selling software licenses, but selling convenience, reliability, and integrated scale. They could take the raw material of open-source projects, add the operational wrapper of their global infrastructure, and offer it as a turnkey service.

This practice, while legally permissible, severed the direct line between value creation and value capture. The community and its commercial sponsors did the work of innovation and ecosystem building; the cloud provider harvested the demand, often becoming the default choice for new users.

The consequence was not merely competition but a systemic market failure: the economic incentives that sustained large-scale open-source development were being hollowed out from beneath. The mechanism was the managed service as a core product line.

For a cloud provider like AWS, adding a managed open-source service was a high-return, low-risk investment. The software was already built, tested, and popular.

The provider’s engineering task was operationalization—building the control plane to deploy, monitor, and scale instances across their data centers. This leveraged their core competency: their global infrastructure footprint.

For the customer, the appeal was undeniable. Why wrestle with deploying your own Elasticsearch cluster when you could click a button and have AWS run it?

The value proposition shifted from the software itself to the proprietary service wrapper around it. This created a new, paradoxical form of vendor lock-in built on open-source raw material. You were not locked into a proprietary database protocol, but you were locked into AWS’s operational ecosystem, its billing meter, and its network. The software was free; the convenience was proprietary and profitable.

The economic impact on the originating companies was acute. Take Elastic NV, commercial steward of the Elasticsearch search engine and its companion tools. By 2015, Elasticsearch was the de facto standard for search and log analytics. Elastic’s business model followed the “open core” path: core software open source under the Apache License 2.0, revenue from proprietary features, support, and its own managed cloud service.

Its growth depended on converting the massive open-source user base into paying customers. AWS’s Amazon Elasticsearch Service directly cannibalized that funnel. A user who might have graduated to Elastic’s own cloud offering now had a compelling alternative within the AWS ecosystem. AWS’s service was often “good enough,” especially for users whose primary loyalty was to their cloud vendor. Elastic’s leadership described the phenomenon with palpable frustration: cloud providers were taking their products, providing them as a service, and keeping all the value.

The same pattern played out for MongoDB and Redis. AWS launched Amazon DocumentDB, marketed as “MongoDB-compatible.” It enhanced its ElastiCache service into a fully managed Redis offering. In each case, the cloud provider offered a service that directly replicated the open-source project’s API and functionality, competing head-to-head with the companies that bore the bulk of development costs.

The financial stakes were substantial. By 2018, MongoDB was a public company with annual revenues approaching $300 million; Elastic filed to go public with revenues over $160 million.

The cloud providers’ services represented a multi-million dollar drag on their growth, a shadow marketplace siphoning away their most logical customers.

Why was this permissible? The answer lies in the legal frameworks the community had championed.

Projects like Elasticsearch and Redis used extremely permissive licenses—the Apache License 2.0 or the three-clause BSD license. These were designed to maximize adoption and freedom. They allow anyone to use, modify, and distribute the software for any purpose, proprietary or commercial, without obligation to contribute changes back, provided copyright notices are retained. There is no clause prohibiting commercial sale of the software as a service.

This was a feature, embodying the ideal that code should be free from downstream restrictions. In the pre-cloud era, the main commercial use was embedding software in a larger product or selling support.

The rise of cloud computing created a novel exploitation vector that the licenses did not anticipate. A cloud service is not “distribution” of software in the traditional copyright-law sense; users access functionality over a network.

Permissive licenses governed “distribution,” leaving this network-use loophole—the “Application Service Provider loophole”—wide open.

The cloud providers were playing by the rules the open-source community had written. This exposed a profound tension between legal freedom and economic sustainability.

The licenses ensured the software could never be locked up. But they could not ensure that the labor of its creation would be rewarded in a market transformed by hyperscale utility computing.

The idealism in permissive licensing assumed a rough symmetry between use and contribution, or a marketplace with many competitors. The cloud era shattered that assumption. It created platform entities of such scale that they could incorporate open-source projects and become the primary commercial interface for them.

The economic model of open-source software can be explained as developers contributing work to projects, creating public benefits. Developers choose projects based on perceived benefits or costs, such as improved reputation and network effects. But this model depends on a healthy ecosystem where sponsors can thrive.

When the most profitable channel is controlled by entities that contribute little back, the incentive structure for maintaining that public good erodes.

The community reaction mixed betrayal with grim realization. For many developers and company leaders, this felt like hijacking. They had built something valuable in the open, following collaborative rules, only to see its commercial value captured by giants who had not shared the risk. It was asymmetrical competition: one side bore all the R&D costs, the other side only the packaging costs.

The friction was public. MongoDB’s leadership accused cloud providers of “strip-mining” open-source innovation. Redis Labs’ co-founder stated that existing licenses weren’t designed for the cloud era and that his company funded most development while cloud providers reaped hundreds of millions without sharing.

This friction translated into concrete business pressures. Open-source companies faced investor scrutiny over cloud provider competition. Sales cycles hardened as enterprise customers asked why they should buy a proprietary managed service when AWS offered one. The pressure forced a strategic reckoning. The response would be legal and institutional.

If licenses were the problem, licenses must change. Thus began a messy scramble to retrofit legal defenses. Companies moved to revise licensing terms to explicitly restrict cloud provider commercialization.

In 2018, MongoDB shifted from the GNU AGPL license to a new custom license: the Server Side Public License (SSPL). Based on the AGPL, it included a critical new condition: if you offered the software as a service, you must also open-source the entire stack used to deliver that service, including management tools. The intent was clear: to force AWS to open-source its entire proprietary service infrastructure—a condition commercially unacceptable to them.

Redis Labs adopted the “Redis Source Available License” for new modules, prohibiting their use in competing database-as-a-service offerings. Elastic later moved its codebase from Apache 2.0 to a dual-license scheme featuring the restrictive Elastic License.

These moves were instantly controversial. Were they still open source? The Open Source Initiative (OSI), steward of the Open Source Definition, stated that licenses with restrictions based on field of use are not open-source licenses. The OSI rejected the SSPL.

A schism emerged between pragmatic corporate efforts to ensure survival and the orthodox community committed to unconditional freedom.

Companies argued they were protecting sustainable development from free-riding giants. Critics accused them of betraying principles for corporate gain, creating “fauxpen source” that would balkanize the community.

This legal counterattack demonstrated the historical pattern central to this book’s thesis. The institutionalization of open source was not a linear march driven by pure technical efficiency. It was a series of contested renegotiations of “openness,” driven by shifting power balances. Here, hyperscale cloud capital forced a renegotiation of the legal frontier. The permissive license, once a weapon against proprietary lock-in, was now inadequate against a new economic lock-in. The response was to rewrite the rules, pulling back some of the very freedom that enabled adoption.

It was a painful paradox: to save the economic vessel of open-source development, some felt they must partially sink the ideological ship. The consequences altered developer relations and community trust. When a company unilaterally changed its license, it affected every user and contributor downstream.

The economic pressure was not merely a matter of lost potential customers; it fundamentally altered the capital calculus for these open-source companies.

For startups like Elastic and MongoDB, which had scaled on venture funding predicated on capturing a significant portion of their vast open-source adoption, the cloud providers’ services acted as a cap on their total addressable market. Investors began modeling in a persistent “AWS discount,” a percentage of growth that would inevitably be siphoned by the infrastructure giant’s convenient offering.

This pressured the companies to accelerate their path to profitability, often leading to more aggressive commercialization of their own offerings or a push into adjacent proprietary products sooner than their organic community development might have supported. The need to demonstrate a defensible moat to Wall Street or private markets directly conflicted with the community-centric, slow-build ethos that had birthed their projects. The commercial logic that had matured through platform companies now faced a superior force: a platform that commoditized not just software, but the very act of running it.

This commercial capture was enabled by a historical blind spot in open-source licensing philosophy. The permissive licenses that triumphed in the 2000s—Apache 2.0, MIT, BSD—were crafted in reaction to the restrictive, copyleft licenses of the previous generation. Their goal was maximum adoption by removing friction for corporate users, especially in embedding software into larger products. They succeeded spectacularly, making open source the default building block for internet-scale applications.

Yet their architects operated in a world where software was primarily distributed as bits on physical media or downloads, and where service-based delivery was a niche model. The legal concept of “distribution” was clear; offering access over a network was not.

This ASP loophole was a known but minor curiosity until cloud computing turned software access into its primary product. Thus, a legal framework designed to prevent restriction of freedom had no mechanism to address extraction of value in a service-based economy. The cloud providers were not violating any terms; they were operating in a space the terms did not govern.

The strategic playbook for hyperscale clouds was rooted in their core business model: attracting and retaining workload spend within their walled gardens.

A managed open-source service served multiple strategic purposes simultaneously. First, it was a customer retention tool. By offering a popular database or search engine as a native service, AWS ensured a customer would not look outside its ecosystem for that solution, keeping associated compute, storage, and networking revenue within its platform. Second, it was a competitive differentiator against other clouds; having the best-managed Redis service could be a deciding factor for an enterprise choosing between AWS and Google Cloud. Third, it commoditized potential rivals before they could become threats. By offering a “good enough” managed version of Elasticsearch, AWS could preempt Elastic’s own cloud service from gaining critical mass and becoming a cross-cloud alternative that could reduce leverage over customers. This was not malice but ruthless platform strategy: absorb successful abstractions into your own service layer to increase switching costs and control the pace of innovation.

For developers within these cloud providers, building these managed services was often seen as an engineering challenge and a customer-centric win. Teams focused on creating robust control planes, seamless scaling operations, and deep integration with other cloud services like IAM and CloudWatch. From this internal vantage point, they were providing immense value by relieving users of operational toil—a genuine benefit celebrated in post-launch blog posts and re: Invent presentations. This perspective often clashed starkly with the external view from the open-source project’s maintainers, who saw their years of complex feature development, bug fixing, and community support being reduced to a “wrapper” problem. The cognitive disconnect was profound: one side saw itself as adding value through operational excellence; the other saw itself as being deprived of value for foundational creation.

The community’s sense of betrayal thus stemmed from this perceived misalignment of risk and reward. The originating companies had navigated the precarious early years of product-market fit, funded initial development, managed contentious community contributions, and provided legal liability shields—all under the assumption that commercial success would follow widespread adoption. The cloud providers entered only after the market was proven, the API standardized, and the community evangelism complete. They took on no technical risk associated with pioneering new data structures or query languages; their risk was purely operational and market-facing. This asymmetry felt like a violation of an unwritten social contract within the open-source ecosystem: that those who benefit most from a common good should contribute back proportionally to its maintenance.

This friction inevitably rippled through downstream users and enterprise adopters. Corporate architects, tasked with choosing sustainable technologies, now faced a new dilemma: should they adopt the cloud provider’s managed service for simplicity and integration, or choose the originator’s offering to ensure funding for future innovation? This choice was often framed as “convenience vs. ethics,” but in reality it was a calculation about long-term viability and feature velocity. If AWS’s service captured most of the market, would Elastic have enough revenue to fund the next major version?

Some contributors felt their work was weaponized in a corporate fight. Large corporate users grew wary of building on software whose licensing terms could change overnight.

The cloud providers responded with indifference and adaptation. AWS, facing license changes, accelerated efforts to build alternatives from scratch—like Amazon DocumentDB—that were “compatible” but not derived from the original codebase. This further inflamed tensions, showing cloud providers could clone functionality without using the original code, rendering new restrictive licenses ineffective. The game escalated from packaging to replication.

By late 2018, the landscape had shifted. The dream of a pure “open core” company thriving with a permissive license in a benevolent cloud ecosystem was broken.

The unsustainable economic pressure on open-source companies, now fully exposed by cloud providers’ managed services, demanded a response more definitive than licensing tweaks. It demanded a structural reckoning with what “open” could mean when the most powerful actors were utility providers selling access, and the raw material for that utility was freely given by its makers. The unresolved pressure from the commoditized stack had found its economic conclusion.

The efficiency of containers and standard APIs had lowered friction so completely that packaging open source into services became trivial. The right to orchestrate was indeed the new frontier, dominated by those who controlled the underlying infrastructure. The stage was set not for collaboration, but for confrontation.