リナス・トーバルズのリーダーシップスタイル：スケールで出荷するベニャ独裁者

主要事実：リナス・トーバルズ（1969年12月28日生まれ、ヘルシンキ）は、1991年にヘルシンキ大学の学生としてLinuxカーネルを作成し、GPL v2の下でそれをリリースしました。彼は2005年4月にLinuxコミュニティがBitKeeper アクセスを失った後、Gitを作成しました。10日間でその中核を書きました。Linuxはパブリッククラウドサーバーの80%以上、世界のトップスーパーコンピューターの97%、およびおおよそ30億個のハンドセットのAndroidデバイスを実行しています。トーバルズはLinuxカーネルのBDFL（Benevolent Dictator For Life）であり、Linux Foundation Fellow です。2018年9月、彼はLinux Kernel Mailing List上の敵対的なコミュニケーションのためのパブリック謝罪を発行し、短い休暇を取り、プロジェクト全体で採用されたCode of Conductで戻ってきました。

BDFLドクトリン（トーバルズスケール出荷モデル）

BDFLドクトリンは、単一の技術的に信頼できる創設者がコードベースを最終マージ権限の下に保持するリーダーシップ構造ですが、事実上すべての日々のレビューを信頼できるサブシステム管理者に委任します。採用の採用です。雇用関係のない場合でも、実際には規模を合わせた一貫した製品を生成することができます。基準は目に見えて一貫して、透過的に適用され、散発的に行使されるために — 委任がデフォルト、中央機関が例外 — 数千の貢献者が実際にそれに実現するときに。

1991年8月25日、ヘルシンキ大学の21歳の学生がcomp.os.minixニュースグループにメッセージを投稿しました。「フリーのOS（ただの趣味、gnu のような大きく専門的ではない）を386（486）AT クローンのためにやっています。」彼はそれに署名しました。リナス・トーバルズ。

35年後、そのホビーOSは世界のトップスーパーコンピューターの97%で実行されています。世界中でクラウドサーバーの大部分を備えています。Androidは、約30億の活動的なデバイスで実行され、変更されたLinuxカーネルの上に構築されています。Google、Amazon、Meta、およびほぼすべての主要な技術企業の下のインフラストラクチャは、その1991年のUsenet投稿にトレースバックするコードを実行します。

リナス・トーバルズはこのプロジェクトをオルグチャート権限、公平なインセンティブ、または正式な管理構造でリードしませんでした。彼は技術的な信頼性、プロジェクトを構造的に開いたままにしたライセンス、そして他の人が合意に達することができない場合に最終的な決定を行う意思を通じてそれをリードしました — すべて一流の仕事を保持し、結果のリアルな商業的関心を保持していない間。

これがどのように機能し、どこで中断するかを理解することは、それを超えて持続するものを構築しようとしている工学的リーダーに有用です。

リーダーシップスタイルの分析

55/45の分割はすべてのコンテキストで安定していません。コミュニティがメリトクラシーを信頼するとき、ベニャ独裁者の役割は後退し、サブシステム管理者はほとんどの決定を処理します。何か議論になったとき、バランスシフトとトーバルズステップインがシフトします。その動き — 委任がデフォルト、中央機関が例外 — はプロジェクトが、トーバルズを瓶として行かずに、スケールで成長することを可能にします。

主要なリーダーシップ特性

リナス・トーバルズをリーダーとして定義した3つの決定

1. 1991年のUsenet投稿が一体でした

トーバルズは静かにLinuxを構築し、それが完了したときにリリースしました。代わりに、準備ができる前にニュースグループに投稿し、正確に趣味プロジェクトとして説明し、フィードバックを求めました。その決定 — 最初にリリースして、ポーランドを最初に完璧にして発表するのではなく、現在、その名前と業界を持つ開放ソース開発のモデルを設定しました。

初期のコミュニティは大きくありませんでした。しかし、それは、トーバルズが働いていた問題に技術的に能力がありアクティブだった人を含みました。数か月以内に、彼が決して満たされなかった人の寄与は、彼が単独で改善できるより速くコードを改善していました。プロジェクトは単に成長していませんでした — それ自体から入力を改善していました。彼ができませんでした。

