Compizの開発者、今後の発展をやめ保守のみし、Waylandへの移植もしないと表明

Sideways | Make it better

Compizの主要な開発者の一人であり、一時期Canonicalに雇われていたこともあるSam Spilsburyがブログで、Compizはこれ以上開発せず、保守のみするべきであり、Waylandへの移植もしないという意見を表明している。

主な理由は、Wayland環境では、Compizの存在価値がなくなるから、また細分化の弊害のためだとしている。

かつて、Waylandへの移行をロードマップに描いたCanonicalの意向に逆行する意見だ。確か、当時のCanonicalの意向では、CompizをWaylandに移植し、すなわちCompiz上で動くUnityをWaylandに移植するということになっていたはずだ。また少し前は、WaylandのWestonをforkしてUnityをWayland上で実装するなどという話も聞こえてきた。一体どうなることやら。そもそも、Waylandはいつ実用になるのか。

思うに、現時点で、このプロジェクトをこれ以上発展させるのは無意味だ。大勢の人がいまだに使っているので、利用者のために保守するのは重要だが、そこまでだ。

このブログ記事は、以上を念頭に置いた上で書く。

近い将来の、ポストX11の世界と、ポストデスクトップの世界には期待しているが、ひそかに思うに、またぞろ似たようなウインドウマネージャとかシステムコンポジターが必要なのかどうか疑問だ。Waylandでは、幸いにも今のところ、westonがいわゆるデファクトなコンポジターかつウインドウマネージャーになっている。つまり、どのように動くべきかという規格上の問題を心配する必要がなく、ウインドウマネージャーとクライアントの間をつなぐインターフェースが存在するだけだ。

最近の予測では、X11はいずれ退場するため、Waylandへ移植する必要がある。そのため、X11とWaylandを、共通のインターフェースに抽象化して隠し、いずれは移行を終える。どうやったらそんなことができるのだ？　二つの方法が思いつく。一つには、新しいwl_compositorを実装することだ。これはつまり、オペレーティングシステムにより提供されるサーフェイスのOpenGLコンテキストの初期化のためのオペレーティング・システムのインターフェースをなんとかしなければならない（Linuxの場合、KMS）。さらに、オペレーティング・システムにより提供されるグラフィックバッファーの管理もしなければならない（LinuxはGBM、Androidはgraloc）。さらに、ディスプレイモードやらディスプレイ回転やら何やらも面倒を見なければならない。2つ目は、wl_shellを実装することで、これはつまり、一度に有効にできるwl_shellはひとつだけになる。

そのようなシステムにおいて、Compizがユーザーに提供するものとはなんだ？　開発者として、私は以下のような点を挙げるだろう。

• OpenGLの基本的概念(vertex buffer objects, framebuffer objects, frame timing etc)に沿ったC++インターフェース
• 設定
• コールバックのディスパッチによるプラグイン
• reparentingをサポートしたウインドウマネージャー

利用者は、以下のような点を挙げるだろう。

• 状態変化に伴うアニメーション
• キューブ上の仮想デスクトップ
• グラフィカルなウインドウ選択

利用者が使っているこれらの機能はいずれも、コンポジットエンジンでしか提供できない機能ではない。我々のコンポジットエンジンが存在すべき理由がなくなるのだ。もうこれ以上、他の「ウインドウマネージャー」と同じ事をする別の「ウインドウマネージャー」だが、独自の機能も提供するといったものは必要ない。

CompizをUbuntuとUnityのために長年保守してきて学んだことは、コンポジットエンジンとウインドウマネージャーを正しく動作させるのはとても難しいということだ。実に多数の考慮すべき問題があるし、グラフィックドライバーはまともにうごかないし、OpenGLを使うのは嫌になる。Canonicalで働いていたとき、98%の労力はコンポジットエンジンとウインドウマネージャーを保守することに費やされ、2%の労力が、新機能の提供に費やされた。存在理由を探す方が難しい仕事だ。

Linuxのエコシステムにおける断片化の弊害だ。単に、車輪の実装が複数あるというのではない。ほぼ同じことをする完全な車両の実装が複数あるが、どれもほんのわずかだけ違っているのだ。ある者曰く、これこそ自由なソフトウェアの最大の強みであると。断片化の弊害を身をもって思い知らされた今、最大の弱みであると思う。

Compizで好かれているとある機能を提供するためだけに、完全なコンポジットエンジンとウインドウマネージャーを再実装するのはまったくもって合理的ではない。私は、精神的にも、プロジェクトのそのような方向にもっていき、このエコシステムにさらなる断片化をもたらし、新たな開発者をお互いに罵らせる理由をつくるというのは。断じてできない。

そのため、私にはCompizをWaylandに移植するつもりはまったくないし、そのようなことは一切推奨しない。

納得できる作業とは、利用者に好まれている機能を、すでに存在するフレームワーク上で提供することだ。つまり、より多くの人が共同開発することになり、労力が分散されない。

わたしはかつて、自由ソフトウェアの最高な点は、プロジェクトはメンテナーやコードベースがいなくなっても使えることであると思っていたが、間違いだった。

自由ソフトウェアの最高な点は、コードベースがその本来のプロジェクトを離れて活用できるということだ。

自由ソフトウェアの美しいところは、完全に終了することがなく、常に可能性の開かれている芸術品だということだ。プロジェクトからメンテナーが離れても、開発を続行できる道具は他者に残されているので、新しいメンテナーはプロジェクトを続行するか、あるいは新しいプロジェクトで部分的に再利用するかを選択できる。

私からすれば、現状は非効率的であり、あまりに競争的過ぎると思う。時には妥協や協調も必要なのだ。

協力して何か素晴らしいものを作ろうじゃないか。

Compizとは、本来コンポジットエンジンとして始まった。仮想デスクトップとか、ウインドウのアニメーションとか、ウインドウの配置とかいった機能は、なにもコンポジットエンジンでなければ提供できない機能ではない。

とすれば、Wayland環境では、Compizはその存在理由を失う。そのため、Compizやその他多数のほぼ同じ事をするコンポジットエンジンやウインドウマネージャーを断片独立してWayland上で再実装するよりも、皆で協力した労力の分散を低減したほうがいいのではないか、ということを言っているようだ。