Synchronous development in open-source projects: A higher-level perspective

One of the benefits firms can derive from using Open Source Software (OSS) is informal development collaboration, and the primary tool for collaboration and coordination are group mailing lists. The purpose of the paper is modelling mailing lists behaviour in OSS projects, using a set of descriptors that could inform about their quality and their evolution. As a case study, a mailing list focused on ARM embedded Linux has been selected. Messages posted to this list from 2001 to 2006 have been extracted, and factor analysis has been applied to obtain the underlying patterns of behaviours. Theory about communities of practice has been used to understand the meaning of the extracted patterns. Their time distribution is finally described. The paper provides new insights into the behaviour of mailing list as a source of support for OSS projects and highlights the importance of an involved core of individuals inside the community.

Open-source software projects are characterized by their loose management property. Most of the activities of their developers are voluntary instead of mandatory. Compared to closed-source software projects, open-source projects are less dependent on external turbulence, but more on its own structure and operation mechanism. In this paper, we assume that the activities of open-source software projects are only dependent on time. We use time series analysis techniques to study the time dependence of open-source software activities. The activities of open-source Software projects are extracted from mailing lists, bug reports, and revision history. Three mailing list (Linux, FreeBSD, and Apache HTTP), two bug archives (Eclipse and Apache Software Foundation), and one revision history (Apache Software Foundation) are mined. Various time series analysis techniques are used. We find that some activities of some open-source projects are cyclic and seasonally dependent, some are cyclic but seasonally independent, and some are acyclic. We build regression models for cyclic activities and analyzed their model accuracy.

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.

Mailing lists provide a rich set of data that can be used to improve and enhance our understanding of software processes and practices. This information allows us to study development characteristics like team structure, activity, and social interaction. In this paper, we perform an exploratory study on the GNOME project and recover operational knowledge from mailing list discussions. Our findings indicate that mailing list activity is driven by a dominant group of participants, that it is greatly connected to development activity, yet influenced by external factors like market competition. Our results provide a broad picture of the central role played by mailing lists in open source projects.

Many open-source software projects depend on a few core developers, who take over both the bulk of coordination and programming tasks. They are supported by peripheral developers, who contribute either via discussions or programming tasks, often for a limited time. It is unclear what role these peripheral developers play in the programming and communication efforts, as well as the temporary task-related sub-groups in the projects. We mine code-repository data and mailing-list discussions to model the relationships and contributions of developers in a social network and devise a method to analyze the temporal collaboration structures in communication and programming, learning about the strength and stability of social sub-groups in open-source software projects. Our method uses multi-modal social networks on a series of time windows. Previous work has reduced the network structure representing developer collaboration to networks with only one type of interaction, which impedes the simultaneous analysis of more than one type of interaction. We use both communication and version-control data of open-source software projects and model different types of interaction over time. To demonstrate the practicability of our measurement and analysis method, we investigate 10 substantial and popular open-source software projects and show that, if sub-groups evolve, modeling these sub-groups helps predict the future evolution of interaction levels of programmers and groups of developers. Our method allows maintainers and other stakeholders of open-source software projects to assess instabilities and organizational changes in developer interaction and can be applied to different use cases in organizational analysis, such as understanding the dynamics of a specific incident or discussion.

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.

This paper focuses on the process capability index considering the irregular fluctuation of the operation of OSS. Recently, many open source software (OSS) are developed under various open source projects. Considering the characteristics of OSS, many OSS are used via the internet network, such as the software update service, software version upgrade, cloud service, HTTP server, mobile devices, etc. From the above mentioned characteristics of OSS, the debugging process and operating phase of OSS development will take an irregular fluctuation in the long term of operation. In particular, we apply Wiener process model to the noisy cases in the operation of OSS. Moreover, we compare the method of process capability assessment based on Wiener process model considering the irregular fluctuation for OSS projects with several nonhomogeneous Poisson process (NHPP) models. Also, we analyze actual data to show numerical examples of the proposed method considering the characteristics of recent OSS projects and the existing NHPP models.

Community-based Open Source Software (OSS) projects are usually self-organized and dynamic, receiving contributions from distributed volunteers. Newcomer are important to the survival, long-term success, and continuity of these communities. 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 paper, we propose and evaluate FLOSScoach, a portal created to support newcomers to OSS projects. FLOSScoach was designed based on a conceptual model of barriers created in our previous work. To evaluate the portal, we conducted a study with 65 students, relying on qualitative data from diaries, self-efficacy questionnaires, and the Technology Acceptance Model. The results indicate that FLOSScoach played an important role in guiding newcomers and in lowering barriers related to the orientation and contribution process, whereas it was not effective in lowering technical barriers. We also found that FLOSScoach is useful, easy to use, and increased newcomers' confidence to contribute. Our results can help project maintainers on deciding the points that need more attention in order to help OSS project newcomers overcome entry barriers.

