| 1 | |
| 2 |
|
| 3 | ========================================
|
| 4 | Linux Kernel Contribution Maturity Model
|
| 5 | ========================================
|
| 6 |
|
| 7 |
|
| 8 | Background
|
| 9 | ==========
|
| 10 |
|
| 11 | As a part of the 2021 Linux Kernel Maintainers’ Summit, there was a
|
| 12 | `discussion <https://lwn.net/Articles/870581/>`_ about the challenges in
|
| 13 | recruiting kernel maintainers as well as maintainer succession. Some of
|
| 14 | the conclusions from that discussion included that companies which are a
|
| 15 | part of the Linux Kernel community need to allow engineers to be
|
| 16 | maintainers as part of their job, so they can grow into becoming
|
| 17 | respected leaders and eventually, kernel maintainers. To support a
|
| 18 | strong talent pipeline, developers should be allowed and encouraged to
|
| 19 | take on upstream contributions such as reviewing other people’s patches,
|
| 20 | refactoring kernel infrastructure, and writing documentation.
|
| 21 |
|
| 22 | To that end, the Linux Foundation Technical Advisory Board (TAB)
|
| 23 | proposes this Linux Kernel Contribution Maturity Model. These common
|
| 24 | expectations for upstream community engagement aim to increase the
|
| 25 | influence of individual developers, increase the collaboration of
|
| 26 | organizations, and improve the overall health of the Linux Kernel
|
| 27 | ecosystem.
|
| 28 |
|
| 29 | The TAB urges organizations to continuously evaluate their Open Source
|
| 30 | maturity model and commit to improvements to align with this model. To
|
| 31 | be effective, this evaluation should incorporate feedback from across
|
| 32 | the organization, including management and developers at all seniority
|
| 33 | levels. In the spirit of Open Source, we encourage organizations to
|
| 34 | publish their evaluations and plans to improve their engagement with the
|
| 35 | upstream community.
|
| 36 |
|
| 37 | Level 0
|
| 38 | =======
|
| 39 |
|
| 40 | * Software Engineers are not allowed to contribute patches to the Linux
|
| 41 | kernel.
|
| 42 |
|
| 43 |
|
| 44 | Level 1
|
| 45 | =======
|
| 46 |
|
| 47 | * Software Engineers are allowed to contribute patches to the Linux
|
| 48 | kernel, either as part of their job responsibilities or on their own
|
| 49 | time.
|
| 50 |
|
| 51 | Level 2
|
| 52 | =======
|
| 53 |
|
| 54 | * Software Engineers are expected to contribute to the Linux Kernel as
|
| 55 | part of their job responsibilities.
|
| 56 | * Software Engineers will be supported to attend Linux-related
|
| 57 | conferences as a part of their job.
|
| 58 | * A Software Engineer’s upstream code contributions will be considered
|
| 59 | in promotion and performance reviews.
|
| 60 |
|
| 61 | Level 3
|
| 62 | =======
|
| 63 |
|
| 64 | * Software Engineers are expected to review patches (including patches
|
| 65 | authored by engineers from other companies) as part of their job
|
| 66 | responsibilities
|
| 67 | * Contributing presentations or papers to Linux-related or academic
|
| 68 | conferences (such those organized by the Linux Foundation, Usenix,
|
| 69 | ACM, etc.), are considered part of an engineer’s work.
|
| 70 | * A Software Engineer’s community contributions will be considered in
|
| 71 | promotion and performance reviews.
|
| 72 | * Organizations will regularly report metrics of their open source
|
| 73 | contributions and track these metrics over time. These metrics may be
|
| 74 | published only internally within the organization, or at the
|
| 75 | organization’s discretion, some or all may be published externally.
|
| 76 | Metrics that are strongly suggested include:
|
| 77 |
|
| 78 | * The number of upstream kernel contributions by team or organization
|
| 79 | (e.g., all people reporting up to a manager, director, or VP).
|
| 80 | * The percentage of kernel developers who have made upstream
|
| 81 | contributions relative to the total kernel developers in the
|
| 82 | organization.
|
| 83 | * The time interval between kernels used in the organization’s servers
|
| 84 | and/or products, and the publication date of the upstream kernel
|
| 85 | upon which the internal kernel is based.
|
| 86 | * The number of out-of-tree commits present in internal kernels.
|
| 87 |
|
| 88 | Level 4
|
| 89 | =======
|
| 90 |
|
| 91 | * Software Engineers are encouraged to spend a portion of their work
|
| 92 | time focused on Upstream Work, which is defined as reviewing patches,
|
| 93 | serving on program committees, improving core project infrastructure
|
| 94 | such as writing or maintaining tests, upstream tech debt reduction,
|
| 95 | writing documentation, etc.
|
| 96 | * Software Engineers are supported in helping to organize Linux-related
|
| 97 | conferences.
|
| 98 | * Organizations will consider community member feedback in official
|
| 99 | performance reviews.
|
| 100 |
|
| 101 | Level 5
|
| 102 | =======
|
| 103 |
|
| 104 | * Upstream kernel development is considered a formal job position, with
|
| 105 | at least a third of the engineer’s time spent doing Upstream Work.
|
| 106 | * Organizations will actively seek out community member feedback as a
|
| 107 | factor in official performance reviews.
|
| 108 | * Organizations will regularly report internally on the ratio of
|
| 109 | Upstream Work to work focused on directly pursuing business goals.
|