トーバルズをリーダーとして逃すほとんどの人々が逃すもの。彼の主要なレバレッジポイントは彼の独自のコードではありませんでした。他の人のコードが彼のプロジェクトを改善することができるコンテキストを作成しています。彼が基準を設定し、最終的な権限を保持し、数千の人がお互いに直接調整する必要がなく貢献できるようにしました。Linuxの開発モデルの網路アーキテクチャ — 分散貢献、明確な基準、中央最終権限 — は、他にできた組織設計決定です。

今日のオペレーターの場合、質問は、あなたの技術文化が貢献を増加させまたは集中させるために設計されているかどうかです。ほとんどの技術組織は、容量を追加するためにヘッドカウント追加。トーバルズは、周辺寄与者が彼らの貢献に比例する管理オーバーヘッドを必要としないモデルを構築しました。Jeff Deanはスケール時にGoogleで同様のことを達成しました。他にはなく、共開発コミュニティのダイナミクスでしたが、設定技術基準が非常に高いこと。他のエンジニアはあなたのトラブルシューティング標準の直接管理ではなく、あなたのリーダーバー向上に彼らの仕事を整列させた。これは構造的に珍しく、研究価値があります。

2. GPL v2を選択：Linuxを永遠に無料で保つ

1991年、トーバルズはLinuxをGNU General Public Licenseバージョン2の下でリリースしました。Linux Foundation、2000年に設立され、その後、彼が構築したエコシステムの管理者になりました。その決定は、他のテクニカルな選択よりもはるかにはるかに、その後に続くすべての形を決定しました。

GPL v2は、GPL でライセンスされたコードから派生したソフトウェアを配布する人は、同じライセンスの下で彼らの変更をリリースする必要があります。商用製品でLinuxを使用できます。変更できます。しかし、その修正は所有できません。これはどの単一企業も、Linuxを取り、彼らの独自の目的のために改善を追加し、コミュニティとこれらの改善を共有することを拒否するのを防ぎました。

GPL v2がなく、IBM、Red Hat、Google、Amazonはそれぞれ独自の改善でLinuxを取り、互換性のないバージョンを作成しました。カーネルは分裂していました。単一のコードベースへのコミュニティ投資は失われていました。1000人の寄与者が共有の基盤の上で構築からのデミングスタイルの累積改善が停止していました。

トーバルズはこれが意図的な選択であると明示的でした。彼はまた、Free Software Foundation は時々主張するように機能しないと明示的でした。彼はカーネルスペースとユーザースペースが明確な境界を持つことを保持しており、Linuxで実行されるユーザースペースプログラムは派生の作品ではないこと。その実用的な解釈は、GPLの要件を独自のコードで発動することなく、Linuxの上に大規模な商用エコシステムを構築することを許可しました。

リーダーシップレッスンは、オープンソースのライセンスについては具体的ではなく、後続の選択肢を作成または禁止するかどうかを創造する構造的決定についてのみです。トーバルズは1991年に、すべての後続選択を制約する決定をしました — しかし制約は、Linuxをそれ以上もの時間で価値を作成する方向に正確でした。

3. BitKeeperが崩壊した後、10日間でGitを作成する

2005年4月、Linuxカーネル開発コミュニティはBitKeeper、彼らが使用していた独専的バージョン管理システムへのアクセスを失いました。BitKeeperの所有者との紛争後、ライセンスは失効しました。トーバルズは、プロジェクトがバージョン管理なしになる前に48時間警告されていました。

彼は既存のソリューションを評価できました — CVS、Subversion、何でも利用可能でした。代わりに、彼はLinuxカーネル開発が実際に機能した方法のために具体的に設計されたスクラッチから新しいバージョン管理システムを書くことを選択しました。分散、中央サーバーなし、数百の寄与者から数千のパッチを処理するのに十分な速度。そしてマージ履歴の処理に正しい。

Gitのコアは10日間で書かれました。これはLinuxカーネル自体と共にカーネルの下のインフラストラクチャの下でホストおよび維持されます。Gitを使用した最初のLinuxカーネルのコミットは2005年4月16日に発生しました。1.0リリースは2005年12月に来ました。

