LinuxCon2010/10+ Years of Linux at IBM
10+ Years of Linux at IBM
Dan Frye, IBM Vice President, Open Systems Development and Linux Foundation Board Member
IBMがLinuxに取り組んだ10年をふりかえる
当初、Linuxはエンタープライズのエッジで使われていた
今ではミッションクリティカルなコアでも使われている。
IBMでも日本の銀行などでシステムを組んだりして、主要プロダクト，システムであたりまえのように使われている。
1999年にIBMでLinuxの組織を作った。
そこから10年、多くの失敗をした。
本にするとすごい量になるだろう。
Linuxはグローバルなビジネスのツールとしても機能しだした。
今では欠かせないものだ。
1998年、インターネットブーム
コミュニティの存在がこれまでにないものになってきた。
たとえば、ファイルシステムの開発者が世界各地で改善を続けていた。
真の意味での「イノベーション」がOSSで起こっていて、革新の速度が変わった。
コミュニティがビジネスにおけるゲームを変える原動力であると考え始めた。
1998年9月、小さなチームのリーダーだった。
Linuxが将来のプラットフォームとして注目されていた。
当時はばかげた考えといわれるぐらい、誤解が多かった。
当時の上司に、Linuxとは何なのか、誰がコントロールしているのか、を説明する必要があった。
Linuxは90日間でIBMで「戦略」として採用された。
お客様の中でも使われるようになった。
IBMよりも先に、お客様がLinuxを知るようになった。
1999年：IBM gets started
OSSのコミュニティはひとつではない。
リーダーシップ、やり方も違う。
カーネルの中でも、メモリマネジメントなど、機能が違うと違うと知った。
次に、教育について考えた
ミスしたことが受け入れられた。
- 1999年9月に、IBMの戦略がより真剣な方向に向いた
お客様の要望は、想像したよりも大きかった。
もっと投資が必要、よりリソースをさくことが必要だった。
お客様からの信頼も得られてきた。
2000年 Linuxに参入し、お客様からの信頼も得られてきた。
カーネルへのコントリビュートを始めた。
最初はカーネルから離れて別のコミュニティに貢献していた。
Andrew Mortonにも、カーネルへの貢献が遅いと指摘を受けていた。
「本格化」から「加速」に方針転換
IBMの基調講演のなかで、10億ドルの投資を発表。
コントロールではなく、貢献であると明確に方針を示した。
IBMの主要な部門にはLinuxのチームが作られて、
Linuxのビジネスができるようにした。
マーケティング部門もそう。
Lesson Learned #1 : Develop in the Open
- ジャーナルFS
最初、うまくいかなかった。
完成した後でソースを出した。
IBMのファイヤウォール内で作ってから公開というパターン
カーネルコミュニティの反応は、面白い
コミュニティは、インクリメンタルに作り上げていく。
初期で発表して、みんなで作っていかなければならない
- スケーラビリティ
複数のCPUで動かすための対応
メーリングリストでの議論を進めていく中で、いろいろと違和感があった。
このことについて考えたとき、やり方が間違っていた
社内でのコミュニケーションを禁止した。
コミュニティ向けのE-mailのみでやり取りするようにした。
LinuxではSMPではうまくいかないとLinusも言っていた。
参加の仕方がわるかった。
これをしっかりと見ていけば、問題は解決していく。
-
- 早めに目標を設定して
- 参加して
- インクリメンタルに
- 個人として参加し、迅速にフィードバックを反映していく。
2003年 カーネル2.6の開発に参画。
エンタープライズのエッジから、ミッションクリティカルな分野、Webアプリケーションなど、主要製品に入り込むことができると考えていた。
この時点では、IBMがLinuxについていけてなかった。
開発コミュニティが先を行っていた。
さらなる投資を決断、CEO、CTOに説明、
Fortune500企業にもLinuxが有用であることを説明していった。
いずれ、Linuxが世界の標準になることを推進
そのことで、信頼を勝ち得た。
Lesson Learned #2 : Don't reinvent the penguin
ここで学んだのは、十分広い分野をサポートしていたと考えいたのは間違いだった。
コミュニティに貢献する中で、分野は広がっている。
IBMがサポートしていたアーキテクチャ、分野も、公開してみると、他のシステムにも広がっていくことを知った。
- スケジューラの改善
IBMの社員のコードがコミュニティで拒否されたが、
そこから提案のより改善されたコードが、コミュニティで作られた。
誰が作ったということは重要ではない。
結果にこだわるのであれば、コミュニティ全体の成果を考えることが重要であることを学んだ。
OSSディベロッパのマネジメントは時間がかかるが、個人、企業にとっても意味があることになる。
これは、コミュニティに参加することで得られるメリットである。
新しいプロジェクトを作るのではなくて、すでに活動を続けているコミュニティに参加し、そこで一緒により良いものを作るのが、最も効率的に成果を得られる。
経験のあるプログラマに手伝ってもらうには、参加しないといけない。
企業の開発者、経営者にアドバイスしたいのは、
「コミュニティへの参画が、最も効率が良い」と伝えたい。
2004年〜2005年
Linuxは特別プロジェクトとして開発するチームでした。
”Emerging Business Opportunity”
→重点的分野として、特別に短期的に投資するチームとなった。
Lesson Learned #3 : Work with the process
Linuxは責任者ではない。
影響力を持っているが、意思決定の責任は無い。
社長ではなく、裁判所のような立場が近いだろう。
会社として効果を得るには、コミュニティで信頼を得ることが必要だ。
コミュニティで信頼された開発者が、コミュニティの中で「議論」をしていかなければならない。
ハードウェアのサポートなど、コミュニティの中で仕事をしなければ取り入れられない。
ほとんどのこと（ロードマップなど）は予想ができるものである。
コントロールはされていないが、コミュニティの向かう方向は読めてくる。
IBMもコミュニティの進み方に慣れてきた。
ハードウェアのチームも心配しなくなった。
だいたいはきちんと対応できることがわかってきた。
ハードウェアはかなり早い段階でサポートしなければならない。
それで初めてpatchが受け入れられ、Linuxのベストのサポートが受け入れられるようになる。
