110 lines
4.4 KiB
ReStructuredText
110 lines
4.4 KiB
ReStructuredText
.. SPDX-License-Identifier: GPL-2.0
|
||
|
||
========================================
|
||
Linux Kernel Contribution Maturity Model
|
||
========================================
|
||
|
||
|
||
Background
|
||
==========
|
||
|
||
As a part of the 2021 Linux Kernel Maintainers’ Summit, there was a
|
||
`discussion <https://lwn.net/Articles/870581/>`_ about the challenges in
|
||
recruiting kernel maintainers as well as maintainer succession. Some of
|
||
the conclusions from that discussion included that companies which are a
|
||
part of the Linux Kernel community need to allow engineers to be
|
||
maintainers as part of their job, so they can grow into becoming
|
||
respected leaders and eventually, kernel maintainers. To support a
|
||
strong talent pipeline, developers should be allowed and encouraged to
|
||
take 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 common
|
||
expectations for upstream community engagement aim to increase the
|
||
influence of individual developers, increase the collaboration of
|
||
organizations, and improve the overall health of the Linux Kernel
|
||
ecosystem.
|
||
|
||
The TAB urges organizations to continuously evaluate their Open Source
|
||
maturity model and commit to improvements to align with this model. To
|
||
be effective, this evaluation should incorporate feedback from across
|
||
the organization, including management and developers at all seniority
|
||
levels. In the spirit of Open Source, we encourage organizations to
|
||
publish their evaluations and plans to improve their engagement with the
|
||
upstream community.
|
||
|
||
Level 0
|
||
=======
|
||
|
||
* Software Engineers are not allowed to contribute patches to the Linux
|
||
kernel.
|
||
|
||
|
||
Level 1
|
||
=======
|
||
|
||
* Software Engineers are allowed to contribute patches to the Linux
|
||
kernel, either as part of their job responsibilities or on their own
|
||
time.
|
||
|
||
Level 2
|
||
=======
|
||
|
||
* Software Engineers are expected to contribute to the Linux Kernel as
|
||
part of their job responsibilities.
|
||
* Software Engineers will be supported to attend Linux-related
|
||
conferences as a part of their job.
|
||
* A Software Engineer’s upstream code contributions will be considered
|
||
in promotion and performance reviews.
|
||
|
||
Level 3
|
||
=======
|
||
|
||
* Software Engineers are expected to review patches (including patches
|
||
authored by engineers from other companies) as part of their job
|
||
responsibilities
|
||
* Contributing presentations or papers to Linux-related or academic
|
||
conferences (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 in
|
||
promotion and performance reviews.
|
||
* Organizations will regularly report metrics of their open source
|
||
contributions and track these metrics over time. These metrics may be
|
||
published only internally within the organization, or at the
|
||
organization’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 upstream
|
||
contributions relative to the total kernel developers in the
|
||
organization.
|
||
* The time interval between kernels used in the organization’s servers
|
||
and/or products, and the publication date of the upstream kernel
|
||
upon 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 work
|
||
time focused on Upstream Work, which is defined as reviewing patches,
|
||
serving on program committees, improving core project infrastructure
|
||
such as writing or maintaining tests, upstream tech debt reduction,
|
||
writing documentation, etc.
|
||
* Software Engineers are supported in helping to organize Linux-related
|
||
conferences.
|
||
* Organizations will consider community member feedback in official
|
||
performance reviews.
|
||
|
||
Level 5
|
||
=======
|
||
|
||
* Upstream kernel development is considered a formal job position, with
|
||
at least a third of the engineer’s time spent doing Upstream Work.
|
||
* Organizations will actively seek out community member feedback as a
|
||
factor in official performance reviews.
|
||
* Organizations will regularly report internally on the ratio of
|
||
Upstream Work to work focused on directly pursuing business goals.
|