米Sun Microsystems, Inc.で，「チーフ・オープンソース・オフィサー」という肩書きを自ら名乗るSimon Phipps氏に，Sunのオープンソース活動の現状を聞いた。同氏は，Sun社内でオープンソース活動の普及を進めた実績から，「オープンソースにできないソフトウエア開発プロジェクトは，事実上ない」と言い切る。オープンソース化に伴う動きで「もしSunに間違ったことをする社員がいたら，遠慮なくオンブズマン制度に基づいて報告してほしい」とまで言う。OpenSolarisの組み込み分野への適用を進めていることについてもコメントした。（聞き手は，星 暁雄＝Tech-On! ）
---いつから「チーフ・オープンソース・オフィサー」を名乗っているのか。また，その役割は。
Phipps 3カ月前からだ。
Sun社の設立から24年が経つ。その間，開発者コミュニティとSun社は常に一緒に仕事をしてきた。
オープンソースという言葉が登場したのは1998年だが，Sun社はオープンソースに取り組んだ最初の企業の1社だ。Mozillaプロジェクトに資金を提供し，約50人の開発者が参加した。この動きがトレンドを作り，それから7年，Sun社のオープンソース・プロジェクトのポートフォリオは成長を続けている。
私の役割は，オープンソースの開発部門を直接指揮することではない。今では，多くのオープンソース・プロジェクトが大規模な組織に成長している。例えばOpenSolaris（Sun社の主力OSである「Solaris10」のソース・コードを2005年6月よりオープンソース・ソフトウエアとして公開したもの）は1000人以上のプロジェクトだ。このような状態では，グループ同士を結び付ける役割を果たす人間が必要になる。
全社横断的な「オープンソース委員会」を開催
私の役割は，それぞれのグループに参加し，ベスト・プラクティス（成功事例に関する知識の蓄積）を浸透させ，一貫性が保たれるようにし，そして新規のオープンソース・プロジェクトが迅速かつ効果的に立ち上がるよう手助けすることだ。
Sun社では，45日ごとに社内のオープンソース委員会を開催している。Sun社でオープンソースを推進するリーダーを集めた組織で，前回は約100人が集まった。
---あるソフトウエア開発プロジェクトをオープンソースにするかどうか，という判断はどのように行えばいいのか。
Phipps 出発点は，協力し合うコミュニティが，いかにしてより良いソフトウエアを開発できるか，ということだ。
質問に対して，逆方向から考えてみよう。私は社内の開発者たちに対して「なぜオープンソースにしないのか」と問い掛けてみた。合理的な理由を持っていたグループは，ごく少数だった。
「オープンソースの三角形」で考える
私たちは，開発者グループと様々な議論を繰り広げた。オープンソースに関して議論するには，図1[拡大表示]のような三角形のモデルを使う。3つの頂点が，ライセンス，ビジネス・モデル，ガバナンスを示している。
あるグループが，自分たちのプロジェクトをオープンソースにしたい，と相談してきた場合は，どのライセンス方式を適用するかという検討から始める。最大の自由度を得られるライセンス方式を探す。
ライセン方式スに関しては，次のようなモデルを用意している。（天秤の図を描きながら）すなわち，「イノベータの自由」と「コミュニティのコモンズ（共有財産）」のバランスを判断するというモデルだ。代表的なオープンソース・ライセンスを見てみよう。GNU General Public License（GPL）は，コミュニティのコモンズの側面に偏っている。BSDライセンスは，イノベータの自由の側面が強い。Mozilla Public License（MPL）は両方のバランスが取れている。
私たちは，ほとんどのプロジェクトがMozilla系のライセンス方式を選択すると考えている。実際には，私たちは3系統のオープンソース・ライセンス方式を全部使っている。Project Looking Glass（Sun社が開発中の3次元デスクトップ環境）はGPLでライセンスしている。Jini（Sun社が開発した分散オブジェクト技術）は，最近BSD系のApache Software License（ASL）でライセンスした（IT Pro関連記事）。Apache Tomcat（Servletコンテナ）やApache Derby（組み込みデータベース）と同様のライセンスだ。OpenSolarisやProject GrassFishで使っているCommon Development and Distribution License（CDDL）はMozilla系だ。
ガバナンスも重要だ。全く新たにコミュニティを立ち上げる場合は，ガバナンスをどのように構築するかを考える。まず，コントリビューション中心，という考え方がある。コミュニティの中で実際にソース・コードを提供する人を重視する考え方だ。透明性も重要だ。意思決定がなされた場合は，コミュニティの全員に知らされなければならないし，意思決定の過程も周知徹底されている必要がある。
最後に，ビジネス・モデルも大事だ。オープンソースは慈善事業ではない。もちろん，社会的な効用はあるが，それはビジネス・モデルが機能したことに伴う副作用なのだ。
オープンソース・プロジェクトの運営では，この三角形の範囲内での自由度がある。この中で，独自のやり方を考えていく訳だ。
---それだけの議論を重ねた上で，なお「オープンソースにはしない」という決定を下す場合もあるのではないか。
Phipps 私が知る限りでは，ない。もちろん，まだ意思決定に至っていない場合はあるが。Sun社のCOO兼社長のJonathan Schwartzは「究極的にはすべてがオープンソースになる」と言っている。
