Most COSS founders pick a number too early and then guard it like a fortress. They settle on something that feels defensible, publish it, and refuse to touch it again, because changing prices feels like breaking a promise. The instinct is backwards. A price is a hypothesis. You test it against what people will actually pay, you update it as you learn, and you change it when the product changes. Your pricing page should report what you’ve figured out, not what you guessed in month three.

This post covers the mechanics. Which model fits which kind of product, how to build the tiers, how to find the right number through real sales conversations, and what specific COSS companies charge today.

The five models and what each one really prices

There are five ways COSS companies charge, and each one bets on a different thing being the source of value.

Usage-based pricing charges for consumption: API calls, GB ingested, compute hours, eCKUs (metered capacity unit for Kafka clusters). It fits infrastructure and data tooling, where usage swings wildly from one customer to the next, and it fits cloud-native products you can meter cleanly. Confluent bills in eCKUs, Elastic in GB ingested, and MongoDB Atlas in cluster hours. The bet is that value tracks volume.

Seat-based pricing charges a fixed monthly fee per active user. It fits collaboration tools and DevOps platforms, where value grows with the size of the team. GitLab charges $29 per user per month for Premium; Grafana Cloud charges $55 per user per month. The bet is that value tracks headcount.

Feature-gated pricing, the open-core model, gives away a real core and puts proprietary enterprise features behind a paywall. It fits products where what an enterprise needs separates cleanly from what an individual needs. HashiCorp Vault and Nextcloud both work this way. The bet is that you can draw a clean line between the free thing and the paid thing.

Support-tiered pricing gives the software away and sells the SLA. It fits infrastructure OSS where the paid value is operational reliability: someone on the other end of the phone when production is down at 2am. OpenProject runs this way, and so did the older Red Hat model. The bet is that customers will pay for the guarantee, not the bits.

Hybrid pricing combines them. A seat-based base with usage layers on top, or a platform fee plus consumption credits. It fits most modern COSS, especially anything with AI features or consumption patterns too messy for a single meter. HashiCorp’s HCP Terraform prices on resources; Elastic stacks compute and support tiers. The bet is that no single meter captures the value, so you use two.

Match the model to where the value lives

The model isn’t a style choice. It follows from where value actually accumulates in your product, and getting that wrong mis-prices you systematically.

For developer infrastructure, databases, and streaming, usage-based or hybrid wins, because value is tied to data volume, query throughput, or compute. MongoDB Atlas charges by the hour per cluster. Confluent charges in elastic compute units that autoscale. Elastic Cloud charges per GB ingested and retained. The detail that trips people up: discounts should get better as usage climbs, so the customer who commits hard pays less per unit than the one dabbling at spot prices. Reward the commitment, not the dabbling.

For DevOps, security, and CI/CD platforms, hybrid works. Resource-based plus seat-based. HashiCorp moved off pure seats to Resources Under Management in June 2023, charging $0.10 to $0.99 per resource per month depending on tier. GitLab went the other way and stayed on pure seats: free with unlimited users, then $29 per user per month for Premium, then a custom quote for Ultimate. Both work, because in each case the meter matches the value.

For observability and monitoring, the pattern is usage-based with a genuinely generous free tier. Grafana charges per metric series ($6.50 per thousand), per GB of logs, per GB of traces, and keeps a permanent free tier under all of it. The per-unit price drops as you consume more, which is what turns a small monitoring footprint into a land-and-expand account without anyone making a phone call.

For collaboration and project management, seat-based still fits, because here value really does equal the number of collaborators. Mix in usage limits on compute minutes or storage to nudge teams toward higher tiers so growth comes from real expansion rather than seat arbitrage.

The market has been drifting toward hybrid for a few years. Bain & Company found 85% of SaaS leaders now use some form of usage-based or hybrid pricing, with 61% on hybrid models by 2025. The shape that keeps winning is the same one. A base subscription, a seat or a platform fee gives the customer a predictable floor. A usage layer of credits, tokens, or compute units lets revenue expand with value.

The canonical tier ladder

Each tier sells to a different buyer and unlocks a different kind of value. The ladder runs from the individual deciding to try your product to the organization deciding to standardize on it.

Community or Free is the individual developer’s tier, and it has to be genuinely useful. Not a demo, not a crippled trial. This tier is your distribution. If it’s too thin to be worth running, it generates no community, and you’ve quietly broken the engine that feeds every tier above it.

Team or Pro is the collaboration tier. It adds what a team of two to twenty needs: shared state, basic collaboration, somewhat higher usage limits, and better support. For seat-based products it usually lands between $10 and $50 per user per month.

Business or Growth is the tier for the company that’s scaling. It adds what you need to manage twenty to two hundred people: governance, more integrations, volume pricing, and standard SLAs. This is often where mid-market lands and stays.

Enterprise is the large-organization tier, and it’s where the security and compliance machinery lives. SSO and SAML, SCIM, audit logs, compliance certifications, dedicated support, and custom SLAs. You quote it rather than list it, and a typical ACV runs from $25K to north of $500K.

Rules that actually move the number

Guessing in a spreadsheet doesn’t work. Here’s how to find the price instead.

Start with the friction test. Bessemer Venture Partners’ AI pricing playbook lays out a process simple enough to run in a live call. Name a price, say $12K a year. If the customer says “sold” before you finish the sentence, you’re too cheap. Raise it incrementally until you hear “we’ll have to think about that.” Then stop, just short of where it becomes a real blocker. Run this in actual sales conversations, not a survey, and track how the answers cluster at each price point. The distribution tells you where the elasticity lives. Their hesitation is data. Their enthusiasm is a warning.

Never compete on price in open source. Your product is free to download and run, so if you find yourself in a price war with your own community edition, you’ve got a feature-placement problem wearing a pricing costume. The 2024 Open Source Founders Summit consensus is blunt: pricing too low is a strategic error because it trains customers to read your product as a commodity. It isn’t one. You’re selling operational simplicity, compliance readiness, and reliability that someone is accountable for.

The features that reduce organizational risk command the biggest premium. Compliance, governance, and security controls can carry three to five times the price of features that merely make someone more productive. The reason is structural. Compliance is a hard requirement with no substitute; a productivity gain is nice to have. The buyer with a mandate doesn’t negotiate the way the buyer with a preference does. Price the mandate accordingly.

For an early-stage usage-based product, a workable starting formula is a platform fee of twice your delivery cost, plus usage or outcome credits on top. The 2x floor means the baseline never loses you money, and the credits let consumption expand on its own.

Four pricing pages and what each one gets right

The theory is easier to trust once you’ve seen it survive contact with a real pricing page. GitLab, Grafana, MongoDB, and Confluent all reach billion-dollar scale on the same two moves: tier by who’s buying and let usage expand the bill underneath. Each one emphasizes a different piece. GitLab the buyer-based split, Grafana the metered ladder, MongoDB the clean cloud-versus-on-prem divide, Confluent the compute-unit model. Each of these is accurate as of July 19, 2026. Read them as four angles on one pattern rather than four separate playbooks.

GitLab: role‑based tiers on top of a complete DevOps core

GitLab’s pricing and tiering starts from the buyer and radiates out to features.

• Free: Targeted at individual contributor developers, Free is a complete DevOps solution with capabilities across all GitLab stages, including core source code management, collaboration, and CI/CD, but with limited compute minutes and no enterprise readiness or security features.

• Premium: Aimed at director‑level buyers and teams, Premium adds “enterprise level support, enterprise readiness features and DevOps features required for growing and multiple teams,” with pricing themes like faster code reviews, advanced CI/CD, enterprise agile planning, release controls, and self‑managed reliability.

• Ultimate: Designed for executive‑level buyers and entire organizations, Ultimate’s pricing themes are advanced security testing, security risk mitigation, compliance, portfolio management, and value stream management; Ultimate’s “key value is Security,” bundling DevSecOps, compliance dashboards, and broader insights.

GitLab’s handbook literally maps tiers to “Likely Buyer: Individual Contributor / Manager or Director / Executive” and uses that lens to decide which feature sits in which tier, making buyer‑based tiering explicit rather than implicit.

Grafana Labs: free observability, then pay‑as‑you‑grow

Grafana Cloud turns its open‑source foundation into a three‑step SaaS ladder: Free, Pro, and Enterprise.

• Free: “Always free” and “perfect for personal projects, exploring new ideas, and early‑stage startups,” Free includes all Grafana Cloud services with usage limits and about 14 days of retention for metrics, logs, traces, profiles, and k6 performance tests, plus community support.

• Pro: A self‑serve tier “from $19/month + usage,” Pro keeps all services but switches to pay‑as‑you‑go above the free limits, with extended retention (e.g. 13 months for metrics, 30 days for logs/traces/profiles/k6) and 8×5 email support.

• Enterprise: A full‑service offering starting at a $25,000/year spend commit, aimed at companies with security, compliance, and deployment requirements, adding premium support, custom retention, and deployment flexibility (public cloud, federal cloud, or BYOC).

Every step builds usage‑based expansion into the plan: metrics, logs, traces, and profiles are all metered, and moving up tiers mainly adjusts included usage, retention, support, and deployment guarantees rather than changing the core product.

MongoDB: clean separation of cloud vs. on‑prem paths

MongoDB’s commercial story preserves a clear separation between managed cloud (Atlas) and on‑prem or BYOC enterprise subscriptions.

• Atlas Free: Atlas exposes a free shared cluster tier (commonly M0) with constrained storage and performance, giving developers a no‑cost way to start building on MongoDB in the cloud.

• Atlas Dedicated: Dedicated Atlas clusters are billed usage‑based (instance size, region, consumption), with public guides showing small dedicated instances priced at a few cents per hour and scaling up with workload size.

• Enterprise Advanced: MongoDB’s Enterprise Advanced subscription targets on‑premise or bring‑your‑own‑cloud deployments and bundles advanced security, compliance, and SLAs, keeping the enterprise path for self‑managed environments distinct from the Atlas SaaS path.

This pattern keeps the cloud “pay for what you run” path clean, while giving regulated or large enterprises a separate “subscription + SLA” track for on‑prem/BYOC.

Confluent: usage‑based streaming with tiered readiness

Confluent commercializes Kafka and streaming workloads through Confluent Cloud, built around compute units and tiered cluster offerings.

• Cluster tiers: Confluent Cloud offers cluster types like Basic, Standard, and Enterprise (with specialized options such as Freight), each tuned to different workload and reliability profiles—from development and smaller production workloads up to mission‑critical, highly regulated deployments.

• Usage‑based pricing: Across tiers, pricing is primarily usage‑based: clusters are billed for elastic/compute Kafka units (eCKUs/CKUs) on a per‑hour basis, plus networking and data operations per GB and per request, so cost tracks throughput, storage, and retention rather than seats.

• Enterprise value: Higher tiers add stronger SLAs, private networking options, and governance and compliance features, aligning spend with operational risk and regulatory requirements.

The net effect is an elastic compute‑unit model where streaming cost scales in line with data volume and workload intensity, while tier labels signal what level of reliability and control you’re buying. The clearest way to see these rules at work is to read the pages of companies that priced well. Tier data first, then what the page is doing.

Seven ways pricing goes wrong

Most pricing mistakes repeat. Here are the ones that show up again and again in COSS.

Leaving off a “Contact Sales” path. Self-serve handles deals under $25K cleanly. Above that, the buyer wants to negotiate, ask about custom terms, and put a name to the person accountable for the relationship. Hide the contact button and you don’t look streamlined. You lose the enterprise deal.

Too many tiers. Four is the ceiling before decision cost starts killing conversion. If you have eight, the customer doesn’t study them admiringly. They stall. And a stalled customer buys nothing. Consolidate.

A free tier that’s too weak. The job of free is adoption, not revenue. If it’s so limited that it never shows the product’s real value, you haven’t built a funnel, you’ve built a frustration machine that teaches people to leave. The Bessemer-cited finding that companies maintaining robust open-source versions see 30% higher adoption exists because of exactly this dynamic.

Gatting developer productivity features is the most common and most damaging pricing mistake in COSS. Gate on organizational context, never on the individual developer’s ability to do good work.

Hiding Enterprise entirely. You don’t have to publish an exact Enterprise number; “custom quote” is standard and fine. But you do have to describe what Enterprise includes and give a clear path to a quote. Mystery packaging reads as something to hide, and developers respond to that with distrust.

