Contributions, Collaborations, and Transitions: Paid and Volunteer Developers in the Rust Community

The success of open source software (OSS) projects relies on voluntary contributions from various community roles. Among these roles, being a committer signifies gaining trust and higher privileges in OSS projects. Substantial studies have focused on the requirements of becoming a committer in OSS projects, but most of them are based on interviews or several hypotheses, lacking a comprehensive understanding of committers' qualifications. To address this knowledge gap, we explore both the policies and practical implementations of committer qualifications in modern top OSS communities. Through a thematic analysis of these policies, we construct a taxonomy of committer qualifications, consisting of 26 codes categorized into nine themes, including "Personnel-related to Project", "Communication", and "Long-term Participation". We also highlight the variations in committer qualifications emphasized in different OSS community governance models. For example, projects following the "core maintainer model" place great importance on project comprehension, while projects following the "company-backed model" place significant emphasis on user issue resolution. Based on the above findings, we propose eight sets of metrics and perform survival analysis on two representative OSS projects to understand how these qualifications are implemented in practice. We find that the probability of gaining commit rights decreases as participation time passes. The selection criteria in practice are generally consistent with the community policies. Developers who submit high-quality code, actively engage in code review, and make extensive contributions to related projects are more likely to be granted commit rights. However, there are some qualifications that do not align precisely, and some are not adequately evaluated. This study enhances trust understanding in top OSS communities, aids in optimal commit rights allocation, and empowers developers' self-actualization via OSS engagement.

This panel will present several experiences in involving students in Open Source Software (OSS) projects from the perspectives of both the instructor and a member of the OSS community. OSS is growing rapidly and gaining market share in both industry (e.g., Linux and Mozilla) as well as academia (e.g, Moodle, Greenfoot, and Drupal). OSS projects have a culture built on volunteer participation to support software development. Computing degree programs desire to involve students in large-scale software projects to provide students with real-world experience and an understanding of the issues found in large, complex software projects. Involving computing students in OSS projects serves both the OSS community by providing development resources for the project while also serving the academic community by providing access to large software projects in which students can gain experience. However, the marriage of student and OSS project presents some challenges including identification of approachable OSS projects, creation of appropriate educational infrastructure, evaluation and grading, and more. Panelists will address the factors that contribute to student success in an OSS project.

