You are presented with multiple paper abstracts, alongside the associated literature review and chapter titles. Given the provided information, you are going to do a literature review. Please generate a coherent literature review that synthesizes the content, draws connections between different works, highlights major findings, and identifies any gaps in the existing research.

Literature Review Title: On Using Network Science in Mining Developers Collaboration in Software Engineering: A Systematic Literature Review 
Chapter Title:  Data, results, and interpretation (Feature C) 
1. Abstract of Cited Paper (BIB001):  Commercial software project managers design project organizational structure carefully, mindful of available skills, division of labour, geographical boundaries, etc. These organizational "cathedrals" are to be contrasted with the "bazaar-like" nature of Open Source Software (OSS) Projects, which have no pre-designed organizational structure. Any structure that exists is dynamic, self-organizing, latent, and usually not explicitly stated. Still, in large, complex, successful, OSS projects, we do expect that subcommunities will form spontaneously within the developer teams. Studying these subcommunities, and their behavior can shed light on how successful OSS projects self-organize. This phenomenon could well hold important lessons for how commercial software teams might be organized. Building on known well-established techniques for detecting community structure in complex networks, we extract and study latent subcommunities from the email social network of several projects: Apache HTTPD, Python, PostgresSQL, Perl, and Apache ANT. We then validate them with software development activity history. Our results show that subcommunities do indeed spontaneously arise within these projects as the projects evolve. These subcommunities manifest most strongly in technical discussions, and are significantly connected with collaboration behaviour. 
2. Abstract of Cited Paper (BIB002):  Studies have shown that social factors in development organizations have adramatic effect on software quality. Separately, program dependencyinformation has also been used successfully to predict which software componentsare more fault prone. Interestingly, the influence of these two phenomena haveonly been studied separately. Intuition and practical experience suggests,however, that task assignment (i.e. who worked on which components and howmuch) and dependency structure (which components have dependencies on others)together interact to influence the quality of the resulting software. Westudy the influence of combined socio-technical software networks onthe fault-proneness of individual software components within a system. Thenetwork properties of a software component in this combined network are ableto predict if an entity is failure prone with greater accuracy than priormethods which use dependency or contribution information in isolation. Weevaluate our approach in different settings by using it on Windows Vista andacross six releases of the Eclipse development environment including usingmodels built from one release to predict failure prone components in the nextrelease. We compare this to previous work. In every case, our method performsas well or better and is able to more accurately identify those softwarecomponents that have more post-release failures, with precision and recallrates as high as 85%. 
3. Abstract of Cited Paper (BIB003):  A critical factor in work group coordination, communication has been studied extensively. Yet, we are missing objective evidence of the relationship between successful coordination outcome and communication structures. Using data from IBM's Jazz™ project, we study communication structures of development teams with high coordination needs. We conceptualize coordination outcome by the result of their code integration build processes (successful or failed) and study team communication structures with social network measures. Our results indicate that developer communication plays an important role in the quality of software integrations. Although we found that no individual measure could indicate whether a build will fail or succeed, we leveraged the combination of communication structure measures into a predictive model that indicates whether an integration will fail. When used for five project teams, our predictive model yielded recall values between 55% and 75%, and precision values between 50% to 76%. 
4. Abstract of Cited Paper (BIB004):  Members of software project teams have specific roles and responsibilities which are formally defined during project inception or at the start of a life cycle activity. Often, the team structure undergoes spontaneous changes as delivery deadlines draw near and critical tasks have to be completed. Some members -- depending on their skill or seniority -- need to take on more responsibilities, while others end up being peripheral to the project's execution. We posit that this kind of ad hoc reorganization of a team's structure can be discerned from the project's bug tracker. In this paper, we extract a social network from the bug log of a real life software system and apply ideas from social network analysis to understand how the positions of individual team members in the network relate to their organizational seniority, project roles, and geographic locations that define the formal team structure. In addition to providing insights on individual team members for the system studied, our approach can serve as a framework for analyzing team dynamics of software projects. 
5. Abstract of Cited Paper (BIB005):  Correcting software defects accounts for a significant amount of resources such as time, money and personnel. To be able to focus testing efforts where needed the most, researchers have studied statistical models to predict in which parts of a software future defects are likely to occur. By studying the mathematical relations between predictor variables used in these models, researchers can form an increased understanding of the important connections between development activities and software quality. Predictor variables used in past top-performing models are largely based on file-oriented measures, such as source code and churn metrics. However, source code is the end product of numerous interlaced and collaborative activities carried out by developers. Traces of such activities can be found in the repositories used to manage development efforts. In this paper, we investigate statistical models, to study the impact of social structures between developers and end-users on software quality. These models use predictor variables based on social information mined from the issue tracking and version control repositories of a large open-source software project. The results of our case study are promising and indicate that statistical models based on social information have a similar degree of explanatory power as traditional models. Furthermore, our findings suggest that social information does not substitute, but rather augments traditional product and process-based metrics used in defect prediction models. 
6. Abstract of Cited Paper (BIB006):  This paper analyses the behaviour of virtual communities for Open Source Software (OSS) projects. The development of OSS projects relies on virtual communities, which are built on relationships among members, being their final objective sharing knowledge and improving the underlying project. This study addresses the interactive collaboration in these kinds of communities applying social network analysis (SNA). In particular, SNA techniques will be used to identify those members playing a middle-man role among other community members. Results will illustrate the importance of this role to achieve successful virtual communities. 
7. Abstract of Cited Paper (BIB007):  Social network analysis has many applications in software engineering and is often performed through the use of visualizations. Discovery of these networks, however, presents a challenge since the relationships are initially not known. We present an approach for mining and visualizing networks of software developers from version control systems. It computes similarities among developers based on common file changes, constructs the network of collaborating developers and applies filtering techniques to improve the modularity of the network. We validate the approach on two projects from industry and demonstrate its use in a case study of an open-source project. Results indicate that the approach performs well in revealing the structure of development teams and improving the modularity in visualizations of developer networks. 
8. Abstract of Cited Paper (BIB008):  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. 
9. Abstract of Cited Paper (BIB009):  Cross-system bug fixing propagation is frequent among systems having similar characteristics, using a common framework, or, in general, systems with cloned source code fragments. While previous studies showed that clones tend to be properly maintained within a single system, very little is known about cross-system bug management. This paper describes an approach to mine explicitly documented cross-system bug fixings, and to relate their occurrences to social characteristics of contributors discussing through the project mailing lists--e.g., degree, betweenness, and brokerage--as well as to the contributors' activity on source code. The paper reports results of an empirical study carried out on FreeBSD and OpenBSD kernels. The study shows that the phenomenon of cross-system bug fixing between these two projects occurs often, despite the limited overlap of contributors. The study also shows that cross-system bug fixings mainly involve contributors with the highest degree, betweenness and brokerage level, as well as contributors that change the source code more than others. 
10. Abstract of Cited Paper (BIB010):  Developer teams may naturally emerge independent of managerial decisions, organizational structure, or work locations in large software. Such self organized collaboration teams of developers can be traced from the source code repositories. In this paper, we identify the developer teams in the collaboration network in order to present the work team evolution and the factors that affect team stability for a large, globally developed, commercial software. Our findings indicate that: a) Number of collaboration teams do not change over time, b) Size of the collaboration teams increases over time, c) Team activity is not related with team size, d) Factors related to team size, location and activity affect the stability of teams over time. 
11. Abstract of Cited Paper (BIB011):  Developers contributing to open source projects spontaneously group into "emerging'' teams, reflected by messages exchanged over mailing lists, issue trackers and other communication means. Previous studies suggested that such teams somewhat mirror the software modularity. This paper empirically investigates how, when a project evolves, emerging teams re-organize themselves-e.g., by splitting or merging. We relate the evolution of teams to the files they change, to investigate whether teams split to work on cohesive groups of files. Results of this study-conducted on the evolution history of four open source projects, namely Apache httpd, Eclipse JDT, Netbeans, and Samba-provide indications of what happens in the project when teams reorganize. Specifically, we found that emerging team splits imply working on more cohesive groups of files and emerging team merges imply working on groups of files that are cohesive from structural perspective. Such indications serve to better understand the evolution of software projects. More important, the observation of how emerging teams change can serve to suggest software remodularization actions.

