You said it yourself, this is a very hard problem.
There are Java packages that haven't seen a commit in years and are still perfect for a task. There are npm packages that are 2 months old and terribly outdated and unmaintained.
My personal favorite metric is "time to maintainer response": how long does it take for a maintainer to respond to issues or pull requests. Not necessarily to resolve them, but triage issues or provide guidance on a PR.
If this happens quickly and with reasonable responses, projects are usually solid, assuming they have existed for a while and see decent usage.
Author of Scriptella here. Thank you for mentioning it! The product was neglected for many years, but I never was ready to finally press the kill switch. Hoping that one day I will have more time to work on it...
In this case, the code is still maintained and at least some pull requests are being processed (I haven't checked in detail). The only thing is that there hasn't been an official release for some time.
These are not great metrics. There are no great metrics.
The official JSON implementation is a good example. It is a mature project. It's used everywhere. If you leave an issue or submit a PR that fixes a typo, the maintainer will flat out delete your comment and tell you to buy his book to educate yourself.
Maybe this behavior is good or maybe it's bad. But maintainers are human and metrics are not going to cleanly pick up how well a project is maintained.
There are Java packages that haven't seen a commit in years and are still perfect for a task. There are npm packages that are 2 months old and terribly outdated and unmaintained.
My personal favorite metric is "time to maintainer response": how long does it take for a maintainer to respond to issues or pull requests. Not necessarily to resolve them, but triage issues or provide guidance on a PR.
If this happens quickly and with reasonable responses, projects are usually solid, assuming they have existed for a while and see decent usage.