How we rank and review

Where the data comes from

Alternatives are sourced from the public GitHub REST API v3 — specifically GET /search/repositories and GET /repos/{owner}/{repo}. For each candidate repository we record: repository name, owner, description, primary language, SPDX license id, star count, archived flag, and the pushed_at timestamp of the last push to the repository (any branch — GitHub does not restrict it to the default branch). A daily cron-driven ETL re-fetches this data and the site is rebuilt automatically, so what you see on a comparison page reflects what GitHub returned at the last daily run, not a stale manual snapshot. The clickable repository link on every alternative card is the primary citation — it points at the GitHub source that supplied each value on that card. Where the API returns no SPDX id (open-core and custom licences come back as NOASSERTION), we read the repository's LICENSE file ourselves and show that value marked †, linked to the exact file and commit we read, with the date we checked it.

Each alternative card surfaces the last-pushed date for the underlying repository so you can judge maintenance freshness directly from the source signal rather than trusting a generic "updated" banner. We deliberately do not paper over silence: if upstream has not shipped a commit in 12+ months we say so on the page rather than reusing the SaaS comparison's own "last reviewed" date.

Data we do not use: download counts from package registries (npm/PyPI/Docker Hub) are excluded because they are gameable and inconsistent across ecosystems; we rely on stars + last-pushed as the cross-language baseline.

What Claude drafts vs. what we write by hand

We are explicit about this so readers can tell repository facts apart from editorial framing, and see which sentences were drafted with a language model and which were written by hand. The general policy (three production paths, and the May 2026 end of API use in the pipeline) is stated once on the About page; the split on a comparison page is:

• Claude-drafted: the per-page intro paragraph, the comparison notes (pros/cons framing and "who should use this / who should skip" cues), and the migration tips. They are drafted with Claude — in Claude Code sessions or scheduled routines run under the operator's account — against the upstream GitHub metadata for that specific SaaS and its alternatives. Samples are spot-checked against the upstream repository; entries are not individually reviewed unless they carry a signature, and a few have been hand-edited by the operator. The prompts do not invent repositories, but the text can still get a licensing edge case wrong; the repository link on each card is the authority.
• Deterministic / templated: the alternative cards themselves (name, stars, license, language, last-pushed), the upstream activity block (latest release, releases in the last year, open issues, archived flag), and the "At a glance" score table are rendered straight from GitHub API data by fixed rules, untouched by any model. Sort order, the "X of N shipped a commit in the last 12 months" line, and the curation gate (see below) are pure code.
• Signed editorial: the "Editor's take" on each comparison page and the guides carry an author and a last-revised date. They are drafted in Claude Code sessions the operator runs, then read and confirmed by the operator before publication. They are written from each project's README, LICENSE, release history, issue tracker, and the write-ups its operators publish — not from running the project in production; where that distinction matters, the take says so in its text.
• Written by hand: this page, the About page, the legal pages, and any correction applied after a reader report.

For fields that move between rebuilds — licensing nuance (AGPL vs. GPL vs. SSPL implications), version numbers, pricing, and recent project status (forks, archive events, governance changes) — the upstream repository linked on every comparison page is the authoritative citation. We link it directly on each card so the current state is always one click away from the editorial summary.

How we rank these projects

We sort by GitHub star count, but we treat stars as a community-size signal, not a quality signal — a 50,000★ project with no commits in 18 months is not what you want to deploy in production. Each project on a comparison page is annotated with its last-pushed date, language, and license so you can apply your own ranking weights. Our threshold for calling a project "actively maintained" is at least one commit in the past 12 months; the per-page "X of N shipped a commit in the last 12 months" line above each comparison is calculated against that bar.

How we score each project

The "At a glance" table on each comparison page turns raw GitHub data into three decision axes, so you can scan the trade-offs before reading the long write-ups. Each value comes from applying a fixed editorial rubric to public signals — the rubric and its thresholds are our editorial judgement, but we apply them consistently rather than scoring projects by gut feel, and we never invent benchmarks we haven't measured.

• Adoption — a plain bucket of the GitHub star count: Niche (<1k), Established (1k–4,999), Mainstream (5k–29,999), Flagship (30k+). It proxies how much community knowledge, plugins and deployment runbooks you'll find, not code quality.
• Maintenance — based on the last push date: Active (within 90 days), Maintained (within a year), Stale (older). A stale repo isn't automatically wrong, but it changes your support calculus before you self-host.
• Commercial-use risk — read from the license, not the star count: permissive (MIT/Apache/BSD) is Low, weak copyleft (LGPL/MPL) is Medium, strong/network copyleft (GPL/AGPL/SSPL) and source-available or "fair-code" terms (BUSL, Elastic, Sustainable Use, Fair Use, Polyform, Commons Clause) are High. The license value is the GitHub API's SPDX id where one exists; where the API returns none, it is what we read in the repository's LICENSE file (marked † on the page, linked to the pinned commit, with the date checked). A project with a split licence — a permissive or copyleft core plus separately licensed enterprise directories — is rated on its core component and flagged as split. Only a project we could not resolve either way is Unknown — treat it as all-rights-reserved until you read the LICENSE file yourself.

