arXiv subjects

Tom Mens

Publications and source records attributed to Tom Mens.

29 records · Page 2Linked to original sources

arXiv2018

Breaking the borders: an investigation of cross-ecosystem software packages

Software ecosystems are collections of projects that are developed and evolve together in the same environment. Existing literature investigates software ecosystems as isolated entities whose boundaries do not overlap and assumes they are self-contained. However, a number of software projects are distributed in more than one ecosystem. As different aspects, e.g., success, security vulnerabilities, bugs, etc., of such cross-ecosystem packages can affect multiple ecosystems, we investigate the presence and characteristics of these cross-ecosystem packages in 12 large software distributions. We found a small number of packages distributed in multiple packaging ecosystems and that such packages are usually distributed in two ecosystems. These packages tend to better support with new releases certain ecosystems, while their evolution can impact a multitude of packages in other ecosystems. Finally, such packages appear to be popular with large developer communities.

cs.SE↗

arXiv2018

On The Relation Between Outdated Docker Containers, Severity Vulnerabilities and Bugs

Packaging software into containers is becoming a common practice when deploying services in cloud and other environments. Docker images are one of the most popular container technologies for building and deploying containers. A container image usually includes a collection of software packages, that can have bugs and security vulnerabilities that affect the container health. Our goal is to support container deployers by analysing the relation between outdated containers and vulnerable and buggy packages installed in them. We use the concept of technical lag of a container as the difference between a given container and the most up-to-date container that is possible with the most recent releases of the same collection of packages. For 7,380 official and community Docker images that are based on the Debian Linux distribution, we identify which software packages are installed in them and measure their technical lag in terms of version updates, security vulnerabilities and bugs. We have found, among others, that no release is devoid of vulnerabilities, so deployers cannot avoid vulnerabilities even if they deploy the most recent packages. We offer some lessons learned for container developers in regard to the strategies they can follow to minimize the number of vulnerabilities. We argue that Docker container scan and security management tools should improve their platforms by adding data about other kinds of bugs and include the measurement of technical lag to offer deployers information of when to update.

cs.SE↗

arXiv2018

On the evolution of technical lag in the npm package dependency network

Software packages developed and distributed through package managers extensively depend on other packages. These dependencies are regularly updated, for example to add new features, resolve bugs or fix security issues. In order to take full advantage of the benefits of this type of reuse, developers should keep their dependencies up to date by relying on the latest releases. In practice, however, this is not always possible, and packages lag behind with respect to the latest version of their dependencies. This phenomenon is described as technical lag in the literature. In this paper, we perform an empirical study of technical lag in the npm dependency network by investigating its evolution for over 1.4M releases of 120K packages and 8M dependencies between these releases. We explore how technical lag increases over time, taking into account the release type and the use of package dependency constraints. We also discuss how technical lag can be reduced by relying on the semantic versioning policy.

cs.SE↗

arXiv2017

Automatic link extraction: The good, the bad and the ugly in software ecosystem mining

This abstract presents the automatic link extraction pitfalls based on our experience on manually investigating links in the RubyGems package manager metadata. This work can lead in automating the link extraction approach so as to avoid these pitfalls and produce more complete datasets to be used by researchers when they investigate the multi-platform evolution of software ecosystems.

cs.SE↗

arXiv2017

Towards an interdisciplinary, socio-technical analysis of software ecosystem health

This extended abstract presents the research goals and preliminary research results of the interdisciplinary research project SECOHealth, an ongoing collaboration between research teams of Polytechnique Montreal (Canada), the University of Mons (Belgium) and Laval University (Canada). SECOHealth aims to contribute to research and practice in software engineering by delivering a validated interdisciplinary scientific methodology and a catalog of guidelines and recommendation tools for improving software ecosystem health.

cs.SE↗

arXiv2017

An Empirical Comparison of Dependency Network Evolution in Seven Software Packaging Ecosystems

