For this directory, I catalogue open-source alternatives to commercial software. You would expect me to tell you that every paid subscription is a tax you can shed by self-hosting. I won’t, because it isn’t true, and pretending otherwise would make this directory useless. The honest version is more boring: open source is the right move surprisingly often, and the wrong move often enough that “just self-host it” deserves a hard look before anyone files a cancellation.
Below are the situations where I’d tell a team to keep paying. None of them are about open source being inferior software. They’re about the gap between the software and the obligations a business carries around it.
When a certificate is part of the product
The clearest case is regulation. If you handle cardholder data, health records, or anything that lands you inside SOC 2, ISO 27001, HIPAA, or PCI DSS scope, a SaaS vendor’s audited attestation is doing work that no codebase can do for you. The vendor has paid an external auditor to assert that controls exist and operate. When your own auditor asks how access to that system is governed, “we run the open-source version on a VPS” is the start of a long, expensive conversation, not the end of one.
You can self-host compliantly — plenty of regulated companies do — but then you inherit the evidence-gathering, the access reviews, the change logs, and the audit interviews. That labour is the thing you were buying. An identity provider like Auth0 is a good example: the appeal of a hosted option is partly the certifications that come stapled to it. A self-hosted alternative such as Keycloak is genuinely capable, but it shifts the compliance burden onto your team rather than removing it. Choose deliberately, not by reflex.
When the SLA is load-bearing
Some systems can be down for an afternoon and nobody outside the office notices. Others can’t. If a contract with your own customers promises uptime, or if an outage stops revenue, then a vendor’s service-level agreement — with credits, an escalation path, and someone whose job is to answer your 3 a.m. page — is not a luxury. It’s risk transfer.
Self-hosting means you are the on-call rotation. There is no support tier to escalate to, only your own engineers and a community forum. For observability, where you’re often the last line of defence during an incident, this is acute: a tool like Datadog is paying a team to keep the monitoring up while everything else is on fire. Run an open-source stack like Grafana with Prometheus instead and you’ve absorbed that responsibility yourself. Fine if you have the people. Dangerous if you don’t.
When the missing 10% is the part you need
Feature parity is usually overstated in both directions. Most open-source alternatives cover the workflows that 80% of users actually touch. The trouble is when your team lives in the other 20%. A workflow-automation buyer might find an open-source option such as n8n handles the bulk of what Zapier does — until they hit the one connector or the one governance feature their finance process is built on, and it isn’t there. The headline feature list looked complete. The specific capability you depend on was the gap.
Before migrating, write down the three or four things that would genuinely break your operation if they vanished, then check those specifically. General comparison tables — including the ones on this site — won’t catch a niche dependency. Only you know which corner of the product is holding up your business.
When nobody is going to run it
This is the failure mode I see most. Self-hosted software is not free; it’s unpriced labour. Someone patches it, monitors it, upgrades it, restores it after the disk fills, and figures out why it broke after a dependency bumped a major version. If your team has no one who can own that — and “the founder does it at weekends” is not ownership — the software will quietly rot until an incident forces the issue.
A subscription, for all its faults, outsources operational competence. That has real value to a small team whose scarcest resource is attention, not cash.
When the maths doesn’t close
Run the actual numbers, not the sticker comparison. The fair calculation is: SaaS fee versus (infrastructure + engineering hours + the opportunity cost of those hours spent elsewhere). For a low-priced tool a team uses lightly, the migration almost never pays back — you’ll spend more in salaried hours moving and maintaining it than years of subscription would have cost. The arithmetic tilts toward open source as seat counts climb, as per-seat pricing compounds, or as a vendor’s price increases outrun your patience.
When the data won’t move cleanly
Migration risk deserves its own line. Exporting from a closed platform is sometimes lossy — relationships, history, attachments, or permission structures that don’t survive the round trip. If the data is critical and the export path is murky, the safe move is to pilot a one-way copy and verify integrity before you commit, rather than discovering the gaps after you’ve cancelled the source.
So when does open source win?
Plenty of times, and it’s worth saying clearly so this doesn’t read as a defence of incumbents. Open source is the strong choice when you have the operational skill in-house, when avoiding vendor lock-in is a strategic priority, when data residency or privacy means you want everything on infrastructure you control, when the SaaS pricing has stopped matching the value, or when you need to modify the software in ways a vendor will never prioritise. For a great many teams those conditions hold, which is exactly why this directory exists.
The point isn’t open source versus SaaS. It’s matching the tool to your obligations, your team, and your honest tolerance for operational work. Sometimes that answer is self-hosted. Sometimes the grown-up decision is to keep paying — and recognising which is which is the whole skill.