Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Things like number of stars on a repository, number of forks, number of issues answered, number of followers for an account. All these things are powerful indicators of quality, and like it or not are now part of modern software engineering.

I hate that this is perceived as generally true. Stars can be farmed and gamed; and the value of a star does not decay over time. Issues can be automatically closed, or answered with a non-response and closed. Numbers of followers is a networking/platform thing (flag your significance by following people with significant follower numbers).

> Developers are more likely to use a repo that has more stars than its alternatives.

If anything, star numbers reflect first mover advantage rather than code quality. People choosing which one of a number of competing packages to use in their product should consider a lot more than just the star number. Sadly, time pressures on decision makers (and their assumptions) means that detailed consideration rarely happens and star count remains the major factor in choosing whether to include a repo in a project.



Stars, issues closed, PRs, commits, all are pointless metrics.

The metrics you want are mostly ones they don't and can't have. Number of dependent projects for instance.

The metrics they keep are just what people have said, a way to gameify and keep people interested.


So number of daily/weekly downloads on PyPI/npm/etc?

All these things are a proxy for popularity and that is a valuable metric. I have seen projects with amazing code quality but if they are not maintained eventually they stop working due to updates to dependencies, external APIs, runtime environment, etc. And I have see projects with meh code quality but so popular that every quirk and weird issue had a known workaround. Take ffmpeg for example: its code is.. arcane. But would you choose a random video transcoder written in JavaScript just due to the beautiful code that was last updated in 2012?


It is fine if a dependency hasn't been updated in years, if the number of dependent projects hasn't gone down. Especially if no issues are getting created. Particularly with cargo or npm type package managers where a dependency may do one small thing that never needs to change. Time since last update can be a good thing, it doesn't always mean abandoned.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: