FLOSS Projects Research Articles

Does Superposition Influence the Success of FLOSS Projects? An Examination of Open-Source Software Development by Organizations and Individuals

Does the task work orchestration in free (Libre) and open-source (FLOSS) software projects influence the project’s success? Does satisfying the psychological needs of the contributors effectively scale up to the level of the project and manifest as project success? For answers, we developed an innovative approach to operationalize and study the degree to which a project’s task work consisted of sequential layering of individually developed tasks, referred to as "superposed organization of tasks." Using this measure on a large sample of FLOSS projects hosted on GitHub, we found that the degree of superposition exhibited an inverted U-shaped relationship with project success, indicating the presence of an optimal value for the project’s work structures. Further, organizational ownership of projects introduced practices that tended to influence the nature of this relationship. The greater the organization owner was willing to invest in the project by contributing code and employees’ time, the lesser was the overall influence of superposed work structures on the success of the project. The greater the organization owner invested in the support activities of the FLOSS project, greater was the time-cost of money—creating a higher need for efficient development practices in lieu of superposition.

Endurance in Open Online Communities: An Examination of Visibility and Focus of Attention in the Context of Free/Libre Open Source Software Projects

The remarkable success of open source software applications, such as the Mozilla web browser and the Apache server, which have surpassed the success of most of their commercial counterparts (Mockus et al. 2002), can be attributed, to a large part, to the knowledge collaboration (Faraj et al. 2011) and consequent innovations (von Krogh and von Hippel 2006; O’Mahony and Ferraro 2007) that take place in the online communities that foster FLOSS projects. Even when the FLOSS movement has transcended its mythical beginnings as groups of hackers’ working voluntarily in software projects, the consciousness of kind, shared rituals and traditions, and a sense of duty or obligation among members are community markers that persist (Bagozzi and Dholakia 2006).

Who Will Stay in the FLOSS Community? Modeling Participant’s Initial Behavior

Motivation: To survive and succeed, FLOSS projects need contributors able to accomplish critical project tasks. However, such tasks require extensive project experience of long term contributors (LTCs). Aim: We measure, understand, and predict how the newcomers' involvement and environment in the issue tracking system (ITS) affect their odds of becoming an LTC. Method: ITS data of Mozilla and Gnome, literature, interviews, and online documents were used to design measures of involvement and environment. A logistic regression model was used to explain and predict contributor's odds of becoming an LTC. We also reproduced the results on new data provided by Mozilla. Results: We constructed nine measures of involvement and environment based on events recorded in an ITS. Macro-climate is the overall project environment while micro-climate is person-specific and varies among the participants. Newcomers who are able to get at least one issue reported in the first month to be fixed, doubled their odds of becoming an LTC. The macro-climate with high project popularity and the micro-climate with low attention from peers reduced the odds. The precision of LTC prediction was 38 times higher than for a random predictor. We were able to reproduce the results with new Mozilla data without losing the significance or predictive power of the previously published model. We encountered unexpected changes in some attributes and suggest ways to make analysis of ITS data more reproducible. Conclusions: The findings suggest the importance of initial behaviors and experiences of new participants and outline empirically-based approaches to help the communities with the recruitment of contributors for long-term participation and to help the participants contribute more effectively. To facilitate the reproduction of the study and of the proposed measures in other contexts, we provide the data we retrieved and the scripts we wrote at https://www.passion-lab.org/projects/developerfluency.html.

Quality evaluation of floss projects: Application to ERP systems

ContextThe selection and adoption of open source software can significantly influence the competitiveness of organisations. Open source software solutions offer great opportunities for cost reduction and quality improvement, especially for small and medium enterprises that typically have to address major difficulties due to the limited resources available for selecting and adopting a new software system. ObjectiveThis paper aims to provide support for selecting the open source software that is most suitable to the specific needs of an enterprise from among the options offering equivalent or overlapping functionality. MethodThis paper proposes a framework for evaluating the quality and functionality of open source software systems. The name of the framework is EFFORT (Evaluation Framework for Free/Open souRce projecTs). It supports the evaluation of product quality, community trustworthiness and product attractiveness. The framework needs to be customised to the analysis of software systems for a specific context. ResultsThe paper presents the customisation of EFFORT for evaluating Enterprise Resource Planning (ERP) open source software systems. The customised framework was applied to the evaluation and comparison of five ERP open source software systems. The results obtained permitted both the refinement of the measurement framework and the identification of the ERP open source software system that achieved the highest score for each chosen characteristic. ConclusionEFFORT is a useful tool for evaluating and selecting an open source software system. It may significantly reduce the amount of negotiation conducted among an enterprise’s members and reduce the time and cost required for gathering and interpreting data. The EFFORT framework also considers the users’ opinions by introducing relevance markers associated with the metrics and questions in the data aggregation process.

Are Developers Fixing Their Own Bugs?

The process of fixing software bugs plays a key role in the maintenance activities of a software project. Ideally, code ownership and responsibility should be enforced among developers working on the same artifacts, so that those introducing buggy code could also contribute to its fix. However, especially in FLOSS projects, this mechanism is not clearly understood: in particular, it is not known whether those contributors fixing a bug are the same introducing and seeding it in the first place. This paper analyzes the comm-central FLOSS project, which hosts part of the Thunderbird, SeaMonkey, Lightning extensions and Sunbird projects from the Mozilla community. The analysis is focused at the level of lines of code and it uses the information stored in the source code management system. The results of this study show that in 80% of the cases, the bug-fixing activity involves source code modified by at most two developers. It also emerges that the developers fixing the bug are only responsible for 3.5% of the previous modifications to the lines affected; this implies that the other developers making changes to those lines could have made that fix. In most of the cases the bug fixing process in comm-central is not carried out by the same developers than those who seeded the buggy code.

Artifacts, Actors, and Interactions in the Cross-Project Coordination Practices of Open-Source Communities

While there has been some research on coordination in FLOSS, such research has focused on coordination within a project or within a group. The area of cross-project coordination, where shared goals are tenuous or non-existent, has been under-researched. This paper explores the question of how multiple projects working on a single piece of existing software in the FLOSS environment can coordinate. Using the Ordering Systems lens, we examine this question via a cross-case analysis of four projects performed on the open source game Jagged Alliance 2 (JA2) in the forum Bear’s Pit. Our main findings are that: (1) Ongoing cross-project ordering systems are influenced by the materiality of development artifacts. (2) The emergent trajectory of cross-project ordering systems is influenced by affordances that emerge from the interaction between the goals and desires of the project team building the development artifact, and the materiality of the development artifact. (3) When two parties need to coordinate in the ordering system, all or almost all coordination effort can be borne by a single party. Furthermore, over time, emergent FLOSS projects bear more coordination effort than stable, mature projects.

Sustainability of Free/Libre Open Source Projects: A Longitudinal Study

This paper examines the factors that influence the long-term sustainability of FLOSS projects. A model of project sustainability based on organizational ecology is developed and tested empirically. Data about activity and contribution patterns over the course of five years for 2,772 projects registered with SourceForge is analyzed. Our results suggest that the size of the project’s development base, project age and the size of niche occupied by the project are positively related to the project’s ability to attract user and/or developer resources. The ability to attract resources is an indicator of the perceived project legitimacy, which in turn is a strong predictor of the project’s future sustainability. Thus a project’s ability to attract developer and user resources is shown to play a mediating role between the demographic (size and age) and ecological (niche) characteristics of the project and its future sustainability. Our results support the applicability of tenets of organizational ecology related to the liability of smallness, the liability of newness, and population characteristics (niche size) to the FLOSS development environment. The implications of the results for future research and practice are discussed.

Survival analysis on the duration of open source projects

Context Open source (FLOSS) project survivability is an important piece of information for many open source stakeholders. Coordinators of open source projects would like to know the chances for the survival of the projects they coordinate. Companies are also interested in knowing how viable a project is in order to either participate or invest in it, and volunteers want to contribute to vivid projects. Objective The purpose of this article is the application of survival analysis techniques for estimating the future development of a FLOSS project. Method In order to apply such approach, duration data regarding FLOSS projects from the FLOSSMETRICS (This work was partially supported by the European Community’s Sixth Framework Program under the Contract FP6-033982) database were collected. Such database contains metadata for thousands of FLOSS projects, derived from various forges. Subsequently, survival analysis methods were employed to predict the survivability of the projects, i.e. their probability of continuation in the future, by examining their duration, combined with other project characteristics such as their application domain and number of committers. Results It was shown how probability of termination or continuation may be calculated and how a prediction model may be built to upraise project future. In addition, the benefit of adding more committers to FLOSS projects was quantified. Conclusion Analysis results demonstrate the usefulness of the proposed framework for assessing the survival probability of a FLOSS project.

Self-organization of teams for free/libre open source software development

This paper provides empirical evidence about how free/libre open source software development teams self-organize their work, specifically, how tasks are assigned to project team members. Following a case study methodology, we examined developer interaction data from three active and successful FLOSS projects using qualitative research methods, specifically inductive content analysis, to identify the task-assignment mechanisms used by the participants. We found that ‘self-assignment’ was the most common mechanism across three FLOSS projects. This mechanism is consistent with expectations for distributed and largely volunteer teams. We conclude by discussing whether these emergent practices can be usefully transferred to mainstream practice and indicating directions for future research.

Government policy toward open source software: The puzzles of neutrality and competition

For a variety of policy reasons, governments throughout the world are now adopting different legislative and administrative strategies that support the development of FLOSS. Some governments have actually begun to procure FLOSS, whereas others have channeled public funds to large-scale FLOSS projects. This study demonstrates both the benefits and the risks of government policy favoring FLOSS from the perspective of economics, technology, and politics, and to further analyze whether these same policy goals can be achieved through government support of FLOSS. The most fundamental argument of the study is that, in lending its support to FLOSS, the difference between a government user and a business user is that the government should take into account society’s long-term interests, not merely its own interests as a consumer.

The social structure of free and open source software development (originally published in Volume 10, Number 2, February 2005)

Metaphors, such as the Cathedral and Bazaar, used to describe the organization of FLOSS projects typically place them in sharp contrast to proprietary development by emphasizing FLOSS’s distinctive social and communications structures. But what do we really know about the communication patterns of FLOSS projects? How generalizable are the projects that have been studied? Is there consistency across FLOSS projects? Questioning the assumption of distinctiveness is important because practitioner–advocates from within the FLOSS community rely on features of social structure to describe and account for some of the advantages of FLOSS production. To address this question, we examined 120 project teams from SourceForge, representing a wide range of FLOSS project types, for their communications centralization as revealed in the interactions in the bug tracking system. We found that FLOSS development teams vary widely in their communications centralization, from projects completely centered on one developer to projects that are highly decentralized and exhibit a distributed pattern of conversation between developers and active users. We suggest, therefore, that it is wrong to assume that FLOSS projects are distinguished by a particular social structure merely because they are FLOSS. Our findings suggest that FLOSS projects might have to work hard to achieve the expected development advantages which have been assumed to flow from "going open." In addition, the variation in communications structure across projects means that communications centralization is useful for comparisons between FLOSS teams. We found that larger FLOSS teams tend to have more decentralized communication patterns, a finding that suggests interesting avenues for further research examining, for example, the relationship between communications structure and code modularity.

The social structure of free and open source software development

Metaphors, such as the Cathedral and Bazaar, used to describe the organization of FLOSS projects typically place them in sharp contrast to proprietary development by emphasizing FLOSS’s distinctive social and communications structures. But what do we really know about the communication patterns of FLOSS projects? How generalizable are the projects that have been studied? Is there consistency across FLOSS projects? Questioning the assumption of distinctiveness is important because practitioner–advocates from within the FLOSS community rely on features of social structure to describe and account for some of the advantages of FLOSS production. To address this question, we examined 120 project teams from SourceForge, representing a wide range of FLOSS project types, for their communications centralization as revealed in the interactions in the bug tracking system. We found that FLOSS development teams vary widely in their communications centralization, from projects completely centered on one developer to projects that are highly decentralized and exhibit a distributed pattern of conversation between developers and active users. We suggest, therefore, that it is wrong to assume that FLOSS projects are distinguished by a particular social structure merely because they are FLOSS. Our findings suggest that FLOSS projects might have to work hard to achieve the expected development advantages which have been assumed to flow from "going open." In addition, the variation in communications structure across projects means that communications centralization is useful for comparisons between FLOSS teams. We found that larger FLOSS teams tend to have more decentralized communication patterns, a finding that suggests interesting avenues for further research examining, for example, the relationship between communications structure and code modularity.