Ubuntu開発者会議レポート：デスクトップ版、PowerPC版、およびコミュニティに関する展望
PowerPCサポートの今後
現在のコンピュータ環境は、Ubuntuが誕生した当時と比べると大きく様変わりしている。Ubuntuのファーストバージョンがリリースされた当時、Apple製コンピュータと言えばPowerPC搭載と相場が決まっており（少なくとも世間一般ではそう認識されていた）、こうしたPowerPCデスクトップに対するLinuxのサポートを望むユーザも多数存在していた。
今回の会議会場でもApple製ラップトップをいくつか見かけたが、その大半はUbuntu環境で動いており、またこれは私の個人的推測だが、そうしたUbuntu搭載ラップトップの2分の1から3分の1はIntelベースのマシンだと見ていいだろう。実際PowerPCの対応状況に関してPowerPCReviewに挙げられた数字によると、archive.ubuntu.comからのダウンロード数に占めるPowerPCアーキテクチャの割合は、2006年11月時点においてわずか0.8％でしかなく、2005年7月の1.95％から見ても大幅に減少している。
Ubuntuの創設者であるMark Shuttleworth氏とCTOを務めるMatt Zimmerman氏の示唆するところによると、デスクトップ用UbuntuのPowerPCインストールについては、オフィシャルサポートを打ち切ることが既に検討されているとのことである。PowerPC版の需要は減少しているものの、同アーキテクチャ関連の移植作業を維持するには、それなりの体制を維持する必要があるからだ。
ただしオフィシャルサポートの打ち切りが即、PowerPCサポートの完全消滅を意味する訳ではない。例えばPowerPCのサーバインストールに一定の需要があれば、非公式な形で移植作業を継続して、管轄をports.ubuntu.comに移行させるということもありえるだろう。
サウンド編集を容易にするJokosher
Ubuntuコミュニティのマネージャを務めるJono Bacon氏がデモンストレーションを行っていたのは、Ubuntu 7.04に同梱予定のJokosherというアプリケーションだ。Jokosherについては、同0.1リリースがUbuntuの6.10リポジトリにも収録されているが、それは完全版ではないとのことである。
Bacon氏はLugRadioというポッドキャストにも携わっているが、Linux用アプリケーションの中に簡単に扱えるサウンド編集アプリケーションが存在しないことが同プロジェクトを生み出す切っ掛けになったとのことである。同氏の説明によると、以前に理想的なサウンド編集アプリケーションに関するいくつかのアイデアを自身のブログに掲載したところ、それを契機にプロジェクトが進行し始めたということだそうだ。
| |
| Jono Bacon氏の語るUbuntuコミュニティについての展望（クリックでビデオ再生） |
Jokosherのユーザインタフェースは操作性を重視したとのことであり、実際に私の知る限りにおいても、Audacityなど既存のLinux用サウンド編集アプリケーションに比べ、遥かに使いやすい形にまとめられている。
Jokosherの操作は、よくあるトラック形式ではなく、インストルメント単位で行う。この点はAppleのGarageBandと似ているが、Bacon氏によるとGarageBandを参考にした訳ではないとのことだ。Jokosherはモデルエディタの一種で、サウンドを録音する場合と特定プロジェクトのミキシングをする場合とでインタフェースに若干の違いが生じるようになっている。
録音したインストルメントにおけるサウンドの編集は非常に簡単だ。例えば、サウンドの一部のみ録音レベルを調整したいのであれば、シフトキーを押しながら先頭位置と終了位置をクリックして操作範囲を指定すると、トラックの前後にボリュームセレクタが表示されるので、後はそれをドラッグするだけで自由にレベル調整を施すことができる。フェードインやフェードアウトなどの効果を付ける場合にせよ、トラック全体のボリュームを調整する場合にせよ、画面を見ながらの直感的な編集をすることが可能だ。
サウンドの一部をカットすることも簡単で、必要な部分をダブルクリックすると、該当部をトラック中に切り出すことができる。その後は目的に応じて、切り出した部分を適当なタイムラインにドラッグするか、あるいはトラック上から削除して前後のセクションをつなげるなどの操作をすればよい。
Feistyリリースでの公開が予定されている開発作業が順調に進めば、オーディオ分野でのLinuxの使用を考えているユーザにとって、Jokosherはキラーアプリケーションの1つとなるだろう。
Telepathy
今回私はCollaboraのSimon McVittie氏との間で、Telepathyプロジェクトについて話す機会を得ることもできた。これは、IRC、インスタントメッセージ、VoIP、ビデオチャットなど「あらゆるリアルタイム会議用フォーマットを統合したフレームワーク」という触れ込みのプロジェクトである。
| |
| Matt Zimmerman氏の語るUbuntuについての展望（クリックでビデオ再生） |
Telepathyプロジェクトの目的は、乱立状態にある通信プロトコルに対して統合的なアクセス手段を確立することであり、より具体的には、JabberないしIRCなどの特定のプロトコルを介して異種アプリケーション間での相互通信体制を整備することである。その際に個々のアプリケーションはD-Bus上でTelepathyを使用さえすればよく、これは開発者にとって、JabberやIRCなどの様々な通信プロトコルに対応するための機構をゼロから構築する負担から解放されることを意味する。
Telepathyを用いた場合、特定のアプリケーションが異なるプロトコル間での接続をするには、Jabberプロトコル用Gabbleなど、Telepathyに用意されているいくつかの接続マネージャを使用することになる。つまりこのテクノロジにおける“オフィシャル”なプロトコルは唯一Gabbleが存在するだけなのだが、様々な接続マネージャを使い分けることで、IRCやMSNなど各種のプロトコルを扱えるようになるのだ。
McVittie氏の説明によると、バックエンドでTelepathyを使用するようにしたIMクライアントのGossipをFeistyに収録することが現在検討中だとのことだ。接続マネージャの切り換えで複数のプロトコルに対応可能なGossipが登場した場合、Ubuntuにおける現行のデフォルトIMクライアントであるGaimの立場が脅かされることになるかもしれない。
Telepathyの長期的な展望を読み解くと、その目的が単にインターネット上で友人や家族相手のチャットを行うだけではないことが見て取れる。例えば先のJokosher開発チームは1.0リリース以降で“ネットワークインストルメント”を追加することを検討しているが、現行のプランではそうした機能をTelepathyを採用することで実現する予定だとのことだ。このネットワークインストルメントを用いると、いわゆるVoIP音声やその他のオーディオセッションをJokosherで直接録音できるようになるはずだが、そうした機能の実現はオーディオキャスト用のデータを編集する人間にとっての朗報となるに違いない。
デスクトップ用の開発計画
GNOMEのリリースサイクルは始まったばかりであるので、ここでGNOME 2.18についての詳細を語るのは時期尚早であろう。とは言うものの、今回の会議でインタビューすることのできた複数のGNOME開発者からは、GNOME 2.18およびUbuntu 7.04で登場するであろういくつかの機能について、ある程度共通した見解を聞くことができた。
Edgyに関する不満の1つとして、Beagleのようなデスクトップ検索ツールの不備を挙げることができる。UbuntuがBeagleから距離を置いているのは、主としてパフォーマンス的な理由から今後はTrackerに統合するという意向が働いているようだ。
GNOME 2.18におけるGnomeScan も同様な立ち位置にあり、Google Summer of Code 2006プロジェクトで開発が進められた同ソフトは将来的にXSaneと置き換わって、GNOMEアプリケーションが直接スキャナにアクセスするためのAPIを提供することになるであろう。このNetwork ManagerはGNOME 2.18での採用が予想されている一方で、Feistyでの採用リストにも名を連ねている。Network Managerを使用する具体的なメリットとして期待されているのは、ネットワーク接続の頻繁な切り替えを必要とするローミング機能の向上だ。ただし現状のNetwork Managerはスタティック設定をサポートしていないので、スタティックなネットワーク設定を必要とするユーザがNetwork Managerを使えるようにするには、Ubuntu開発陣がそれなりの努力をする必要があるだろう。
| |
| Murray Cumming氏の語るGNOMEについての展望（クリックでビデオ再生） |
今回の会議ではKDEおよびKubuntu関係者から、Feistyリリースに対してKubuntuでは何が予定されているかを聞くことができた。取材に答えてくれたKDEおよびKubuntu開発陣の見解によると、Feistyのリリース時点でおそらくKDE 4の正式版は完成段階に到達していないので、バージョン7.04用のデフォルトデスクトップはKDE 3.5.6に据え置かれ、KDE 4については開発用の参考プラットフォームという位置づけで公開されるだろうとのことであった。現在KDEチームはKDE 4の開発に主力を注いでおり、基本的にメンテナンスリリースでしかないKDE 3.5.6では、それほど多数の新機能は追加されないという話である。
KDE 4は、おそらく短期的なリリースサイクルで公開されるはずで、位置的にはFeistyとFeisty+1の中間に相当すると思われる。実際Riddell氏によると、KDE 4がオフィシャルにリリースされればKubuntuユーザはすぐに同パッケージを入手できるはずだが、Kubuntu本体がKDE 4をオフィシャルにサポートするのはKubuntu 7.10以降のリリースになるだろうとのことだ。
言うまでもなくKubuntuの標準環境はKDEであるが、Kubuntu FeistyではKOfficeの代わりにOpenOffice.orgがデフォルトでインストールされ、その状態は少なくともFeisty+1まで継続されるとのことである。ただしこの体制には1つの例外があって、データベースコンポーネントにはOpenOffice.org BaseではなくKexiが採用される予定であり、その理由としては、後者の方が機能的な完成度が高いとKubuntu開発陣が判断したことおよび、Microsoft Accessのフォーマットもサポートしている点が挙げられている。対するOpenOffice.orgはMDBファイルをサポートしていない。
Microsoft WindowsからLinuxへの乗り換えを考えているユーザもいると思うが、Kubuntu 7.04では、Windows用のユーザ設定をLinuxに移植するためのmigration assistantというツールが提供されるはずである。このツールを使用すると、メールやブラウザなどの様々な設定を対応するLinuxアプリケーションに自動的にコピーできるので、ユーザはこれらの設定をわざわざ手動で再入力しなくて済む。
Kubuntu開発陣は、Network Manager用のフロントエンドとして機能するKNetworkManagerを、Feistyのデフォルトとして採用することを計画している。現行のKubuntuにおけるデフォルトのネットワークマネージャは、KDEに標準で用意されているネットワーク管理アプリケーションだが、これは様々な点で見劣りすることが知られている。
DapperからEdgyのアップデート手順が複雑であるのは、多くのユーザが指摘する問題であるが、そうした不満の声は既にUbuntu開発者の耳にも届いている。Kubuntuの場合、同様の問題が更に深刻な形で横たわっているが、その理由はAdeptがディストリビューションのアップデート機能をサポートしていないためであり、現在Kubuntu開発陣はそうした機能をサポートするためのオプションをFeistyに向けて開発中だとのことだ。
Ubuntuコミュニティ
Ubuntuを成功させた要因の1つとしては、同ディストリビューションを中心に形成されたUbuntuコミュニティの存在を挙げることができる。今回の会議における140名あまりの参加者の中、Canonicalに雇用される形でUbuntuに携わっている人間は30名にすぎなかった。つまり残りの参加者は、個人的ないしは商用的な用途でのUbuntuの使用に関心を抱いている人々なのである。商用利用を考えているユーザとコミュニティとのギャップを埋めるにあたり、Shuttleworth氏と主催者側は非常に優れた仕事をしたようである。また今回の会議においては、コミュニティの形成と運営も主要なトピックとされていた。
Bacon氏の言葉を借りれば、Ubuntuコミュニティ形成に必須なツールとして機能するのがLocal Community（LoCo）チームだということになる。既にいくつかのLoCoチームは活動を開始しており、Bacon氏によるとその働きぶりはローカルレベルにおいて高く評価すべき点があるものの、横方向のつながりが弱く、意見の交換なども効率的に行われていないとのことだ。
こうした状況を受けてLoCoチームの活動効率を高めるためのいくつかの構想が検討されており、具体的な活動としては、Webサイトやメーリングリストを個々のLoCoチーム単位で独自に用意させるのではなく、認可されたチームに対して提供するリソースとして一括管理するよう改めることや、チームの立ち上げに必要な情報を提供する指導サービスの整備を進めることなどが挙げられる。
ある意味LoCoチームとは、専門化したLinuxユーザグループ（LUG）と見なせないこともない。そこで私はBacon氏に、LoCoチームとLUGとのあるべき関係について質問し、あるいはLoCoチームとはLUGに置き換わるべき存在なのか、と尋ねてみた。これに対するBacon氏の回答では、同氏自身の考えとしてLoCoチームはLUGの領分を犯す存在だとは見なしておらず、その理由として大部分のLUGは擁護団体としての要素が非常に薄いのに対して、LoCoチームは基本的にUbuntuの普及を推進するための擁護団体であり、場合によっては移行作業のサポートも行うことがある点を挙げている。
その他、Ubuntu関係のローカルコンファレンスやUbuntuユーザの年会を開催するためのサポートを行うことも検討されているが、これらについては提案の域をまだ出ていないそうだ。
今回の会議では、Ubuntuコミュニティにおける様々なグループを統括する各種チーム委員会の設立や、現行のオフィシャルなUbuntu開発者メーリングリスト（ubuntu-devel）におけるノイズ的発言の増加を鑑みて、非公開型の開発者メーリングリストを立ち上げることなど、その他の運営面に関する事項も検討されていた。この中で特に波紋を呼びそうなのは、オフィシャルなメーリングリストをUbuntu開発者専用のもの（ubuntu-devel）と一般ユーザに公開するもの（devel-discuss）に分けるという案であろう。この場合ubuntu-develのメーリングリストは、アーカイブされた後に一般公開されるものの、投稿に関しては開発者のみに限定することで、ノイズ発言の減少を図るとされている。
Ubuntuの収益性に対するCanonicalの思惑と派生ディストリビューション
| |
| Mark Shuttleworth氏の語るUbuntuについての展望（クリックでビデオ再生） |
Ubuntuというディストリビューションに関してささやき続けられている疑問の中には、このディストリビューションの人気を利用して商業的な成功につなげることは可能であるか、というものがある。今回私はShuttleworth氏に対して、Ubuntuの商業面でのあり方を尋ねてみたが、同氏からの回答は、同ディストリビューションについては「プロフェッショナルなサポートに対する要求が急速に高まりつつある」というもので、現状でトントンないしは黒字の収支が得られているのかについては言質を得られなかった。
Shuttleworth氏は、Ubuntuが最大の成功を収められる分野を総括して、「フリーソフトウェアを活用して自分のことは自分でやるというユーザのいるケースで……、要は、安定したOSさえ使えればプロプライエタリ系ソフトは必要ない」という人たちに使ってもらえる場合だとしている。
同氏は、SiemensによりUbuntuを用いたビデオストリーミング配信装置のプロジェクトが進められている事例や、MEPISやImpi LinuxなどUbuntuベースの派生ディストリビューションが多数生まれていること、およびLinux MintとgNewSenseという設計思想の異なったディストリビューションなども生み出されていることに言及していた。
Shuttleworth氏によると、Ubuntuが現在直面している最大の課題は、Oracleなどのプロプライエタリ系アプリケーションをUbuntuで実行させるに当たって必要な認証を得るための“タマゴが先かニワトリが先か”的問題だとしている。つまり自社のアプリケーションをUbuntuに対応させる側のベンダとしては、そのために負担するコストをペイできるだけのカスタマがUbuntuに付いていないと不安であるし、Ubuntuを導入する側のカスタマの心理としては、Ubuntu上でそうしたアプリケーションが動かせることがあらかじめ保証されていないと安心できない、という関係である。
もっともShuttleworth氏は、Ubuntuが新天地でも成功を収める展望は開けつつあるとしている。「ちょうど現在、Fortune 50企業との間で3つの案件を進めているところです。先方としては今あるRed HatをUbuntuに入れ換える気はないようで、それは当方の適合度に問題があるためですが……、可能である分野については（Ubuntuの導入も）視野に入れているそうです」。
これは長期的な展望だが、Shuttleworth氏の信じるところでは、5から7年ないしはより短期間でUbuntuの認証レベルはRed Hatと比肩するレベルに到達するはずであり、「それだけの時間をかけられれば、地道な努力で必要な成果を出すのに何の問題もありません」ということである。