Per-seat pricing for infrastructure tools. If value scales with data volume, compute, or resource count rather than team size, seats will mis-price you every time. A team of 5 running 50TB should pay more than a team of 50 running 50MB, and per-seat pricing gets that exactly backwards.

Raising prices without a communication plan. Existing customers on legacy pricing have to be grandfathered or given real runway to adjust. A surprise increase in a COSS context doesn’t stay between you and the affected accounts. It spills into the community as public backlash and reaches far past the customers who were actually repriced.

The first price is always wrong

Your pricing is wrong right now, and that’s fine. The goal is to be wrong in a direction you can learn from fast. Start usage-based or hybrid for infrastructure, seat-based for collaboration. Three or four tiers, no more. A free tier worth running. Enterprise features are gated at the organizational complexity line, not the developer’s desk. Then run the friction test: charge more than feels comfortable, listen for where “we’ll have to think about it” starts, and let the market hand you the clearing price instead of guessing at it.

The COSS companies with the strongest outcomes didn’t get the number right on the first try. GitLab, Confluent, and MongoDB have each surpassed $1B in ARR after many rounds of pricing iteration. The question was never whether the first price was wrong. It’s how fast the second one got less wrong than the first.

Subscribe now

Every commercial open-source founder hits the same fork, usually before they’ve sold anything. Do you sell your product as a better version of something buyers already budget for? Or do you try to name and own a category that doesn’t exist yet?

For COSS companies the fork is nastier than for most startups. Your open-source project might already be changing how developers work, but the commercial tier still gets sold to an enterprise buyer who maps every dollar to a category their CFO recognizes. The choice shapes your marketing story, who you get compared to, and how much venture money you’ll burn before any of it pays off.

Three paths. Two obvious ones and a third that’s usually the right answer.

Option 1: Position in an existing category

The common path, and the safer one. You frame your product as a much better option inside a category enterprises already understand.

The upside is money that’s already allocated. You don’t spend millions teaching a CISO why they need a database, an identity provider, or an observability tool. They know. You just have to convince them yours is the one to buy. For a startup running on a seed round, that’s faster and cheaper.

In COSS, being open source is usually the wedge. Customers are already shopping; they’re just sick of the incumbents.

GitLab is the clean example. When they showed up, “source code management and CI/CD” already belonged to GitHub and Jenkins. GitLab didn’t coin a term. They planted themselves in the existing category and differentiated hard: one application for the whole DevOps lifecycle, open-core, easy to self-host. Companies already knew they needed CI/CD. GitLab argued that unified and open beat fragmented and proprietary, and let the incumbents keep the fragments.

The move is to turn your open-source strengths into the buyer’s selection criteria. So name what actually makes you better than the closed incumbents:

• No vendor lock-in.

• A developer experience that’s 10x, not 10% better.

• Air-gapped deployment, for the customers nobody else will serve.

• Usage-based pricing that undercuts per-seat licensing.

The cost of this path is noise. You’ll answer “why not just use Datadog, Oracle, Okta?” in every pitch, forever. One tactic that works: publish the buyer’s guide or the architecture whitepaper yourself, and write your differentiators in as the must-have criteria. You get to define what “good” looks like, which quietly files the closed-source players under “missing features.”

Option 2: Create a new category

Bolder, riskier, and if it lands, enormous. Category creation means you sell something new: a solution to a problem nobody was framing that way yet, not a better X.

Win, and you define the category, become the “category king,” and raise at valuations that don’t make sense on revenue alone. Open source is built for this. You can hand a new paradigm to millions of developers for free and set the technical standard years before any enterprise writes a check.

Confluent is the case people cite. They commercialized Apache Kafka and stood up the category people now call “event streaming,” or “data in motion.” Before Kafka, the enterprise ran batch jobs and message queues. Confluent and the Kafka community sold a different architecture altogether: data as a live, continuous stream. They sold a vision of a real-time, event-driven company, and Kafka was how you got there.

HashiCorp did the same with Terraform, championing “Infrastructure as Code” as a whole way of working. It spun up a new job title (the modern platform engineer) and a software market to feed it.

Category creators go hunting for a higher-level problem the existing buckets don’t touch. The product is almost secondary. What you’re really selling is a new way to build.

The downsides of category creation in COSS

The bill is brutal, and it comes early. Enterprises have no line item for “data in motion” or “infrastructure as code” at the start, because they don’t yet believe they have the problem.

So you pour years and cash into thought leadership, DevRel, and community, just to explain what the paradigm is before you ever get to why they should pay you specifically. A chunk of that goes to convincing Gartner and Forrester to name the category on their maps, because until an analyst blesses it, half your buyers can’t get budget approved.

Then there’s the free-rider trap. Spend millions teaching the market, ship code that’s too permissive, and AWS or GCP can host your project, absorb the demand you manufactured, and hand you nothing. (Ask anyone who watched a hyperscaler roll out a managed version of their OSS the same quarter as a good launch.)

Attempt this only if you actually have a breakthrough architecture, and only if fighting inside an established category would badly underprice you. If your project is Postgres but 10% faster, don’t go invent “hyper-relational data stores.” It falls flat. You’ll waste every conversation explaining what the thing is instead of why your managed cloud beats RDS. Save category creation for a genuinely new problem, backed by enough funding to play a ten-year game.

Option 3: Re-segmentation, the COSS sweet spot

For most commercial open-source startups, the best move is neither. You don’t conjure a category from nothing, and you don’t line up shoulder to shoulder with the proprietary incumbents on their turf. You re-segment: take an existing category and reframe it around a use case, a deployment model, or an audience the incumbent serves badly.

Supabase is the textbook case. No new category. They called themselves “the open-source Firebase alternative.” Backend-as-a-Service was already a thing everyone understood, dominated by Google’s proprietary Firebase. Supabase kept the category’s built-in demand (”we know what Firebase is and why we want it”) and claimed the whole open-source, Postgres-under-the-hood corner of it as theirs.

Re-segmentation lets you spend the incumbent’s budget while keeping a story that’s unmistakably yours. dbt Labs did it to data transformation. ETL had been around for decades; dbt didn’t invent it. They reframed it around software engineering habits, version control and testing applied to SQL, and named the result “analytics engineering.” A twist on an old idea that landed hard with modern data teams, because it described work they were already trying to do.

Subscribe now

How to actually decide

It comes down to three things: your architecture, your community traction, and how much runway you have.

Go with Option 1 (differentiation) if:

The market is mature, the enterprise problem is already well defined, budgets exist, and you hold a real COSS edge, lower total cost of ownership, no lock-in, air-gapped deployment. Lean on why your open core beats the legacy proprietary players, and go after the segment they can’t be bothered to serve.

Go with Option 2 (category creation) if:

You genuinely have a new architectural paradigm, the way Docker had containers or Kafka had streaming. Quick test: if you keep explaining your product with “it’s sort of a database, but it also acts like a message broker, and honestly nothing out there does both,” you might have a real category on your hands. Just make sure you have the capital and the DevRel stamina for years of evangelism before the money shows up.

Go with Option 3 (re-segmentation) if:

You want both. The search volume and budget of an established category, plus a win condition that’s a fundamentally different open-source take on it. “We’re an API gateway, but built Kubernetes-native from the ground up.” That kind of thing.

Best practices for executing your choice

If you decide to create a category:

Be the loudest, clearest voice in it. Define the problem in big terms and build a movement, not a product page. In COSS this is as much about pushing a technical philosophy as selling a managed service. Find the higher-level need developers actually care about and make your project the standard-bearer: write the definitive book, run the flagship conference, get engineers to list your paradigm on their LinkedIn.

If you position in an existing category (or re-segment):

Map the proprietary competitors cold, then turn your open-source nature into a weapon against them. Build a plain matrix of the buying criteria enterprises weigh (security, scalability, ease of use) and slip in at least one new criterion that only you win. “Extensibility via open code,” say, or “deployment portability.”

Don’t be shy about naming names. Your account executives should have a sharp “unlike Datadog, we…” or “unlike Snowflake, we…” loaded for every incumbent. Set the rules of the category, or you get filed under “cheap open-source clone.” That label is very hard to peel off.

There’s no universal right answer

There’s no universal right answer here; it depends entirely on your context. What isn’t optional is consistency. Pick the story and hammer it in every channel where developers actually hang out: Hacker News, your README, the analyst briefing. If you’re creating a category, repeat the new term until the market says it back to you. If you’re fighting inside an existing one, keep pounding on why open and transparent beats expensive and closed.

Pick that story early, while the open-source momentum is still building. The market hands its own label to anything that hesitates, and the default label is not a flattering one.

Most commercial open-source founders can describe their perfect user in their sleep. The developer who stars the repo files thoughtful issues, runs the tool in production, and pays you nothing. Far fewer can describe their perfect customer. They’re not the same person, and confusing the two is how COSS companies build a beloved project that can’t make payroll.

Your Ideal Customer Profile (ICP) closes that gap. It’s a hypothesis about your perfect-fit commercial customer: the kind of company, the people inside it, and the operational mess that makes them exactly right for your enterprise tier or managed cloud. In B2B, the customer is an organization, so the ICP describes a company. But it also names the buyer who signs the contract and the open-source champion who got you in the door in the first place. A composite sketch of your dream account.

Here’s the definition I’d hold onto: an ICP describes the organization that gets the most value from what you sell and has the budget and authority to buy it. Not who needs your open-source code. Who can buy your commercial solution. The fatal mistake in COSS is defining the ideal user and skipping the second test entirely. The developer loves the free tool. That tells you nothing about whether her company will spend a dollar on enterprise features. Your ICP has to clear both bars at once: the technical need and the commercial viability.

Which makes ICP work in COSS a balancing act with no real equivalent in ordinary SaaS. You’re weighing bottom-up community adoption against top-down enterprise purchasing inside a single definition. The question underneath it all: given the community traction you already have, which organizations, and which people inside them, actually deserve your sales and marketing attention?

Start with your community traction

Start where the project already won. Look at where your open-source has organically caught fire and ask whether it clusters: certain industries, certain company sizes, certain technical use cases. Open-source tools almost always resonate hardest with one tech stack or one operational problem that keeps showing up in a particular kind of company. That cluster is your raw material.

PostHog is the cleanest example I know. The open-source analytics platform noticed its strongest uptake came from product engineers at high-growth tech companies who wanted to self-host their own data. So they wrote an ICP that most founders would find uncomfortably narrow: ambitious, skilled product engineers building high-craft products at high-growth, engineering-led startups, Series B to IPO, 15 to 500 employees.

The precision is the whole point. PostHog had figured out that these companies build fast, depend on controlling their own data infrastructure, and carry venture funding to spend on managed hosting once self-hosting turns into a chore. The narrow definition let them aim their commercial go-to-market like a laser. Build enterprise features for high-performance engineering teams, attract more high-performance engineering teams, sharpen the paid product on their needs, stay ahead of the generalist competitors trying to serve everyone at once. Narrowness compounds.

The lesson travels beyond PostHog. Use your real community data to find who loves the free product most and stands to benefit enough to pay for the commercial one. Love alone doesn’t convert.

The two axes every COSS ICP rides

A commercial open-source ICP combines two axes that pull in different directions.

The first is the company, the buyer. Industry, size, stage, tech stack, compliance posture, regulatory environment. “Tech-forward mid-market fintechs with 100 to 1,000 employees who run cloud-native infrastructure and need SOC2 compliance” is a buyer axis. These traits tell you whether the company can legally and financially buy and whether it’s likely to have the enterprise-scale problem your paid tier solves.

The second is the team, the champion. Which role inside those companies adopts your open-source first? In COSS it’s almost always technical: developers, DevOps, platform engineering, and data science. “DevOps teams managing multi-region Kubernetes clusters” is a champion axis. These traits tell you who falls in love with the free product and eventually argues for the purchase in a room you’re not in.

Cross the two and you get a narrative. Our ICP is an X type of company, with a Y type of technical team, facing a Z problem that our open-source solves locally; they adopt through the developer community, then convert to paid because they need enterprise scale and security. Make it concrete with an open-core monitoring tool: our ICP is large fintechs, 500-plus employees, running modern cloud infrastructure, where SRE teams need better system visibility. They self-host our open-source monitoring at first. As they scale, the maintenance burden gets ugly, and they come to us for multi-cluster federation, SAML/SSO, and managed infrastructure. The free tool earns the relationship. The operational pain closes the deal.

Knowing who to ignore

Defining the ICP means defining who is not the ICP. Call it the negative persona at the account level, and treat it as a feature.

