This presentation was given at the BENEVOL 2019 workshop in Brussels.
Reusable Open Source Software (OSS) components for major programming languages are available in package repositories. Developers rely on package management tools to automate deployments, specifying which package releases satisfy the needs of their applications. However, these specifications may lead to deploying package releases that are outdated or otherwise undesirable because they do not include bug fixes, security fixes, or new functionality. In contrast, automatically updating to a more recent release may introduce incompatibility issues. To capture this delicate balance, we formalise a generic framework of technical lag, a concept that quantifies to which extent a deployed collection of components is outdated with respect to the ideal deployment. The framework can be used to assess and reduce the outdatedness, vulnerability and bugginess of software deployments, software projects, software containers and reusable software libraries. We argue that such a metric is very relevant for assessing the health of software (eco)systems, and should be used.
Not updateUpdate “If I go there will be trouble,
And if I stay it will be double,
So come on and let me know:
Should I Stay Or Should I Go? ”
Technical lag*: the diﬀerence between deployed
software packages and the ideal available packages.
1.0.1 1.2.0 220.127.116.11.0 2.1.0
Releases of a
Measurement: bugs, vulnerabilities, version updates,
line of code, commits, etc.
Gold standard/IDEAL: stability, security, functionality,
1.0.1 1.2.0 2.0.1
Credits: https://exploring-data.com/vis/npm-packages-dependencies/ 11
● is a set of component releases
● is a set of possible lag values
● ideal : → is a function returning the “ideal” component release
● delta : x → is a function computing the difference between two
● agg : is a function aggregating the results of a set of lags
Given a technical lag framework , we define:
Aggregated Technical lag
Let D C be a set of components, then:
- npm packages : the whole registry
- Debian-based Docker images
Goal: Analyze technical lag in software ecosystems.
- npm packages have a median version lag of 14 versions (2 majors, 2 minors , 10 patches)
- Technical lag is increasing over time.
- Version constraints (e.g, ^1.0.0), are the main reason behind the technical lag.
- Development dependencies have slightly more technical lag than runtime dependencies
For direct dependencies
/npm applications For direct dependencies
Time lag induced by direct dependencies in GitHub applications:
Technical lag in GitHub applications is higher than in npm
- Debian packages have a median version lag of 1 version
- Debian-based images have a median version lag of 6 versions.
- Technical lag depends on the Debian version used in the image
- Diﬀerent dimensions of technical lag are complementary
- The technical lag could help open source software developers and deployers to keep their
software in a healthy shape.
- TL can be a proxy for the eﬀort needed to deploy the ideal version.