Linuxカーネルの開発およびサポートシステムは、私たちが望むほど完璧ではありません。 他のプロジェクトの成功経験を実験として使用して、現在のシステムを改善してみませんか？ この提案は、開発者Daniel Vetter（Daniel Vetter）によって作成されました。 彼は、LCA 2017カンファレンスのこのトピックに関するレポートを作成し（ スライド ）、ブログでより詳細なテキストを公​​開しました。



過去数年間、Daniel VetterはIntel drm / i915グラフィックスのカーネルドライバーをサポートしており、Intel Open Source Technology Centerで働いています。 drm / i915ドライバーは2人のメンテナーによってサポートされており、約19人の開発者がメインブランチに直接パッチをコミットする権利を持っています。 「これはオープンソースコミュニティにとっては完全に正常な状況ですが、Linuxカーネルにとってはまったく考えられないことです」とダニエルは言います。 彼は、ドライバーに関するこのような作業の組織化が非常に成功していることを証明し、他の場所で使用できると考えています。 たとえば、Linuxカーネルでは、メンテナーに負荷がかかりすぎています。



レポートの主なポイントは次のとおりです。

雇用と燃え尽きのカルト

Vetter氏は、メンテナーのトピックについて議論するとき、常に雇用と時間の不足というトピックが最初にすべきことだと書いています。 西側では、これは真のカルトです-開発者は仕事で過負荷になり、残業しなければならず、常に忙しくなければならず、その場合、彼はヒーローと見なされます。 暇があれば、あなたはある種のローファーであり、おそらく仕事から休憩してください。



雇用カルトは燃え尽き症候群につながります-感情的な疲労を増し、人々とのコミュニケーションの分野に個人的な変化をもたらす可能性があります（深い認知的歪みの発達まで）。 クリニックによれば、感情的な燃え尽きは、彼の職務や職場での出来事への無関心、同僚やユーザーに対する否定的な形での非人間化、そして専門用語でのネガティブな自己認識、彼の仕事に対する不満によって明らかになります。



言い換えれば、感情的な消耗で、開発者はお互いに誓い、また彼らが専門的なスキルを欠いているように感じます。



燃え尽き症候群は、その人の賃金が十分に高くない場合、および/または彼の仕事に対する心理的な励ましが十分に高くない場合にしばしば始まります。 この場合、彼の作品には価値がないという感覚があります。 時には、感情的な燃え尽き症候群の期間中のハードワークにはアルコール乱用が伴います。



ダニエル・ベッターは、感情的な燃え尽き症候群がオープンソースプロジェクトに携わる開発者にとっての主要な脅威であると考えています。 雇用のカルトとメンテナーの燃え尽きは理解できます。 あなたは2、3人の開発者と仕事を始め、数年後に彼らの数は数十人に増えます。 当然、すべてに十分な時間はありません。 元メンテナーでもあるDjangoの主要な開発者の1人であるJacob Kaplan-Mossは 、このプロセスと彼自身の燃え尽き症候群についてよく話しました 。



毎年、カーネル開発者会議でLinusが幸せかどうかについて議論しています 。



燃え尽き症候群の問題を無視することはできませんので、あまり働きすぎないように注意してください。

Linuxカーネルメンテナー

著者によると、現在のLinuxカーネルのメンテナーは働きすぎであり、これは不健康な状況です。 すべてのパッチの約80％は、他の作成者に代わってメンテナーによって公開されています。 通常、変更はメーリングリストにダンプされ、ここで説明されます。その後、メンテナーがパッチをgitブランチに追加します。 次に、各メンテナーは、変更を含めるための要求を送信します。多くの場合、直接Linusに送信されます。 一部の大規模なサブシステム（ネットワークスタック、グラフィックス、ARM-SoC）には、第2レベルまたは第3レベルのメンテナーがいます。 カーネルへのパッチの20％のみが作者から直接提供されています。



ほとんどのメンテナーは本当に酷使されています。 ある人は、カーネルのいくつかの領域を、対応する異なるgitブランチとリポジトリで管理します。



Daniel Vetterによると、drm / i915プロジェクトでは、約1年前に根本的に異なるシステムを導入し、すべての開発者がdrm-intel



リポジトリにパッチを追加する平等な権限を与えられたという。 現在、19人がそのような権利を持っています。 操業初年度の結果によると、この実験は非常に成功しているようです。 現在、リポジトリへのコミットの約70％は作成者から直接送信されています。



著者はまた、そのようなシステムが非常にうまく機能するRustコミュニティの経験 （昨年のLCA会議の報告）にも言及しています。



Daniel Vetterは、メンテナーと一緒に従来のモデルに長年取り組んできましたが、現在では新しい経験を積んでおり、Linuxカーネルメンテナーの現在のモデルは単にスケーリングしないと自信を持って言っています。 これは、階層モデルが開発者の数の増加に対して技術的に無能であるという事実に関するものではありません。 まったくありません。 このgitモデルは成功を収めています。 パッチがレビューされ、カーネルに導入される効果についてです。 この効率は低下しています。



コミュニティでは、メンテナがほぼ一生任命されることは受け入れられています。 彼はこのストラップを引っ張って、社会的および個人的な生活を害しています。 Linuxカーネルコミュニティには、プロジェクトがスケールアップされたときに有効になる正式なソーシャル管理構造がありません。



「プロジェクトの目標が世界的な支配、または少なくとも長期的なものの創造である場合、労働の流れに対処できる信頼できる組織を持つことが望ましいです」とベターは書いています。 代わりに、メンテナーは状況を悪化させるだけの新しい階層レベルを生み出します。 そのため、グラフィックスサブシステムでは、単純なドライバーの場合、5つの異なるブランチのパッチが必要になることがあります。 メンテナーの少なくとも1人がすぐに利用できなくなる可能性はほぼ100％であり、プロセスは長時間に及びます。



もう1つの問題は、現在の階層システムでは、メンテナー自身のパッチのほとんどがレビューおよび分析されていないことです。 すでに独裁のように見えます。 平等な権利を持つ「フラット」システムには、このような欠点はありません。



当然のことながら、Debianコミュニティでも、 メンテナーのいないモデルへの切り替えについて議論しています。



Daniel Vetterは、現在の階層構造の代わりに、開発者がコミットする平等な権限を持つメッシュネットワークのようなものを検討することを提案します。 彼は、時間の不足について不満を言うと同時に、誰も信用できないと言っているメンテナーは、実際に仕事をうまくやっていないと考えています。



より多くの人々を信頼する必要がありますが、 git revert



を実行する準備をしてください。 メンテナーは、開発者にサービスを提供しているのではなく、開発者にサービスを提供していることを覚えておく必要があります。