.png)
Frameworks, core principles and top case studies for SaaS pricing, learnt and refined over 28+ years of SaaS-monetization experience.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
What Percentage of Features Should Be Open Source vs Proprietary - Finding the Right Open Core Ratio
The question arrives almost reflexively: should we open 30 percent of the product, or 60 percent? What is the dividing line? Companies evaluating the open-core model—releasing a free, community-driven version alongside a proprietary commercial tier—often start with this arithmetic. They sketch pie charts. They benchmark against competitors. They ask their investors, "What's the rule?"
This is the wrong question. The evidence from companies that have scaled open-core models—GitLab, Grafana, PostHog, Supabase, and HashiCorp among them—reveals something more important: the optimal feature split is not a fixed percentage. It is a buyer-based segmentation strategy. The features that should be open are those that appeal to the person with no budget authority: the developer. The features that should be proprietary are those that appeal to the person with budget authority and risk ownership: the manager, the compliance officer, the executive. When the person using the software and the person buying the software are the same person, feature licensing tracks buyer role, not feature difficulty.
This framework—buyer-based feature segmentation aligned with willingness and authority to pay—outperforms percentage-based splits because it directly links feature availability to the economics of purchasing. It converts more users from free to paid. It expands revenue faster among those users. And it sustains community trust, which is the foundation of the open-core revenue model itself.
The Arithmetic Is Not the Strategy
Many teams assume that the feature split should mirror the work required to build it. A harder feature belongs in the proprietary tier. A simple one belongs in open source. This intuition is backward. Difficulty of implementation is not correlated with ability to pay or authority to pay. A single-sign-on integration (SSO) is technically straightforward—often a few hours for a competent engineer—yet it is one of the highest-value proprietary features because it is purchased by security teams and IT administrators who control budget.
Conversely, a graph database or advanced indexing scheme might be technically complex and expensive to build, yet it should be open source if it appeals primarily to developers who make no purchasing decision. The economic value lives in the buyer's role, not in the feature's technical weight.
The case studies that follow—GitLab, Grafana, PostHog, Supabase, and HashiCorp—all demonstrate this pattern. Where they succeed, they gate features at the boundary between beneficiary and decision-maker. Where they stumble, they gate at the boundary between simple and complex.
Applying the Five-Step Pricing Framework to Open-Core Feature Decisions
Monetizely's 5-Step Pricing Framework provides a disciplined approach to building any pricing model, including open-core splits. The framework moves through five sequential decisions: (1) Goals and segmentation—who are your buyers and what are you optimizing for? (2) Packaging—what combination of features and terms fits each buyer? (3) Choosing the pricing metric—how do you measure consumption? (4) Setting price points—what does each tier cost? (5) Operationalizing the model—how do you make it run? For open-core companies, steps two and three are critical. Packaging determines which features land in open source and which belong in proprietary tiers. The metric—whether you charge per user, per feature, per resource, or per event—shapes how the community edition scales without cannibalizing paid revenue.
In the framework, segmentation is not an afterthought. It is the foundation. GitLab segments into individual developers, growing teams, and enterprises. Grafana segments into engineers running single-node systems, observability teams, and large organizations with compliance requirements. PostHog segments into product teams experimenting, growing companies instrumenting at scale, and enterprises that need advanced governance. Once segments are clear—and they are clear along the lines of role (developer vs. operator), scale (solo vs. team vs. enterprise), and risk appetite (experimenting vs. regulated)—feature packaging becomes obvious. Open features serve the first group. Proprietary features serve the last.
The Amazon URL for the book "Monetizing Agentic AI"— this framework in detail, and its applications to open-core decisions are directly transferable. The discipline is the same whether you are building a SaaS product from scratch or inheriting a large open-source project and deciding what to commercialize.
The Three Buyer Personas and What Each Wants Unlocked
The buyer-based framework reduces to three personas, each of which purchases different feature sets. This segmentation holds across infrastructure, developer tools, data platforms, and applications software.
The first persona is the developer, engineer, or individual contributor. This person has no budget authority and typically no purchasing power. They seek to accomplish work: run code, build features, debug systems, access data. They are comfortable with complexity if it solves their immediate problem. They do not want administrative overhead. They do not fear upgrades or missing managed support. For this persona, the open-source tier should offer full core functionality: the ability to complete the central use case without limit. GitLab's community edition includes repositories, merge requests, CI/CD pipelines, and issue tracking. PostHog's free tier includes analytics events, session replays, and feature flags. Supabase's open tier includes a PostgreSQL database, authentication, and real-time subscriptions. These are complete workflows. A developer hitting these open-source features does not feel artificially limited.
The second persona is the operator, team lead, or manager. This person has partial budget authority (or influences it) and is responsible for team velocity, quality standards, and process consistency. This person does not write code in the product; they configure it, monitor it, set policies on it. They value observability, control, and consistency across their team. For this persona, the proprietary tier should unlock governance, collaboration, and risk control: team management, approval workflows, audit logs, security policies, advanced RBAC, SSO, and compliance exports. These features are not necessary for a developer to complete work. They are necessary for a manager to deploy that work confidently. GitLab's professional and ultimate tiers add branch protection rules, approval requirements, security policies, and advanced approval workflows. Grafana's enterprise tier adds team management, SAML/SAML-plus authentication, and audit logs. PostHog's Scale tier unlocks RBAC, SSO, and the enterprise edition. Supabase's Team plan adds SSO and advanced security features.
The third persona is the executive, compliance officer, or buyer. This person has full budget authority and is optimizing for risk mitigation, regulatory compliance, vendor lock-in prevention, and cost predictability. For this persona, the proprietary tier should deliver SLAs, security certification, dedicated support, and contractual guarantees. These features are sold, not discovered. An executive does not find the SLA by exploring the product interface. The SLA is negotiated as part of the contract. HashiCorp's enterprise tier promises defined SLAs, Sentinel policy enforcement, and predictable scaling. GitLab's ultimate tier includes SAML2/LDAP integration, advanced IP restrictions, and premium support with defined response times.
When feature packaging aligns with buyer role rather than feature complexity, conversion increases and churn decreases. A developer evaluating the product can complete meaningful work for free and feels no artificial constraint. A manager deploying that work can justify the paid tier because governance is genuinely necessary. An executive buying the contract understands they are purchasing certainty, not features.
Five Companies and the Buyer-Based Split in Action
GitLab - Segmentation by Role Across Three Tiers
GitLab reported fiscal year 2025 revenue of $759.2 million, up 31 percent year-over-year from $579.9 million in fiscal 2024, with a 37 percent increase in fiscal 2024. The company maintains a three-tier structure: Community Edition (open source, no licensing cost, MIT license), Professional (proprietary, sold to growing teams), and Ultimate (proprietary, sold to enterprises). The Community Edition includes core DevOps workflows—repositories, CI/CD pipelines, issue tracking, and wiki. It places no limit on concurrent users, no rate limiting, and no feature deprecation. A developer or small team can run GitLab in production at zero cost. The Professional and Ultimate tiers reserve advanced features for team leads and IT administrators: branch protection rules, approval requirements, advanced RBAC, security policy enforcement, audit logs, and change management controls. A manager deploying code from developers into production requires these guardrails; a developer writing code does not. GitLab's gross margin stands at 89 percent, and dollar-based net retention exceeds 130 percent, indicating strong expansion within paying customers. These metrics demonstrate that the open-source tier successfully converts developers into paying users, and the proprietary tiers expand revenue as those users scale into teams and enterprises.
Grafana exposes a clear boundary: the AGPL-licensed Grafana server is open source, with free hosting on Grafana Cloud or self-hosted on customer infrastructure. The proprietary Grafana Cloud tiers reserve operational features: alerting, user management, integrations, and data source management. The free Grafana Cloud tier accommodates 10,000 active time series and 50 gigabytes of logs per month. Developers working alone can visualize metrics, build dashboards, and set up basic alerts at zero cost. Grafana Cloud Pro ($19 per month base) and Advanced tiers add team features: user management, advanced RBAC, custom branding, and integrations. The enterprise tier, starting at $25,000 per year, includes SAML, advanced IP restrictions, and custom SLAs. The median Grafana contract for enterprises is approximately $100,000 per year, reflecting both per-user and usage components (the platform charges $6.50 per 1,000 active metrics, $0.40 per gigabyte of logs retained). The split works because Grafana reserves governance and team features—not data access or visualization capability—for paid tiers. An individual engineer exploring metrics hits no ceiling on the free plan; a team scaling observability requires the paid service to manage users, enforce policies, and track audit trails.
PostHog offers an MIT-licensed core with proprietary enterprise features. The free tier includes 1 million events per month, unlimited session replays, unlimited feature flags, and community support. Developers experimenting with product analytics, session replay, or feature flags pay nothing. When event volume exceeds 1 million monthly events, PostHog charges $0.000050 to $0.000090 per additional event on a tiered scale, with volume discounts reaching 82 percent at high scale. The proprietary tiers unlock advanced governance: the Boost tier ($250 per month) adds RBAC and custom SSO. The Scale tier ($750 per month) adds advanced RBAC, SSO, and compliance features. The Enterprise Edition (custom pricing) includes white-gliding onboarding, priority support, and advanced SLAs. Pricing is transparent: PostHog publishes exact per-event rates and tier costs on its website. This transparency builds trust with the open-source community because users see that costs scale with their actual usage, not with artificial feature limits. The buyer-based split is explicit: individual developers and small product teams use the free tier and pay only for event volume. Larger companies with governance requirements upgrade to Boost or Scale. Enterprises with mission-critical analytics move to Enterprise Edition. PostHog reports that 97 percent of its user base operates on the free tier, indicating that the free tier is genuinely useful, not a stripped-down demo.
Supabase provides a PostgreSQL database with a free, open-source interface (Auth, RealtimeDB, Vector Storage, Edge Functions) and a proprietary managed hosting service. The free tier includes 500 megabytes of database storage, 1 gigabyte of file storage, and community support. Developers building prototypes or learning PostgreSQL can do so at zero cost. The Pro tier ($25 per month) increases storage to 8 gigabytes and adds email support. The Team tier ($599 per month) adds SSO and SOC 2 compliance. The Enterprise tier (custom pricing) includes dedicated infrastructure, HIPAA compliance, and custom SLAs. The buyer-based split mirrors Supabase's customer segments. Individual developers and bootstrapped startups use the free or Pro tier. Growing teams purchase the Team tier to unlock SSO and compliance features needed for enterprise customers. Enterprises negotiate custom terms on dedicated infrastructure. Supabase's self-hosting option—the entire platform deployed on customer infrastructure—is completely open source and free. The proprietary layer is the managed service and the additional governance features that come with it. A developer does not buy Supabase the managed service; a CTO or VP of Engineering negotiates the contract.
HashiCorp transitioned Terraform from the Mozilla Public License 2.0 (open source) to the Business Source License (BSL) beginning with Terraform version 1.6, released in 2023. This shift was controversial but illustrative. The BSL allows free use for most purposes but requires a license for commercial use (defined as embedding Terraform into a product sold to others or using it at extreme scale within the company). For commercial infrastructure teams, HCP Terraform—the managed service—provides the legal clarity and operational features that enterprises require. HCP Terraform's free tier allows 500 resources. The Standard tier and above unlock team management, state locking, VCS integration, and run history. Enterprise pricing typically starts at $25,000 per year and scales with the number of resources, teams, and policy enforcements. Vault, HashiCorp's secrets management platform, offers an open-source core with an Enterprise edition that adds namespaces, advanced replication, policy enforcement (Sentinel), and audit logging. HashiCorp's pricing moved away from open-source economics toward a more traditional enterprise software model, but the buyer-based split remains: infrastructure teams can experiment with the open tools at zero cost. Operations teams and security organizations purchasing Vault or Terraform Enterprise are negotiating based on compliance, multi-tenancy, and SLA guarantees—not feature counts. The shift illustrates that as companies mature, the proprietary tier focuses increasingly on risk and governance, not on feature novelty.
The following table summarizes the feature split across the five case studies, organized by buyer persona and functional area.
The pattern is consistent: developers receive unlimited access to core functionality (build, debug, deploy, measure). Managers receive bounded governance (team management, approval workflows, audit trails). Executives receive contractual certainty (SLAs, compliance certification, dedicated support, legal guarantees).
When feature segmentation aligns with buyer role, conversion from free to paid rises. Open-core companies with clear role-based feature splits report trial-to-paid conversion rates between 8 and 12 percent. This is materially higher than the industry median for SaaS trials, which is approximately 3 to 10 percent for freemium models. The data suggests that a user who completes meaningful work on the free tier (because the open core is genuinely useful) is more likely to convert when they hit a governance or scale boundary.
Feature adoption rates also correlate with expansion. Core feature adoption averages 24.5 percent across B2B SaaS; top-quartile companies exceed 45 percent. When companies gate features—especially governance features—at the boundaries between persona layers, adoption of proprietary features drives net revenue retention. GitLab's 130 percent dollar-based net retention is a direct result: each expanding customer adopts more proprietary governance features as their team grows. PostHog's high free-tier adoption (97 percent of the user base) combined with event volume growth (as companies instrument more deeply) drives usage-based expansion. Supabase's move from free to Team tier unlock SSO, which is a governance feature, not a core functionality feature, confirming that expansion is driven by role-based needs.
The following checklist translates the buyer-based model into a decision framework.
For each proposed feature, answer the following questions in sequence:
- Does the target user make the purchasing decision, or do they influence it? If they make it (developer), the feature belongs in the open core. If they influence it (manager or executive), the feature belongs proprietary.
- Does the feature unlock a new use case, or does it reduce friction on an existing use case? New use cases belong in the open core (developers exploring). Friction-reduction belongs proprietary (managers rolling out).
- Would a user who cannot afford the paid tier still benefit from this feature? If yes, open core. If no (compliance, audit, SLAs), proprietary.
- Can the feature be disabled or rate-limited without breaking the core workflow? If yes, proprietary. If disabling it creates a non-functional product, open core.
- Does the feature create governance, risk, or compliance liability? If yes, proprietary (risk is borne by the organization, not the developer). If no, open core.
Applied to common features:
The following matrix maps buyer personas to the appropriate product tier, illustrating where conversion should occur.
The matrix clarifies that not all users should convert at the same point. A team of 2 engineers does not need the professional tier; the free tier serves them well. A team of 20 needs team governance but not executive compliance features. A regulated enterprise needs all three layers. Conversion happens when the user's role or scale makes proprietary features essential, not merely convenient.
A critical implementation detail: successful open-core companies maintain a single codebase and gate features at runtime, not at build time. GitLab does not ship different software to free and paid customers; it ships the same software and disables proprietary features in the free tier. PostHog does the same. Supabase does the same. This approach reduces maintenance burden and eliminates the confusion of multiple product versions. A user can explore the full feature set, discover what interests them, and then learn that certain advanced features require a paid tier.
The alternative—shipping a stripped-down free version and a separate proprietary product—fails on two counts. First, the maintenance burden doubles: every bug fix and feature must be applied to both codebases. Second, users feel deceived when they discover that a feature they need is in the paid version only. They suspect the feature was artificially disabled, which erodes trust.
The single-codebase approach with role-based gating also simplifies migration. A free user upgrading to a paid tier experiences no product switch. They are the same product with the same workflows; the proprietary features are simply unlocked.
Recommendations for Your Open-Core Decision
Based on the evidence from these case studies, we recommend the following approach to determining your open-core feature ratio:
Segment your buyers explicitly by role, not by company size. Identify the developer (individual contributor), the manager (team lead), and the executive (budget owner). For each segment, define what success looks like: developers succeed when they complete core work; managers succeed when they deploy that work with confidence; executives succeed when they mitigate risk and cost. Base your feature split on these role-based definitions, not on feature complexity or development cost.
Gate governance, not core workflows. Your open core should include repositories, databases, dashboards, event ingestion, CI/CD pipelines—anything a developer needs to complete their primary task. Your proprietary tier should unlock team management, approval workflows, audit logs, SSO, and compliance features that a manager or executive needs to deploy at scale. The line between open and proprietary runs between "what developers build" and "what organizations control."
Publish transparent pricing for the proprietary tier. Hidden pricing erodes trust with your open-source community. PostHog publishes per-event costs and tier pricing openly. GitLab publishes feature matrixes. Grafana publishes per-series costs. This transparency builds confidence that the proprietary tier offers genuine value, not artificial lock-in. It also allows users to estimate their costs before upgrading, reducing purchasing friction.
Measure conversion and expansion by role, not by segment. Track trial-to-paid conversion separately for developers, managers, and executives. Track which proprietary features drive expansion within paying customers. If you find that developers are converting at 3 percent but managers are converting at 15 percent, you have a packaging problem: either your free tier is too generous for managers (they should see the need to upgrade sooner) or your proprietary features are misaligned with manager needs. Use these metrics to refine your feature split.
Maintain a single codebase with role-based feature gating. Do not ship different products to free and paid tiers. Ship one product with proprietary features disabled in the free tier. This reduces complexity, eliminates user confusion, and allows free users to explore the full feature set before upgrading.
Design your conversion path around organizational growth. A solo developer should remain on the free tier indefinitely. A team of 5 should feel the need to upgrade to team governance features. A regulated enterprise should require proprietary features for compliance. Your feature split should make this progression feel natural, not artificial.
Footnotes
- https://www.amazon.com/Monetizing-Agentic-AI-Handbook-Transformation/dp/B0H7Z13VKJ/—covers
- https://www.sec.gov/Archives/edgar/data/1653482/000162828025014344/0001628280-25-014344.txt
- https://www.sec.gov/Archives/edgar/data/1653482/000162828024012963/0001628280-24-012963.txt
- https://grafana.com/pricing
- https://checkthat.ai/brands/posthog/pricing
- https://www.stackscored.com/pricing/product-analytics/posthog
- https://gamemakerblog.com/2025/04/27/supabase-2025-full-breakdown-of-features-and-pricing
- https://www.softwaresuggest.com/supabase
- https://www.srvrlss.io/provider/supabase
- https://dev.to/terraformmonkey/terraform-licensing-the-2023-change-still-shaping-your-2025-strategy-4mfb
- https://redresscompliance.com/hashicorp-terraform-vault-negotiation
- https://developer.hashicorp.com/hcp/docs/vault/get-started/deployment-considerations/tiers-and-features