When someone recommends an open source tool, the first instinct is to peek at the GitHub page and check the star count. Twenty thousand stars? Looks serious. Five hundred? 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 I 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: Fewer than 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 actively maintained.

One caveat: some projects have "slow but sure" cadence by design. LibreOffice does thousands of commits per month. dnsmasq ships once a year and that's fine. The question is: does the cadence match the project's promise? A project that markets itself as "actively developed" with a cliff three months ago is a signal. Cross-reference with the issues — a sudden stop usually has a visible story behind it (maintainer announcement, GitHub Discussions thread, sudden silence after a fundraising drive).

2. How many people merged code in the last year

GitHub → Insights → Contributors. Count humans with 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, not just 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: when somebody files a new issue, does a maintainer respond?

Click into a few recent issues. Time from filing to the first maintainer comment?

  • Under 48 hours: Healthy. The maintainer is engaged.
  • Under two weeks: Acceptable for a hobby project.
  • Months old, no response: Warning. Either overwhelmed, uninterested, or gone.

Also look at closed issues. Are they closed with resolutions, or just "stale — closing" by a bot? 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'll get burned by a breaking change you didn't see coming.

Also look at: is there a CHANGELOG.md? A migration guide for major versions? Both are signs the project thinks about users beyond the primary maintainer.

5. License clarity

Check the LICENSE file. Not every "open source" project is actually open source. Watch for:

  • MIT / Apache-2.0 / BSD-3-Clause: Classical permissive. Low-friction commercial use.
  • AGPL-3.0: Genuinely open source, but has strong copyleft that matters if you're building SaaS on top.
  • GPL-3.0 / GPL-2.0: Copyleft, less aggressive than AGPL.
  • BSL (Business Source License), SSPL, Elastic License v2, "Sustainable Use License": Source-available, not open source. The vendor is signaling they want to control commercial use. Often good products, but don't assume open source guarantees. No guaranteed fork. No guaranteed continued freedom. Redis and Elasticsearch took this path; the OpenSearch and Valkey forks exist precisely because of it.
  • "Fair-code" / "Commons Clause": Same as above. The founders may be wonderful, but you're trusting them, not the license.
  • No license file: Legally closed by default. Usually 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. (I check stars first out of habit, but I try to discount what I see.)

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 just want to read the code. Only meaningful when 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

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 or DECISIONS.md? These don't make a project good, but their absence in a project claiming "community-driven" governance is a tell.

Applying this in practice

Most directory entries here 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 three 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, read more carefully before you commit.

I'll also admit: I get this checklist wrong about 20% of the time. Plausible looked thinner than it was. A federated search project I evaluated in 2023 looked stronger than it was. The framework is a heuristic, not a verdict. The point is to spend ten minutes thinking before you adopt rather than ten months unwinding after.

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.