Open Core Strategy FAQ

Open core is a commercial model where the core product is open source and free to self-host, while advanced features — enterprise security, team management, compliance tooling, support SLAs — are sold as a commercial cloud tier or enterprise license. It is the model behind companies like GitLab, HashiCorp (pre-BSL change), Mattermost, and Metabase.

The questions below reflect what founders building open core products ask before committing to the model.

❓ Frequently Asked Questions

What is the difference between open core and open source?
Open source means the code is publicly licensed and free. Open core means the core is open source, but the commercial product wraps it with closed-source enterprise features. The open source layer drives adoption; the closed commercial layer drives revenue.

What should I open source vs. keep commercial?
Open source: core functionality, integrations, the self-host path. Keep commercial: SSO/SAML, audit logs, advanced role-based access control, SLA-backed support, and compliance features (HIPAA, SOC 2 reporting). The rule: enterprise buyers need these features and cannot self-build them faster than they can buy. Individual users rarely need them.

Does open core slow down enterprise sales?
The opposite. Open core shortens enterprise sales cycles because the technical team has already evaluated the product before procurement gets involved. The trial is the GitHub repo. The proof of value is production deployment.

Can open source competitors undercut my commercial pricing?
On core features, yes. On enterprise features, no — because those require vendor-grade SLAs, compliance certifications, and dedicated support, none of which a fork provides. Your commercial moat is the enterprise layer, not the open source core.

What license should I use for the open source layer?
Apache 2.0 for maximum adoption. AGPL-3.0 if you want to prevent cloud providers from offering your product as a managed service without contributing back. Avoid non-OSI licenses (BSL, SSPL) if community trust is a priority — they create friction with enterprise legal teams and OSS community contributors.

How do I price the commercial tier?
Per-seat pricing for team-based products ($15–$50/user/month is common). Usage-based or value-based pricing for infrastructure or AI products. Enterprise contracts (annual, $10K–$100K+) for compliance-heavy buyers. Never price the commercial tier lower than the value a mid-market company receives from SSO alone — enterprise buyers expect to pay for identity management.

Do I need a contributor license agreement (CLA)?
Yes, if you ever plan to offer a commercial version of code contributed by the community. A CLA gives you the right to re-license contributions under your commercial terms. Without one, you cannot include community contributions in your commercial product.

Is open core right for my product?
Open core works best when: the product has genuine utility as a self-hosted tool; the target buyer is technical; enterprise features add clear value beyond what an individual can configure; and you have the resources to maintain two products (open source + commercial). It is a poor fit for pure SaaS products where self-hosting is impractical, or for consumer-facing products where enterprise features are irrelevant.

How do I handle the open source community vs. commercial customer split?
Maintain a clear public roadmap for the open source core. Avoid shipping commercial features into the open source version on a delayed basis — it creates resentment. Treat community contributors as a product team; they surface bugs and build integrations you cannot staff. Enterprise customers fund the engineering that benefits the whole project.

What to Do Next

If you are evaluating open core as a model: list the five features your target enterprise buyer would need beyond the self-hosted core. If you cannot name them, you do not have an enterprise tier yet — and open core requires one to be viable. If you have already launched open source and are thinking about commercializing: start with SSO and audit logs. They are universally required by enterprise buyers and rarely resented by community users.