Why the Open Source Success Formula Began to Shake
Open source has long grown on a very simple structure. Code is open, anyone can use it, and developers collaborate to build better software together. This philosophy began with the free software movement and spread rapidly alongside the rise of the internet. Many developers embraced open source not just as a development method, but as a culture. Sharing code, solving problems collectively, and evolving projects together formed a collaboration model fundamentally different from the traditional software industry. Remarkably, this model did not remain an ideal—it began to demonstrate real power within the industry. Today, countless technology stacks are built on open source. Projects such as Linux, PostgreSQL, Kubernetes, Redis, and Kafka have become core components of modern infrastructure, supporting services across countless companies.
Yet a natural question emerges from this reality. How do the projects behind such critical software actually make money? Open source is fundamentally distributed for free. Anyone can download, modify, and redistribute the code. From this perspective, open source projects appear to have very low economic sustainability. However, in practice, large companies have emerged based on open source. The most representative example is Red Hat. By building enterprise distributions and support services on top of the Linux operating system, Red Hat established a stable revenue model over decades. In 2019, it was acquired by IBM for $34 billion, becoming one of the most successful business cases in open source history. This event demonstrated that open source is not merely free software—it can form a sustainable industrial model.
This success created a kind of formula for open source companies. The core software is released as open source, enterprise customers are offered stable operations and support, and additional enterprise features are introduced as needed. For a time, this model appeared to function quite stably. Open source grew rapidly through developer communities, while companies generated revenue through commercial services built on top of it. A relatively balanced relationship formed among developers, companies, and users. However, over time, cracks began to appear in this structure. In particular, a new technological paradigm that emerged in the late 2010s started to significantly disrupt this balance: the cloud. The cloud was not simply about hosting servers elsewhere—it fundamentally changed how software is distributed and consumed.
At first, this shift did not seem particularly threatening. In fact, many open source projects spread even faster thanks to the cloud. Cloud platforms provided infrastructure for building new services, and developers could freely deploy open source software on top of them. But over time, the situation began to evolve in a different direction. Cloud companies went beyond providing infrastructure—they started offering open source software itself as a service. From that moment on, open source companies found themselves facing a new and unexpected competitive landscape.
How the Cloud Era Changed the Economics of Software
Before the emergence of the cloud, the software industry had a relatively simple structure. Companies purchased or downloaded software and installed it on their own servers. Core infrastructure such as operating systems and databases typically ran within internal data centers. In this environment, the role of software companies was clear: develop products, sell licenses, and provide maintenance and updates. Open source companies were not fundamentally different. The code itself was free, but companies generated revenue by providing the stability and support required in real-world environments. Enterprise customers did not just need software—they needed a partner capable of operating it reliably.
With the rise of the cloud, however, this structure began to change fundamentally. Instead of installing software, the cloud centered around consuming it as a service. Companies no longer needed to purchase or operate servers themselves. Instead, they could provision infrastructure on cloud platforms with just a few clicks. If they needed a database, they could create one instantly. If they needed a search system, they could spin up a cluster in minutes. This approach offered a completely different user experience compared to traditional software deployment. There was no installation process, no complex configuration, and most scaling and operations were automated.
This shift was not just about convenience—it transformed the economic structure of software. In the past, the company that created the software sold it and provided support. In the cloud era, platform providers could deliver that software as a service. From the user’s perspective, there was no longer a need to purchase the software itself. Instead, it was far more convenient to use a ready-to-run service. This change was especially pronounced in infrastructure software such as databases, message queues, and search engines. Many developers began choosing managed services provided by cloud platforms instead of installing and operating software themselves.
At first, this structural change appeared to be just another technological trend. But over time, it began to raise critical questions for open source companies. If cloud platforms provide the software we created as a service, who will customers actually pay? And when that service succeeds, which company captures the most value? This question was not limited to a single company—it became a structural challenge faced by the entire open source industry.
Managed Service — A New Competitive Model
One of the most significant changes the cloud introduced to the software industry is the concept of Managed Service. A managed service is not simply about renting servers—it is about delivering software in a fully operated state. Users do not install software, manage updates, or operate clusters themselves. Instead, the cloud platform handles all operations. If a database is needed, it can be created in just a few clicks. Backup, scaling, and failure handling are largely managed by the platform. This model is especially powerful for infrastructure software, where operational complexity is high.
For developers, managed services are an extremely attractive option. Running a database or search engine in a traditional way requires significant operational expertise. Clusters must be configured, failure scenarios anticipated, performance tuned, and scaling strategies designed. But when a cloud platform takes care of these tasks, developers can build services much faster. As a result, many companies and startups began choosing managed services instead of operating software themselves. This was particularly advantageous in startup environments, where minimizing operational overhead while maintaining reliable infrastructure is critical.
However, from the perspective of open source companies, this model has a completely different implication. Open source companies develop software, grow communities, and build ecosystems. But in the managed service model, a separate company can provide the actual service based on that software. In other words, the company that creates the software and the company that delivers the service can be entirely different. And in most cases, it is the service provider that charges users directly. In this structure, cloud platforms often capture more economic value than the companies that originally developed the software.
At this point, open source companies began to recognize a new reality. Open source was still spreading rapidly, but that growth did not necessarily translate into revenue for the companies behind it. In some cases, cloud platforms were capturing that value even more efficiently. This structural tension eventually became clear through a specific event—the conflict between Elasticsearch and AWS. This case would become one of the most representative examples of how complex the relationship between open source companies and cloud platforms had become.
The Rise of Elasticsearch and Its Explosive Growth
As the new competitive model of Managed Service emerged, open source companies began to find themselves in a different environment than before. However, it was not yet entirely clear what kind of tensions this shift would ultimately create. Many projects were still growing rapidly, and the open source ecosystem continued to expand actively. In this context, one of the most representative projects to emerge was Elasticsearch. This software evolved beyond a simple search engine into a critical data processing platform within modern infrastructure environments. In particular, Elasticsearch began to be recognized as a powerful tool in areas such as log analysis and real-time data search.
Elasticsearch is a distributed search engine built on top of a search library called Lucene. Unlike traditional search systems, which often required complex architectures and high operational costs, Elasticsearch offered a relatively simple API and a scalable architecture. Through a JSON-based REST API, developers could easily index and search data, allowing for rapid adoption. In addition, because it was designed with a distributed architecture from the beginning, it could scale horizontally by adding nodes as data volumes increased. Thanks to these characteristics, Elasticsearch expanded beyond a simple search system into a wide range of data analysis environments. It became a core component in areas such as log collection and analysis, application monitoring, and security event analysis.
The growth of Elasticsearch did not stop at the success of a single piece of software. It led to the creation of an ecosystem known as the ELK Stack, which combined Elasticsearch with Logstash and Kibana. Logstash was responsible for collecting and transforming data from various systems, while Kibana provided visualization tools for data stored in Elasticsearch. Together, these three tools formed a powerful platform for log analysis and data search. As DevOps culture spread, the ELK Stack began to be used almost as a standard tool. Many companies adopted it to analyze service logs and monitor system states.
Behind this growth was the company Elastic. Elastic chose a strategy of expanding its community by releasing the core code of Elasticsearch as open source. At the same time, it built a business model by adding features for enterprise customers. The core search engine was freely available to anyone, while certain features—such as security and advanced analytics—were offered as paid components. This approach is commonly referred to as the Open Core strategy. The core product is open source, but features required in enterprise environments are provided commercially. This strategy allowed Elasticsearch to spread rapidly while also establishing a foundation for acquiring enterprise customers.
However, the success of Elasticsearch was also creating a new situation. Countless companies began using Elasticsearch, and it was becoming a de facto standard tool for data analysis and log processing. In this context, cloud platforms quickly recognized its value. Before long, cloud companies began building new services based on this popular open source software. From that moment on, Elasticsearch was no longer just an open source project—it was placed in direct competition with cloud platforms.
AWS Turns Elasticsearch into a Service
At the time Elasticsearch was rapidly spreading, cloud platforms were also growing at an extraordinary pace. In particular, Amazon Web Services was expanding its range of infrastructure services, enabling companies to operate applications in cloud environments. AWS went beyond simply providing servers and began offering managed services for databases, message queues, analytics platforms, and more. The core idea behind this strategy was to eliminate the need for users to operate complex infrastructure themselves. Companies could focus on application development instead of infrastructure management. This approach proved highly attractive to both developers and enterprises.
Within this trend, AWS launched a managed service based on Elasticsearch: Amazon Elasticsearch Service. This service was designed to allow users to create and operate Elasticsearch clusters with just a few clicks. Users no longer needed to configure servers or manage clusters themselves. By selecting the number of nodes in the AWS console, an Elasticsearch environment could be ready within minutes. Tasks such as scaling, failure handling, and backups were largely automated. This provided significant convenience for companies that had previously operated Elasticsearch in traditional ways.
From the user’s perspective, this service was a highly rational choice. Elasticsearch was a powerful piece of software, but operating it required a significant level of expertise. Managing cluster health, balancing shards, tuning performance, and planning scalability all demanded specialized operational knowledge. However, by using AWS’s managed service, much of this burden could be eliminated. As a result, many companies began choosing AWS’s managed service instead of running Elasticsearch themselves. Developers could focus on building applications, and infrastructure management costs could be reduced.
From Elastic’s perspective, however, the situation looked entirely different. Elasticsearch was software developed over many years by Elastic and its community. Yet AWS was building a commercial service based on that software and selling it. Many users ended up paying AWS instead of Elastic. This situation raised a complex question for open source companies: if another company can generate greater revenue from software we created, where does that leave us?
This case was not simply an instance of one company using another’s software. Open source licenses fundamentally allow such usage. The Apache License does not restrict commercial use and permits anyone to build services based on the code. Therefore, AWS’s actions were legally valid. However, this event clearly revealed the position open source companies occupy in the cloud era. At this point, open source companies began to more clearly recognize the structural challenges they were facing.
The Structural Dilemma Faced by Open Source Companies
The situation between Elasticsearch and AWS was not merely a matter of competition. It was a structural example of the position open source companies occupy in the cloud era. Open source companies develop software, grow communities, and build ecosystems. This process requires significant time and effort. Developers continuously improve features, fix bugs, and advance projects. Companies attempt to build products and acquire customers around these projects. However, in the cloud era, the results of these efforts do not necessarily translate into revenue for the companies that created the software.
Cloud platforms occupy an extremely powerful position. They operate globally distributed infrastructure and are already connected to a vast number of enterprise customers. They also provide a wide range of services and tools within a single platform. Offering open source software as a managed service on top of this platform is relatively straightforward. Since users are already using the cloud platform, adopting additional services is seamless. As a result, cloud platforms often end up closer to users than the companies that originally developed the software.
In this structure, platform companies hold a significant advantage. While software companies develop products and build communities, platform companies can capture the service layer and direct customer relationships. This difference becomes even more pronounced in the Managed Service model, where users do not need to install or operate software themselves. Users simply provision services through a cloud console and pay for them. In this process, the role of the company that created the software may become almost invisible to the user.
This situation raises a difficult question for open source companies. The core philosophy of open source is freedom of use and sharing. However, maintaining that philosophy while building a sustainable business model as a company is becoming increasingly challenging. As cloud platforms began offering services based on open source software, this issue became even more apparent. Ultimately, many open source companies reached the conclusion that maintaining their existing licensing models would no longer be sufficient. And this realization led to a critical decision: changing their licenses. Elastic, too, began reexamining its open source strategy in order to address this challenge.
Elastic’s Choice: Changing the License
The tension between Elasticsearch and AWS did not end as a simple case of competition between companies. Over time, a deeper question began to grow within Elastic itself. The open source strategy had been highly effective in driving the rapid adoption of Elasticsearch. Countless developers began using it, and the community expanded quickly. At the same time, however, more and more companies were building services and generating revenue based on technology created by Elastic. In particular, as cloud platforms began offering Elasticsearch as a managed service, Elastic’s direct touchpoints with customers gradually diminished. In such a structure, there was no guarantee that the company creating the open source project would capture the largest share of economic value.
Elastic began to realize that this problem could not be solved through simple competitive strategy alone. The structure was enabled by the open source license itself. Elasticsearch had long been distributed under the Apache License 2.0, a highly permissive license that places almost no restrictions on commercial use. Anyone could modify and redistribute the code, and it was explicitly allowed to build new services on top of it. This freedom contributed greatly to the growth of the open source ecosystem, but it also enabled cloud platforms to create service offerings based on Elasticsearch. Ultimately, Elastic concluded that this structure could no longer be maintained as it was.
In 2021, Elastic announced a critical decision. It declared that Elasticsearch and Kibana would no longer be distributed under the Apache License. Instead, it introduced new licenses: the Elastic License and SSPL (Server Side Public License). The core objective of this decision was clear—to make it more difficult for cloud providers to take Elasticsearch and offer it as a managed service. In particular, SSPL included a clause requiring companies that provide the software as a service to release the source code of the entire service. In practice, this made it extremely difficult for large cloud providers to build commercial services based on the software.
This decision sparked intense debate within the open source community. Some developers criticized Elastic for undermining the spirit of open source. The core principle of open source is to allow anyone to freely use and extend software, and restricting certain forms of use through licensing was seen by some as contradictory to that philosophy. Others, however, viewed the decision as a pragmatic choice necessary for the survival of open source companies. In a situation where cloud platforms were capturing most of the value, it was argued that it was unsustainable for the company that created the project to compete without any form of protection.
Elastic’s license change carried meaning beyond a simple policy shift. It became a symbolic event demonstrating how open source companies attempt to protect their business in the cloud era. However, rather than resolving the conflict, this decision opened a new phase. Cloud platforms did not simply accept the change—especially AWS, which responded in a highly proactive way.
AWS’s Response: The OpenSearch Fork
When Elastic changed its license, AWS was among the first to respond. AWS had been operating services based on Elasticsearch for a long time, and many customers relied on those services. If AWS were to accept Elastic’s new license, it would become difficult to continue offering Elasticsearch in the same way. The conditions of the SSPL license, in particular, posed a significant challenge for cloud platform companies. Requiring the release of the entire service’s source code was a condition most commercial platforms could not accept. As a result, AWS made a different choice.
AWS decided to start a new project based on the last version of Elasticsearch released under the Apache License. This project was named OpenSearch. OpenSearch began as a fork of Elasticsearch and Kibana, but AWS did not limit it to internal use. Instead, it was developed publicly, with an emphasis on building a community-driven project that others could contribute to. Over time, OpenSearch evolved beyond a simple technical fork into an independent project.
This moment became highly symbolic in the history of open source. The company that created the original project and the platform company providing services based on it diverged in different directions. Elastic changed its license to protect its business, while AWS forked the project to maintain an open source version. This event revealed how complex the relationships within the open source ecosystem had become. It also demonstrated that open source projects do not necessarily evolve along a single path—they can branch into multiple directions when necessary.
The emergence of OpenSearch raised broader questions for the entire open source industry. Who determines the direction of an open source project? Is it the company that created it, or the larger ecosystem that uses it? And how will the participation of cloud platforms in open source projects shape the future? These questions extend far beyond Elasticsearch—they reflect a new reality faced by the entire open source industry.
The Questions This Event Left Behind for the Open Source Industry
The conflict between Elastic and AWS may appear, at first glance, to be a dispute between specific companies. But from a broader perspective, it revealed a structural issue faced by the entire open source industry. Open source projects grow through collaboration between developer communities and companies. However, as a project becomes more successful, more companies begin to build on top of it. Cloud platforms, in particular, are in a powerful position to turn open source technologies into service products. In this process, there is no guarantee that the company that created the project will capture the largest share of economic value.
After the Elastic incident, many open source companies began reexamining their strategies. MongoDB had already introduced SSPL to restrict how cloud providers could offer its software as a service. Redis Labs adopted a similar approach by changing the license of certain modules. Confluent began directly competing with platform providers by offering its own cloud services based on Kafka. CockroachDB introduced a hybrid model combining open source and commercial licensing. All of these changes stem from the same question: how can open source companies build sustainable businesses in the cloud era?
This question is not merely about business strategy—it is deeply connected to the philosophy of open source. Open source has grown based on freedom of use and collaboration. But if that freedom begins to threaten the survival of companies, then a new balance must be found. Some companies chose to change their licenses, others chose to offer their own cloud services, and still others reinforced the Open Core model by clearly separating community and enterprise editions.
Ultimately, the Elastic vs AWS case made one thing clear. Open source remains the foundation of the modern software industry, but the economic structures built on top of it are continuously evolving. As cloud platforms have become the central layer for software distribution and operation, open source companies now face a completely different competitive environment. This shift is not just a technological trend—it is a structural transformation of the software industry. And within this transformation, open source companies continue to search for new strategies. At this point, we are left with another critical question: can open source licenses remain unchanged in the cloud era? In the next article, we will explore this question through another emerging conflict in the open source world—the license wars.
The Uneasy Coexistence of Open Source and the Cloud
The conflict between Elastic and AWS is not simply a story of one project splitting into two paths. It is a symbolic case that reveals how complex the relationship between open source and cloud platforms has become. Open source is deeply embedded across nearly every part of the modern software industry. From operating systems to databases, message queues, and container platforms, most of the infrastructure technologies we use today originated from open source projects. Developers have been able to adopt new technologies quickly thanks to open source, and companies have built services on top of these technologies. In this sense, open source has been a critical foundation that significantly accelerated innovation across the entire software industry.
However, with the rise of cloud platforms, new tensions began to emerge within this structure. Cloud companies actively leveraged open source to build a wide range of services. Technologies such as Kubernetes, Linux, and PostgreSQL became core infrastructure in cloud environments as well. From this perspective, cloud and open source appear to form a mutually reinforcing relationship. Open source projects can reach more users through the cloud, and cloud platforms can rapidly deliver new services using open source technologies. On the surface, this looks like an ideal model of collaboration.
But a closer look reveals that this relationship goes beyond simple cooperation. Cloud platforms are more than just users of software. They operate massive infrastructure and maintain direct relationships with countless enterprise customers. Services provided on these platforms are typically sold under the platform company’s brand. Users may be using technologies like PostgreSQL or Elasticsearch, but the entity they actually pay is the cloud platform. In this process, the company that created the open source project does not necessarily capture most of the value.
This structure forces open source companies into a complex set of choices. On one hand, they must preserve the openness and collaboration of the open source ecosystem. On the other, they must secure a sustainable revenue model as businesses. These two goals can sometimes conflict. If too many restrictions are introduced, the support of the open source community may be lost. If the model remains too open, cloud platforms may absorb most of the value. Elastic’s license change was an attempt to rebalance this tension.
Ultimately, in today’s software industry, open source and the cloud are not separate worlds. They are deeply intertwined, continuously alternating between cooperation and competition. The cloud would not have grown at its current pace without open source, and open source has spread globally through the cloud. Yet this coexistence is far from simple. It is shaped by intertwined factors such as economic interests, technological ecosystems, and platform power. The Elastic vs AWS case was one of the first major moments where this complex relationship became clearly visible.
The Next Chapter: License Wars
As Elastic changed its license and AWS forked OpenSearch, another critical question emerged within the open source ecosystem: can open source licenses continue to function in the same way in the cloud era? For a long time, licenses such as GPL, MIT, and Apache have been widely used in the open source world. These licenses are fundamentally designed to guarantee the free use and sharing of software. Many developers believe that these licenses enabled global collaboration and made countless innovations possible. In fact, a large portion of the internet and cloud infrastructure has been built on top of these open source licenses.
However, in the cloud era, these licenses began to be used in ways that were not originally anticipated. In the past, using software required installing and operating it directly. This allowed the companies that created the software to generate revenue through support or services. But with the emergence of the Managed Service model, the situation changed. Cloud platforms could build services based on open source software and deliver them to users worldwide. In this process, the companies that created the open source projects were not necessarily included in the revenue generated by those services. This structure introduced a new dilemma for many open source companies.
To address this issue, some companies began introducing new licensing models. Licenses such as SSPL include conditions that restrict cloud service providers, while models like BSL impose limitations on commercial use for a certain period. These licenses differ fundamentally from traditional open source licenses. Some argue that such changes undermine the spirit of open source. Others contend that new rules are necessary for open source companies to survive in the cloud era.
This debate extends beyond legal concerns—it is closely tied to the future of the software industry itself. Open source remains a critical foundation for innovation, but the economic models built on top of it continue to evolve. As cloud platforms have become the central layer for software distribution and operation, licenses have taken on a meaning beyond simple legal documents. They have become key instruments that shape the power structure of technological ecosystems. In the next article, we will explore this emerging conflict in greater depth—the license wars of the open source world, examining why new licenses such as SSPL, BSL, and the Elastic License have emerged and what they truly represent.
