.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
Open core is often treated as a licensing question. In practice, it is a pricing and packaging decision that determines who can adopt your product, what they can do without paying, and why a larger company will sign a six-figure contract rather than self-host indefinitely.
The question is not how many lines of code should be public. A 2,000-line role-based access control module can be worth more to an enterprise buyer than 200,000 lines of data ingestion code. The useful measure is the share of buyer-visible capability that is open: the work a customer can complete, the systems they can connect, and the risk they can manage.
Monetizely's position is clear: for B2B SaaS companies that want developer adoption and enterprise ARR, roughly 35% of buyer-visible capability should be genuinely open source and 65% should remain proprietary. GitLab offers the strongest commercial blueprint: keep the daily work and basic collaboration open, then charge for organization-wide control, security, managed operations, and advanced automation.
The percentage must reflect customer value rather than code volume
A feature ratio only helps when it measures what a buyer experiences. Counting repositories, pull requests, or lines of code creates a false sense of precision. The same product can have an open agent, open APIs, and open dashboards while reserving the few controls that determine whether a 5,000-person company can deploy it safely.
Consider the difference between a developer team and a central IT buyer. A developer team needs to run queries, ship code, view errors, or analyze product behavior. Those actions should be easy to try, inspect, extend, and self-host. A central buyer pays for SSO, SCIM, audit logs, fine-grained permissions, compliance evidence, uptime commitments, private networking, and someone else carrying the operating burden.
That distinction explains why the best open-core companies do not withhold the basic job to be done. They make the product useful before a contract exists. They monetize the point where one team's tool becomes a company-wide system.
The starting ratio below translates that logic into a product architecture.
| Capability area | Open or proprietary | Share of buyer-visible capability | Why it belongs there |
|---|---|---|---|
| Core workflow execution | Open | 20% | Users must be able to complete the central task, such as monitoring an application, running a pipeline, or analyzing events. |
| SDKs, agents, APIs, and basic integrations | Open | 8% | Developers adopt products that fit their existing stack without a sales process. |
| Plug-ins, extensions, and basic dashboards | Open | 7% | Community contribution and ecosystem reach depend on a usable extension layer. |
| Enterprise administration and policy controls | Proprietary | 15% | Central buyers pay to govern access across teams, business units, and environments. |
| Security, compliance, and audit capability | Proprietary | 20% | Features such as SAML, SCIM, audit logs, data controls, and compliance reporting solve named enterprise risks. |
| Managed service, reliability, and large-scale operation | Proprietary | 15% | Running the product at scale creates recurring operating cost and a clear reason to buy. |
| Advanced automation, AI agents, and cross-product workflows | Proprietary | 15% | These capabilities require ongoing model, infrastructure, and workflow investment. |
Exhibit 1. A 35/65 open-core starting point, measured by customer capability rather than source-code volume.
The table points to a simple boundary: open the work that makes adoption spread; keep proprietary the controls and operating services that make broad deployment safe, reliable, and economically sustainable.
GitLab is the most useful reference point because its packaging follows the buyer's expanding needs rather than treating open source as a permanent free substitute for paid software. Its Free tier serves individuals and open-source contributors. Premium is positioned for scaling organizations at $29 per user per month when billed annually. Ultimate is positioned for enterprises that need advanced security, compliance, portfolio management, and governance, with custom pricing as of September 3, 2026. GitLab also charges for usage-based AI and infrastructure features through credits, with on-demand credits listed at $1 each.
The structure matters more than the exact price. GitLab keeps the development workflow accessible, then moves buyers upward when coordination, security, and accountability become expensive to manage manually. A twenty-person engineering team can start with core source control and CI/CD. A regulated organization that needs vulnerability management, compliance controls, and supply-chain security encounters a paid reason to upgrade.
Other open-source-led vendors illustrate the same commercial boundary, although they use different pricing metrics.
| Vendor | Open or accessible foundation | Target paid buyer | Packaging approach | Primary pricing metric as of September 3, 2026 | What the model teaches |
|---|---|---|---|---|---|
| GitLab | Free DevSecOps access and open-core development workflow | Scaling engineering organizations and enterprises | Free, Premium, Ultimate, plus usage-based credits | Named user for the platform; credits for selected AI and other usage | The best general model for turning broad developer adoption into enterprise expansion. |
| Grafana Labs | Grafana OSS is licensed under AGPLv3; users can self-manage dashboards and visualization | Central observability teams that need managed telemetry, scale, support, and controls | Free, Pro, Enterprise cloud service; enterprise self-managed options | Platform fee plus usage such as logs processed, written, and retained; Enterprise starts at a $25,000 annual commit | Open visualization can drive adoption while managed data operations and access controls create paid demand. |
| PostHog | MIT-licensed open-source product and self-hosting option | Product teams that need greater scale, more projects, long retention, and company-wide controls | Monthly free allowances, pay-as-you-go products, platform packages, annual plans | Events, recordings, feature-flag requests, warehouse rows, and other product-specific usage | A generous open and free layer can work when each growing workload has a clear meter. |
| Elastic | Parts of Elasticsearch and Kibana source are available under AGPLv3, SSPL, and ELv2 options; default distribution licensing is more restrictive than a pure open-source model | Search, observability, and security buyers that want managed cloud deployment | Hosted, serverless, and self-managed offerings | Resource consumption, including RAM-hours, data transfer, storage, and Elastic Consumption Units | Source availability is not the same as open source, and licensing alone does not create a durable paid layer. |
Exhibit 2. GitLab's buyer-led tiers are the best reference model; Grafana, PostHog, and Elastic show how the boundary shifts by workload and operating cost.
GitLab is the better blueprint for most enterprise-bound B2B SaaS operators because its paid layer maps to a familiar procurement event: an organization needs stronger governance, security, and coordination. Grafana and PostHog are strong models when cloud usage is a major cost driver. Elastic is a useful warning that a source-available license strategy should not be mistaken for an open-core pricing strategy.
A product that opens only connectors, demo dashboards, or a thin SDK does not earn developer loyalty. It creates a gated trial with extra installation steps. Buyers may download it, but they will not build internal standards around it, contribute to it, or recommend it to peers.
The open portion must let a technical user solve a meaningful problem in production. Grafana OSS lets users visualize and query data. PostHog gives teams product analytics, session replay, feature flags, and self-hosting access. GitLab Free enables core source-code management and DevSecOps workflows. Those products create a real reason to adopt before the commercial conversation begins.
Three feature groups usually belong in the open product:
- The core work loop. A monitoring platform should collect, query, and display telemetry. A developer platform should store code, support review, and run basic pipelines.
- The integration layer. SDKs, APIs, CLI tools, plug-ins, schemas, and connectors should be open enough that technical users can fit the product into existing systems.
- The single-team operating experience. A team should be able to configure basic projects, invite collaborators, and use standard dashboards without confronting an artificial paywall.
PostHog demonstrates the strength of this approach. Its pricing page lists a recurring free allowance of one million analytics events, 5,000 session recordings, one million feature-flag requests, 100,000 error-tracking exceptions, and other product allowances. Once buyers need more usage, more projects, longer retention, or company-wide access controls, the commercial path becomes visible.
The lesson is not to copy PostHog's exact allowances. A free tier should give a target user enough capacity to prove value in a real environment. That proof creates the internal champion who later argues for a paid deployment.
The highest-value proprietary features are rarely the flashy ones. They are the capabilities that let a security leader, platform owner, or CIO say yes without taking on unmanaged risk.
Grafana makes the distinction explicit. Grafana OSS includes standard organization permissions, while Grafana Enterprise and Grafana Cloud add data source permissions and role-based access control. Those features allow organizations to control who can query, edit, or administer sensitive data sources.
PostHog similarly places SSO, audit logs, custom roles, and project permissions in paid platform packages. Sentry places SAML and SCIM support, advanced quota management, and expanded administrative capabilities in higher paid plans. Its Team plan is listed at $26 per month and Business at $80 per month, both with usage charges above included quotas, as of September 3, 2026.
The line should be firm. Do not reserve basic security hygiene simply to create friction. Do reserve controls whose value grows with organizational complexity.
| Feature | Recommended treatment | Commercial reason |
|---|---|---|
| Public SDK, CLI, API, and basic plug-in framework | Open | Adoption expands when developers can inspect, extend, and automate the product. |
| Single-project dashboards and standard alerts | Open | A team must see the core value without procurement approval. |
| Basic authentication and encryption | Open | Customers should not have to pay for baseline safety. |
| SAML, SCIM, custom roles, and fine-grained permissions | Proprietary | These features solve identity and access problems that appear at company scale. |
| Audit trails, policy controls, and compliance reporting | Proprietary | They reduce a central buyer's operational and regulatory risk. |
| Managed upgrades, private networking, high availability, and support commitments | Proprietary | The vendor takes on recurring work and accountability. |
| AI agents that execute multi-step work | Proprietary | The vendor bears model, compute, quality-control, and workflow-maintenance costs. |
Exhibit 3. The paid boundary should track organizational risk and vendor operating cost, not arbitrary feature scarcity.
The practical test is direct: if a 10-person team can replace the feature with a simple configuration file, it is rarely a strong proprietary anchor. If a 2,000-person company needs the feature to pass a security review or run a shared platform, it belongs in the paid offer.
The Monetizely 5-Step Pricing Framework makes the ratio operational rather than ideological. As described in Monetizing Agentic AI, the sequence begins with Goals and Segmentation, then moves through Packaging, Pricing Metric, Price Points, and Operationalizing Pricing. The order matters. A company first decides whether it seeks adoption, expansion ARR, margin protection, or a new market. It then identifies distinct buyer groups, builds offers for those groups, chooses what it will measure and charge for, sets the rates, and finally makes billing, entitlement, and reporting work in day-to-day operations.
Applied to open core, the sequence leads to a harder but better question than “what should we keep closed?” Ask: “Which customer segment needs a managed, governed version badly enough to pay for it?”
A product-led startup may use open source to reach developers who cannot approve a contract. Its paid offer should then target the platform team that needs centralized administration. A security product may offer open detection rules and agents, then charge for policy orchestration, case management, compliance reporting, and managed response. A data product may open ingestion tools but charge for hosted storage, compute, retention, and service levels.
The framework also prevents a common packaging error: putting every enterprise feature into one oversized tier. Monetizely's view is that packages should map to real segments and their distinct needs, not merely sort features into good-better-best columns. A 100-person software company may need SSO and audit logs but not a dedicated deployment model. A global bank may need all three. Those buyers should not be forced into the same commercial package.
AI belongs in the proprietary layer when it performs work rather than merely assists
AI makes the 35/65 split more important because model cost and autonomous action create a new source of recurring expense. An open-source agent can help adoption, especially when it runs locally or lets developers inspect prompts and tools. The paid layer should retain the high-cost, high-liability operating system around that agent: hosted inference, data connectors, evaluation, guardrails, task orchestration, monitoring, and outcome reporting.
The Agentic Monetization Spectrum, or AMS, clarifies why. It scores an agent on three dimensions: zero-human ability, meaning how little human work remains; operational domain, meaning whether the agent performs one task, one business workflow, or cross-functional work; and output/cost ratio, meaning whether the value created rises faster than the cost to run it. As autonomy, domain breadth, and output value increase, pricing should move away from a simple user seat and toward usage or outcomes.
The same logic informs the open-core boundary. A modest assistant that helps a developer write a query can sit near the open product. An agent that investigates incidents, fixes code, triggers workflows, or acts on customer data should be proprietary and separately metered.
| Product or AI surface | Zero-human ability | Operational domain | Output/cost ratio | AMS score | Recommended commercial treatment |
|---|---|---|---|---|---|
| GitLab Duo Agent Platform | Medium - 2 | Medium - 2 | Inflecting - 2 | 6/9 | Keep proprietary; use a seat-led platform price with credits for intensive agent activity. |
| Sentry Seer debugging agent | Medium - 2 | Small - 1 | Inflecting - 2 | 5/9 | Sell as a proprietary add-on because it performs costly, specialized debugging work. |
| PostHog AI assistance | Small - 1 | Small - 1 | Inflecting - 2 | 4/9 | Offer a controlled free allowance, then charge in credits or usage as activity expands. |
| Elastic Agent Builder | Large - 3 | Large - 3 | Inflecting - 2 | 8/9 | Keep proprietary and meter by execution because it can act across enterprise data and workflows. |
Exhibit 4. Higher AMS scores push AI capabilities deeper into the proprietary layer and toward variable pricing.
The current vendor pricing supports that direction. GitLab includes promotional credits with paid plans and lists $1 per on-demand credit. Sentry describes Seer as an AI debugging agent available at additional cost. PostHog grants 500 free AI credits, described as worth $5. Elastic lists Agent Builder execution pricing beginning at $0.025 per execution after a free allowance, effective May 1, 2026.
The central call is not to make every AI feature usage-priced. The primary meter should remain the one buyers recognize for the core product. For a developer platform, that is usually a seat. For observability or analytics, it may be telemetry volume or events. AI usage becomes a secondary charge when autonomous work creates material cost or value beyond normal use.
Buyers should select the model that matches the paid moment they already recognize
The right product model is not the one with the most open code. It is the one whose paid boundary matches a buyer's natural reason to spend money.
Exhibit 5. GitLab is the default model for enterprise-bound B2B SaaS; usage-led models fit products whose cost base rises directly with customer activity.
For most B2B SaaS operators, GitLab remains the better buy as a strategic reference because it preserves a clear primary meter. Seats fund the shared platform. Credits monetize incremental AI and infrastructure value. Ultimate-tier capabilities solve the risks that appear when a product becomes a company standard.
That architecture is more durable than hiding core workflows behind a paywall and more monetizable than opening every feature except support.
Five operating decisions make the 35/65 split durable
Define the ratio in customer capability, not source-code volume. Assign every major feature to a customer job, then estimate how much of that job a user can complete in the open product.
Make the open edition good enough to become a standard. A developer should be willing to deploy it for a real team, connect it to real systems, and recommend it internally.
Set the proprietary boundary around organization-wide risk. Reserve advanced identity, permissions, compliance, auditability, managed reliability, and cross-team governance for paid plans.
Choose one primary meter for the core product. Use seats for collaborative work tools, usage for infrastructure-heavy workloads, and a secondary meter only when AI or compute creates incremental cost.
Treat AI as a paid operating capability, not a free feature bundle. Open tools and interfaces where they drive adoption, but charge for hosted execution, orchestration, guardrails, monitoring, and autonomous work.
Footnotes
- Monetizing Agentic AI: https://www.amazon.com/Monetizing-Agentic-AI-Handbook-Transformation/dp/B0H7Z13VKJ/
- GitLab, “Pricing,” accessed September 3, 2026: https://about.gitlab.com/pricing/
- Grafana Labs, “Roles and Permissions,” accessed September 3, 2026: https://grafana.com/docs/grafana/latest/administration/roles-and-permissions/
- Grafana Labs, “Grafana Pricing,” accessed September 3, 2026: https://grafana.com/pricing/
- PostHog, “Pricing,” accessed September 3, 2026: https://posthog.com/pricing
- Elastic, “FAQ on Software Licensing,” updated August 29, 2024 and accessed September 3, 2026: https://www.elastic.co/pricing/faq/licensing
- Elastic, “Elasticsearch Serverless Pricing,” with Workflow and Agent Builder pricing effective May 1, 2026: https://www.elastic.co/pricing/serverless-search
- Sentry, “Pricing Plans for Dev Teams of All Sizes,” accessed September 3, 2026: https://sentry.io/pricing/
- Grafana Labs, Grafana AGPLv3 license file, accessed September 3, 2026: https://github.com/grafana/grafana/blob/main/LICENSE