Open Source Systems

Background. Industrial software increasingly relies on open source software. Therefore, industrial practitioners need to evaluate the quality of a specific open source product they are considering for adoption. Automated tools greatly help assess open source software quality, by reducing the related costs, but do not provide perfectly reliable indications. Indications from tools can be used to restrict and focus manual code inspections, which are typically expensive and time-consuming, only on the code sections most likely to contain faults. Aim. We investigate the extent of the effectiveness of static analysis bug detectors by themselves and in combination with code smell detectors in guiding inspections. Method. We performed an empirical study, in which we used a bug detector (SpotBugs) and a code smell detector (JDeodorant). Results. Our results show that the selected bug detector is precise enough to justify inspecting the code it flags as possibly buggy. Applying the considered code smell detector makes predictions even more precise, but at the price of a rather low recall. Conclusions. Using the considered tools as inspection drivers proved quite useful. The relatively small size of our study does not allow us to draw universally valid conclusions, but our results should be applicable to source code of any kind, although they were obtained from open source code.

Formulation of mandatory requirements in procurement projects has significant influence on opportunities for development and deployment of Open Source Software (OSS). The paper contributes insights on a widespread practice amongst public procurement projects which causes problematic lock-in effects and thereby inhibits opportunities for use of OSS solutions. Through a systematic investigation of 30 randomly selected procurement projects in the software domain the paper highlights illustrative examples of mandatory requirements which cause lock-in and presents five recommendations for how requirements instead should be formulated in order to avoid causing lock-in. Findings show significant lock-in caused by current procurement practices with a stark preference for proprietary software and SaaS solutions amongst procuring organisations.

Finding the same or similar code snippets in the source code for a query code snippet is one of the fundamental activities in software maintenance. Code clone detectors detect the same or similar code snippets, but they report all of the code clone pairs in the target, which are generally excessive to the users. In this paper, we propose ccgrep, a token-based pattern matching tool with the notion of code clone pairs. The user simply inputs a code snippet as a query and specifies the target source code, and gets the matched code snippets as the result. The query and the result snippets form clone pairs. The use of special tokens (named meta-tokens) in the query allows the user to have precise control over the matching. It works for the source code in C, C++, Java, and Python on Windows or Unix with practical scalability and performance. The evaluation results show that ccgrep is effective in finding intended code snippets in large Open Source Software.

Open source software (OSS), playing an increasingly critical role nowadays, has been commonly adopted and integrated in various software products. For many practitioners, selecting and adopting suitable OSS can help them greatly. Though many studies have been conducted on proposing OSS evaluation and selection models, a limited number are followed and used in the industry. Meanwhile, many existing OSS evaluation tools, though providing valuable details, fall short on offering intuitive suggestions in terms of framework-supported evaluation factors. Towards filling the gap, we propose an Open Source Software Project Evaluation and Selection TOol (OSS PESTO). Targeting OSS on Github, the largest OSS source code host, it facilitates the evaluation practice by enabling practitioners to compare candidates therein in terms of selected OSS evaluation models. It also allows in-time Github data collection and customized evaluation that enriches its effectiveness and ease of use.

Software development for electronic games has remarkable performance and portability requirements, and the system and low-level languages usually provide those. This ecosystem became homogeneous at commercial levels around C and C++, both for open source or proprietary solutions. However, innovations brought other possibilities that are still growing in this area, including Rust and other system languages. Rust has low-level language properties and modern security guarantees in access to memory, concurrency, dependency management, and portability. The Open Source game engine Amethyst has become a reference solution for game development in Rust, has a large and active community, and endeavors in being an alternative to current solutions. Amethyst brings parallelism and performance optimizations, with the advantages of the Rust language. This paper presents scripting concepts that allow the game logic to be implemented in an external interpreted language. We present a scripting module called Legion Script that was implemented for the entity and component system (ECS) called Legion, part of the Amethyst organization. As a Proof-of-Concept (POC), we perform the Python code interpretation using the Rust Foreign Function Interface (FFI) with CPython. This POC added scripting capabilities to Legion. We also discuss the benefit of using the alternative strategy of developing a POC before contributing to OSS communities in emergent technologies.

The literature dedicated to free and open source software emphasizes the support given by the community to software producers. However, the community is also a place of conflict and can sometimes experience violent splits (forks). Communities can show different forms of resistance to change. In this research, we propose a re-reading of these mechanisms of opposition in light of Albert Hirschman's theory (exit, voice, loyalty). We present the fork as a new form of defection (exit) allowed by licenses and discuss the rationality of choice for the economic actors who implement it.

Customizability, extensive community support and ease of availability have led to the popularity of Open-Source Software (OSS) systems. However, maintenance of these systems is a challenge especially as they become considerably large and complex with time. One possible method of ensuring effective quality in large scale OSS is the adoption of software change prediction models. These models aid in identifying change-prone parts in the early stages of software development, which can then be effectively managed by software practitioners. This study extensively evaluates eight Homogeneous Ensemble Learners (HEL) for developing software change prediction models on five large scale OSS datasets. HEL, which integrate the outputs of several learners of the same type are known to generate improved results than other non-ensemble classifiers. The study also statistically compares the results of the models developed by HEL with ten non-ensemble classifiers. We further assess the change in performance of HEL for developing software change prediction models by substituting their default base learners with other classifiers. The results of the study support the use of HEL for developing software change prediction models and indicate Random Forest as the best HEL for the purpose.