8 ms·

Libyear

228 points by Crier1002 2y ago

bmacho 2y ago
The metric should be called libtime, and measured in pcyear.
newswasboring 2y ago
This is such a good idea. Another one I would like to have is a single number repressing legacy code. I'm not sure exactly what but is there a way to represent the code which people are writing workarounds for.
- yreg 2y ago
  There are tools[0] that show you which users touched which files/modules and how many of those users (if any!) are still in the company. Doesn't necessarily tell you what code is legacy – perhaps a function is just so solid, that there was no reason to touch it in years. But I've found such analysis helpful and it can give you warning signs about what knowledge is being lost in the team and which parts of your own codebase became unknown territory. [0] I know of CodeScene but suppose there are others
amelius 2y ago
Can we also have libloc (metric based on #lines of code)?
- lifthrasiir 2y ago
  Behold, you will see a single-line library soon! (Depends on the language support.)
  - impulsivepuppet 2y ago
    Don't tell the corporate about it, but using charcount/80, excluding newlines and whitespace is the _improved_ pseudoscience. Additionally, excluding 'imports', namespacing, and other boilerplate helps too.
barbegal 2y ago
Can't see this as being particularly useful. Libraries under active development will have larger more frequent releases (but small number of libyears out of date) whereas mature software with only occasional bug fixes may be 10s of libyears out of date.
- stavros 2y ago
  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).
  - edflsafoiewq 2y ago
    Well, no you can't. Adding them together implicitly affirms that libyears from different dependencies are equivalent.
    - stavros 2y ago
      Yes it does. And you can say "this project has more libyears, so it's more mature".
      - IanCal 2y ago
        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.
        stavros 2y ago
        Are you saying that libyears is a pointless metric? That's what your comment implies.
        2y ago
avi_vallarapu 2y ago
I went through this project before. For some applications it might be of great use but for a vast and complex applications architecture, the libyear metric might only oversimplify the complexity of dependency management,compatibility issues, updates and security patches, etc I noticed that it focuses only on the age of dependencies without considering other factors like the how critical is the update, and how stable it is, and the improvements in newer versions, etc.
- Raed667 2y ago
  At a previous company we had this big web-app (filterable) matrix which listed each project dependency, but the neat thing was that you can tag dependencies to add weight and importance. Initially i thought it would need to be more complex, but but it was more than enough.
- liampulles 2y ago
  It's a tradeoff between having a simple and easily quantifiable measure vs a more subjective, more complex and more accurate measure. Libyear seems like a decent starting measure if there is no appetite for something more in-depth, IMO and YMMV.
  - KingMob 2y ago
    > Libyear seems like a decent starting measure if there is no appetite for something more in-depth Maybe, but couldn't measuring, and thus reacting to, a bad measure be worse than doing nothing?
    - verve_rat 2y ago
      Sure, it's almost like you need to exercise judgement when selecting metrics and planning your work.
      - KingMob 2y ago
        Right, but that means it's not a decent starting measure. To me, "decent starting measure if there is no appetite for something more in-depth" sounds like "just drop it in, it's enough to get started, we'll figure out the rest later", but that could be temporarily harmful. Exercising judgment is the opposite of that, no? Then you're going into depth.
nikolayasdf123 2y ago
nice metric!
School-Cotton 2y ago
The linked website does not explain what a libyear is. It gives two examples: > Rails 5.0.0 (June 2016) is 1 libyear behind 5.1.2 (June 2017). and > If your system has a one year old dependency and a three year old dependency, then your whole system is four libyears old. which don't explain much. I suspect what they meant to say is that Rails 5.0.0 (June 2016) is 1 year (not libyear) behind 5.1.2 (June 2017) and that the "libyear age" of a project is the sum of how old each of its dependencies is. But if so, they should say so clearly somewhere on their page.
- eternityforest 2y ago
  I guessed the same thing but didn't even notice it was unclear, I just assumed my guess was probably right ... The concept really does seem obvious, especially since it sounds like man year, but it needs better documentation.
  - School-Cotton 2y ago
    What confused me was saying that some version of Rails is some number of libyears behind some other version, when in order to know that you'd need to expect the dependencies of Rails itself...
andyjohnson0 2y ago
It's nice to have a name for this, and for it to be quantifiable. I could see this on some kind of product dashboard - maybe automatically generated. But, while I appreciate the need for simplicity, I also wonder if it would be wise to scale dependencies by how prevalent they are in the codebase. For example, if I'm using a five year old version of react but the library I use to convert temperature units is up-to-date, then thats bad. But if I'm using the latest react and the conversion lib is old then thats less bad. Probably feature creep though...
- semanser 2y ago
  The features that you described are somewhat close to what I'm trying to build with depshub.com. Dependency visibility is still a major problem in any engineering team that cares about dependencies, and it's often very hard to say if a project is moving in the right direction in terms of updates. Some teams just completely ignore the fact that they need to update dependencies, but this usually comes with the consequence of "updating ASAP because we need X feature or Y bugfix." All the major tools (dependabot, renovate) to keep dependencies up to date treat all the dependencies equally when in reality there are always core libraries (e.g., react) and everything else. While trying to keep *everything* up to date is extremely challenging, what I'm trying to do is to find a balance between what and when needs to be updated (using code static analysis, different data sources, AI etc) and automate it in a simple manner.
