In an analysis of 100,000 deployed applications, Sonatype found coders updating open-source dependencies in their wares to a "suboptimal" version of the library the vast majority of the time.
The optimal library, by Sonatype's standards, might not be the most recent release — instead, it's more likely the most stable library without vulnerabilities that requires the least amount of changes to the current code to make it work.
"There's so much choice out there, so many versions out there. The pace of the new supply outpaces the developers' ability to consume the supply intelligently," said Matt Howard, Sonatype executive vice president.
Dependencies are a place where functionality, security and stability meet. Software is typically designed using open-source libraries that, in turn, require other open-source libraries. Updating a critical component to maintain the functionality of software or patch a vulnerability might mean updating the dependancies all the way down the chain, which in turn might cause other components to fail. You could try to minimize the clean-up work by only updating to the bare minimum dependancies, or minimize the potential for missing an important update by pulling every available update. Doing either could have negative consequences.
Libraries that are too far out of date can contain known vulnerabilities. Libraries that are on the bleeding edge may not have all the kinks, including nacent security problems, worked out. And every time developers update a library, it requires a substantial investment of time and work. If a developer has to update the same library more than they have to, it can be a financial hit.
The best choice, then, would be to update to the perfect mix of longevity, stability and security every time. Sonatype developed an eight-criteria system of determining what that might be. They list four as subjective and four as objective. The objective priorities are avoiding experimental releases of new libraries that are not tested in the real world, choosing the newest version of a library if multiple versions are published in quick succession, avoiding libraries that have known vulnerabilities, if avoiding known vulnerabilities is impossible, updating to the least vulnerable version. Subjective criteria include updating software in a version-to-version path others have tried before, using the most commonly deployed version of a library, minimizing code breakages and — if all things were equal — just choosing the latest version.
Using those criteria, Sonatype studied how often developers selected the optimal choice. In most cases — 69% of the time — they did not, with the overwhelming majority — 64% — coming from failures of the subjective criteria.
While subjective criteria might seem more minor, those minor dents add up. By not choosing the optimal libraries, projects waste an average of eight work days updating and re-updating libraries they would not have to if they followed an optimum strategy.
For many developers, accrued technical debt may cause bad decision-making on its own.
"It's a common fear that if I am on version 2.3, and the latest is 5.1, I just see those two numbers and think that's probably going to break a bunch of stuff in my application," said Stephen Magill, Sonatype's vice president of product innovation. "Then I make an incremental change, even though I'm still going to end up having to do the work later."
