Background¶

As a part of the 2021 Linux Kernel Maintainers’ Summit, there was adiscussion about the challenges inrecruiting kernel maintainers as well as maintainer succession. Some ofthe conclusions from that discussion included that companies which are apart of the Linux Kernel community need to allow engineers to bemaintainers as part of their job, so they can grow into becomingrespected leaders and eventually, kernel maintainers. To support astrong talent pipeline, developers should be allowed and encouraged totake on upstream contributions such as reviewing other people’s patches,refactoring kernel infrastructure, and writing documentation.

To that end, the Linux Foundation Technical Advisory Board (TAB)proposes this Linux Kernel Contribution Maturity Model. These commonexpectations for upstream community engagement aim to increase theinfluence of individual developers, increase the collaboration oforganizations, and improve the overall health of the Linux Kernelecosystem.

The TAB urges organizations to continuously evaluate their Open Sourcematurity model and commit to improvements to align with this model. Tobe effective, this evaluation should incorporate feedback from acrossthe organization, including management and developers at all senioritylevels. In the spirit of Open Source, we encourage organizations topublish their evaluations and plans to improve their engagement with theupstream community.

Level 0¶

• Software Engineers are not allowed to contribute patches to the Linuxkernel.

Level 1¶

• Software Engineers are allowed to contribute patches to the Linuxkernel, either as part of their job responsibilities or on their owntime.

Level 2¶

• Software Engineers are expected to contribute to the Linux Kernel aspart of their job responsibilities.

• Software Engineers will be supported to attend Linux-relatedconferences as a part of their job.

• A Software Engineer’s upstream code contributions will be consideredin promotion and performance reviews.

Level 3¶

• Software Engineers are expected to review patches (including patchesauthored by engineers from other companies) as part of their jobresponsibilities

• Contributing presentations or papers to Linux-related or academicconferences (such those organized by the Linux Foundation, Usenix,ACM, etc.), are considered part of an engineer’s work.

• A Software Engineer’s community contributions will be considered inpromotion and performance reviews.

• Organizations will regularly report metrics of their open sourcecontributions and track these metrics over time. These metrics may bepublished only internally within the organization, or at theorganization’s discretion, some or all may be published externally.Metrics that are strongly suggested include:

  • The number of upstream kernel contributions by team or organization(e.g., all people reporting up to a manager, director, or VP).

  • The percentage of kernel developers who have made upstreamcontributions relative to the total kernel developers in theorganization.

  • The time interval between kernels used in the organization’s serversand/or products, and the publication date of the upstream kernelupon which the internal kernel is based.

  • The number of out-of-tree commits present in internal kernels.

Level 4¶

• Software Engineers are encouraged to spend a portion of their worktime focused on Upstream Work, which is defined as reviewing patches,serving on program committees, improving core project infrastructuresuch as writing or maintaining tests, upstream tech debt reduction,writing documentation, etc.

• Software Engineers are supported in helping to organize Linux-relatedconferences.

• Organizations will consider community member feedback in officialperformance reviews.

Level 5¶

• Upstream kernel development is considered a formal job position, withat least a third of the engineer’s time spent doing Upstream Work.

• Organizations will actively seek out community member feedback as afactor in official performance reviews.

• Organizations will regularly report internally on the ratio ofUpstream Work to work focused on directly pursuing business goals.