The focus of this paper is to review what is known about free and open source software development (FOSSD) work practices, development processes, project and community dynamics, and other socio-technical relationships. It focuses on exploring how FOSS is developed and evolved based on an extensive review of a set of empirical studies of FOSSD projects that articulate different levels of analysis. These characterize what has been analyzed in FOSSD studies across levels that examine (i) why individuals participate; (ii) resources and capabilities supporting development activities; (iii) how cooperation, coordination, and control are realized in projects; (iv) alliance formation and inter-project social networking; (v) FOSS as a multi-project software ecosystem, and (vi) FOSS as a social movement. Next, there is a discussion of limitations and constraints in the FOSSD studies so far. Last, attention shifts to identifying emerging opportunities for future FOSSD studies that can give rise to the development of new software engineering tools or techniques, as well as to new empirical studies of software development.

Successful online communities have complex cooperative arrangements, articulations of work, and integration practices. They require technical infrastructure to support a broad division of labor. Yet the research literature lacks empirical studies that detail which types of work are valued by participants in an online community. A content analysis of Wikipedia barnstars – personalized tokens of appreciation given to participants – reveals a wide range of valued work extending far beyond simple editing to include social support, administrative actions, and types of articulation work. Our analysis develops a theoretical lens for understanding how wiki software supports the creation of articulations of work. We give implications of our results for communities engaged in large-scale collaborations.

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 “bazaarlike” 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. However, in large, complex, successful, OSS projects, we expect that sub-communities will form organically within the “bazaar ” of developer teams. Studying these sub-communities, and their behavior can shed light on how successful OSS projects self-organize. This phenomenon could even hold important lessons for how commercial software teams might be organized. Building on wellestablished techniques for detecting community structure in complex networks, we extract and evaluate 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 form within these projects. We find, in other words, that “chapels ” (if not cathedrals) spontaneously arise within the bazaar as OSS systems and the teams evolve. We also find that these subgroups manifest most strongly in technical discussions, and are significantly connected with collaboration behaviour. 1.

Software development has traditionally been regarded as an activity that can only be effectively conducted and managed within a firm setting. However, contrary to such assertions, the open source software development (OSSD) approach, in which software developers in digital social networks coordinate to voluntarily contribute programming code, has recently emerged as a promising alternative. Although many high profile cases of successful OSSD projects exist, the harsh reality is that the vast majority of OSS projects fail to take off and become abandoned. A commonly cited reason for the failure of OSS projects is the inability of the software project to bring together a critical mass of developers. This paper empirically examines the role of prior collaborative ties on how OSSD project teams are formed. Using software project data from real world OSSD projects, we find that the existence and the amount of prior collaborative relations in the developer network do increase the probability that an OSS project will attract more developers and that a developer’s prior relationships with a project initiator do increase the likelihood that a developer will join a project initiated by a past collaborator. We also explore the performance implications of early team formation behaviors.

Abstract not found

This paper presents a model of the behavior of candidates for promotion to administrator status in Wikipedia. It uses a policy capture framework to highlight similarities and differences in the community’s stated criteria for promotion decisions to those criteria actually correlated with promotion success. As promotions are determined by the consensus of dozens of voters with conflicting opinions and unwritten expectations, the results highlight the degree to which consensus is truly reached. The model is fast and easily computable on the fly, and thus could be applied as a self-evaluation tool for editors considering becoming administrators, as a dashboard for voters to view a nominee’s relevant statistics, or as a tool to automatically search for likely future administrators. Implications for distributed consensus-building in online communities are discussed. Author Keywords Wikipedia, administrators, management, collaboration,

While there is a considerable amount of research on analyzing the change information stored in software repositories, only few researcher have looked at software changes contained in email archives in form of patches. In this paper we look at the email archives of two open source projects and answer questions like the following: How many emails contain patches? How long does it take for a patch to be accepted? Does the size of the patch influence its chances to be accepted or the duration until it gets accepted? Obviously, the answers to these questions can be helpful for the authors of patches, in particular because some of the answers are surprising. Categories and Subject Descriptors D.2.7 [Software Engineering]: Distribution, Maintenance,

Open source software is built by teams of volunteers. Each project has a core team of developers, who have the authority to commit changes to the repository; this team is the elite, committed foundation of the project, selected through a meritocratic process from a larger number of people who participate on the mailing list. Most projects carefully regulate admission of outsiders to full developer privileges; some projects even have formal descriptions of this process. Understanding the factors that influence the “who, how and when ” of this process is critical, both for the sustainability of FLOSS projects, and for outside stakeholders who want to gain entry and succeed. In this paper we mount a quantitative case study of the process by which people join FLOSS projects, using data mined from the Apache web server, Postgres, and Python. We develop a theory of open source project joining, and evaluate this theory based on our data. 1

Social network-based systems usually suffer from two major limitations: they tend to rely on a single data source (e.g. email traffic), and the form of network patterns is often privileged over their content. To go beyond these limitations we describe a system we developed to visualize and navigate hybrid networks constructed from multiple data sources – with a direct link between formal representations and the raw content. We illustrate the benefits of our approach by analyzing patterns of collaboration in a large Open Source project, using hybrid networks to uncover important roles that would otherwise have been missed. Author Keywords Online communities, social networks, natural language processing, visualization. ACM Classification Keywords H5.m. Information interfaces and presentation (e.g., HCI):

Abstract. We present CodeSaw, a social visualization of distributed software development. CodeSaw visualizes a distributed software community from two important and independent perspectives: code repositories and project communication. By bringing together both shared artifacts (code) and the talk surrounding those artifacts (project mail), CodeSaw reveals group dynamics that lie buried in existing technologies. This paper describes the visualization and its design process. We apply CodeSaw to a popular open source project, showing how the visualization reveals group dynamics and individual roles. The paper ends with a discussion of the results of an online field study with prominent open source developers. The field study suggests that CodeSaw positively affects communities and provides incentives to distributed developers. Furthermore, an important design lesson from the field study leads us to introduce a novel interaction technique for social visualization called spatial messaging. 1