As collaborative coding environments make it easier to contribute to software projects, the number of developers involved in these projects keeps increasing. Consequently, making it more difficult for code reviewers to deal with harmful contributions. Collaborative environments like GitHub provide a rich source of data on developers' contribution, which can be used to extract information on technical (e.g., developers' experience) and social (e.g., interactions among developers) factors related to developers. Recent studies analyzed the influence of these factors on different activities of the software development. However, there is still little knowledge on the relation between these factors and the introduction of bugs. We present a broader study on relating five technical, two social factors and the introduction of bugs. The results indicate that both technical and social factors present statistically significant relations with the introduction of bugs. Particularly, the developers' habits of not following technical contribution norms are associated with an increase on commit bugginess. Unexpectedly, the presence of tests in commits presents a relation with the increase of commit bugginess. Finally, the developer's experience presents a contradictory relation with the introduction of bugs. But, the analysis of both code complexity and developer's experience may explain this contradiction.
Rahman & Devanbu analyzed four open-source projects and found that high levels of ownership are associated with a lower bug introduction rate. Moreover, the authors found that specialized experience is consistently associated with buggy code, while general experience is not. Similar findings on the ownership factor were presented in the work of Bird @cite_21 . Thongtanunam @cite_7 show that there is a relationship between ownership and code review. In addition, the proportion of reviewers without expertise shares a strong relation with commit bugginess. Tufano @cite_28 presented an empirical study on developer-related factors. Their results show that commit coherence, developer experience, and past interfering changes are associated with commit bugginess.
@cite_28 @cite_21 @cite_7
2374812233 2143177027 2145574830 2047988765
Code ownership establishes a chain of responsibility for modules in large software systems. Although prior work uncovers a link between code ownership heuristics and software quality, these heuristics rely solely on the authorship of code changes. In addition to authoring code changes, developers also make important contributions to a module by reviewing code changes. Indeed, recent work shows that reviewers are highly active in modern code review processes, often suggesting alternative solutions or providing updates to the code changes. In this paper, we complement traditional code ownership heuristics using code review activity. Through a case study of six releases of the large Qt and OpenStack systems, we find that: (1) 67 --86 of developers did not author any code changes for a module, but still actively contributed by reviewing 21 --39 of the code changes, (2) code ownership heuristics that are aware of reviewing activity share a relationship with software quality, and (3) the proportion of reviewers without expertise shares a strong, increasing relationship with the likelihood of having post-release defects. Our results suggest that reviewing activity captures an important aspect of code ownership, and should be included in approximations of it in future studies. In a traditional sense, ownership determines rights and duties in regard to an object, for example a property. The owner of source code usually refers to the person that invented the code. However, larger code artifacts, such as files, are usually composed by multiple engineers contributing to the entity over time through a series of changes. Frequently, the person with the highest contribution, e.g. the most number of code changes, is defined as the code owner and takes responsibility for it. Thus, code ownership relates to the knowledge engineers have about code. Lacking responsibility and knowledge about code can reduce code quality. In an earlier study, [1] showed that Windows binaries that lacked clear code ownership were more likely to be defect prone. However recommendations for large artifacts such as binaries are usually not actionable. E.g. changing the concept of binaries and refactoring them to ensure strong ownership would violate system architecture principles. A recent replication study by [2] on open source software replicate the original results and lead to doubts about the general concept of ownership impacting code quality. In this paper, we replicated and extended the previous two ownership studies [1, 2] and reflect on their findings. Further, we define several new ownership metrics to investigate the dependency between ownership and code quality on file and directory level for 4 major Microsoft products. The results confirm the original findings by [1] that code ownership correlates with code quality. Using new and refined code ownership metrics we were able to classify source files that contained at least one bug with a median precision of 0.74 and a median recall of 0.38. On directory level, we achieve a precision of 0.76 and a recall of 0.60. Ownership is a key aspect of large-scale software development. We examine the relationship between different ownership measures and software failures in two large software projects: Windows Vista and Windows 7. We find that in all cases, measures of ownership such as the number of low-expertise developers, and the proportion of ownership for the top owner have a relationship with both pre-release faults and post-release failures. We also empirically identify reasons that low-expertise developers make changes to components and show that the removal of low-expertise contributions dramatically decreases the performance of contribution based defect prediction. Finally we provide recommendations for source code change policies and utilization of resources such as code inspections based on our results. One of the perceived values of open source software is the idea that many eyes can increase code quality and reduce the amount of bugs. This perception, however, has been questioned by some due the lack of supporting evidence. This paper presents an empirical analysis focusing on the relationship between the utilization of open source components and their engineering quality. In this study, we determine the popularity of 2,406 Maven components by calculating their usage across 55,191 open source Java projects. As a proxy of code quality for a component, we calculate (i) its defect density using the set of bug patterns reported by Find Bugs, and (ii) 9 popular software quality metrics from the SQO-OSS quality model. We then look for correlations between (i) popularity and defect density, and (ii) popularity and software quality metrics. In most of the cases, no correlations were found. In cases where minor correlations exist, they are driven by component size. Statistically speaking, and using the methods in this study, the Maven repository does not seem to support the "many eyeballs" effect. We conjecture that the utilization of open source components is driven by factors other than their engineering quality, an interpretation that is supported by the findings in this study.