Open Source to SaaS: The Conversion Playbook

Turning open source to SaaS works when you keep the core project open and free, then sell what a team or company will pay for: hosting it for them, operational features like access control and audit logs, and a support contract with a real SLA. The free project drives adoption and trust. The paid product sits on top and serves a different buyer with a budget. That gap between the free user and the paying buyer is the whole game.

I write this as a working solo founder, not from the far side of a successful open-source company. I run a small portfolio (PDF9to5, a typing platform called TYPEMUSE, and a set of mobile apps) on Cloudflare and Stripe from Bharatpur, Nepal. I am pre-revenue, so I will not invent star counts, conversion rates, or ARR to make a point. What I can give you is the model, the public companies worth studying, and the order of operations that keeps a free community from quietly killing your ability to charge.

The conversion from a popular repo to paid software is a pricing and packaging problem before it is an engineering one. Before you draw any lines, it helps to have a view on how you will tier and price the product, to be comfortable selling to teams directly, and to understand the broader shape of productizing work into software. This piece sits in the Founder Systems pillar, because deciding what is free and what is paid is a system you will run for years, not a one-time call.

Key takeaways

• GitHub stars measure popularity, not willingness to pay. The buyer with a budget is rarely the person who starred your repo.
• The open-core line should be drawn by buyer (individual vs team or company), not by which feature was hardest to build.
• The four real models are hosted cloud, open-core paid features, support and SLA, and dual licensing. Most successful companies combine two of them.
• Pricing follows the buyer: individuals pay near zero, teams pay per seat for ops features, enterprises pay for security, compliance, and support.
• Sequence it: build a large free user base first, then monetize the operations buyer. Taking features away later is the fastest way to lose trust.

Why GitHub stars are not revenue

A star costs nothing. That is the entire problem. Someone clicks it because your project looks interesting, solves a problem they might have one day, or because they want to find it again later. None of those impulses involve a credit card.

This is the trap that catches technical founders hardest. You ship something good, the stars climb, the Hacker News thread is kind, and your brain reads all of it as demand. It is demand, but for the free thing. The people celebrating your project are celebrating that they get it for nothing.

Willingness to pay lives in a different person. It is the engineering manager whose team now depends on your tool and needs it to have audit logs before the security review. It is the company that cannot self-host because nobody on staff wants to be on call for it. Those buyers may never have starred the repo at all.

So treat stars as a top-of-funnel signal and nothing more. They tell you the project resonates and that distribution is working. They tell you almost nothing about whether you have a business. The question that matters is not “how many people use this” but “who, specifically, has a budget and a reason to pay, and what do they need that the free version does not give them.”

What is open core, and where does the line go?

Open core is the dominant model for a reason: the free core earns the adoption that a paid product alone could never buy, and the paid ring earns the revenue the free core never will. The entire business lives or dies on where you draw the line between them.

Draw it badly and you get one of two failures. Put too much in the free tier and nobody ever needs to pay, so you have a beloved project and no company. Put too much behind the paywall and adoption stalls, because the free version is crippled and developers move to a competitor who gives more away.

The line that works is drawn by buyer, not by feature whim. Ask of every feature: does this serve an individual developer doing real work, or does it serve an organization managing many people and meeting obligations to others? Individual-serving features stay free, always, because blocking them blocks adoption. Organization-serving features are where you charge.

This is why single sign-on, role-based access control, audit logs, and compliance reporting are the classic paid features across the industry. None of them help a solo developer. All of them are mandatory for a company past a certain size. The line is not “advanced features cost money.” It is “features a company needs to run safely and provably cost money.”

Resist the temptation to price by effort. Founders who paywall a feature because it was hard to build, rather than because a buyer values it, end up with a paid tier full of things individuals wanted for free and teams do not care about. The community resents the wall, and the wall does not even convert. Price by who the feature serves.

The Open-Core Line

Here is the model I would use to sort any feature into free or paid. The test is who the feature serves, which directly predicts who will pay for it.

Side of the line	Who it serves	Example features	Why it sits here
Free core	The individual developer	Core functionality, local install, single-user use, the CLI, integrations, the data format	Adoption is the asset. Anything that blocks a developer from real work blocks your distribution channel.
Free, but visible	The future buyer, today	Docs for the paid features, an “upgrade for teams” path, clear limits	Lets the free user grow into a buyer without feeling tricked. The ceiling is honest from day one.
Paid ring	The team and the company	SSO, RBAC, audit logs, multiple environments, longer data retention	These exist because an organization manages people and risk. An individual never needs them, so charging never blocks adoption.
Paid, sold separately	The operations buyer	Hosting, managed upgrades, support with an SLA, compliance certifications	The buyer can run it themselves but does not want to. They pay you to carry the operational burden and the risk.

The two paid rows are your revenue. The two free rows are your funnel. Keep that mapping honest and you can grow the community and the company at the same time, because they are not fighting over the same features.

How do you make money from open source?

You make money from open source by selling what the free project deliberately does not include: a hosted version you operate, paid features aimed at teams and companies, a support contract with guaranteed response times, or a commercial license for users who cannot accept the open-source terms. The code stays free. The convenience, the team features, and the accountability are what you charge for.

In practice almost every successful commercial open-source company runs more than one of these at once. GitLab keeps a free community edition and sells higher tiers plus a hosted offering. Sentry is open source you can self-host, with a paid cloud that most users choose because running it yourself is real work. PostHog follows the same shape: open source under the hood, a hosted cloud and paid features as the business.

The pattern across all three is the same. The open project is the marketing, the trust, and the distribution. The paid product is hosting plus the features a company needs once more than one person depends on the tool. You are not selling the code. You are selling the answer to “I do not want to run this myself” and “my company needs this to be secure and supported.”

The four monetization models (and their tradeoffs)

