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 (a PDF toolkit, a typing platform, 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.

Do GitHub stars turn into SaaS revenue?

No. GitHub stars measure interest, not willingness to pay. A star costs nothing, so it records curiosity rather than budget. Revenue for an open-source project comes from a different person entirely: the team that needs the tool hosted, supported, and secured before it will depend on it. Stars do not predict that buyer.

That zero cost is the whole problem. Someone clicks a star 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.

It 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. 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. A feature paywalled because it was hard to build, rather than because a buyer values it, produces a paid tier the community resents and nobody buys.

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 excludes: a hosted version you operate, paid features aimed at teams and companies, a support contract with guaranteed response times, or a commercial license. The code stays free. Convenience, team features, and 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.

Which open-source license should you pick if you plan to sell?

Pick a permissive license (MIT or Apache 2.0) for a library meant to be embedded in other people’s products, and a copyleft or source-available license (AGPL or the Business Source License) for a server-side product you do not want a larger company to host and resell. The license is a business decision wearing legal clothing.

License	What it permits	Commercial effect	Fits
MIT, BSD	Almost anything, including closed redistribution	Maximum adoption, no hold at all over anyone who resells you	Libraries, SDKs, client tooling you want embedded everywhere
Apache 2.0	Everything MIT permits, plus an explicit patent grant	Same adoption, with the patent clarity corporate counsel asks for	Anything a large company’s legal team has to sign off
GPL, AGPL	Free use, but derived works (and under AGPL, network-served ones) must also be open	Creates a genuine reason for some companies to buy a commercial license instead	Server-side products where dual licensing is the plan
BSL and other source-available terms	Read, modify, self-host, but not resell as a competing service	Blocks cloud resale, at the cost of not being open source at all	Databases and infrastructure a hyperscaler could host against you

choosealicense.com is the fastest way to compare the permissive options side by side, and the Open Source Initiative’s license list is the authority on which terms are genuinely open source and which only sound like it.

Two things follow from the table that founders learn too late. The first: a permissive license on a server-side product means dual licensing will never work for you, because nobody needs a commercial license to comply with MIT. If dual licensing is any part of the plan, that call has to be made before the first public release.

The second is the honest counter-argument to the whole source-available trend. The Business Source License and its relatives are not open source, and the OSI is correct to say so. Describing a source-available project as open source buys a short-term positioning win and a long-term credibility problem with exactly the developers you need. If you choose those terms, name them plainly in the README and explain who the restriction targets. Developers accept a restriction whose logic they can see. They do not accept being told a thing is open when it is not.

Relicensing later is possible but costly. It requires copyright assignment or a contributor licence agreement from the start, or the individual consent of every contributor. Decide once, early, and record the reasoning where a future you can find it.

Who actually pays for open-source software?

Three buyers exist and only two of them pay. Individual developers pay close to nothing and are the distribution engine. Teams pay per seat once more than one person needs managed access. Companies pay the most, for security, compliance, and support, because they are buying risk reduction rather than features.

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

Individuals pay near zero by design. The free tier is not a loss leader you tolerate, it is the distribution engine, and squeezing the solo developer trades long-term adoption for short-term revenue.

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.

What does it cost to host an open-source project for customers?

Servers are the cheap part. An early hosted tier for a small project runs on a single node plus object storage for tens of dollars a month. The costs that actually hurt are support time, on-call attention, and the trust artifacts a paying business customer expects before they will depend on you.

My own reference point, since I am pre-revenue and will not quote numbers I have never paid: the largest system I run, a real-time multiplayer typing platform, is designed to launch on a single ARM node at 25 euros a month. That is an entire production stack, not a hosted tier for one tool. Infrastructure is almost never the reason a commercial open-source project fails.

The honest cost stack for a solo founder running a hosted version, ordered by what actually consumes you:

Cost line	Rough shape	Why it bites
Compute and storage	Tens of dollars a month at early scale	The cheapest line on the list and the one founders most overestimate
Backups and egress	Small, until one customer exports everything	Predictable if you cap it, unpleasant if you do not
Error tracking and uptime monitoring	Free tiers cover an early product	Skip it and your customers discover your outages before you do
Support	Hours, not dollars	Every hosted account can interrupt you. This is the real price
Trust artifacts	Days of writing, then upkeep	A DPA, a security page, a status page. Business buyers ask for all three
On-call attention	Unbounded	You are the pager. This is the line that decides whether hosting suits you at all

Price the hosted tier so a single support conversation a month is still profitable. If the plan is ten dollars a month and one customer emails you twice, that customer costs you money, and the free self-hosted version would have been cheaper for both of you. Hosting works as a business when the price reflects that you absorb operations, not when it reflects your server bill.

The status page and the security page belong on this cost list rather than a later one. A team evaluating your hosted tier looks for both, and writing them honestly takes a weekend, not a quarter.

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. A paid feature should be paid from the start, or signposted as future-paid before anyone depends on it. People accept a ceiling they saw coming. They do 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. Every change to the free tier should make a developer’s life better or leave it untouched. The paid side grows upward into the enterprise, never 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.

When is open source the wrong choice?

Open source is the wrong choice when your value is the implementation rather than the interface, when your buyers are not developers and will never self-host, and when you cannot carry the support load a free community creates. Open source buys distribution among engineers. If engineers are not your channel, you pay the cost and collect none of the benefit.

The first case is the non-technical buyer. If the person with the budget is a marketer, an accountant, or a small-business owner, publishing the code gives them nothing they value and gives you a permanent maintenance obligation. They were never going to self-host. Nobody in that market picks you because they can read your source.

The second case is a support load you cannot serve. A free community generates issues, questions, and pull requests, and behind each one is a person who reasonably expects an answer. A large free user base with a single maintainer is not an asset. It is a queue that grows faster than you can work it, competing directly with the paid product for the only resource you have.

The third case is when the implementation is the moat. If the advantage is a hard algorithm, a data pipeline nobody else has assembled, or years of accumulated edge cases, publishing it hands your differentiation to anyone with a clone of the repository and more capital than you have.

Now the strongest argument against all of that. Plenty of experienced founders say open source is net positive regardless, through trust, hiring, and inbound interest. They are right where developers are the buyer, which is why the companies worth studying make it work. It stops being right the moment free users and paying buyers are unrelated populations. Before you open a repository, write one sentence explaining how a free user becomes a paying one. If that sentence is vague, you have a marketing expense, not a distribution channel.

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 that line after the community forms is what creates the clawback risk, where taking back a free feature costs more trust than the revenue it captures.

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 track three numbers instead of stars: how many teams rather than 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 →