HN Explorer

Ask HN: Evaluating Open Source: Beyond Stars, What Do You Look For?

3 points by keploy ↗ HN
Hey HN community! Recently I've noticed a disconnect between GitHub stars and actual usability in some top-trending(#1) projects—no names, just a pattern I've observed. Stars don't seem sufficient for gauging project quality. For instance, a new project with thousands of stars last week doesn't work for many users(as per issues/community channel).

When you evaluate open-source projects, what metrics matter to you? Do forks (suggesting active use and adaptations), the number of contributors (indicating a healthy development environment), or open issues (reflecting responsiveness and ongoing development) influence your decisions?

Keen to hear which metrics you find most reliable to get into a project.

9 comments

[ 2.8 ms ] story [ 31.6 ms ] thread
talldayo
It depends on what you're evaluating it for. Active contributors is generally the most important metric IMO, but there are a lot of projects that break that rule too.

More often than not I see these questions asked in the context of comparing Open Source solutions to B2B products with integration and continuous support contracts; you cannot really "evaluate" Open Source with expectations that high. Getting things to work well takes elbow-grease, and you can't expect free work to materialize and solve every problem for you. You should go into most of these Open Source projects with the assumption it will take some dedicated research on your part to get it working properly.

slayerjain
> Active contributors is generally the most important metric IMO, but there are a lot of projects that break that rule too.

Just curious, can you please share some OSS projects that break the rule?

pamoroso
Stars, forks, algorithmic rankings, or other popularity metrics are actually the least important things for me. Assuming a project does what I need, what I'm interested in is the availability of good documentation, how understandable the code is, when was the project last updated, and other clues that have little to do with popularity.
slayerjain
For a complex project it can be hard to go through the codebase. I have seen many projects where the development is active and the docs looms good but are quickly become outdated because of low usage.
pamoroso
I'm a hobby programmer with no production requirements, so I often use projects maintained by only one developer who may not be much active if all all. Also, since I program in Lisp, code updated a few years ago may still be good.
keploy
I see the importance of solid documentation and recent updates, but low-star projects often raise concerns about longevity. How do you gauge that?
pamoroso
I addressed this in my reply to slayerjain above. As a hobbyist I don't mind projects that may be infrequently maintained or abandoned.
viraptor
Metrics are silly. Evaluate what you actually care about. Run the software and check if the features you care about when as you expect. Do a trivial implementation in the environment you want. There's no single common indicator that will replace that.

If a project with no stars, no contributions for the last decade and no forks solves the exact use case your have in mind - are you going to skip it?