peer reviewed

Large open-source software (OSS) communities are composed of multiple interrelated projects, hosting numerous repositories involving thousands of interacting contributors. Socio-technical studies about a community’s collaboration dynamics can benefit from historical data logs of the detailed activities performed by the projects’ contributors.This paper provides an automated mapping of raw public events in GitHub repositories to structured activities that more accurately capture the intent of contributors. It also contributes a large dataset containing three years of activities of the 180K+ contributors of NUMFOCUS, a large OSS community supporting scientific research and data science. The dataset covers 58 projects, including 2.2M+ activities across 2,851 GitHub repositories. This dataset allows advanced studies of the NUMFOCUS community collaboration dynamics, and the activity mapping process enables the possibility to create and use similar datasets for other OSS communities.

GitHub Actions is the de facto workflow automation tool for GitHub repositories. Its popularity has increased dramatically over the recent years, opening up opportunities for empirical studies related to its usage. To enable such studies, we implemented gigawork, an open source tool for extracting the commit histories of changes to work-flow files in GitHub repositories. Using this tool we collected and publicly released a dataset of 160K+ commit histories of workflow files in 32K+ public GitHub repositories, covering 1.5M+ workflow file versions. In order to facilitate its use by other researchers, the dataset includes relevant metadata related to workflow file changes in each commit. gigawork is publicly released on PyPi. Its associated dataset can be found on Zenodo (DOI: 10.5281/zenodo.10259013).

Collaborative software development through GitHub repositories frequently relies on bot accounts to automate repetitive and error-prone tasks. This highlights the need to have accurate and efficient bot identification tools. Several such tools have been proposed in the past, but they tend to rely on a substantial amount of historical data, or they limit themselves to a reduced subset of activity types, making them difficult to use at large scale. To overcome these limitations, we developed RABBIT, an open source command-line tool that queries the GitHub Events API to retrieve the recent events of a given GitHub account and predicts whether the account is a human or a bot. RABBIT is based on an XGBoost classification model that relies on six features related to account activities and achieves high performance, with an AUC, F1 score, precision and recall of 0.92. Compared to the state-of-the-art in bot identification, RABBIT exhibits a similar performance in terms of precision, recall and F1 score, while being more than an order of magnitude faster and requiring considerably less data. This makes RABBIT usable on a large scale, capable of processing several thousand accounts per hour efficiently.

GitHub's integrated automated workflow mechanism called GitHub Actions promotes the use of Actions as reusable building blocks in workflows. The majority of those Actions are developed in JavaScript and depend on packages distributed through the npm package manager. Those packages can suffer from security vulnerabilities, potentially affecting the Actions that rely on them. Using a dataset of 8,107 JavaScript Actions, we analysed to which extent dependencies on npm packages expose these Actions to vulnerabilities. We observed that JavaScript Actions tend to rely on dozens of npm packages, and that the vast majority of them depend on npm package releases with known vulnerabilities. Most of these vulnerabilities are caused by indirect dependencies, making it difficult for Actions maintainers to analyse their exposure to security vulnerabilities. Moreover, indirect dependencies are more likely to suffer from vulnerabilities of higher severity. We also studied to which extent security weaknesses occur in the source code of JavaScript Actions. To do so, we used CodeQL to detect security weaknesses, revealing that more than 54% of the studied JavaScript Actions contain at least one security weakness, and a small subset of these weaknesses recur frequently in their code. This justifies the need for further studies and more advanced tool support for addressing security issues in the GitHub Actions ecosystem.

The GitHub social coding platform introduced GitHub Actions as a way to automate different aspects of collaborative software development through the use of workflow files. It is the most popular CI/CD and workflow automation tool for GitHub. To maintain workflow code over time, it is useful to rely on differencing tools to identify the changes made during successive commits. Unfortunately, existing code differencing tools are not able to correctly identify changes made to workflow files. We therefore implemented gawd, a syntactic differencing tool for GitHub Actions workflows. The tool is capable of reporting the addition, deletion, modification and move of syntactic components in workflow files, taking into account the specific syntax of workflows. gawd has been evaluated on manually classified sets of workflow changes taken from existing commits in 40 different GitHub repositories, and was able to successfully identify these changes. gawd is publicly released as an open source Python tool distributed on PyPI.

