I’m curious, how do you measure the pulse of a project that old? Do people still talk about it? Or that not even necessary — use it until it breaks and otherwise don’t think about it?

Why do you want your building materials to have a pulse?

Ideally, in adopting dependencies, you should be looking for a mature utility whose design was clear and implementation is complete.

If it's open source, you should be able to read and unserstand the code yourself, and you should make an earnest effort to do so, in case it has faults you wouldn't usually allow in your own code and in case you need to fork it at some point.

This lets you you build well-designed, stable, maintainable, clear things yourself.

The alternate, building your project on a random collection of "living" projects undergoing active development is how you banish yourself to perpetual maintenance, build failures and CVE warnings that have nothing to do with your work, surprise regressions when you update your referenced version (you are, at least, pinning your versions??), etc

If it has an issue tracker, you can look in there for things that look like real issues and are unaddressed.

If there's no issue tracker, you can YOLO and try it and see if it works, or you can look around at the code and see if it looks reasonable.

Even if there are unaddressed issues, you can always use it and fix it when it breaks. If it's reasonable enough, it's a good start anyway. And at least my assumption with open source is I'm going to be fixing it when it breaks, so lack of a pulse is better than churn.

Maybe "pulse" could be transitive? Like, if a project doesn't have many recent commits, but many projects using it have recent commits.