The Open Source Business Model

Abstract

Richard Stallman freed software to create freedom, not an industry. Yet from his GPL grew an ecosystem worth billions. The history of the open source business model is the history of a question that still has no satisfying answer: how do you build a company on something you give away for free?

Richard Stallman and the Birth of Copyleft

By 1983, software was increasingly proprietary. Vendors shipped only binaries. Source code was a trade secret. Whoever found a bug could not fix it themselves; they had to wait for the vendor to react. Or pay.

Richard Stallman, then a programmer at the MIT AI Lab, experienced this shift as moral decay. He had known a world in which programmers shared code as a matter of course, improved it together, passed it on. That world was disappearing. Stallman’s reaction was not resignation; it was radicalism.

In September 1983 he announced the GNU Project: a complete free Unix-compatible operating system. In 1989 came the instrument meant to secure his approach legally: the GNU General Public License (GPL).

The GPL was a legal sleight of hand. It used copyright (the instrument for controlling software) to enforce exactly the opposite: freedom. Whoever distributed GPL software had to ship the source code. Whoever modified GPL software and passed it on had to release the modified work under the GPL as well. The copyleft principle: freedom propagates like a virus, which is why critics call it a “viral license model” and supporters call it a stroke of genius.

Stallman’s vision was explicitly anticommercial. Software should be free as in free speech, not as in free beer, though in practice it was often both.

Linux: The Collaborative Wonder

In 1991, Linus Torvalds, a student in Helsinki, wrote an email to the newsgroup comp.os.minix:

“I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu)…”

He was wrong.

The Linux kernel became the most successful collaborative software project in history. What began as a Finnish student’s hobby project today runs on roughly 96% of the top million web servers, on 100% of the top 500 supercomputers, on billions of Android devices, in the data centers of Amazon, Google, and Microsoft.

Torvalds initially chose his own license and switched to the GPL in 1992. The decision mattered: it prevented companies from taking Linux, improving it, and making closed derivatives. Every improvement had to flow back.

The development process was anarchic and worked anyway: thousands of developers worldwide, coordinated over mailing lists, without central organization, without paid management. Patches were discussed, rejected, refined, accepted. Quality was high. The speed surprised everyone.

What nobody had foreseen: companies began paying to contribute to Linux. For years, the largest blocks of kernel commits have come from corporate engineers: Intel and Red Hat at the top, followed by IBM, Google, and Samsung. The companies do not pay for the code; they pay for influence over direction, for early access to new features, for the ability to support their hardware optimally.

Red Hat: The First Billion-Dollar Open Source Company

Red Hat answered the question “how do you make money with free software?” pragmatically: not with software, but with service, support, and certification.

Bob Young and Marc Ewing founded Red Hat in 1993. Their product was not proprietary software; it was a validated, stable, enterprise-grade distribution of Linux, combined with subscriptions for support, patches, security updates, and certifications. Companies did not pay for Red Hat Enterprise Linux itself (the source code was freely available); they paid for the guarantee that someone would answer when the kernel crashed at 3 a.m.

Proof that the model works came in 2019. IBM bought Red Hat for 34 billion dollars, the largest software acquisition in history to that point. A company that had never sold a byte of proprietary code was worth 34 billion.

The Red Hat model had an elegant logic: the source code is free, the know-how is expensive. Whoever needs support pays. Whoever does not downloads a free RHEL-compatible rebuild (long CentOS, today Rocky Linux or AlmaLinux) and stays in the Linux ecosystem anyway.

Info

The three license families at a glance:

Permissive licenses (MIT, Apache 2.0, BSD): “Do what you want.” Source code may be used, modified, and integrated into proprietary products without derivatives having to be open. The only obligation: keep the copyright notice. The entire macOS and iOS kernel is based on BSD-licensed code. React (MIT), Android (Apache 2.0), Kubernetes (Apache 2.0).

Copyleft licenses (GPL, LGPL, AGPL): “Derivatives stay open.” Whoever modifies GPL software and distributes it must publish the source under the GPL. The AGPL sharpens this: whoever offers GPL software over a network (i.e., builds a SaaS product) must also disclose the source. Linux kernel: GPL v2. WordPress: GPL v2.

Business Source License (BSL / BUSL): “Open, but not for competitors.” Code is visible and modifiable but may not be used in competing commercial products, typically for four years, after which it automatically converts to a permissive license. Developed by MariaDB (2016), adopted by CockroachDB (2019) and HashiCorp (2023), among others. (Elasticsearch switched to the SSPL in 2021, not the BSL.)