Gitはソフトウェア開発での支配的バージョン管理システムです。GitHub、Gitの上に構築された、2025年に1億人以上の開発者と420万以上のリポジトリを持っています。トーバルズがLinuxカーネル開発のために設計したワークフローモデル — リポジトリの分散、ローカルコミット、明示的なマージ — はほぼすべての専門的なソフトウェア開発の基準になりました。

意思決定プロセスはここに検査する価値があります。トーバルズは具体的な問題を持ち、実家の期間限定をし、特定のスキルセット既存のツールが満たさないこと。そして既存のものを調整するか正しいものを構築する選択。彼は何か良い、素早く構築し、それは問題を数十年続いたのに駆り立てられた。それはいない決定メイキングスタイルを利用可能にします。実際のスキル必要：新しい解決策が既存のものより多く価値があるメッセージに認識するというもの。その後期限より迅速にそれを実行します。

あなたの役割でトーバルズがすることは何か

CEOの場合、トーバルズのモデルは、あなたの組織のアーキテクチャが分散貢献または中央集約化貢献を可能にするかどうか尋ねることを示唆しています。ほとんどの企業は意思決定を構築しました。これはエグゼクティブレイヤーでボトルネックされます — 重要なものはすべてのサイン必要です。少数の人から。トーバルズは、1000人が毎日独立した決定を行うシステムを構築しました。中央当局は交差する決定に従事するだけです。これには投資が必要です。分散意思決定を安全にする基準とノルム。しかし、レバレッジが膨大です。エグゼクティブボトルネックに追加することなく、より多くの決定が正しく行われます。

COOの場合、Gitのオリジンストーリーはあなたのインフラストラクチャとツールの決定に適用する価値があります。クリティカルな依存が失敗の場合、リフレックスは最も近い置き換えを見つけてください。トーバルズがより困難な質問を求めました。あなたの実際のワークフローのために設計されたシステムはどのように見えますか？その質問は回答遅く、ツール近い十分なツールの代わりに一致するツール生成することより遅く。あなたのチームが構築した解決策のために作られていない2-3の場所を特定してください。Gitスタイルの再デザイン質問はそこで質問する価値があります。

プロダクトリーダーの場合、保守可能性を超える速度の原則はテクニカル負債の決定に直接適用されます。トーバルズは、直接的な問題を解決するが、将来の複雑さを作成するパッチ一貫して拒否します。最も製品チームは反対方向の取引をします。出荷の速度、クリーンアップの後方。これは初期段階でのしばしば正しい呼び出しです。しかし、規模で、「出荷の速度」決定の累積複雑さは、将来のベロシティの制約になります。現在のスプリント容量の何パーセントが働いているかあなたのチームに尋ねてください。6か月前のより厳密な基準を保有していなければ存在しないのか。その答えはトーバルズの基準を適用する位置にあるかどうかを教えます。

営業またはマーケティングの場合、オープンソースコミュニティモデルにはパートナーと生態系開発での直接的な類似性があります。トーバルズは、人々が貢献する場所でプロジェクトを構築しました。彼らは貢献から価値を受け取ります — Linuxへの彼らの改善はまた、彼らが依存するシステムを改善します。パートナーのエコシステムを構築する場合、パートナーが、関係がジェニュイン彼らのプロダクトをより良くするため、または摩擦に対するトランザクション・インセンティブを作成したため、貢献するかどうかを尋ねてください。最初のタイプのエコシステムは化合物です。2番目のタイプは継続的なメンテナンスが必要です。

トーバルズモデルをどのようにReworkが装備させるか

