Picture a scheduling SaaS with a few dozen paying customers, a funded competitor and a founder who has heard that open source is a distribution strategy. This is a hypothetical, but the decision is real, and it has one property that most roadmap items lack. You can reprice, rebrand, rewrite the backend and change vendors. You cannot un-publish source code that has already been cloned, and a fork doesn't need your permission to keep existing after you change your mind.
That asymmetry is the whole decision about open source SaaS, and the enthusiastic advice rarely mentions it. Your first action, before reading further: write down who signs your invoice, and whether that person has ever self-hosted anything.
Should you open-source your SaaS codebase?
Open-source it only when distribution is your real bottleneck and your moat lives somewhere the code can't reach. Otherwise stay closed. This is my recommendation, and the test 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 would be volunteering to hand it over. Network effects survive being copied, because a clone starts with no users on any side of the market. A dataset you spent two years building survives too. Plain application logic doesn't, and many early SaaS products are mostly application logic behind a marketing site.
Then ask whether anybody is failing to find you. Open source is a top-of-funnel channel. It works when developers are the buyers, when they will run your product locally before booking a call, and when the category is crowded enough that reading the code differentiates you. It does little when your buyer has never opened a terminal.
BookBed, the property management system I built solo on Flutter, Firebase and Stripe, stays closed for that reason. Its buyers are property owners, not developers. Some of its value sits in details the case study documents, such as timezone-correct iCal sync tested against real Adriagate imports, and that knowledge lives in bug fixes and workarounds rather than in a headline feature a reader could copy at a glance. How many of your customers have asked to read your source? If the number is zero, publishing is a bet on a different customer than the one paying you now. That bet is sometimes right, and it is never free.
Which license should an open-source SaaS pick?
Pick the license before you write the README: MIT or Apache 2.0 if you accept competitors reselling your work, AGPL if you want copyleft, and BSL or FSL if you want to block production competition and accept being source-available.
A default chosen from a dropdown decides whether a cloud provider can resell your work to your own customers, so treat the license as a product decision. Four options cover most real cases:
| License | What a competitor may do | Blocks competing resale | OSI-approved open source |
|---|---|---|---|
| MIT / Apache 2.0 | Anything, including closing their fork and selling it | No | Yes |
| AGPL v3 | Compete, but must offer source to users of modified network services | Only through the copyleft obligation | Yes |
| BSL 1.1 | Everything except production use the licensor restricts, until the change date | Yes, during the term | No |
| FSL | Everything except competing use; converts automatically later | Yes, for two years | No |
The Functional Source License states its own terms plainly. Each released version converts to Apache 2.0 or MIT after two years, and until then, in its words, "you can do anything with FSL software except undermine its producer": run it, study it, modify it and distribute your changes. Its FAQ is explicit that FSL is not OSI-approved open source. Say the true thing on your landing page. Calling it source-available may cost you a few GitHub stars, while calling a non-compete license open source costs you credibility with the audience you published for. MariaDB's BSL FAQ describes the older BSL 1.1 the same way: a change date no more than four years out, after which it converts to a GPL-compatible license.
AGPL is genuine open source, and Cal.com explains that it is AGPL licensed and that you won't capture revenue from people who self-host on their own. The catch sits on the buyer side. Google's AGPL policy says AGPL code "MUST NOT be used at Google", and it is reasonable to infer that other companies with similar policies will filter AGPL products out of procurement. Check your target buyers' policies before you assume the license only scares competitors.
If you haven't settled how the product gets built, do that first, because the no-code versus pro-code trade-off decides whether there is a portable codebase worth publishing.
Can you change the license later?
You can, but it doesn't return you to where you started. Redis is the best public case: in March 2024 it moved to SSPL, and by its own account AWS and Google now maintain their own fork.
In May 2025 Redis announced AGPLv3 as an additional license option starting with Redis 8, and its CEO wrote that the SSPL change had "hurt our relationship with the Redis community". The fork stayed a fork. Percona's Martin Visser quantified the aftermath in December 2025: 9 of 24 Redis contributors (37.5%) stopped contributing, Valkey grew from 18 to 49 contributors over eighteen months, and in 2025 Valkey created 865 pull requests to Redis's 537.
Read that as a price list rather than a morality tale, and note that these numbers are correlational: they don't prove the license change alone caused every departure. My conclusion is a recommendation. If you expect to end up at BSL or FSL by year three, start there in year one, because the migration is the expensive part and you only get to run it once.
How do open source SaaS companies make money?
Mostly by selling what the code can't give you: hosting, uptime, compliance paperwork and someone to call. The source works as marketing, and the operations are the product.
Managed hosting is the cleanest model. Plausible offers a free, self-hosted, AGPL-licensed Community Edition and a paid cloud service with hosting, updates and support. Cal.com describes hoping that open source traction puts you on the radar of larger companies that sign bigger deals. Open core is the second model: a free core with a commercial layer for things like SSO, audit logs and granular permissions. If you are weighing open core vs open source, the deciding question is which specific features a paying customer needs that a self-hoster doesn't.
Open source is a distribution channel for one buyer, the developer who evaluates by cloning. If that person isn't in your funnel, the channel stays closed whatever you publish.
When does open source clearly not fit?
Callidus OS is the counter-case I've shipped: a multi-tenant clinic SaaS on React, Firebase and Stripe Connect, built solo in roughly ten weeks from 14 February 2026, sold to independent UK aesthetic clinics. Deposits flow to each clinic's own Stripe account, and every tenant's isolation rules are part of the product. Publishing that source would, in my judgment, produce few if any self-hosters and hand outsiders a readable map of the tenant isolation rules to probe.
There is also a failure mode no license prevents, because it is legal. Steve Sewell of Builder.io wrote about Cursor: "They took VS Code (MIT licensed), added some AI features, and now charge $20/month for it." Nobody violated a license, and the value still landed with someone other than the people who built the base.
Has AI weakened copyleft licenses?
It has made enforcement harder to rely on, according to Sentry's argument. In March 2026 Sentry wrote that LLMs are trained on public source code without much effort to respect license terms, and pointed to AI agents rewriting existing libraries under different licenses, including Cloudflare's vinext reimplementing Next.js in a week. It also cites the US Copyright Office position that copyright protects only material with human creative input. Sentry sells a Fair Source license, so weigh its conclusion accordingly: a contract-based license such as FSL doesn't depend on that copyright question in the same way. None of that makes AGPL a mistake. It makes AGPL a bet on an enforcement mechanism that is still moving.
What should you actually do?
Run these in order and stop at the first no:
- Name who signs the invoice. If it's a clinic manager, practice owner or hotel operator, stay closed. Nothing downstream rescues the channel.
- State the moat that survives publication in one sentence. If it needs a conjunction to sound convincing, you don't have one yet.
- Choose the license before the first public commit. If you'd object to a funded competitor running your code as a paid service, you want FSL or BSL, described honestly as source-available.
- Budget support hours per week in advance. An unfunded issue tracker becomes a public record of you ignoring people.
- Publish the edges before the core. SDKs, CLI tools and integrations carry little of your defensibility and most of the developer goodwill. The stack I recommend for a SaaS MVP is boring on purpose for the same reason: keep reversible decisions cheap.
If you're 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 one inbound conversation that opens with "I found your GitHub." And if you have already decided to publish everything, answer this before you push: which specific person do you expect to clone the repository, and what do you want them to do in the ten minutes after it finishes cloning?