Ubuntu開発者会議レポート
UDS開発者会議の参加登録者数は全体で約140人に上った。 Canonical社マーケティング統括のJane Silber氏によると、 Ubuntuのスポンサー企業である Canonical社に実際に雇われている人は そのうちの30人に過ぎないとのことだ。 それ以外の参加者は、 Ubuntuコミュニティのメンバー、 Ubuntuのコンポーネントの開発元プロジェクトの代表、 その他Ubuntuの開発方針に関心を持つ関係者などだ。 私が話すことができた人たちの中には、 Software Freedom Dayプロジェクトや Linux Terminal Server Projectのメンバー、 Sun社の社員数名、それに（当然のことながら） 様子を見に立ち寄ったGoogle社の社員も何人かいた。
参加した開発者の中には、 自分が特に関心のある部分の仕様について議論するために1、2日間だけ参加した人もいた。 例えばPostgreSQL開発チームのJosh Berkus氏は、 Ubuntu上での初期設定のPostgreSQLの性能向上について話し合うために水曜日のみ参加した。 また、X.orgの Keith Packard氏は、 Feisty Fawn（Ubuntu 7.04のコードネーム）用の X.orgに関して提案されたいくつかの仕様について話し合うために金曜日頃に参加する予定になっている。
仕様の提案プロセス
このUDS開発者会議は、主に開発者にとっての会議という位置付けで、 Ubuntuディストリビューションの新機能やUbuntuコミュニティにおける行動規範について、 アイデアをとことん話し合い仕様として書き上げるための会議となっている。 一日の最初と最後に短時間だけ アナウンスや短いプレゼンテーションのための時間が確保されているが、 それ以外の時間はまるまる、 Ubuntuディストリビューションの次期リリースや Ubuntuコミュニティの統治についての仕様に関する議論や脇目も振らない集中した作業に当てられている。
手順としては、まず開発者が Launchpad 上で仕様の提案を行なう。 次に、提案された仕様案が各々1時間程度のBoF（分科会）セッションとして予定に組み込まれる。 そしてBoFセッションの後、 仕様案はさらに議論が必要として後回しにされるかあるいは承認され仕様の記述作業へと進められる。 仕様の記述作業が終わると、レビュー作業へと進められる。 レビューに合格すると、さらに実装作業へと進められる。
今回、多くの開発者がマウンテンビューへと実際にやって来たが、 遠隔参加も奨励されている。 すべてのセッションにおいてVoIPダイヤルインが用意されており、 開発者はコラボレーション用テキストエディタの Gobby を使用して各会議のメモをまとめていた。 UDS開発者会議で直接会うことに越したことはないが、 直接参加できなかった開発者のためにも便宜を計るようUbuntuの人たちは努力していた。
私はいくつかのBoFセッションを傍聴したが、 一つ一つの機能が非常に丁寧に検討されている様子を見るのは興味深かった。 例えば水曜日には、 Ubuntuでのオーディオコーデックのサポートの向上についてのセッションを傍聴した。 そのセッションには約20人の開発者が参加しており、 人気のあるコーデックのサポートを、 ユーザが抱えることになる面倒を最低限に抑えつつ 開発者にとってもできるだけ楽に提供する方法が議論されていた。
そのための方法として技術的に最も簡単な解決法である、 入手可能なものをすべて含めてリリースするという方法は、 法的な理由から除外された。 そうではなく開発者たちは、 コーデックのダウンロードをユーザ自身にオンデマンドで能動的に行なわせ、 ユーザ自身に法的な問題を片付けさせることができないだろうかと検討していた。 解決のための方法はGNOME、KDE、Xfceのすべてにおいてうまく行く方法である必要があるため、 かなり周到な計画が要求される。
私の知る限りUbuntuは、他に類を見ないほど プロジェクト外部の開発者にも干渉することを認め発言権を与えている。 例えばDebianプロジェクトはコミュニティ指向のディストリビューションであるものの、 決定に関する発言権は主としてプロジェクトのメンバーのみに与えられている。 またDebianの新リリースを計画するための中心的な計画会議というものも存在しない。 FedoraプロジェクトとopenSUSEプロジェクトは コミュニティの参加をいくらか認めているものの、 それぞれRed Hat社とNovell社がおおかたのところ主導している。 そしてRed Hat Enterprise LinuxとSUSE Linux Enterpriseの方向付けは 完全に両社のエンジニアリングチームによって行なわれている。
とは言っても、Ubuntuも100％コミュニティ主導ということではない。 UbuntuのSABDFL（「自己任命慈悲深き終身独裁者」）であるMark Shuttleworth氏によると、 Feistyの開発は、Canonical社が開発チームに対し要求する機能と、 コミュニティ主導の機能とをフィフティー・フィフティーに混ぜ合わせたものになるだろうということだ。
興味を引く新機能
Feistyの最終的な機能がどうなるのかはまだ確定していない。 しかしすでにこれまでの時点で興味を引かれる議論がいくつかあった。
先にも述べたように、 Feistyではマルチメディアコーデックをユーザが 「オンデマンドで」より簡単に入手できるようになる可能性が高い。 これにより今までの苦労から解放されるユーザは多いことだろう。 また、異なるサウンドシステムやサウンドプログラムが オーディオデバイスへのアクセスを「取り合い」する オーディオ混線問題の対処に関しても作業が行なわれている。
Feistyの仕様は現時点ではまだ確定していないが、 どうやらESD（Enlightened Sound Daemon）から PulseAudio に新しく入れ替わるらしい。 そしてこれが恐るべき「/dev/dspへアクセスできません」エラーを見ることなく、 複数のプログラムのすべてが同時に サウンドカードから音楽を再生したりビープ音を鳴らしたり音声を出力できるようにするための、 オーディオデバイスへの協調的なアクセスへ向けての第一歩となるようだ。
またFeistyでは、Berylを利用したデスクトップの画面効果ということに 高い優先度が与えられるということをShuttleworth氏が示唆している。 また、FeistyリリースではUbuntuのバイナリドライバの含有率がやや高くなるようだ。 現在のところはUbuntuはワイヤレスカード等のデバイスのサポートのために いくつかのバイナリドライバを含んではいるものの、 例えばnon-freeのNvidiaドライバなどはデフォルトではオフになっている。
Shuttleworth氏によるとFeistyでは、 ユーザに最高の性能を提供するために バイナリドライバをデフォルトで提供するつもりであるとのことだ。 しかしドライバに「フリー」なものと「非フリー」なものがあることについてや、 フリーのドライバを入手可能にしている同等のハードウェアも存在するということについて、 ユーザを教育することもしたいとShuttleworth氏は述べている。
UDS開発者会議は本日が最終日だ。 もし今日マウンテンビューあたりにいて Ubuntuの開発に興味があるなら、wiki上で登録して参加してみてはいかがだろうか。 私も参加していて、最終日の議論を取材している。 そして来週、何人かのUbuntu開発者のインタビューや Feistyの新機能のより詳細なまとめをお届けする予定だ。