Software repositories hosted on GitHub frequently use development bots to automate repetitive, effort intensive and error-prone tasks. To understand and study how these bots are used, state-of-the-art bot identification tools have been developed to detect bots based on their comments in commits, issues and pull requests. Given that bots can be involved in many other activity types, there is a need to consider more activities that they are carrying out in the software repositories they are involved in. We therefore propose a curated dataset of such activities carried out by bots and humans involved in GitHub repositories. The dataset was constructed by identifying 24 high-level activity types that could be extracted from 15 lower-level event types that were queried from GitHub’s event stream API for all considered bots and humans. The proposed dataset contains around 834K activities performed by 385 bots and 616 humans involved in GitHub repositories, during an observation period ranging from 25 November 2022 to 9 March 2023. By analysing the activity patterns of bots and humans, this dataset could lead to better bot identification tools and empirical studies on how bots play a role in collaborative software development.

GitHub Actions was introduced in 2019 and constitutes an integrated alternative to CI/CD services for GitHub repositories. The deep integration with GitHub allows repositories to easily automate software development workflows. This paper empirically studies the use of GitHub Actions on a dataset comprising 68K repositories on GitHub, of which 43.9% are using GitHub Actions workflows. We analyse which workflows are automated and identify the most frequent automation practices. We show that reuse of actions is a common practice, even if this reuse is concentrated in a limited number of actions. We study which actions are most frequently used and how workflows refer to them. Furthermore, we discuss the related security and versioning aspects. As such, we provide an overview of the use of GitHub Actions, constituting a necessary first step towards a better understanding of this emerging ecosystem and its implications on collaborative software development in the GitHub social coding platform.

Social coding platforms centred around git provide explicit facilities to share code between projects: forks, pull requests, cherry-picking to name but a few. Variant forks are an interesting phenomenon in that respect, as they permit for different projects to peacefully co-exist, yet explicitly acknowledge the common ancestry. Several researchers analysed forking practices on open source platforms and observed that variant forks get created frequently. However, little is known on the motivations for launching such a variant fork. Is it mainly technical (e.g., diverging features), governance (e.g., diverging interests), legal (e.g., diverging licences), or do other factors come into play? We report the results of an exploratory qualitative analysis on the motivations behind creating and maintaining variant forks. We surveyed 105 maintainers of different active open source variant projects hosted on GitHub. Our study extends previous findings, identifying a number of fine-grained common motivations for launching a variant fork and listing concrete impediments for maintaining the co-existing projects.

Continuous integration (CI) services are used in collaborative open source projects to automate parts of the development workflow. Such services have been in widespread use for over a decade, with new CIs being introduced over the years, sometimes overtaking other CIs in popularity. We conducted a longitudinal empirical study over a period of nine years, aiming to better understand this rapidly evolving CI landscape. By analysing the development history of 91,810 GitHub repositories of active npm packages having used at least one CI service, we quantitatively studied the evolution of seven popular CIs, specifically focusing on their co-usage and migration in the considered repositories. We provide statistical evidence of the rise of GitHub Actions, that has become the dominant CI service in less than 18 months time. This coincides with the fall of Travis that has seen an important decrease in usage, likely due to a combination of policy changes and migrations to GitHub Actions.

The practice of backporting aims to bring the benefits of a bug or vulnerability fix from a higher to a lower release of a software package. When such a package adheres to semantic versioning, backports can be recognised as new releases in a lower major train. This is particularly useful in case a substantial number of software packages continues to depend on that lower major train. In this article, we study the backporting practices in four popular package distributions, namelyCargo,npm,PackagistandRubyGems. We observe that many dependent packages could benefit from backports provided by their dependencies. In particular, we find that a majority of security vulnerabilities affect more than one major train but are only fixed in the highest one, letting thousands of dependent packages exposed to the vulnerability. Despite that, we find that backporting updates is quite infrequent, and mostly practised by long-lived and more active packages for a variety of reasons.