PostHog again. They decided, deliberately, not to target less technical users or non-core teams like marketing, even though a product analytics tool could plausibly serve marketers. The reasoning is the part worth stealing: chasing that broader audience would have bent the commercial roadmap toward features their core engineers didn’t want, and a diluted product is a weaker product for everyone.

That kind of restraint is survival in a community-led model. Your free tool can be downloaded by a solo hobbyist or a three-person agency. Fine. That doesn’t mean you should build enterprise features for them or burn sales cycles selling to them. Strategy is as much what you refuse as what you pursue. A clear picture of the ideal commercial customer is what inoculates you against the urge to chase every account that stars your GitHub repo. It steers product (which features land in the paid tier versus the open one), messaging (whose language you speak), and early sales (which inbound users earn high-touch attention and which get a thank-you and a link to the docs).

What actually goes into a COSS ICP

A strong ICP pairs firmographic detail with the specific triggers that push a company from free to paid. The firmographics tell you who to call. The triggers tell you why they’d ever pay. Most founders nail the first half and forget the second.

So run through the components.

Industry and vertical. What sector are they in, and does your paid tier assume it? If your commercial features include air-gapped deployment, HIPAA compliance, or advanced audit logs, your ICP skews toward the heavily regulated worlds: healthcare, finance, and government.

Company size and stage, usually measured in employees or infrastructure scale. Tiny startups may adore your open-source while your commercial solution only pencils out for mid-sized companies, say 100 to 1,000 employees, that have hit a scaling wall. Write the threshold down.

Geography. Maybe your best enterprise customers sit in regions with strict data-sovereignty rules, the EU under GDPR being the obvious one, which makes a self-hosted enterprise tier far more attractive than a SaaS competitor.

Budget and willingness to pay. This is the one open-source founders skip, because they’re used to giving things away. Can the target company actually afford an enterprise license? One COSS team learned that companies under roughly $2M in annual revenue rarely closed on their $50,000 managed-cloud contract, so they wrote a revenue floor straight into the ICP. A size or budget threshold keeps your sales team from chasing accounts that love the demo, lean on your free community support, and disappear the moment the CFO says there’s no budget.

The key commercial pain point. This is the why behind the purchase, and in COSS it’s rarely the core technology, since they already have that for free. The pain is operational. “Losing 20-plus engineer hours a week to manual database maintenance and struggling to scale self-hosted nodes” is a pain point. The demographic facts get you in the room. The operational pain is what opens the wallet.

Current solutions and tech stack. What does their architecture look like? Clunky legacy system, or active use of adjacent open-source? Your ICP might be “companies running Apache Kafka for streaming but missing a good data-governance UI.” Decide up front whether you anchor on customers using specific adjacent systems, because the alternative is drowning in custom-integration requests for every platform on earth.

The decision maker. Who signs for the commercial tier? The VP of Engineering, the CISO, the Head of Platform? Name the company and the buyer inside it, so your commercial marketing reaches the person holding the budget and not only the developer writing the code.

Open-source maturity. Is this a company that mandates open-source to dodge vendor lock-in, or a legacy enterprise trying to modernize? The answer changes how you sell.

Put it together and you get something like this for an example open-source stream-processing framework: fast-growing, data-driven companies, 200 to 1,000 employees, processing more than 10TB a day on a modern cloud-native stack (AWS and Kubernetes), with dedicated data-engineering teams, bleeding 15-plus hours a week to managing stateful infrastructure. Read back how specific that is. Not “anyone who processes data.” A size, an architectural complexity, an organizational maturity, and a quantified pain. That precision is what stops the team from chasing a five-person startup pushing 1GB a day. The startup can run the open-source version forever, and good for them. They’re just not who the sales team should be calling.

Building the thing, step by step

Start with what you know or strongly suspect

For a zero-to-one COSS startup, the commercial ICP usually starts life as an educated guess in the founder’s head. “Our perfect paying customer is a mid-sized tech company drowning in the DevOps overhead of running our project, with a VP of Engineering desperate to reallocate headcount.” Write that aspiration down plainly and make sure it carries the elements above. Thin data is fine this early. Reason from the enterprise features you’re actually building.

Pressure-test against community data

Once you have a hypothesis, attack it with your community. Do you have a handful of early enterprise design partners or managed-cloud beta users? Hold them up against the profile. Do they fit?

Then mine the data signals only COSS companies get. Tools like Scarf track package downloads. Telemetry surfaces corporate IP addresses hitting your docs. If your repo has hundreds of stars from users at known companies, cross-reference their email domains and LinkedIn profiles. The disconfirming case is the valuable one. If your hypothesis was “mid-sized banks” but your first five commercial inquiries came from e-commerce, that’s not noise, that’s the market telling you where willingness to pay actually clusters. Segment by quantifiable criteria and follow the money.

Pin down the commercial use case

Flesh out the why-do-they-pay-us half. Talk to your power users and ask the uncomfortable questions. What’s the hardest part of self-hosting this? How many hours a week does your team lose maintaining it? What would a fully managed version with SLAs be worth to you? Their answers confirm whether the pain you think is urgent really is. Sometimes the enterprise feature you assumed was the unlock (advanced analytics, say) barely registers, and something duller, seamless SSO, turns out to be what frees the budget.

Map the buying committee

In B2B, almost no one buys alone, and in COSS the split is sharper than usual. Name the roles at the ICP level. For mid-market tech companies that might be a Lead DevOps Engineer (the champion who loves the open-source), a Head of Platform (the buyer who cares about scale), and a CISO (the approver who cares about SOC2). Map them now, so when you go to market you know whose radar to land on for the commercial pitch instead of preaching to the developer choir.

Keep it alive

Treat the ICP as a living document. Once you’ve launched the commercial tier and started selling, revisit it every quarter. Are your best paying customers the ones you predicted? Do they share traits you never saw coming? Over time you should drift from an intuition-driven ICP to a data-driven one. Maybe you discover that companies over 500 employees churn off your managed cloud because they’d rather self-host the enterprise version in their own VPC. That’s not a disappointment. It’s a signal to adjust either the ICP or the delivery model. Keep it tethered to reality and it stays useful.

ICP versus persona

One distinction to settle before moving on, because these two get conflated constantly. The ICP defines the company: its characteristics, the overarching commercial problem, the key buyer role. Buyer personas define the individual people and their daily motivations inside those companies. ICPs tell you which companies to pursue. Personas tell you how to sell to the humans inside them.

You need both. A company can match your ICP perfectly and you’ll still lose the deal if you pitch open-source developer experience to a CFO, or use messaging that lands nowhere near the real buyer. Run it the other way and you can win an open-source contributor’s heart completely, but if her company has no budget and no enterprise need, that’s effort spent on a deal that was never going to close. What you want is the right company profile aligned with the right internal personas.

The dual-engagement problem

Defining an ICP in commercial open source is hard for one structural reason that ordinary software companies never face: two kinds of people live inside the same target organization. Community users who adopt freely. Enterprise buyers who sign contracts. Your ICP has to bridge them. You’re hunting for organizations that have both the technical users who’ll pick up the tool for free and the institutional willingness to pay for more.

HashiCorp’s Terraform is the textbook case. It spread like wildfire among ops engineers, the community users, across thousands of companies. But HashiCorp’s paying customers, the true ICP, were only the companies that hit a scale where they genuinely needed collaboration, state governance, and role-based access control. Wide adoption, narrow monetization, and the gap between them was the whole business. HashiCorp said as much in its IPO filing, flagging the risk of failing to convert open-source users into paying customers as a core business concern. When a company writes that into an S-1, believe them. The conversion is the hard part, not the adoption.

So your COSS ICP has to read in two tiers. Something like: enterprise IT organizations, 1,000-plus employees in regulated industries, with a platform-engineering team running our open-source core in production today; these are the companies likely to pay for advanced security, compliance, and 24/7 support SLAs. That captures the who (the enterprise org), the what (the technical team on the open-source), and the why (regulation and scale forcing the need for enterprise features).

Whatever else you cut, don’t cut the champion. In a bottom-up open-source model, no enterprise deal closes without an internal technical advocate carrying you up the chain. The community user isn’t a step on the way to the real customer. The community user is how the real customer ever hears your name.

As a commercial open source founder, you face a pricing and packaging challenge that traditional SaaS founders do not: your biggest competitor is often your own free product.

When your baseline offering is a fully functional, highly capable open-source project that developers can clone, deploy, and run for free, your commercial packaging must be exceptionally strategic. Packaging determines how you structure product versions, feature bundles, and usage limits. Done well, it creates a seamless journey from enthusiastic community user to high-paying enterprise customer, maximizing revenue while keeping your developer ecosystem healthy. Done poorly, it either alienates the community that created your momentum through the dreaded “crippleware” trap, or leaves millions of dollars on the table by giving away enterprise value for free.

Think of packaging as creating the “menus” for your commercial entity. The goal is to make choices intuitive, aligned to customer budgets, and tailored to specific organizational needs. In commercial open source, packaging is the mechanism that separates the user, usually the developer, from the buyer, often the engineering manager, VP, CISO, or procurement team.

This guide explains how to package a commercial open-source offering to drive adoption, protect the community, and accelerate revenue.

The COSS “Good-Better-Best” Strategy

Successful B2B software companies overwhelmingly rely on tiered pricing. In commercial open source, this usually appears as a three- or four-tier model, with the open-source project serving as the foundational layer. This “Good-Better-Best” structure creates a bridge between grassroots developer adoption and enterprise monetization.

A small set of well-defined tiers makes it easier for customers to place themselves in the right option. Too many choices create analysis paralysis. A typical COSS lineup provides a clear baseline through the open-source core, an enhanced commercial version through a managed cloud offering, and a deluxe version through enterprise self-hosted or dedicated cloud. This helps buyers self-identify. A small team with no budget and time to operate infrastructure may choose OSS, while a bank that needs SOC 2 compliance and SSO will quickly recognize that it needs Enterprise.

Each tier should map to a different level of organizational maturity and willingness to pay. Smaller startups often pay for convenience. Large enterprises pay for risk mitigation, compliance, governance, and scale. Every step up in tier must add meaningful, justifiable value rather than arbitrary restrictions.

The strongest strategic reason for tiered packaging is expansion revenue. Your open-source project might first land inside a startup when the company has five people. As the company grows to 50 engineers, the team needs collaboration features and managed infrastructure, which pushes it toward a mid-tier plan. As the company becomes more mature or more regulated, it may need compliance logs, custom SLAs, and enterprise security controls, which pushes it into Enterprise. Good packaging nudges this progression by design.

When defining tiers, each tier needs a clear job, buyer persona, and target segment. The open-source tier is the community workhorse. It is designed for individual developers and hobbyists, and its job is distribution, market education, and top-of-funnel lead generation.

The Managed Cloud or Pro tier is the entry-level commercial offering for SMBs and mid-market teams. Its job is to monetize convenience. You are effectively selling teams their weekend back by managing infrastructure for them.

The Enterprise Cloud tier is the high-end SaaS offering. Its job is to capture larger teams that want a managed service but also require advanced security, VPC peering, role-based access control, and stronger operational assurances.

The Enterprise Self-Hosted tier is designed for highly regulated industries, air-gapped environments, and Fortune 500 companies. Its job is to generate high-ACV, sales-led enterprise revenue.

The differentiation between these tiers must be obvious. If a CISO cannot immediately understand why the Enterprise tier is necessary, you have a packaging problem.

Defining the Boundary Through Buyer-Based Open Core

The hardest packaging decision in commercial open source is deciding what belongs in the free open-source project and what belongs behind a commercial paywall. This is the core tension of the open core model.

The most useful framework is Buyer-Based Open Core, popularized by companies like GitLab. Instead of gating features based on how advanced or technically impressive they are, you gate them based on who needs them.

If a feature helps a single developer write code, deploy a service, or solve a technical problem, it belongs in the open-source tier. Core performance features, CLI tools, basic APIs, and foundational integrations should remain free. If you gate the core engine, the community may fork you or abandon you.

If a feature helps a manager coordinate a team of developers, it belongs in a commercial team or pro tier. This includes team dashboards, basic role-based access control, collaboration features, and historical reporting.

If a feature helps a director or VP manage multiple teams or scale infrastructure across a department, it belongs in a higher commercial tier. This includes advanced analytics, multi-environment deployments, and infrastructure-as-code integrations.

