Open-source catalog
Where the catalog rows come from, what each importer keeps, how often the data refreshes, and how to get an entry corrected.
Behind alternatives and wellworn.dev/alternatives sits a catalog of open-source tools and packages. It is not a verdict corpus. Nothing in it has been reviewed, tested, or recommended: it is other people's metadata, imported and kept attributable, so that a search for a replacement has somewhere to start.
Every catalog row carries an attribution value naming where it came from. Staff-written entries, the ones verdicts are built on, have none. That single column is what keeps the two apart: an importer only ever updates rows its own source created, and the nightly freshness pass ignores everything with an attribution.
The sources
| Source | What it contributes | Licence of the data |
|---|---|---|
| awesome-selfhosted-data | Self-hostable applications with categories, licences, star counts and release dates | CC BY-SA 3.0 |
| awesome-sysadmin-data | Operations and infrastructure tooling, same file format | CC BY-SA 3.0 |
| registry.npmjs.org | npm packages the registry's own search returns for 50 curated topics | package metadata, per package |
| pypi.org | A hand-written list of 30 well-known Python packages, each validated against the JSON API | package metadata, per package |
| registry.modelcontextprotocol.io | MCP servers, with their transports and packages | registry entries, per server |
| GitHub | Agent skills published as SKILL.md files in public repositories | per repository |
Verified 2026-09-08 against registry.modelcontextprotocol.io
Descriptions are always the maintainer's own words. Nothing is rewritten, which is why some rows read oddly and why a row with no description is dropped rather than filled in.
What each importer keeps out
Every importer refuses more than it accepts, and the rules are worth knowing before you conclude that something is missing.
The two awesome catalogs need a name, a description, and either a source repository or a website. They bring stars, commits over the last three months, platforms and licences with them, and a repository the upstream data marks as archived becomes a row with status archived rather than a deletion.
The npm importer requires a description, a resolvable repository link, and at least 20,000 weekly downloads. PyPI has no official search API, so its list is curated by hand per topic rather than crawled.
Slugs are prefixed to stop collisions across sources: an npm package lands as npm-<name> and a PyPI package as py-<name>, because redis and minio name a hosted tool, an npm client and a Python client all at once, and the catalog would otherwise overwrite one with another.
The MCP registry importer needs a name, a description, and a documentation, website or package URL; entries with none of those are skipped.
How often it refreshes
The importers are commands, not schedules. Someone runs them; nothing runs them nightly. The only job on a timer is the 02:00 UTC freshness pass, and it deliberately skips every catalog row: it reads registries for the nodes a verdict depends on and leaves the catalog alone.
Practically, that means a star count or a last-release date in the catalog is as old as the last import. The date to trust on a catalog page is the release date shown on the row, not the freshness of the page. Verdict pages are the opposite: they carry a verification date and an expiry, and they are checked nightly.
Re-running an importer is safe at any time. Rows are upserted by slug, so a second run updates what changed and adds what is new rather than duplicating anything.
Thin pages
A catalog page with no maintainer summary is served with noindex, and so is one with fewer than 20 stars and no release in two years. Both stay readable and stay linked from their category; they are kept out of search results because a page with no description says nothing a search result can use. Verdict pages are never treated this way.
Correcting an entry
For anything that came from one of the two awesome catalogs, the fix belongs upstream: open a pull request against the source repository. The next import picks it up, and the correction helps everyone using that data rather than only this catalog. Package metadata works the same way; a wrong description on npm or PyPI is wrong at the source.
For anything else, or for a row that should not be in the catalog at all, email support@wellworn.dev with the slug. Catalog corrections are not the same queue as a verdict dispute, and they are quicker: nobody has to reproduce anything.
What the catalog is not
No row in it is a recommendation. Tool pages say so directly when no verdict has been tested against them. If you want a judgment rather than a list, that is what recommend and compare are for, and the honest answer from them is often that no verdict exists yet.