Who runs this site
OSS Alternatives is written and operated by Yusuke Morinaga, an independent developer based in Japan (GitHub: @mori7ga2222, [email protected]). I build small SaaS and directory products, this site among them, and I set the rules every page follows: which projects qualify, how they are scored, and what gets said about them. This is a one-person publication, not a company front for a vendor, a paid review shop, or an SEO agency pretending to be a publisher.
The registered business mailing address is published in full on the Contact page, alongside the correction and takedown process.
Why this site exists
Most "alternatives to X" lists you find on the open web are either (a) marketing pages from a direct competitor, (b) automated scrapes with no opinion, or (c) rankings that never say where their numbers came from. We wanted the in-between: opinionated tradeoff notes anchored to live GitHub data, kept fresh by a deterministic ETL pipeline, with the Claude-drafted parts clearly labeled so you know what is editorial framing vs. what is upstream fact.
See the Methodology page for the editorial process this site applies in detail — where the data comes from, how projects are ranked, and which text is written by hand, which is drafted with Claude, and which is computed.
What the editorial takes are based on
The Editor's take on each comparison page, and the guides, are written from the public record of each project: its README, LICENSE file, release history, issue tracker, deployment docs, and the migration write-ups and postmortems its operators publish — checked against the GitHub data shown on the same page. They are not based on running the projects in production; where that distinction matters, the take says so in its text.
This site's own pipeline is a GitHub Actions workflow — the data-refresh job runs on a self-hosted runner (a Mac the operator maintains) and the result is published as static files. None of the projects listed here are run by this site, so it does not report first-hand operating-cost or incident figures. The cost and migration guidance on the Methodology page is deliberately qualitative for that reason.
How we decide what counts as a serious alternative
Our objective inclusion thresholds are documented on the Methodology page, but the short version is: a SaaS comparison page is only built when it has at least 3 open-source alternatives, the top alternative has at least 800 GitHub stars, and the editorial intro is a real drafted paragraph (not a templated stub). The why behind those specific numbers:
- ≥ 3 alternatives — fewer than 3 makes the comparison table less useful than just reading the top project's README. A one- or two-entry page is a redirect, not a directory entry.
- ≥ 800 stars on the top alternative — below this, the project is usually too early for production teams to evaluate seriously, and our pros/cons summary won't be reliable because we don't have enough community signal to lean on.
- ≥ 80-character intro — eliminates pages where the drafting step failed and fell back to a one-line template. Those SaaS are not given a public comparison page until the intro clears this bar, so the index only contains pages that are actually worth reading.
AI usage policy
Text on this site is produced in one of three ways: (a) written or line-edited by hand by the operator and signed with a date; (b) drafted with Claude through Claude Code sessions or scheduled routines the operator runs against the upstream metadata, then spot-checked — not individually reviewed unless (a) applies; (c) assembled by deterministic templates from metadata. We stopped calling Anthropic's API from the pipeline in May 2026; entries drafted through the API before then are not distinguishable from (b) and are labelled Claude-drafted. Pages whose editorial text is only (c) are not published.
On this site that maps as follows. This About page, the Methodology page, and the legal pages are
(a). The Editor's takes and the guides are drafted in Claude Code sessions the operator runs, then
read and confirmed by the operator before they are signed with a name and a last-revised date. The
per-SaaS intro, comparison notes, and migration tips are (b): most were written by a scheduled
Claude Code routine run under the operator's account, and a handful have since been hand-edited by
the operator; samples are spot-checked, entries are not individually reviewed unless signed. Repository facts (stars, license, language, last pushed,
releases, open issues) come straight from the GitHub public API — except that where the API returns
no SPDX license id we read the repository's LICENSE file ourselves and mark that value
with a † linked to the exact commit we read, with the date checked — and the "At a glance" table is
computed from them by fixed rules. That is (c), and no language model touches it. The complete
split is on the Methodology page (AI vs. human roles).
Corrections and contact
Found a wrong license, an archived project we're still treating as active, or an alternative that should obviously be on a list and isn't? Email [email protected] with the page URL and what's wrong, or use the Contact page for the full intake format (correction, removal, partnership, bug). We acknowledge within 5 business days and aim to ship corrections within 14 days. Project maintainers requesting removal: see the verification steps on Contact.
Editorial independence and monetization
We are not affiliated with any vendor, project, or model listed on this site. The site is funded by a combination of disclosed affiliate links (primarily for VPS hosting and adjacent services that readers would likely buy anyway when self-hosting) and, where eligible, display advertising. Affiliate commissions never buy placement, ranking, or a more favorable summary — the full editorial-independence statement and the AI / human-roles split is on the Affiliate Disclosure, and the Privacy Policy covers how visitor data is handled. The same operator also runs aiappdex.com and findindiegame.com; they share the legal pages but are separate publications.