How we check projects

Health score

The health score answers one question: is someone still looking after this project? It adds up five parts to a total out of 100.

Activity 30 points

Commits on the default branch in the last 90 days, on a logarithmic scale: 300 or more earns the full 30 points, a handful earns a few.

Contributors 20 points

How many different people wrote the most recent commits (up to 100), with bots left out. 30 or more earns the full points. A project where one person writes more than 80% of the work and fewer than five people take part loses 40% of this part.

Releases 20 points

How recent the latest release is (within 90 days counts fully, within a year partly) and how many releases came out in the last 12 months. Projects that never publish GitHub releases get a small fixed score rather than zero.

Replies to issues 20 points

Of the last 30 issues opened by people outside the team, how many got a reply from a maintainer, and how fast the median first reply came. With fewer than five such issues we give a neutral half score.

Security practices 10 points

The OpenSSF Scorecard, an independent automated check of branch protection, code review, dependency updates and similar practices. Projects without a Scorecard get a neutral half score.

Each project also gets a status. Archived means the owners have archived the repository on GitHub; its score is 0. Abandoned means no commit for more than a year, or a README in which the authors say the project is no longer maintained; the score is capped at 20. Slowing means fewer than five commits in 90 days and no release in six months; the score is capped at 50. Everything else is active.

A high score does not mean the software is good, and a low score does not mean it is bad. Some finished tools need few changes. The score tells you how much activity there is around the code today.

License

We read the license file itself rather than trusting the label alone, in three layers: the license GitHub detects, an SPDX identifier in the file, and the text of the file.

We mark a project as OSI open source only when its license is approved by the Open Source Initiative. Licenses such as the Business Source License, the Server Side Public License, the Sustainable Use License or the Functional Source License make the code public but restrict its use, so we call them source-available or fair-code.

Paid features in repo

Folders named ee, enterprise, premium or commercial near the top of the repository, extra license files with commercial terms, or a license file that puts part of the code under a different license.

License changed

We compare the current license file with its earlier versions in the repository’s history. Changes in a project’s first year are ignored, because new projects often start with a placeholder. We link to the commit that made the change.

Contributor agreement

A contributor license agreement file, a CLA bot, or a contributing guide that requires one. A CLA lets the owner relicense contributed code later.

App code in this repo

Some repositories carry an open-source license but hold only plugins, documentation or an SDK, while the app people download is closed. When the README says so, we show it.

This is an automated reading, not legal advice. Before you build a business on a project, read its license yourself.

Setup

We look for a Dockerfile or compose file, a Helm chart for Kubernetes, and ready-made builds for macOS, Windows, Linux, Android or iOS among the files of recent GitHub releases. Interface languages are counted from translation files in the repository.

Setup effort, from 1 to 5, comes from the compose file a self-hoster would use: one service is 1; more than one service, more than three, a heavy service such as Elasticsearch, ClickHouse or Kafka, and more than six services or 40 settings each add a point. Projects without a compose file are not rated.

Project descriptions

The short guide on each project page, what the project is, who it suits and what to check before adopting it, is drafted with AI from the project’s README and the data on the page, and signed as such. A person rewrites some of them; those are signed by the editors.

Before a description is published, an automatic check compares it with the data: the license it names, whether it says the license is not OSI open source, paid features, license changes, contributor agreements, Helm charts, interface languages and claims about who maintains the project must all match what we collected. It also rejects filler words, sentences repeated within a page or copied from another page, and links that recommend a project that has stopped. A description that fails is left off the page until it is fixed.

Category guides, the picks by use case and the advice on choosing, are made and checked the same way: every project they recommend must be in the category and still active, and license words next to a project must match its data. The license overview on each category page is built from the data alone.

Data sources

GitHub

Repository details, commits, releases, issues and files, through the public GitHub API, refreshed every day.

OpenSSF Scorecard

Security practice scores from the Open Source Security Foundation’s public API.

awesome-selfhosted

We use the awesome-selfhosted list (CC BY-SA 3.0) to discover projects and suggest categories. We do not republish its text.

Editors

Categories, display names, alternatives and the notes on some pages are chosen by people.

The current data was read on 1 November 2026.

Paid placements

Opensaurus is paid for by labeled placements and partner links. Money never changes a health score, a fact on a project page, or the order of any list. Paid placements are marked Sponsored or Featured, and partner links carry rel="sponsored".

Placements for projects and companies

Corrections

Found a wrong fact? Tell us the page and what is wrong. If the mistake comes from how we read the data, we fix the method for every project, not just one page.

Email hello@opensaurus.org.