If a feature mitigates legal, security, compliance, or operational risk for the whole company, it belongs in Enterprise. SSO through SAML, Active Directory integration, audit logs, compliance reporting, and custom SLAs are executive-level requirements. They are purchased by organizations with large budgets and little tolerance for risk.

This framework aligns packaging with willingness to pay. A solo developer will rarely pay for SAML SSO, but a Fortune 500 CISO may refuse to approve software without it. Using the buyer persona as your compass lets you build a serious enterprise business without degrading the open-source developer experience.

A useful analogy is the “Tiffany Store” approach. Tiffany & Co. can sell accessible luxury and high-end diamonds in the same store because the experience helps customers self-select. Your COSS pricing page should do the same. A clear separation between self-serve cloud offerings that may start around $50 per month and a “Contact Sales” Enterprise tier signals that both grassroots teams and large corporations are welcome.

Feature Gating and Usage Limits

Packaging is not only about organizing features. It is also about engineering incentives to upgrade. Feature gating and usage limits are two of the strongest tools available to a COSS founder. The objective is to provide immense value in the open-source or entry-level tiers while creating natural friction points that trigger commercial upgrades.

Feature gating means certain capabilities are unlocked only in commercial tiers. In open source, this must be handled carefully.

You should not gate features that drive fundamental engagement, network effects, or core utility. If a capability makes your product more central to a developer’s workflow, it often belongs in open source. For example, basic integrations such as Slack alerts or GitHub actions can increase retention and overall dependence on your technology. That dependence may later create commercial upgrades based on scale, security, or operational needs.

The features worth gating are the ones that solve organizational pain, not individual technical pain. If you build an open-source database, the core query engine, speed, and standard drivers should be free. But point-in-time recovery, automated multi-region backups, advanced performance monitoring, and compliance reporting address organizational requirements. Keep the must-haves free to win developer adoption. Gate the security, scale, governance, and operational capabilities that buyers care about.

Avoiding the Crippleware Trap

The fastest way to destroy a COSS company is to artificially limit the open-source version until it is unusable in production. This is the “crippleware” trap. If your OSS project limits how much data users can process or artificially throttles CPU performance, developers will see it as a thinly veiled sales pitch rather than a genuine open-source project.

In the open-source tier, limits should be bound by the user’s hardware and operational capacity, not by arbitrary software locks. If users want to scale the OSS version to handle petabytes of data, they should be able to do so if they are willing to wire together the infrastructure, manage the nodes, and handle outages themselves. The upgrade trigger should be the pain of managing that scale, not an artificial kill switch in the code.

Usage limits are much more appropriate in managed cloud offerings. When developers tire of hosting the OSS version themselves, they may turn to your managed SaaS. In that context, limits on compute hours, storage, active users, API calls, or data volume are essential growth mechanisms.

The best usage metric aligns with the value the customer receives. If your product is a message broker, charging by message volume can make sense. If it is an analytics database, charging by compute time or data scanned may be more appropriate. This ensures your revenue scales with delivered value.

Usage paywalls also create a compelling event for conversion. When a team hits a limit after relying heavily on your managed cloud, it has an immediate reason to upgrade. The product itself triggers the upsell without a hard sales pitch.

The entry-level cloud tier must be generous enough for a small team to use in production, but constrained enough that a scaling mid-market company eventually outgrows it. If the lower tier is too generous, users never pay. If it is too restrictive, they may simply return to self-hosting the OSS version.

Bundles, Add-Ons, and Premium Support

Beyond tiered packages, COSS companies often use bundles, add-ons, and support packages to maximize revenue and capture specific enterprise budgets. This allows you to upsell power users without complicating the core packages for average buyers.

Not every capability needs to be included in a predefined package. Optional add-ons give sales teams flexibility to tailor deals and extract value from specific use cases. Good add-on candidates are features that a small subset of enterprise customers value highly but the broader market does not need.

Advanced compliance modules such as HIPAA or FedRAMP packages are strong add-ons because only regulated industries need them, and those buyers are used to paying premiums. Proprietary connectors can also work well. If you build an open-source data integration platform, the core framework and standard database connectors should remain free, while premium connectors to legacy systems such as SAP or Oracle can be commercial add-ons. The companies using those systems usually have meaningful budgets.

Premium support and SLAs are also natural commercial offerings. In open source, support is fundamentally a commercial feature. Elevated support tiers such as 24/7 response times, dedicated Customer Success Managers, and architecture review sessions let you tap into operational budgets without changing the software itself.

As your product suite grows, bundling becomes a powerful cross-selling mechanism. If your open-source project evolves into a multi-product company with a core database, analytics visualization layer, and machine learning pipeline tool, you can price each commercial product separately while also offering an “Enterprise Data Suite” bundle at a strategic discount.

Bundling simplifies enterprise procurement. It is much easier for a CIO to sign one contract for a comprehensive suite than to manage three separate vendor approvals. It also strengthens your moat. The more of your stack an enterprise adopts through a bundle, the harder it becomes for a competitor to replace you.

The Open Source Land-and-Expand Motion

All of these packaging strategies culminate in the central COSS advantage: land-and-expand.

In traditional SaaS, marketing teams spend large sums trying to push leads into trials. In a successful COSS company, the open-source project does much of this automatically. Your packaging must support the journey from free download to seven-figure contract.

A typical account may begin when a junior developer at a Fortune 500 company downloads your open-source project to solve a specific problem. Because it is free, the developer bypasses procurement entirely. If the project succeeds and the team adopts it more broadly, they may choose your Managed Cloud tier rather than operating the infrastructure themselves. Usage limits scale naturally with their growing data or workload.

As the application becomes mission-critical, senior stakeholders appear. The VP of Engineering may require multi-region high availability. The CISO may mandate SAML SSO and audit logging. At that point, the account upgrades to Enterprise, moving from self-serve credit card usage to a negotiated annual contract.

The following year, the company may expand into a regulated use case such as healthcare data. Your sales team can then upsell a HIPAA compliance add-on and 24/7 premium support.

This transition only works if your packaging anticipates it. Each tier must be a logical stepping stone to the next.

A Practical Example: StreamOps

Imagine a COSS startup called StreamOps, an open-source event streaming platform.

StreamOps OSS is the free core streaming engine available on GitHub. It is fast, horizontally scalable, and includes standard APIs. It targets individual developers and architects who want to build streaming applications.

StreamOps Cloud Developer is the managed SaaS version. It is priced predictably by gigabytes streamed per month, includes seven-day data retention, and provides basic community support. It targets startups and small teams that want to build rather than manage infrastructure.

StreamOps Cloud Business includes higher usage limits, 30-day data retention, VPC peering, and role-based access control. It targets mid-market engineering managers running production workloads who need security boundaries between teams.

StreamOps Enterprise is available as dedicated cloud or a self-hosted enterprise binary. It includes SAML SSO, SOC 2 and HIPAA compliance tooling, multi-region replication, and a 99.99% uptime SLA. It targets directors, executives, and regulated enterprises.

StreamOps does not gate the core speed of the engine, so developers can love and trust the product. But when a bank needs Active Directory integration and guaranteed failover, the Enterprise tier becomes a mandatory and high-value purchase.

The Core Principle: Gate Organizational Context, Not Developer Productivity

This is the question that breaks many open core companies. Get the boundary wrong in one direction and you have a great project with no business. Get it wrong in the other direction and you have a community revolt. The resolving principle is simple, but it requires discipline: gate on organizational context, never on developer productivity.

Developers choose tools. Procurement teams buy software. Your free tier must serve the person who makes the choice. Your paid tier must serve the person who writes the check. These are different people with different needs.

An individual developer needs a working product, documentation, extensibility, integrations, and basic security and authentication. An enterprise procurement team needs SSO enforcement, audit trails, governance controls, SLA guarantees, security certifications, and compliance evidence.

Enterprise needs exist almost entirely in organizational context. They require multiple users, centralized administration, compliance frameworks, procurement processes, and risk management. Individual developers do not usually encounter these needs. Gating them does not impede developer adoption. Instead, it creates a natural upgrade path when that developer’s company formalizes its use of your product.

The Enterprise Feature Matrix in Prose

Identity and access features are among the cleanest examples of enterprise gating. SAML SSO enforcement is an enterprise-only requirement tied to systems like Okta and Azure AD. Individual developers rarely need it, so the risk of gating it is low. SCIM provisioning and deprovisioning are also relevant only at organizational scale. Fine-grained project-level RBAC can be more nuanced: community users may need basic RBAC, but advanced permissions for multi-team coordination can reasonably live in paid tiers.

Governance features also map naturally to enterprise plans. Immutable, long-retention audit logs are driven by compliance mandates such as SOC 2, ISO 27001, and HIPAA. Basic logs should remain available, but compliance-grade auditability is a buyer requirement. Policy-as-code, data retention policies, and similar controls belong in paid tiers because they are used by organizations managing risk across teams.

Security features such as FIPS 140-2 compliance, bring-your-own-key encryption, external key management, CVE SLAs, and priority security patches are all enterprise-oriented. They are required by government, regulated industries, or high-security buyers rather than individual developers.

Multi-tenancy and administrative controls also belong largely in enterprise packaging. Organization-level management consoles, multi-region or geo-distributed deployment, tenant isolation controls, and multi-team governance are admin requirements, not developer workflow requirements.

Advanced analytics and reporting can also be gated when they serve buyers rather than users. Usage dashboards, custom reports, exports for procurement, and compliance reporting are typically needed by management, finance, security, or legal teams.

Support and SLAs are even more straightforward. Priority support, dedicated customer success, and 99.99% uptime guarantees are commercial services. They do not restrict the code, and they map directly to enterprise procurement needs.

What Not to Gate

Gating features that individual developers genuinely need creates community resentment and long-lived criticism. The “feature gap problem” is real: when core operational features are gated, trust in the entire product erodes.

Do not gate core functionality that makes the product work for a single user or small team. Do not gate basic security features such as OAuth2 or OIDC authentication mechanisms and basic role assignment. Do not gate basic logging, though compliance-grade immutable audit logs can be paid. Do not gate key developer APIs, standard integrations, or basic SSO protocols such as OIDC and OAuth2. SAML enforcement is different because it is genuinely enterprise-oriented.

The goauthentik case study is instructive. Authentik does not gate core SSO features such as OIDC, API access, or service accounts because those are table stakes for modern security and community users need them. It gates corporate auditor checklist items such as FIPS compliance, compliance-related logging, and enterprise identity provider migration tooling. The principle holds: if a developer needs it to do their job, it stays free; if a compliance auditor needs it to approve the vendor, it can be paid.

GitLab applies a similar logic. Core CI/CD, issue tracking, and code review belong in the community edition. Security scanning, compliance dashboards, and advanced CI/CD automation belong in enterprise tiers.

The Complexity Line Framework

Think of your product’s features along one dimension: organizational complexity. Features that manage complexity in a single developer’s workflow belong in free. Features that manage complexity across organizational governance, compliance, or multi-team coordination belong in paid.

Core product functionality, basic integrations, APIs, community support, reasonable usage, basic authentication, self-managed deployment, and single-user or small-team workflows should remain open or broadly accessible.

Enterprise plans should capture organization-level administration, SAML and SCIM, priority support, higher limits, advanced auditability, FIPS, BYOK, air-gapped deployment, GovCloud support, and multi-team or multi-organization governance.

When unsure, ask whether a solo developer at a five-person startup would ever need the feature to get value from the product. If yes, it belongs in free. If the honest answer is that only organizations dealing with compliance, governance, procurement, or multi-team scale need it, then it belongs in paid.

GitLab’s Buyer-Based Open Core Philosophy

GitLab made explicit what many open core companies leave implicit: features are tiered based on who buys them, not based on their technical category.

Features individual contributors need belong in Free or Community Edition. Features engineering managers and directors need belong in Premium. Features executives, CISOs, and compliance teams need belong in Ultimate or custom enterprise plans.

This framework is powerful because it is community-defensible. Developers do not usually buy GitLab, so the features developers need for their workflow stay free. The people who write the check pay for the features they care about.

GitLab also made a public commitment that became a major trust signal: when a feature is open source, it will not be moved to a paid tier. That promise directly addresses the biggest fear in open core models, which is the bait-and-switch where community editions become progressively crippled. The trust created by that commitment can be worth more than any individual feature gate.

Subscribe now

The Onion Approach to Tier Design

Think of the product as concentric layers.

The core layer is open source. It contains what makes the product useful to any individual developer and explains why they installed it in the first place. If this layer is weak, nothing else matters.

