The Open Core Business Model Explained, With Examples
Open core means the main product is open source, while a company sells proprietary features, usually for larger organizations: single sign-on, audit logs, advanced permissions, compliance and support. GitLab is a well-known example, with a free community edition and paid enterprise tiers.
What is the open core business model?
In open core, one codebase is published under an open-source licence and anyone can run it. A second layer of features is kept proprietary and sold under a commercial licence or as part of a paid subscription.
The open part drives adoption: developers try it without asking procurement, and a community grows around it. The paid part targets the buyer who has a budget, typically a company that needs security, governance and scale.
The model works when the free edition is genuinely useful and the paid features matter mostly to organizations, not to individual users.
GitLab is the textbook case: its core is open source and it sells higher tiers with enterprise features. Many developer infrastructure companies follow a similar split, often combined with a hosted cloud offering.
Mattermost and Metabase are other commonly cited products with an open-source edition and paid editions aimed at companies. Details of which features sit where change over time, so check each project’s current edition comparison and licence files rather than relying on old summaries.
How does open core compare with other open-source models?
| Model | What is paid | Example | Main trade-off |
|---|---|---|---|
| Open core | Proprietary enterprise features | GitLab | Constant debate about which features belong in the free edition |
| Hosted cloud (managed service) | Running it for you | Supabase, Plausible | Competes with self-hosting and with cloud providers |
| Dual licensing | Commercial licence instead of copyleft | MySQL, Qt | Needs copyright ownership of all contributions |
| Support and services | SLAs, consulting, training | Red Hat’s subscription model | Revenue scales with people, not software |
| Source-available licence | Rights to use in competing services | Licences such as BSL or SSPL | Not open source by the OSI definition; can split the community |
What should be free and what should be paid?
A common rule is to ask who cares about a feature. If an individual developer or small team needs it to get value, keep it open. If mainly a manager, security team or compliance officer needs it, it can be paid.
Typical paid features are single sign-on and SCIM provisioning, audit logs, fine-grained roles, data retention policies, high availability setups, multi-tenant administration and priority support. These are painful to build, rarely needed by hobbyists and important to enterprises.
- Keep free: core functionality, APIs, integrations the community depends on, basic auth, self-hosting docs.
- Make paid: SSO and SCIM, audit logs, advanced RBAC, compliance reports, clustering and HA, premium support.
- Decide case by case: analytics dashboards, advanced workflow features, AI features with real running cost.
How do you set up open core step by step?
- Pick a licence for the core; permissive licences grow adoption fastest, copyleft licences such as AGPL make it harder for others to resell a closed fork.
- Decide how you will keep paid code separate: a separate repository, a separate directory with its own licence, or plugins.
- Require a contributor agreement or DCO so the project’s licensing stays clear.
- Write a public edition comparison page and a policy explaining how you decide what is paid.
- Build a licence key or entitlement check that is simple and does not break the free edition.
- Add a hosted cloud option once self-hosted demand proves the market; many buyers prefer not to operate it.
Where does open core break?
The biggest risk is the free edition feeling crippled. If the community sees useful features moved behind a paywall, contributors leave and forks appear.
The opposite risk is giving away so much that no organization needs to pay. Then the company either drifts toward hosting or changes the licence.
Licence changes are the most visible failure mode. Elastic moved Elasticsearch away from Apache 2.0 in 2021, and HashiCorp moved Terraform to the Business Source License in 2023, which led to the OpenTofu fork. Both show that changing terms later has community costs.
Common mistakes with open core
Say it early and in writing. A public page that explains the business model, lists what is in each edition and states the principles for future decisions prevents most of the anger that surprises cause.
Commit to things you can keep, such as never moving an existing open feature behind the paywall. Breaking such a promise does more damage than never making it.
Invite feedback when a feature’s placement is unclear. Community members often accept a paid feature once they understand who it is for and see that the free edition keeps improving.
- Paywalling features that individual users need, which kills adoption.
- No clear, published rule for what goes into which edition.
- Accepting outside contributions without a contributor agreement, then being unable to relicense or dual-license.
- Maintaining two codebases that drift apart instead of one core with an extension layer.
- Ignoring the hosted option, where many buyers would happily pay.
- Treating the community as a free marketing channel rather than as users with their own needs.
Is open core right for your project?
Open core fits infrastructure and team tools where enterprise buyers have clear extra needs. It fits poorly for small libraries or single-user tools, where there is no natural enterprise layer.
If your users mostly want the software run for them, a hosted cloud model may be simpler. If they embed your code in their own products, dual licensing may fit better. Many companies end up combining two of these models.
How do open-core companies structure the code?
There are two common layouts. In the first, the paid features live in the same repository under a separate directory with its own licence, and the build includes or excludes them. GitLab has long used this style, with a community edition and enterprise edition built from shared code.
In the second, the core is published alone and paid features ship as closed plugins or services that connect through documented extension points. This keeps the public repository clean but requires stable internal APIs.
Either way, the core should be buildable and usable without any proprietary code. If the free edition only works with paid modules installed, users will notice quickly.
| Layout | Pros | Cons |
|---|---|---|
| Single repo, licensed folders | One codebase, easy refactoring across editions | Contributors may see code they cannot use freely |
| Core repo plus closed plugins | Clear separation, clean open repository | Needs stable extension APIs and more release coordination |
| Core open, cloud-only extras | Paid parts never ship as code | Self-hosting enterprises cannot buy those features |
How does open core make money in practice?
Revenue usually arrives as annual subscriptions per user, per node or per instance for the enterprise edition, often bundled with support. A hosted cloud version adds a second stream for customers who do not want to run the software.
The sales motion is typically bottom-up. Engineers adopt the free edition, usage spreads across teams, and the company is approached when security or IT asks for SSO, audit trails and a support contract. Tracking which organizations run the free edition, where users opt in to telemetry or register, helps target that conversation.
Pricing should follow the value the paid layer provides to organizations, not the size of the codebase. Buyers are paying for reduced risk and administration work, so tie tiers to team size or deployment scale.
Frequently asked questions
- Is open core still open source?
- The core edition is open source if it uses an OSI-approved licence. The paid features are proprietary. So an open-core product is partly open source; you can run the community edition freely, but the enterprise features need a commercial licence or subscription.
- What licence should an open-core project use?
- Permissive licences such as MIT or Apache 2.0 maximize adoption. Copyleft licences such as AGPL require anyone offering a modified version as a network service to share their changes. The choice depends on how worried you are about competitors reselling your core.
- Can competitors fork an open-core project?
- Yes. Anyone can fork the open edition under its licence terms, and that is part of the deal. Forks are most likely when a company changes the licence or restricts the free edition, as the OpenTofu fork of Terraform showed.
- How is open core different from freemium SaaS?
- Freemium SaaS gives a limited free tier of a closed, hosted product. Open core publishes the source of the core product so anyone can self-host and modify it. The paid layer is similar, but the free layer is code you control, not an account on someone else’s service.