トーバルズのモデルは、あなたの技術チームが可能性が不足している2つのもので実行されます。メリトクラティックコードレビューと出荷規律。カーネルに、あらゆるパッチは可視の各拒否が公開。すべてのメインテナーのスループットは同じバーに対して測定されます。ほとんどのソフトウェア組織はJira票とスタンドアップでこれを複製しようとします。アーティファクトはアクティビティを追跡するが、レビューの基準が実際に一貫しているおよび出荷スピードが少数の寄与者で集中するかどうかかくします。Reworkは実際のワークフロー全体で処理可能性を与える技術リーダー。PR-to-Ship cycleの時間メインテナーあたり。レビュー負荷配布。パッチはマージ前に停止します。スポイントはレビューでマイクロマネージメントすることではありません。あなたのチームのメリトクラシーが本当であるか無音のために見えることです。少数のシニアエンジニアが標準を持ってわかるために。LKMLはシステムレコードを作成しました。コミュニティは自己補正できました。Reworkはこれを非常に多くの人々がそれを選ぶOpt‐in されていないという内部の技術チームのために行いました。LKMLの摩擦。

注目すべき引用と教室の外のレッスン

トーバルズは2012年のTEDトークで言った。「私は本当に怠け者で他の人が実際にしていることに信用をとるのが好きです。」それは自由な謙虚さ — それはレバレッジモデルの正確な説明です。彼は他の人を開発作業を行うシステムと基準を構築することに35年を費やしてきました。彼自身としての最終フィルタと信用受信者。那是规模:あなたのビジョンが、彼らは彼ら独自の動機を実行してください。

LKMLで数年にわたってさまざまな形式で、彼はコードを拒否する理由について明示的になった。著者が間違っているため。コードはLinuxコミュニティで数十年中、維持されるため、オリジナルの会話にいなかった人で理解する必要があります。「話して安いです。私にコードを見てください。」これは計画の却下ではありません — これは、本番で作業するコードのみ証拠が実際に重要だという声明です。サウンド計画で回避される思想は好ましいです。世界のスーパーコンピューターの97%で実行されるコードは、かなり狭いカテゴリです。

2018年の公開謝罪、彼はカーネルから1か月離止したときと、彼が戻ってきたとき、Code of Conductを場所に戻ってきたときも啓示的でした。「私は私の動作のいくつかを変更する必要があり、傷つけた人々に謝罪したいのです。そして可能性がある、カーネル開発から軍隊。」彼は過去の動作を防衛しませんでした。彼はそれが害があり、変わったことを確認しました。信頼失うことなくプロジェクトを主導すること取り戻すことが、その意思であり、公開で見直しを変わることでした。

このスタイルが壊れるところ

トーバルズが数十年実行されたメーリング・リスト炎文化は、弱いコードと弱い思考をフィルタリングするのに効果的でした。また寄与者でフィルタリングするのに効果的でした。誰が彼らの仕事が公開で彼らの公開プロジェクト作成によってシュレッド されるために準備ができていますか。2018年のCode of Conduct採用は、カーネルコミュニティが新規参入者、女性、および具体的なテクニカル原型に収まらなかった人に敵対的であったとの批判の後に数年後来ました。トーバルズはこれが本当の問題であり、苦情から人々が批判を取れなかったことではなく、個人的な批判を確認しました。

BDFLモデルはP&L圧力と雇用関係を持つ組織へ移されません。トーバルズは、寄与者があります。外出しません。彼はそれらの寄与者は彼を支配する力を持つため、彼がそれがするため、彼がそれをしています。Elon Muskはいくつかの社内で彼が管理する企業の中で同様にブラント技術権限を適用しますが、それの背後にある雇用レバレッジで — より迅速な短期合意とはるかにより多くの機関的脆弱さを生成トーバルズモデルより場所に居座る投票による。寄与者は単に出荷を停止できます。社内では、同等の状況 — CTO副会長の決定を定期的にオーバーライド — は、セットアップの問題を作成し、委任する信頼を破壊します。

そして彼の具体的な組み合わせ — 比較のない技術的信頼性プラス明確な最終権限プラス数十年の一貫した公開行動 — はほぼ複製不可能です。構造的要素を採用します。分散貢献、メリトクラティック基準、中央最終権限を採用できます。同じ合法性ベースなしで。これはモデルが実行する方法を変わります。

---

関連する技術的なリーダーシップに関する読み取り:ワーナー・ボーゲルス・リーダーシップスタイル、マーティン・ファウラー・リーダーシップスタイル、そしてアンディ・グローブ・リーダーシップスタイルを参照してください。