How to Turn an Open Source Project into a SaaS

Can you legally sell an open-source project as a SaaS?

Usually, yes. Open-source licences allow commercial use by definition, and many successful hosting businesses run open-source software for customers. The limits come from specific licence terms, trademarks and, for source-available projects, explicit restrictions on hosted services.

This is practical guidance, not legal advice. If your business depends on the answer, pay for a legal review of the licence, your modifications and your branding before launch.

Which licences allow hosted commercial use?

Check the licence of the exact release you start from, plus any enterprise directories, which are often under different terms. Projects have moved from open-source to source-available licences before, so pin your starting version and track upstream announcements.

What about the project’s name and trademark?

Code licences cover copyright, not trademarks. Many projects keep their name and logo under a trademark policy that forbids or restricts using them in commercial product names or domains.

Choose your own brand, and describe the relationship honestly, for example “managed hosting for” followed by the project name, only if the trademark policy permits that phrase. Read the policy file or website section before buying domains.

If a project has no written trademark policy, that does not mean the name is free to use. Unregistered marks can still be protected in many places, so the cautious route is a distinct name and a descriptive mention.

Being respectful here is also good business. Maintainers who feel their brand is being exploited are less likely to accept your contributions or recommend you.

Should you fork or build around upstream?

Forking gives you full control but makes you responsible for merging every future security fix and feature. The longer your fork diverges, the more expensive each merge becomes.

Building around upstream means running the unmodified project and adding your value outside it: provisioning, billing, backups, single sign-on, monitoring and integrations. Where you need changes in the core, contribute them upstream. This keeps upgrades cheap and relationships healthy.

Many hosted offerings combine both: a thin set of patches maintained as a small, rebased branch, with everything else in separate services.

Whatever you choose, automate the upgrade path. A script or pipeline that pulls a new upstream release, applies your patches, runs tests and deploys to a staging tenant turns upgrades from a quarterly project into a routine task.

Also check whether upstream requires a contributor licence agreement. Signing one may give the maintainers rights to relicense your contributions, which is worth understanding before you send code you consider strategic.

What do customers actually pay for?

The software is free for anyone to self-host, so your customers are paying to avoid work and risk. Be explicit about which work you remove.

• One-click setup, custom domains and TLS without touching a server.
• Automatic updates and security patches, tested before rollout.
• Backups with tested restores and clear retention.
• Monitoring, uptime targets and someone who responds when it breaks.
• Team features: single sign-on, roles, audit logs, usage reports.
• Integrations and templates for a specific industry or workflow.
• Data residency, compliance paperwork and a real contract.

How do you launch step by step?

• Pick a project with real demand, active maintenance and a licence you have verified for hosted use.
• Choose a niche: an industry, a region, a company size or a workflow the generic project does not serve well.
• Run it yourself in production-like conditions for weeks, and document every operational task you perform.
• Automate provisioning per customer, whether that means one instance per tenant or a carefully isolated shared deployment.
• Build backups, upgrades and monitoring before the signup page, not after the first incident.
• Write terms of service, a privacy policy and a data processing agreement appropriate for your market.
• Launch to a small group, measure support load per customer, and price with that load in mind.
• Contribute fixes upstream and follow the project’s release notes and security advisories closely.

How should you price and run the service?

Price from your costs and the value you remove, not from the fact that the code is free. Measure infrastructure per customer, support hours per customer and the time spent on upgrades, then add margin. Customers comparing you with self-hosting are really comparing you with an engineer’s time.

Tie plans to things that drive your costs or their value: number of users, workspaces, storage, compute, support response times or compliance features. Avoid pricing on a metric you cannot measure reliably from day one.

Operate like an infrastructure company. Keep a staging environment that mirrors production, roll out upstream releases to internal tenants first, and write runbooks for restore, rollback and incident communication. A single botched upgrade that loses customer data costs more than any feature.

Plan an exit path for customers. Offering data export and a documented way to move to self-hosting sounds counterintuitive, but it lowers the perceived risk of buying from a small provider and fits the open-source audience’s expectations.

Where does it break? Common mistakes

• Choosing a project whose licence changes or already restricts hosted services, then discovering it after launch.
• Using the project’s name as your brand, inviting a trademark dispute.
• Forking heavily early, then falling behind on upstream security fixes.
• Underpricing because the software is free, while support and operations costs grow with each customer.
• Running one shared instance without real tenant isolation, so one customer’s load or bug affects all of them.
• Competing head-on with the maintainers’ own cloud offering without a clear niche or better service.

How do you pick the right project to build on?

Look for projects that businesses want but struggle to run: databases with tricky upgrades, apps with many moving parts, or tools that need GPUs or careful tuning. Operational pain is what makes hosting valuable.

Talk to potential customers before you build anything. Ask current self-hosters what breaks, how long upgrades take and what they would pay to stop doing it. Their answers tell you which features matter and whether a niche exists.

Check health signals before you commit: recent releases, responsive maintainers, security advisories being handled and more than one active contributor. Your business inherits the project’s maintenance risk.

Check whether the maintainers already sell a hosted version. That is not a dealbreaker, but you need a clear reason customers would choose you, such as region, industry focus, price point or bundled services.

RepoLoot’s catalog describes what can be built on each project, its business value and difficulty, which is a useful starting shortlist before you do your own licence and health checks.

Frequently asked questions

Do I have to open-source my SaaS if it uses AGPL code?

Not your whole SaaS by default, but if you modify the AGPL software and users interact with it over a network, you must offer them the source of that modified software. How far this reaches into connected components is debated, so get legal advice for your architecture.

Can I charge for hosting an MIT-licensed project?

Yes. MIT allows commercial use, including selling hosted access. Keep the copyright and licence notices where required, avoid using the project’s trademarks in ways its policy forbids, and remember that competitors can legally offer the same software, so your advantage must come from service, niche and execution.

Should I tell the maintainers I am building a business on their project?

It is usually wise. Maintainers can warn you about roadmap changes, and a good relationship makes your upstream contributions easier to land. Many businesses also sponsor the projects they depend on, which supports the maintenance your service relies on and builds goodwill in the community.

Is it better to host one instance per customer or a shared instance?

One instance per customer offers stronger isolation, simpler data residency and easier per-customer upgrades, but costs more to run and automate. A shared instance is cheaper but needs the software to support multi-tenancy safely. Many start per-customer for business plans and shared for small plans.