Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Technical Lag in Software Ecosystems


Published on

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.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Technical Lag in Software Ecosystems

  1. 1. Technical Lag in Software Ecosystems Ahmed Zerouali The 18th Belgium-Netherlands Software Evolution Workshop November 28-29, 2019 - VUB, Brussels 1
  2. 2. 2
  3. 3. /background Credits: 3
  4. 4. /background 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? ” The Clash 4
  5. 5. /background Technical lag*: the difference between deployed software packages and the ideal available packages. 1.0.1 1.2.0 2.1.0 Technical lag Deployed Ideal Releases of a used software 5
  6. 6. /background Measurement: bugs, vulnerabilities, version updates, line of code, commits, etc. Gold standard/IDEAL: stability, security, functionality, etc. 6
  7. 7. /example up-to-date 1.0.1 3.6.0 1.2.0 4.0.0 allowed dependent package P required package D 7
  8. 8. /example outdated 1.0.1 1.2.0 2.0.1 3.6.0 4.0.0 2.0.0 allowed 4.1.0 missing updates dependent package P required package D 8
  9. 9. /example package.json 9
  10. 10. /dependency network Credits: 10
  11. 11. /dependency tree Credits: 11
  12. 12. /technical lag framework ● 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 component releases ● agg : is a function aggregating the results of a set of lags 12
  13. 13. /technical lag framework Given a technical lag framework , we define: Technical lag Aggregated Technical lag Let D C be a set of components, then: 13
  14. 14. /case studies - npm packages : the whole registry - Debian-based Docker images Goal: Analyze technical lag in software ecosystems. 14
  15. 15. /results /npm packages - 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 versions 15
  16. 16. /results /npm applications For direct dependencies Time lag induced by direct dependencies in GitHub applications: Technical lag in GitHub applications is higher than in npm package releases 16
  17. 17. /results /Docker images - 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 - Different dimensions of technical lag are complementary 17
  18. 18. /conclusion - 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 effort needed to deploy the ideal version. 18