The professional layer serves small coordinated teams. It includes collaboration, shared state, basic governance, and team-level workflows.

The enterprise layers add progressive organizational capabilities. Each layer serves another stakeholder whose approval is required for formal enterprise deployment, including security, compliance, legal, procurement, and executive leadership.

OpenProject expresses this idea clearly: Enterprise does not replace Community; it extends it. Enterprise add-ons are developed as open source software but enabled only on Enterprise plans. This lets community developers read, audit, and understand the enterprise features even if they cannot activate them without a license. That transparency builds trust around the gated layer.

The Compliance Upsell Pattern

Compliance is the most durable and defensible enterprise gate because it is created by external regulatory requirements rather than arbitrary product decisions. Charging for SOC 2 audit reporting, HIPAA compliance logging, FedRAMP-certified deployment, or enterprise-grade auditability is easier to defend because these features do not exist in individual developer contexts. They are procurement requirements driven by organizational governance.

The pattern usually begins when an individual developer adopts the free or community product. As the company grows, or as the product is adopted by a larger enterprise, IT, security, or legal teams begin formal evaluation. During that evaluation, compliance requirements emerge. The organization may need SSO enforcement, audit logs, a Business Associate Agreement for HIPAA, or specific data retention guarantees. Those requirements live in the Enterprise tier.

The upgrade conversation then changes. You are not saying, “We want to sell you more software.” You are saying, “Your organization’s compliance requirements require these capabilities, which are part of Enterprise.” That is a much stronger sales motion because compliance requirements are often non-negotiable in regulated industries. You are not selling a productivity improvement; you are clearing a legal or security checkbox.

Pricing Page Examples

GitLab’s pricing structure moves from Free, with unlimited public repositories, CI/CD, and DevSecOps basics, to Premium at approximately $29 per user per month for enterprise agile planning, advanced CI/CD, and code insights, and then to Ultimate for enterprise security, compliance, and advanced analytics. Its buyer-based logic is explicit because the tiers are described by organizational need and role.

Grafana Labs moves from a free tier with limited retention and community support to Pro, Advanced, and Enterprise plans. Its structure builds usage-based expansion into the model, with higher tiers adding longer retention, volume discounts, SLAs, SAML, RBAC, and advanced security.

MongoDB separates its free Atlas shared clusters, dedicated usage-based cloud clusters, and Enterprise Advanced offerings. This creates a clear distinction between cloud adoption and enterprise on-prem or bring-your-own-cloud requirements.

Confluent uses a similar progression from developer usage to standard usage-based plans, advanced governance, bring-your-own-cloud, and enterprise plans with dedicated infrastructure, compliance, and SLAs. Its elastic compute model aligns cost with value for streaming workloads.

Final Takeaway

The line between free and paid in open core should be drawn at organizational complexity, not feature richness.

If your enterprise tier includes features individual developers genuinely need, such as basic SSO, core APIs, or standard logging, you are crippling your adoption funnel and inviting community resentment. If your community tier includes features that only appear on enterprise procurement checklists, such as SAML enforcement, compliance audit logs, multi-org governance, and regulatory reporting, you are leaving significant revenue on the table.

Packaging is not a static spreadsheet exercise. It is a core part of company strategy and product positioning. In commercial open source, packaging determines how the community perceives you and how enterprises value you.

Keep the tier structure simple, with three or four clearly defined levels at most. Protect the core utility of the open-source project so it can continue serving as your distribution engine. Monetize organizational complexity, security, compliance, governance, scale, and support. Keep developer productivity free.

When designed well, the open-source project becomes an unstoppable wedge, and the commercial packaging becomes a frictionless ladder from developer enthusiasm to scalable enterprise revenue.

Your license is your contract with the market. It is your business model enforcement mechanism. Define it early. Be transparent about your boundaries. And remember: You can always make a restrictive license more permissive later, but making a permissive license more restrictive is a painful, trust-burning one-way door. Measure twice, cut once.

Your license choice is one of the most important decisions you’ll make in the life of your company. If you get it wrong in one direction, you undermine your community by being overly restrictive, strangling the top-of-funnel adoption that makes the COSS model so powerful. If you get it wrong in the other direction, you hand your revenue directly to hyperscale cloud providers by being too permissive. Let’s strip away the legal hedging and philosophical debates. We are going to look directly at what these licenses actually do in the market, how they shape competitive dynamics, and how you must use them to defend your enterprise.

The permissive trap

When a founder writes their first line of code, their primary objective is adoption. They want developers to use their tool, love their tool, and share their tool. Consequently, developers instinctively reach for permissive licenses. Recent data from the Open Source Initiative (OSI) confirms this enduring psychological default: in 2025, the MIT license remained the most-viewed license in the world with over 1.5 million pageviews, followed distantly by Apache 2.0 with 344,000.

The gap between this permissive instinct and commercial reality is the central crisis of the modern COSS ecosystem. Starting with an MIT or Apache 2.0 license maximizes initial adoption and friction-free distribution because it provides absolute freedom. These licenses allow anyone to embed your code into any commercial product without restriction. However, they provide precisely zero legal protection against commoditization.

As of Q4 2025, AWS, Azure, and Google Cloud together held sixty-three percent of the global cloud market and generate $119 billion in quarterly cloud infrastructure revenue. These are the apex predators of the internet. If your permissively licensed infrastructure tool achieves widespread popularity, it will inevitably attract their attention. The pattern is painfully consistent: you spend years building a massive open-source ecosystem; a hyperscaler launches a managed service wrapping your exact code without contributing a single commit back to the core project; your enterprise buyers default to the hyperscaler because the spend is already committed in their multi-year enterprise discount programs; and finally, you are starved of the very managed-service revenue you created. You must plan your defense before they arrive, not after they have integrated your life’s work into their cloud console.

From copyleft to network defense

To defend your business, you must understand the mechanics of the traditional open-source spectrum beyond permissive licenses. Moving up the ladder of protection, we encounter weak copyleft licenses like MPL 2.0 and LGPL. The key characteristic of these licenses is that any modifications made specifically to the licensed files must be shared back with the community. However, the enforcement mechanism is limited strictly to the file level, meaning a hyperscaler can easily build a proprietary control plane around your unmodified open-source core without triggering any obligation to share their lucrative management software.

Strong copyleft, GPL 2.0 and 3.0, escalate the defense. Any software that incorporates GPL code must itself be GPL, and the trigger is distribution: ship the software, share the source. But the modern cloud broke that lever. Hyperscalers don’t distribute software. They host it, and hosting isn’t distribution. This massive loophole gave rise to network copyleft licenses, specifically the AGPL v3.

AGPL v3 is the strongest fully OSI-approved license available. It extends GPL to network use, so a company that modifies an AGPL application and offers it as a service is legally compelled to share its modifications. In theory that puts enormous pressure on cloud providers and forces their proprietary wrappers into the open. In practice the corporate reaction was swift and brutal. Because AGPL is viral, it’s banned across much of the enterprise. Many Fortune 500 companies maintain blanket policies forbidding any AGPL dependency, on the reasoning that one bad import could infect their proprietary code. So AGPL protects you against cloud providers and, in the same stroke, throttles the enterprise adoption you were counting on. Strong defense, narrow doorway.

Source-available and fair source

Because traditional OSI-approved licenses either failed to protect revenue (Apache/MIT) or triggered enterprise procurement bans (AGPL), a new category of “source-available” licenses emerged to thread the needle. These are not technically “open source” by OSI definitions, but they provide the community with source code access while erecting commercial firewalls.

MongoDB invented the first of these, the Server Side Public License, later adopted by Redis. The SSPL is a poison pill aimed squarely at hyperscalers. It adds one devastating clause beyond AGPL: any company offering the software as a managed service must open source its entire infrastructure stack, not just its modifications. Because no hyperscaler will ever open source their proprietary operational backend, it practically outlaws third-party managed services without a commercial agreement. It is incredibly powerful, but major Linux distributions immediately removed MongoDB packages upon its adoption, and the ecosystem backlash was severe.

More recently, the Business Source License (BSL 1.1) became the most widely adopted source-available license, largely popularized by MariaDB, CockroachDB, and heavily utilized by HashiCorp. BSL is generally considered more “enterprise friendly” because it allows free use for almost all internal commercial purposes. Its enforcement mechanism specifically restricts production use only if it is part of a competing managed service. Crucially, BSL requires that the code revert to a fully OSI-approved license, typically after four years. It does not force anyone to open-source anything; it simply buys the creator a temporary monopoly on cloud commercialization.

Elastic took its own route with Elastic License v2 (ELv2). This license cleanly bars SaaS use without the vendor’s permission and bars circumventing built-in license keys or usage limits. It avoids the viral “entire stack” complexities of the SSPL, making it an elegant, targeted weapon against cloud commoditization, though it is best suited for younger products where the risk of a massive community fork is lower.

The newest arrival is the Fair Source family, led by the Functional Source License (FSL) that Sentry adopted recently. FSL is built for SaaS companies that care about developer sustainability. It keeps the source available and protected from commercial competitors for two years, then converts automatically to permissive Apache 2.0 or MIT. Because it carries none of AGPL’s viral obligations, it sails through enterprise legal review.If you are building a SaaS application rather than an on-premise infrastructure tool, FSL is a masterclass in balancing commercial defense with long-term open-source contribution.

Working the decision in order

Choosing a license is a sequence of business questions, and the order matters.

First, coldly evaluate your commoditization risk. If you’re building core database infrastructure, an observability platform, or an event-streaming pipeline, AWS is coming for you, and you need protection. If you’re building a niche developer workflow tool with no heavy compute appetite, your risk is genuinely lower and you can lean toward permissive adoption.

Then look at how much your roadmap depends on outside contributions. If community pull requests are a real engine of your velocity, a heavily restrictive license like BSL or SSPL will scare off the enterprise contributors who write most of them.

Then look at how you ship. A pure SaaS company gets time-limited protection and enterprise friendliness from FSL. An on-premise infrastructure company has to weigh the OSI-approved purity of AGPL against the broader, more contested commercial protection of BSL.

The last question is the one founders skip and later regret: who owns the intellectual property? The choice is between a Contributor License Agreement (CLA) and a Developer Certificate of Origin (DCO). A DCO is light. It’s a one-line sign-off in a Git commit, developers like it, and it adds almost no friction. It also gives you no future flexibility, because you never consolidate the rights and so can never unilaterally relicense the project. A CLA is the opposite trade. It adds friction, and many corporate developers are forbidden from signing one, but it grants the commercial entity full IP rights over the aggregated codebase.

The answer here isn’t balanced, and it shouldn’t be. If there’s any chance you’ll need to change your license later, to fend off a hyperscaler, to clean up before an IPO, or to position for an acquisition, you must institute a CLA on day one. HashiCorp’s pivot to BSL, community fallout and all, was only legally possible because someone had the foresight to require a CLA.

The full spectrum

A reference map of the field, from maximum freedom to maximum defense.

OSI-approved licenses

License Type Key characteristic What enforces it MIT / Apache 2.0 / BSD Permissive Maximum freedom; embeddable in any commercial product Nothing; anyone can do anything MPL 2.0 / LGPL Weak copyleft Changes to licensed files must be shared back File-level copyleft only GPL 2.0 / 3.0 Strong copyleft Any software incorporating GPL code must be GPL Distribution triggers sharing AGPL v3 Network copyleft Extends GPL to network use; SaaS apps must share source Network use triggers sharing

Source-available and fair source

License Type Key characteristic What enforces it SSPL Source-available Offering it as a service requires sharing the entire stack Prohibits managed-service competitors in practice BSL 1.1 Source-available Restricts competing managed services; reverts to OSS after a set period Production use as a managed service is restricted Elastic License v2 Source-available Prohibits SaaS use and circumventing license restrictions Custom vendor license FSL Fair source Source-available for two years, then converts to Apache 2.0 Time-limited commercial protection

OSI license pageview data for 2025 shows MIT is still the most-viewed license (1.53M pageviews), with Apache 2.0 second (344K). Developers still start with permissive licenses. The gap between that instinct and commercial reality is the central problem this chapter addresses.

The source-available options, up close

Business Source License (BSL 1.1)

BSL is the most widely adopted source-available license since 2022. It allows free use for almost everything, including internal commercial use, and restricts only production use as part of a competing managed service. After a defined window, typically four years, it reverts to an OSI-approved license such as AGPL or MPL. And it imposes no copyleft obligation — nothing downstream has to be open-sourced.

