Open source: What you sell when the code is free

PostHog states on its own pricing page that more than 90% of companies use PostHog for free, a figure it published rather than one anyone audited.¹

Read that as a failure and you will never run this model. It is the design. The free majority is not a funnel that converts badly; it is the thing that makes the paid minority possible, because it produces the adoption, the scrutiny and the credibility that no marketing budget buys.

Few companies that try open source have accepted that trade.

Why would you give away the product?

Open source as a growth pattern means releasing the working core of your product under a license anyone can read, run and modify, then selling something adjacent: hosting, operations, compliance, support, or the features only large organizations need.

The reason is not price. It is that some purchases cannot be made on trust alone.

Developers adopt this way without asking anyone, which makes open source a clean case of bottom-up adoption: the tool is in production before procurement has heard of it. A developer choosing infrastructure is making a bet they will personally answer for in two years. “Trust us” is not evidence. “Here is the code” is. That is why this pattern dominates in databases, observability and developer tooling, and barely exists anywhere else.

What you are actually selling

The commercial question is not “which features do we hold back.” That is a pricing reflex and it is the wrong one here. The question is “what is genuinely hard about running this thing at scale,” because that is the only thing a company will keep paying for once they already have the code.

Three answers recur, and they are all operational, not functional:

Not running it yourself. Managed hosting, upgrades, backups, uptime. The customer could do this. They have read the code. They would simply rather not, and that preference gets stronger as the company grows.

Answering to somebody. SSO, audit logs, retention controls, a support contract with a name on it. These are bought by people who need to satisfy a security review, and they are unglamorous to build, which is precisely why they price well.

Somebody to blame. An enterprise buying infrastructure is partly buying an escalation path. That escalation path is the actual product.

There is a fourth return that is not revenue. People who contribute to a project become invested in it, and an invested contributor is a more durable advocate than any customer. That only happens in categories with enough developers to spare and a problem interesting enough to be worth their evening, which is another way of asking whether your category has that kind of developer in it.

There is an architectural decision that comes before positioning, and it is the same move made one layer down: build on a foundation your buyers already trust. Supabase chose Postgres, a database developers have known for decades, which means the scariest question about a new backend (what happens to my data when you go away) is answered before it is asked. Inventing a new paradigm means asking for trust twice, once for the company and once for the technology.

The other half of the commercial answer is positioning, and it comes free with the license: name the locked-in incumbent you are the open alternative to. “The open source Firebase alternative” does two jobs in four words. It borrows a mental model the developer already has, so you skip the explanation entirely, and it makes the escape hatch the headline feature, not a footnote. Categories where one proprietary vendor dominates are the ones where this works best, which is usually the same set of categories where open source works at all.

Does this apply to your product?

The categories where this works are narrow and nameable: databases and infrastructure (MongoDB, Postgres, Redis), developer platforms, and analytics that touch customer data. It reaches beyond that occasionally, mostly in design tools, but if your category is not on a list like this one, assume the pattern is not yours.

The failure that keeps happening

Relicensing is where this goes wrong, and it goes wrong more often than nonpayment does.

The sequence is consistent enough to be predictable. A company open-sources its core and grows on the adoption that follows. Cloud providers or competitors run the software commercially without contributing much back. The company, understandably angry, changes the license to something more restrictive. And the community it spent years building treats that as a breach, forks the last permissive version, and takes a good deal of the ecosystem with it.

This has now happened often enough in databases, search and infrastructure tooling that the forks are themselves substantial projects.² The pattern matters more than the individual cases: the license is the product’s constitution, and amending it retroactively is read as a betrayal even when the business case is sound.

Two consequences follow for anyone starting out.

Your license choice is close to irreversible. Not legally, but practically. You may change it once, and it will cost you the trust that made the model work. Choose as though you cannot change it.

“Open core” only holds if the core is genuinely useful alone. A free tier crippled enough to force upgrades is not open source with a commercial layer; it is a trial with extra steps, and developers identify it immediately.

Is the model working, or are you just giving software away?

Download counts and GitHub stars measure attention, not health, and both can rise for years while the business does nothing. What follows reads the project against itself instead, using numbers you already hold.

1. Do self-hosted users convert at a different rate than people who arrive cold? They should, substantially. Someone running your software in production has already done the evaluation. If they convert like strangers, your commercial layer is not solving a problem they actually have.
2. How long from first install to first payment, and is it shortening? The absolute number will be long, and that is fine. A number that is not shortening as the product matures means the paid layer is not tracking what scale actually makes painful.
3. Is expansion coming from more seats or from bigger plans? Instrument the two separately, because they call for opposite responses: seat growth means the product is spreading inside accounts and your job is to keep removing friction from invitations, while plan upgrades mean the value is concentrated in features and your job is pricing. Expect it to be overwhelmingly the first, and expect that to surprise you.
4. What share of your paid accounts self-hosted first? If it is low, the free tier is not feeding the business, and you are running two products, not one funnel.

Before you publish anything

1. Write down what you will sell, before you publish anything. If the answer is “we will figure out monetization later,” you are giving software away with no plan to be paid.
2. Pick the license as if it were permanent, because in every way that matters to your community it is. Starting permissive buys the fastest adoption and leaves you the least room to tighten later, which is the trade the section above is about.
3. Check the free tier is genuinely useful alone. Ask someone outside the company to run it in production without help. If they cannot, you have a trial.
4. Instrument self-host to paid. Few teams do this early, and it is the only measurement that tells you whether the model works. Someone running your software in production is about as strong a product-qualified signal as this handbook has: they have already done the evaluation, at their own cost, without telling you.
5. Expect to add sales later, not instead. The usual sequence is self-serve conversion first, then a sales motion layered on for expansion once accounts are large enough to warrant one. It works because bottom-up adoption creates the demand before anyone sells, and it fails when the two motions are given separate targets and start competing for the same account. Two structural choices prevent that: put both on the same first-order goals, not on metrics that can be won at each other’s expense, and keep pricing, packaging and billing under a single owner.
6. Budget in years. Commercial conversion in this pattern lags adoption by a long way, and the temptation to abandon it peaks just as the base gets large enough to matter.

Publishing the source is the most complete answer to “why should I trust you” that software has, and a developer has to work through it. There is a faster version of the same trade, for products where reading the implementation is beside the point and watching it run is everything. It takes minutes, the developer never asks anyone’s permission, and the whole evaluation happens inside their own codebase: API-first products distribute through their documentation.

Updated August 2026