Open core

Open core, open source and freemium are three different lines

These get used interchangeably and they cut along different axes. It is worth being precise, because the difference decides what happens to you if the vendor changes its mind.

• Open source is a licensing fact about code: the licence grants you the right to run, study, modify and redistribute it. It says nothing about who pays for what.
• Open core is a packaging decision on top of that: some of the product carries an open licence and some of it does not exist in public at all. The proprietary half is usually the hosted service, single sign-on, audit logs, permissions, and whatever the largest customers ask for.
• [Freemium](/glossary/freemium) is a pricing decision inside one proprietary product: a free tier and paid tiers of the same closed software. Nothing is open, and self-hosting is not on the table.
• [Usage-based pricing](/glossary/usage-based-pricing) is orthogonal to all three — it describes how the bill is calculated, not what you are allowed to do with the code.

A useful test: with freemium, hitting the ceiling means you upgrade. With open core, hitting the ceiling means you either upgrade or build the missing piece yourself, because you have the rest of the system in your hands. That second option is the whole value of the model to an adopter, and it is real more often than people assume.

Reading a repository for where the line actually falls

We write up open-source growth tools regularly on our /grow pages, and after more than sixty of them the pattern is consistent enough to be a checklist. The claim on the badge and the location of the paywall are separate facts, and the second one is the one that decides whether the tool solves your problem. Read for these before you adopt anything:

• Open the LICENSE file, not the badge. GitHub's own licence field reads `NOASSERTION` when it cannot classify what it found, and some repositories with a licence badge have no licence text at all. That is not a smoking gun on its own, but it is the one field where you cannot afford a guess.
• Look for the footnote that says cloud-only. The most common shape is a README feature list where one or two entries carry a quiet note that they are available on the hosted plan. If that entry is the reason you were adopting the tool, you have just read the whole story.
• Read the comparison table the project publishes about itself. It is marketing, so treat the competitor columns with suspicion, but the column describing its own product is usually accurate and tells you what the maintainers think they are selling.
• Check which plugins or modules are labelled core. A project that marks some capabilities core and others optional has already drawn its line in public, which is far easier to trust than a pricing page.
• Check the copyright holder and the contributor agreement. A single company holding copyright can relicense later; a foundation or a broad contributor base makes that considerably harder. This is the field that predicts what happens in three years.

docmd, a documentation compiler we wrote up on 3 September 2026, is a clean small example of the shape done legibly: the compiler and all of its build outputs are MIT in the repository, and the one hosted piece — a relay that lets a purely static site run the AI assistant without operating a backend — is clearly marked as the optional service. You can tell in a minute what you would be self-hosting and what you would be buying, which is not true of every project in the category.

What this means if you are adopting one, and if you are building one

As an adopter, the honest question is not whether the tool is open, it is what your exit costs. Self-hosting is free in licence terms and not free in hours: someone runs the upgrades, the backups and the outage. Price that against the hosted plan at the size you expect to be in a year, not the size you are now. The upside you are paying those hours for is real, though — your data stays in a database you control, and if the vendor's roadmap turns away from you, you still have a running system rather than a migration.

As a founder considering the model for your own product, the thing to be clear-eyed about is that open core is a distribution strategy before it is a revenue strategy. It buys reach, credibility with developers and a stream of contributors; it does not by itself produce customers, and it constrains you afterwards, because moving a feature from the open side to the paid side is one of the few decisions that reliably costs a project its goodwill. Decide the line before the repository is public, and write it down where users can read it.

It also does not remove any of the work of being found. An open repository is a distribution channel with the same problem as every other one — people have to hear about it. That is why the projects that win in this model are usually the ones doing ordinary content and community work alongside the engineering, not the ones that assumed the licence would do the marketing.