It's true that dependency-free software is very rare these days. The most obvious reason is that people don't want to "reinvent the wheel" when doing something. While this is a 100% valid reason, sometimes people simply forget what they are building and for whom. Extensive usage of dependencies is just one of the forms of overengineering. Some engineering teams even do their planning and features because of the new shiny thing.
The problem of dependencies is massive these days, and most companies are focusing on producing more and more code instead of helping people manage what they already have.
I had a similar idea for a while. Happy to see someone is actually doing it.
One of the main problems of PH is the amount of bots and fake accounts. Any plans of fighting that?
PH is still a great platform for visibility since it gets tons of traffic.
Thanks! Yeah, this is a recurrent problem that can't be solved once and for all (at least right now). So we definitely need better tools to deal with it.
I’m working on a similar project (DepsHub) where LLMs are used to make major library updates as smooth as possible. While it doesn’t work in 100% cases, it really helps to minimize all the noise while keeping your project up to date. I’m not surprised Slack decided to go this way as well.
> 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?
This is exactly what I've added for depshub.com, and people seem to like it a lot. It just gives you better visibility across all of your connected repositories about what the current status of each dependency is and how the major vs. minor vs. patch ratio changes over time. While it's still a naive metric, it's the easiest to understand and visualize - and as a result, the one that is used the most.
> Any ideas on how we can measure improvements?
- Quantitative: Spend as little amount of time as possible on trying to keep everything relatively up to date (hours/month)
- Qualitative: not having any CVE issues, not having major updates for core libraries and tools.
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.
> 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.
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."
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.
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.
> 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.