It is revealed that feature branches in open-source projects are long-lived, with a median lifespan exceeding two years, diverging from the short, agile iterations typically employed in software development.
Abstract
Although “feature” is a common term across requirements engineering, product-line engineering, and agile methods, its operationalization in practice–especially through feature branches–has received little empirical attention. Feature branches are widely recommended on platforms like GitHub; yet, empirical evidence on how they are actually used is scarce. This study investigates feature-branch development practices in open-source software (OSS) projects. We conducted a large-scale empirical analysis of 27,103 feature branches from 3,388 popular GitHub repositories. Using branch-naming conventions, we identified feature branches and measured their lifespan, commit history, and commit-share distributions among contributors. In addition, we profiled contributors according to their opened issues, opened pull requests, number of followers, and total stars. Our analysis revealed that feature branches in open-source projects are long-lived, with a median lifespan exceeding two years, diverging from the short, agile iterations typically employed in software development. Commit intensity is low and irregular, averaging fewer than two commits per day. Contribution is highly unequal within feature branches: a small share of contributors accounts for most commits, revealing strong dependence on a small subset of developers. These findings have several practical implications. Our findings suggest that monitoring contribution concentration within feature branches– for instance, by computing the share of commits attributable to the top contributor or a Gini coefficient over the branch’s commit history–can help maintainers identify branches where development knowledge is held by very few individuals. Likewise, rolling commit intensity–computable directly from commit timestamps–may serve as an early signal of branch stagnation in OSS projects. Moreover, these findings establish an empirical baseline for future studies, including analyses of proprietary repositories.
The ability to benchmark new approaches and replicate already published research in empirical software engineering has suffered from limited advancement over time because there was no large-scale, multi-domain dataset containing both raw workflow data and derived features in one place. To address this, we created the Itemlet dataset, which is compliant with agile-based software engineering tasks. It is comprised of 727,282 data points from 204 projects with publicly accessible Jira issue trackers across 19 different domains. There are 108 features per sample, which consist of 60 raw structural fields retrieved from the JIRA REST API and 48 derived features. The raw structural fields and the derived features were designed to support three types of research tasks: (1) sprint planning and effort proxy analysis; (2) requirements prioritization; and (3) complexity classification. The effort-related fields are proxies reflecting how agile teams record effort; the dataset does not contain independently validated deliverable size measures (such as function points) required for formal effort estimation in the classical sense. We also demonstrated that the dataset complies with FAIR principles on fifteen criteria; except for one, all criteria are completely satisfied. The dataset can be accessed under CC-BY 4.0 license terms and has been archived at Zenodo with a DOI number:
https://zenodo.org/records/19411554
.
Michael Abebe, A. Rusiecki· Scientific Data· 0 citations
Interviews with sixteen early-adopter software professionals who integrated LLM-based tools into their day-to-day work in early to mid-2023 offer actionable implications for developers, organizations, educators, and tool designers seeking to integrate LLMs responsibly into professional software practice.
Benyamin T. Tabarsi, Heidi Reichert, Sam Gilson et al.· Empirical Software Engineeri...· 22 citations· ⚡1
While it is fairly well known how empirical software engineering (ESE) is used in the academic world, we have limited knowledge of how ESE is practiced in industry. As part of our regular column on empirical software engineering (ACM SIGSOFT SEN-ESE), we want to dedicate a series of articles to interviewing ESE practitioners from various companies. Among other things, we want to understand how ESE processes are implemented in industry, e.g., different research methods, how practitioners decide on what to study, how research results are used within companies and beyond, and if they face recurrent impediments to using ESE methods in industrial contexts. In the first edition of"ESE in Practice", we are joined by Ciera Jaspan and Collin Green from the Developer Intelligence team at Google. This article is a faithful account of our conversation from August 13, 2026, which we edited for our column.
The code integration process is critical for any distributed, large-scale open-source software (OSS) project. It serves as an implicit or explicit quality control gate and is inherently of a socio-technical nature in that the bare technical act of merging new code contributions is preceded by (oftentimes engaged) discussions and reviews. Given the reasonable and widely accepted assumption that professional experience and seniority lead to higher social credit in communities, more experienced developers are expected to get favored in this process, manifesting in higher probabilities of receiving feedback on contributions, or getting contributions accepted. We conjecture that exceptions to this pattern may indicate procedural issues and examine this hypothesis through a mixed-method study. To this end, we use developer coreness, a continuous proxy measure of experience that measures how important and connected a developer is within a project. We then study code integration processes of 16 popular OSS projects, employing a new methodology to measure the impact of developer coreness on these processes. This allows us to identify process-deviant projects, which we investigate qualitatively to determine whether unexpected observations indicate underlying procedural issues. Our findings show that developers with higher coreness values have a higher probability of getting code contributions accepted and, in many cases, of receiving feedback. Notably, projects identified as process-deviant often exhibit signs of procedural deficiencies, highlighting the practical utility of our methodological framework.
Christian Hechtl, Thomas Bock, Ralf Ramsauer et al.· International Conference on...· 0 citations
This research aims to identify and validate key challenges and their solutions within the RE process for open‐source software development (OSSD) and propose best practices to address these challenges.
Fazli Rabi, M. Ilyas, Nasir Rashid et al.· Journal of Software: Evoluti...· 0 citations
A novel holistic theory of requirements engineering (RE) quality is proposed that can serve as a coherent theoretical framework for understanding the success or failure of RE processes and artifacts, and it is envisioned that the theory can serve as a coherent theoretical framework for understanding the success or failure of RE processes and artifacts.
Henning Femmer, Julian Frattini· IEEE International Requireme...· 0 citations
We use cookies to run the site and, with your consent, for analytics and to show ads.
See our Cookie Policy.
