Fedora Summitで公開されたロードマップ:コミュニティ全体に関わる大幅な変更

先月、Red HatのFedoraプロジェクトに携わる開発者、エンジニア、マネージャたちが、同プロジェクトの短期および長期的な将来計画を検討すべく、マサチューセッツ州ウェストフォードで開催された3日間のサミットに集結した。そしてブレインストーミングセッションの結果、Fedoraコミュニティ全体に変化を及ぼすロードマップが定められたのである。

今回のFedora Summitでは、FedoraリリースエンジニアのJesse Keating氏、Fedora開発者のJeremy Katz氏、Fedora Projectのオリジナル創設者でありエンジニアの1人でもあるWarren Togami氏、Red Hatのコミュニティ開発マネージャを務めるGreg DeKoenigsberg氏、Fedora Project LeaderのMax Spevack氏など、Red HatおよびFedoraチームのトップ10にランクされるメンバが一堂に会した。またマサチューセッツまで足を運ぶことのできなかったチームメンバ用に電話会議用の回線が用意されていた他、討論の様子はIRCチャンネルにリアルタイムで中継されており、後者は100名を越えるFedoraコミュニティの人間に利用されていたようである。

本サミットでは30以上のトピックが検討されたが、重要度の高い問題はごく一部に集約されていた。特に長時間をかけて討議されていたのは、コミュニティ側のメンバが参加する際の障壁をいかにして低くするかであったが、それは過去におけるFedoraの発展においてRed Hatの正規雇用者だけでなくコミュニティのメンバが実質的に同レベルの貢献をしてきたことに、ほぼ全員が同意していたからである。そして今回は1つの構想として、現在は基本的にRed Hatの正規雇用者が開発と維持をしているFedora Coreパッケージと、主としてコミュニティの有志が開発を担っているFedora Extrasの間の垣根を取り除くことで、貢献者間の交流を密にすることを最大限に図ることが提案されている。

「私が考えるに、最大のポイントは、Fedora CoreとFedora Extrasを隔てている溝を埋めることでしょう」とDeKoenigsberg氏は語る。「この18カ月間にコミュニティ側の貢献者たちが作成してきたパッケージは、Red Hatの正規エンジニアのものと比べて遜色ありませんし、いくつかは上回っている部分もあるくらいです。ですから、先に述べたような目標をより明確化し、ロードマップとしても定めておくことが最優先の課題だと私は思っています」。

そうした見解にはProject Leaderを務めるMax Spevack氏も同意している。現行のシステムに従うと、CoreパッケージのメンテナはRed Hatの正規雇用者でなければならない。「私たちが求めているのは、その点の変更です」と同氏は語る。「パッケージの開発には、最適な人員を当てられるようにしたい訳です。そうした人材がたまたまRed Hatの従業員であれば、それはそれでOKです。しかし、そうでないケースがあっても特に問題はないはずでしょう。オープンソースという形態のソフトウェアを扱う場合、コミュニティの重要度は言うまでもありません。いずれにせよ、完成形態のディストリビューションは、どれも多かれ少なかれ同じようなものになるはずです。違いがあるとすれば、それはユーザコミュニティのメンバをどれだけ上手くプロジェクトに参加させるようにしたかでしょう。今回私たちが行おうとしているのはコミュニティ側の発言権を高めることで、それによって健全かつ活動的なコミュニティを育成することになると信じています。言い換えれば、最適な人材を見つけて、そうした人々に改善を進めるための権限を与えるようにしよう、ということですね」。

そうした方向に沿った活動の1つとして最近FedoraはInfrastructure Leaderという職務に関する求人広告を出しており、その具体的な役割としては、エンジニアリングとマネージメントのスキルを併せ持ち、今回のサミットで確認されたいくつかの項目を監督することに第一義的責任を負う者とされている。Spevack氏の説明によると、この求人への反応は高く、来年1月初頭には採用者を決定したいとのことだ。