Literature Review:
The used data set in the PSs was distributed as follows: (1) 6 PSs used data from industry, (2) 27 PSs used data from open source platforms, and (3) 2 PSs, BIB003 BIB008 , used both industry and open source data in the experiments. From the open source project, the projects Mozilla, Apache, Eclipse, and Linux were used much often. For the industry projects, the MS-Vista binaries were used 2 times by the same author in BIB009 BIB001 . The MS-Vista binaries was used also in addition to an open source project (i.e., the Eclipse) in the work BIB003 . Two PSs did not provide information about the used industrial data BIB005 BIB011 . The projects Eclipse, Firefox, and Apache were used the most in the PSs with frequencies 7, 6, and 4 times, respectively. The answer to feature "C3" found as follows. Only 34% of the PSs, 12 PSs, provided an Explicit interpretation of the results in the context of the studied context of SE, feature "A2". Other 14 studies provided Implicit interpretation of the results, which means it was not clear in the primary study how the context in "A2" was related to the results directly. The rest of the results, 9 PSs, did not provide any information about connecting the results to feature "A2". The PSs that provided Explicit lessons and guidelines for the practitioners based on the results of the study were 5 studies only, BIB004 BIB001 BIB012 BIB009 BIB002 . Also, 4 studies  BIB010 BIB006 BIB007 provided Implicit lessons and guidelines for the practitioners, and the rest did not provide any information.