When someone recommends an open source tool, our first instinct is to peek at the GitHub page and check the star count. Twenty thousand stars? Looks serious. Five hundred stars? Feels risky. This heuristic is convenient and about 60% useful. The other 40% of the time, it sends you straight into a ditch.

High-star projects die quietly. Low-star projects become the load-bearing infrastructure of your workflow. The stars don't tell you which is which. Below is the framework we use in this directory to evaluate open source alternatives — five signals that genuinely matter, in rough order of importance.

1. Commit cadence over the last six months

Pull up the project's GitHub insights (Insights → Contributors, or just /graphs/commit-activity). What does the last six months look like?

  • Healthy: 30+ commits per month, spread across multiple weeks, with at least one commit from a non-owner contributor.
  • Stable-maintenance: 5–15 commits per month, mostly dependency bumps and bug fixes. This is fine for mature projects with small surface area.
  • Warning: <5 commits per month, all from the original author. Often a sign of burnout or pivot.
  • Dead: No commits in six months. Can still work, but reconsider if you need something that's being actively maintained.

One caveat: some projects have "slow but sure" cadence by design. LibreOffice commits are thousands per month; dnsmasq does a release a year and that's fine. The question is: does the cadence match the project's promise? If a project markets itself as "actively developed," but the graph shows a cliff three months ago, that's a signal. Cross-reference with the issues/discussions — a sudden stop usually has a visible story behind it.

2. How many people have merged code in the last year

GitHub → Insights → Contributors. Count how many humans have had at least one commit merged in the last 12 months.

  • 1 contributor (bus factor = 1): Everything runs through one person. If they stop, the project stops. Fine for a hobby dependency, scary for anything you're relying on.
  • 2–3 contributors: Better, but still fragile.
  • 10+ contributors: The project has absorbed outside contribution and can probably survive a maintainer change.
  • 50+ contributors: Mature enough to have real governance, for better or worse.

This number is more important than raw commit count, because it tells you about durability rather than activity. A project with 5,000 commits from one person is more brittle than one with 500 commits from 50 people.

3. Issue responsiveness, not issue count

The "open issues" count on GitHub is meaningless. What matters is: when somebody files a new issue, does a maintainer respond?

Click into a few recent issues. What's the time from filing to the first maintainer comment?

  • Under 48 hours: Healthy. The maintainer is engaged.
  • Under two weeks: Acceptable for a hobby project.
  • Issues from months ago with no response: Warning. Either the maintainer is overwhelmed, uninterested, or gone.

Also look at closed issues. Are they closed with resolutions or just with "stale — closing"? A project that closes issues by aging them out is a project where your bug reports will die.

4. Release cadence and versioning

Check the Releases tab. A project that ships a real release (with notes, not just a Git tag) at least every few months is in a different league than one that hasn't tagged a release in two years but "just use main."

  • Proper semver + release notes: Signs of professional discipline. You can upgrade safely.
  • Tags but no release notes: Acceptable for small projects.
  • "Just pull main": Red flag for anything running in production. You will get burned by a breaking change you didn't see coming.

Also look at: is there a changelog? Is there a migration guide for major versions? These are signs the project thinks about users beyond the primary maintainer.

5. License clarity

Check the LICENSE file. For reasons beyond this essay, not every "open source" project is actually open source. Watch for:

  • AGPL-3.0: Genuinely open source, but has strong copyleft requirements that matter if you're building a SaaS on top.
  • MIT / Apache-2.0 / BSD-3-Clause: Classical permissive. Low-friction to use commercially.
  • "BSL" (Business Source License), "Sustainable Use License," "Elastic License v2": These are source-available, not open source. The vendor is signaling they want to control commercial use. Often a good product, but don't assume open source guarantees (no guaranteed fork, no guaranteed continued freedom).
  • "Fair-code" / "Commons Clause": Same as above. The project's founders may be wonderful people, but you're trusting them, not the license.
  • No license file at all: Legally closed by default. Often an oversight, but don't build on it without asking.

Signals that look good but often aren't

A few things that look meaningful but aren't very predictive.

GitHub stars. Tell you about marketing, not quality. A viral Hacker News thread years ago can inflate a dead project's count. Current activity is the better signal.

Docker pulls. Can be a bot. Can also be inflated by one popular tutorial that said "just docker run this."

Number of forks. Similar to stars. Forks get created when people plan to contribute, and also when people want to read the code. Only meaningful if paired with sustained contributions back upstream.

"Built by ex-Google engineers." Nice, but not predictive. Many great projects come from nowhere. Many pedigreed projects stall.

Signals that matter more than GitHub shows you

Community forum activity. Discourse, Discord, Zulip, Matrix. A project with 5,000 stars but a dead Discord is probably trading on past virality. A project with 500 stars and an active Discord where the maintainer answers questions daily is probably the one you want.

Quality of the docs. Read the Getting Started. Can you install it without Googling? Did you trip over a typo or an out-of-date instruction? Docs are the tell for whether the project cares about users, as opposed to caring only about the code. A project that cares about users is a project that will still be around in three years.

Governance documents. Does the project have a CONTRIBUTING.md? A CODE_OF_CONDUCT.md? A STEERING.md? These don't make a project good, but their absence on a project claiming to be "community-driven" is a tell.

Applying this in practice

Most of our directory entries include license and self-host difficulty scores explicitly. Before you pick an alternative and commit to it for anything important, do this 10-minute test:

  1. Open the GitHub repo. Look at commit cadence.
  2. Count distinct contributors in the last year.
  3. Read the 3 most recent issues. How fast did a maintainer respond?
  4. Read the last release notes. Is the project shipping?
  5. Verify the license is what you expect.

If four of those five look good, the project is probably solid. If only two or three look good, read more carefully before you commit.

The best open source projects are usually not the loudest ones. They're the ones with a few dozen steady contributors, a boring but consistent release cadence, and a maintainer who answers issues within the week. When you find those, you've found something worth building on.

Want to apply this lens to a specific category? Browse our category index — we've done a first-pass evaluation on every project listed, but your own 10-minute review before committing is always worthwhile.