Abstract— Open source software represents a new paradigm of software development based on a subjacent community. It is widely accepted in the literature the layered structure of open source communities, being the core group the most active contributors usually located at the center of the community. The tasks of this group include not only an intense activity in terms of contributions but also to promote participation among the rest of the community members. In this paper, the general role of this group is analyzed by modeling communities as Social Networks and applying Social Network Analysis techniques. Findings related their brokerage activity with open source software success. Keywords-wireless Open source communities; Virtual communities; Social Network Analysis; brokerage role. I. I NTRODUCTION Open Source Software (OSS) projects constitute a prominent example of software development based on communities [1]. They are supported by a community of developers and users who work in geographically distributed locations, rarely or never meet face to face, and coordinate their activities making an intense use of Internet. The wide success of several well known Open Source Software (OSS) projects has attracted much attention. Software engineering researchers and commercial companies alike have been trying to learn lessons from the success of OSS and apply some of them to the development of proprietary software [2]. However, there is a cruel reality that the vast majority of OSS projects fail to take off and soon become abandoned [3]. According to the popular open source portal, SourceForge (http://sourceforge.net/), most OSS projects have ended in failure: 58% do not move beyond the alpha developmental stage, 22% remain in the planning phase, 17% remain in the pre-alpha phase, and some become inactive [4]. Previous studies on OSS have been mainly focused on motivation of people participating in subjacent virtual communities. Motivations have been found to range from problem solving [5] [6], to reputation benefits and career opportunities [7] [8] [9]. But a more reduced amount of work has been focused on communities’ structure. It has been demonstrated that much of the OSS development is realized by a small percentage of individuals despite the fact that there are tens of thousands of available developers. Such concentration is called “participation inequality” [10], [11], and it can be explained by the different user profiles of open source communities. Consequently, the structure of OSS communities is not completely flat as it was claimed by the bazaar model of full participation [12]. II. OSS C

This paper studies the success of Open Source Software (OSS) projects in attracting developer interest and achieving project efficiency. The focus of our study is on examining the relationship between the four sets of capabilities proposed in the Theory of Competency Rallying (TCR) and the success of OSS projects. The data collected from 607 OSS projects mainly confirm that the capabilities proposed in the TCR are necessary for the success of OSS projects. The results of this study show that in order to succeed, OSS projects should constantly identify their market’s quality and functionality needs. Ability of OSS project managers to know which developers possess certain skills required to meet a particular market need is also found to be critical. Another capability that is recognised to be crucial in predicting project success is the ability of OSS developers in effectively addressing market needs and continuously learning from such experiences. Finally, the ability of stakeholders involving in addressing a particular market need to efficiently collaborate and fulfil that specific market need is found to be another essential capability required for OSS projects to succeed. Implications of the results for practitioners and the research community are presented.

Standard Development Organizations (SDO) and Open Source Software (OSS) Projects offer two different models for open and collaborative innovation. While SDO standards have interacted with independent OSS projects for a long time, an increasing number of SDOs are themselves hosting OSS projects, notably for the development tools or for reference implementations of their standards. While policy makers and industry stakeholders have rightly identified the potential benefits of tighter integration of OSS and SDO processes, the potential downsides of this integration are insufficiently understood. An OSS reference implementation sponsored by the SDO itself has the potential to dominate the market for standard-compliant implementations. SDO participants may feel compelled to participate in the OSS project, as decisions made in the development of the OSS implementation will influence standardization outcomes and determine how the standard will be used. It is thus a significant concern when formal and influential SDOs develop OSS reference implementations of their standards under a license that is incompatible with the SDO’s balanced patent policy, and using processes that do not reflect the SDO’s commitment to openness and consensus decision-making. When SDOs use inadequate licenses, owners of standard-essential patents (SEP) participating in the OSS project may be deprived of the possibility to collect royalty revenue from the licensing of their SEP. For SEP owners unwilling to forfeit this royalty revenue, participation in the standard development itself becomes unattractive, as they are excluded from significant parts of the decision-making, as well as from using the dominant implementation of the standard. We illustrate these potential risks using the case of Open Source MANO (OSM), an OSS project of the European Telecommunications Standards Institute (ETSI).

New technologies such as 5G, IoT, blockchain and many others are implemented as ecosystems with many interoperable products and services designed to communicate seamlessly through a developing web of technical standards. Today’s standards are far more software-driven than in the past. As a result, standards development organizations (SDOs) are increasing their use of open source software (OSS) to promote both the rapid development of new standards and the deployment of standards-conformant products and services in the marketplace. Although SDOs have traditionally avoided requiring the use of any specific software code for conformance to its standards, SDOs have relied on OSS communities to develop tools, test suites, and independent implementations to assist implementers in developing products and services utilizing the standard. Today, however, there is a growing movement for SDOs to initiate their own OSS projects so that the standards and open source development efforts can be better integrated. SDOs understandably seek to replicate the benefits of collaborative development associated with OSS projects. In doing so, SDOs are also selecting the most common OSS licenses for the software they develop through these projects, such as the BSD or Apache licenses. These common licenses are ones that have been certified by the Open Source Initiative (OSI) as being compliant with its open source definition (OSD). While OSI does not hold a trademark on the term “open source” nor is it the arbiter of which software is considered OSS, OSI discourages others from referring to software as open source if the applicable software is licensed under a license that does not meet the requirements of the OSD. As OSS has become more commercial, the OSS development community has increasingly formulated OSS licenses that are more tailored to their respective objectives even when those licenses do not satisfy the terms of the OSD. SDOs, however, have not for the most part considered using an OSS license tailored to the intended use of the software being developed nor to their unique goals. Rather, by default, SDOs most often select a common OSI-approved license for their OSS projects. SDOs have long balanced the rights and interests of stakeholders through intellectual property (IP) policies that have permitted their contributors to commit to negotiate licenses for their essential patent claims on reasonable and non-discriminatory terms and conditions (RAND). While all open source licenses are royalty free, they do not require that the OSS be “patent-free” in the sense that no patent licenses would be required for use of the OSS. Nonetheless, OSI advocates that a RAND licensing commitment from a patent holder is incompatible with OSI’s approved licenses. Some innovators who have committed to license their essential patent claims on RAND terms have raised concerns about the use of OSI-approved licenses for SDO software projects. These innovators are discouraged from participating in such SDOs’ OSS projects because these innovators’ business models are not consistent with OSI’s requirements for unrestricted royalty free licensing. If an SDO’s OSS project becomes fundamental to the way standards are implemented in the marketplace, the lack of participation from these innovators may (i) deprive the community of valuable contributions, and (ii) skew the resulting SDO-approved OSS implementation in a way that is no longer vendor neutral. OSI-approved open source licenses also authorize unrestricted modifications and distribution of the modified software which is antithetical to an SDO’s goal of promoting conformant products and services. If the software can be modified without restriction, then it can be modified in ways that fail to conform to the standard, disrupting the market and thwarting widespread adoption of the standard. The vast majority of SDOs restrict recipients of their specifications, the documents which set forth the requirements of the standard, from making any modifications. Similarly, RAND commitments are made with respect to conforming products and services, not non-conforming ones. It is rather inexplicable then that SDOs are selecting OSI- approved open source licenses that are contrary to their goals of conformance, inconsistent with their existing balanced IP policies, and creating tension among stakeholders. This paper, using real world examples, explores some of the business motivations that have led to the common use of OSI-approved licenses in SDO OSS projects and the challenges created by using those licenses. The paper concludes by offering sample licenses that SDOs may consider that will promote their goals, foster consistency across their standards and software development efforts, and reduce IP-related friction among different stakeholder groups.

The open-source software (OSS) movement is often analogized as a commons, where products are developed by and consumed in an open community. However, does a larger commons automatically beget success or does the phenomenon fall prey to the tragedy of the commons? This research forwards and empirically investigates the curvilinear relationship between developers and OSS project quality and a project's download volume. Using segmented regression on over 12,000 SourceForge OSS projects, findings suggest an inflection point in the number of contributing developers on download volume – suggesting increasing and diminishing returns to scale from adding developers to OSS projects. Findings support the economic principle of the tragedy of the commons, a concept where an over-allocated (large number) of developers, even in an open-source environment, can lead to resource mismanagement and reduce the benefit of a public good, i.e. the OSS project.

The massive emergence of Open Source Software (OSS) projects led to the rapid increment of data available to software engineers and those who would like to contribute to an OSS project. There is an arising need for a way to analyze and draw conclusions about the value of an OSS project, from an epistemic point of view. OSS projects have been used for a long time as vehicles for learning programming and software engineering. However, there is a need for more evidence about the scientific value conveyed by OSS projects. We posit that if we deeply study the dialogues of software engineers involved in the communities of the various projects and draw conclusions from them, this can be an additional way of assessing OSS projects. Learning analytics, data mining and data science provide diverse statistical and computational approaches to analyzing data. In this work, we describe Epistemic Network Analysis (ENA), a network analysis technique used by a growing community of researchers to support thick descriptions based on large volumes of data. ENA is based on the theory of epistemic frames. The theory of epistemic frames models the ways of being, thinking and acting inside some community of practice. In this research, we focus on the epistemic frame of software engineering and discuss the elements of this frame: the knowledge, the set of skills and values and the set of processes for making and justifying decisions. We coded the discourses of two well-known open source projects, LibreOffice and OpenOffice, and we used the online tool ENA WebKit to analyze the coded rows of the discourses, but also to visualize and compare the networks of different units of data. We conducted three types of experiments and comparisons on the mean networks of the two projects, on the networks of the different bugs, as well as on the networks of some software engineers who participated in the discussions, and we came to conclusions about how epistemic these dialogues were and therefore assessing their educational value. This is an introductory work utilizing the ENA method for OSS discourse analysis. We believe that the rational presented in this paper can lead to a set of processes on evaluating OSS projects based on their epistemology and at the same time, become an educational tool for software engineering courses and research groups.

Mentoring is a well-known way to help newcomers to Open Source Software (OSS) projects overcome initial contribution barriers. Through mentoring, newcomers learn to acquire essential technical, social, and organizational skills. Despite the importance of OSS mentors, they are understudied in the literature. Understanding who OSS project mentors are, the challenges they face, and the strategies they use can help OSS projects better support mentors’ work. In this paper, we employ a two-stage study to comprehensively investigate mentors in OSS. First, we identify the characteristics of mentors in the Apache Software Foundation, a large OSS community, using an online survey. We found that less experienced volunteer contributors are less likely to take on the mentorship role. Second, through interviews with OSS mentors (n=18), we identify the challenges that mentors face and how they mitigate them. In total, we identified 25 general mentorship challenges and 7 sub-categories of challenges regarding task recommendation. We also identified 13 strategies to overcome the challenges related to task recommendation. Our results provide insights for OSS communities, formal mentorship programs, and tool builders who design automated support for task assignment and internship.

A systematic examination of knowledge loss in open source software projects

One of the recurrent themes in open source software research is to understand the impacts of various project characteristics on its success. Open source software (OSS) projects rely on voluntary participation of developers and tend to be continually in development. Hence, an important measure of success is the time it takes for an OSS project to release a stable version to its users. However, there is little research on this success measure and how the OSS characteristics enable or delay the progress towards stable release. In this study, we use survival analysis technique on open source project data to explore the impacts of OSS characteristics on the time it takes to release stable software versions. We find that when compared to the interest of developers in the project, interest of end-users has a greater positive effect on an OSS project progress towards stable release. Our findings also suggest that the use of C and C-like programming languages or a Weak-Copyleft license for the open source project negatively impact the project’s time to reach stable status. In OSS projects less than 8 months since becoming public, the use of a Strong-Copyleft license positively affects the project’s progress. One of the implications of our findings is that OSS project administrators should control software change requests or form smaller developer groups to better control the delays due to higher developer interest in their projects.

Open Source Software is a term used to identify software developed and released under an “open source” license, meaning that under certain conditions; it is openly available for use, inspection, modification, and for redistribution free of cost (or with cost based on the license agreement). Incorporation of OSS while developing software can reduce time and cost of development. The nature of the work force (volunteers and paid) in OSS projects is transient and results in high turnover leading to knowledge loss. In this work, we explore the phenomenon of knowledge loss in OSS projects. Maintenance of OSS projects requires knowledge, typically shared asynchronously using technology-mediated channels. Knowledge sought in this manner is reactive in the sense that a developer will consult these channels looking for possible solutions or supporting information. We follow the backward snowballing to study the relevant literature on knowledge loss in OSS. Our work suggests that proactive knowledge exchange mechanisms may bring some benefits to OSS projects. Further integration of knowledge management practices with the established OSS practices can minimise knowledge loss.

Context: Several Open Source Software (OSS) projects have adopted frequent releases as a strategy to deliver both new features and fixed bugs on time. This cycle begins with express requests from the project’s community, registered as issues in bug repositories by active users and developers. Each OSS project has its own priorities established by their respective communities. A a still open question is the set of criteria and priorities that influence the decisions of which issues should be analyzed, implemented/solved and delivered in next releases. In this paper, we present an exploratory study whose goal is to investigate the influence of target product quality attributes in software evolution practices of OSS projects. The goal is to search for evidence of relationships between these target attributes, priorities assigned to the registered issues and the ways they are delivered by product releases. To this end, we asked six participants of an exploratory study to identify these attributes through the data analysis of repositories of three well-known OSS projects: Libre Office, Eclipse and Mozilla Firefox. Evidence indicated by the participants suggest that OSS community developers use criteria/priorities driven by specific software product quality attributes, to plan and integrate software releases.

Whereas there are several instances of Open Source Software (OSS) projects that have achieved huge success in the market, a high failure rate has been reported for OSS projects. This study conducts a literature survey to gain insight into existing studies on the success of OSS projects. More specifically, this study seeks to extract the critical success factors for OSS projects. Based on the literature survey in this study, the authors found determinants of success in OSS projects and classified them into three broad categories of project traits, product traits, and network structure. These findings have important implications for both the OSS research community and OSS practitioners.

Nowadays, many software projects are partially or completely open-source based. There is an increasing need for companies to participate in open-source software (OSS) projects, e.g., in order to benefit from open source ecosystems. OSS projects introduce particular challenges that have to be understood in order to gain the benefits. One such challenge is getting newcomers onboard into the projects effectively. Similar challenges may be present in other self-organised, virtual team environments. In this paper we present preliminary observations and results of in-progress research that studies the process of onboarding into virtual OSS teams. The study is based on a program created and conceived at Stanford University in conjunction with Facebook's Education Modernization program. It involves the collaboration of more than a dozen international universities and nine open source projects. More than 120 students participated in 2013. The students have been introduced to and supported by mentors experienced in the participating OSS projects. Our findings indicate that mentoring is an important factor for effective onboarding in OSS projects, promoting cohesion within distributed teams and maintaining an appropriate pace.