요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
Level 0과 1: 금지에서 허용으로
contribution-maturity-model.rst:37-49| 단계 | 조직의 상태 |
|---|---|
| Level 0 | Software engineer가 Linux kernel patch를 upstream에 보낼 수 없다. |
| Level 1 | 업무 또는 개인 시간에 kernel patch를 보낼 수 있도록 허용한다. |
Level 1은 contribution을 막지 않는 단계일 뿐, upstream work에 실제 근무 시간·평가·여행 예산을 제공하는 단계는 아니다.
Level 2: Contribution을 공식 업무로 인정
contribution-maturity-model.rst:51-60- Engineer에게 Linux kernel contribution을 job responsibility로 기대한다.
- Linux 관련 conference 참석을 업무로 지원한다.
- Upstream code contribution을 promotion과 performance review에 반영한다.
Level 3: Review와 community 성과 측정
contribution-maturity-model.rst:61-87자사 patch뿐 아니라 다른 회사 engineer의 patch review를 업무로 인정하고, Linux·academic conference 발표와 논문도 work product로 본다. 평가에는 code만이 아니라 community contribution을 포함한다.
- Team·조직별 upstream contribution 수
- 전체 kernel developer 중 upstream contributor 비율
- 제품·server kernel base와 upstream release 사이의 시간 차이
- 내부 kernel에 남은 out-of-tree commit 수
이 metric은 최소 내부적으로 정기 추적하고 조직 선택에 따라 외부 공개할 수 있다. 단순 patch 수만 늘리는 목표가 아니라 upstream lag와 private delta를 함께 보아 장기 유지비용을 측정한다.
Level 4: Upstream 공공재에 근무 시간 배정
contribution-maturity-model.rst:88-100Engineer가 일정 근무 시간을 patch review, program committee, test infrastructure, upstream technical debt 축소와 documentation 같은 Upstream Work에 쓰도록 장려한다. Conference 조직도 업무로 지원하고 공식 성과평가에 외부 community member feedback을 고려한다.
Level 5: Upstream 개발을 정식 직무로 운영
contribution-maturity-model.rst:101-110Upstream kernel development가 공식 job position이며 engineer 시간의 최소 3분의 1을 Upstream Work에 쓴다. 조직은 community feedback을 능동적으로 수집해 평가에 반영하고, 직접 business goal을 좇는 업무와 upstream work의 비율을 내부에 정기 보고한다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. 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.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
배경
1-382021 Linux Kernel Maintainers’ Summit에서는 kernel maintainer 모집과 maintainer 승계의 어려움을 논의했다. 논의의 결론 가운데 하나는 Linux Kernel community에 참여하는 회사가 engineer의 maintainer 활동을 업무로 인정해야 한다는 것이었다. 그래야 engineer가 존중받는 leader로 성장하고 결국 kernel maintainer가 될 수 있다.
튼튼한 인재 흐름을 만들려면 developer가 다른 사람의 patch review, kernel infrastructure refactoring, documentation 작성 같은 upstream contribution을 맡도록 허용하고 장려해야 한다.
이를 위해 Linux Foundation Technical Advisory Board는 Linux Kernel Contribution Maturity Model을 제안한다. Upstream community 참여에 관한 공통 기대치를 세워 개인 developer의 영향력을 높이고 조직 사이의 협력을 늘리며 Linux Kernel ecosystem 전체의 건강성을 개선하는 것이 목적이다.
TAB는 조직이 Open Source maturity model을 지속적으로 평가하고 이 model에 맞추기 위한 개선을 약속하도록 권고한다. 평가는 management와 모든 seniority level의 developer를 포함해 조직 전반의 feedback을 반영해야 한다. Open Source 정신에 따라 조직이 평가 결과와 upstream community 참여 개선 계획을 공개하는 것도 권장한다.
Level 0부터 Level 2
40-61- Level 0: Software engineer가 Linux kernel에 patch를 contribute하는 것을 허용하지 않는다.
- Level 1: Software engineer가 업무의 일부 또는 개인 시간에 Linux kernel patch를 contribute할 수 있다.
- Level 2: Software engineer가 업무 책임의 일부로 Linux Kernel에 contribute하기를 기대한다.
- Level 2: 업무의 일부로 Linux 관련 conference 참석을 지원한다.
- Level 2: Upstream code contribution을 승진과 성과 평가에 반영한다.
Level 3
63-89- 다른 회사 engineer가 작성한 patch를 포함해 patch review를 업무 책임으로 기대한다.
- Linux 관련 또는 학술 conference에 presentation이나 paper를 제출하는 일을 engineer의 업무로 인정한다.
- Software engineer의 community contribution을 승진과 성과 평가에 반영한다.
- 조직은 Open Source contribution metric을 정기적으로 보고하고 시간에 따른 변화를 추적한다. Metric은 내부에만 공개하거나 일부 또는 전부를 외부에 공개할 수 있다.
권장 metric에는 team 또는 조직별 upstream kernel contribution 수, 전체 kernel developer 중 upstream contribution 경험이 있는 developer 비율, 제품·server에서 쓰는 kernel과 그 기반 upstream kernel publish date 사이의 간격, 내부 kernel의 out-of-tree commit 수가 포함된다.
Level 4
91-101- Software engineer가 업무 시간 일부를 upstream work에 사용하도록 장려한다.
- Upstream work에는 patch review, program committee 활동, test 작성·유지보수 같은 core infrastructure 개선, upstream technical debt 감소, documentation 작성 등이 포함된다.
- Linux 관련 conference 조직 활동을 지원한다.
- 공식 성과 평가에서 community member의 feedback을 고려한다.
Level 5
103-109- Upstream kernel 개발을 공식 직무로 인정하고 engineer 업무 시간의 최소 3분의 1을 upstream work에 사용한다.
- 공식 성과 평가 요소로 community member의 feedback을 적극적으로 수집한다.
- Upstream work와 직접적인 business 목표를 위한 업무의 비율을 조직 내부에 정기적으로 보고한다.
Maintainer 후속 세대를 만드는 조직 조건
contribution-maturity-model.rst:4-352021 Kernel Maintainers' Summit에서는 새 maintainer 모집과 succession 문제가 논의됐다. 조직이 engineer에게 patch 작성뿐 아니라 다른 회사 patch review, 공통 infrastructure refactoring과 documentation을 업무로 수행할 시간을 줘야 respected leader와 maintainer로 성장할 수 있다는 결론이 나왔다.
Linux Foundation Technical Advisory Board는 조직의 upstream 참여 수준을 공통 기준으로 평가하기 위해 이 model을 제안했다. Management와 모든 seniority의 developer 의견을 함께 반영하고 가능하면 평가와 개선 계획을 공개하도록 권장한다.