Skip to content
appsgit

Last updated

How we label project health

Every project on appsgit gets one maintenance label, a few yes/no badges and the raw numbers behind them, with the date of the data. There is no overall score and no star rating: a label describes recent activity on GitHub, not quality, security or whether the software suits you.

Maintenance labels

Each project gets exactly one label. The rules are checked in this order, and the first match wins. "Days" are whole calendar days (UTC) between a date and the snapshot date shown next to the label.

Archived

The maintainers archived the repository on GitHub, so it is read-only. Self-hosted apps and the other collections drop archived repositories at the next refresh, so you will rarely see this label.

Too new to judge

The repository was created less than 90 days before the snapshot. We do not judge maintenance this early, following OpenSSF Scorecard, whose checks documentation says projects younger than 90 days "are too new to assess whether they are maintained or not" (Scorecard checks, Maintained).

Active

Both of these are true:

  • the last commit is at most 90 days before the snapshot, and
  • the project has at least 24 commits in the last 12 months, or a GitHub release published at most 183 days (six months) before the snapshot.

We only count commits for self-hosted apps. MCP servers, agent skills, templates, mobile apps and desktop apps can reach Active only through the release rule. Missing data never counts as meeting a threshold, so a project we know less about is labelled Maintained rather than Active.

Maintained

The last commit is at most 365 days before the snapshot, but the project does not meet the Active rule.

Quiet

The last commit is more than 365 days before the snapshot and the repository is not archived. Quiet is not the same as abandoned. Scorecard puts it this way: "a lack of active maintenance is not necessarily always a problem. Some software, especially smaller utility functions, does not normally need to be maintained" (Scorecard checks, Maintained). A Quiet project may be finished. Check its issues before you rely on it.

Activity unknown

Our data has no last-commit date for the project, so we show no judgement at all.

Badges

A badge appears only when its rule is true. A missing badge can mean "no" or "no data".

Regular releases

At least 4 non-prerelease GitHub releases in the 12 months before the snapshot. We count from the 10 newest releases, so "10 or more" is the highest value we show. This follows the Release Frequency metric in the CHAOSS Starter Project Health model. Projects that ship through tags, package registries or app stores instead of GitHub releases will not get this badge.

Welcomes contributors

At least 5 open issues labelled "good first issue" or "help wanted" (either spelling, any letter case), and a contributing guide (a CONTRIBUTING file) in the repository.

Security policy

GitHub reports a security policy for the repository (a SECURITY.md file or an organisation-wide policy). It tells you how to report a vulnerability. It is not an audit and says nothing about how secure the code is.

The raw numbers we show

Next to every label we list its inputs: last commit date, commits in the last 12 months (self-hosted apps only), the latest release and its date, releases in the last 12 months and in total, open issues, open pull requests, open good first issues, whether there is a contributing guide and a security policy, and the creation date. Values we do not have are left out rather than guessed.

Data sources and refresh

  • All inputs come from the GitHub GraphQL API. For self-hosted apps, "last commit" is the repository's last push. For the other collections it is the last commit on the default branch.
  • The data refreshes every night. Every label shows the date of the snapshot it was computed from ("as of"), never the date the page was built. If GitHub cannot answer for a repository on a given night, we keep the previous night's values.
  • Counts are totals on the snapshot date, not trends. Issue and pull-request totals include bots and duplicates.

What we do not measure

  • Code quality, test coverage, documentation quality or ease of installation.
  • Security. We do not audit code or scan for vulnerabilities, and a badge is not a security rating. For security practices, see the project's OpenSSF Scorecard result where one exists. Its own documentation warns that a low score in several checks "is therefore not a definitive indication that the project is at risk" (Scorecard checks).
  • Popularity. GitHub stars are never a health input. CHAOSS notes that "popular packages are no more or less likely to follow good security practices" (CHAOSS practitioner guide: Viability).
  • How many people maintain a project, how fast they respond, or whether a company stands behind it. We may add a sampled contributor measure later and will document it here first.
  • Whether the software fits your needs, licence obligations, or hardware.

Why there is no score

A single number would look more precise than the data is. CHAOSS also stresses that there is no "one size fits all" approach and that "the thresholds for each model category will vary based on your organization's assumption of risk" (CHAOSS practitioner guide: Viability). So we publish our thresholds and the raw numbers, and you can apply your own. Health labels are not ratings, and we do not mark them up as ratings for search engines.

Report a data error

If a label or number looks wrong (for example, a project that moved repositories or releases outside GitHub), please contact us with the page URL. Maintainers are welcome to write in. Our general approach to corrections is on the editorial policy page.