How Open-Source Companies Make Money

An open-source company gives away its core product and still has to pay salaries. That sounds like a contradiction, and it is the first question every founder and investor asks about the model. The answer is that the code is rarely the thing being sold. Customers pay for what surrounds the code: someone to run it, support it, certify it, extend it or take legal responsibility for it.

This article explains what "open source" actually means, the main ways companies turn it into revenue, and the tension that pushed several well-known companies to change their licenses between 2021 and 2026. It is a reference on the business model, not legal advice, and it doesn't compare vendors' current prices. For the wider set of ways startups earn money, see SaaS pricing models.

What "open source" actually means

"Open source" is not a loose synonym for "free" or "the code is public." The Open Source Initiative (OSI) maintains the Open Source Definition, a list of ten criteria a license must meet. Three matter most for business models:

• Free redistribution. The license can't stop anyone from selling or giving away the software.
• Derived works. The license must allow modifications and derived works.
• No discrimination against fields of endeavor. The license can't restrict anyone from using the program in a specific field, which in practice includes running it commercially.

That last criterion is where business models collide with the definition. A license that says "anyone may use this, except to sell it as a competing hosted service" is restricting a field of endeavor. It may be a perfectly reasonable commercial choice, but under the OSI's reading it isn't open source. The OSI said exactly this about the Server Side Public License (SSPL) in a January 2021 statement, calling the practice of describing such software as open source deception.

So there are really two camps:

The rest of this article keeps the two apart. The distinction matters for customers (what are they allowed to do?), for contributors (will my work stay open?) and for founders (what can I promise?).

The paradox of giving the core away

If anyone can download, modify and run the product for free, why would anyone pay? Open-source companies answer in one of four ways:

1. Reduce the burden. Running the software well is hard. Customers pay to have someone else operate it.
2. Reduce the risk. Large organizations want a vendor to call, a security response team and a legal guarantee.
3. Add what the free version lacks. Features that matter mainly to big teams (access controls, audit logs, single sign-on) are sold separately.
4. Protect the right to charge. Some companies keep the code open to read but limit who can resell it.

Giving the core away also works as distribution. Developers adopt what they can try without a procurement process, and a company that wins that adoption has an inbound sales channel. This is close to the logic of product-led growth and freemium business models, with one difference: a free user of open-source software can also fork the code, host it themselves and never become a customer.

The main monetization models

1. Support and subscriptions (the Red Hat model)

The oldest model sells assurance around free software. Red Hat is the standard example. IBM's October 2018 announcement of its agreement to acquire Red Hat at $190 per share, an enterprise value of about $34 billion, described the target as a leading provider of enterprise open source software, including Linux, hybrid cloud, container and Kubernetes technologies.

What does a Red Hat customer pay for? Its own subscription FAQ lists patches, bug fixes, updates and upgrades, technical support with 24/7 availability, and hardware, software and cloud-provider certifications. It also states that a customer who lets a subscription lapse loses security errata, bug fixes and technical support. In other words, the product is a maintained, certified, supported version, not the source code itself.

Where it works: infrastructure software that large organizations run in production and can't afford to see break. Where it struggles: sales are slow and heavy, and the model scales with people and trust, not with downloads.

2. Open core

In an open-core company, the base product is open source and a set of additional features is proprietary and paid. The extras are usually the things large organizations ask for: advanced security, governance, scalability tooling, official integrations and dedicated support.

The strategic question is where to draw the line. Put too little in the free version and the community has no reason to adopt it. Put too much in and nobody has a reason to pay. Founders often use a simple test: features that help an individual developer stay free, and features that help an organization coordinate (permissions, compliance, administration) are paid.

The risk is trust. When a company moves a feature from the free tier to the paid tier, the community can read it as a betrayal, and a fork can follow.

3. Managed cloud (hosted service)

Most modern open-source revenue comes from running the software for customers. The company hosts it, handles upgrades, backups and scaling, and charges for usage or capacity. This is the SaaS model applied to an open-source product, and the pricing mechanics are covered in usage-based pricing.

MongoDB shows how large this can get. In its fiscal 2026 results release (fiscal year ended January 31, 2026), MongoDB reported total revenue of $2.46 billion, and its Atlas cloud service accounted for roughly $1.81 billion of that, about 73%. That's one company's fiscal-year figure, not an industry benchmark, and MongoDB's core database is source-available rather than open source (more on that below).

Where it works: products that are painful to operate, so convenience is worth paying for. Where it struggles: anyone with a cloud account can offer the same service, including the largest cloud providers. That's the root of the licensing fights described below.

4. Dual licensing

Under dual licensing, the same code is offered under two licenses. One is a free, usually copyleft license that requires anyone who builds on it to share their own source code under the same terms. The other is a paid commercial license for companies that want to embed the software in a closed product without that obligation.

It works best for libraries and components that other companies embed in their own products. It works poorly for end-user applications, where nobody needs an exemption from the copyleft terms. It also usually requires the company to hold the rights to relicense, which is where contributor agreements come in (see below).

5. Source-available and license changes

A growing group of companies now publishes source code under licenses that restrict commercial use, usually to block competitors from reselling the product as a hosted service. Common examples are the SSPL, the Business Source License and fair-code style licenses. These licenses let customers read, run and modify the code, and let the vendor keep the exclusive right to sell it as a service.

