Don’t Sell Support. Sell Confidence.

Every open-source founder eventually hears the same advice: “Just sell support.” It sounds clean, almost morally satisfying. Keep the code free, charge the companies that need help, and everyone wins.

In practice, support-only businesses are harder than they look. They can work—Red Hat proved that at enormous scale—but they are rarely the easiest path for a small team building around a fast-moving project. Support revenue is labor-intensive, difficult to forecast, and often misaligned with the product work you actually want to fund.

The better question is not, “Can we charge for help?” It is: “What does a serious buyer need before they can safely depend on this software?”

That answer is usually not support alone. It is operational confidence.

Support is a service, not a product strategy

Support has an obvious appeal because it does not require you to close source code. You can preserve a generous community edition and still create a reason for companies to pay. But support has three structural problems.

First, the value is reactive. Customers often pay when something is already broken, risky, or politically visible. That makes support feel like insurance, and insurance is one of the first things buyers negotiate down unless the pain is fresh.

Second, the margins depend on people. Great support requires great engineers, and great engineers are also the people you need improving the product. If every large customer creates custom operational work, you have built a consulting firm with a GitHub repository attached.

Third, support does not always map to willingness to pay. The companies that create the highest burden are not always the companies with the largest budgets. A small team running your project in a fragile environment can consume more support time than a Fortune 500 customer with mature platform engineering.

None of this means support is bad. Support is often a necessary component of enterprise packaging. But when it becomes the primary thing you sell, you risk underpricing the real business value: reduced risk, faster adoption, and credible accountability.

What companies actually buy from open-source vendors

When a company pays for software it could technically use for free, it is rarely paying because it lacks the skill to run the free version. Especially in infrastructure, developer tools, security, data, and AI tooling, the buyer often has capable engineers.

They pay because the free version does not fully solve the organizational problem around the software.

• Security wants auditable controls, patch visibility, and a known escalation path.
• Finance wants predictable cost and a contract.
• Legal wants indemnity, licensing clarity, and data-processing terms.
• Platform teams want high availability, upgrades, observability, and integrations.
• Executives want to know the project will still exist in three years.

The open-source repository may solve the technical job. The commercial product solves the adoption job.

This distinction matters because it changes what you package. If you believe customers are buying “help,” you staff support. If you believe they are buying “confidence,” you build product features, contracts, workflows, and operational guarantees that make adoption safe.

The paid product should remove organizational friction

A strong open-core line usually separates individual or team experimentation from scaled organizational use. The free edition should let a real user experience the core value. The paid edition should make it easier for a company to standardize on that value without creating risk.

That often means charging for features such as:

• Identity and access control: SSO, SCIM, RBAC, audit logs, session policies.
• Governance: approval workflows, policy controls, compliance exports, retention rules.
• Reliability: clustering, backup automation, disaster recovery, uptime commitments.
• Visibility: admin dashboards, usage analytics, cost controls, monitoring integrations.
• Deployment convenience: managed cloud, private cloud, upgrade orchestration, hardened builds.
• Accountability: SLAs, security response, contractual commitments, roadmap access.

These are not “crippleware” if the open version remains genuinely useful. They are features that become valuable when the software moves from a developer’s laptop to a company’s operating model.

Be careful with the “we’ll monetize later” myth

Open-source adoption can create a comforting illusion: stars, downloads, Discord activity, conference talks, and pull requests all feel like momentum. They are momentum—but not necessarily commercial momentum.

If you wait too long to define what paid value means, the community will define the bargain for you. Users will assume everything important belongs in the free project. Contributors will object when previously expected features become commercial. Your own team will struggle to explain why something is paid beyond “we need revenue.”

The answer is not to monetize aggressively from day one. The answer is to be explicit early.

A simple public posture helps:

“The open-source project will always be the best way for individuals and teams to use the core engine. The commercial product is for organizations that need governance, reliability, security, and operational guarantees at scale.”

This gives you room to build a business without making every pricing decision feel like a betrayal.

Support belongs in tiers, not at the center

I like support as part of a commercial package. I dislike it as the whole package.

