Trust
Methodology
How projects get into the catalogue, what the labels mean, and how we keep entries accurate.
Who adds entries
Every project and revival is submitted by a signed-in community member. Submissions start as pending and stay invisible to the public until a moderator approves them. Moderators' own submissions are published directly.
Approved is not the same as verified
- Approved means a moderator checked that the entry is in scope, not spam, and follows the guidelines.
- Verified means a moderator also checked the facts against the original sources: the repository, the maintainers' own statements, and the revival's repository or website.
- Last verified shows when that check last happened. Projects change; an old date is a hint to double-check.
Moderation states:
- Pending review: Submitted, not yet public.
- Approved: Published in the catalogue.
- Rejected: Not published; the submitter sees a note.
Project status is a judgement
We never mark a project as abandoned automatically. An old last commit can mean “finished” as easily as “dead”, and a busy repository can still be unmaintained. Status comes from the submitter and is checked by moderators, using evidence such as maintainer announcements, an archived repository, unanswered issues and pull requests, or broken releases.
- Abandoned: The maintainers have explicitly stopped or clearly walked away.
- Dormant: No meaningful activity for a long time, but not formally abandoned.
- Seeking revival: Looking for people willing to pick it up.
- Revival in progress: Someone is actively working on bringing it back.
- Revived: Successfully brought back to life.
- Forked: Development continues in a fork rather than the original.
- Revival failed: A revival was attempted but did not stick.
Repository data is evidence
Stars, forks, open issues, languages, the last commit and release dates, the archived flag and the licence are fetched from the GitHub, GitLab or Codeberg API. The fetch time is shown next to them. This data can be stale or wrong (for example, mirrored repositories), so it informs a project's status but never sets it.
Revival types
A revival does not have to be a fork. We distinguish:
- Fork: Continues the original codebase.
- Rewrite: Same project, new codebase.
- Reimplementation: Independent implementation of the same design, format or protocol.
- Successor: Endorsed or de facto next-generation project.
- Alternative: A different project that solves the same problem.
- Compatibility layer: Keeps software, data or plugins built for the original working.
- Replacement: A drop-in replacement for the original.
- Other
Corrections
Anyone with an account can use Report a problem or Suggest a correction on a project page. Reports go to the moderation queue. A moderator checks the claim, edits the entry if needed, and marks the report resolved or dismissed. You can follow the status of your reports on your account page.
Maintainers of a listed project can ask for corrections or removal through the contact page.
Independence
Entries are not paid for, and listing a project or revival is not an endorsement or a security review.