Some of these licenses also convert to a fully open license after a fixed period. This is a way to promise openness eventually while protecting a head start now.

6. Donations, sponsorships and foundations

Not every open-source project is a company. Many are maintained by volunteers, funded by sponsors, or housed in foundations. The Apache Software Foundation, for example, asks significant contributors to sign an individual contributor license agreement so the foundation can defend the project if a legal dispute arises over the software. Foundations give projects neutral governance and legal cover, but they don't pay founders. Commercial companies often grow up around foundation projects and sell support or hosting, which feeds back into models 1 to 3.

Comparing the models

Most real companies combine several. A typical product has a free open core, a hosted version, an enterprise tier and a support option.

The hyperscaler problem and the 2021 to 2026 relicensing wave

Managed cloud is the most profitable model, and it is also the easiest one for a larger competitor to copy. If the license allows it, a cloud provider can host an open-source database or tool, charge for it and contribute little back. Open-source vendors call this "strip-mining."

Several companies responded by changing licenses. Each of the announcements below comes from the company itself.

A few things stand out when you read these announcements together.

The reasons are consistent. Elastic said the change was meant to stop providers from offering its software as a service without contributing back. HashiCorp argued that some vendors benefit from open-source work without contributing. Redis said the majority of its commercial sales were channeled through the largest cloud service providers.

Honesty about the label matters. Redis stated plainly that its new licenses don't meet the OSI definition and that it would call the free version "Community Edition" instead of open source. The OSI has taken the same view of the SSPL.

Reversals happen. Elastic and Redis both later added the OSI-approved AGPL as an option. Redis said its earlier change had hurt its relationship with the community, and Elastic said its move had been driven by concerns about Amazon's practices but that the situation had since changed. For a founder, the lesson isn't that one license is right. It's that a license change is a business decision with a community cost that can last for years.

Some licenses include a clock. Directus says every version of its software becomes fully open source under GPLv3 after four years, and under its thresholds, organizations below $5 million in annual revenue and 50 employees can use it free. A time-delayed license tries to protect the vendor now while honoring the open-source promise later.

Community versus revenue: the core tension

Commercial open-source companies live with a permanent conflict. The community wants stable, free, permissively licensed software. Investors and employees want revenue that grows. Every monetization decision shifts the balance.

Some practical pressure points:

• Feature gating. Moving an existing feature behind a paywall breaks an unwritten promise to users and contributors.
• Governance. If one company controls the roadmap, outside contributors may drift away. A foundation gives neutral control but takes some away from the company.
• Forks. If a license change angers enough of the community, a fork can appear under a permissive license. The fork keeps the old code and may attract the cloud providers the company was trying to block.
• Trademark. Even when the code is free to copy, the name usually isn't. Redis, for example, now limits use of "Redis" in other products' names under its trademark policy.

Contributor license agreements

A contributor license agreement (CLA) is a document in which a contributor grants a project the rights it needs to use their contribution. Foundations use them for legal clarity, as the Apache Software Foundation's ICLA rationale shows.

For a company, a CLA has a second purpose: it makes it possible to change the license later or sell the code under a commercial license, because the company holds the rights it needs. Redis, for instance, said it requires contributors to accept its CLA before it will consider their contributions.

Contributors sometimes see CLAs as a one-way street. A company that wants to keep community goodwill should be clear about why it requires one and what it promises in return.

What this means for a startup

If you're considering an open-source business model, a few questions are worth working through early.

1. What are customers paying for if the code is free? Convenience, risk reduction, features or permission. If you can't name it, you don't have a business model yet.
2. Who could resell your product? If the answer is "any cloud provider," choose your license with that in mind from the start, because changing it later is costly.
3. How will you earn the community's trust? Decide what you will never move behind a paywall, and write it down.
4. Do you understand the economics? Free users cost money to serve and support. Track unit economics for the paying segment, not the total download count.
5. Is there a moat beyond the code? Brand, hosting expertise, ecosystem and data can matter more than the license. The economic moat article covers this idea in detail, and network effects can apply when a large developer community makes the product more valuable.

Early-stage teams in particular should compare this model with other options, such as platform business models, before committing.

Practices around licensing and contributor agreements vary by country and by investor, so founders should get legal advice for their own situation. We haven't found a reliable comparative source for open-source business practices in Southeast Asia specifically.

Key Facts

• The OSI's Open Source Definition has ten criteria and was last modified in 2007. One of them bars restrictions on fields of endeavor.
• The OSI stated in January 2021 that the SSPL is not an open-source license.
• IBM announced in October 2018 that it would acquire Red Hat at $190 per share, about $34 billion in enterprise value.
• Red Hat's subscription FAQ lists patches, updates, support and certifications as what a subscription provides.
• MongoDB's Atlas service generated about 73% of its $2.46 billion revenue in fiscal 2026.
• Elastic moved to SSPL in January 2021 and added AGPL in August 2024.
• HashiCorp adopted BSL 1.1 in August 2023.
• Redis went source-available in March 2024 and added AGPLv3 in May 2025.
• NocoDB and Directus both moved to source-available licenses in 2026.
• A source-available license isn't OSI open source, even when the code is public.

Related Reading

• Freemium Business Models
• Product-Led Growth
• Economic Moat
• Hardware Startup Business Models
• SaaS Pricing Models
• Platform Business Model