Open core

The commercial layer finances the company behind it.

The term was coined in 2008 by the analyst Andrew Lampitt to describe a strategy that could be observed at several open-source companies at the time. Since then, the model has become the most widespread way of generating revenue with open-source software. For companies that use such software, it is important for a practical reason: anyone who equates "open source" with "completely free of charge and completely free" can get their calculations wrong.

How the open-core model is structured

An open-core product consists of two layers. The community edition contains the core and is under a recognised open-source licence such as MIT, Apache 2.0 or GPL. Anyone may download, use, modify and pass it on. The enterprise edition builds on it and adds functions that larger organisations in particular need. These extensions are under a commercial licence; their source code is either closed or viewable but not freely usable.

Which functions move into the paid layer is rarely a matter of chance. Typical candidates are features that become a problem above all as an organisation grows and for which, experience shows, companies are willing to pay:

• Central log-in and directory connection, for example single sign-on
• Fine-grained rights management, for example role-based access control (RBAC)
• Audit logs and compliance reports
• High availability, clustering and scaling functions
• Professional support with guaranteed response times
• Managed cloud offerings (managed hosting)

The logic behind it is simple: an individual developer or a small team can manage with the core. A corporation with compliance requirements needs roles, log-in and evidence, and there is a budget for these requirements.

Distinction from related models

The boundaries are fluid, and many providers combine several models. The distinction from open source in the narrower sense is important: according to the definition of the Open Source Initiative (OSI), a licence must, among other things, allow free redistribution and unrestricted use for any purpose. Source-available licences such as the Business Source License do not meet this, even if the source code is readable.

Why open core is relevant for companies

For providers, the model is attractive because it combines reach and revenue. Developers try out the open version without a purchasing process, recommend it and build up knowledge and extensions in the ecosystem. As a project grows into an organisation, the natural transition to the paid edition arises.

For users, the benefit lies in transparency and control. The source code of the core can be inspected, the product can be self-hosted, and switching vendor is easier than with purely proprietary software. The risk lies at the boundary: what is in the core today can move into the paid layer tomorrow, or a licence can be changed for future versions. This results in three concrete questions for decision-makers.

1. Which functions do we really need? If the specifications contain a function that typically sits behind the paywall, such as rights management or corporate log-in, the enterprise licence belongs in the cost calculation from the outset.
2. How is the licence worded? An MIT licence for the core and a separate licence file for enterprise components have a different risk profile than a licence that restricts use as a service.
3. How viable is the roadmap? Do functions have a history of moving from the core into the commercial layer? A look at release notes and issue history provides clues.

Examples from practice

GitLab is one of the best-known open-core products. The Community Edition is under the MIT licence, and the Enterprise Edition adds functions under a commercial licence. GitLab publicly describes its strategy as "buyer-based open core": functions are classified according to which buyer role they primarily affect and distributed across edition tiers accordingly.

Elastic changed the licence of Elasticsearch and Kibana in 2021 from Apache 2.0 to dual licensing under the Server Side Public License (SSPL) and the Elastic License. In response, Amazon Web Services published a fork called OpenSearch. The case is regarded as an object lesson in how conflicts between open core software and cloud providers can arise. In 2024, Elastic added the AGPL as a recognised open-source option again.

HashiCorp switched its products, including Terraform, from MPL 2.0 to the Business Source License in August 2023. The community responded with the fork OpenTofu, which is continued under the umbrella of the Linux Foundation. Here too, the trigger was the relationship with providers that commercially exploit the software.

The cases show that licence changes are a real scenario and not just a theoretical one. But they also show that the legal status of versions already published is retained and that forks are possible if the community loses trust.

An example from the commerce environment

There are open-core constellations in e-commerce too. The MedusaJS framework is predominantly under the MIT licence, but according to the ENTERPRISE-LICENSE.md in the repository, it has excluded individual building blocks as enterprise materials since August 2026. According to the licence, these include RBAC and the OIDC connection for single sign-on. Generic authentication and normal user and invitation management remain MIT. The change applies going forward and does not withdraw any rights to versions already published. The entry on MedusaJS describes the context for cost calculation and operation.

