Portlandプロジェクト：デスクトップ環境の分裂問題を解決する特効薬という幻想
PortlandプロジェクトとはLinuxデスクトップ環境の統合を目標に掲げた計画で、そのための手法としては、すべてのアプリケーションが共通して用いるAPIのセットを整備し、これらアプリケーションの開発に必要なツール群を提供するという構想である。こうしたテクノロジを使用する側の主役となるのは独立系ソフト開発会社（ISV）であり、Portlandのプロジェクトリーダ陣たちの説明によると、これらのサードパーティ企業はLinux用ソフトウェアの開発には興味があるものの、収拾不可能な群雄割拠状態にあるLinuxデスクトップ環境を前にして二の足を踏んでいるだけだ、ということになる。
この見方は、問題の核心をついていると言っていいだろう。フリーソフトウェアコミュニティは以前からその問題に気づいており、長年にわたって論争を繰り広げてきた。実際こうしたデスクトップ環境の分裂問題は、ソフトウェアに携わる開発者、販売元、ユーザのすべてが共有する頭痛の種として横たわっている。そしてPortlandプロジェクトは、こうした問題に対して正面玄関からの総攻撃をかけようとしているのだ。
問題は、過去に試みられた類似の計画が、すべて同じような戦略を採用していたことである。
特効薬の処方箋
思い起こせばドットコムバブルの到来と共に始まったLinuxおよびフリーソフトウェアへの投資熱の高まりは、デスクトップ環境の分裂問題を静める魔法の特効薬の調合を約束する新手の錬金術師を、年に1人程度のペースで登場させてきた。そのすべては、意欲に溢れ、技術的に卓越し、勤勉な努力家であったが、今日ではその存在の大部分が忘れ去られている。
そうしたものの1つがBluecurveだ。BluecurveとはRed Hatが推進したプロジェクトで、GNOMEおよびKDEアプリケーション用の共通テーマを構築することでデスクトップ環境の統合を目論んでいた。このテーマの共通化は大筋において成功したが、依然としてデスクトップ環境は分裂したまま残されている。今から振り返ると、そんな表層的な部分だけをいじくっても根本的問題が解決されないことは分かり切ったことなのだが、当時は企業もメディアも諸手をあげて特効薬の出現を約束していたものだった。
XimianおよびSUSEの買収後のNovellも同じような行動に出ていたが、その際にはKDEとGNOMEの良いとこ取りをできるという新企業の利点を生かして、統合デスクトップ環境時代の到来を高らかに宣言したものであった。同様の試みは非営利のfreedesktop.orgでも行われており、その創設時に掲げられていた目標は、これまたやはりAPIの共通化をすることでLinuxデスクトップ環境の統合を果たすという構想だったのである。そうした発想はSunにおいても例外ではなく、同社の推進したProject Mad Hatterというのは、GNOME、Java、StarOffice、Mozillaをつなぎ合わせてLinuxデスクトップ環境を統合するという構想であった。
同様の事例は、MetaTheme、Linux Standards Base、GTK-Qt Theme Engineなど、数えだしたらきりがない。こうしたプロジェクトの中には、テクニカル面に傾注したものもあれば、アーティスティックやフィロソフィカルな側面に主眼をおいていたものもあった。そしていくつかのプロジェクトは短命に終わったが、現在でも活動を継続しているものも存在している。いずれにせよ、これらすべてのプロジェクトに共通しているのは、Linuxデスクトップ環境の統合を目標に掲げたこと、および、その目標達成に挫折したという2点である。
おそらく、こうした見方に対するPortland擁護派からの反論は、このプロジェクトはBluecurveのような表層的な取り繕いでもなければ、Mad Hatterのような特定アプリケーションに束縛されている訳でもない、といったところだろう。確かにその通りである。ただし過去に試みられた“Linuxデスクトップ環境の統合”プロジェクトがことごとく失敗に終わった理由は、そのカバー範囲が限定的だったからでもなければ、不適切なAPIを選択したからでもなく、そもそもLinuxデスクトップ環境の統合という目標が、本質的に実現不可能な命題だったからなのである。
将来的な予想：完治は無理です
誤解しないで頂きたいのだが、私は何も、これらの特効薬プロジェクトは有益な成果を何ももたらさなかったと主張しているのではない。Bluecurveは美しいテーマを世に送り出しているし、freedesktop.orgも実用的な仕様をまとめ上げている。私が言いたいのは、これらのプロジェクトが掲げた特効薬的な高度な目標は達成されなかった、ということである。別の見方をすれば、特効薬の調合という夢想に妄執しているのはプログラマたちであって、彼らの作るプログラムではないとも言えるだろう。こうした症状をもたらしている病根は、プログラムコードが実際に行う各種のタスクと、それによって達成されると喧伝されている謳い文句との落差なのだ。そして、ここで解決すべき技術的な課題が超自然的な現象でないのと同様、それに対する魔法の特効薬というのも存在しないのである。
このように“Linuxデスクトップ環境の統合”とは手の付けられない解決不可能な命題であって、それに手を出すプロジェクトは、魔法の特効薬を調合するに等しい約束をすることになる。“Linuxデスクトップ環境の統合”を追求し続けている特効薬プロジェクトは今日でも存在してはいるが、それらの大部分は、壮大かつ雄大な理想を達成するために、現実的かつ妥当な目標を犠牲にしてきたのだ。仮にPortlandプロジェクトが基礎研究以上の段階に既に達しているのであれば、そこで生み出されるAPIおよびツール群を多数のISVが採用することになるだろう。だが同時に、それ以上の効果を期待するのは無理だとも言えるのだ。
Fred Brooks氏が『No Silver Bullet: Essence and Accidents of Software Engineering』（銀の弾丸などない：ソフトウェアエンジニアリングで生じる問題とエッセンス）を書き下した1986年当時、プログラミング効率を妨げていた大きな問題の1つを解決できれば、プログラマの生産性は1桁上がっていたはずである。当時を経験した世代の人間であれば、こうした問題を解決するソリューションが遂に登場したというニュースを何か耳にした経験があるだろう。だが“write once, run anywhere（一度書けばどこでも動く）言語”にしろ“easy-to-use security（簡単にできるセキュリティ）”にしろ、結局そのような特効薬は実現しなかったが、そうした事情は今まで見たような“Linuxデスクトップ環境の統合”についても同様なのであって、それが冷めた目で見た現実なのである。
