Perpetual development: A model of the Linux kernel life cycle

Abstract

Software evolution is widely recognized as an important and common phenomenon, whereby the system follows an ever-extending development trajectory with intermittent releases. Nevertheless there have been only few lifecycle models that attempt to portray such evolution. We use the evolution of the Linux kernel as the basis for the formulation of such a model, integrating the progress in time with growth of the codebase, and differentiating between development of new functionality and maintenance of production versions. A unique element of the model is the sequence of activities involved in releasing new production versions, and how this has changed with the growth of Linux. In particular, the release follow-up phase before the forking of a new development version, which was prominent in early releases of production versions, has been eliminated in favor of a concurrent merge window in the release of 2.6.x versions. We also show that a piecewise linear model with increasing slopes provides the best description of the growth of Linux. The perpetual development model is used as a framework in which commonly recognized benefits of incremental and evolutionary development may be demonstrated, and to comment on issues such as architecture, conservation of familiarity, and failed projects. We suggest that this model and variants thereof may apply to many other projects in addition to Linux.

Coevolution of variability models and related artifacts

“…Such high frequency agrees with existing work [9,12,15,8], stating that the Linux kernel evolution is mainly driven by the addition of new drivers; (b) core functionality (2%)-features added to the core kernel, such as supporting self-test for 64-bit atomic instructions; (c) complementary functionality (5%)-features that complement an existing feature, either in or outside the core, with extra functionality (e.g., debugging support); and (d) shared functionality (3%)-features that provide a common base to a set of features. For example, the CAN (Controller Area Network) network bus driver provides a generic infrastructure that all specific CAN drivers rely on.…”

Coevolution of variability models and related software artifacts

“…This high frequency is in line with previous work (Feitelson 2012;Godfrey and Tu 2000;Izurieta and Bieman 2006;Lotufo et al 2010) stating that Linux kernel evolution is mainly driven by the addition of new device driver-related features. -Architecture specific code (arch): 2.4 % of the instances of this pattern add modules that are specific to a given hardware architecture.…”

A Study of Feature Scattering in the Linux Kernel

“…Our longitudinal analysis of the source code concentrated on driver features, which are defined in the driver subsystem of the Linux kernel. Beside practicality, this decision rests on existing work stating that the Linux kernel evolution is mainly driven by the evolution of its device drivers [14,27,[31][32][33], and on our own analyses (which we explain shortly). Setting the scope to features in the driver subsystem required us to distinguish them from features of other subsystems.…”