Well, it's up to you to interpret the libyears how you like. It doesn't have to be that more libyears is worse, but it will mean that you're missing X libyears of security updates (and also X libyears of potential new bugs).
That really doesn't follow. A barely maintained mess of a personal project running for 10 years is not more mature than a 7 year project heavily developed and released by a high quality team, with 3 years of stability in the main API and in use around the world.
Comments
Well, it's up to you to interpret the libyears how you like. It doesn't have to be that more libyears is worse, but it will mean that you're missing X libyears of security updates (and also X libyears of potential new bugs).
Well, no you can't. Adding them together implicitly affirms that libyears from different dependencies are equivalent.
Yes, that's the point of the metric. The observation that libyear is a dimension, libyears are additive.
If you value some library years more, and some less, then weight the sum.
It's like saying there is no point of natural numbers, because when you count apples, some apples might be rotten.
It's saying you can't add different units together.
Yes it does. And you can say "this project has more libyears, so it's more mature".
That really doesn't follow. A barely maintained mess of a personal project running for 10 years is not more mature than a 7 year project heavily developed and released by a high quality team, with 3 years of stability in the main API and in use around the world.
Are you saying that libyears is a pointless metric? That's what your comment implies.
Broadly, yes.