How ZBS Index works

This catalog is built by software that reads public sources and records where every field came from. Nothing on it is written from memory, and nothing is summarised from a vendor’s marketing page.

Where the data comes from

Entries are ingested from official registries and public repositories. For each field we store the exact document it came from, that document’s content hash, and the date it was observed. If a source changes, it becomes a new document rather than overwriting the old one, so an old claim always points at the bytes it was actually derived from.

Sources are ranked by how directly they know the thing they describe: an official structured API first, then an official page, then a repository or package registry, then independent measurement, then community reports, and vendor marketing last. Anything we worked out ourselves is marked as inference and carries reduced confidence.

Why there is no overall score

Stars, downloads, votes, saves and website traffic measure different things, and adding them together produces a number that cannot be checked or acted on. So we never do it. Each measurement is shown separately with the window it covers, its source, its date and a sentence saying what it actually measures.

If a number cannot be explained in one sentence, it is not shown as a ranking signal at all.

What "verified" means here

We currently track 23,781 entries and have checked 10,523 of them against their upstream repository. Checking means we requested the repository the maintainer listed and recorded whether it exists, whether the owner archived it, and when it was last pushed to.

It does not mean we ran the software, tested its output, or confirmed that it does what its description claims. Where a page says something is untested, that is literal.

A page enters the search index only after at least two independent sources have been observed for it. One source means we reprinted somebody’s listing, which is not worth a search result.

How listings are ordered

By the date of the most recent push to the project’s repository, not by popularity. A widely bookmarked project that stopped two years ago is not a better answer than a smaller one shipped last week, and ordering by stars is precisely how stale entries end up at the top of directories.

Entries whose repository is gone or archived are still shown, grouped separately and marked, because knowing something is dead saves more time than not finding it at all. They are excluded from the search index.

What we get wrong

Category tags are derived by matching keywords against the maintainer’s own description. They are a starting point, not a judgement, and they are marked as derived wherever they appear.

Coverage is uneven: most of the catalog has not been checked yet, and pages say so rather than implying otherwise.

If you find something wrong, the fastest correction is to fix it at the source we cite, because the next sweep will pick it up automatically.