The semantic versioning (semver) policy is commonly accepted by open source package management systems to inform whether new releases of software packages introduce possibly backward incompatible changes. Maintainers depending on such packages can use this information to avoid or reduce the risk of breaking changes in their own packages by specifying version constraints on their dependencies. Depending on the amount of control a package maintainer desires to have over her package dependencies, these constraints can range from very permissive to very restrictive. This article empirically comparessemvercompliance of four software packaging ecosystems (Cargo, npm, Packagist and Rubygems), and studies how this compliance evolves over time. We explore to what extent ecosystem-specific characteristics or policies influence the degree of compliance. We also propose an evaluation based on the “wisdom of the crowds” principle to help package maintainers decide which type of version constraints they should impose on their dependencies.

The open-source Linux operating system is available through a wide variety of distributions, each containing a collection of installable software packages. It can be important to keep these packages as fresh as possible to benefit from new features, bug fixes and security patches. However, not all distributions place the same emphasis on package freshness. We conducted a survey in the first half of 2020 with 170 Linux users to gauge their perception of package freshness in the distributions they employ, the value they place on package freshness and the reasons why they do so, and the methods they use to update packages. The results of this survey reveal that, for the aforementioned reasons, keeping packages up to date is an important concern to Linux users and that they install and update packages through their distribution’s official repositories whenever possible, but often resort to third-party repositories and package managers for proprietary software and programming language libraries. Some distributions are perceived to be much quicker in deploying package updates than others. These results are useful to assess the expectations and requirements of Linux users in terms of package freshness and guide them in choosing a fitting distribution.

Large open source software projects, like Eclipse, follow a continuous software development process, with a regular release cycle. During each release, new bugs are reported, triaged and resolved. Previous studies have focused on various aspects of bug fixing, such as bug triaging, bug prediction, and bug process analysis. Most studies, however, do not distinguish between what happens before and after each scheduled release. We are also unaware of studies that compare bug fixing activities across different project releases. This paper presents an empirical analysis of the bug handling process of Eclipse over a 15-year period, considering 138K bug reports from Bugzilla, including 16 annual Eclipse releases and two quarterly releases in 2018. We compare the bug resolution rate, the fixing rate, the bug triaging time and the fixing time before and after each release date, and we study the possible impact of "release pressure". Among others, our results reveal that Eclipse bug handling activity is improving over time, with an important decrease in the number of reported bugs before releases, an increase in the bug fixing rate and an increasingly balanced bug handling workload before and after releases. The recent transition from an annual to a quarterly release cycle continued to improve the bug handling process.

Deploying software packages and services into containers is a popular software engineering practice that increases portability and reusability. Docker, the most popular containerization technology, helps DevOps practitioners in their daily activities. Despite being successfully and increasingly employed, containers may include buggy and vulnerable packages that put at risk the environments in which the containers have been deployed. Existing quality and security monitoring tools provide only limited support to analyze Docker containers, thus forcing practitioners to perform additional manual work or develop adhoc scripts when the analysis goes beyond security purposes. This limitation also affects researchers desiring to empirically study the evolution dynamics of Docker containers and their contained packages. To overcome this limitation, we present ConPan, an automated tool to inspect the characteristics of packages in Docker containers, such as their outdatedness and other possible flaws (e.g., bugs and security vulnerabilities). ConPan comes with a CLI and API, and the analysis results can be presented to the user in a variety of formats.

Containerized applications, and in particular Docker images, are becoming a common solution in cloud environments to meet ever-increasing demands in terms of portability, reliability and fast deployment. A Docker image includes all environmental dependencies required to run it, such as specific versions of system and third-party packages. Leveraging on its modularity, an image can be easily embedded in other images, thus simplifying the way of sharing dependencies and building new software. However, the dependencies included in an image may be out of date due to backward compatibility requirements, endangering the environments where the image has been deployed with known vulnerabilities. While previous research efforts have focused on studying the impact of bugs and vulnerabilities of system packages within Docker images, no attention has been given to third-party packages. This paper empirically studies the impact of npm JavaScript package vulnerabilities in Docker images. We based our analysis on 961 images from three official repositories that use Node.js, and 1,099 security reports of packages available on npm, the most popular JavaScript package manager. Our results reveal that the presence of outdated npm packages in Docker images increases the risk of potential security vulnerabilities, suggesting that Docker maintainers should keep their installed JavaScript packages up to date.

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.

