How the Apache community upgrades dependencies: an evolutionary study

Bavota, Gabriele; Canfora, Gerardo; Penta, Massimiliano Di; Oliveto, Rocco; Panichella, Sebastiano

doi:10.1007/s10664-014-9325-9

Cited by 108 publications

(59 citation statements)

References 32 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…A large amount of dependencies can lead to issues such as extended build time because of fetching the dependencies and increased software package size. Exponential growth has been observed inside Apache ecosystem as well [15]. Recently, a newer dependency management tool compatible with npm was introduced [30].…”

Section: A Resultsmentioning

confidence: 99%

See 1 more Smart Citation

Structure and Evolution of Package Dependency Networks

Kikas

Gousios

Dumas

et al. 2017

2017 IEEE/ACM 14th International Conference on Mining Software Repositories (MSR)

128

129

View full text Add to dashboard Cite

Abstract-Software developers often include available opensource software packages into their projects to minimize redundant effort. However, adding a package to a project can also introduce risks, which can propagate through multiple levels of dependencies. Currently, not much is known about the structure of open-source package ecosystems of popular programming languages and the extent to which transitive bug propagation is possible. This paper analyzes the dependency network structure and evolution of the JavaScript, Ruby, and Rust ecosystems. The reported results reveal significant differences across language ecosystems. The results indicate that the number of transitive dependencies for JavaScript has grown 60% over the last year, suggesting that developers should look more carefully into their dependencies to understand what exactly is included. The study also reveals that vulnerability to a removal of the most popular package is increasing, yet most other packages have a decreasing impact on vulnerability. The findings of this study can inform the development of dependency management tools.

show abstract

Section: A Resultsmentioning

confidence: 99%

“…A study of dependency management process in Apache projects [15] found that if the number of projects in the ecosystem grows linearly, the dependencies among them grow exponentially. Bavota et al [16] also find that new releases often do not contain updates to their dependencies.…”

Section: B Related Workmentioning

confidence: 99%

Structure and Evolution of Package Dependency Networks

Kikas

Gousios

Dumas

et al. 2017

2017 IEEE/ACM 14th International Conference on Mining Software Repositories (MSR)

128

129

View full text Add to dashboard Cite

show abstract

“…The complexity of dependency management [7][8][9], or their significant evolution over time [3] are reasons both to delay upgrading (because of the potential problems), and to consider it (because of the added functionality and improved code). The same way that the complexity in dependencies, or the some parameters of their evolution [10] can be measured, we are exploring the concept of technical lag to measure their "degradation" over time with respect to some "ideal" gold standard.…”

Section: Discussionmentioning

confidence: 99%

Technical Lag in Software Compilations: Measuring How Outdated a Software Deployment Is

González-Barahona

Sherwood

Robles

et al. 2017

Open Source Systems: Towards Robust Practices

View full text Add to dashboard Cite

Abstract. Large software compilations based on free, open source software (FOSS) packages are the basis for many software systems. When they are deployed in production, specific versions of the packages in the compilation are selected for installation. Over time, those versions become outdated with respect to the upstream software from which they are produced, and from the components available in the compilations as well. The fact that deployed components are outdated is not a problem in itself, but there is a price to pay for not being "as much updated as reasonable". This includes bug fixes and new features that could, at least potentially, be interesting for the deployed system. Therefore, a balance has to be maintained between "being up-to-date" and "keeping the good old working versions". This paper proposes a theoretical model (the "technical lag") for measuring how outdated a system is, with the aim of assisting in the decisions about upgrading in production. The paper explores several ways in which technical lag can be implemented, depending on requirements. As an illustration, it presents as well some specific cases in which the evolution of technical lag is computed.

show abstract

“…This could happen when the old version of a FOSS component is affected by a vulnerability but it is not supported by its developers (e.g., EOL of Tomcat 5.5), or it is not actively maintained at the moment. application that consumes it, thus there is significant effort involved in migrating the application; 3) The internal changes of the library are of limited concern for the developers of the consuming application unless the functionality has been changed -the latter change is often being captured by a change in the APIs (See [5], [46] for a discussion); Considering the above, we understood that a simple metric for change, the number of changed API of a component, is considered to be more interesting by developers as their focus is to use the FOSS component as a (black box) library.…”

Section: Data Selectionmentioning

confidence: 99%

A Screening Test for Disclosed Vulnerabilities in FOSS Components

Dashevskyi

Brucker

Massacci

2019

IIEEE Trans. Software Eng.

View full text Add to dashboard Cite

Abstract-Free and Open Source Software (FOSS) components are ubiquitous in both proprietary and open source applications. Each time a vulnerability is disclosed in a FOSS component, a software vendor using this component in an application must decide whether to update the FOSS component, patch the application itself, or just do nothing as the vulnerability is not applicable to the older version of the FOSS component used. This is particularly challenging for enterprise software vendors that consume thousands of FOSS components and offer more than a decade of support and security fixes for their applications. Moreover, customers expect vendors to react quickly on disclosed vulnerabilities-in case of widely discussed vulnerabilities such as Heartbleed, within hours. To address this challenge, we propose a screening test: a novel, automatic method based on thin slicing, for estimating quickly whether a given vulnerability is present in a consumed FOSS component by looking across its entire repository. We show that our screening test scales to large open source projects (e.g., Apache Tomcat, Spring Framework, Jenkins) that are routinely used by large software vendors, scanning thousands of commits and hundred thousands lines of code in a matter of minutes. Further, we provide insights on the empirical probability that, on the above mentioned projects, a potentially vulnerable component might not actually be vulnerable after all.

show abstract

How the Apache community upgrades dependencies: an evolutionary study

Cited by 108 publications

References 32 publications

Structure and Evolution of Package Dependency Networks

Structure and Evolution of Package Dependency Networks

Technical Lag in Software Compilations: Measuring How Outdated a Software Deployment Is

A Screening Test for Disclosed Vulnerabilities in FOSS Components

Contact Info

Product

Resources

About