Commit | Line | Data |
---|---|---|
10a29eb6 TT |
1 | .. SPDX-License-Identifier: GPL-2.0 |
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. |