Factors Influencing Participant Satisfaction with Free/Libre and Open Source Software Projects

<p>The purpose of this research was to identify factors that affect participants’ satisfaction with their experience of a free/libre open source software (FLOSS) project. The research built on existing models of user satisfaction from the information systems literature, and also incorporated two characteristics of FLOSS projects first identified by Ye, Nakakoji, Yamamoto, and Kishida (2005), product openness and process openness. The central research question it answered was, What factors influence participant satisfaction with a free/libre and open source application software project? Richard Stallman’s reasons for setting up the GNU project and the Free Software Foundation arose from his frustration at being forced to be a passive user of software used for a Xerox printer. These suggest that being able to be an active participant in a FLOSS project is one factor that should be examined, and therefore the first sub-question this project answers is, What types of contributions do participants make to free/libre and open source software projects? Several studies have shown that the extent of participation in a FLOSS project varies from individual to individual, and this variation leads to the second sub-question, Do the factors that influence satisfaction vary for different types of participation? If so, in what way? A preliminary conceptual model of factors affecting participant satisfaction was developed, reflecting the key concepts identified in the literature. The main theoretical goal of this research was to test the model using empirical data. The research used a sequential, mixed methods approach. The first, qualitative stage involved reviewing documents from selected projects and interviewing a purposive sample of FLOSS project participants. The second, quantitative stage involved an online survey of FLOSS project participants, and the data gathered were used to test the conceptual model. The results of the first stage showed that participation in FLOSS projects was a more complex construct than previously reported in the literature. Seven distinct categories of activities were identified: • use; • interaction with code; • supporting the community; • outreach; • sponsorship; • management; and • governance. Four attributes that modified these categories were also identified: organisational focus, role formality, remuneration, and time commitment. Data from 154 responses to the online survey were used to test the model using stepwise multiple regression, which determined the effect of each of the variables on overall participant satisfaction. Moderated regression analysis was used to test the effects of three potential moderating variables. The results showed that that perceived system complexity had the largest effect, decreasing satisfaction if respondents perceived that the software was complex, while project openness and perceived developer communication quality accounted for the most variance in satisfaction. The main theoretical contribution of this research lies in its extension of satisfaction studies to FLOSS communities, showing that communication and openness are more important than in conventional software projects. Its practical contribution will help people involved in the management and governance of FLOSS projects to identify ways of increasing their participants’ satisfaction, which may in turn encourage them to contribute more.</p>

Successful Free/Libre Open Source Software (FLOSS) projects must attract and retain high-quality talent. Researchers have invested considerable effort in the study of core and peripheral FLOSS developers. To this point, one critical subset of developers that have not been studied are One-Time code Contributors (OTC) - those that have had exactly one patch accepted. To understand why OTCs have not contributed another patch and provide guidance to FLOSS projects on retaining OTCs, this study seeks to understand the impressions, motivations, and barriers experienced by OTCs. We conducted an online survey of OTCs from 23 popular FLOSS projects. Based on the 184 responses received, we observed that OTCs generally have positive impressions of their FLOSS project and are driven by a variety of motivations. Most OTCs primarily made contributions to fix bugs that impeded their work and did not plan on becoming long term contributors. Furthermore, OTCs encounter a number of barriers that prevent them from continuing to contribute to the project. Based on our findings, there are some concrete actions FLOSS projects can take to increase the chances of converting OTCs into long-term contributors.

The FLOSSMetrics project has set up a system that has already collected detailed information from software development repositories of about 3,000 FLOSS (free, libre, open source software) projects. The system is capable of retrieving data from source code management, mailing lists, and issue tracking repositories. All the data obtained is stored in an SQL database, with a structure intended to facilitate further analysis and studies. All the data is also published, so that researchers can use it for their own purposes. This paper describes how FLOSSMetrics can be used to better understand how a FLOSS project is developed, and how several projects can be compared, by analyzing some VoIP clients.

