Open Core vs. Fully Open Source: How to Tell What You'll Actually Have to Pay For

Two tools describe themselves as open source. One is free to use in full forever, funded by paid hosting and support. The other gives you a capable free core but keeps single sign-on, audit logs, and access control in a paid "Enterprise" edition. Both descriptions are accurate. They are just different business models, and you want to know which one you are adopting before you build on it.

The two models

Fully open source. Every feature is under an open-source licence. The company (if there is one) makes money from a hosted version, support contracts, training, or consulting. You can run the entire product yourself with nothing withheld.

Open core. There is an open-source core — often genuinely good and genuinely usable — plus proprietary add-ons sold as a "Pro," "Team," or "Enterprise" edition. The core is the funnel; the add-ons are the revenue.

Neither is inherently bad. Open core funds a lot of software that would not otherwise exist, and the free core is frequently enough for small teams. But the incentive is real: the vendor decides where the line between free and paid sits, and that line tends to move toward the features businesses will pay for.

How to tell which one you are looking at

Signs a project is open core:

• An "Enterprise" or "Pro" edition with its own pricing page and a feature-comparison table.
• A features matrix with checkmarks where the interesting rows — SSO, audit log, RBAC, LDAP, high availability — are only ticked in the paid column.
• A separate ee/ or enterprise/ directory in the repo, often under a different licence file, or a second repo entirely.
• Features gated behind a licence key you enter to "unlock" functionality in the same binary.
• A Contributor License Agreement (CLA) required for contributions. Not proof of open core by itself, but it is what lets a company relicense or take features proprietary later, so it is a signal worth noting.
• Language like "source available" or a non-OSI licence (BSL, SSPL) on some or all of the code.

Signs it is fully open source:

• One licence (MIT, Apache 2.0, AGPL) covering the whole codebase.
• Money comes from a clearly separate hosted offering or support plans, not from features.
• No "Enterprise edition" — just "the software" and "we'll host it for you."
• Governance under a foundation, which makes relicensing far harder.

What tends to live behind the paywall

If a project is open core, these are the features most commonly reserved for the paid tier. If you need any of them, price the paid edition now:

The free core usually covers the actual function of the tool well. What is withheld is the stuff that makes it manageable for a bigger organisation.

Questions to ask before you commit

1. Is every feature I need in the free tier today? Make the list explicit — do not assume.
2. Has the project moved features from free to paid before? Check the changelog and release notes. A history of " this is now Enterprise-only" predicts the future.
3. Is the core genuinely useful on its own, or is it a demo that pushes you toward the paid edition within a month?
4. What licence is the core under, and is there a CLA? (See the companion post on open-source licences for founders.)
5. If the paywall moved tomorrow, how bad would that be for me? Could I fork the last good version and maintain it?

A worked example

You adopt a self-hosted analytics tool. The open-source core does everything you need: dashboards, custom events, data export. Great.

Eighteen months later a client's security review requires SSO. SSO is in the Enterprise edition, priced per seat with an annual minimum. Now you are choosing between paying for a tier you did not plan for, running a community patch that adds SSO (if one exists), or migrating to a fully open-source competitor mid-flight.

None of this was hidden. The features matrix said "SSO — Enterprise" the whole time. The mistake was not checking the paid tier's price against your likely future needs on day one.

The bottom line

Open core is not a trap, but it is a business model with a built-in tendency: the free/paid line drifts toward what companies will pay for. Before you depend on an open-core tool, confirm the features you need are free, check whether the project has relicensed or re-gated things before, and know what your fork-and-maintain fallback would be. If it is fully open source under a single permissive or copyleft licence, you have far less to worry about — the whole thing is yours to run.