A healthier structure is to attach support to product tiers that already reflect customer value. For example:

• Community: free, self-service, public documentation, community forums.
• Team: hosted convenience, collaboration features, basic admin controls.
• Business: SSO, audit logs, policy controls, priority support, predictable limits.
• Enterprise: advanced governance, dedicated environments, SLAs, security review, account team.

In this model, support reinforces the value of the tier. It is not the only reason to buy. Customers pay more because the software is more deeply embedded in their organization, not simply because they are allowed to ask more questions.

The “free rider” problem is often a packaging problem

Founders sometimes become resentful when large companies use the free version heavily. I understand the frustration. Nothing sharpens your views on open-source sustainability like watching a well-funded company run your project in production while your team debates payroll.

But “they are free riding” is not a go-to-market strategy. If a company is getting major value without paying, one of three things is true:

1. They are not experiencing enough organizational pain to justify a purchase.
2. You have not packaged the paid product around the pain they do have.
3. You are giving away the features that convert usage into budget.

The third point is the painful one. Many open-source companies accidentally donate their enterprise value to the free edition because those features are technically interesting or community-requested. A maintainer enjoys building clustering, policy engines, or advanced observability. But those may be exactly the features that larger organizations are willing to fund.

Generosity is good. Unexamined generosity is dangerous.

A practical test for what should be paid

When deciding whether a capability belongs in open source or commercial, I use a simple test:

Does this feature primarily help someone understand and adopt the core technology, or does it help an organization control, scale, and govern it?

The first category usually belongs in the open project. The second category is often commercial.

For example, a great local developer experience should usually be open. Clear APIs, SDKs, basic integrations, documentation, and a single-node deployment path help the project spread. They increase trust and create more potential buyers later.

But centralized audit logs, multi-team governance, enterprise identity integrations, automated failover, and compliance reporting usually serve the organization around the user. Those features are legitimate candidates for paid packaging.

The boundary will not be identical for every company. A database, an observability tool, an AI framework, and a security scanner all have different adoption dynamics. But the principle travels well: keep the core value accessible; charge for scaled operational confidence.

Managed cloud changes the equation—but not completely

For many open-source businesses, managed cloud is the cleanest commercial product. It sells convenience, reliability, upgrades, and lower operational burden. It also avoids some of the emotional tension of open core because customers are paying for a service, not merely permission to use code.

But managed cloud is not magic. It introduces infrastructure cost, on-call obligations, security responsibilities, and potentially usage-based pricing complexity. It can also be undercut by sophisticated users who self-host unless the managed experience is meaningfully better.

The best managed offerings do not just host the open-source project. They make the production experience calmer. They handle upgrades safely. They surface cost and performance. They integrate with enterprise identity. They provide backups, recovery, and observability by default.

Again, the product is confidence.

Community trust is built by clarity, not by avoiding money

Some founders avoid commercial decisions because they fear community backlash. The irony is that ambiguity often creates more backlash than monetization does.

Communities can accept a company making money when the bargain is understandable. They become angry when the bargain changes without warning, when a project pretends to be community-led while all meaningful control sits with the vendor, or when essential capabilities are suddenly moved behind a paywall.

Clarity is a form of respect. Say what the open project is for. Say what the company sells. Say how decisions are made. Say which parts are governed by maintainers, which by the vendor, and which by customers.

You do not need everyone to agree with your model. You need the right users, contributors, employees, and customers to understand it.

The business should fund the project’s future

The moral case for commercial open source is not “we deserve money because we wrote code.” That may be true, but it is not enough.

The stronger case is: a sustainable business makes the project more dependable. It funds maintainers, security work, documentation, releases, compatibility, testing, and long-term stewardship. It gives serious users someone accountable when the software becomes important to them.

If your paid product is designed well, customers are not paying reluctantly to avoid guilt. They are paying because the commercial layer helps them succeed with the open technology.

That is the line I would rather see more founders draw. Do not sell support as an apology for being free. Sell the operational confidence that turns a promising project into infrastructure a company can bet on.