Software systems often leverage on open source software libraries to reuse functionalities. Such libraries are readily available through software package managers like npm for JavaScript. Due to the huge amount of packages available in such package distributions, developers often decide to rely on or contribute to a software package based on its popularity. Moreover, it is a common practice for researchers to depend on popularity metrics for data sampling and choosing the right candidates for their studies. However, the meaning of popularity is relative and can be defined and measured in a diversity of ways, that might produce different outcomes even when considered for the same studies. In this paper, we show evidence of how different is the meaning of popularity in software engineering research. Moreover, we empirically analyse the relationship between different software popularity measures. As a case study, for a large dataset of 175k npm packages, we computed and extracted 9 different popularity metrics from three open source tracking systems: libraries.io, npmjs.com and GitHub. We found that indeed popularity can be measured with different unrelated metrics, each metric can be defined within a specific context. This indicates a need for a generic framework that would use a portfolio of popularity metrics drawing from different concepts.

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, reusability and fragility of these dependency networks, and use these metrics to analyze 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.

Abstract 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 model of technical lag, a concept that quantifies to which extent a deployed collection of components is outdated, with respect to the ideal deployment. We operationalise this model for the npm package manager. We empirically analyze the history of package update practices and technical lag for more than 500K packages with about 4M package releases over a seven‐year period. We consider both development and runtime dependencies, and study both direct and transitive dependencies. We also analyze the technical lag of external GitHub applications depending on npm packages. We report our findings, suggesting the need for more awareness of, and integrated tool support for, controlling technical lag in software libraries.

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.

Security vulnerabilities are among the most pressing problems in open source software package libraries. It may take a long time to discover and fix vulnerabilities in packages. In addition, vulnerabilities may propagate to dependent packages, making them vulnerable too. This paper presents an empirical study of nearly 400 security reports over a 6-year period in the npm dependency network containing over 610k JavaScript packages. Taking into account the severity of vulnerabilities, we analyse how and when these vulnerabilities are discovered and fixed, and to which extent they affect other packages in the packaging ecosystem in presence of dependency constraints. We report our findings and provide guidelines for package maintainers and tool developers to improve the process of dealing with security issues.

The evolution dynamics of a software ecosystem depend on the activity of the developer community contributing to projects within it. Both social and technical changes affect an ecosystem's evolution and the research community has been investigating the impact of these modifications over the last few years. Existing studies mainly focus on temporary modifications, often ignoring the effect of permanent changes on the software ecosystem. We present an empirical study of the magnitude and effect of permanent modifications in both the social and technical parts of a software ecosystem. More precisely, we measure permanent changes with regard to the ecosystem's projects, contributors and source code files and present our findings concerning the effect of these modifications. We study the Ruby ecosystem in GitHub over a nine-year period by carrying out a socio-technical analysis of the co-evolution of a large number of base projects and their forks. This analysis involves both the source code developed for these projects as well as the developers having contributed to them. We discuss our findings with respect to the ecosystem evolution according to three different viewpoints: (1) the base projects, (2) the forks and (3) the entire ecosystem containing both the base projects and forks. Our findings show an increased growth in both the technical and social aspects of the Ruby ecosystem until early 2014, followed by an increased contributor and project abandonment rate. We show the effect of permanent modifications in the ecosystem evolution and provide preliminary evidence of contributors migrating to other ecosystems when leaving the Ruby ecosystem.

Nearly every popular programming language comes with one or more open source software packaging ecosystem(s), containing a large collection of interdependent software packages developed in that programming language. Such packaging ecosystems are extremely useful for their respective software development community. We present an empirical analysis of how the dependency graphs of three large packaging ecosystems (npm, CRAN and RubyGems) evolve over time. We study how the existing package dependencies impact the resilience of the three ecosystems over time and to which extent these ecosystems suffer from issues related to package dependency updates. We analyse specific solutions that each ecosystem has put into place and argue that none of these solutions is perfect, motivating the need for better tools to deal with package dependency update problems.