Dual Licensing: MySQL and the Commercialization of the GPL

MySQL found another way. The database was GPL-licensed, free for anyone building open source software themselves. But whoever wanted to embed MySQL in proprietary software needed a commercial license.

The dual licensing model was a lever: the GPL forced proprietary users to either open their code or pay. Whoever wanted to pay bought a commercial license from MySQL AB. Money flowed back from those who profited most from the software without wanting to contribute to the community.

Sun Microsystems bought MySQL in 2008 for a billion dollars. Oracle acquired Sun in 2010, and with it MySQL. The community reacted nervously: Oracle was the direct competitor in the database market. Would Oracle strangle MySQL?

Michael “Monty” Widenius, MySQL’s founder, had taken precautions: he had kept MySQL under the GPL. That meant he could fork the project. MariaDB was born: compatible, independent, community-controlled. MySQL lives on under Oracle; MariaDB lives as the counter-model. The fork worked because the GPL allows it.

Qt, the GUI framework from Nokia (later The Qt Company), followed the same dual licensing principle: LGPL for open source projects, a commercial license for proprietary applications.

The Cloud Crisis: When Amazon Presented the Bill

The dual licensing model had an implicit assumption: whoever uses the software commercially pays. That assumption did not survive the cloud.

AWS, Google Cloud, and Azure began offering popular open source databases as managed services: Amazon ElastiCache (Redis), Amazon Elasticsearch Service (Elasticsearch), Amazon DocumentDB (MongoDB-compatible). The cloud providers paid nothing to the original developers. They did not have to: permissive and GPL licenses did not require it.

Elastic, the company behind Elasticsearch and Kibana, lost millions of potential customers to Amazon, to a product Amazon’s own engineers had built with Elasticsearch source code. In 2021, Elastic acted: it switched Elasticsearch and Kibana from the Apache 2.0 license to the Server Side Public License (SSPL), an AGPL variant that explicitly targets cloud providers: whoever offers Elasticsearch as a service must disclose the entire source code of their infrastructure. Practically impossible for AWS.

AWS answered: it forked Elasticsearch at the last Apache 2.0 state and launched OpenSearch: community-maintained, permissively licensed, hosted directly at AWS. Elastic had not stopped Amazon. It had given Amazon a reason to maintain its own fork.

HashiCorp (Terraform, Vault, Consul) repeated the pattern in 2023: a switch from the Mozilla Public License to the Business Source License. The community responded with a fork: OpenTofu, adopted by the Linux Foundation. Within months, OpenTofu had several major cloud providers behind it.

The pattern was always the same: license switch → community outrage → fork → two parallel projects.

Dead End: Open Core

Warning

The promise of the open core model, and why it structurally breaks

Open core was supposed to be the perfect synthesis: the core is open, enterprise features are proprietary. Users get a free entry point, companies pay for advanced functionality. Everyone wins.

In practice, open core creates a permanent tension. The community wants features in the open source core. The company wants to keep features in the proprietary tier. Every feature decision is simultaneously a commercial decision. Developers notice.

GitLab struggled for years to justify the line between CE (Community Edition) and EE (Enterprise Edition). Features migrated between tiers, sometimes in both directions, under community pressure. Trust suffered.

Confluent (Apache Kafka, commercialized) had to watch AWS build Amazon MSK (Managed Streaming for Apache Kafka) as a direct competitor, with the same open source components, without paying Confluent a cent.

The structural problem: open core works as long as no cloud provider offers the open side as a service itself. Once that happens, the company loses its main sales channel to a competitor with unlimited infrastructure resources. The alternative (making more features proprietary) undermines the community adoption that was the differentiator against purely proprietary software in the first place.

Open core is not a dead model. But it is a fragile equilibrium that requires constant recalibration and offers no permanently stable solution.

Legacy

Stallman wanted freedom. Torvalds wanted a good operating system. Red Hat wanted to build a company. Amazon wanted to sell services. All of them got what they wanted, and together they created an ecosystem that carries the entire digital infrastructure of the world.

The GPL could not prevent commercial actors from using free software. It only forced improvements to flow back, at least in theory. In the cloud era, where code is not “distributed” but offered as a service, even the AGPL no longer reliably applied.

What remains: open source has won, as a development model, as a quality guarantee, as a community coordination mechanism. As a business model it remains an experiment in permanent imbalance: who carries the costs when everyone profits from the commons?

The answer taking shape is not a license. It is a question of power: which actors have the resources to maintain a fork? Which have the infrastructure to host it? Which have the market power to pull users there? In that question lies the real tension defining open source in the 21st century.