What the table deliberately does not show is anything we'd have to fabricate — startup time, Docker readiness or migration effort require actually running each project, which this site does not do, so we do not publish measurements of them. Where a take mentions a resource footprint or a deployment shape, it is repeating the project's own documentation, not a benchmark of ours. The axes above are decision aids; the GitHub repo linked on each row is always the primary source.

Below the scores, each project also shows raw upstream activity pulled straight from the GitHub API — its latest release and date, how many releases shipped in the last year, the open issue/PR count, and an archived-repository warning where it applies. Those are unedited facts, refreshed automatically. We deliberately don't attach an opinion to them: the editorial judgement belongs in the written take, not in an auto-generated caption.

Why some SaaS pages aren't published

Not every SaaS we have data for makes the cut. A comparison page is built, indexed, and linked internally only when it clears all of these objective gates:

• At least 3 open-source alternatives with usable metadata (so a comparison table is actually possible)
• The top alternative has at least 800★ on GitHub (no anonymous / empty-topic pages)
• The intro paragraph is at least 80 characters of Claude-drafted text (no templated stubs)
• The intro was not produced by the hard-coded fallback template (pages whose editorial text would only be templated are not built)

Category pages follow the same logic at the category level: a category page is only built when it contains at least 1 curated SaaS page. Sub-threshold SaaS are not given a public comparison page at all — a page is only generated once it clears the gate, so thin entries never reach the index, sitemap, internal navigation, RSS feed, or breadcrumbs rather than being published as a low-value page. The rationale: we'd rather have fewer pages that are each worth reading than a wide index of thin pages, both for readers and for search-quality compliance. The exact thresholds live in src/lib/curation.ts and are mirrored in astro.config.mjs so the sitemap cannot drift from the in-page logic.

Self-hosting cost reality check

The compute that runs an open-source project is usually the smallest line in the budget. The real cost is operational: backup automation and restore drills, OS and dependency patching, TLS renewal, monitoring and the on-call attention behind it, and incident response. Those costs scale with the complexity and the stakes of the service more than with its usage — roughly the same set of duties whether you have ten users or ten thousand, and heavier the more downtime actually costs you. SaaS pricing, by contrast, scales with usage (seats, events, gigabytes), which is why self-hosting tends to look better as a SaaS bill climbs and worse for a small team whose scarcest resource is attention.

We deliberately publish no hour, dollar, or payback figures here. Earlier versions of this page did, and we removed them: this site runs none of the projects it lists — its own pipeline is a GitHub Actions workflow on a self-hosted runner the operator maintains, publishing static files — so we have no measured operating costs for these projects to report, and the operator write-ups the framing above is drawn from vary by roughly an order of magnitude between "runs a Docker Compose once a quarter" and "PII-bearing production". A number we cannot source is not a number we should print. The hidden cost of self-hosting guide walks through the line items in more depth.

A realistic migration timeline

A migration off a SaaS has four phases, and skipping one is where most of the pain comes from: an evaluation pilot on real data, data export and import scripting, a parallel run with both systems live, and user cutover. How long each phase takes depends on the data shape and the team, so we do not publish durations. Always export the SaaS data into a portable format (CSV, JSON, or the spec format the OSS tool accepts) before you touch production. The per-page "Migration tips" section, when present, covers the data-shape gotchas specific to that SaaS.

When you should stay on the SaaS

Self-hosting pays back at scale and political-risk hedging, not at small-team convenience. Stay on the SaaS if any of these apply: (a) your team is small and the SaaS bill is modest relative to the engineering time it would take to own the stack; (b) you depend on a SaaS-exclusive integration that no OSS project replicates; (c) nobody on the team is willing to own the self-hosted stack on a recurring schedule. The when not to replace SaaS guide covers the compliance, SLA, and data-portability cases in detail.

Editorial independence

We are not affiliated with the vendors, projects, or models listed beyond standard, disclosed affiliate programs for adjacent services (e.g. VPS hosting referral links). A vendor paying an affiliate commission does not buy placement, a higher ranking, or a more favorable summary. See our Affiliate Disclosure for the full picture, and our Privacy Policy for how visitor data is handled.

Found a mistake? Tell us.

AI summaries get licensing edge cases wrong. Star counts go stale between rebuilds. Projects get archived, forked, or relicensed without us noticing. If you see something incorrect — especially on licensing, archive status, or governance — send the page URL and what is wrong to the address on the Contact page (prefix the subject with [correction]). We acknowledge within 5 business days and aim to ship the fix within 14 days. Maintainers of indexed projects can also request removal from the same address; see the Contact page for the verification steps.

When this changes

If we materially change how data is sourced, how rankings are computed, which models we use, or how affiliate links are placed, we update this page and the "Last updated" date on the relevant legal page. The framework above is intentionally stable — the per-page numbers move with the underlying GitHub data, not with our opinions.