今日、あなたはおそらくLinuxを使ったことがあるでしょう–特に、iPhoneを持っていない人は。 そして、今日 Web を閲覧した場合、訪問した Web サイトも Linux で提供されていた可能性が高いです。
Linux はオペレーティング システムですが、Microsoft Windows や macOS などのソフトウェアとは異なり、Linux はボランティアによる自主組織コミュニティによって開発されてきました。 これは、…
- 地球上のすべての Android phone とタブレット
- 世界のサーバーの 66%
- スーパーコンピューター上位 500 の 100%
このテクノロジーは、厚いポリシーブックと何層ものマネジメントから成る組織的チームから生まれたのではありませんでした。 この投稿では、これほど本質的で複雑かつ重要なテクノロジーが、従来の管理構造なしに、どのようにして効果的に生み出されたのかを見ていきます。 その前に……
- なぜ Linux カーネルはそれほど印象的なのか? G. Pascal Zachary の言葉を借りれば、オペレーティング システムのカーネルは、「いつでも2階の家族に仕えるほど勤勉で、夜も昼も待機し、あらゆる要求を処理する家事参謀」に例えることができます。 カーネルは、どんな事態に陥ってもマシンを動かし続ける。 コンピュータが一度に1つのアプリケーションだけを実行できた世界から、今日の世界への本質的な飛躍でした。
- そして、開発者の管理について、とにかく何がそんなに難しいのか。
- How policy, process and 15,000,000 lines of code are documented
- How is communication between 1000s of developers are managed
- How critical decisions are (not) made
- How contributors are oriented around a strong common goal
- Is this a repeatable process?
なぜ Linux カーネルはそれほど印象的なのか? G. Pascal Zachary の言葉を借りれば、オペレーティング システムのカーネルは、「いつでも2階の家族に仕えるほど勤勉で、夜も昼も待機し、あらゆる要求を処理する家事参謀」に例えることができます。 カーネルは、どんな事態に陥ってもマシンを動かし続ける。 コンピュータが一度に1つのアプリケーションだけを実行できた世界から、今日の世界への本質的な飛躍でした。
UNIXをベースにしたLinuxカーネルは、1990年代初頭にリーナス・トーバルズによって開発されました。
1991 年までに、Torvalds は最初のバージョンをリリースし、わずか 10,000 行のコードで、上記のような謙虚な電子メール発表でソフトウェア開発コミュニティの興奮に火を付けました。 実験をする気があれば、ユーザーは何かが壊れているのを見つけたら、パッチを組み立て、ソフトウェアをどのように改善するかを議論することができました。
この記事では、長年にわたって進化してきた Linux カーネル プロジェクトをサポートするために必要なプロセスやポリシーについて見ていきます。
正式なプロセスなしに、21 歳のコンピューター サイエンス学生だったトーバルズは、どのようにしてカーネル プロジェクトを高みに導いたのか……
そして、開発者の管理について、とにかく何がそんなに難しいのか。
Genecaの調査によると、ビジネスおよびITの幹部の75%以上がソフトウェア プロジェクトは失敗に終わると考えているそうです。 信頼性の高いソフトウェアを作成し、その開発者を管理することの難しさから、数え切れないほどの管理本、生産性研究、およびリーダーシップのフレームワークが生まれました。
「ソフトウェアの複雑さは、すべてのパスをテストすることが不可能なことを意味します」と Kynetix CEO Paul Smyth は Finextra で書いています。 「ソフトウェア アプリケーションは氷山のようなもので、その 90% は目に見えません。 アプリケーションの主要な複雑性は、喫水線の下にある」
CRM や Microsoft Windows などのオペレーティング システムなど、大きな規模のソフトウェア プロジェクトは、一人の人間の頭の中に収まるには大きすぎるのです。 多くの貢献者による知識の共有とコラボレーションが必要なのです。 これは、開発者がアプリケーションの専門的な部分に取り組む一方で、自分の仕事が全体にどのように影響するかを理解する必要があることを意味します
ゼロからオペレーティング システムを構築していた 250 人の Microsoft ソフトウェア開発者チームのマネージャーは、「1 人の頭ですべてを理解できない」と述べた、と G. Zachary は Show stoppers!
プロジェクトが大きければ大きいほど、変更の実行は遅くなります。 Steve McConnell 氏の研究はこれを証明し、10,000,000 行を超えるプロジェクトでは、コードが書かれる速度が 5 ～ 10 倍遅くなることを発見しています。 さらに、Microsoft の開発プラクティスの研究では、1,000 行のコードごとにおよそ 10-20 のバグがあることが明らかになりました。
プロジェクトの規模と貢献者の数にもかかわらず、Linux カーネルの開発は迅速に行われ、その大規模で熱狂的なユーザーベースはバグをキャッチし、パッチを書き、迅速に改良版を出荷します。 現在では、より成熟した段階となり、スマートフォンの 80% とインターネット サーバーの大部分に利用されているため、望ましいリリース期間は 8 ～ 12 週間となっています。 各リリースで、カーネルは 2,000 人の開発者から平均 10,000 パッチを受けており、すべての開発者は 20,000,000 行以上のコードと格闘しています。 このレベルのコラボレーションと生産性を組織化するために必要な管理手法やプロセスとは何でしょうか。 それは、部門長やビジネス書の著者によって書き上げられたものではありません。 プロジェクトの「慈悲深い独裁者」である Linus Torvalds 氏の指導のもと、有機的に発展していきました。 不機嫌で反社会的なハッカーが、ほぼ 20 年間にわたり、何千人もの開発者間の論争、貢献、コミュニケーションをどのように管理していたのか、
How policy, process and 15,000,000 lines of code are documented
従来の組織とは異なり、新しいカーネル開発者は厳密にコミュニティに「オンボード」されませんが、入門ドキュメントを完全に読んで理解したことが求められます。 カーネルプロジェクトが文書に重点を置くのは、技術的な複雑さと開発者の膨大な数のために必要なことでした。
多数の FAQ、ハウツー、および入門ガイドがカーネルの文書リポジトリにあり、世界中のカーネル開発者によって作成および保守されている wiki にも存在しています。
文書が書かれ改善される方法は、カーネルが共同して、オープンに、そして段階的に開発される方法を反映しています。 Linus の法則をコンテンツ編集者が理解しやすいように曲げると、「十分な眼球があれば、すべてのタイプミスは明白である」ということになります。
“A guide to the Kernel Development Process” のインデックスページには、次のような段落があります：
「この文書の目的は、開発者 (とそのマネージャー) が開発コミュニティと最小限のフラストレーションで作業できるようにすることです。 これは、Linux カーネル開発 (あるいは、一般的なフリーソフトウェア開発) に精通していない人でもアクセス可能な方法で、このコミュニティがどのように機能しているかを文書化する試みです」
git バージョン管理システムや、メーリングリストへのパッチ送信方法についての生来の知識を持っている人は誰もいません。 同じ基本的な情報を一度に一人に説明しても、スケールしません。
How is communication between 1000s of developers are managed
開発者間の会話は、カーネル開発メーリングリストという公開の場で行われました。 今日に至るまで、電子メールはそのシンプルさゆえに好ましいツールです。 これらのメーリング リストはアーカイブされ、整理され、生きたドキュメントと歴史の体を構成していました。
公の場でコミュニケーションすることの効果は、今日 Slack などのツールを使う利点と似ています – どんな情報も蒸発せず、安全で検索可能になっているのです。 しかし、このような情報のファイアーホースを管理するために、カーネル プロジェクトはコミュニケーション ポリシーを開発し、ドキュメントの一部として配布しました。
このような規模でのコミュニケーションとコラボレーションはインターネット以前には不可能でしたので、 初期のプロジェクトではコミュニティ管理、エチケット、 コードプレゼンテーションの問題に対する迅速で有効な解決策を書いて配布することが必要でした。 これは、パッチは添付されず、プレーンテキストで電子メールで送られなければならないことを意味します。 パッチは 1 つの電子メールにつき 1 回に抑え、特定のコーディングスタイルのガイドラインに従わなければなりません。 ひとつのエラーが波及して将来的に不安定なコードを生み出したり、多くのテスターや開発者の時間を無駄にしたりするような空間でのエラーを減らすのに役立ちます。
How critical decisions are (not) made
トーバルズの言葉を引用すると、「ゲームの名前は、決定を下すことを避けることです。 特に、「(a)か(b)を選べ、どうしても決めてほしい」と言われたら、経営者としては困ってしまうでしょう。 管理する側は、自分より詳しいはずなのに、技術的な判断を求められても、お手上げです。 あなたは明らかに、彼らのためにその決定を下す能力がないのです。” – Linux Kernel Development Documentation
管理階層を避けるのと同様に、Linux プロジェクトには明確なルールと文書があり、議論や討論、あるいは (多くの) メーリングリストの炎上などを必要とせずに決定を下すのに役立ちました。 しかし、可能なことは、意思決定の負担を否定するポリシーを作ることです。
「したがって、大きな決定を避けるための鍵は、取り返しのつかないことをするのを避けることだけになります。 逃げ場のないコーナーに追い込まれないようにしましょう。 追い詰められたネズミは危険かもしれませんが、追い詰められたマネージャーは哀れなだけです」
Show Stoppers！では、ビル・ゲイツの哲学が似ていることを明らかにしています。 彼は「プログラマを賞賛し、プログラミングの経験がないか古い知識を持つプロの管理者が支配する状況を避けるために、管理とプログラミングの両方ができるプログラマを必ずプロジェクト担当にした」のです。
How contributors are oriented around a strong common goal
Linux の場合、多くの人気のあるオープンソース プロジェクトと同様に、カーネルは貢献者の大きなグループによって共同で設計されて出現したのではなく、これまでの作業の強力な基盤を不安定にする決定をせずに段階的に改良されました。 これは、経営における意思決定に関する Torvalds の哲学とよく結びついていますが、コード自体に埋め込まれている哲学とも結びついています。 UNIX の哲学に明示されているように、
「ソフトウェア、たとえオペレーティング システムでも、早期に、理想的には数週間以内に試せるように設計し構築せよ。 不器用な部品を捨てて、再構築することをためらわないこと」
Torvalds と Raymond (Torvalds のコミュニティ構築の成功を再現しようとした人) は、早く、頻繁にリリースすることが、将来性を見出せるような刺激的で成長するプロジェクトに貢献者を結集する助けになると発見したのです。 Raymond氏は、プロジェクトが世に出たときに失敗してはならないことを、次の2点に集約しています。
- Run
- Convince potential co-developers (user) that the project can be evolved into something great soon
The many of today’s startups launch with these same principles – Process Street includes:
上記は2014年の Process Street です。 8179>
Is this a repeatable process?
表面的には、最も複雑な人類の創造物の1つが突然組み合わされることは、錬金術のように見えます。 しかし、構成要素を分解することで、根底にあるプロセスを容易に見ることができるのです。 エリック・S・レイモンドは、『カテドラルとバザール』を執筆した当時、同時にオープンソースの電子メールクライアントの開発を進めていた。 それをオープンソース化することにより、Raymond はコミュニティの関与とカーネル プロジェクトの最終的な成功を再現しようとしていました。