Who runs it: HashiCorp moved Terraform, Vault, Consul, and Nomad to it in August 2023, alongside MariaDB and CockroachDB.

The verdict: BSL is the most enterprise-friendly of the source-available options because it permits most commercial use. Its weak spot, which HashiCorp found the hard way, is that it triggers forks on contact. OpenTofu launched within thirty days of the announcement. If your project is dominant enough that a foundation will back the fork (and the Linux Foundation backed OpenTofu), BSL buys time without permanently protecting your position.

SSPL (Server Side Public License)

SSPL was MongoDB’s invention and was later used by Redis before the Valkey fork. The SSPL adds one clause beyond AGPL: any company offering the software as a service must open-source its entire infrastructure stack, not just its modifications. That effectively bars cloud providers from offering a managed service without a commercial agreement because no hyperscaler will open-source its whole operations stack.

The verdict: powerful on paper, but not OSI-approved and widely treated as a non-open-source license. Major Linux distributions removed MongoDB packages after the change. The Redis switch triggered the Valkey fork, backed by AWS, Google, Snap, and others, which picked up adoption fast. SSPL works only if you can stomach the community and ecosystem cost.

Elastic License v2 (ELv2)

Elastic’s custom license (ELv2) is the most vendor-friendly of the bunch. It prohibits two things: SaaS use without the vendor’s permission, and circumventing built-in license or usage restrictions.

The verdict: ELv2 is cleaner and simpler than SSPL, with narrower restrictions, and no entire-stack open sourcing requirement. But Elastic’s own history shows the catch. Switching from Apache 2.0 to ELv2 prompted AWS to fork Elasticsearch into OpenSearch (Apache 2.0) and split the community for good. ELv2 fits products that are newer or less dominant, where fork risk is lower.

FSL (Functional Source License)

FSL is the newest major license in the category, adopted by Sentry in 2024 and others. It converts to Apache 2.0 or MIT after two years. Per FSL’s own site, it’s designed for SaaS companies that value both user freedom and developer sustainability.

The verdict: the most developer-friendly of the source-available options, thanks to that two-year sunset into fully open source. It carries no AGPL-style obligations, so it passes muster in enterprises where AGPL is banned. If you’re a SaaS company rather than an on-premise infrastructure product, FSL deserves a serious look.

AGPL v3, the strongest OSI-approved option

AGPL v3 is the strongest fully open-source license. Its key extension over GPL: any software that communicates over a network must share its source. In theory that pressures cloud providers running AGPL software to share their modifications.

The reality bites the other way. AGPL is widely banned in the enterprise because it’s viral, and many large companies forbid AGPL dependencies outright. So it protects you against cloud providers while capping your enterprise adoption. Elastic’s 2024 move, adding AGPL v3 as a third option alongside SSPL and ELv2, was a goodwill gesture to OSI-aligned developers, not a commercial pivot. The commercial default stayed ELv2.

Subscribe now

Case studies, and what they cost

HashiCorp to BSL, August 2023

The change: Terraform, Vault, Consul, and Nomad all moved from MPL 2.0 to BSL 1.1.

The trigger: stopping competing managed-service providers, Gruntwork, Env0, and Spacelift, from using the code commercially.

The outcome: OpenTofu launched within thirty days, backed by the Linux Foundation. Gartner put the industry re-tooling cost above $600M. IBM later acquired HashiCorp for $6.4B, a 54% discount to its $14B IPO valuation. The prevailing read is that the BSL change was meant in part to clean up the cap table before an exit. It worked in that narrow sense while dissolving the community moat that made HashiCorp worth the premium in the first place.

The lesson: a license change that fragments the community right before an exit destroys the trust-based moat that justified the price.

Elastic to SSPL/ELv2, January 2021, then AGPL, September 2024

The change: Apache 2.0 to dual SSPL/Elastic License in January 2021, then back to AGPL v3 in September 2024 alongside SSPL and ELv2.

The trigger: AWS launched Amazon Elasticsearch Service in 2015 and contributed little. By 2021, Elastic was bleeding cloud revenue to AWS.

The outcome: AWS immediately forked OpenSearch (Apache 2.0) and split the community for good. In August 2024, Elastic’s stock dropped 27% on weak cloud guidance, with OpenSearch pressure cited. The 2024 return to AGPL was a sound strategy since AGPL blocks managed-service extraction better than SSPL because it’s OSI-approved. It was also a public admission that the 2021 change had damaged community trust.

The lesson: never say you’ll never change your license, which is precisely what Elastic had said in public. And build your cloud offering before the cloud providers build theirs. Elastic Cloud launched in 2019. Four years after AWS Elasticsearch.

Redis to SSPL/RSALv2, March 2024

The change: BSD to dual SSPL/Redis Source Available License.

The trigger: AWS ElastiCache was capturing managed Redis revenue without contributing back. Underneath sat Redis’s 1% conversion problem: only 1% of Redis users ever became paying Redis Enterprise customers, while AWS earned ElastiCache revenue from the other 99%.

The outcome: the Valkey fork launched within weeks, backed by AWS, Google, Snap, Ericsson, and others, and again by the Linux Foundation. Enterprise migration was fast, and Redis’s community position weakened sharply.

The lesson: BSD-licensed infrastructure that becomes a cloud staple gets commoditized eventually. The relicense bought time at the cost of the community.

MongoDB to SSPL, October 2018

The change: AGPL to SSPL.

The trigger: AWS DocumentDB, MongoDB-compatible but not MongoDB, launched in 2018 and captured enterprise AWS customers who wanted compatibility without paying MongoDB.

The outcome: commercial success. Atlas grew from $100M annualized in 2019 to 75% of MongoDB’s $2.4B ARR in 2025. The trade, community damage for commercial protection, paid off because Atlas, not community-driven adoption, had already become the primary growth engine.

The lesson: if your business has already pivoted to managed cloud as its main growth engine, the SSPL’s community costs may be a price worth paying. MongoDB made that trade with open eyes, and it worked.

Ring-fencing the value into three layers

Trust requires clarity, and clarity means saying out loud which parts of your software live under which rules. This is a communication strategy as much as a legal one. It tells every user exactly where they stand. Three layers do the work.

Layer one: the commons

This is the engine of the flywheel, and it has to stay friction-free.

License: permissive, Apache 2.0 or MIT.

The promise: this code will always be free. Run it, inspect it, modify it, build on it. It includes the core runtime, the standard APIs, and single-node functionality.

The strategy: this layer optimizes for ubiquity. It drops the barrier to entry to zero and lets developers quietly bring your product into the enterprise without procurement approval. Choke this layer and you kill your own top-of-funnel.

Layer two: the enterprise product

This is where you capture value, and it aims at the organization, not the individual developer.

License: proprietary or source-available, such as Polyform, ELv2, or a commercial EULA.

The promise: these features are for companies operating at scale. They solve organizational, compliance, security, and governance problems. They are paid.

The strategy: this layer monetizes complexity and risk. Single Sign-On, audit logs, role-based access control, and multi-region replication all belong here. The individual developer does not care about SSO. The Chief Information Security Officer does, and the CISO is who you’re selling to.

Layer three: the cloud shield

This is the defense against a hyperscaler taking your code, selling it as a service, and contributing nothing.

License: copyleft (AGPL v3) or Business Source License.

The promise: you cannot wrap our code in a cloud service and resell it against us without contributing back or paying a license fee.

The strategy: this is what stops the Amazon problem. If a cloud provider wants to monetize your R&D, it has to either open-source its entire stack, which it won’t, or come negotiate a commercial partnership.

The rug pull and how not to do one

The most damaging move in the COSS world is the rug pull: build a large community on a permissive license like Apache, then flip overnight to something restrictive like BSL to force monetization. It reads as betrayal, and it taxes exactly the hobbyists and early adopters who built your success.

Sometimes you genuinely have to change licenses to survive, say moving from Apache to BSL to stop a cloud competitor. When you do, integrity is the difference between a hard pivot and a rug pull. Four rules hold the line.

Exempt the little guy. Make the new license permissive for non-commercial use, development, and companies under a revenue threshold. You’re targeting the whales, not the minnows.

Honor the legacy. Never retroactively relicense old versions. Code that was free stays free. The new terms apply only to future versions.

Give notice, in plain words. Explain the economics, not the legalese: we need to protect our ability to invest in R&D against cloud providers who strip-mine our work, and this change is how we keep building the best product for you.

Never bait and switch. Don’t move features from the free tier to the paid tier. That’s the cardinal sin. The only direction you may move a feature is from paid to free.

CLA versus DCO, in practice

The choice between a Contributor License Agreement (CLA) and a Developer Certificate of Origin (DCO) is a strategic one, not a paperwork detail to delegate to outside counsel. Both govern how IP from outside contributors flows into your project. They determine what rights your company holds over code other people commit and what every contributor has to agree to before their code lands. It decides whether you can adapt your business model five years from now or sit paralyzed by fragmented IP. You can’t maximize commercial optionality and community velocity at once. You have to choose.

A CLA is a formal contract a developer signs before any code merges. Signing it grants your company broad rights over the contributed code, often including the right to relicense it, dual-license it, or use it in proprietary products. The IP consolidates under your roof, and that buys you commercial agility. Because you control the aggregated rights to the whole codebase, you can change the open-source license later on your own authority. When a hyperscaler starts strip-mining the project, or when an IPO requires ring-fencing the commercial offering, the CLA is what lets you pivot. HashiCorp’s move to BSL was possible only because it had one. The cost is friction. CLAs are heavy, many enterprise developers are barred by their legal departments from signing them, and requiring one lowers your raw contribution volume.

A DCO is the lightweight alternative the Linux kernel popularized. There’s no document to sign. A developer adds a Signed-off-by line to the commit message, asserting only that they wrote the code or have the right to contribute it under the project’s existing license. Developers love it, it rarely trips corporate legal alarms, and if your goal is to grow the ecosystem and aggregate contributions fast, the DCO is the gold standard. The cost is total. A DCO transfers no broad rights, so the IP stays fragmented across every contributor, and you can’t relicense later without tracking down each one. Launch on Apache 2.0 under a DCO, and when AWS commoditizes you three years on, switching to a protective license means getting explicit permission from everyone who ever committed. That isn’t a hard task. It’s an impossible one.

For a venture-backed COSS company the recommendation is clear: a CLA is usually necessary to preserve the option for dual-licensing or defensive relicensing.

How to actually execute

Don’t let lawyers pick your license. Your business model picks it. An open-core model needs a permissive core and a proprietary wrapper. A dual-licensing model, selling exceptions to GPL, needs a copyleft base. Lawyers optimize for risk. You have to optimize for leverage.

Gate features by buyer versus user. When you decide which features go in the free core and which go in the paid tier, ask who the feature serves. Does it help an individual developer build an app, the CLI, local testing, and raw speed? Make it free. Does it solve a problem for a manager, an auditor, or a VP, compliance, reporting, or team management? Make it paid. The developer is the user. The manager is the buyer, and the buyer is who pays.

Manage copyright deliberately. A CLA hands you the rights to relicense later, at the cost of contribution friction. A DCO keeps contribution easy at the cost of relicensing freedom. For a venture-backed company that may one day need to launch an enterprise edition or defend against a hyperscaler, the CLA is usually the right call.

Let the business model dictate the legal strategy, never the reverse. Default to AGPL v3 when you need the strongest OSI-approved protection against hyperscalers and can absorb the enterprise procurement friction that comes with it. Default to MIT or Apache 2.0 only when ubiquity is the whole game and cloud extraction risk is genuinely low. Look hard at FSL if you’re a modern SaaS company looking for a principled path to commercial sustainability. The license is the one decision you make under no pressure and live under for years. And the asymmetry never moves: loosening is free, and tightening is the door that swings one way.

Subscribe now

GitHub stars don’t pay the bills. Neither do fork counts or Docker pulls. They’re the best top-of-funnel signal a commercial open-source founder will ever get, and they tell you almost nothing about the size of the business you can build. Every credible go-to-market plan starts somewhere less flattering, with an honest count of the people who will actually open their wallets.

Total Addressable Market (TAM) is that count, expressed as a ceiling. It’s the revenue you’d book if you won every enterprise customer on earth who could buy your commercial offering, the theoretical top of your business rather than your project. Two things hang on the number. It sets the line you draw between the free tier and the paid one, and it’s the figure an investor uses to decide whether your model can return a venture-scale fund.

