The Deal That Should Have Killed Red Hat
In the mid-1990s, a small company decided to package Linux, a free operating system, put it in a box, and sell it. The joke was obvious: who pays for something you can get for free? Competitors laughed. IBM certainly wasn’t worried. Then Red Hat signed a deal with IBM in 2019 for $34 billion, the largest software acquisition in history at the time. The free software company had become more valuable than most of the proprietary vendors it had supposedly been disadvantaged against.
This was not an anomaly. It was the first clear signal that the conventional wisdom about open source, which held that giving away your product was a charitable act incompatible with serious business, had it exactly backwards.
What ‘Free’ Actually Means in a B2B Context
The consumer software world taught us to be suspicious of free products. The adage holds that if you’re not paying, you’re the product. That logic doesn’t transfer cleanly to enterprise software, and conflating the two has confused a lot of people about why open source companies can be so profitable.
When a Fortune 500 company adopts an open-source database, they aren’t being monetized through their attention or their data. They’re making a procurement decision that reduces vendor lock-in and lowers their initial barrier to adoption. The ‘free’ part is the hook, not the business model. The business model is everything that happens after the hook lands: support contracts, managed cloud services, enterprise security features, compliance tooling, and the professional services organizations need to run software at scale.
HashiCorp built this case study in plain sight. Terraform, their infrastructure-as-code tool, became the de facto standard for cloud provisioning because anyone could download and use it without a purchase order. Once it was embedded in thousands of engineering workflows, HashiCorp had extraordinary leverage to sell Terraform Cloud, enterprise support, and the broader stack. The open-source distribution did the sales work that a traditional sales team would have done, except it scaled infinitely and cost almost nothing to deploy.
The Real Moat Is the Community, Not the Code
Proponents of traditional software licensing have always assumed the moat is the code itself. Keep it proprietary, keep competitors out, extract rent from the people who need access. This made sense in a world where software was genuinely hard to write and alternatives were scarce.
What open source companies figured out is that in mature software categories, the code eventually commoditizes. The moat that doesn’t commoditize is the community built around it. When tens of thousands of engineers learn Kubernetes, write about it, answer Stack Overflow questions, build integrations, and recommend it to their companies, you have created a distribution advantage that no amount of paid marketing can replicate.
This is why Red Hat could charge enterprise customers substantial amounts for something technically available for free. The value wasn’t in the bits. It was in the support, the certification, the liability coverage, and critically, the talent pool of engineers who already knew how to operate it. An enterprise running Red Hat Enterprise Linux wasn’t paying for Linux. They were paying for a managed relationship with the people who understood Linux most deeply.
The same logic applies to Elastic, MongoDB, and Confluent. Each built enormous communities around open-source projects before building commercial products layered on top. The community doesn’t just generate goodwill. It generates pipeline.
The Cloud Providers Accidentally Validated the Model
Around 2018, a specific tension emerged that clarified the economics better than any business school case study could. Amazon, Google, and Microsoft began offering managed versions of popular open-source databases and tools as cloud services, sometimes generating significant revenue without contributing proportionally back to the projects. MongoDB, Redis Labs, and Elastic all responded by changing their licenses to restrict cloud providers from commercializing the software without contributing back or paying.
The community reaction was fierce, with many developers arguing these companies were betraying open-source principles. The business reality was more interesting. The license changes confirmed something that the open-source vendors had quietly understood: the managed service layer, the operational abstraction on top of open-source software, was where most of the commercial value lived. AWS could offer Amazon DocumentDB (a MongoDB-compatible service) precisely because MongoDB had done the work of making document databases the standard. The open-source project had created the market; the cloud provider was trying to capture value from a market it hadn’t built.
This conflict clarified the actual business model. The code is a market-creation tool. The service layer is the business. Every enterprise that runs self-hosted open-source software and hits an operational problem is a potential customer for the managed version. The community that was built on free access to the code becomes the qualified lead pool for the commercial product.
Why the Unit Economics Beat Traditional Software
A conventional enterprise software company spends heavily on sales and marketing before a customer ever touches the product. Analysts have to be courted, proof-of-concept evaluations have to be managed, pilots have to be structured. It is expensive to acquire customers who have never seen your product work.
Open-source companies have inverted this. By the time a company’s procurement team is evaluating an open-source vendor’s commercial offering, their engineers have often already been running the free version in production for months or years. The sales conversation isn’t ‘let us show you what this can do.’ It’s ‘you already know what this can do; here’s what you get when you pay us.’
This compresses sales cycles and changes the nature of the sales motion. You’re not convincing someone to try something unfamiliar. You’re converting someone already committed to the technology into a paying customer. The result is meaningfully lower customer acquisition costs relative to the contract values these deals generate.
Confluent, the company built around Apache Kafka, went public with revenue growing at rates that most proprietary software companies would envy, largely because the open-source version of Kafka had already penetrated deeply into the companies Confluent was selling to. The open-source project was doing the marketing.
The Pricing Power Nobody Talks About
Here’s the counterintuitive part. Open-source companies often have more pricing power with enterprise customers, not less, because the alternative to paying them is not paying a competitor. The alternative is running the open-source version yourself, which means staffing the engineering and operations work internally. For most enterprises, that cost calculation favors paying the vendor.
This is a structurally different competitive dynamic than traditional software faces. A CIO considering whether to renew a proprietary software license is weighing the price against switching to a competitor. A CIO considering whether to pay for an open-source vendor’s managed service is weighing the price against the internal cost of doing it themselves. That’s a comparison the vendor can often win, especially as software infrastructure grows more complex and internal talent grows more expensive.
The pricing design that enterprise software companies use typically anchors on feature differentiation. Open-source vendors anchor on operational risk and internal cost. That’s a more durable anchor for large contracts, because operational risk is genuinely expensive and hard to quantify.
The Model Has Real Limits
None of this means every open-source project becomes a billion-dollar company. The model requires a few specific conditions to work.
First, the open-source project has to actually become a standard. Projects that don’t achieve widespread adoption never build the community that makes the commercial flywheel spin. Most don’t. The graveyard of open-source projects that raised venture capital on the premise of eventually monetizing community is substantial.
Second, the commercial layer has to be genuinely differentiated from the free version. When companies fail to build a compelling managed service, they end up with a lot of community goodwill and not much revenue. The free product has to create the market; the paid product has to solve a distinct problem within that market, usually operational scale, security, or compliance.
Third, the open-source license matters more than founders often appreciate. Choosing the wrong license, or changing it later as many companies did under pressure from cloud providers, creates community damage that can take years to recover from. The license is not just a legal document. It’s a signal about the relationship between the company and the community that made it viable.
What This Means
The profitability of open-source enterprise software is not a paradox once you understand what’s actually being sold. The code is a distribution mechanism and a community-building tool. The business is everything enterprises need to run that code safely, at scale, with someone on the hook when it breaks.
The companies that understood this earliest, Red Hat, MongoDB, Elastic, HashiCorp, Confluent, built positions that proprietary competitors couldn’t easily attack, because competing with them meant competing with a community, not just a product. You can out-feature a product. You can’t easily out-community a standard.
The older software licensing model treated code as the scarce resource worth protecting. Open source inverted the scarcity: the code is abundant, but deep operational expertise and managed reliability at enterprise scale are genuinely scarce. That’s where the value went, and that’s where the margins followed.