Open-source software now holds a dominant position in the software industry. Open-source software projects follow a community-based software development approach unlike that of the traditional software paradigm. Software developers voluntarily participate and contribute to an open-source project. It is important to understand the motivations for this volunteerism and the communication means they use to collaborate with each other. It is important to understand how people work together to develop complex systems in the open-source movement. This paper attempts to understand the contributions of several research studies undertaken in this regard.

This work presents Source-o-grapher, a tool built with the aim to investigate software resilience aspects of Open Source Software (OSS) projects. The tool uses several metrics from the literature to evaluate an OSS project on four major dimensions: structural (source code), business and legal, integration and social (community of the project). Many of these metrics are automatically acquired by the tool using the Github repository of the project whereas some others are manually input by the expert who performs the analysis.

Software code review is a well-established software quality practice. Recently, Modern Code Review (MCR) has been widely adopted in both open source and proprietary projects. To evaluate the impact that characteristics of MCR practices have on software quality, this paper comparatively studies MCR practices in defective and clean source code files. We investigate defective files along two perspectives: 1) files that will eventually have defects (i.e., future-defective files) and 2) files that have historically been defective (i.e., risky files). Through an empirical study of 11,736 reviews of changes to 24,486 files from the Qt open source project, we find that both future-defective files and risky files tend to be reviewed less rigorously than their clean counterparts. We also find that the concerns addressed during the code reviews of both defective and clean files tend to enhance evolvability, i.e., ease future maintenance (like documentation), rather than focus on functional issues (like incorrect program logic). Our findings suggest that although functionality concerns are rarely addressed during code review, the rigor of the reviewing process that is applied to a source code file throughout a development cycle shares a link with its defect proneness.

In this paper, we define and validate a new multidimensional measure of Open Source Software (OSS) project survivability, called Project Viability. Project viability has three dimensions: vigor, resilience, and organization. We define each of these dimensions and formulate an index called the Viability Index (VI) to combine all three dimensions. Archival data of projects hosted at SourceForge.net are used for the empirical validation of the measure. An Analysis Sample (n=136) is used to assign weights to each dimension of project viability and to determine a suitable cut-off point for VI. Cross-validation of the measure is performed on a hold-out Validation Sample (n=96). We demonstrate that project viability is a robust and valid measure of OSS project survivability that can be used to predict the failure or survival of an OSS project accurately. It is a tangible measure that can be used by organizations to compare various OSS projects and to make informed decisions regarding investment in the OSS domain.

Technical debt refers to decisions made during the design and development of software that postpone the resolution of technical problems or the enhancement of the software’s features to a later date. If not properly managed, technical debt can put long-term software quality and maintainability at risk. Self-admitted technical debt is defined as the addition of specific comments to source code as a result of conscious and deliberate decisions to accumulate technical debt. In this paper, we will look at the presence of self-admitted technical debt in open-source blockchain projects, which are characterized by the use of a relatively novel technology and the need to generate trust. The self-admitted technical debt was analyzed using NLP techniques for the classification of comments extracted from the source code of ten projects chosen based on capitalization and popularity. The analysis of self-admitted technical debt in blockchain projects was compared with the results of previous non-blockchain open-source project analyses. The findings show that self-admitted design technical debt outnumbers requirement technical debt in blockchain projects. The analysis discovered that some projects had a low percentage of self-admitted technical debt in the comments but a high percentage of source code files with debt. In addition, self-admitted technical debt is on average more prevalent in blockchain projects and more equally distributed than in reference Java projects.If not managed, the relatively high presence of detected technical debt in blockchain projects could represent a threat to the needed trust between the blockchain system and the users. Blockchain projects development teams could benefit from self-admitted technical debt detection for targeted technical debt management.

Large open source software projects often have a globally distributed development team. Studies have shown developer turnover has a significant impact on the project success. Frequent developer turnover may lead to loss of productivity due to lacking relevant knowledge and spending extra time learning how projects work. Thus, lots of attention has been paid to which factors are related to developer retention, however, few of them focus on the impact of activities of individual developers. In this paper, we study five open source projects from different organizations and examine whether developer turnover is affected by when they start contributing and what types of contributions they are making. Our study reveals that developers have higher chances to survive in software projects when they 1) start contributing to the project earlier, 2) mainly modify instead of creating files, 3) mainly code instead of dealing with documentations. Our results also shed lights on the potential approaches to improving developer retention.

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.