支持を求めてあがくAutopackage

1年2か月前、小規模ながらも活発な取り組みを行っていたAutopackageプロジェクトのメンバーは、自分たちの成功について楽観的な態度を示していた。この代替インストーラのプロジェクトは現在も活動を続けてはいるものの、進展はほとんど見られない。irc.oftc.netの#autopackageチャンネルは誰も訪れない日が大半を占め、開発者のブログで取り上げられているのはプロジェクト以外のことばかりで、ソースコード・リポジトリに対するコミットは滅多に行われていない。形のうえではまだ継続中であるが、主だった貢献者たちは1人残らず、プロジェクトが終焉を迎えつつあることに同意している。いったい何が起こったのだろうか。

その答えには、多くのフリーおよびオープンソースソフトウェア(FOSS)プロジェクトが失敗に終わる理由、そして現在のLinuxの基本的な構造を大きく変えることの難しさが反映されている。

2005年のLinux.com掲載記事にあるように、Autopackageはネイティブのパッケージ管理システムにはないメリットをいくつか提供している。オペレーティングシステムの基本的なファイルやユーティリティではなく、主にデスクトップ・アプリケーションでの利用を想定して開発されたAutopackageは、root以外のアカウントに対してのみソフトウェアをインストールすることができる。

これは便利であるだけでなく、システム全体をマルウェア(悪意のあるソフトウェア)から保護することにもなる。ネイティブのパッケージ管理システムとは異なり、Autopackageは任意のディストリビューションで動作し、魅力的かつ効果的、それでいて簡素なインタフェースを備えている。マニュアル類も明解な内容でよくまとまっている。一見すると、Autopackageには使ってみたくなる要素がすべて揃っているように思える。

プロジェクトを取り巻く状況も完全に否定的というわけではない。Xara Xtremeの各リリースはAutopackage形式で利用可能であり、2005年にはオランダのある税務ソフトウェアがAutopackage形式としてリリースされていた。さらに、最も積極的に貢献していたメンバーの1人Isak Savo氏は、Autopackageの利用を促進するために同プロジェクトのチームは熱心に取り組んできたと語る。

Autopackageプロジェクトのメンバーはパッケージを作ってはメンテナが見つかるかもしれないと期待しながら各プロジェクトに送り、ソフトウェアの最新バージョンが素早く利用できるというAutopackageを使うことのメリットをユーザに伝えてきた。その機会があれば、彼らは喜んで記事やブログ、メーリングリストのなかでAutopackageのメリットを説明してくれるだろう。

だが、こうした努力にもかかわらず、昨年は利用可能なパッケージの数が伸び悩み、GIMP用パッケージなど、多くのパッケージの現行版がAutopackageで利用できなくなった。検索すればすぐにわかるように、Autopackageを利用したパッケージのすべてが同プロジェクトのWebサイトに記載されているわけではないのは確かだ。しかし、Autopackageの採用が増えていないのは明らかであり、もしかすると減少さえしているかもしれない。

小さなプロジェクトの問題点

Autopackageの場合、非常にわかりやすい問題点の1つが、このプロジェクトに取り組むボランティアの少なさである。多くの開発者が特定のパッケージのメンテナンスを行ってはいるが、Autopackageのコードの大部分はわずか3人の開発者によるものだ。その1人、Savo氏は最近大学を卒業し、FOSSの開発にはほとんど時間を割けなくなっている。

同じように、このプロジェクトの創設者の1人でその活動推進の中心を担ってきたMike Hearn氏も昨年Googleに入社し、もはやAutopackageプロジェクトでの活動は行っていない。「今でも電子メールの対応や議論への参加はしているが、もうコードを書いたり普及活動に努めたりはしない」。全盛期ですら人手不足だったAutopackageのコア・チームは現在、依然として活動を続けるTaj Morton氏たった1人になり、生み出された成果の大部分を引き受けようというボランティアは今のところいない。

さらに悪いことに、こうしたボランティアの不足は、基本的な機能のコーディングがすでに終わって、あと残っているのはバグ修正が大半という段階で生じている。多くの場合、この手の細かい作業はどんなプロジェクトでもボランティアを惹き寄せる際の障害となる。その理由は面白みに欠けるからであり、また最初のプログラミングよりも深い専門知識と細部への注意が要求されることが多いからでもある。Hearn氏はAutopackageにおける技術的な難点のリストを用意しているが、本当の問題は単にそれらを解決できるだけの専門知識と時間を兼ね備えた人が十分にいないことにある。

その結果として「我々は一部のディストリビューションとの間に今なお統合に関する問題を抱えている」とSavo氏は言う。また、たとえばエンドユーザ使用許諾を表示する機能のような、Autopackageを独立系ソフトウェアベンダにアピールできるような変更をくわえる時間もない、とSavo氏は語る。こうした問題のほとんどはLinuxを対象とした開発者の多くが必ず直面するはずのものだが、Autopackageのようにボランティア不足に悩むプロジェクトにとっては厄介な障害になる。

ディストリビューションの保守的傾向

小さなプロジェクトで大きな問題に取り組もうとすることの難しさに加え、Autopackageはソフトウェアのインストール・ツールとしてオペレーティングシステムのような根本的な部分に挑むという難易度の高さゆえの困難にも直面している。

そうした難しさの1つとして、多くのプロジェクトにはAutopackageを考慮する理由がないことをSavo氏は挙げている。「大規模なプロジェクトにとって、Autopackage形式で配布しようという動機になるものはあまりない。そうしたプロジェクトには、とにかく主要なディストリビューション向けのアプリケーションであればどんなものでもパッケージングできる担当者が何十人もいるからだ」

