Open Source Software Projects Research Articles

An empirical study of issue-link algorithms: which issue-link algorithms should we use?

The accuracy of the SZZ algorithm is pivotal for just-in-time defect prediction because most prior studies have used the SZZ algorithm to detect defect-inducing commits to construct and evaluate their defect prediction models. The SZZ algorithm has two phases to detect defect-inducing commits: (1) linking issue reports in an issue-tracking system to possible defect-fixing commits in a version control system by using an issue-link algorithm (ILA); and (2) tracing the modifications of defect-fixing commits back to possible defect-inducing commits. Researchers and practitioners can address the second phase by using existing solutions such as a tool called cregit. In contrast, although various ILAs have been proposed for the first phase, no large-scale studies exist in which such ILAs are evaluated under the same experimental conditions. Hence, we still have no conclusions regarding the best-performing ILA for the first phase. In this paper, we compare 10 ILAs collected from our systematic literature study with regards to the accuracy of detecting defect-fixing commits. In addition, we compare the defect prediction performance of ILAs and their combinations that can detect defect-fixing commits accurately. We conducted experiments on five open-source software projects. We found that all ILAs and their combinations prevented the defect prediction model from being affected by missing defect-fixing commits. In particular, the combination of a natural language text similarity approach, Phantom heuristics, a random forest approach, and a support vector machine approach is the best way to statistically significantly reduced the absolute differences from the ground-truth defect prediction performance. We summarized the guidelines to use ILAs as our recommendations.

Innovating beyond firm boundaries: resource deployment control in open source software development

PurposeIn times of open and distributed innovation, many innovation activities that are important for firms' products and services take place beyond the boundaries of the firm and thus beyond firms' direct control. A prime example for this phenomenon is open source software (OSS) development, where multiple actors contribute to a public good, which is also integrated into company-owned software products. Despite the importance of aligning community work on the public good with own in-house development efforts, firms have limited options to directly control the OSS project or the project's outcome. This research reflects on resource deployment control, a control mode in which firms assign own developers to work for an OSS project to influence the OSS project, and tests hypotheses on individual developer levels.Design/methodology/approachThis research tests the effect of perceived resource deployment control on opinion leadership by analyzing employed Linux kernel developers.FindingsThe findings show that developers who perceive being assigned to an OSS project to enact control also exhibit opinion leadership. This research also investigates boundary conditions such as the OSS business model a firm operates and the reputation developers assign to the developers' employer.Originality/valueThis research is the first that is devoted to resource deployment control, and the research closes with a discussion of implications for control theory and the management of innovation beyond firm boundaries.

Turnover of Companies in OpenStack: Prevalence and Rationale

To achieve commercial goals, companies have made substantial contributions to large open-source software (OSS) ecosystems such as OpenStack and have become the main contributors. However, they often withdraw their employees for a variety of reasons, which may affect the sustainability of OSS projects. While the turnover of individual contributors has been extensively investigated, there is a lack of knowledge about the nature of companies’ withdrawal. To this end, we conduct a mixed-methods empirical study on OpenStack to reveal how common company withdrawals were, to what degree withdrawn companies made contributions, and what the rationale behind withdrawals was. By analyzing the commit data of 18 versions of OpenStack, we find that the number of companies that have left is increasing and even surpasses the number of companies that have joined in later versions. Approximately 12% of the companies in each version have exited by the next version. Compared to the sustaining companies that joined in the same version, the withdrawn companies tend to have a weaker contribution intensity but contribute to a similar scope of repositories in OpenStack. Through conducting a developer survey, we find four aspects of reasons for companies’ withdrawal from OpenStack: company, community, developer, and project. The most common reasons lie in the company aspect, i.e., the company either achieved its goals or failed to do so. By fitting the survival analysis model, we find that commercial goals are associated with the probability of the company’s withdrawal, and that a company’s contribution intensity and scale are positively correlated with its retention. Maintaining good retention is important but challenging for OSS ecosystems, and our results may shed light on potential approaches to improve company retention and reduce the negative impact of company withdrawal.

