It’s about the time delta between the used version and the latest available version.
It might be more useful to assign each direct dependency's transitives to it, and then you can do maths to figure out whether updating a direct dependency actually has an effect (e.g. 2 directs both with a 50 lib year dependency aren't worth upgrading unless you upgrade both of them.)
Having a single number that is a rough measure is still useful, though perhaps a (weighted?) average would be more useful.
Anyway, I just downloaded the Python tool (called "libyear" on PyPI) and ran it to quite quickly find three dependencies on my project that were over 2 years behind. That was helpful and I would use it again.
You are the one that has an advantage to know you're behind, not someone else.
No, you can't resort to chicanery to manipulate your metric.
In this case, the libraries you want to use become transitive dependencies, but if your code uses those transitive dependencies, then your project still depends on them.
A metric like this can't keep you honest (just about no matter how you design it, people will find loopholes), but it can help honest people document their needs.
I think the top-line aggregate libyear number is helpful to monitor over time to get a general sense of the slope of your technical debt. If the number is trending upwards then your situation is getting worse and you're increasing the chance you find yourself in an emergency (i.e., a CVE comes out and you're on an unsupported release line and need to go up major versions to take the patch).
Tracking total # of major versions behind gets at the same thing but it's less informative. If you're on v1 of some package that has a v2 but is actively releasing patches for the v1 line that should be a lower priority upgrade than some other package where your v1 line hasn't had a release in 5 years.
A regularly updated 1.x branch for docs/security looks like you're doing fine even though the project is on 3.x and deprecating soon.
Perhaps as a vague guide to point to potential issues, sure.
IE, it discourages someone from sucking in a library just to use one tiny function that they could recreate in 10-15 minutes.
> If your system has a one year old dependency and a three year old dependency, then your whole system is four libyears old.
How far down the tree do we go? Either fully, which means that one project with 365 one day old dependencies is 1 libyear old. Or not at all, as the rails example suggests, in which case if I have a wrapper around rails that I bump to an old rails version, anyone using my wrapper would have older rails but a fewer libyears?
There is no single answer to all of this, because it's too complex to boil down to a single number. But I think it's a bit odd to introduce a whole new thing that doesn't measure at all what's changed.