Most founders get TAM wrong in the same direction, upward. Your open-source database does not have a TAM of $100 billion just because that’s what the world spends on databases. That slide looks impressive until someone asks how close you are to displacing Oracle or AWS, and the answer is “not close.” A TAM built on total community downloads is a vanity number. It aims your sales budget at people who were never going to pay, and it drains the runway you raised to find the ones who would.

You run two funnels at once. The community funnel feeds on free downloads, stars, and developer goodwill. The commercial funnel feeds on enterprise features, managed cloud, and SLAs. Confusing the two is the original sin of COSS finance, and experienced investors smell it on contact, because claiming the entire database spend as your market is the same as admitting you can’t tell a free user from a buyer.

A tight definition does the opposite. It keeps your strategy anchored to the slice you can actually win, and it proves to a board that you did the arithmetic before you asked for the check.

The crowd at the door is not the market

Open source democratizes technology, which is the whole point and also the source of the confusion. Your software gets downloaded by students, hobbyists, weekend tinkerers, three-person startups, and the Fortune 50, all from the same release page. That produces an enormous pool of Total Addressable Users, basically every developer who could benefit from running your code for free. Your TAU dwarfs your TAM. Always.

Your TAM is the much smaller subset who work somewhere with the budget, the operational scale, and the specific pain that needs your paid offering. The crowd at the door isn’t the market. It’s the reason the market exists at all.

The classic mistake is multiplying total deployments by enterprise contract value. A hundred thousand active open-source deployments times a $50,000 enterprise tier looks like a $5 billion TAM, and it’s a mirage. Somewhere between 95 and 99 percent of those deployments will never send you a dollar, which is open source working exactly as designed. Your free users are your marketing engine and your QA department. They aren’t your buyers.

Getting to a real number means running those users through a brutal, realistic conversion filter.

Your pricing model decides your market

In traditional SaaS, TAM is close to a multiplication problem: companies that need the software times the subscription price. In COSS, the number swells or collapses depending on how you decide to charge for free code. Pick the vehicle before you run the math.

The support-and-services model is the Red Hat path. You give the software away and sell SLAs, training, and emergency patches. The customer base is wide, but contract values stay low, margins stay thin, and your ceiling is whatever companies will pay for insurance against their own infrastructure.

Open-core is the path Elastic and GitLab took. The core is free, and the enterprise features live behind a license: SSO, RBAC, compliance reporting, and high availability. Contract values climb, but the market narrows to mid-market and enterprise buyers with real security and compliance obligations. A ten-person startup never enters your TAM because nobody that small needs row-level access control.

Then there’s managed cloud, the MongoDB Atlas and Confluent path, which usually produces the largest and most defensible market of the three. You stop selling features and start selling uptime and the elimination of a DevOps payroll line. The market widens at both ends, small companies that lack the talent to self-host, and large ones that would rather hand off the operational burden than staff for it.

Whatever you pick, the TAM has to reflect its pricing and its limits, not a generic count of everyone who could install the thing.

Three ways to size it

You have three methods, and a COSS founder needs all three, because each one answers a different person in the room.

The analyst filter, from the top down

Top-down starts wide and narrows. You find a Gartner or Forrester line that reads “global enterprise spend on monitoring and observability is $15 billion a year,” and you carve it down.

A generic startup says “capture 5 percent and the TAM is $750 million” and stops there. A COSS founder keeps filtering. Start with the $15 billion. Strip out the spend locked into legacy proprietary mainframes that will never touch open infrastructure; if 40 percent of the market is actively modernizing, you’re down to $6.0 billion. Then ask how much of that $6.0 billion belongs to organizations willing to pay a vendor for managed open source rather than running it themselves. Call it 30 percent, and the top-down number lands at $1.8 billion.

This view is fast and imprecise by construction. It rests on broad assumptions about how a whole market behaves, which makes it useful for a sanity check or a macro vision and dangerous as a sales quota. Use it to prove the market is real. Don’t let anyone on your team carry it into a forecast.

The open-source funnel, from the bottom up

Bottom-up is the method that wins Series A rooms. You build the number from your own community data and a sharp Ideal Customer Profile, unit by unit, and the act of building it proves you know exactly who buys and what they pay.

The equation is a chain of filters:

TAM = (target organizations) × (share with the specific pain) × (COSS conversion rate) × (average contract value)

Walk it with real numbers. If your tool requires Kubernetes, your universe is companies running Kubernetes in production, say 50,000 mid-market and enterprise accounts worldwide. Now the pain filter. Your commercial product does multi-region replication, which only matters to companies large enough to need multi-region setups, so 20 percent qualify and the pool drops to 10,000. Then the conversion rate, which is the number that actually governs your business. Of the companies that need the technology, how many pay rather than self-host the free build? Successful open-core conversion runs 2 to 5 percent of the active base. Be aggressive, take 5 percent of these highly qualified orgs, and you get 500 paying customers. Price the managed enterprise cloud at a $50,000 ACV from early pilots or competitor benchmarks, and the chain closes:

10,000 qualified orgs × 5% conversion × $50,000 ACV = $25,000,000.

A $25 million beachhead sounds small to a founder dreaming in unicorns. It’s far more persuasive to a Series A partner than a fabricated $10 billion top-down claim, because it shows you know how to land your first 500 logos. Expansion comes later, when you add features, open new regions, or drop a self-serve tier that lowers the floor.

Value theory for the market that has no report yet

Value theory earns its keep when you’re creating a category, replacing a legacy giant, or solving a problem in a way nobody has named. Instead of carving up existing software spend, you price the problem itself. In open source, the problem usually gets measured in reclaimed engineering hours and infrastructure you no longer have to run.

The question to ask: if an enterprise adopts our managed open-source cloud, what’s the dollar value of the DevOps salaries, the downtime, and the legacy licenses they delete?

Picture a next-generation open-source vector database for AI workloads. No analyst tracks “vector database spend” yet, so you reason from value. Companies shipping AI features pay specialized engineers roughly $200,000 a year to hand-build data pipelines on databases that were never meant for the job. Your managed cloud removes half that custom work, saving $100,000 a year. Because you’re handing the customer $100,000 in hard value, a $30,000 ACV is easy to defend; it leaves $70,000 in their pocket. Estimate 15,000 companies actively deploying generative AI in your target regions, and the math is:

15,000 companies × $30,000 ACV = $450 million.

Value-based TAM is speculative, and without strong case studies it’s hard to hold under questioning. For founders leading a genuine shift, it’s often the only honest way to size an uncharted market. Be ready to defend, line by line, what a DevOps engineer’s time is worth to a CFO who would rather not believe you.

When the hyperscaler forks you

Every COSS pitch reaches the same question, and you should want it asked early. What happens when AWS, GCP, or Azure forks your project and runs it as a managed service? Does your TAM go to zero?

This is the recurring fear of commercial open source, and it isn’t paranoid. A hyperscaler that wraps your free code in its billing console can, in theory, take the entire managed-cloud market you just sized. It has happened. When Elastic relicensed Elasticsearch under the SSPL in 2021, AWS forked the last open version and shipped it as OpenSearch, billing console and all. A credible TAM doesn’t pretend the threat away. It shows the moat in the numbers.

Licensing is the first wall. A Business Source License or SSPL legally blocks the hyperscalers from offering your software as a competing managed service. It protects the market, and it costs you goodwill with the open-source purists, so price that trade deliberately. The second wall is the enterprise delta. Your commercial TAM has to rest on features the open-source core doesn’t carry. AWS can fork the core and still lack your control plane, your advanced security modules, your specialized console, which means your market is defended by the parts you never gave away. The third wall is multi-cloud. Enterprises are afraid of AWS lock-in, and a managed service that runs cleanly across AWS, Azure, and GCP holds customers an Amazon-only fork can only trap.

A strong presentation names the hyperscaler threat out loud, then shows the arithmetic for why a buyer pays the people who built the project instead of the cloud renting it back to them.

An example, sized two ways

Say you’re building MeshFlow, an ultra-lightweight open-source service mesh aimed at mid-sized companies on Kubernetes.

The top-down pitch sells the vision. Global enterprise spend on cloud infrastructure software hits $120 billion next year; networking and security are roughly 10 percent of it; the macro TAM is $12 billion.

The bottom-up pitch sells the execution, and it’s where the company actually lives. Fortune 50 banks are entrenched with legacy gear and heavyweight tools like Istio, so you skip them. Your sweet spot is the mid-market, companies with 100 to 1,000 engineers who need simplicity more than they need knobs. Tech-stack scraping turns up 30,000 mid-sized SaaS and tech companies on Kubernetes worldwide. About 30 percent of them, 9,000 orgs, have hit the microservices complexity where a mesh stops being optional. Your own telemetry shows 10 percent of those, 900 orgs, are already running the free build. MeshFlow Cloud manages the control plane for $25,000 a year:

9,000 target orgs × $25,000 ACV = $225 million beachhead.

In the room, you say both numbers in one breath:

“Our beachhead TAM is $225 million: 9,000 mid-market Kubernetes shops that need a simplified service mesh at a $25k ACV, and we already have open-source deployments inside 10 percent of those accounts, which is a warm pipeline our sales team can work today. As we ship multi-cluster compliance and move upmarket, we have a clear line into the broader $12 billion cloud-native networking market.”

That tells a coherent story. It separates the macro-market you can imagine from the developer segment you can win this year, and it shows you know the difference cold.

Open source builds the market it later sells to

The COSS model does something proprietary software can’t. It doesn’t just take a share of an existing market, it grows a new one. Enterprise software is expensive, gated behind a sales call, and a chore to trial. Open-sourcing the core drops the barrier to zero, and a developer who could never get a $100k legacy license approved pulls your tool down in seconds.

Those developers carry your software into industries, geographies, and company sizes the legacy vendors never bothered to address. The small accounts grow. Their usage scales. Some convert into paying customers for your commercial tier, and they arrive already knowing the product, having run it for a year before anyone signed anything.

When you present TAM, claim that effect explicitly. Open source is a wedge that keeps widening the borders of your market by raising buyers the top-down B2B playbook would have ignored.

A small market can be the whole point

Founders panic that a small TAM sinks the raise. Investors do love big markets. They love fast, efficient, dominant businesses more, and in open source a tightly drawn market is often the asset rather than the liability. Developers distrust the generic all-in-one platform. They adopt the opinionated tool that solves one acute pain perfectly, and they adopt it hard.

Take an open-source tool built only to manage compliance configurations for FinTech startups running Terraform. Maybe 2,000 well-funded startups on earth fit the profile. In raw dollars the TAM looks like a rounding error. But the pain is severe and regulatory, so adoption inside that niche is fast and loyal, and the community standardizes on your tool because there’s no second choice worth evaluating. Conversion to your commercial compliance-auditing cloud runs far above the open-core norm, maybe 20 percent instead of 5, and the contracts are large and long because a failed audit costs millions:

2,000 orgs × 20% conversion × $75,000 ACV = $30 million in defensible, high-margin revenue.

That’s stable revenue and enviable net revenue retention, earned while you own the mindshare of an entire industry. Investors who know open source recognize the shape. Winning is far easier when your roadmap is laser-focused and you’re not out-marketing 50 generic competitors at once. The best open-source VCs say a version of the same thing: better to own 100 percent of the mindshare in a critical niche than to be the tenth proprietary option in a loud, crowded one.

Domination doesn’t stay contained, either. The community pulls your product into adjacent markets on its own. Developers change jobs and bring your tool from FinTech into Healthcare, and the TAM expands organically while you sleep. The niche was the tip of the spear, never the ceiling.

What to actually do with the number

Know your numbers. Separate the free crowd from the paying buyers. Be honest with yourself about where your monetization model stops, even when honesty shrinks the slide.

Build the TAM bottom-up on assumptions you can defend one at a time and hold the number in its proper place: not a promise of revenue, but a direction for your focus. A TAM done right tells your team and your investors the same thing about you. You have the operational maturity to turn a popular repository into a business, and you already know which 500 customers come first.

Subscribe now

You can have 40,000 GitHub stars, a hundred forks a week, and a Slack channel that never sleeps, and still not have a business. Stars tell you people run your code. They don’t tell you anyone will pay for it, and downloads aren’t revenue either.