thriftwy 2y ago
So, how many libyears were that xz dependency out of date? Libyears are meaningless. A library either has known vulnerabilities or it doesn't. When it doesn't, old is often better than new one.
_xivi 2y ago
Related discussion: Libyear – a simple measure of software dependency freshness - https://news.ycombinator.com/item?id=24975339 https://news.ycombinator.com/item?id=24975339 - Nov 2020 (16 comments)
agilob 2y ago
libyear assumes that constant development happens all the time in a library and software has to change and grow constantly. There are some libraries that are just mature and doesn't need to change. 5.0.1 could be released 5 years ago, and 5.0.1 today with just changes to docs. It doesn't mean that it took 5 libyears to develop and release the new version. This is the type of thinking that attackers used in xz trying to pressure original author to add more official maintainers, because he wasn't merging and updating code fast enough. "You're not merging and releasing our code fast enough, therefore you're doing bad job". What would be other measures that could be similarly useful? Lines of code or story points? Maybe even a number of tests added?
- quassy 2y ago
  That is an argument for libyears, not against it. If they only updated the docs, why didn't you upgrade already? If anything, projects using stable libraries like this could very easily reach 0 libyears, because there are no breaking changes when upgrading.
  - agilob 2y ago
    It's for and against at the same time. Depends on your software upgrade roadmap. I think that's just a silly number, that us correct and incorrect at the same time, but probably good enough on a large scale, just like story points.
jamietanna 2y ago
It's worth also reading https://chaoss.community/kb/metric-libyears/ https://chaoss.community/kb/metric-libyears/ - as noted elsewhere, regularly updating libraries, or a library that infrequently pushes out large breaking changes will not reflect as easily in Libyear, but it's worth having it as something to gauge out-of-date-ness I've been using that alongside some other metrics for providing insights into how behind teams are on updates
- semanser 2y ago
  > I've been using that alongside some other metrics for providing insights into how behind teams are on updates What are some other metrics that you are using? I am working on a product that is helping to keep dependencies up to date and would love to integrate some of these things in the product.
tomaszsobota 2y ago
I agree with other comments that it's not a perfect measure but it's a solid step in the right direction from having no metrics at all. The libs we're measuring up to could have their own libyears to upgrade, but we can only control what's in our hands. Sometimes a small security patch is worth more than a major version bump of features, so I consider measuring the time instead of major versions a benefit.
- prmoustache 2y ago
  I guess that having to rely on metrics to begin with means the battle is lost and your have no control on the code you are using. Maybe we should stop boilerplating everything and write the actual code we need. For the most part softwares usually use a tiny fraction of capabilities of any given library. Maybe before trying to limit our lag in dependencies update of unlimited levels of libraries we should focus first on having a maximum level of dependencies. Like one project would use a maximum of 2 level of libraries dependencies and you would have to rewrite those that have too many levels. The javascript ecosystem for instance is totally unmanageable as I see it. We just pretend we have a bit of control but in reality nobody knows what code is executed really and this is sad.
  - tomaszsobota 2y ago
    That is better, I agree. I'd take a lean set of dependencies any day, but it becomes increasingly more difficult the more velocity the project gets. Suddenly less and less is considered core and it's easier than ever to 'outsource' to external libs to save time. Or is it rather that the project gets more velocity because of that? > We just pretend we have a bit of control but in reality nobody knows what code is executed really and this is sad. True, this is also slowly starting to be the case with other languages. With Python it can be so bad that even attempting to 'build' and run the same project a year later may well fail. Much to what I'm used to with JavaScript projects by now.
impulsivepuppet 2y ago
As a worthless junior dev, thank you for the post. I am seeing a general sentiment of reluctancy towards an introduction of yet another dubious metric in an environment where "software quality" is hijacked to mean something else. This lead me questioning how good is it to judge a project by its age + last commit (+ project size/complexity + funding/community), as this is what I do in practice. I agree that SemVer isn't really designed to be human-readable and is a rather meaningless / deceiving metric due to divergent practices of different developers.
cess11 2y ago
Matters a lot what kind of applications the library is for. Being a couple of years behind in mobile application development usually means you have to spend a week piecing together a development environment to get the crap to build so you can start the library upgrading process. A couple of years hither or dither with grey-haired Java libraries matters very little. There might be some vulnerabilities but you probably know about them and have workarounds, and sometime next year it's likely you'll be allowed a month or two to do 'life cycle management' in the dependency stack.
semanser 2y ago
As a person who works on automated dependency updates (depshub.com), the libyear indicator is often not very useful. There are several other indicators to consider, such as release frequency, update type (major/minor/patch), the dependency's criticality for your project, etc. Instead of solely focusing on reducing the libyear for your projects, a better approach is to minimize the steps needed to keep your project reasonably up to date. For instance, think about managing 20 PRs weekly to update various package.json packages versus 1 PR for critical dependencies when necessary. It's important to note that updating dependencies is not a consistent task that can be done at the same pace all the time. Expect varying update volumes and complexities that may need attention at different times. Setting a fixed configuration for, let's say, 10 updates per week may not be effective, as it could lead to dealing with unnecessary updates regularly (e.g., aws-cli, which has almost daily releases). Finding the right balance between keeping your project up to date and spending too much time on dealing with dependencies is the hardest part here that doesn't have a 100% right answer yet.
- mikepurvis 2y ago
  I've been doing this work for a while and been pushing my org to move from updating the "base layer" every 2-4 years (Ubuntu LTS versions) down to every six months (each NixOS release). I think one thing I've increasingly found is that it's important to set up the infrastructure for parallel building— it's not realistic to have a flag day twice a year, and it's not realistic to try to test everything first "on a branch". If you can have a transitional period of a few weeks where the product outputs (containers, dev environments, whatever) are consistently available in both the old and new flavour, then you can invite people to try the updated thing, while still having an escape lane to keep using the older thing if stuff turns out to be broken in a way that's beyond their capacity to correct in the moment.
- Crier1002 2y ago
  I'm interested in knowing more about how companies typically gauge the freshness of their codebase dependencies. putting all the nuances/details aside, i think we can all agree that having a codebase with most dependencies that are over 8 years old is a pretty clear indication that it's way overdue for an update, right? i was thinking, would it be helpful to keep track of how far behind each dependency is in terms of minor, patch, and major updates? but this seems a bit too complex to explain to the management. i'm trying to figure out the best way to explain this to management so they understand why it's important to stay current. any ideas on how we can measure improvements? maybe we should agree on a few key factors to track our progress and see if we're getting better or worse.
