If you build a company around free software, the hardest product decision is not whether to charge. You have to charge. Payroll, security reviews, release engineering, documentation, support, and the unglamorous work of keeping a project alive all cost money.
The hard decision is where to draw the line.
Draw it too far toward “free” and you create a beloved project with no economic engine. Draw it too far toward “paid” and the community correctly senses that the repository is a demo, not a commons. The open-core line is not a pricing trick. It is the moral contract of the business.
After operating in this model, my view is simple: the free product should be complete for individual and small-team use. The paid product should solve organizational complexity.
That sentence sounds clean. In practice, it is where most open-core companies either earn trust or burn it.
The wrong question: “What can we get away with charging for?”
Many founders start with a spreadsheet of features and ask, “Which of these can we put behind a paywall?” That framing almost always leads to resentment because it treats the community edition as a lead funnel with missing limbs.
A better question is: “Who is creating the cost and who is receiving the value?”
Open-source users create enormous value: adoption, bug reports, integrations, tutorials, credibility, and a hiring pool. They also create some cost, but usually not in proportion to their strategic value. Enterprise customers, by contrast, create high support, compliance, procurement, security, and roadmap cost — and receive value that is tied directly to risk reduction, scale, and internal coordination.
That is the economic logic of open core. Not “developers get less, companies pay more,” but “software freedom remains real, and institutional complexity is monetized.”
What should be free
The free edition should be good enough that a serious practitioner can use it in production without feeling tricked.
That does not mean every enterprise control must be free. It does mean the core utility must be intact. If your project is a database, it should store and retrieve data reliably. If it is an observability tool, a team should be able to instrument services and debug problems. If it is a developer platform, a developer should be able to build and ship with it.
A healthy open-source core usually includes:
- The primary runtime or engine
- Local development and self-hosted usage
- Core APIs and extension points
- Documentation sufficient to succeed without sales assistance
- Reasonable defaults for security and operations
- A path to migrate data out
- Community-visible issue tracking and contribution norms
That last point matters. A project can be technically open and culturally closed. If every meaningful discussion happens in private customer channels, the repository becomes a distribution artifact, not a community.
The free product should create pride. People should recommend it without needing to add, “It’s useful, but the real thing is paid.”
What should be paid
The paid product should map to the needs of organizations, not the curiosity of individual developers.
The cleanest paid features are those that become valuable when software moves from “a person using a tool” to “a company depending on a system.” These include:
- Single sign-on and advanced identity controls
- Role-based access control and audit logs
- Compliance reporting and data governance
- High availability, backups, disaster recovery, and multi-region operations
- Admin dashboards for large teams
- Policy management and approval workflows
- Enterprise support, SLAs, and security reviews
- Usage controls, spend controls, and internal chargeback
- Managed cloud convenience where the customer is paying to avoid operational burden
These features are not “withheld goodness.” They are the connective tissue companies need when software becomes shared infrastructure.
A developer running the project on a weekend does not need a SOC 2 packet, SCIM provisioning, custom retention policies, or a procurement-friendly invoice. A bank, hospital, public company, or 2,000-person engineering organization absolutely does. That difference is fair ground for monetization.
The dangerous middle: team features
The hardest calls are team features: collaboration, permissions, dashboards, hosted sync, integrations, and limits.
This is where founders often rationalize bad decisions. “Teams have budgets,” they say, and then lock basic collaboration behind a paywall. The result is predictable: the product becomes lonely when free. Users can evaluate it, but not actually adopt it with peers.
My rule of thumb: if a feature is necessary to understand the core value of the product in a normal working context, be cautious about paywalling it too early.
For example, a code review tool that does not allow a small team to collaborate freely is not meaningfully usable. A project management tool without shared projects is a toy. An observability tool that allows only one service may not teach users whether the system works.
But advanced team administration is different. Granular permissions, audit trails, enforced policies, centralized billing, approval chains, and directory sync are not basic collaboration. They are organizational governance.
The distinction is not always obvious, but users can feel it. If the paywall appears at the moment they are getting value, it feels fair. If it appears before they can reach value, it feels like a trap.
Open source is not a free trial
A free trial says: use this temporarily, then pay or leave.
Open source says: you have durable rights to use, inspect, modify, and share this software under the license.
Those are different promises. Confusing them is one of the fastest ways to lose community trust.
This is why I dislike “source available as marketing” when it is presented as open source. There are valid businesses built on source-available licenses, but they should be described honestly. Developers make architecture decisions based on license rights. If the rights change after adoption, or if the marketing language overstates the freedom, the backlash is not entitlement. It is a reaction to a broken expectation.
Open-core companies have to be unusually explicit:
- What is open source?
- What is commercial?
- What license applies to each component?
- What is the company’s commitment to the community edition?
- What would trigger a licensing change, if anything?
Ambiguity may help in the short term. It hurts later, usually at the exact moment the company needs the community most.
The “cloud tax” problem
Managed cloud is one of the best business models for open-source infrastructure. Many customers do not want to operate databases, queues, observability stacks, model-serving systems, or security tools themselves. They want the outcome, not the pager.
Charging for hosted convenience is fair. But the cloud line can become exploitative if the self-hosted product is intentionally starved.
A good managed service should win because it is easier, safer, faster, and better operated — not because the open-source version has been made artificially painful.
There is a difference between “we charge for automated upgrades” and “we refuse to document upgrades unless you pay.” There is a difference between “we provide enterprise-grade backups in cloud” and “we make self-hosted backup hooks inaccessible.” One is a service business. The other is hostage-taking.
The open-source version does not need to be effortless. Operations are work. But it should be honest work, not manufactured friction.
Pricing should reinforce the line
Packaging is the product strategy made visible. If your pricing page contradicts your community philosophy, users will believe the pricing page.
For open-core companies, I usually like a three-part structure:
- Community: free, self-serve, complete core utility, suitable for individuals and small teams.
- Team or Pro: paid self-serve, convenience and collaboration, priced so a growing team can adopt without procurement drama.
- Enterprise: governance, security, compliance, scale, support, and contractual commitments.
Usage-based pricing can work well here, especially for infrastructure products, but it needs guardrails. Open-source adoption is often bottom-up. If the first paid experience is a surprise bill, you have converted goodwill into anxiety.
Good usage pricing includes clear metering, caps, alerts, and a generous free tier that reflects real experimentation. The customer should always know what behavior creates cost.
Hybrid pricing is often the most practical: a platform fee for organizational features, plus usage for resource consumption. That lets you charge for both the right to coordinate a company and the cost of serving its workload.
Do not monetize pain you created
This is the principle I come back to most often.
It is fair to monetize value. It is fair to monetize risk reduction. It is fair to monetize scale. It is fair to monetize convenience.
It is not fair to monetize pain you deliberately created in the open product.
Examples of created pain include:
- Artificial user limits that prevent realistic evaluation
- Missing export functionality
- Deliberately incomplete documentation
- Security basics withheld from all free users
- Breaking changes that push users into paid migration help
- Community support channels ignored until someone upgrades
Some of these tactics may increase conversion in the short term. They also teach the market that your company cannot be trusted with stewardship. In open source, trust is a distribution channel. It is also a balance sheet asset, even if accounting does not know what to do with it.
A practical test for your roadmap
When deciding whether a feature belongs in open source or paid, I use five questions.
1. Is this part of the core promise?
If yes, it probably belongs in the open core. Weakening the core weakens adoption.
2. Does this primarily help an individual succeed, or an organization govern?
Individual success leans free. Organizational governance leans paid.
3. Does the feature reduce business risk for a customer?
Compliance, auditability, access control, uptime, and support commitments are strong paid candidates.
4. Would withholding this feature make the free product misleading?
If users cannot reach the advertised outcome without paying, your positioning is dishonest.
5. Who bears the cost at scale?
If the company incurs ongoing infrastructure, support, or contractual cost, monetization is easier to justify.
No framework removes judgment. But a framework forces the conversation out of vibes and into principles.
The community is not your unpaid SDR team
Open-source communities are often described in business plans as top-of-funnel. That is not entirely wrong, but it is incomplete and, frankly, a little insulting.
A community is not just a source of leads. It is a source of legitimacy, resilience, product insight, and long-term relevance. Many people in the community will never pay you. They may still be the reason a future buyer trusts you.
The healthiest open-core companies understand reciprocity. They invest in maintainership, not just demand generation. They publish roadmaps. They accept contributions with respect. They keep the community edition alive even when enterprise revenue is screaming for attention.
And they speak plainly about money. Most practitioners understand that companies need revenue. What they reject is pretending that every commercial decision is somehow for the community.
Sometimes a feature is paid because the business needs to capture value. Say that. People can handle honesty.
The line can move, but not casually
As products mature, the open-core line may need to change. Markets shift. Cloud costs rise. Abuse patterns emerge. Enterprise needs become clearer. A feature that seemed commercial may become essential to the core experience, or vice versa.
But moving the line should be treated like constitutional law, not a weekly growth experiment.
If you are moving a feature from paid to free, celebrate it. If you are moving something from free to paid, proceed with extreme care: grandfather existing users, explain the reason, provide migration paths, and accept that some trust will be spent.
Trust can be spent. It cannot be spent indefinitely.
The best open-core line feels obvious in hindsight
When open core works, users do not need a long explanation. The free product feels complete. The paid product feels like a natural next step for companies with more complexity, more risk, and more money than time.
That is the standard to aim for.
Not maximum extraction. Not purity theater. Not a repository that exists only to feed a sales motion. A real open-source core, paired with a commercial product that solves problems created by organizational scale.
If you are a founder or maintainer trying to draw this line, start with the promise you want the community to believe ten years from now. Then price the things that help institutions adopt that promise safely.
That is how you build a business without hollowing out the very project that made the business possible.
Leave a Reply