[linux-block.git] / Documentation / process / contribution-maturity-model.rst

.. 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.
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.