Relational databases (DB) play a critical role in many information systems. For different reasons, their schemas gather not only tables and columns but also views, triggers or stored functions (i.e., fragments of code describing treatments). As for any other code-related artefact, software quality in a DB schema helps avoiding future bugs. However, few tools exist to analyse DB quality and prevent the introduction of technical debt. Moreover, these tools suffer from limitations like the difficulty to deal with some entities (e.g., functions) or dependencies between entities. This paper presents research issues related to assessing the software quality of a DB schema by adapting existing source code analysis research to database schemas. We present preliminary results that have been validated through the implementation of DBCritics, a prototype tool to perform static analysis on the SQL source code of a database schema. DBCritics addresses the limitations of existing DB quality tools based on an internal representation considering all entities of the database and their relationships.

Software development projects frequently rely on testing-related libraries to test the functionality of the software product automatically and efficiently. Many such libraries are available for Java, and developers face a hard time deciding which libraries are most appropriate for their project, or when to migrate to a competing library. We empirically analysed the usage of eight testing-related libraries in 4,532 open source Java projects hosted on GitHub. We studied how frequently specific (pairs of) libraries are used over time. We also identified if and when library usages are replaced by competing ones during a project's lifetime. We found that some libraries are considerably more popular than their competitors, while some libraries become more popular over time. We observed that many projects tend to use multiple libraries together. We also observed permanent and temporary migrations between competing libraries. These findings may pave the way for recommendation tools that allow project developers to choose the most appropriate library for their needs, and to be informed of better alternatives.

In this invited paper I focus on the difficulties of maintaining and evolving software systems that are part of a larger ecosystem. While not every software system falls under this category, software ecosystems are becoming ubiquitous due to the omnipresence of open source software. I present several challenges that arise during maintenance and evolution of software ecosystems, and I argue how some of these challenges should be addressed by adopting a socio-technical view and by relying on a multidisciplinary and mixed methods research approach. My arguments are accompanied by an extensive, though unavoidably incomplete, set of references to the state-of-the-art research in this domain.

When developing software packages in a software ecosystem, an important and well-known challenge is how to deal with dependencies to other packages. In presence of multiple package repositories, dependency management tends to become even more problematic. For the R ecosystem of statistical computing, dependency management is currently insufficient to deal with multiple package versions and inter-repository package dependencies. We explore how the use of GitHub influences the R ecosystem, both for the distribution of R packages and for inter-repository package dependency management. We also discuss how these problems could be addressed.

Many software projects rely on a relational database in order to realize part of their functionality. Various database frameworks and object-relational mappings have been developed and used to facilitate data manipulation. Little is known about whether and how such frameworks co-occur, how they complement or compete with each other, and how this changes over time. We empirically studied these aspects for 5 Java database frameworks, based on a corpus of 3,707 GitHub Java projects. In particular, we analysed whether certain database frameworks co-occur frequently, and whether some database frameworks get replaced over time by others. Using the statistical technique of survival analysis, we explored the survival of the database frameworks in the considered projects. This provides useful evidence to software developers about which frameworks can be used successfully in combination and which combinations should be avoided.

Users and developers of software distributions are often confronted with installation problems due to conflicting packages. A prototypical example of this are the Linux distributions such as Debian. Conflicts between packages have been studied under different points of view in the literature, in particular for the Debian operating system, but little is known about how these package conflicts evolve over time. This article presents an extensive analysis of the evolution of package incompatibilities, spanning a decade of the life of the Debian stable and testing distributions for its most popular architecture, i386. Using the technique of survival analysis, this empirical study sheds some light on the origin and evolution of package incompatibilities, and provides the basis for building indicators that may be used to improve the quality of package-based distributions.

The R development community maintains thousands of packages through its Comprehensive R Archive Network CRAN. The growth and evolution of this archive makes it more and more difficult to maintain packages and their interdependencies, and the existing tools that aim to help developers in this process no longer suffice. We propose maintaine R, a web-based dashboard that allows CRAN package developers to understand and deal with the implications and problems raised by package updates. The dashboard complements existing analysis tools by providing additional support such as the visualisation of package dependencies and reverse dependencies, package conflicts, cross-package function clones, and so on.

