• Home  
  • Open Source Business Models: Who Gets Paid When the Code Is Free
- Business

Open Source Business Models: Who Gets Paid When the Code Is Free

Support, open core, hosting, dual licensing: how Red Hat, GitLab, MongoDB and others make money, and what the licence wars settled.

Close-up of a computer screen showing lines of colourful source code

On August 10, 2023, HashiCorp announced that future releases of Terraform, the infrastructure-as-code tool used by a huge share of the cloud industry, would no longer be open source. The new Business Source License let most people keep using it for free, but barred anyone from building a competing commercial product on it. Within six weeks, a group of companies had forked the last open version, and the Linux Foundation had taken the fork, called OpenTofu, under its wing. Eighteen months later, IBM closed its $6.4 billion purchase of HashiCorp, ending one of the most closely watched tests of open source business models.

That sequence captures the central tension. Giving your code away builds adoption faster than any sales team could. It also means anyone, including a cloud giant with a bigger sales team, can sell your work back to your customers.

Founders building on open source in 2026 have more case studies to learn from than ever, and several of them now run in both directions: companies that closed their licences and then reopened them. Here’s how the main models work, who has made money with each, and what the license wars of the last few years actually settled.

Open source business models: why free code can still pay

Open source is a distribution strategy before it is a business model. A developer can download your database and ship it to production without ever talking to you. That’s a huge advantage when your buyer hates sales calls. It also means you must charge for something the free version doesn’t provide.

Broadly, companies have settled on four answers:

  • Support and subscriptions: the software is free; certified builds, updates and help are not.
  • Open core: the core is open; features that larger organizations need are proprietary.
  • Hosted or managed service: you run the software for customers as a cloud product.
  • Dual licensing: the code is available under a copyleft licence, and you sell a commercial licence to those who can’t or won’t accept its terms.

Most successful companies mix several. The question is which one carries the revenue.

Support and subscriptions: the Red Hat playbook

Red Hat proved that open source could build a large public company. It sold subscriptions to Red Hat Enterprise Linux that bundled certified builds, security updates, and support, and in fiscal 2012 it became the first open-source company to pass $1 billion in annual revenue. IBM bought it in 2019 for $34 billion, its largest acquisition ever, and still runs it as a separate unit.

The model works because enterprises buy predictability, not code. A bank running thousands of Linux servers wants someone accountable when a kernel bug lands at 2 a.m., plus a long support window and compliance paperwork. Those things are hard to fork.

Here’s the catch: the code itself is always one rebuild away from a free clone. For years, CentOS offered a no-cost rebuild of RHEL. In June 2023, Red Hat stopped publishing RHEL sources on its public git server and pointed everyone to CentOS Stream instead, which cut off easy one-to-one rebuilds by projects like Rocky Linux and AlmaLinux. Both projects kept going, but the episode showed how much pressure a pure support model is under when the product is identical to the free copy.

Open core: GitLab’s tiered bet

Open core is probably the most common model for venture-backed open-source startups. The core product is open source; features aimed at managers, security teams, and compliance officers sit in paid tiers.

GitLab is the textbook example, partly because it writes down its reasoning in public. Its handbook describes a “buyer-based” model: features go into the tier whose buyer cares most about them. Individual developers get the free tier. Features that team managers care about, like merge approvals, go into Premium. Portfolio management, advanced security testing and compliance tools go into Ultimate, for executives. When GitLab isn’t sure where something belongs, its stated default is to put it in the lower tier.

The approach has scaled. GitLab reported revenue of $955.2 million for fiscal 2026, up 26%, with 1,456 customers paying more than $100,000 a year, and said it crossed $1 billion in annual recurring revenue during the year.

The open-core trap

Open core has a built-in conflict. Every useful feature you add to the free edition is one you can’t sell. Every feature you hold back makes the community edition less attractive, and invites someone else to build it in the open. The companies that handle this best set rules in advance, as GitLab does, rather than deciding feature by feature under quarterly pressure.

Rack of server hardware with status lights in a dark server room
Running the software for customers has become the main revenue engine for many open-source companies. Photo: Tyler / Unsplash

Hosted services, and the cloud provider problem

For databases and infrastructure software, the strongest model in the past decade has been running the software for customers. MongoDB is the clearest case. Its managed cloud database, Atlas, made up 73% of total revenue in fiscal 2026, up from 66% two years earlier. Total revenue for the year reached $2.46 billion, and the company counts more than 65,200 customers.

The trouble is that hosting is also what the big cloud providers do best. If your software is under a permissive licence, Amazon, Google or Microsoft can offer it as a managed service, integrate it with their billing, and capture much of the value without contributing much back. That fear drove nearly every licence change of the last eight years.

The license wars: MongoDB, Elastic, HashiCorp and Redis

Starting in 2018, a string of well-known companies moved away from standard open-source licences to “source-available” ones that restrict competing commercial use. Several of them have since partly reversed course. The current state, as of late 2026:

Company Change Where it stands now
MongoDB Moved Community Server from AGPL to its own SSPL in October 2018 Still SSPL; not approved by the Open Source Initiative
Elastic Moved Elasticsearch and Kibana from Apache 2.0 to SSPL and Elastic License in 2021 Added AGPLv3 as an option in August 2024
HashiCorp Moved Terraform, Vault and others from MPL 2.0 to BSL 1.1 in August 2023 Still BSL under IBM ownership; OpenTofu fork thrives
Redis Moved from BSD to RSALv2 and SSPLv1 in March 2024 Added AGPLv3 with Redis 8 in May 2025

