Open core is the most common business model on the licensing shelf, and the easiest to misunderstand. The name describes the shape of the product rather than a license: a working edition of the software is released under an open license at the center, and a ring of additional features, tooling, or services is sold around it under proprietary terms. GitLab, Elastic before its relicensing, and a long list of infrastructure companies have run this way.

The bargain is simple to state. The commons gets a genuinely useful program; the company gets a commercial product built on top of it. Everything interesting is in where the boundary is drawn.

Where the line is drawn

The open core question is always the same: which features live inside the open kernel and which live in the paid ring? The classic arrangement keeps the engine, the APIs, and the single-user workflow open, then charges for the things organizations need at scale: authentication, audit logs, high availability, dashboards, support. Each company draws the ring differently, and the drawing is the whole strategy.

Draw the ring too close to the center and the free edition is too thin to build a community. Draw it too far out and the paid product has nothing left to sell. The companies that do it well publish the rule, in a stewardship document or a public handbook, so that the boundary is a promise and not a mood.

The model also inherits the licensing question whole, because the core still needs a license of its own. Most open cores sit on a permissive text or a weak copyleft, chosen so that the paid ring can be closed around them without friction.

The community edition is not a demo

The model only works when the open core is real. A free edition that exists to upsell a crippled product is just a trial with a longer name, and communities can tell the difference quickly. The projects that sustained the model, GitLab being the careful example, kept the open edition complete enough to run a serious workload and treated its community as users rather than leads. That distinction, user versus lead, is the moral axis of the whole model.

It is also a discipline. Once a feature is in the open core, it stays there; taking it back is the one move communities do not forgive. The companies that thrive are the ones that treat the open edition as a product in its own right, not as the bottom of a funnel.

Why companies choose it

Open core trades the simplicity of dual licensing for flexibility. Because the paid ring is a separate codebase, the company does not need to own every contribution to the core, and does not need the contributor agreements that dual licensing requires. It can also move features between the rings over time, releasing last year's paid capability into the open core as the market shifts, which produces a healthy sense that the commons keeps gaining.

The suspicion it always carries

The model carries a permanent suspicion that the open edition is a hostage, that any feature the community wants badly will be moved to the paid ring. The suspicion is not always wrong. Open core companies publish boundary documents, contributor guidelines, and occasionally public commitments about what will stay free, precisely because the doubt never fully dissolves. The ones that handle it best treat the boundary as a public, revisable decision rather than a secret.

Adjacent models on the same shelf

The model also has a failure mode the other shelves do not: a community can fork the open core and compete with the paid ring. The risk is priced into the bargain, and it is why the companies that run it well keep the most operationally painful features, the ones nobody wants to maintain alone, in the paid ring where they earn their keep.

Open core sits between dual licensing and pure commercial open source. A step further out, hosted services monetize the same code without changing the license at all, which is the model the cloud era eventually commoditized. A step further in, the Business Source License makes the paid ring temporary instead of proprietary. All three are answers to the same question the old contribute-or-pay text asked: where in the stack does the money attach?

The honest reading

Filed in the binder, open core is the model that proved a software company could be built in the open without being a charity. Its failures are all boundary failures: a ring drawn in the wrong place, or moved silently. Its successes are the projects where the line was drawn in public and kept. The reader's rule is to ask not whether a project is open core, but where the ring sits, who decides, and what has been moved across it lately.

The honest version of the model is also the most demanding. An open core company has to keep two products coherent at once, one open and one paid, and the work of keeping the boundary legible is never finished. The binder files it as the model that made the most of the commons without pretending the commons was the whole product.

What the text grants

A working open edition at the center and a commercial ring around it, monetizing the features scale requires.

What a reader should check

Where the boundary sits between core and ring, and whether the company publishes the rule it uses to draw it.

The limit of this reading

The model names a product shape more than a license; the real terms live in two separate texts.