Community-based Open Source Software (OSS) projects are generally self-organized and dynamic, receiving contributions from volunteers spread across the globe. These communities' survival, long-term success, and continuity demand a constant influx of newcomers. However, newcomers face many barriers when making their first contribution to an OSS project, leading in many cases to dropouts. Therefore, a major challenge for OSS projects is to provide ways to support newcomers during their first contribution. In this thesis, our goal was to identify and understand the barriers newcomers face and provide appropriate strategies to lower these barriers. Toward this end, we conducted multiple studies, using multiple research methods. To identify the barriers, we used data collected from: semi-structured interviews with 35 developers from 13 different projects; 24 answers to an open questionnaire conducted with OSS developers; feedback from 9 graduate and undergraduate students after they tried to join OSS projects; and 20 primary studies gathered via a systematic literature review. The data was analyzed using Grounded Theory procedures: namely, open and axial coding. Subsequently, the analysis resulted in a preliminary conceptual model composed of 58 barriers grouped into six categories: cultural differences, newcomers' characteristics, reception issues, newcomers' orientation, technical hurdles, and documentation problems. Based on the conceptual model, we developed FLOSScoach, a portal to support newcomers making their first OSS project contribution. To assess the portal, we conducted a study with undergraduate students, relying on qualitative data from diaries, self-efficacy questionnaires, and the Technology Acceptance Model. By applying the model to a practical application and assessing it, we could evaluate and improve the barriers model, changing it according to improvements identified during the conception of the tool, as well as suggestions received from the study participants. The FLOSScoach study results indicate that the portal played an important role guiding newcomers and lowering barriers related to the orientation and contribution process, whereas it was inefficient in lowering technical barriers. We also found that the portal is useful, easy to use, and increased newcomers' confidence to contribute. The main contributions of this thesis are: (i) empirical identification and modeling of barriers faced by OSS project newcomers; and (ii) a portal providing information to support OSS project newcomers.

Downsides of Using Inadequate Open Source Software Processes and Licenses within Standard Development Organizations

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.

The majority of contributions to community open source software (OSS) projects are made by practitioners acting on behalf of companies and other organisations. Previous research has addressed the motivations of both individuals and companies to engage with OSS projects. However, limited research has been undertaken that examines and explains the practical mechanisms or work practices used by companies and their developers to pursue their commercial and technical objectives when engaging with OSS projects. This research investigates the variety of work practices used in public communication channels by company contributors to engage with and contribute to eight community OSS projects. Through interviews with contributors to the eight projects we draw on their experiences and insights to explore the motivations to use particular methods of contribution. We find that companies utilise work practices for contributing to community projects which are congruent with the circumstances and their capabilities that support their short- and long-term needs. We also find that companies contribute to community OSS projects in ways that may not always be apparent from public sources, such as employing core project developers, making donations, and joining project steering committees in order to advance strategic interests. The factors influencing contributor work practices can be complex and are often dynamic arising from considerations such as company and project structure, as well as technical concerns and commercial strategies. The business context in which software created by the OSS project is deployed is also found to influence contributor work practices.

Complex software development projects rely on the contribution of teams of developers, who are required to collaborate and coordinate their efforts. The productivity of such development teams, i.e., how their size is related to the produced output, is an important consideration for project and schedule management as well as for cost estimation. The majority of studies in empirical software engineering suggest that - due to coordination overhead - teams of collaborating developers become less productive as they grow in size. This phenomenon is commonly paraphrased as Brooks' law of software project management, which states that "adding manpower to a software project makes it later". Outside software engineering, the non-additive scaling of productivity in teams is often referred to as the Ringelmann effect, which is studied extensively in social psychology and organizational theory. Conversely, a recent study suggested that in Open Source Software (OSS) projects, the productivity of developers increases as the team grows in size. Attributing it to collective synergetic effects, this surprising finding was linked to the Aristotelian quote that "the whole is more than the sum of its parts". Using a data set of 58 OSS projects with more than 580,000 commits contributed by more than 30,000 developers, in this article we provide a large-scale analysis of the relation between size and productivity of software development teams. Our findings confirm the negative relation between team size and productivity previously suggested by empirical software engineering research, thus providing quantitative evidence for the presence of a strong Ringelmann effect. Using fine-grained data on the association between developers and source code files, we investigate possible explanations for the observed relations between team size and productivity. In particular, we take a network perspective on developer-code associations in software development teams and show that the magnitude of the decrease in productivity is likely to be related to the growth dynamics of co-editing networks which can be interpreted as a first-order approximation of coordination requirements.

