How we rank open-source alternatives

The five signals we track

Every project on this site is scored against five signals, refreshed daily from public APIs. No manual "editor picks" without data behind them.

1. GitHub adoption (live)

Stars, forks, and open-issue count from the GitHub REST API. Stars alone are vanity — we pair them with fork ratio and issue-close rate so a 50k-star project with a 3-year-old open issue backlog doesn't outrank an 8k-star project shipping weekly.

2. Maintenance activity (live)

Last-pushed date, translated to a colour-coded activity indicator on every comparison table:

• This week / This month \u2014 actively shipping. Safe to bet on for production.
• Under 90 days \u2014 still alive but slower. Fine for stable tools, worrying for early-stage ones.
• Under a year \u2014 read the last five closed issues before committing.
• Over a year \u2014 assume abandoned until proven otherwise. Check for a community fork.

3. License risk (SPDX)

We surface the SPDX license classification on every card and group projects into four buckets: permissive (MIT/Apache/BSD \u2014 embed anywhere), weak copyleft (LGPL/MPL \u2014 fine for linking), strong copyleft (GPL/AGPL/SSPL \u2014 read carefully before hosting or redistributing), and unverified (GitHub API returned no SPDX id \u2014 treat as all-rights-reserved until you read the LICENSE file). GitHub's SPDX classification can lag a relicense; the linked repo is always authoritative.

4. Deploy difficulty (hands-on)

Every project we recommend has been deployed at least once on a Hetzner CX22 by the editor. Deploy-difficulty ratings ("Trivial / Easy / Moderate / Hard / Expert / Ops team") are based on that experience \u2014 not on the project's marketing page. If we haven't deployed it, we say so.

5. Community sentiment (attributed)

We quote real Reddit and Hacker News threads with permalinks and upvote counts, not paraphrased "users say" filler. If we can't find honest community discussion of a project, we say that too.

How the picks are ordered

The comparison table on every page is sorted by star count, because stars are the fastest heuristic for "did enough people care about this to click a button." But the recommendation matrix \u2014 the "if you are X, pick Y" list at the bottom of every article \u2014 is ordered by fit, not popularity. A 3k-star project can beat a 40k-star project for the right user.

What we don't do

• We don't take money to rank a project higher. Not now. Not later. If that changes, it will be labelled per-page and per-link, not tucked into a footer.
• We don't publish "top 20" lists that hide the losers. If a project made the list and shouldn't have, we say why in the article.
• We don't generate pages we haven't reviewed. Every SaaS guide on this site was hand-edited by a person before publishing, even when data collection was automated.
• We don't hide the age of a page. Every guide shows its last-revisited date. If it's more than 90 days old, treat it as reference, not gospel.

Hosting affiliates \u2014 the honest bit

The "Ready to deploy?" section at the bottom of every guide links to DigitalOcean, Hetzner, and Railway. Some of those are affiliate links. We include them because we deploy on those hosts ourselves \u2014 not because they pay best. The rankings on the comparison table above are completely independent of the affiliate section below it, and always will be.

If a host stops working well, we drop the affiliate. If a new host is genuinely better, we add it. The goal is that following our advice makes your self-hosting cheaper and easier, not that we make an extra $2.

Corrections and feedback

Every SaaS guide is signed by an editor. If we got a fact wrong, missed a project that clearly belongs, or you disagree with a recommendation, email hello@swaptosaas.com. Pull requests welcome once the repo is public.

How often we revisit

Data (stars, forks, activity) refreshes daily via the GitHub API. Editorial content (the actual recommendations) gets revisited when a project we recommend changes materially \u2014 relicensing, major version, ownership change, or a maintenance red-flag. Minimum revisit cadence is quarterly. If a page hasn't been touched in over 90 days, the header will show that.