その他に非常に高い関心を集めていたものは、早くても数カ月以上先の話になるであろうFedora Core 7のリリースにあわせて新規のビルドツールを構築しようという計画である。現在Red Hatで使用されているツールは、Coreパッケージの構築と頒布に用いる、非公開型ビルド用システムのBrewおよび、Extrasパッケージのビルド時に用いる、mockやyumなどのプログラムを利用した頒布型パッケージビルド用システムのPlagueという色分けになっている。新規のビルド用システムには、開発者にとって最適であると同時に、コミュニティ側のメンバが独自パッケージを自由に作成できるものという要件が課されるが、具体的にどのようなものが相応しいかはFedoraチームが評価を進めている段階である。

ビルド用システムのリフォームと並行する形で検討されているものに、ライブCDプロジェクトの改変計画がある。Red HatはこれまでにもライブCDディストリビューションの開発に関心を示しており、実際、Googleの主催した2005 Summer of CodeにおいてKadischiという関連プロジェクトを支援したこともある。このプロジェクトは実質的な中断状態となったが、その開発者兼メンテナであるDavid Zeuthen氏は、Red HatのHardware Extraction Layer(HAL)を構築してアプリケーションによるシステムハードウェアの識別を簡単化したことで知られる人物であり、既に同氏はPilgrimというライブCDツールを作成している。このPilgrimで構築されるシステムイメージはフラッシュドライブからの実行が可能であり、FedoraのライブCD構想ページにある表現を借りれば、「理想的なライブCDに非常に近い形態を示している」のである。

今回のサミットではPilgrimおよびKadischiを比較検討した結果としてPilgrimが選択されたが、その理由として挙げられたのが、プロジェクトの牽引に不可欠である強力なリーダシップをZeuthen氏が有していることであった。またPilgrimがFedoraおよびOne Laptop Per Childという2つのプロジェクトで利用されることになれば、そのコードに対しては多数の人間による評価と修正が定常的に施されるため、非常に堅固なコードベースに仕上がるのではないかという期待も持たれている。

Spevack氏は、新しく構築するビルドおよびライブCD用ツールの使用目的を明確化しておくことは、今回のサミットで確立された開発戦略の行方全体を左右する重要事項だと語っている。同氏の発言によると、Fedoraチームとしては、個々のユーザに歓迎されるパッケージのビルドに必要なツールをコミュニティに提供すると同時に、開発の成果を公開して頒布するためのISOイメージの作成機能も準備しておきたい、という意向があるようだ。「自分自身が必要と思う機能をFedoraに組み込む際に、Red Hatに依存することなく実行できるような体制を整えたい訳です」。

これだけ大幅な変更をFedora Projectに施すとなると、当然その影響はリリースのプロセスにも広がるはずだが、チームメンバの説明によると今回の決定には、Fedora CoreおよびFedora Extrasの開発プロセスを共通化する上で最適な手法を今のうちに見定めておきたい、という大目的が存在しているとのことである。Spevack氏は、開発プロセス全体が改められていくにつれ、自然とリリースのプロセスも変わっていくはずだと語っている。「私どもの希望は、個々のパッケージに最適なメンテナを配することですが、その結果として今ある“何がCoreであり何がExtraか”という区別は、やがて単なる用語解釈上の問題だけになるでしょう」。

Spevack氏の説明するところによると、旧バージョンのFedoraをサポートしてきたコミュニティベースのLegacyプロジェクトについては、そのサポートを数カ月延長することが予定されており、リリースのプロセスにはその辺の影響も入り込むであろうとのことである。その他に同氏が強調していたのは、特定の変更に伴って誰かが追放されるような事態を生じさせないようにし、必要に応じて各自の能力を最大限に発揮できるための回避策を執りたい、ということであった。

これと同様の主張は、Legacyのオリジナルチームを率いてきたKeating氏からも繰り返されている。「私たちもLegacyを立ち上げた当初は、自分たちがサポートすると宣言したFedoraおよびRed Hat Linux(のバージョン)に対するアップデートを周囲の期待を裏切ることなく進めていこうという、高い理想を抱いていました。ところが実際のプロジェクトは、思っていたスケジュール通りにいくものではなかったのです。そうした原因の一部は、貢献してくれる人材が少なすぎたこともありますが、一部は私自身のプロジェクト管理能力が至らなかったせいだと感じています。いずれにせよ、中盤以降のFedoraリリース(FC2/3/4)となると目標に掲げたアップデートのサポートが達成できなかったのは厳然たる事実です」。

