JavaWorld誌2005年2月号に掲載した「 特集２ Apache Incubatorのすべて」のうち、「 Part 1 Apache Incubatorオーバービュー」の内容を、Blog用にサマリしたものです。なお、掲載については、JavaWorld編集部の許可を得ています。
はじめに
the Apache Software Foundation（以下ASF）には、Apache Incubatorプロジェクト（意:孵卵器）と呼ばれるプロジェクトが存在する。その名の通り、ASFに参加するプロジェクトが一時的に所属し、正式なプロジェクトになれるよう孵化させるための機関だ。
なお、Incubatorを研究所や実験場と考えている方がいるようだが、それは間違いだ。ncubatorは、あくまでも通過機関であって、それ自身に開発能力はない。
ASFとはなにか
ASFの母体は、Apache HTTPサーバを開発しているプロジェクトだ。その後、オープンソースプロジェクトの健全な開発と利用を促すため、1999年にアメリカで設立された非営利企業だ。ASFの役割を理解するうえ重要な「Apache Way」と「Apache License」という2つのキーワードを説明する。
Apache Way
ASFの開発体制は、複数の開発者による”コミュニティ”をベースにしている。Apache HTTPサーバは、多くの開発者によって開発が進められてきたという歴史をもつ。そこから、多くのボランティア開発者が情報を交換し、パッチや新機能提案が集めることこそが、より良いソフトウェアにつながると考えられるようになった。ASFではこの考え方を”Apache Way”と呼んでいる。
このApache Wayを体現しているのがASFの組織体系だ。”meritocracy（実力・能力主義社会）”と呼ばれており、開発者の実力や貢献度に応じて4つに階層化されている。
1層目が、PMC（Project Management Committees）と呼ばれる存在で、開発プロジェクトの方向付けや管理を目的としている。PMCはトップレベルプロジェクト（TLP）ごとに存在すると考えてよい。最も多くのプロジェクトをかかえるのがJakartaプロジェクトのJakarta PMCになる。
2層目が、コードを書く”コミッタ”である。コミッタはメンバーが固定されており、ソースコードリポジトリにコミットする権限や専用のメールアドレスを与えられる。なお、PMCメンバーやコミッタは、投票によって決定される。その際の判断基準となるのが、開発者としての能力であり、プロジェクトへの貢献度だ。この投票やメンバーが足らなくなるたびに行われており、この制度によって、メンバーが入れかわりながらも継続的な開発を行うことが可能になっている
3層目が、バグレポートやパッチを送る”コントリビューター”で、誰でもなることができる。
そして4層目がソフトウェアを利用する”ユーザー”である。
もし、ASFに参加したければ、まずコントリビューターとして活躍し、認められれば、コミッタ、PMCメンバーと選出されていくことになる。実力さえあれば、誰もがASFのメンバーになることが可能なのだ。
Apache License
オープンソース界では知的財産権や特許の問題が話題になることが多い。しかし、これに独立したオープンソースプロジェクトが対応するのは難しい。そこで、ASFでは、配布ライセンスの提供だけでなく、コードを保護するための施策を用意している。
まず、ASF傘下のすべてのコードはASFに著作権があり、Apache License（現在は、バージョン2.0）の元に配布される。このライセンスは、ユーザーは配布されたコードの商用利用、改造、そして、（いくつかの簡単な条件を満たせば）ASFプロジェクトを取り込んだ製品を制限なく販売することが許されている。 GNU GPLなどのコピーレフトライセンスとは異なり、改変したコードを公開したり、オープンソース化したりする義務はない。そのために、商用利用しやすいライセンスといえる。
さらに、ASFのプロジェクトにコードを提供するためには、提供者がCLA（Contributor License Agreement）と呼ばれる合意書にサインを行わなくてはいけない。このCLAには、以前プロジェクトに提供したコードに特許が認められた場合でも、特許侵害でASFを訴えることができないという記載がされている。これにより、将来的な訴訟リスクを軽減させている。もちろんコミッタは、このCLAに必ずサインしている。
Apache Incubatorプロジェクトの役割
Incubatorは外部プロジェクトや新規プロジェクトをASFに参加させるために2002年10月に設立された。これ以降、ASFに参加したプロジェクトは例外なくIncubatorを通っている。Incubatorの目的は、前述したようなASFの文化や手法に、そのプロジェクトを適合させることだ。
Incubatorプロジェクトに参加するまで
ASFに参加したいプロジェクトは、IncubatorのWikiやメーリングリストを通じて、ASFと開発者コミュニティに提案を行う。これを受けて、コミュニティ内で、プロジェクトがPMCにふさわしいのか、受け入れられるのか、開発の方向性に問題ないかということが、オープンに議論される。
提案に際しては、"チャンピオン"と呼ばれている後援者と、スポンサーPMCを事前に決定しておく。
チャンピオンの目的は、プロジェクトがASFやコミュニティで受け入れられるように、初期段階でのコミュニケーションの醸成を行うことだ。具体的には、提案の作成支援やApache Wayの説明などを行う。チャンピオンはプロジェクトの成否について、特に責任を負うわけではない。
スポンサーPMCは、プロジェクトが正式に受け入れられた場合に所属したいPMCだ。Jakartaプロジェクトに参加したければ、Jakarta PMCがスポンサーとなり、トップレベルプロジェクトになる場合はASF役員会がスポンサーとなる。PMCは、プロジェクトに責任をもち、監督をおこなう。
この提案後、コミュニティによる投票が行われ、受理されれば参加が正式に参加が認められる。この段階からIncubator PMCの管理下となり、Incubatorプロジェクトに名を載せることになる。
Incubatorプロジェクトでの作業
Incubatorプロジェクトでは、参加が決定したプロジェクトに対して、Apache WayとApache Licenseの適用作業を行う。
まず、開発体制を決定するために、メンターとコミッタを決定する。メンターは、開発者のリーダーといえる存在で、コミッタとともに、通常は既存のコード開発者の中から選ばれることになる。なお、ASFにはコミッタは３人以上という規定がある。これが健全なプロジェクトに必要な最低限の開発人数なのだろう。次に、どんなコミュニケーションツールを利用するか決定する。WebサイトのURL、メンバーのメールアドレス、メーリングリスト、ソースコード管理、バグ管理のセットアップを行う。
そして重要なのが、著作権や知的財産権に関する作業だ。既存コードの著作権をASFに委譲し、Apache Licenseに従わなくてはいけない。そのため、すべてのコードにApache Licenseの文言を追加し、既存コードの提供者からCLAにサインをもらう必要性がある。この際、CLAが取得できない（コードの提供を拒否、連絡が取れないなど）場合は、該当コードを削除するか、新しく書き直すしかない。こういった作業は地道で、プロジェクトの規模や開発者の人数によっては数ヶ月に及ぶことになる。Incubator PMCでは、この過程を監査し記録する。こうしておくことで、後の著作権・知的財産権の問題を回避しているのだ。他にも、プロジェクト名が商標に違反しないことなども確認されている。
こうして、Incubatorで必要な作業がすべて終了すると、スポンサーPMCの合意（トップレベルプロジェクトの場合は、ASF役員会の合意）を得たうえで、晴れて卒業となるのだ。
Apache Incubator Projectの詳細
Incubatorのプロジェクト一覧には、現在「腑卵中」のプロジェクト、卒業したプロジェクト、そして腑卵に失敗したプロジェクトの一覧が乗っている。当然だが、IncubatorプロジェクトにはJava以外の製品も入っているので、なじみのない名前もあるかもしれない。
また、これからIncubatorに参加するかもしれない候補プロジェクトは、WhiteboardとかかれたWiKiサイトで見ることができる。”Project proposals”の部分に、MyFaces、iBatisといった、すでにIncubateに参加している過去の提案も残っている。
Geronimoを例にとり、Incubatorサイトの見方を説明しておこう。IncubatorにおけるGeronimoのページを見ることができる。
ここには最新のIncubatorの作業状態が反映されている。上部から、名称の決定、臨時の責任者、著作権、コミッタの決定、コミュニケーションツールの設定などが示されており、Geronimoの場合は、すべてDONE（終了）となっている。この項目の最後には、卒業が認められたかが記されている。Geronimoは、トップレベルプロジェクトとしてPMCの設立を行い、承認されたと書かれている。 これらの項目は、プロジェクトにより多少フォーマットや項目が違うが、基本的には同じような内容だ。
また、Geronimoは、JBoss Groupから、コードの類似により、違法性を指摘されている。この指摘を受けた書簡と返信した書簡も閲覧可能だ。そして、この件について徹底的な調査を行い、コード類似性の指摘には根拠がないと確認したことも明記されている。
まとめ
Incubatorの基本は、健全なオープンソースプロジェクトの環境作りだ。そのために、参加の手順、プロジェクトページの項目やステータス表記のための用語、レビュー体制、卒業のための条件など、事細かに定義されている。Incubatorでは、これらのドキュメントを「Incubatorが開発しているコード」と捉え、改善を行っている。ASFが長年かけてオープンソースプロジェクト育ててきた成果物だ。以下のURLから様々なドキュメントが参照できる。一読していただければ、さらに詳細について理解することができるだろう。
http://incubator.apache.org/index.html
http://incubator.apache.org/learn/index.html
また、オープンソースプロジェクトの重要性が増すにつれ、ASFの重要性も高まっており、同時にIncubatorが活躍する機会も多くなっている。Incubtorへの参加プロジェクトを見ていると、2つのパターンが見えてくる。
1つ目は、MyFacesやiBATISのように、ASFへ移行をしようとするオープンソースプロジェクト。これは、ASFが開発コミュニティとして非常に優秀だからだろう。
2つ目はベンダーによるプロジェクト。例えば、JackrabbitやMuse/Apollo/Hermesは、標準を狙う仕様提案のRI実装をベンダーのエンジニアが中心となって行っていこうとしている。Jackrabbit は、JCPのJSR-170のRIを目指しているが、実装の中心はJCPでのスペックリーダーを務めているDay Softwareだ。一方、MuseがOASISに提出されたWSDM/MuWSの実装で、ApolloがWS-Resource Framework、HermesがWS-Notificationの実装になる。WS-Resource FrameworkとWS-Notificationは、IBMやHPが中心となって2004年1月に提案したものだ。Muse/Apollo/HermesははHPが実装メンバーの中心になっている。また、BEAのBeehaiveのように、フレームワークの普及のためにASFに寄付している場合もある。
最後になるが、Incubatorを定期的にチェックしたい方は、メーリングリストを購読されることをお勧めする。月当たり100件程度と、件数がそれほど多くないわりに新しい提案情報や状況がいち早く入手できる。こちらから参加可能だ。
バックナンバー：
 | 月刊JavaWorld (ジャバ ワールド) 2月号 [雑誌] Amazonで詳しく見る by G-Tools |