There are four durable ways to turn an open-source project into revenue. Each fits a different buyer and carries a different cost. Most companies combine two.

Hosted or managed cloud. You run the software so the customer does not have to. This converts teams who could self-host but value their time more than the savings. The tradeoff is that you now operate infrastructure, carry uptime, and absorb the support load. It is the most reliable revenue and the most operational burden, which is a hard combination for a solo founder.

Open-core paid features. You add proprietary features around the free core, aimed at teams and enterprises. This converts companies that self-host but need SSO, access control, and audit trails. The tradeoff is the constant judgment call about where the line sits, and the risk of community backlash if a feature people relied on moves behind the wall.

Support and SLA. You sell a contract: guaranteed response times, a named contact, help with upgrades and incidents. This converts risk-averse companies that have standardized on your tool and need someone accountable. The tradeoff is that support revenue scales with your time, not your code, which is dangerous for a solo operator unless you price it high and cap the volume.

Dual licensing. You offer the project under an open-source license and a separate commercial license for users who cannot comply with the open one (often for redistribution or embedding). This converts companies building products on top of yours. The tradeoff is that it only works for certain project types and copyleft licenses, and the buyer pool is narrow.

For a solo founder, hosting and a single high-value paid feature are usually the cleanest start. Support contracts and dual licensing demand legal and sales motions that are hard to run alone. Pick the model that matches a buyer you can actually reach.

Pricing the conversion: who actually pays

Pricing falls out of the buyer, and the buyer changes as you move up the open-core line. Get this mapping right and your pricing page almost writes itself.

Individuals pay near zero, and that is intentional. The free tier is not a loss leader you tolerate. It is the distribution engine. Any attempt to squeeze the solo developer trades long-term adoption for short-term revenue, and adoption is the thing the whole model runs on.

Teams pay per seat for operational features. Once a tool has more than one user inside a company, someone has to manage access, provisioning, and visibility. That is the moment the paid ring becomes worth real money, and per-seat pricing tracks the value because the pain grows with headcount.

Enterprises pay for security, compliance, and support. This is the top tier, and it is rarely about features at all. It is about audit logs that satisfy a review, SSO that satisfies IT, an SLA that satisfies procurement, and a contract that gives someone a throat to choke. The price reflects risk reduction, not engineering effort, so it can be high.

The deeper principle from pricing your tiers holds here: price the buyer’s problem, not your cost to build. The enterprise tier is expensive because the buyer is de-risking a company-wide dependency, not because the audit-log feature was hard. Build the tier ladder so each rung clearly serves the next buyer up.

The trust risk of taking features away

The single fastest way to damage a commercial open-source business is to take something the community already had for free and move it behind the paywall. Adding a new paid feature is fine. Reclaiming an existing free one feels like a betrayal, and the community remembers.

This is why the line should be drawn early and held. If a feature is going to be paid, it should be paid from the start, or clearly signposted as a future paid feature before anyone depends on it. People will accept a ceiling they saw coming. They will not forgive a floor that drops out from under them.

The reputational cost is asymmetric. A relicensing or a feature clawback generates a wave of forks, angry threads, and a permanent dent in trust, and it often nets less revenue than projected because the people affected were never going to pay anyway. You spend trust you cannot easily rebuild to capture a buyer who was already free-riding.

The safe path is additive. Grow revenue by adding new value for the team buyer, not by removing value from the individual user. Every change to the free tier should make a developer’s life better or leave it untouched. The paid side grows by expanding upward into the enterprise, not by encroaching downward onto the free user.

Sequencing: build users first, then monetize the buyer

The order is not optional. You build a large, genuinely useful free user base first, and only then build the paid product for the operations and team buyer who emerges from it. Reverse the order and you have a paid product with no funnel and no trust.

The first phase is pure adoption. Make the open core excellent, easy to install, well documented, and free of artificial limits. Your only job is to get the tool into as many hands as possible and to earn a reputation for quality. There is no monetization to design yet, only a community to grow.

The second phase begins when you can name the buyer. You will know it is time because the same kind of company keeps showing up with the same kind of request: “can we get SSO,” “do you offer support,” “is there a hosted version.” That repeated request from a budget-holding team is the signal to build the paid product.

This sequencing also protects you from the solo-founder trap, where a large free community consumes all your time in support and you never ship the paid product. The way out is to identify the team buyer early, build the smallest paid offering that serves them (usually hosting or one operational feature), and let that revenue fund everything else. The same logic shows up in pre-selling a B2B product: confirm the buyer will pay before you build the thing they pay for.

What I would do differently

If I were starting an open-source project today with the intent to convert it to SaaS, I would write down the paid line on day one. Not the prices, the line: which features serve the company, and a public note that those will be paid. Drawing it after the community forms is the mistake that creates the trust risk above.

I would keep the open core deliberately small. A solo founder cannot support a sprawling free project and still build a paid product. A narrow, excellent core is easier to maintain, easier to position, and leaves you the time to build the thing that earns money.

I would default to hosting as the first paid product, not paid features. Hosting converts the clearest buyer (the team that does not want to operate infrastructure), and it does not require touching the open-core line at all, so it carries none of the community-backlash risk. Paid features come later, once I know exactly which company need keeps recurring.

And I would resist measuring success in stars. Stars are a vanity metric that feels like progress. The metrics that predict a business are different: how many teams (not individuals) use the tool, how many ask for SSO or support or hosting, and how many of those convert. Watch the buyer, not the crowd.

Want the system, not just the article?

This post is one play from a larger founder operating system. The full version, The Bootstrapped Founder Operating System ($29), turns these models into worksheets: an open-core line you can fill in for your own project, a buyer-mapped pricing ladder, and a sequencing checklist so you monetize the right buyer at the right time.

Get the workbook →