MongoDB and the SSPL

MongoDB wrote the Server Side Public License specifically to target cloud providers: anyone offering the database as a service must release the source of their entire service stack. MongoDB submitted it to the Open Source Initiative and then withdrew it once approval looked unlikely. The OSI has since stated plainly that the SSPL is not an open source licence. MongoDB’s own annual report still lists that status as a risk to adoption. And yet the business has grown well. The licence may have mattered less than the quality of Atlas.

Elastic’s round trip

Elastic’s 2021 relicensing came after a public feud with AWS, which responded by forking Elasticsearch into OpenSearch under Apache 2.0. Three years later, Elastic added the AGPL as a third licensing option, alongside SSPL and the Elastic License, making the code open source again by the OSI definition. Founder Shay Banon argued the AGPL would broaden adoption, particularly in vector search. OpenSearch did not disappear; it now has its own home, the OpenSearch Software Foundation.

HashiCorp, OpenTofu and IBM

HashiCorp’s BSL converts each release back to the open MPL licence four years after publication, which softens the blow for long-term users. It didn’t stop the fork. OpenTofu was accepted by the Linux Foundation in September 2023, backed by companies such as Spacelift, Gruntwork, env0 and Scalr, and shipped a drop-in replacement in January 2024. IBM announced its deal in April 2024 and closed it in February 2025. HashiCorp’s licence FAQ shows no change since the acquisition, so Terraform remains source-available under IBM. The irony: IBM also owns Red Hat, a firm built on the opposite philosophy.

Redis returns to open source

Redis’s March 2024 switch triggered the fastest fork of all. Within weeks, the Linux Foundation launched Valkey, based on the last BSD-licensed version and backed by AWS, Google, Oracle and others. By 2025, Redis had changed course. CEO Rowan Trollope announced AGPLv3 as a licensing option starting with Redis 8, helped along by the return of the project’s creator, Salvatore Sanfilippo. Meanwhile, Valkey reached version 9.0 in October 2025 and is now sold as a managed service by AWS, Google Cloud and Oracle.

The pattern is hard to miss. Relicensing rarely stops a well-funded competitor; it mostly creates a fork and burns community goodwill. The AGPL, which forces anyone who runs modified code as a network service to share their changes, has become the compromise that lets companies protect themselves while still calling their software open source.

Dual licensing: the old model that still works

Dual licensing predates all of this. The company releases code under a copyleft licence like the GPL and sells a commercial licence to customers who want to embed it in proprietary products without releasing their own source. MySQL made this famous. Today, the Qt Group, the Finnish company behind the Qt application framework, offers Qt under LGPL and GPL or under a paid commercial licence, and forbids mixing the two within the same project. The commercial licence buys freedom from copyleft obligations, plus support and some extra tools.

Dual licensing has a strict requirement: you must own the copyright to all the code, or have contributors sign agreements that let you relicense their work. That makes it awkward for projects with large outside communities. Contributor licence agreements are also exactly what enabled the relicensing moves above, which is why some developers now refuse to sign them.

Hand holding a pen while signing a document at a desk
Dual licensing depends on owning the copyright. Photo: Scott Graham / Unsplash

A Canadian example: open source as a wedge

Toronto-headquartered Tailscale shows a quieter variant. The core client code for its mesh VPN is open source, but the hosted coordination server that manages devices and access policies remains proprietary as part of the paid managed service. The approach has attracted serious capital, including a $160 million Series C led by Accel in April 2025. A community-built open-source coordination server, Headscale, exists for people who want to self-host. Rather than fighting it, Tailscale employs a developer who helps maintain it, which says something about where the company believes its value really sits: in running the service well, not in owning every line of code.

Choosing a model: practical questions for founders

If you’re building a company on open-source code, the licence is a business decision you’ll live with for years. Some questions worth answering before you publish your first release:

  1. Who is your buyer? If it’s a developer, keep the free product genuinely useful. If it’s a CISO or a CFO, open core with governance features in paid tiers can work.
  2. Can you run it better than anyone else? If yes, a managed service may be your best revenue engine, as Atlas was for MongoDB. If a hyperscaler could run it just as well, consider a copyleft licence such as the AGPL from day one.
  3. Do you own the copyright? Dual licensing and future relicensing both depend on it. Decide early whether you will ask for contributor agreements.
  4. What will you promise publicly? GitLab’s written rules about what stays free are a trust asset. Changing licences later costs more goodwill than choosing a restrictive one at the start.
  5. What happens if you get forked? OpenTofu, OpenSearch and Valkey all show that a well-backed fork can arrive within weeks. Your moat has to be the product, the service and the team, not the licence.

This isn’t legal advice, and licence choices have real consequences for contributors and customers. Talk to a lawyer who knows open-source licensing before you commit.

The broad lesson from the last few years is simple enough. Open source gets you adopted. Something else has to get you paid, whether that’s support, hosting, enterprise features or a commercial licence. The companies that struggled were the ones that tried to make the licence do the work of the business.

Sources and further reading

Leave a comment

Your email address will not be published. Required fields are marked *

Sign Up for Our Newsletter

Get our best reporting on Canadian tech and startups in your inbox twice a week. Free, and you can unsubscribe anytime.

Email Us: [email protected]

Call: +1 (416) 555-0147

Suite 704, 120 Adelaide Street West, Toronto, ON M5H 1T1, Canada

© 2026 Texcovery Media. All rights reserved.