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

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.