For a commercial open-source (COSS) founder, go-to-market is how free adoption turns into paid revenue. It comes down to a list of unglamorous questions. Who actually needs the enterprise or cloud version? What does the paid tier do that the free tier doesn’t? How does the buyer find it? And why would they pay when they could keep self-hosting the code they already have, for free? GTM is the work of lining up marketing, sales, product, pricing, and distribution behind one named customer, with the line between free and paid drawn on purpose instead of by accident.

The easy move is to “sell to the community.” It’s the path of least resistance, and it’s usually wrong. Before you hire a single rep, answer the question everything else hangs on: who pays, and why?

Why your community is not your market

Pick your market wrong and you die the most common COSS death, which is selling to people who have no budget.

I watched one COSS team spend three months sharpening a pitch aimed straight at the developers who contributed to their repo. They nailed the user and missed the buyer. They chased startups that were perfectly happy on the free self-hosted version, and never once called the enterprise compliance teams who had both the pain and the purchase order. A quarter of their sales hours went into trying to pull money out of people who wanted, reasonably, to keep using free software. You can guess how that quarter ended.

Your community tells you who uses your code. Your ideal customer profile tells you which companies are worth a sales conversation. Treat them as the same list and you’re selling blind.

A defined market keeps the rest of the company honest, too. Tell an investor your target is “anyone who downloads the project” and what you’ve actually told them is that you don’t have a beachhead. Pick a narrow segment you can win a paid contract in. Win it. Then widen out.

From ICP to message

Your ICP and personas are where the value proposition comes from. Once you know a segment’s specific pain, you can write a line that makes the buyer realize they need the commercial tier.

Say your ICP is a mid-market engineering org drowning in the cost of self-hosting your tool. The headline isn’t the code, it’s the cost of running it:

“The power of [Project Name] without the DevOps headache. Fully managed, secure, ready to scale.”

That goes straight at the wasted time, the infrastructure bill, and the fear of what breaks at scale. Compare it to something like “Next-Gen Data Management,” which speaks to nobody.

The user is not the buyer

In COSS, tailoring the message usually means splitting the practitioner from the executive, because they want different things.

The lead developer cares about developer experience, open APIs, raw performance, and not getting locked in. The VP of Engineering (or the CISO) cares about SOC 2, SSO, SLAs, and not owning the maintenance. So write two angles. For the developer champion: “fits straight into your existing CI/CD pipelines.” For the VP: “enterprise-grade security, RBAC, and 99.99% uptime.” Same product underneath. Different language on top, each in the dialect one persona actually respects.

Mirror their vocabulary and you signal you understand their world. Selling to developers, you talk PRs, workflows, open-source flexibility. Selling to the enterprise buyer, you talk total cost of ownership, governance, managed infrastructure. Use the wrong words and the reader stops trusting you somewhere around the first line.

Positioning against your own free product

COSS has a strange wrinkle here. The status quo you have to beat is often your own free product. So make the contrast loud. If the whole pitch is that you take maintenance off their plate, say it in exactly those words:

“Stop waking up at 3 AM to fix database nodes. Let the creators of [Project Name] run it for you.”

That puts the commercial product up against the real cost of self-hosting, which is the only competitor that matters here.

If you serve several industries, give each one its own landing page. The open-source engine underneath doesn’t change. What changes is the case studies, the terminology, and the compliance language, and a financial-services buyer who needs strict audit controls will convert at a higher rate on a page written for him than on a page written for everyone (and therefore no one in particular).

What the groundwork buys you

Define the market, segment it, build the ICPs, separate the users from the buyers, and you’ve got the raw material for messaging that actually lands.

Skip all that and you ship copy that reads like a README: technically accurate, commercially dead. Put in the hours and you can write something precise. When your users are DevOps engineers and your buyers are CTOs, the line almost writes itself: “Give your engineers the open-source tools they love, with the compliance, SSO, and audit logs your enterprise requires.”

Anchor the message in a real ICP and a clear read on who uses versus who pays, and it stops sounding like a pitch. It starts sounding like you know what your open-source success is worth to the person who has to sign the check.

Open source is the strongest distribution strategy in enterprise software, and the companies that treat it as charity leave most of the value on the table. If you’re building developer-facing infrastructure, data tooling, DevOps platforms, or security software, the commercial open source model hands you advantages no marketing budget can buy. Whether you capture them comes down to execution.

Start with the numbers, because they settle the argument before any theory gets a chance to. The Linux Foundation’s State of Commercial Open Source 2025 report draws on 25 years of venture data across 800 VC-backed startups, and COSS beats its closed-source peers on every financial dimension that matters:

• COSS median IPO valuation of $1.3 billion against $171 million for closed-source peers, a 7.6× premium

• COSS median M&A valuation of $482 million against $34 million, a 14.2× premium

• COSS companies raise 20 to 34% faster than closed-source peers at each stage

• COSS companies command 1.29 to 1.60× higher valuations at Seed and Series A, with the Series A premium the widest gap anywhere in the lifecycle

None of these premiums is luck. They fall out of the economics: lower customer acquisition cost, faster product-market validation, a community doing R&D the competition has to pay for. That last one is the wall a competitor can’t scale, and it runs through everything below.

Five things the model gives you that money can’t

Faster product-market fit comes first. An open source project is a pre-commercial signal no volume of customer interviews can match. When 10,000 developers download your project and 500 of them file issues, you’ve got harder evidence of real pain than any focus group will produce. HashiCorp waited until Terraform was genuinely everywhere before pushing enterprise features, and by then the market was pulling those features out of them. The proprietary SaaS path runs the other direction: you spend $2M on sales and marketing just to find out whether anyone wanted the thing.

Then there’s a lower cost to acquire each customer. Download-and-deploy growth cuts effective CAC by 30 to 50% against sales-led equivalents. MongoDB’s own data shows that 25% of its customers spending $100K+ ARR started as self-serve users, and those self-serve-originated enterprise accounts reach $1M ARR 15% faster than the ones sales sourced directly. Your OSS project runs outbound around the clock, in every country, and never files an expense report.

Third, community as R&D leverage. (This is where the compounding actually lives.) GitLab took in more than 6,500 external merge requests in calendar 2025 alone, real product contributions from engineers who draw no GitLab paycheck. Open Core Ventures’ handbook documents how community value and business value feed each other over years: the open core improves, which pulls in more users, which produces more contributors, which improves the core again. And the cycle turns at roughly zero marginal cost to you.

Fourth, enterprise trust, the kind that wins procurement fights a proprietary vendor can’t. Security teams can audit your code. Legal can read your dependencies. Architects see your internals instead of guessing at them. This matters most in regulated industries (financial services, healthcare, government) where a security review can drag on for months, and a product that survives one closes deals a black box never reaches.

Fifth, a hiring moat. The contributors who already know your codebase make your strongest engineering hires, and they often arrive inbound. Good engineers have opinions about their tools, and when you build the best one in a category, a fair number of them quietly decide they’d rather be working on it with you than on whatever they’re stuck with now.

The moat a competitor can’t dig

Every other distribution advantage has a counter. Outspend the marketing, poach the sales team, fine. But nobody conjures 50,000 GitHub stars, 10,000 production deployments, and 300 active contributors on a deadline. A community moat takes longer to build than any proprietary edge, and it lasts longer once built.

Community creates distribution through three separate channels. The first is word-of-mouth between practitioners: a developer who solved a real problem with your project recommends it unprompted, in code reviews, in Slack threads, in Stack Overflow answers, with a credibility no marketing copy manufactures. The second is ecosystem gravity. Once your project becomes the standard in a space (Terraform in IaC, Kafka in event streaming, Elasticsearch in search) every tutorial and blog post and job description that names it reinforces your position, and you stop competing for attention because you’ve become the default. The third is recognition that shows up before your sales team does. When the buyer’s engineers already run your project in production, you walk into the deal with a reference customer sitting at the table. Confluent landed 136 Fortune 500 companies at IPO partly because more than 70% of the Fortune 500 was already running Apache Kafka, the project Confluent’s founders created. Your sales team negotiates with organizations your community already won.

The unit economics, run right

The financial model is clean once you execute it correctly. Grafana Labs crossed $270M+ ARR at 69% YoY growth with 20 million users and roughly 5,000 paying customers. That’s a conversion rate of about 1%. The math holds because the 1% who pay carry high ACV ($25K to $500K+), net revenue retention is strong through land-and-expand, gross margins sit at 80 to 90%, and CAC on community-sourced leads is structurally low. Open core companies that run the model well land SaaS-like margins: Grafana at 80 to 90%, GitLab at 87%. The community subsidizes your margin directly, by cutting the marginal cost of building the core.

Where the moat never forms

Be honest about the failure modes before you commit. COSS punishes the wrong fit harder than proprietary SaaS does.

Some products have no natural community. The model works because developers choose their own tools and build network effects around them. Sell top-down to procurement, with non-technical buyers signing off (ERP, financial compliance, HR systems) and community-led growth just won’t show up the way COSS needs it to. The Linux Foundation notes that roughly 90% of COSS companies operate in infrastructure software rather than business applications. That split isn’t a coincidence.

Some moats live in data or network rather than code. If your defensibility is a proprietary dataset, a user network, or a curated marketplace instead of a technical implementation, open-sourcing the code gives away little and earns you little distribution back. Marketplace and data businesses are rarely served well here.

Some companies need revenue now, and COSS ramps slowly: you invest in community before you can charge for value. HashiCorp didn’t start meaningful commercialization until 2016, four years in. Databricks had enormous Apache Spark traction by 2015 with, in Ali Ghodsi’s own words, essentially no monetization path. If you need $500K ARR in twelve months to keep the lights on, this isn’t your road.

Some teams can’t sustain the investment, and a half-executed COSS strategy is worse than none. A neglected project, slow on issues, stale docs, no maintainer in sight, actively destroys trust. A zombie repository does more damage than never open-sourcing at all. Without the engineering bandwidth and the commitment to keep a project healthy, don’t start one.

And some attack surfaces are simply too narrow. Monetizely’s research benchmarks free-to-paid conversion at 0.3 to 3%. If your total addressable community is a thousand developers worldwide, the enterprise pipeline that funnel produces will be thin. The funnel needs a large enough developer population to work at all.

What the data settles

COSS is a complete business model with its own economics, not a marketing tactic bolted onto a proprietary core. It wins on distribution, on trust, and on a community moat proprietary SaaS can’t copy. The IPO premium (7.6×), the M&A premium (14.2×), and the funding-speed advantage stopped being arguable a while ago. It also fails, predictably, when the product has no natural developer community, when the moat is data or network instead of code, or when the team can’t sustain the community the model demands. Both the premiums and the failure modes are real. The job is knowing which camp you’re in before you build a go-to-market around either one.

I’ve spent three decades in technology, watching brilliant founders pour their hearts into building world-changing open-source projects. Yet, time and again, I have seen these same founders fall prey to a dangerous illusion: the belief that a massive community and a mountain of GitHub stars automatically forge a viable business. Let me be clear: GitHub stars often reflect popularity more than health or sustainability. Popularity is not a business model, and raw downloads do not equal a go-to-market (GTM) strategy.

For years, a flawed narrative has persisted, framing open source as a kind of digital charity. That era is over. Open source is an asset class—arguably the most undervalued one in the modern economy. The data is conclusive: Commercial Open Source (COSS) companies consistently achieve 7x greater valuations at IPO and 14x at M&A compared to their closed-source peers. However, COSS founders face a unique positioning paradox that traditional proprietary SaaS founders simply do not understand. Because your baseline offering is a fully functional project that developers can deploy for free, your biggest competitor is often your own free product. The traditional B2B SaaS playbook shatters when you have to convince people to pay for something they can technically get for free.

To win, you must master the dual-engagement model by fundamentally separating the user from the buyer. Throughout these pages, you will learn how to navigate this distinct two-level persona structure: the End-User (the developer or DevOps engineer who adopts the free code) and the Economic Buyer (the executive who signs the check). You will learn how to delight the developer with open APIs and frictionless workflows, while simultaneously selling Total Cost of Ownership (TCO), compliance, and risk mitigation to the C-suite.

When capital and community are aligned, everyone benefits. A thriving open-source community acts as an unstoppable top-of-funnel engine. This book provides the actionable frameworks—from defining your Total Addressable Market (TAM) and Ideal Customer Profile (ICP) to structuring your packaging and messaging—necessary to seamlessly feed that community into a highly efficient enterprise sales machine. By defining your commercial value, respecting the boundaries of your community, and executing a targeted strategy, you can turn developer enthusiasm into sustainable, scalable enterprise revenue.

— Matt Trifiro, April 2026