An Open Source Software (OSS) project can be considered as a new type of business entity involving various roles and stakeholders, e.g., project managers, developers, and users, who apply individual methods. The project managers have the responsibility to manage the OSS development in a way that the OSS product can be delivered to the customers in time and with good quality. This responsibility is challenging, because the heterogeneity of the data collected and analyzed from different stakeholders leads to the complexity of efforts of the project managers to measure and manage OSS projects. In this paper, we propose a measurement framework (OSMF) to enable the project managers to collect and analyze process data from OSS projects efficiently. Initial results show that OSMF can help project managers to manage OSS business processes more efficient, hence improve the decision on OSS project quality.

Established contributors are the backbone of many free/libre open source software (FLOSS) projects. Previous research has shown that it is critically important for projects to retain contributors and it has also revealed the motivations behind why contributors choose to participate in FLOSS in the first place. However, there has been limited research done on the reasons why established contributors disengage, and factors (on an individual and project level) that predict their disengagement. In this paper, we conduct a mixed-methods empirical study, combining surveys and survival modeling, to identify the reasons and predictive factors behind established contributor disengagement. We find that different groups of established contributors tend to disengage for different reasons; however, overall contributors most commonly cite some kind of transition (e.g., switching jobs or leaving academia). We also find that factors such as the popularity of the projects a contributor works on, whether they have experienced a transition, when they work, and how much they work are all factors that can be used to predict their disengagement from open source.

In this article a perspective of relating various Free/Libre Open Source Software (FLOSS) projects and linking different FLOSS developers is given. Specifically, by viewing projects and developers as characterized by their choices of features such as intended audiences, licenses, programming languages, operating systems, and topics, two-mode networks are generated to link projects (or developers) to their feature choices. Based on the generated networks, similarities among projects and among developers are calculated, and projects (or developers) are clustered through their measured similarities. Implication to this perspective can be the provision of project and developer recommendation services to extend developers' social networks beyond their participated projects and also to facilitate the sharing of information. This perspective also opens the possibility of discovering free software ideologists in FLOSS community.

But what will it cost me? How do private costs of participation affect open source software projects?

Open Source Software (OSS) projects start with an initial vocabulary, often determined by the first generation of developers. This vocabulary, embedded in code identifier names and internal code comments, goes through multiple rounds of change, influenced by the interrelated patterns of human (e.g., developers joining and departing) and system (e.g., maintenance activities) interactions. Capturing the dynamics of this change is crucial for understanding and synthesizing code changes over time. However, existing code evolution analysis tools, available in modern version control systems such as GitHub and SourceForge, often overlook the linguistic aspects of code evolution. To bridge this gap, in this paper, we propose to study code evolution in OSS projects through the lens of developers' language, also known as code lexicon. Our analysis is conducted using 32 OSS projects sampled from a broad range of application domains. Our results show that different maintenance activities impact code lexicon differently. These insights lay out a preliminary foundation for modeling the linguistic history of OSS projects. In the long run, this foundation will be utilized to provide support for basic program comprehension tasks and help researchers gain new insights into the complex interplay between linguistic change and various system and human aspects of OSS development.

This paper presents the results after four years of running of an instructional method that utilizes free/libre open source software (FLOSS) projects as tools for teaching software engineering in formal education. In the last four academic years, a total of 408 juniors majoring in Informatics (in a 4-year program) participated in the study, assuming the roles of requirements engineers, testers, developers, and designers/analysts. Students appreciated the benefits gained by the method and identified aspects that require further improvement. In the paper, we present (a) the details of our method, (b) students' opinions as recorded through a questionnaire including both closed and open ended questions, and (c) conclusions on how the use of FLOSS projects can be applied, and be beneficial for the students.

Open-source software (OSS) projects are relatively unexplored territory in music education research and practice. In contrast to commercial software development, OSS projects are informally organized and free in terms of administration and control. Developers contribute in several ways according to their own will and whenever they want. In music education, the possible OSS project stakeholders can vary from independent developers to researchers, schools and commercial companies. The structure of this multifaceted collaboration scheme can be very diverse and complex. This article will present a case from a sponsored music educational open-source project that developed a mobile phone-based music software for children. The characteristics of collaboration, project structure, roles of different stakeholders and open-source licensing from this project will shed light on different aspects and characteristics of OSS development in music education. As a conclusion, an iterative process model for OSS projects in music education will be drawn.