An analysis of the adoption of OSS by local public administrations: Evidence from the Emilia-Romagna Region of Italy

The wide diffusion of open source software (OSS) is driving discussion among scholars on a set of issues, including its adoption by public administrations (PA). Previous works only discussed one or a few factors that drive the decision to adopt OSS and did not addressed the potential benefits in terms of e-government that OSS may bring to PA. Our paper attempts to fill these gaps. The analysis is based on the Emilia-Romagna region of Italy and studies the adoption of software (both proprietary and open source) by local PA. The results show there is increased adoption of OSS in several different domains of application, both servers and desktop clients. Among the motivations to adopt OSS, only dependence on software suppliers seems to be important. Its adoption also positively affects the variety and extent of interactivity of local public e-services.open source software; public administration; online public services; empirical research

Epistemic Communities, Situated Learning and Open Source Software Development

This paper analyses open source software development as an epistemic community. Open source software develpoment is a learning process where the involved parties contribute to, and learn from the community. It is discovered that theory of epistemic communities does indeed contribute to the understandig of open source software development. But the important learning process of open source development only explained by the introduction of situated learning and legitimate peripheral participation as a theoretical prerspective. This allows the learning process to be part of the activities in the epistemic community. The combination of situated learning and epistemic community is shown to be fruitful and capable of explaining some of the empirical observations. In particular the combination of theories can shed light on the motivational issues and group dynamics

Identifying Unmaintained Projects in GitHub

Background: Open source software has an increasing importance in modern software development. However, there is also a growing concern on the sustainability of such projects, which are usually managed by a small number of developers, frequently working as volunteers. Aims: In this paper, we propose an approach to identify GitHub projects that are not actively maintained. Our goal is to alert users about the risks of using these projects and possibly motivate other developers to assume the maintenance of the projects. Method: We train machine learning models to identify unmaintained or sparsely maintained projects, based on a set of features about project activity (commits, forks, issues, etc). We empirically validate the model with the best performance with the principal developers of 129 GitHub projects. Results: The proposed machine learning approach has a precision of 80%, based on the feedback of real open source developers; and a recall of 96%. We also show that our approach can be used to assess the risks of projects becoming unmaintained. Conclusions: The model proposed in this paper can be used by open source users and developers to identify GitHub projects that are not actively maintained anymore.Comment: Accepted at 12th International Symposium on Empirical Software Engineering and Measurement (ESEM), 10 pages, 201

Contributors’ Preference in Open Source Software Usability: An Empirical Study

The fact that the number of users of open source software (OSS) is practically un-limited and that ultimately the software quality is determined by end user’s experience, makes the usability an even more critical quality attribute than it is for proprietary software. With the sharp increase in use of open source projects by both individuals and organizations, the level of usability and related issues must be addressed more seriously. The research model of this empirical investigation studies and establishes the relationship between the key usability factors from contributors’ perspective and OSS usability. A data set of 78 OSS contributors that includes architects, designers, developers, testers and users from 22 open source projects of varied size has been used to study the research model. The results of this study provide empirical evidence by indicating that the highlighted key factors play a significant role in improving OSS usability

An Open Source Usability Maturity Model (OS-UMM)

User satisfaction has always been a major factor in the success of software, regardless of whether it is closed proprietary or open source software (OSS). In open source projects, usability aspects cannot be improved unless there are ways to test and measure them. Hence, the increasing popularity of open source projects among novice and non-technical users necessitates a usability evaluation methodology. Consequently, this paper presents a usability maturity model specifically aimed at usability-related issues for open source projects. In particular, the model examines the degree of coordination between open source projects and their usability aspects. The measuring instrument of the model contains factors that have been selected from four of our empirical studies, which examine the perspectives of OSS users, developers, contributors and the industry. In addition to presenting the usability maturity model, this paper discusses assessment questionnaires, a rating methodology and two case studies

A Versatile Dataset of Agile Open Source Software Projects

Agile software development is nowadays a widely adopted practise in both open-source and industrial software projects. Agile teams typically heavily rely on issue management tools to document new issues and keep track of outstanding ones, in addition to storing their technical details, effort estimates, assignment to developers, and more. Previous work utilised the historical information stored in issue management systems for various purposes; however, when researchers make their empirical data public, it is usually relevant solely to the study’s objective. In this paper, we present a more holistic and versatile dataset containing a wealth of information on more than half a million issues from 44 open-source Agile software, making it well-suited to several research avenues, and cross-analyses therein, including effort estimation, issue prioritisation, issue assignment and many more. We make this data publicly available on GitHub to facilitate ease of use, maintenance, and extensibility

"We do not appreciate being experimented on": Developer and Researcher Views on the Ethics of Experiments on Open-Source Projects

A tenet of open source software development is to accept contributions from users-developers (typically after appropriate vetting). But should this also include interventions done as part of research on open source development? Following an incident in which buggy code was submitted to the Linux kernel to see whether it would be caught, we conduct a survey among open source developers and empirical software engineering researchers to see what behaviors they think are acceptable. This covers two main issues: the use of publicly accessible information, and conducting active experimentation. The survey had 224 respondents. The results indicate that open-source developers are largely open to research, provided it is done transparently. In other words, many would agree to experiments on open-source projects if the subjects were notified and provided informed consent, and in special cases also if only the project leaders agree. While researchers generally hold similar opinions, they sometimes fail to appreciate certain nuances that are important to developers. Examples include observing license restrictions on publishing open-source code and safeguarding the code. Conversely, researchers seem to be more concerned than developers about privacy issues. Based on these results, it is recommended that open source repositories and projects address use for research in their access guidelines, and that researchers take care to ask permission also when not formally required to do so. We note too that the open source community wants to be heard, so professional societies and IRBs should consult with them when formulating ethics codes.Comment: 15 pages with 42 charts and 3 tables; accepted versio

What to Fix? Distinguishing between design and non-design rules in automated tools

Technical debt---design shortcuts taken to optimize for delivery speed---is a critical part of long-term software costs. Consequently, automatically detecting technical debt is a high priority for software practitioners. Software quality tool vendors have responded to this need by positioning their tools to detect and manage technical debt. While these tools bundle a number of rules, it is hard for users to understand which rules identify design issues, as opposed to syntactic quality. This is important, since previous studies have revealed the most significant technical debt is related to design issues. Other research has focused on comparing these tools on open source projects, but these comparisons have not looked at whether the rules were relevant to design. We conducted an empirical study using a structured categorization approach, and manually classify 466 software quality rules from three industry tools---CAST, SonarQube, and NDepend. We found that most of these rules were easily labeled as either not design (55%) or design (19%). The remainder (26%) resulted in disagreements among the labelers. Our results are a first step in formalizing a definition of a design rule, in order to support automatic detection.Comment: Long version of accepted short paper at International Conference on Software Architecture 2017 (Gothenburg, SE