The example is typical of the way the line is drawn: what corporations need lies behind the licence boundary, while what developers need to get started remains free. Whether you consider this fair or a break with the open-source idea is a matter of judgement. For project planning, what matters is that the boundary exists and that it can shift.

Licensing mechanics behind the model

For a company to be able to offer parts of its software openly and others proprietarily, it must own the rights to both or obtain them from contributors. That is why many open-core projects require external contributors to sign a contributor licence agreement (CLA) or a comparable assignment. This allows the rights holder to distribute the code under different conditions later. For contributors, this is a point they should be aware of before investing work.

The choice of core licence has a strong influence on the model. Permissive licences such as MIT or Apache 2.0 allow largely free reuse, including in proprietary products. Copyleft licences such as the GPL or AGPL require derivative works to be published under the same conditions. The AGPL extends this obligation to software offered as a service over a network and is therefore relevant for cloud scenarios. Providers choose depending on their goal: a permissive licence maximises distribution, while a copyleft licence makes it harder for competitors to turn the code into closed services.

In practice, a simple check helps users. The repository usually contains a file called LICENSE and, in open-core projects, often a second file for the commercial components. It lists which directories or modules are under which licence. Reading these two files before making a decision takes half an hour and avoids later surprises in cost calculation and contract negotiation.

Advantages and disadvantages at a glance

In favour of using an open-core product are the low entry barrier, the source code that can be inspected, the option of self-hosting and an ecosystem that provides extensions and knowledge. If necessary, you can later switch to the commercial layer without changing the platform.

Against it are the uncertainty about future licence boundaries, the risk of hidden follow-up costs if enterprise functions are noticed late, and a possible dependency on the vendor for security-critical building blocks. Anyone who adapts the product deeply also risks extensions colliding with the proprietary parts or having to be reassessed in the event of licence changes. The counterweight to this risk is a deliberate strategy against vendor lock-in: clear interfaces, documented export routes and regular reassessment.

Common misconceptions

"Open source means free of charge." The licence for the core costs nothing, but operation, development and, where applicable, enterprise functions do. Looking at the total costs is part of every honest calculation, comparable to the total cost of ownership.

"Open core is the same as freemium." With freemium, the product itself is proprietary and is offered in a restricted free version. With open core, the core is open source and freely modifiable. The difference concerns freedoms, not just the price.

"Source-available is open source." Not according to the OSI definition. Licences with usage restrictions are categories of their own, even if they often appear under the umbrella term open source in everyday use.

"An MIT licence guarantees the future." It guarantees that published versions remain freely usable. The rights holder can publish future versions under different conditions.

Outlook

The tension between an open core and commercial success remains. Cloud providers offer open software as a service and earn money from it without financing its development. Vendors respond with more restrictive licences, edition boundaries or cloud exclusivity. The countermovement consists of forks and foundation models that transfer projects to neutral ownership. For users, this results in a sober recommendation: a project's licence, roadmap and governance are just as much selection criteria as its range of functions and code quality.

Anyone planning software for five years should therefore treat the question of the licence boundary like an architectural topic: clarify it early, document it and reassess it at intervals.

Frequently asked questions about open core

What does open core mean?

Open core refers to a business model in which a core product is published as open source and additional functions or services are chargeable.

Is open core the same as open source?

No. The core is open source, but the overall product is not completely so. The commercial extensions are under a proprietary licence.

Which functions typically sit behind the paywall?

Frequently, they are functions for larger organisations: single sign-on, roles and permissions, audit logs, high availability and support contracts.

Is open core suitable for mid-sized companies?

Yes, provided that the functions required and their licensing are checked early. For many requirements, the free core is sufficient; for compliance topics, the commercial layer often becomes relevant.

What happens if the vendor changes the licence?

The licence that applied at the time remains valid for versions already published. The new conditions apply to future versions. The community can fork the last free version, as the examples of OpenSearch and OpenTofu show.

Further sources

The authoritative definition of open source is provided by the Open Source Initiative. The Wikipedia article on the open-core model offers an overview of the model. The licence terms of the MedusaJS framework can be viewed in the ENTERPRISE-LICENSE.md in the repository.