A Theoretical Framework for Enhancing Open-Source Software Security

Cyber security is a rapidly developing field and open-source software (OSS) is being led by a collaborative community and a transparent nature. This research intends to make a theoretical framework highlighting the symbiosis of community engagement models, governance models, and the security of open-source ecosystems. The significant purposes aim to investigate how community engagement affects open source software development, analyze the deployment of the governance systems in widely used open source projects, and create the theoretical model that brings the cybersecurity processes in those practices. The literature survey covers existing research on open-source software development, community engagement, governance models, and cybersecurity practices within the OSS ecosystem. Through literature review the basic concepts are investigated using conceptual analysis to determine which principles and mechanisms the Community Model Engagement and Governance models operate, influencing the security of Open Source Software. Open-source project policy recommendations are the foundation for the security of communities where members fully contribute to better governance. This includes developing a fundamental conceptual analysis to lay out the framework's principles and operation (mechanisms). This contributes to the overall development of the theoretical framework. This research expects to develop a standardized theoretical framework that tackles the community engagement-governance models-security software link from new and insightful perspectives. Practical policy recommendations to protect OSS projects will be presented to solve the cybersecurity problem easily and immediately. This study aims to add to the academic and practical discussions that focus on human and organizational components' critical roles in securing open-source software. The discussion of theoretical aspects gives this platform a unique angle that fits well into the technical approach while improving the understanding of a legally open cybersecurity community

Exploring factors affecting developer abandonment of open source software projects

AbstractOpen Source Software (OSS) projects have long been studied to understand the need of community support for their growth and survival. However, there has been limited research on developers' abandonment, though it is found to have detrimental effect on quality and sustainability of OSS projects. This paper examines the impact of developer and project‐related factors on developer abandonment in OSS projects. Factors include developer attributes: experience, role, coding language, and joining date, and project attributes: change complexity and sentiments in commit logs. The findings are (1) for developer experience, core/non‐core member, and joining date; there exists a pattern of developers abandoning the projects. (2) There is no definite answer for coding language. (3) It does not relate to the change profile of a project except a few indicators. Sentiments can also not be linked. These results provide OSS community and researchers with useful insights on developer abandonment and the factors influencing it or not.

Prioritization of model smell refactoring using a covariance matrix-based adaptive evolution algorithm