betimsl 2y ago
Super idea :)
BoppreH 2y ago
The explanation could be better, but I really like the idea. It punishes you for not updating your dependencies and for having too many direct dependencies. But it doesn't punish you for indirect dependencies (that you have little control of), or libraries that are "done" (since it compares to the newest stable release, not the current year). A sensible balance. Maybe one could write a browser extension to display the libyear of GitHub pages?
IanCal 2y ago
Isn't "we are 5 major releases behind" more obvious that "two libyears". > 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.
- d-k-bo 2y ago
  I think it only counts direct dependencies.
  - falcor84 2y ago
    So that means that the way to game this would be to create a wrapper project (e.g. called "external_deps") for all of my dependencies, and then have my actual project depend on that one. So I'm externalizing all of my tech debt onto external_deps and as long as I never make a new release of that, my main project will always be 0 libyears old.
    - riffraff 2y ago
      Even if you could, why would you? It'd be the same to, say, fork a projectX to myprojectX and say you're at the latest version. You are the one that has an advantage to know you're behind, not someone else.
    - PokestarFan 2y ago
      Look up Goodhart's Law.
    - alanbernstein 2y ago
      Wouldn't it be easier to "game" the tool by just not using it?
xpe 2y ago
While granting that libyear is clear in what is measures, I still think it measures the wrong thing. What should we be measuring? I have some ideas for my projects, but I don't have the answer for your project. Semantic versioning ain't the only game in town for sure, and I'm not anchoring on it as the best or only way. But I will say this: when one has figured out what is important to measure, build metrics for that. You almost certainly will need to factor in supply chain security. And probably some metrics for recency about the hardware platforms you deploy to. This could look like a weighted score, perhaps. But it is unreasonable to hope that libyear or semver to do that for you.
baq 2y ago
One step away from rediscovering voltime. Time flows faster in periods of high volatility and slower in periods of low volatility. Instead of measuring time directly it should be adjusted by things like changes committed, LOC added/removed, CVEs opened/closed, etc.
derrida 2y ago
If you're using libraries from 10 years ago, maybe it's because you used good tools.
noobermin 2y ago
This is a fantastic way to encourage churn and ensure developer job longevity.
lrvick 2y ago
Just remember that blindly updating dependencies that no one trustworthy has reviewed is opening yourself up to supply chain attacks. Blindly upgrading is worse than never upgrading unless you are addressing a specific CVE that impacts you. Public open source code is code you did not have to write which can be a time saver, but you do not get to skip code review. If you do not have time to review 2000 dependencies, then you should drop them favoring simple functions that only do what you need.
- Culonavirus 2y ago
  [flagged]
  - lrvick 2y ago
    Shameless plug: If your team really wants more dependencies than they have the capacity to review, my team and I are happy to help greatly reduce this risk. My company (https://distrust.co https://distrust.co) has reviewed hundreds of dependencies on behalf of our clients, and some even pay for this as a monthly retainer service. JS dependency debt is good for my business.
    - playingalong 2y ago
      What guarantees do you offer?
      - lrvick 2y ago
        We are not an cyber insurance firm, so we don't offer any guarantees or compensation if you get compromised. We operate the same as any security auditing firm. One of our clients reviews all their dependencies in-house with their own team and has us be the second pass for extra assurance. They have also tested our team in the past by not revealing vulnerabilities they have already identified to be sure we are indeed reviewing the way we say we do. Security bugs are everywhere because very few internet rando library authors have infosec experinece, so you are unlikely to get a clean report on any given dependency tree, but /usually/ the items are low to medium risk and can be chased upstream or easily patched out. Sometimes however we find really problematic ones like CVE-2018-9057 that impact you if you have ever used it even once ever. Also there is an economy of scale here in that if one of our other clients asked for review of a react dependency last week, we can copy over our opinion and consume fewer hours on the clock.
api 2y ago
This assumes that code that just works incredibly well and hasn’t needed an update in years is inferior to frothy untested code or broken code constantly requiring bug fix PRs.
amiga386 2y ago
Don't make me wave the Diffusion of Innovations chart at you all: https://en.wikipedia.org/wiki/Diffusion_of_innovations https://en.wikipedia.org/wiki/Diffusion_of_innovations libyear is an opinionated metric that prioritises less well tested software. Meanwhile, companies pay a lot of money for RHEL and other products that promise a stable environment that freezes specific (major) releases of software for years - and also promises backports of any necessary security fixes, without those pesky new features and breaking changes that come with using bleeding-edge releases. Different people, projects, organisations, all have different risk appetites. We need all of them working together; late adopters wouldn't have the stability they crave if early adopters didn't exist to test the crazy broken fresh software. While everyone needs to manage dependencies, there's no one right way to do it, so everyone does it their own way. They only thing we can probably agree on is doing _no_ maintenance on dependencies is a bad thing.
- semanser 2y ago
  Without those pesky new features and breaking changes that come with using bleeding-edge releases. This is usually a popular counterargument when people are talking about keeping everything up to date. What people should consider though is to try to keep everything *relatively* up to date, without always being on the latest version but still not very far away from the latest release. GitHub, Stack Overflow, etc., are full of data about potential issues when updating to library X to version Y, and usually, you're able to find this when it's too late - either you've got an error in production or you're in the middle of an update and you discover that there are some issues with the version that you want to use. Exploring these data points is still a pretty much untapped area, and this is something that I'm trying to explore with my product that updates dependencies automatically in a more "smarter" and autonomous way at depshub.com. I would be happy to see more people working in this area since it's clear that there is a problem that needs to be solved and unfortunately the current status quo is "while everyone needs to manage dependencies, there's no one right way to do it, so everyone does it their own way."
gamegod 2y ago
[flagged]
deleted 2y ago
[deleted]
nrvn 2y ago
This is a hugely misleading indicator to rely on. Not only it sums up all the time behind in dependencies which is more than confusing to start with but it also leaves the end user puzzle what to do with this information. Let's assume my software project is 120 "libyears" behind. What's next? What risks am I exposed to? What should I do? Think of a notorious python2 vs. python3. I am in 2019 and my software project has it as a dependency. My team has assessed that migration to v.3 will require another year of dealing with all the breaking changes. And while brainstorming we are thinking from the risk and cost-benefit perspective. Time per se is relevant only in the context of effort required to perform the migration. From the supply chain security standpoint I could not care less about time as well. If I am using library X of version 1.2.3 and it ticks all the boxes, has no performance impact, has 0 problems, 0 vulnerabilities (including the results from public, third party and internal code audits) I will continue using it even if version 2 is out, especially if it requires reassessment of risks and some code refactoring due to breaking API changes. If I want to automate my dependency management I will rely on tools that will tell me about my risks or potential missed benefits from the newer versions. Time will be taken into account only in terms of time needed for mitigating the risks directly impacting my piece of software.
- semanser 2y ago
  > If I am using library X of version 1.2.3 and it ticks all the boxes, has no performance impact, has 0 problems, 0 vulnerabilities (including the results from public, third party and internal code audits) I will continue using it even if version 2 is out, especially if it requires reassessment of risks and some code refactoring due to breaking API changes. What happens if the library that you're using is completely fine on its own (think React 18) but it's a core cross-dependency for tons of other libraries in your project. No libraries or frameworks should be considered in isolation. Otherwise, it can lead to a situation where you can't use some of the other tools/libraries, etc., because of the other dependency that is quite out of date.
thraxil 2y ago
They've succeeded in creating a single metric that's easy to calculate, but IMHO, it fails to be very useful for common use cases. Basically, it just uses the difference between the date the library version you are using was released and the current date if there's a newer release available. Eg, if you are using a library that has been unchanged at 1.0.0 for the last 10 years, you'll be 0 libyears behind that whole time. Then one day, the developers of that library release 1.0.1. One minute after that hits the package repositories, you are immediately 10 libyears behind. This makes it pretty useless as a metric for tracking how outdated an application really is. Eg, as an ops/SRE/security person, I'd want to be able to run this on a product team's code and have a single number that tells me whether they're reasonably up to date or seem to be ignoring their dependencies and letting technical debt pile up. A team could've been on the ball, keeping every dependency updated daily for years, but if I use libyear to evaluate them right after that that 10 year old dependency updates, it's going to look like they've been negligent. I have an open issue on the Python implementation (which ironically(?) hasn't had any commits in three years) asking for clarification: https://github.com/nasirhjafri/libyear/issues/35 https://github.com/nasirhjafri/libyear/issues/35
- semanser 2y ago
  I'm the developer of depshub.com (for automated dependency updates using AI) and even though a single metric isn't valuable, having any sort of indicators and metrics is very useful when you have more than one repository. Being able to quickly see if your repositories are getting better or worse over time helps to understand when the dependency updates should be prioritized (if so) in the first place. There are a few core metrics that I've built (major vs minor vs patch ratio, security updates, etc.) into the product, and it's one of the most used features up to date.
jlg23 2y ago
A great metric for job security, not necessarily for better software: Unless it concerns security or correctness, I prefer an old but audited version of a library anytime over a newer version that I have to audit again. A metric like this will be loved by PMs and loathed by developers who have to leave a known, sane state, update and deal with the fallout later on.
thih9 2y ago
I propose a different metric, version points: subtract version number of the currently used library from the version number of the latest version. Translate to semver first if possible. Also, a release addressing a CVE adds extra ten million points.
gwbas1c 2y ago
What's nice about the "libyear" concept is that it exposes the cost of indiscriminately pulling in 3rd party libraries. For example, I recently went through a project to bring 3rd party dependencies up-to-date. I noticed that we were using a very old mathematics and statistics library. On closer inspection, we were only using one function from the library to calculate the mode of a list of numbers. Looking at the library's source code, it was about 50 lines. Now, a decent programmer can recreate such a function in 1-3 hours, including a unit test. This is what we did instead of including the dependency. A naive programmer might think that sucking in the 3rd party library "saves" 1-3 hours, but that's not the case: Every few years someone will audit the libraries we're using as part of a security audit, or a legal audit to make sure that we're in compliance with open-source libraries. The stats library will incur a 1-2 hour cost in each audit. Furthermore, every 1-4 years we'll need to update the library, because changes in the programming language, runtime, OS, ect, mean we'll need at minimum a recompile or similar tweak to take advantage of some new language feature or constraint. The 3rd party dependency could add 1-4 hours to such a project. Thus, because libyear shows an increasing cost associated with the library, it's easier to explain why it's better to spend 1-3 hours writing a simple function (and unit test) than to bring in a 3rd party library to do the same thing.
sudo_bang_bang 2y ago
Very rarely do I so vehemently disagree with a particular argument in software. This idea epitomizes much of what is wrong in the industry. We can all agree security updates are essential, but a lot of libraries are “done” from a functional perspective for a majority of their existing use cases. Yes updates can be needed because interfaces break between other programs, standards evolve in backward incompatible ways, performance improvements can be made, etc. But much of the updates I see are changes for the sake of changes. You could use a 5 year old version of React for example, and modulo some set of security fixes if any, you could have a robust application. Sometimes software is just done. We are better off for accepting that idea. Get us off the update hamster wheel and stop the enshittification.
pomoke 2y ago
[dead]
captn3m0 2y ago
I’ve been wanting to make a similar indicator for the work I do at endoflife.date. IMO, a realistic upgradability metric would be linked to the “hardness of the upgrade to a supported version”, which is much harder to answer and quite contextual in how you are running each dependency. But libyear is a good metric to have as prior art in the field.
atgreen 2y ago
I just added libyear support to ocicl for Common Lisp.

228 points by Crier1002 2y ago

The metric should be called libtime, and measured in pcyear.

This is such a good idea. Another one I would like to have is a single number repressing legacy code. I'm not sure exactly what but is there a way to represent the code which people are writing workarounds for.

yreg 2y ago
There are tools[0] that show you which users touched which files/modules and how many of those users (if any!) are still in the company. Doesn't necessarily tell you what code is legacy – perhaps a function is just so solid, that there was no reason to touch it in years. But I've found such analysis helpful and it can give you warning signs about what knowledge is being lost in the team and which parts of your own codebase became unknown territory. [0] I know of CodeScene but suppose there are others

amelius 2y ago

Can we also have libloc (metric based on #lines of code)?

lifthrasiir 2y ago
Behold, you will see a single-line library soon! (Depends on the language support.)
- impulsivepuppet 2y ago
  Don't tell the corporate about it, but using charcount/80, excluding newlines and whitespace is the _improved_ pseudoscience. Additionally, excluding 'imports', namespacing, and other boilerplate helps too.

barbegal 2y ago

Can't see this as being particularly useful. Libraries under active development will have larger more frequent releases (but small number of libyears out of date) whereas mature software with only occasional bug fixes may be 10s of libyears out of date.

stavros 2y ago
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).
- edflsafoiewq 2y ago
  Well, no you can't. Adding them together implicitly affirms that libyears from different dependencies are equivalent.
  - stavros 2y ago
    Yes it does. And you can say "this project has more libyears, so it's more mature".
    - IanCal 2y ago
      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.
      - stavros 2y ago
        Are you saying that libyears is a pointless metric? That's what your comment implies.
        2y ago

avi_vallarapu 2y ago

I went through this project before. For some applications it might be of great use but for a vast and complex applications architecture, the libyear metric might only oversimplify the complexity of dependency management,compatibility issues, updates and security patches, etc I noticed that it focuses only on the age of dependencies without considering other factors like the how critical is the update, and how stable it is, and the improvements in newer versions, etc.

Raed667 2y ago
At a previous company we had this big web-app (filterable) matrix which listed each project dependency, but the neat thing was that you can tag dependencies to add weight and importance. Initially i thought it would need to be more complex, but but it was more than enough.
liampulles 2y ago
It's a tradeoff between having a simple and easily quantifiable measure vs a more subjective, more complex and more accurate measure. Libyear seems like a decent starting measure if there is no appetite for something more in-depth, IMO and YMMV.
- KingMob 2y ago
  > Libyear seems like a decent starting measure if there is no appetite for something more in-depth Maybe, but couldn't measuring, and thus reacting to, a bad measure be worse than doing nothing?
  - verve_rat 2y ago
    Sure, it's almost like you need to exercise judgement when selecting metrics and planning your work.
    - KingMob 2y ago
      Right, but that means it's not a decent starting measure. To me, "decent starting measure if there is no appetite for something more in-depth" sounds like "just drop it in, it's enough to get started, we'll figure out the rest later", but that could be temporarily harmful. Exercising judgment is the opposite of that, no? Then you're going into depth.

nikolayasdf123 2y ago

nice metric!

School-Cotton 2y ago

The linked website does not explain what a libyear is. It gives two examples: > Rails 5.0.0 (June 2016) is 1 libyear behind 5.1.2 (June 2017). and > If your system has a one year old dependency and a three year old dependency, then your whole system is four libyears old. which don't explain much. I suspect what they meant to say is that Rails 5.0.0 (June 2016) is 1 year (not libyear) behind 5.1.2 (June 2017) and that the "libyear age" of a project is the sum of how old each of its dependencies is. But if so, they should say so clearly somewhere on their page.

eternityforest 2y ago
I guessed the same thing but didn't even notice it was unclear, I just assumed my guess was probably right ... The concept really does seem obvious, especially since it sounds like man year, but it needs better documentation.
- School-Cotton 2y ago
  What confused me was saying that some version of Rails is some number of libyears behind some other version, when in order to know that you'd need to expect the dependencies of Rails itself...

andyjohnson0 2y ago

It's nice to have a name for this, and for it to be quantifiable. I could see this on some kind of product dashboard - maybe automatically generated. But, while I appreciate the need for simplicity, I also wonder if it would be wise to scale dependencies by how prevalent they are in the codebase. For example, if I'm using a five year old version of react but the library I use to convert temperature units is up-to-date, then thats bad. But if I'm using the latest react and the conversion lib is old then thats less bad. Probably feature creep though...

semanser 2y ago
The features that you described are somewhat close to what I'm trying to build with depshub.com. Dependency visibility is still a major problem in any engineering team that cares about dependencies, and it's often very hard to say if a project is moving in the right direction in terms of updates. Some teams just completely ignore the fact that they need to update dependencies, but this usually comes with the consequence of "updating ASAP because we need X feature or Y bugfix." All the major tools (dependabot, renovate) to keep dependencies up to date treat all the dependencies equally when in reality there are always core libraries (e.g., react) and everything else. While trying to keep *everything* up to date is extremely challenging, what I'm trying to do is to find a balance between what and when needs to be updated (using code static analysis, different data sources, AI etc) and automate it in a simple manner.

thriftwy 2y ago

So, how many libyears were that xz dependency out of date? Libyears are meaningless. A library either has known vulnerabilities or it doesn't. When it doesn't, old is often better than new one.

_xivi 2y ago

Related discussion: Libyear – a simple measure of software dependency freshness - https://news.ycombinator.com/item?id=24975339 https://news.ycombinator.com/item?id=24975339 - Nov 2020 (16 comments)

agilob 2y ago

libyear assumes that constant development happens all the time in a library and software has to change and grow constantly. There are some libraries that are just mature and doesn't need to change. 5.0.1 could be released 5 years ago, and 5.0.1 today with just changes to docs. It doesn't mean that it took 5 libyears to develop and release the new version. This is the type of thinking that attackers used in xz trying to pressure original author to add more official maintainers, because he wasn't merging and updating code fast enough. "You're not merging and releasing our code fast enough, therefore you're doing bad job". What would be other measures that could be similarly useful? Lines of code or story points? Maybe even a number of tests added?

quassy 2y ago
That is an argument for libyears, not against it. If they only updated the docs, why didn't you upgrade already? If anything, projects using stable libraries like this could very easily reach 0 libyears, because there are no breaking changes when upgrading.
- agilob 2y ago
  It's for and against at the same time. Depends on your software upgrade roadmap. I think that's just a silly number, that us correct and incorrect at the same time, but probably good enough on a large scale, just like story points.

jamietanna 2y ago

It's worth also reading https://chaoss.community/kb/metric-libyears/ https://chaoss.community/kb/metric-libyears/ - as noted elsewhere, regularly updating libraries, or a library that infrequently pushes out large breaking changes will not reflect as easily in Libyear, but it's worth having it as something to gauge out-of-date-ness I've been using that alongside some other metrics for providing insights into how behind teams are on updates

semanser 2y ago
> I've been using that alongside some other metrics for providing insights into how behind teams are on updates What are some other metrics that you are using? I am working on a product that is helping to keep dependencies up to date and would love to integrate some of these things in the product.

tomaszsobota 2y ago

I agree with other comments that it's not a perfect measure but it's a solid step in the right direction from having no metrics at all. The libs we're measuring up to could have their own libyears to upgrade, but we can only control what's in our hands. Sometimes a small security patch is worth more than a major version bump of features, so I consider measuring the time instead of major versions a benefit.

prmoustache 2y ago
I guess that having to rely on metrics to begin with means the battle is lost and your have no control on the code you are using. Maybe we should stop boilerplating everything and write the actual code we need. For the most part softwares usually use a tiny fraction of capabilities of any given library. Maybe before trying to limit our lag in dependencies update of unlimited levels of libraries we should focus first on having a maximum level of dependencies. Like one project would use a maximum of 2 level of libraries dependencies and you would have to rewrite those that have too many levels. The javascript ecosystem for instance is totally unmanageable as I see it. We just pretend we have a bit of control but in reality nobody knows what code is executed really and this is sad.
- tomaszsobota 2y ago
  That is better, I agree. I'd take a lean set of dependencies any day, but it becomes increasingly more difficult the more velocity the project gets. Suddenly less and less is considered core and it's easier than ever to 'outsource' to external libs to save time. Or is it rather that the project gets more velocity because of that? > We just pretend we have a bit of control but in reality nobody knows what code is executed really and this is sad. True, this is also slowly starting to be the case with other languages. With Python it can be so bad that even attempting to 'build' and run the same project a year later may well fail. Much to what I'm used to with JavaScript projects by now.

impulsivepuppet 2y ago

As a worthless junior dev, thank you for the post. I am seeing a general sentiment of reluctancy towards an introduction of yet another dubious metric in an environment where "software quality" is hijacked to mean something else. This lead me questioning how good is it to judge a project by its age + last commit (+ project size/complexity + funding/community), as this is what I do in practice. I agree that SemVer isn't really designed to be human-readable and is a rather meaningless / deceiving metric due to divergent practices of different developers.

cess11 2y ago

Matters a lot what kind of applications the library is for. Being a couple of years behind in mobile application development usually means you have to spend a week piecing together a development environment to get the crap to build so you can start the library upgrading process. A couple of years hither or dither with grey-haired Java libraries matters very little. There might be some vulnerabilities but you probably know about them and have workarounds, and sometime next year it's likely you'll be allowed a month or two to do 'life cycle management' in the dependency stack.

semanser 2y ago

As a person who works on automated dependency updates (depshub.com), the libyear indicator is often not very useful. There are several other indicators to consider, such as release frequency, update type (major/minor/patch), the dependency's criticality for your project, etc. Instead of solely focusing on reducing the libyear for your projects, a better approach is to minimize the steps needed to keep your project reasonably up to date. For instance, think about managing 20 PRs weekly to update various package.json packages versus 1 PR for critical dependencies when necessary. It's important to note that updating dependencies is not a consistent task that can be done at the same pace all the time. Expect varying update volumes and complexities that may need attention at different times. Setting a fixed configuration for, let's say, 10 updates per week may not be effective, as it could lead to dealing with unnecessary updates regularly (e.g., aws-cli, which has almost daily releases). Finding the right balance between keeping your project up to date and spending too much time on dealing with dependencies is the hardest part here that doesn't have a 100% right answer yet.

mikepurvis 2y ago
I've been doing this work for a while and been pushing my org to move from updating the "base layer" every 2-4 years (Ubuntu LTS versions) down to every six months (each NixOS release). I think one thing I've increasingly found is that it's important to set up the infrastructure for parallel building— it's not realistic to have a flag day twice a year, and it's not realistic to try to test everything first "on a branch". If you can have a transitional period of a few weeks where the product outputs (containers, dev environments, whatever) are consistently available in both the old and new flavour, then you can invite people to try the updated thing, while still having an escape lane to keep using the older thing if stuff turns out to be broken in a way that's beyond their capacity to correct in the moment.
Crier1002 2y ago
I'm interested in knowing more about how companies typically gauge the freshness of their codebase dependencies. putting all the nuances/details aside, i think we can all agree that having a codebase with most dependencies that are over 8 years old is a pretty clear indication that it's way overdue for an update, right? i was thinking, would it be helpful to keep track of how far behind each dependency is in terms of minor, patch, and major updates? but this seems a bit too complex to explain to the management. i'm trying to figure out the best way to explain this to management so they understand why it's important to stay current. any ideas on how we can measure improvements? maybe we should agree on a few key factors to track our progress and see if we're getting better or worse.

betimsl 2y ago

Super idea :)

BoppreH 2y ago

The explanation could be better, but I really like the idea. It punishes you for not updating your dependencies and for having too many direct dependencies. But it doesn't punish you for indirect dependencies (that you have little control of), or libraries that are "done" (since it compares to the newest stable release, not the current year). A sensible balance. Maybe one could write a browser extension to display the libyear of GitHub pages?

IanCal 2y ago

Isn't "we are 5 major releases behind" more obvious that "two libyears". > 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.

d-k-bo 2y ago
I think it only counts direct dependencies.
- falcor84 2y ago
  So that means that the way to game this would be to create a wrapper project (e.g. called "external_deps") for all of my dependencies, and then have my actual project depend on that one. So I'm externalizing all of my tech debt onto external_deps and as long as I never make a new release of that, my main project will always be 0 libyears old.
  - riffraff 2y ago
    Even if you could, why would you? It'd be the same to, say, fork a projectX to myprojectX and say you're at the latest version. You are the one that has an advantage to know you're behind, not someone else.
  - PokestarFan 2y ago
    Look up Goodhart's Law.
  - alanbernstein 2y ago
    Wouldn't it be easier to "game" the tool by just not using it?

xpe 2y ago

While granting that libyear is clear in what is measures, I still think it measures the wrong thing. What should we be measuring? I have some ideas for my projects, but I don't have the answer for your project. Semantic versioning ain't the only game in town for sure, and I'm not anchoring on it as the best or only way. But I will say this: when one has figured out what is important to measure, build metrics for that. You almost certainly will need to factor in supply chain security. And probably some metrics for recency about the hardware platforms you deploy to. This could look like a weighted score, perhaps. But it is unreasonable to hope that libyear or semver to do that for you.

baq 2y ago

One step away from rediscovering voltime. Time flows faster in periods of high volatility and slower in periods of low volatility. Instead of measuring time directly it should be adjusted by things like changes committed, LOC added/removed, CVEs opened/closed, etc.

derrida 2y ago

If you're using libraries from 10 years ago, maybe it's because you used good tools.

noobermin 2y ago

This is a fantastic way to encourage churn and ensure developer job longevity.

lrvick 2y ago

Just remember that blindly updating dependencies that no one trustworthy has reviewed is opening yourself up to supply chain attacks. Blindly upgrading is worse than never upgrading unless you are addressing a specific CVE that impacts you. Public open source code is code you did not have to write which can be a time saver, but you do not get to skip code review. If you do not have time to review 2000 dependencies, then you should drop them favoring simple functions that only do what you need.

Culonavirus 2y ago
[flagged]
- lrvick 2y ago
  Shameless plug: If your team really wants more dependencies than they have the capacity to review, my team and I are happy to help greatly reduce this risk. My company (https://distrust.co https://distrust.co) has reviewed hundreds of dependencies on behalf of our clients, and some even pay for this as a monthly retainer service. JS dependency debt is good for my business.
  - playingalong 2y ago
    What guarantees do you offer?
    - lrvick 2y ago
      We are not an cyber insurance firm, so we don't offer any guarantees or compensation if you get compromised. We operate the same as any security auditing firm. One of our clients reviews all their dependencies in-house with their own team and has us be the second pass for extra assurance. They have also tested our team in the past by not revealing vulnerabilities they have already identified to be sure we are indeed reviewing the way we say we do. Security bugs are everywhere because very few internet rando library authors have infosec experinece, so you are unlikely to get a clean report on any given dependency tree, but /usually/ the items are low to medium risk and can be chased upstream or easily patched out. Sometimes however we find really problematic ones like CVE-2018-9057 that impact you if you have ever used it even once ever. Also there is an economy of scale here in that if one of our other clients asked for review of a react dependency last week, we can copy over our opinion and consume fewer hours on the clock.

api 2y ago

This assumes that code that just works incredibly well and hasn’t needed an update in years is inferior to frothy untested code or broken code constantly requiring bug fix PRs.

amiga386 2y ago

Don't make me wave the Diffusion of Innovations chart at you all: https://en.wikipedia.org/wiki/Diffusion_of_innovations https://en.wikipedia.org/wiki/Diffusion_of_innovations libyear is an opinionated metric that prioritises less well tested software. Meanwhile, companies pay a lot of money for RHEL and other products that promise a stable environment that freezes specific (major) releases of software for years - and also promises backports of any necessary security fixes, without those pesky new features and breaking changes that come with using bleeding-edge releases. Different people, projects, organisations, all have different risk appetites. We need all of them working together; late adopters wouldn't have the stability they crave if early adopters didn't exist to test the crazy broken fresh software. While everyone needs to manage dependencies, there's no one right way to do it, so everyone does it their own way. They only thing we can probably agree on is doing _no_ maintenance on dependencies is a bad thing.

semanser 2y ago
Without those pesky new features and breaking changes that come with using bleeding-edge releases. This is usually a popular counterargument when people are talking about keeping everything up to date. What people should consider though is to try to keep everything *relatively* up to date, without always being on the latest version but still not very far away from the latest release. GitHub, Stack Overflow, etc., are full of data about potential issues when updating to library X to version Y, and usually, you're able to find this when it's too late - either you've got an error in production or you're in the middle of an update and you discover that there are some issues with the version that you want to use. Exploring these data points is still a pretty much untapped area, and this is something that I'm trying to explore with my product that updates dependencies automatically in a more "smarter" and autonomous way at depshub.com. I would be happy to see more people working in this area since it's clear that there is a problem that needs to be solved and unfortunately the current status quo is "while everyone needs to manage dependencies, there's no one right way to do it, so everyone does it their own way."

gamegod 2y ago

[flagged]

deleted 2y ago

[deleted]

nrvn 2y ago

This is a hugely misleading indicator to rely on. Not only it sums up all the time behind in dependencies which is more than confusing to start with but it also leaves the end user puzzle what to do with this information. Let's assume my software project is 120 "libyears" behind. What's next? What risks am I exposed to? What should I do? Think of a notorious python2 vs. python3. I am in 2019 and my software project has it as a dependency. My team has assessed that migration to v.3 will require another year of dealing with all the breaking changes. And while brainstorming we are thinking from the risk and cost-benefit perspective. Time per se is relevant only in the context of effort required to perform the migration. From the supply chain security standpoint I could not care less about time as well. If I am using library X of version 1.2.3 and it ticks all the boxes, has no performance impact, has 0 problems, 0 vulnerabilities (including the results from public, third party and internal code audits) I will continue using it even if version 2 is out, especially if it requires reassessment of risks and some code refactoring due to breaking API changes. If I want to automate my dependency management I will rely on tools that will tell me about my risks or potential missed benefits from the newer versions. Time will be taken into account only in terms of time needed for mitigating the risks directly impacting my piece of software.

semanser 2y ago
> If I am using library X of version 1.2.3 and it ticks all the boxes, has no performance impact, has 0 problems, 0 vulnerabilities (including the results from public, third party and internal code audits) I will continue using it even if version 2 is out, especially if it requires reassessment of risks and some code refactoring due to breaking API changes. What happens if the library that you're using is completely fine on its own (think React 18) but it's a core cross-dependency for tons of other libraries in your project. No libraries or frameworks should be considered in isolation. Otherwise, it can lead to a situation where you can't use some of the other tools/libraries, etc., because of the other dependency that is quite out of date.

thraxil 2y ago

They've succeeded in creating a single metric that's easy to calculate, but IMHO, it fails to be very useful for common use cases. Basically, it just uses the difference between the date the library version you are using was released and the current date if there's a newer release available. Eg, if you are using a library that has been unchanged at 1.0.0 for the last 10 years, you'll be 0 libyears behind that whole time. Then one day, the developers of that library release 1.0.1. One minute after that hits the package repositories, you are immediately 10 libyears behind. This makes it pretty useless as a metric for tracking how outdated an application really is. Eg, as an ops/SRE/security person, I'd want to be able to run this on a product team's code and have a single number that tells me whether they're reasonably up to date or seem to be ignoring their dependencies and letting technical debt pile up. A team could've been on the ball, keeping every dependency updated daily for years, but if I use libyear to evaluate them right after that that 10 year old dependency updates, it's going to look like they've been negligent. I have an open issue on the Python implementation (which ironically(?) hasn't had any commits in three years) asking for clarification: https://github.com/nasirhjafri/libyear/issues/35 https://github.com/nasirhjafri/libyear/issues/35

semanser 2y ago
I'm the developer of depshub.com (for automated dependency updates using AI) and even though a single metric isn't valuable, having any sort of indicators and metrics is very useful when you have more than one repository. Being able to quickly see if your repositories are getting better or worse over time helps to understand when the dependency updates should be prioritized (if so) in the first place. There are a few core metrics that I've built (major vs minor vs patch ratio, security updates, etc.) into the product, and it's one of the most used features up to date.

jlg23 2y ago

A great metric for job security, not necessarily for better software: Unless it concerns security or correctness, I prefer an old but audited version of a library anytime over a newer version that I have to audit again. A metric like this will be loved by PMs and loathed by developers who have to leave a known, sane state, update and deal with the fallout later on.

thih9 2y ago

I propose a different metric, version points: subtract version number of the currently used library from the version number of the latest version. Translate to semver first if possible. Also, a release addressing a CVE adds extra ten million points.

gwbas1c 2y ago

What's nice about the "libyear" concept is that it exposes the cost of indiscriminately pulling in 3rd party libraries. For example, I recently went through a project to bring 3rd party dependencies up-to-date. I noticed that we were using a very old mathematics and statistics library. On closer inspection, we were only using one function from the library to calculate the mode of a list of numbers. Looking at the library's source code, it was about 50 lines. Now, a decent programmer can recreate such a function in 1-3 hours, including a unit test. This is what we did instead of including the dependency. A naive programmer might think that sucking in the 3rd party library "saves" 1-3 hours, but that's not the case: Every few years someone will audit the libraries we're using as part of a security audit, or a legal audit to make sure that we're in compliance with open-source libraries. The stats library will incur a 1-2 hour cost in each audit. Furthermore, every 1-4 years we'll need to update the library, because changes in the programming language, runtime, OS, ect, mean we'll need at minimum a recompile or similar tweak to take advantage of some new language feature or constraint. The 3rd party dependency could add 1-4 hours to such a project. Thus, because libyear shows an increasing cost associated with the library, it's easier to explain why it's better to spend 1-3 hours writing a simple function (and unit test) than to bring in a 3rd party library to do the same thing.

sudo_bang_bang 2y ago

Very rarely do I so vehemently disagree with a particular argument in software. This idea epitomizes much of what is wrong in the industry. We can all agree security updates are essential, but a lot of libraries are “done” from a functional perspective for a majority of their existing use cases. Yes updates can be needed because interfaces break between other programs, standards evolve in backward incompatible ways, performance improvements can be made, etc. But much of the updates I see are changes for the sake of changes. You could use a 5 year old version of React for example, and modulo some set of security fixes if any, you could have a robust application. Sometimes software is just done. We are better off for accepting that idea. Get us off the update hamster wheel and stop the enshittification.

pomoke 2y ago

[dead]

captn3m0 2y ago

I’ve been wanting to make a similar indicator for the work I do at endoflife.date. IMO, a realistic upgradability metric would be linked to the “hardness of the upgrade to a supported version”, which is much harder to answer and quite contextual in how you are running each dependency. But libyear is a good metric to have as prior art in the field.

atgreen 2y ago

I just added libyear support to ocicl for Common Lisp.