Even better, a metric for refused PRs (maybe including PR size somehow), tracking where users cared enough to try to contribute and the owner just refused to accept the changes. Easily gamed though.
Think of how much time is wasted because so much software that's been written but not maintained and can't be used because of how libraries have "evolved" since then.
In my experience there are almost always some issues (either legit or misguided support requests,) PRs for docs and features, updates to libraries for vulnerabilities or deprecated code. Worth looking at stuff that isn’t open also. Even if it’s a 10 year old project and the last commit is from 6 months ago fixing a seemingly minor bug, if there more than a few stars or forks, and there aren’t ignored issues and PRs sitting there, I’d consider it trustworthy.
And if it does look abandoned but was active at some point, it’s always a good idea to take a stroll through the forks.
This one is actually archived last year so clearly unmaintained but so far seems to be working great. But no successor fork. I think in this case I will use it, especially because it's in test code and not product.
but if you find a mature/dead project there's a chance it's just old and stable.
what I'm getting at is in an unmantained project any stranger should be able to figure out how to adrees any novel issues. it's the point of open source; I don't undrestand why this is failing. maybe beacuse understanding an anonymous code base is hard work?
It's sometimes possible for a project to have 0 bugs to fix and 0 in-scope improvements (for performance, compatibility, etc.) left to make, but only if its scope is extremely limited. Even Knuth still gets bug reports for his age-old TeX.
If you get many "wtf" moments while doing this, the project is not mature.