The 16th European Conference on Software Maintenance and Reengineering (CSMR 2012), focusing on the theory and practice of maintenance, reengineering, and evolution of software systems, took place in Szeged, Hungary. Since 2014, it has merged with the Working Conference on Reverse Engineering and has been renamed into SANER, the International Conference on Software Analytics, Evolution, and Reengineering. As program co-chairs of CSMR 2012, we have the pleasure to present you this guest editorial containing significantly extended and revised versions of accepted conference papers. The conference proceedings contained 30 full papers, selected after careful peer review from 108 submissions 1. Of the accepted full papers, four were invited for submitting an extended version to the JSEP journal, following another thorough peer review round. Only two of these articles made it into this special issue. The first article, entitled ‘The Linux Kernel: A Case Study of Build System Variability’ was written by Sarah Nadi and Richard Holt. Using the Linux kernel as a case study, they study the software variability in its build system. Among others, they show that considering build system variability constraints allows more anomalies to be detected. The second accepted article is written by Rainer Koschke. It is entitled ‘Large-scale inter-system clone detection using suffix trees and hashing’. It focuses on making clone detection (i.e., detecting similar code between two software systems) more scalable based on an extension of the traditional technique of suffix trees. The approach is evaluated on very large code corpora. We hope you like reading the articles in the special issue and invite you to contribute to the SANER conference series or the JSEP journal in the future.

We present a dataset of the open source software ecosystem Gnome from a social point of view. We have collected historical data about the contributors to all Gnome projects stored on git.gnome.org, taking into account the problem of identity matching, and associating different activity types to the contributors. This type of information is very useful to complement the traditional, source-code related information one can obtain by mining and analyzing the actual source code. The dataset can be obtained at https://bitbucket.org/mgoeminne/sgl-flossmetric-dbmerge.