また、AbiWordのautopackageメンテナであるRobert Staudinger氏は次のように述べる。「最近のディストリビューションはメンテナンスが行き届いていて、頻繁にリリースされているものがたくさんある」。こうした体制の下で、Autopackageによってデスクトップ・アプリケーションをタイムリーにリリースできるという論理は訴求力を失いつつある。ネイティブのパッケージ管理システムを利用してきた多くのディストリビューションについてHearn氏は、Autopackageのようなユニバーサル・インストーラの「コストを過大に、利点を過少に評価」し、自分たちの知見に固執する傾向がある、と述べている。

FurtheまたStaudinger氏は、熟練ユーザはネイティブのパッケージ管理システムを理解しているので、新たなシステムに移行する理由がほとんどない、と語る。「反対に、偏見のない新しいユーザには、とにかく代替インストーラを試してみてうまく使えれば引き続き利用するという人が大勢いた」

こうした意見の対立をひたすら激化させているのが、Autopackageを擁護する声が多くの場合、特定のネイティブ・パッケージ管理システムの批判に終わっているという事実である。Hearn氏は2006年12月に開催されたFree Standard GroupのPackaging Summitにおいてだけでなく、自身のブログでもネイティブのパッケージ管理システムは時代遅れであり民主主義に反すると批判している。「ネイティブのパッケージングおよびインストールの考え方そのものがナンセンスであり、フロッピーディスクでソフトウェアが配布されていた時代の名残に過ぎない。Webの‘インスタント・アクティベーション’モデルのほうが優れているが、ストリーミングおよびセキュリティに関するクライアント側のプラットフォームをまず進化させる必要がある」

ソフトウェアのインストールの問題についても、ドライバなど、Linuxのその他のアーキテクチャ上の問題と同様だ、とHearn氏は述べている。彼は、こうした問題を「技術的いうよりも文化的および社会的な問題」と呼んでいる。主要なディストリビューションと議論してきたHearn氏は、Packaging Summitでのプレゼンテーションのなかで、ディストリビューションの大半は対抗意識が強過ぎるばかりに同氏が必要と信じる根本的な変更に賛同してくれない、と述べた。

Staudinger氏は、Autopackageの受け入れを支持する保守勢力がある意味では正解なのだろうと見ている。一方、Debian開発者でありLinux Foundationに勤務するJeff Licquia氏は、Autopackageにはネイティブのパッケージ管理システムとの連携性がないと批判する。

Autopackageは分別を失っている」と題したブログでLicquia氏は次のように述べている。「ほとんどあらゆる要素がAutopackageの世界観に反していることは明らかだ。少なくともパッケージ・マネージャ、Python、C++、C言語の標準ライブラリ、ELF実行ファイル形式、動的リンカなどはそうだ」

Autopackageを特に強く批判しているのが、技術的な観点からAutopackageのことを「猿が考えたもの」とまで言うJoey Hess氏をはじめとするDebian開発者である。しかし、こうした否定的な反応を示すディストリビューションはDebianだけではない。たとえばGentooの開発ガイドも、Autopackageについて「Gentooシステムにはまったく適合しない」と記している。

Hearn氏の主張は、Autopackageを認めようとしない人々の存在を示しているだけなのかもしれないが、彼自身の意見がAutopackageに対する批判を煽っていることは間違いない。Staudinger氏が言うように、「Autopackageの問題の1つは、それを取り巻く論争」にある。Staudinger氏によれば、Autopackageが直面している最大の問題は、ただ「Linuxのコアな問題をあげつらうMike Hearn氏の態度」に多くの人々が苛立っている」ことにあるというのだ。

今後の展望

Autopackageは正式に終結したわけではなく、プロジェクトはゆっくりとではあるが進展を見せている。同時に、普及させるにあたっての問題と支持者が起こした論争の狭間で、Autopackageの時機はそのリード・プログラマの関心がますます遠のくとともに失われてしまったように思える。

最近Hearn氏はLinuxのアーキテクチャに対して直接的な批判を続けることにあまり関心を示しておらず、この問題に対してはむしろ標準化の必要性に重点を置くことでより間接的なアプローチをとるようになっている。とはいえ、Linuxの根本的な変更については、やはり悲観的な態度を貫いている。

Autopackageをめぐる諸問題について、Hearn氏は次のように語る。「ようやく私がたどり着いた結論は、今後Linuxが大きく改善されて自分の求めるデスクトップ・コンピューティングに近づいていくことは決してなく、ゆえにLinuxが大きな市場シェアを獲得することもないだろう、というものだ。最近、私がLinux組織のクライアント側ソフトウェアではなく、Googleでサーバに取り組んでいる理由の1つはそこにある」

Hearn氏の考え方が正しいとするなら、Autopackageプロジェクトから得られた真の教訓は、ソフトウェアのインストールを改善する方法ではなく、長い歴史を持つLinuxのアーキテクチャに対して今になって大規模な変更を加えることの難しさ ― あるいは可能性のなさ ― であろうか。かつて前途有望に思われたプロジェクトにしては、酔いの醒めるような何ともあっけない結論である。

Bruce Byfield氏はセミナーのデザイナ兼インストラクタで、NewsForge、Linux.com、IT Manager’s Journalに定期的に寄稿しているコンピュータジャーナリストでもある。

NewsForge.com 原文