Open-core business model — what to keep open, what to charge

Open-core gets harder the more successful the project becomes. Early on, every feature you ship is open and adoption compounds. Then you need revenue, you start drawing the line, and the community pushes back on every feature you move behind a paywall. The founders who survive this transition have a clear answer to "what stays open and what becomes commercial?" before they need it.

The three patterns that work

Pattern 1: Core open, scale commercial. The single-user / single-node version is fully open. Multi-tenant, multi-node, clustering, HA, SSO — commercial. This is GitLab's shape, Sentry's, Mattermost's. Works because the open product is genuinely useful on its own, and the commercial features only matter at scale where companies have budget.

Pattern 2: Open library, hosted commercial. The framework / library is fully open. The hosted, managed version is commercial. This is Supabase, Posthog, n8n. Works because hosting genuinely costs money and removing the operational burden is the value proposition.

Pattern 3: Open product, enterprise add-ons commercial. The product is fully open. Enterprise add-ons (audit log, SSO/SAML, compliance certifications, role-based access) are commercial. This is Grafana's shape, Cal.com's. Works because enterprise buyers will pay specifically for the compliance and governance features that small teams don't need.

The decision frame for each feature

For every new feature, ask:

1. Does it benefit the community broadly, or specifically large companies?

   • Broadly → open.
   • Specifically large companies → commercial.

2. Does it cost meaningful infrastructure to run?

   • Yes → managed-version commercial; library stays open.
   • No → could go either way.

3. Does it require ongoing labour from us to support? (e.g., a complex auth integration that needs maintenance per identity provider.)

   • Yes → commercial often justified.
   • No → open easier.

4. Would withholding this from the open project actively hurt adoption?

   • Yes → keep open, find another commercial line.
   • No → commercial is fine.

The trap: moving features from open to commercial

This is where most open-core founders get into trouble. The community sees a feature in v1.4 as open, then in v2.0 it's locked behind a commercial tier. The reaction is rage; the perception is bait-and-switch; the loud users fork the project.

The discipline: never move a feature from open to commercial in the same project. If you decide a feature belongs commercial in retrospect, the path that works is:

• Ship the new version commercial-only (the feature is new, not moved).
• Or release a major version where the change is documented, the deprecation timeline is generous, and the rationale is concrete.

The version where the change is hidden in a release note and discovered by users on upgrade — that's the version that kills your community.

The other trap: making the open version too capable

Equally common: the open version is so good that nobody needs the commercial one. Companies use it forever, never pay, and you have a thriving community with no revenue.

The fix: make sure the commercial features address a real cost the customer is currently paying. Not "would be nice to have." Specifically: hosting and ops cost (Pattern 2), compliance and governance cost (Pattern 3), scale-out infrastructure cost (Pattern 1). These are real budget lines at companies; the commercial value capture aligns with a cost they're already incurring.

What to do early

• License choice matters more than you think. AGPL/SSPL vs MIT vs Apache — each has different implications for whether competitors can host your open project and undercut your commercial version. Talk to a lawyer (specifically one who works with open-source businesses) before v1.0.
• Write down the commercial line in your README. "These features are commercial: [list]. These will always be open: [list]." Public commitment prevents the bait-and-switch perception later.
• Set up commercial billing infrastructure early, even if you're not selling yet. Future-you will thank present-you for the not-having-to-bolt-on-Stripe-at-2am-when-an-enterprise-deal-lands.

The reading list

• The "open-source business" essays from a16z, Sequoia, and Bessemer are useful as macro frames but pretty light on operational specifics.
• The HN / Lobste.rs threads on each major open-core company's pricing changes are the actual education. Read them with the goal of understanding what the community reacted to, not what the company was trying to do.
• Talk to 2-3 other open-core founders who are 18-36 months ahead of you. They'll save you the most pain.