The Mining Software Repositories community typically focuses on data from software configuration management tools, mailing lists, and bug tracking repositories to uncover interesting and actionable information about the evolution of software systems. However, the techniques employed and the challenges faced when mining are not restricted to these types of repositories. In this paper, we present an atypical dataset of software engineering conferences, containing historical data about the accepted papers and the composition of programme committees for eleven well-established conferences. The dataset (published on Github at https://github.com/tue-mdse/conferenceMetrics) can be used, e.g., by conference steering committees or programme committee chairs to assess their selection process and compare against other conferences in the field, or by prospective authors to decide in which conferences to publish.

In this showpiece we demonstrate PetriNect, an instance of a generic layered framework that we have developed for the specification and use of executable models of gestural interaction with virtual objects. The framework is built on top of Petshop and uses ICO models, a variant of high-level Petri nets. PetriNect uses the Kinect as input device for allowing the user to interact gesturally with virtual objects. We present two simple proof-of-concept prototype applications that have been developed for the purpose of this showpiece: a simple Pong game, and the interaction with a virtual bookshelf.

Integrating new input devices and their associated interaction techniques into interactive applications has always been challenging and time-consuming, due to the learning curve and technical complexity involved. Modeling devices, interactions and applications helps reducing the accidental complexity. Visual modeling languages can hide an important part of the technical aspects involved in the development process, thus allowing a faster and less error-prone development process. However, even with the help of modeling, a gap remains to be bridged in order to go from models to the actual implementation of the interactive application. In this paper we use ICO, a visual formalism based on high-level Petri nets, to develop a generic layered framework for specifying executable models of interaction using gestural input devices. By way of the CASE tool Petshop we demonstrate the framework's feasibility to handle the Kinect and gesture-based interaction techniques. We validate the approach through two case studies that illustrate how to use executable, reusable and extensible ICO models to develop gesture-based applications.

Nowadays, large-scale industrial software systems may involve hundreds of developers working on hundreds of different but related models representing parts of the same system specification. Detecting and resolving structural inconsistencies between these models is then critical. In this article we propose to represent models by sequences of elementary construction operations, rather than by the set of model elements they contain. Structural and methodological consistency rules can then be expressed uniformly as logical constraints on such sequences. Our approach is meta-model independent, allowing us to deal with consistency between different models whatever their kind. We have validated our approach by building a Prolog engine that detects violations of structural and methodological constraints specified on UML 2.1 models and requirement models. This engine has been integrated into two contemporary UML-based modelling environments, Eclipse EMF and Rational Software Architect (RSA).

We present a metrics-based study of the evolution of Eclipse, an open source integrated development environment, based on data from seven major releases, from releases 1.0 to 3.3. We investigated whether three of the laws of software evolution were supported by the data. We found that Eclipse displayed continual change and growth, hence supporting laws 1 and 6. Six size indicators, out of eight, closely followed trend models. Four were linear and two superlinear. We found evidence of increasing complexity (law 2) in only two indicators, out of five. At subproject level, size and complexity are not distributed uniformly, and subproject size can be modelled as a negative exponential function of the rank position. We encountered a range of different size and complexity trends across subprojects. Our approach and results can help in evaluating the future evolution of Eclipse, the evolution of other systems and in performing comparisons.

Abstract Previous taxonomies of software change have focused on the purpose of the change (i.e., the why) rather than the underlying mechanisms. This paper proposes a taxonomy of software change based on characterizing the mechanisms of change and the factors that influence these mechanisms. The ultimate goal of this taxonomy is to provide a framework that positions concrete tools, formalisms and methods within the domain of software evolution. Such a framework would considerably ease comparison between the various mechanisms of change. It would also allow practitioners to identify and evaluate the relevant tools, methods and formalisms for a particular change scenario. As an initial step towards this taxonomy, the paper presents a framework that can be used to characterize software change support tools and to identify the factors that impact on the use of these tools. The framework is evaluated by applying it to three different change support tools and by comparing these tools based on this analysis. Copyright © 2005 John Wiley & Sons, Ltd.

The widespread interest in refactoring—transforming the source-code of an object-oriented program without changing its external behaviour—has increased the need for a precise definition of refactoring transformations and their properties. In this paper we explore the use of graph rewriting for specifying refactorings and their effect on programs. We introduce a graph representation for programs and show how two representative refactorings can be expressed by graph productions. Then we demonstrate that it is possible to prove that refactorings preserve certain program properties, and that graph rewriting is a suitable formalism for such proofs. Copyright © 2005 John Wiley & Sons, Ltd.

Analyzing the Evolution of Large-Scale SoftwareThis special issue reports on approaches that address the issue of analyzing and visualizing the evolution of large-scale software.These approaches were discussed during the IEEE Workshop on Evolution of Large-Scale Industrial Software Evolution (ELISA), which was co-located with the International Conference on Software Maintenance in Amsterdam in September 2003.After a thorough review process, two articles have been selected for this special issue.The techniques proposed and illustrated in these articles allow us to gain a deeper insight into the nature of the evolution of large-scale software. THE WORKSHOPThe IEEE ELISA workshop was co-located with the International Conference on Software Maintenance in Amsterdam in September 2003.It was organized by Tom Mens, Juan F. Ramil, Michael W. Godfrey and Brian Down.The main theme of the workshop was planned to be the evolution of large-scale industrial software.Wider themes, such as the evolution of open source software, were also well represented in the workshop submissions.The goal was to achieve a deeper and wider insight into the problems posed by the evolution of software and the possible technological and managerial solutions.This goal is particularly relevant in current-day software practice, since size issues compound the challenges to achieving disciplined software evolution.Industrial and open-source software generally consist of numerous software artifacts that need to be evolved in a harmonious fashion, change requests that arrive more quickly than can be reasonably implemented, and the involvement of several teams implementing the evolution.Typical examples of large-scale software include air traffic control, popular PC operating systems, and telephone switch software.The challenges posed by the continual evolution of these and similar software clearly challenge the current state-of-the-art.In total, the ELISA workshop received 19 workshop submissions, nine of which were short papers and 10 were full papers: 15 of the submissions were classified as research papers, the remaining four as experience papers.One submission was rejected because it was considered as being of insufficient quality.

We provide an extensive overview of existing research in the field of software refactoring. This research is compared and discussed based on a number of different criteria: the refactoring activities that are supported, the specific techniques and formalisms that are used for supporting these activities, the types of software artifacts that are being refactored, the important issues that need to be taken into account when building refactoring tool support, and the effect of refactoring on the software process. A running example is used to explain and illustrate the main concepts.

In this paper, we show how elaborate support for framework-based software evolution can be provided based on explicit documentation of the hot spots of object-oriented application frameworks. Such support includes high-level transformations that guide a developer when instantiating applications from a framework by propagating the necessary changes, as well as application upgrading facilities based on these transformations. The approach relies on active declarative documentation of the design and evolution of the framework's hot spots, by means of metapatterns and their associated transformations.

Maintaining the source code of large software systems is hard. One underlying cause is that existing modularisation mechanisms are inadequate to handle crosscutting concerns. We propose intentional source-code views as an intuitive and lightweight means of modelling such concerns. They increase our ability to understand, modularise and browse the source code by grouping together source-code entities that address the same concern. They facilitate software development and evolution, because alternative descriptions of the same intentional view can be checked for consistency and relations among intentional views can be defined and verified. Finally, they enable us to specify knowledge developers have about source code that is not captured by traditional program documentation mechanisms.Our intentional view model is implemented in a logic metaprogramming language that can reason about and manipulate object-oriented source code directly. The proposed model has been validated on the evolution of a medium-sized object-oriented application in Smalltalk, and a prototype tool has been implemented.

Abstract This special issue reports on approaches that apply the idea of separation of concerns to software evolution. In this context, separation of concerns allows us to separate parts of the software that exhibit different rates of change or different types of change. This makes it possible to provide better evolution support for those parts that have a higher change rate, or to provide different evolution techniques for different views on the software. Another common way to achieve separation of concerns is by raising the level of abstraction to the level of software architectures, business rules and metamodels. This makes software evolution more manageable. The above ideas emerged as important conclusions of the workshop on Formal Foundations of Software Evolution, which was co‐located with the Conference on Software Maintenance and Re‐engineering in Lisbon in March 2001. Of the 12 original position papers, five have been selected for revision and inclusion in this special issue of the Journal of Software Maintenance and Evolution. Copyright © 2002 John Wiley & Sons, Ltd.

Software merging is an essential aspect of the maintenance and evolution of large-scale software systems. This paper provides a comprehensive survey and analysis of available merge approaches. Over the years, a wide variety of different merge techniques has been proposed. While initial techniques were purely based on textual merging, more powerful approaches also take the syntax and semantics of the software into account. There is a tendency towards operation-based merging because of its increased expressiveness. Another tendency is to try to define merge techniques that are as general, accurate, scalable, and customizable as possible, so that they can be used in any phase in the software life-cycle and detect as many conflicts as possible. After comparing the possible merge techniques, we suggest a number of important open problems and future research directions.

My PhD thesis claims that the principles behind object-oriented software evolution are independent of a particular domain or phase in the software lifecycle. To validate this claim, a formalism based on graphs and graph rewriting was developed and applied to a particular aspect of software evolution, namely the problem of software upgrading and software merging. When the same piece of software is modified in parallel by different software developers, unexpected inconsistencies can arise. Formal support can be provided to detect and resolve these inconsistencies in a general way.

Object-oriented design patterns and high-level refactorings are popular means of implementing and evolving large object-oriented software systems. Unfortunately, these techniques are inadequately supported at implementation level by current-day software development environments. To alleviate this problem, we propose to use the promising technique of declarative metaprogramming. It offers a tight, yet flexible, symbiosis between a base language and a metalevel declarative reasoning engine. It provides a uniform and language-independent way to specify design patterns and transformations declaratively, to instantiate patterns and generate code for them, and to deal with the evolution of these pattern instances. Providing support for evolution of a software system in terms of the design pattern instances it uses is the main emphasis of this paper.

ESM systems are a graph-rewriting formalism for concurrent systems: a global system state is represented by a graph and a run of the system is described by a graph rewriting process. These rewriting processes are formally described by computation str