The Margin Math Behind Open-Core Software

Community support, whether that's a forum someone on your team monitors or documentation that has to stay current, is a real, ongoing cost even though no invoice is attached to it. So is the infrastructure cost of anyone self-hosting the free version pulling updates, filing issues, and expecting at least some response. None of this shows up as cost of goods sold in a traditional sense, but it's still headcount time your company is spending, and it needs a budget the same way a paid support tier does.

That cost tends to grow with the free tier's popularity, not shrink, which is the part founders most often miss when they first ship an open source project. A wildly popular free tier can quietly become one of the larger unbudgeted headcount drains in the company if nobody's tracking the support hours it actually pulls from engineers who were supposed to be building the paid product instead.

The paying tier has to cover its own delivery cost plus a meaningful share of what the free tier costs to sustain, since the free tier rarely pays for itself directly. That's not a flaw in the model, it's the whole point of open-core: the free tier is a distribution and trust-building mechanism, and the paid tier's margin needs to be wide enough to fund both its own delivery and its share of that mechanism's cost.

A permissive license lets anyone, including a cloud provider, host and resell your software without paying you anything, which is a real commercial risk if your own hosted offering is a big part of your revenue plan. A more restrictive open-core or source-available license can protect that revenue stream but comes with its own community and adoption tradeoffs, since some enterprise buyers and contributors specifically avoid licenses they see as less genuinely open. This is a decision to make with a lawyer who's actually worked on open source licensing, not one to default into because a template license looked standard.

Dual licensing, an open source license for community use and a commercial license for enterprise customers who need different terms, means every enterprise deal has its own signed commercial agreement layered on top of the open source license. Foxit eSign is a reasonable place to manage that signature trail, since a dual-licensing business ends up with more individually negotiated agreements than a typical single-SKU SaaS company, and losing track of which customer signed which terms is a real, avoidable risk.

Download counts and GitHub stars measure adoption, not revenue, and a project can look wildly successful by that measure while converting almost nobody to the paying tier. Track the ratio of active free-tier deployments to paying customers as its own number, and treat a falling conversion rate as a signal to investigate, whether the paid tier's features aren't compelling enough, or self-hosting has gotten easy enough that fewer users ever feel the need to pay, rather than assuming growing adoption alone means the business is healthy.

Report both numbers together whenever adoption gets celebrated internally or externally, since a headline about download growth without the matching conversion trend gives a misleading picture of how the business is actually doing, to your own team as much as to anyone outside it.

To tell whether the model is working, track these numbers:

• Download counts and GitHub stars, kept separate from revenue, since they measure adoption and not whether anyone pays.
• The ratio of active free-tier deployments to paying customers, tracked as its own number over time.
• Any fall in that conversion ratio, treated as a signal to investigate, starting with whether paid features are compelling enough.
• The ongoing support and hosting cost of the free tier, set against the margin the paying tier actually earns.