A founder emailed me in July asking whether he should put his scheduling SaaS on GitHub. Forty paying customers, a competitor with real funding, and a podcast episode that had convinced him open source was a distribution strategy.
It can be. It is also the only decision on his roadmap that could not be reversed. You can reprice, rebrand, rewrite the backend, fire the agency. You cannot un-publish source code that has already been cloned, and a fork does not need your permission to keep existing after you change your mind.
That asymmetry is the entire decision about open source SaaS, and it is the part the podcast episodes leave out.
Should you open-source your SaaS codebase?
Open-source it only when distribution is your actual bottleneck and your moat lives somewhere the code cannot reach. Otherwise stay closed. The test is not ideological and it takes about ten minutes to run honestly.
Ask what a competitor would need, beyond your source, to beat you. If the honest answer is nothing, the repository is the last missing piece and you are volunteering to hand it over. Network effects survive being copied, because a clone starts with zero users on both sides of the market. A dataset you spent two years accumulating survives being copied. Application logic does not, and most early SaaS products are application logic wearing a marketing site.
Then the question that actually decides it: is anybody failing to find you? Open source is a top-of-funnel channel. It works when developers are the buyers, when they will run your thing locally before they will book a call, and when the category is crowded enough that reading the code is a real differentiator. It does nothing when your buyer is a clinic manager who has never opened a terminal.
BookBed stays closed for exactly that reason. It is a property management system I built solo over six months on Flutter and Firebase, and there is very little in that repository a competent developer could not rebuild from scratch. The value sits in iCal sync behaving correctly against a dozen badly-behaved OTA feeds, and that knowledge is not in the source. It is in the bug fixes, and in the specific shape of the workarounds around them.
How many of your customers have actually asked to read your source code? If the number is zero, publishing is a bet on a different customer than the one paying you now. That bet is sometimes correct. It is never free, and it is never quiet.
Pick the license before you write the README
The license is a product decision wearing paperwork's clothes. Founders postpone it, ship the repository with whatever the GitHub dropdown suggested, and then discover that a default they never thought about determines whether a cloud provider can resell their work back to their own customers.
Four options cover almost every real case:
| License | What a competitor may do | Blocks cloud resale | OSI-approved open source |
|---|---|---|---|
| MIT / Apache 2.0 | Anything, including closing their fork and selling it | No | Yes |
| AGPL v3 | Compete, but network use triggers source disclosure | Weakly; large clouds have learned to comply | Yes |
| BSL 1.1 | Everything except production competition, until the change date | Yes, during the term | No |
| FSL | Everything except competing; converts automatically later | Yes, for two years | No |
The Functional Source License is the most honest of the four about what it is doing. Sentry wrote it as a tightened Business Source License: a two-year change period, after which each released version converts automatically to Apache 2.0 or MIT, with the licensee picking which one. Until that date you may run it, study it, modify it, and redistribute your changes. You may not use it to compete with the company that wrote it.
That is a reasonable deal for most users and a bad deal for the phrase "open source", which neither FSL nor BSL qualifies for under the OSI definition. Say the true thing on your landing page anyway. Calling it source-available costs you a few GitHub stars. Getting caught calling a non-compete license open source costs you the exact audience you published for.
AGPL has the opposite problem. It is genuine open source, and Cal.com runs its scheduling platform on it while stating plainly that self-hosters generate no revenue. The catch sits on the buyer side. A meaningful share of large enterprises maintain a blanket ban on AGPL code touching their network, so the license that protects you from AWS also removes you from the procurement shortlist at the customers with the largest budgets.
If you have not settled how the product gets built yet, that decision comes first, because the no-code versus pro-code trade-off determines whether there is a portable codebase worth publishing at all.
The reversal does not work, and Redis is the receipt
Changing your license after a community has formed does not return you to the position you held before publishing. Redis ran the cleanest natural experiment anyone has on this, in public, at scale.
March 2024: Redis left BSD for SSPL. AWS and Google forked it into Valkey within weeks. May 2025: Redis added AGPLv3 and much of the coverage framed it as a return to open source. The fork stayed forked.
Percona's Martin Visser put numbers on the aftermath in December 2025. Nine of twenty-four Redis contributors, 37.5%, stopped contributing after the fork, while Valkey grew from 18 contributors to 49 across eighteen months. Through 2025 Valkey averaged 80 pull requests a month against Redis's 42, and finished the year at 865 PRs to 537.
Read that as a price list rather than a morality tale. The license change bought Redis protection from cloud resale and cost it roughly half its contribution velocity, permanently, including after the reversal. Which leads to the only strategic conclusion I would defend without qualification: if you expect to end up at BSL or FSL in year three, start there in year one. The migration is the expensive part, and you only get to do it once.
A short word on stars
Your GitHub star count is a vanity metric with a support burden bolted to it. Stars do not convert, issues do not close themselves, and every drive-by bug report from a self-hoster is an hour you did not spend on someone who pays. Budget the hours or do not publish.
How does an open-source SaaS make money?
Almost always by selling what the code cannot give you: hosting, uptime, compliance paperwork, and somebody to call at 2am. The source is the marketing. The operations are the product.
Managed hosting is the cleanest version. Plausible and Cal.com both give away a fully functional product and charge for the instance they run, and the pitch to a buyer is not features, it is that upgrades, backups, and the on-call rota stop being your problem. Open core is the second version, where the core is free and the enterprise layer is not, which in practice means SSO, audit logs, and granular permissions. Everybody in the industry calls that last one the SSO tax. Everybody keeps paying it.
Open source is a distribution channel. Actually, that is too generous. It is a distribution channel for one specific buyer, the developer who evaluates by cloning, and if that person is not in your funnel the channel is closed no matter what you publish.
Callidus OS is the clearest counter-case I have shipped. Multi-tenant clinic SaaS on React and Firebase with Stripe Connect handling per-clinic patient deposits, built solo across roughly ten weeks starting 14 February 2026, after inheriting a failed FlutterFlow attempt carrying around 200 unresolved errors. Every buyer was a UK aesthetics clinic holding patient records with no operations team anywhere in the building. Publishing that source would have produced zero self-hosters and one very readable map of the multi-tenant isolation rules for anybody who wanted to probe them.
There is also a failure mode no license prevents, because it is entirely legal. Steve Sewell of Builder.io made the point using Cursor: a twenty-dollar monthly subscription to what is, structurally, VS Code with AI on top. Nobody violated anything. The permissive license worked precisely as designed, and the value still landed somewhere other than with the people who built the base.
Has AI weakened copyleft licenses?
Copyleft enforcement is weakening, because models train across licenses they never accepted and routing around a copyleft library has become cheap. That is not a fringe position any more.
Sentry's team laid the argument out in March 2026, and it is uncomfortable reading if you were counting on AGPL to hold a line. Models train on public code without regard for the terms attached to it. Agents can reimplement a copyleft dependency cheaply enough that avoiding one is an afternoon rather than a project. And the copyright status of generated code is itself unsettled, after the US Supreme Court declined to hear copyright claims over AI-generated material and left standing a ruling that a significant human element is required for protection.
The conclusion Sentry draws happens to favour the license Sentry wrote, and it is still worth taking seriously. A copyright-based license is only as strong as the copyright sitting underneath it. A contract-based one, which is what BSL and FSL are, does not depend on that question. Sentry reports that compliance departments at more than 10,000 organisations have cleared Fair Source for internal use, which is the argument that matters commercially: the restriction is narrow enough that legal teams sign off without a call.
None of that makes AGPL a mistake. It makes AGPL a bet on an enforcement mechanism that is moving, and bets on moving things deserve a shorter time horizon than the ones founders usually give them.
So what should you actually do
Run the decision in this order, and stop at the first step that returns a no:
- Write down who signs the invoice, and whether that person has ever self-hosted anything in their life. Clinic manager, practice owner, hotel operator: stop here and stay closed. Nothing downstream will rescue the channel.
- Name the moat that survives publication in one sentence. If the sentence needs a conjunction to sound convincing, you do not have one yet.
- Choose the license before the first public commit, not after the first fork. If you would object to a funded competitor running your code as a paid service tomorrow, you want FSL or BSL, and you want to be plain that this is source-available rather than open source.
- Decide the support budget in hours per week, in advance, and write the number somewhere you will see it. An unfunded issue tracker becomes a public record of you ignoring people.
- Publish the edges before the core. SDKs, CLI tools, and integrations carry almost none of your defensibility and most of the developer goodwill, and they let you test whether the channel exists before you bet the product on it. The stack I recommend for a SaaS MVP is boring on purpose for the same reason: keep the reversible decisions cheap.
If you are undecided, step five is the whole experiment. Put your SDK and integrations on GitHub under MIT this month, leave the core closed, and watch for a single inbound conversation that opens with "I found your GitHub." That costs a weekend and gives away nothing defensible.
And if you have already decided to publish everything, there is a narrower question worth answering before you push: which specific person do you expect to clone this repository, and what exactly do you want them to do in the ten minutes after it finishes cloning?
