What do feature branches tell us about feature implementation in open-source projects?
TL;DR
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.