Nearly every popular programming language comes with one or more package managers. The software packages distributed by such package managers form large software ecosystems. These packaging ecosystems contain a large number of package releases that are updated regularly and that have many dependencies to other package releases. While packaging ecosystems are extremely useful for their respective communities of developers, they face challenges related to their scale, complexity, and rate of evolution. Typical problems are backward incompatible package updates, and the risk of (transitively) depending on packages that have become obsolete or inactive. This manuscript uses the libraries.io dataset to carry out a quantitative empirical analysis of the similarities and differences between the evolution of package dependency networks for seven packaging ecosystems of varying sizes and ages: Cargo for Rust, CPAN for Perl, CRAN for R, npm for JavaScript, NuGet for the .NET platform, Packagist for PHP, and RubyGems for Ruby. We propose novel metrics to capture the growth, changeability, resuability and fragility of these dependency networks, and use these metrics to analyse and compare their evolution. We observe that the dependency networks tend to grow over time, both in size and in number of package updates, while a minority of packages are responsible for most of the package updates. The majority of packages depend on other packages, but only a small proportion of packages accounts for most of the reverse dependencies. We observe a high proportion of fragile packages due to a high and increasing number of transitive dependencies. These findings are instrumental for assessing the quality of a package dependency network, and improving it through dependency management tools and imposed policies.

cs.SE↗

arXiv2017

An Empirical Comparison of Developer Retention in the RubyGems and npm Software Ecosystems

Software ecosystems can be viewed as socio-technical networks consisting of technical components (software packages) and social components (communities of developers) that maintain the technical components. Ecosystems evolve over time through socio-technical changes that may greatly impact the ecosystem's sustainability. Social changes like developer turnover may lead to technical degradation. This motivates the need to identify those factors leading to developer abandonment, in order to automate the process of identifying developers with high abandonment risk. This paper compares such factors for two software package ecosystems, RubyGems and npm. We analyse the evolution of their packages hosted on GitHub, considering development activity in terms of commits, and social interaction with other developers in terms of comments associated to commits, issues or pull requests. We analyse this socio-technical activity for more than 30k and 60k developers for RubyGems and npm respectively. We use survival analysis to identify which factors coincide with a lower survival probability. Our results reveal that developers with a higher probability to abandon an ecosystem: do not engage in discussions with other developers; do not have strong social and technical activity intensity; communicate or commit less frequently; and do not participate to both technical and social activities for long periods of time. Such observations could be used to automate the identification of developers with a high probability of abandoning the ecosystem and, as such, reduce the risks associated to knowledge loss.

cs.SE↗

arXiv2017

On the Interaction of Relational Database Access Technologies in Open Source Java Projects

This article presents an empirical study of how the use of relational database access technologies in open source Java projects evolves over time. Our observations may be useful to project managers to make more informed decisions on which technologies to introduce into an existing project and when. We selected 2,457 Java projects on GitHub using the low-level JDBC technology and higher-level object relational mappings such as Hibernate XML configuration files and JPA annotations. At a coarse-grained level, we analysed the probability of introducing such technologies over time, as well as the likelihood that multiple technologies co-occur within the same project. At a fine-grained level, we analysed to which extent these different technologies are used within the same set of project files. We also explored how the introduction of a new database technology in a Java project impacts the use of existing ones. We observed that, contrary to what could have been expected, object-relational mapping technologies do not tend to replace existing ones but rather complement them.

cs.SE↗

arXiv2016

Research trends in structural software complexity

There are many dimensions of software complexity. In this article, we explore how structural complexity is measured and used to study and control evolving software systems. We also present the current research challenges and emerging trends in this domain that has remained active for nearly four decades, and continues to evolve.

cs.SE↗

arXiv2016

Anonymized e-mail interviews with R package maintainers active on CRAN and GitHub

This technical report accompanies a research article that empirically studies the problems related to inter-repository package dependencies in the R ecosystem of statistical computing, with a focus on R packages hosted on CRAN and GitHub. The current report provides supplementary material, reproducing an anonymised and sanitised version of e-mail interviews that have been conducted in November 2015 with five active R package maintainers. The goal was to gain a better understanding in how R package maintainers develop and distribute their packages through GitHub and CRAN. All five interviewees were actively maintaining packages on GitHub, some were also active on CRAN. They have been selected based on their profile (the number of R packages they maintain on GitHub and/or CRAN) as well as their gender (three interviewees were male, two were female).

cs.SE↗

arXiv2016

Evolution Patterns: Designing and Reusing Architectural Evolution Knowledge to Introduce Architectural Styles

Software architectures are critical in the successful development and evolution of software-intensive systems. While formal and automated support for architectural descriptions has been widely addressed, their evolution is equally crucial, but significantly less well-understood and supported. In order to face a recurring evolution need, we introduce the concept of evolution pattern. It formalises an architectural evolution through both a set of concepts and a reusable evolution process. We propose it through the recurring need of introducing an architectural style on existing software architectures. We formally describe and analyse the feasibility of architectural evolution patterns, and provide a practical validation by implementing them in COSABuilder, an Eclipse plugin for the COSA architectural description language.

cs.SE↗