The refactoring process enhances the software design by modifying the structure of design parts impaired with model smells without altering the overall software behavior. However, handling these smells without proper prioritization will not produce the anticipated effects. In this paper, we solve the prioritization of the model smell refactoring using a multi-objective optimization (MOO) algorithm called the multi-objective (MO) covariance matrix adaptation evolution strategy (MO CMA-ES). Our formulation relies on the refactoring of unified modeling language (UML) class diagrams to mitigate the negative effect of design smells. We treat the prioritization problem as a real-valued MOO where we propose novel data encoding procedures. We use two conflicting objectives, quality, and maintainability , to balance the refactoring. We first build a new solution representation that guarantees smell fixing and eliminates the rejection limitation. Furthermore, we suggest a custom mapping scheme to properly encode real-valued quantities using unique representations. For performance evaluation purposes, we developed a large custom dataset with more than 30,000 class records, using seven popular open-source software projects. A novel relative coverage metric is proposed to mitigate the limitations associated with the standard coverage. For benchmarking purposes, we also consider an improved version of the nondominated sorting genetic algorithm (NSGA-II(. The reported performance scores confirm the superiority of the MO CMA-ES algorithm over NSGA-II. The former successfully identified the refactoring sequences that lead to the best improvements in software quality and maintainability while it is able to fix all identified design smells. These improvements are quantified in terms of hypervolume, coverage, spacing metrics, and execution time. The MO CMA-ES attained the highest average maximum quality score of 1149 while keeping the average maintainability at the lowest score of 13.8. In all experiment settings, the proposed solution leads to longer refactoring sequences at no additional computational cost.

Newcomer OSS-Candidates: Characterizing Contributions of Novice Developers to GitHub

The ability of an Open Source Software (OSS) project to attract, onboard, and retain any newcomer is vital to its livelihood. Although, evidence suggests an upsurge in novice developers joining social coding platforms (such as GitHub), the extent to which their activities result in a OSS contribution is unknown. Henceforth, we execute the protocols of a registered report to study activities of a “Newcomer OSS-Candidate”, who is a novice developer that is new to that social coding platform, and has the intention to later onboard an OSS project. Using GitHub as a case platform, we analyze 171 identified Newcomer OSS-Candidates to characterize their contribution activities. Results show that Newcomer OSS-Candidates are likely to target software based repositories (i.e., 66%), and their first contributions are mainly associated with development (commits) and maintenance (PRs). Newcomer OSS-Candidates are less likely to practice social coding, but eventually end up onboarding (i.e., 30% quantitative, 70% follow-up survey) an OSS project. Furthermore, they cite finding a way to start as the most challenging barrier to contribute. Our work reveals insights on how newcomers to social coding platforms are potential sources of OSS contributions.

Quality gatekeepers: investigating the effects of code review bots on pull request activities

Software bots have been facilitating several development activities in Open Source Software (OSS) projects, including code review. However, these bots may bring unexpected impacts to group dynamics, as frequently occurs with new technology adoption. Understanding and anticipating such effects is important for planning and management. To analyze these effects, we investigate how several activity indicators change after the adoption of a code review bot. We employed a regression discontinuity design on 1,194 software projects from GitHub. We also interviewed 12 practitioners, including open-source maintainers and contributors. Our results indicate that the adoption of code review bots increases the number of monthly merged pull requests, decreases monthly non-merged pull requests, and decreases communication among developers. From the developers’ perspective, these effects are explained by the transparency and confidence the bot comments introduce, in addition to the changes in the discussion focused on pull requests. Practitioners and maintainers may leverage our results to understand, or even predict, bot effects on their projects.

Recommendation System for Open Source Projects for Minimizing Abandonment

The rise in the creation and maintenance of Open Source
 Software have facilitated the software developers to contribute
 and prevent abandonment. Software developers often
 face a daunting task to select the open source projects that remain
 active. In the absence of any resource to guide in the selection
 of the Open Source Software projects, recommendation
 systems is way to provide guidance to open source contributors.
 In this work, we describe several approaches in creation
 of recommendation systems for Open Source Software
 projects. Experiments on a synthetic data set are performed
 to evaluate the performance of the recommendation system.

Collaboration in software ecosystems: A study of work groups in open environment

As a particular type of software ecosystem, an open source software ecosystem (OSSECO) is a collection of interdependent open source software (OSS) projects which are developed and evolve together. Events happening within an OSSECO inherently involve the collaboration of participants from multiple OSS projects, forming a temporary work group. However, it is still unclear how different members of a work group collaborate to fix cross-project bugs, a typical event in the maintenance of OSSECOs. This study aims to investigate the characteristics of collaboration within a work group when fixing cross-project bugs in an OSSECO. It involves the participants from the upstream (which caused the bugs) and the downstream (which were affected by the bugs) OSS projects. We conducted our study on 236 cross-project bugs from the scientific Python ecosystem, involving 571 participants and 91 OSS projects, to understand open collaboration within a work group. We established a quantitative analysis to investigate the members of a work group, along with a qualitative analysis to understand the roles of the members from different OSS communities. The results show that: (1) A typical work group is constituted of four to eight members from the core development teams of the two OSS communities. More members concern with the upstream OSS projects and few can make active contributions to both sides; (2) Distinct responsibilities are taken by the two OSS communities, with the downstream members as the problem-finders and the upstream members as the decision-makers or gatekeepers. Our findings reveal the collaborative mechanism and the responsibility allocation between the upstream and downstream OSS communities in the ecosystems. • A study on 236 cross-project bug fixing activities to understand open collaboration in open source software ecosystems. • Six findings that reveal the members of a cross-project bug fixing work group. • Five findings that summarize the roles of cross-project bug fixing group members. • Recommendations to the researchers, developers, and practitioners.

Community, Time, and (Con)text: A Dynamical Systems Analysis of Online Communication and Community Health among Open-Source Software Communities.

Free and open‐source software projects have become essential digital infrastructure over the past decade. These projects are largely created and maintained by unpaid volunteers, presenting a potential vulnerability if the projects cannot recruit and retain new volunteers. At the same time, their development on open collaborative development platforms provides a nearly complete record of the community's interactions; this affords the opportunity to study naturally occurring language dynamics at scale and in a context with massive real‐world impact. The present work takes a dynamical systems view of language to understand the ways in which communicative context and community membership shape the emergence and impact of language use—specifically, sentiment and expressions of gratitude. We then present evidence that these language dynamics shape newcomers' likelihood of returning, although the specific impacts of different community responses are crucially modulated by the context of the newcomer's first contact with the community.

Cui Bono: Do Open Source Software Incubator Policies and Procedures Benefit the Projects or the Incubator?

Open source software (OSS), a form of Digital or Knowledge Commons, underlies much of the technology that we use in our daily lives. The existence and continuation of OSS relies on the contribution of private resources – personal time, volunteer energy, and effort of numerous actors (e.g., software developers’ time as a common-pool resource) – to public goods, the benefits of which are enjoyed by everyone. Nonprofit organizations such as the Apache Software Foundation (ASF) attempt to aid this process by providing various collective services to OSS projects, acting as a second-order actor in the production of the public good. To this end, the ASF Incubator has created policies – essentially rules or norms – that serve to protect its interests and, as they say, increase the sustainability of the projects. Each policy requires investment by ASF (in terms of money or the use of volunteer time) or an incubating project (in terms of taking project personnel time), the benefits of which can accrue to either party. Such policies may impose additional costs on incubating projects, leading to a decreased production of the OSS public good. Using the ASF Incubator policy documents, we construct a dataset that records who – ASF or an incubating project – bears the cost and who enjoys the benefit of each policy and procedure. We can code most policy statements as costing one party and benefiting one party. The distribution of costs and benefits according to party indicates whether the second-order actor is contributing to an increase in the public good and if they are doing so sustainably. Through a two-way ANOVA, we characterize the impact of ASF policies on the production of public goods (OSS). Being a part of ASF imposes some costs on projects, but these costs may make projects more sustainable. Our analysis shows that the distribution of costs and benefits is fairly symmetric between the ASF and incubating projects. Thus, the configuration of policies or the “institutional design” of the ASF could aid in producing the OSS public good by providing services that projects require.

Social-technical network effects in open source software communities: understanding the impacts of dependency networks on project success

Purpose To better understand the success of an open source software (OSS) project, this study aims to examine the role of social dependency networks (i.e. social and technical dependencies) in online communities.Design/methodology/approach This study focuses on dependencies using three network metrics – degree centrality, betweenness centrality and closeness centrality – in developer and module networks. A longitudinal analysis from the projects hosted at Sourceforge.net is conducted to examine the effects of social and technical networks on the success of OSS projects. To address our research questions, we have constructed research models to investigate the social network effects in developer networks, the technical network effects in module networks, and the social-technical network effects in both types of networks.Findings The results reveal nonlinear relationships between degree centrality in both social and technical networks and OSS success, highlighting the importance of a moderate level of degree centrality in team structure and software architecture. Meanwhile, a moderate level of betweenness centrality and a lower level of closeness centrality between developers lead to a higher chance of OSS project success.Originality/value This study is the first attempt to consider the network metrics in both module networks of the technical sub-system and developer networks of the social sub-system to better understand their influences on project success.

Mining GitHub to Identify Open-Source Software Health in Blockchain Projects

GitHub represents the largest open-source software (OSS) community hosting over 100 million repositories by 56 million developers. Since the rise of Bitcoin [1], blockchain projects have grown dramatically and 84% of the top 200 are hosted on GitHub. Growth inspires many new initiatives and clones, but few projects survive. Identifying healthy projects can assist developers looking to contribute to OSS and researchers seeking innovative teams in addition to reducing fraudulent activity. This presentation is part of a larger ongoing study investigating OSS blockchain performance and health. The hypothesis to be studied is that the health of an OSS project can be determined through publicly available data. This will be investigated by answering the research question: How can factors that influence the health of OSS be identified? The methodology is adapted from a framework for extracting, processing, and analysing OSS [2] that combines eleven variables into a measurement model. Latent variables are introduced to represent the constructs of community engagement, project robustness, and public interest. Statistical analysis methods are employed both for the development and specification of the measurement model and the construction and evaluation of its structural efficacy. Validation is by two mechanisms: confirmatory factor analysis applied to the measurement model and structural equation modelling to estimate the validity of the relationships [3]. In the broader study a tool is to be developed to monitor health and highlight areas for innovation. Preliminary findings indicate that community engagement and project interest are positively correlated to robustness, which, in turn, is expected to be a predictor of software project health. A future hypothesis is that healthy projects can be a leading indicator of innovative technology and practice. If OSS communities and projects can be monitored for health, stake holders can identify areas of strength and weakness, extending to industries beyond blockchain.

PAMGuard: Open-source detection, classification, and Localization software

The PAMGuard open-source software project was established in 2006 to provide a toolbox and app for the detection, classification, and localization (DCL) of bioacoustic signals. Releases typically attract between 1500 and 3500 downloads. Primarily developed for marine mammals, users can configure PAMGuard to work with a wide variety of hardware configurations (single hydrophones, to complex 3D arrays) and DCL algorithms, depending on the species of interest. A Java code base and integrated multi-threading allow multiple DCL algorithms to be run in parallel enabling rapid analysis of large acoustic datasets. A comprehensive data management system and a suite of interactive displays then allow users to visualize and annotate resulting data at temporal scales from milliseconds to years. This combination of advanced analysis algorithms and powerful data visualization in both real-time, or reviewing data post-hoc, means PAMGuard provides both automatic and a proven and reliable human-in-the-loop approach to analysis. Developers can use the program’s infrastructure to rapidly develop and deploy new algorithms; recently, an international collaboration has improved support for terrestrial species and developed a new module to import acoustic deep learning models, enabling users to take advantage of PAMGuard’s data management and visualization capabilities alongside the latest automated acoustic classifiers.

A Review Paper on Big Data and Hadoop is solution for Big Data

The amount of data produced and communicated over Internet is significantly increased. The formation of this massive amount of data through divergent source is massive. Now days a Big Data application where data collection has grown very fast and traditional software tools are unable to capture, manage, and process it. In this paper we are highlighting Big Data its sources and types such as structured, unstructured and semi structured. Data is generated from various different sources and can arrive in the system at various rates. In order to process these large amounts of data in an inexpensive and efficient way, parallelism is used. Big Data is a data whose scale, diversity, and complexity require new architecture to manage it and extract value and hidden knowledge from it. Hadoop is an open source software project that enables the distributed processing of large data sets across clusters of commodity servers. It is designed to scale up from a single server to thousands of machines, with a very high degree of fault tolerance.

Will you come back to contribute? Investigating the inactivity of OSS core developers in GitHub

Several Open-Source Software (OSS) projects depend on the continuity of their development communities to remain sustainable. Understanding how developers become inactive or why they take breaks can help communities prevent abandonment and incentivize developers to come back. In this paper, we propose a novel method to identify developers’ inactive periods by analyzing the individual rhythm of contributions to the projects. Using this method, we quantitatively analyze the inactivity of core developers in 18 OSS organizations hosted on GitHub. We also survey core developers to receive their feedback about the identified breaks and transitions. Our results show that our method was effective for identifying developers’ breaks. About 94% of the surveyed core developers agreed with our state model of inactivity; 71% and 79% of them acknowledged their breaks and state transition, respectively. We also show that all core developers take breaks (at least once) and about a half of them (~45%) have completely disengaged from a project for at least one year. We also analyzed the probability of transitions to/from inactivity and found that developers who pause their activity have a ~35 to ~55% chance to return to an active state; yet, if the break lasts for a year or longer, then the probability of resuming activities drops to ~21–26%, with a ~54% chance of complete disengagement. These results may support the creation of policies and mechanisms to make OSS community managers aware of breaks and potential project abandonment.

Leveraging structural properties of source code graphs for just-in-time bug prediction

The most common use of data visualization is to minimize the complexity for proper understanding. A graph is one of the most commonly used representations for understanding relational data. It produces a simplified representation of data that is challenging to comprehend if kept in a textual format. In this study, we propose a methodology to utilize the relational properties of source code in the form of a graph to identify Just-in-Time (JIT) bug prediction in software systems during different revisions of software evolution and maintenance. We presented a method to convert the source codes of commit patches to equivalent graph representations and named it Source Code Graph (SCG). To understand and compare multiple source code graphs, we extracted several structural properties of these .graphs, such as the density, number of cycles, nodes, edges, etc. We then utilized the attribute values of those SCGs to visualize and detect buggy software commits. We process more than 246 K software commits from 12 subject systems in this investigation. Our investigation on these 12 open-source software projects written in C++ and Java programming languages shows that if we combine the features from SCG with conventional features used in similar studies, we will get the increased performance of Machine Learning (ML) based buggy commit detection models. We also find the increase of F1 Scores in predicting buggy and non-buggy commits statistically significant using the Wilcoxon Signed Rank Test. Since SCG-based feature values represent the style or structural properties of source code updates or changes in the software system, it suggests the importance of careful maintenance of source code style or structure for keeping a software system bug-free.

Software Bug Number Prediction Based on Complex Network Theory and Panel Data Model

Accurate software bug number prediction makes software test resource allocation, maintenance, and release time cost efficient. However, it is a challenge to accurately predict the number of software bugs when there fluctuations caused by many uncertain factors faced by the complex software. Considering this, a new method for software bug number prediction based on a panel data model from the perspective of complex networks is proposed in this article. Using complex network theory, we constructed the software code network and calculated the static metrics of the network structure, and the percolation threshold of change in the network structure based on percolation theory as a dynamic metric. These network metrics were then normalized as inputs and a panel data model was used for bug prediction. The proposed method can predict the number of bugs for both within-project and cross-project. Empirical studies were performed on data obtained from 120 releases of eight open-source software projects (Lua, SQLite, Redis, Linux kernel, ant, jmeter, poi, and tomcat), the experimental results indicated that network metrics are effective bug indicators, and the proposed method outperformed ten baseline methods (with an average improvement of 28.05%). This article is expected to provide insights into more smart software quality and reliability assurance.

Exploring factors and metrics to select open source software components for integration: An empirical study

Context:Open Source Software (OSS) is nowadays used and integrated in most of the commercial products. However, the selection of OSS projects for integration is not a simple process, mainly due to a of lack of clear selection models and lack of information from the OSS portals. Objective:We investigate the factors and metrics that practitioners currently consider when selecting OSS. We also investigate the source of information and portals that can be used to assess the factors, as well as the possibility to automatically extract such information with APIs. Method:We elicited the factors and the metrics adopted to assess and compare OSS performing a survey among 23 experienced developers who often integrate OSS in the software they develop. Moreover, we investigated the APIs of the portals adopted to assess OSS extracting information for the most starred 100K projects in GitHub. Result:We identified a set consisting of 8 main factors and 74 sub-factors, together with 170 related metrics that companies can use to select OSS to be integrated in their software projects. Unexpectedly, only a small part of the factors can be evaluated automatically, and out of 170 metrics, only 40 are available, of which only 22 returned information for all the 100K projects. Therefore, we recommend project maintainers and project repositories to pay attention to provide information for the project they are hosting, so as to increase the likelihood of being adopted. Conclusion:OSS selection can be partially automated, by extracting the information needed for the selection from portal APIs. OSS producers can benefit from our results by checking if they are providing all the information commonly required by potential adopters. Developers can benefit from our results, using the list of factors we selected as a checklist during the selection of OSS, or using the APIs we developed to automatically extract the data from OSS projects.