「現状でLegacyに関与している人間は、Legacyに対する既得権に類するものを何も有してはいません。彼らが参加している基本的な動機は、援助を必要としているプロジェクトを手助けしたいというものでしょうが、ある程度は、自分の名を世に知らしめたいという欲求もあるでしょう。私としては、そうした意欲と人材をFedora Projectで使うのであれば、より生産的なプロジェクトに投入すべきだと考えています。卑しむべきは、ドアを閉ざして貢献者たちの意欲をそぐような行為をすることでしょう。こうした意欲ある人々が貢献できる新たな活動場所を見つけられることを、私は心の底から願っています」。

このようにLegacyのサポート体制は大きな曲がり角を迎えることが確定している一方で、その最終的な行く末については、Keating氏へのインタビュが済んだ段階においても、不透明さが漂い続けていた。「これは数カ月前の話ですが、このプロジェクトに関して私個人の時間を割けなくなることが確実になったので、今後のプロジェクトの統括については貢献者の1人に委ねることにしました」とKeating氏は語っている。「つまり、確かに私どもは今回のサミットにおいてLegacyに関する提案を行いましたが、その提案を受け入れるかの決定は現職のプロジェクトリーダが行うことであり、Legacyプロジェクトの終焉を決断する場合も、それは同氏が行うことになるだろうということです」。

そして12月12日、Legacy Projectのホームページにて下記の旨のメッセージが掲示された――「メンテナンスディストリビューションのサポート体制については、現在見直しが行われています。以前に計画したような旧バージョンのFedora Coreリリースに関するサポートを延長することは、現時点において不可能と言わざるを得ません。現在、Fedora Core 4を含むそれ以前のディストリビューションについては、メンテナンスが行えない状況となっています……。事実上、Red Hat Linux系ディストリビューションに対するFedora Legacyについては、これでサポートを終えることになるでしょう。本プロジェクトは今後、Fedora Core系の開発活動に主眼を置き、Fedora Project全体との統合を進める方向で活動していきます」。

今回のサミットは先月開催されたものだが、その会期中および終了後においてコミュニティ側のメンバの一部からは、最近の動向としてFedoraチームは短期および長期的な計画の立案に興味を示すようになってきたが、そうした状況を鑑み、そろそろFedoraサイドとしてもRed Hatコミュニティにおいてより重要な地位を占めるようになったことを自覚してもよいのではないのか、という声が上がっている。Spevack氏は、それは真実からほど遠いと語っている。将来的な計画を構築しておくのはごく基本的なビジネス感覚である、というのが同氏の意見だ。

「Red Hatは大手の株式公開企業の1つですから、そうした企業がより多角的な視点からFedoraを捉えようとするのはごく普通のことでしょう。企業としてのRed Hatが何らかの決定をした場合、それが会社全体として最善な選択であったことを確認したがるものです。例えば私たちが今回行ったサミットのような活動ですが、これをRed Hat側の視点から見れば、私たちの方から“今後の改善法とロードマップを自主的に定めました”と積極的に発言することは、Fedoraに対してRed Hatが過去に行ってきた投資が企業運営にメリットをもたらしたと判断される要素であり、先方としてもそう捉えたいところでしょう。つまり経営サイドとしては、自分たちが仕事を任せた人員が優れた開発計画を構築したことを確認できれば納得がいく、という程度の話であって、FedoraサイドとしてはRed Hat側にそれ以上ないしそれ以下の期待を抱くべきではないと思いますね」。

サミットが終了した現在、そこでの決定事項を実践に移すという重労働が待ちかまえている。提案された構想をコードとして実装するにしても、その前の段階として、多様な意見を持つメンバで構成された評議会その他の了承を得なければならない。またコミュニティのメンバについても、IRCのログSummit wikiに目を通した上で、個々のチームに意見のフィードバックをすることが求められている。「今回の構想については全体的に賛成してくれると思います」と語るのはSpevack氏である。「そして現在の段階は“個別的な疑問点にお答えします”フェーズといったところでしょう。最大の山場である“具体的な作業”フェーズに本格的に取りかかれるのは、たぶん年を越してからですね」。

NewsForge.com 原文