Developer initiation and social interactions in OSS: A case study of the Apache Software Foundation

Abstract

Maintaining a productive and collaborative team of developers is essential to Open Source Software (OSS) success, and hinges upon the trust inherent among the team. Whether a project participant is initiated as a committer is a function of both his technical contributions and also his social interactions with other project participants. One's online social footprint is arguably easier to ascertain and gather than one's technical contributions e.g., gathering patch submission information requires mining multiple sources with different formats, and then merging the aliases from these sources. In contrast to prior work, where patch submission was found to be an essential ingredient to achieving committer status, here we investigate the extent to which the likelihood of achieving that status can be modeled solely as a social network phenomenon. For 6 different Apache Software Foundation OSS projects we compile and integrate a set of social measures of the communications network among OSS project participants and a set of technical measures, i.e., OSS developers' patch submission activities. We use these sets to predict whether a project participant will become a committer, and to characterize their socialization patterns around the time of becoming committer. We find that the social network metrics, in particular the amount of two-way communication a person participates in, are more significant predictors of one's likelihood Empir Software Eng to becoming a committer. Further, we find that this is true to the extent that other predictors, e.g., patch submission info, need not be included in the models. In addition, we show that future committers are easy to identify with great fidelity when using the first three months of data of their social activities. Moreover, only the first month of their social links are a very useful predictor, coming within 10 % of the three month data's predictions. Interestingly, we find that on average, for each project, one's level of socialization ramps up before the time of becoming a committer. After obtaining committer status, their social behavior is more individualized, falling into few distinct modes of behavior. In a significant number of projects, immediately after the initiation there is a notable social cooling-off period. Finally, we find that it is easier to become a committer earlier in the projects life cycle than it is later as the project matures. These results should provide insight on the social nature of gaining trust and advancing in status in distributed projects.

Determinants of pull-based development in the context of continuous integration

“…Instead, anyone can create forks (i.e., local clones of the central repository), update them locally and, whenever ready, request to have their changes merged back into the main branch by submitting a pull-request. Compared to traditional collaboration development models in open source [7,8] (e.g., patch submission and acceptance via mailing lists or bugzilla), the pullbased model offers great advantages in terms of process automation. Nowadays, the modern collaborative coding platforms, e.g., GitHub, BitBucket, Gitorius, provide integrated functionality for pull-request generation, notification, in-line code review, contextual discussion, automatic testing, and merger.…”

A Data Set for Social Diversity Studies of GitHub Teams

“…We believe OSS to be a great source of data for studies of team social diversity, since: (i) software development is inherently a collaborative and human-centric activity; (ii) OSS is as much social as it is technical [9]- [12]; (iii) the selforganized, geographically-distributed, online nature of OSS leads to teams that are quite diverse, consisting of both professionals and volunteers, with varied personalities, educational and cultural backgrounds, age, gender, and expertise; (iv) OSS teams are real-world teams that form, evolve, and dissolve organically; generate measurable artifacts (e.g., source code); and leave publicly-available traces of their activities.…”

Understanding the Heterogeneity of Contributors in Bug Bounty Programs

“…"Onion" refers to the successive layers of member types from core members, contributing developers, bug reporters, and users, for example. In the onion models, advancement through the member types is reward and recognition for each member's abilities and achievements [17], and developer initiation in OSS depends on the social and technical actions of project contributors [18]. Therefore, newcomers must first become familiar with the code base, architecture, build environment, and work practices, which might take days or weeks [5].…”