オープンソースプロジェクトがプロセスを閉ざすことの弊害

 ここ何週間かでオープンソースプロジェクトにおけるオープン性の欠如に驚かされる出来事が2件あった。どちらのケースも、開発者が行動や発言によって、ほかの開発者を意図的に仕事から締め出そうとしたものものだった。

ケース1:許しがたいアイコン盗用

 最初の事件は、KDE 4で使われるアイコンのデザイン変更を順調に進めていたKDEのOxygenプロジェクトで起きた。OxygenのデザイナDavid Vignoni氏は、アクセス制限のない同プロジェクトのアイコンを外部の者が無断で別のテーマパッケージ(編注:当該パッケージはすでに削除されている)に収めたことに非難の声を上げたのだ。彼はそのテーマのパッケージャにOxygenアイコンの削除を要請し、彼のブログには声援を送るコメントが寄せられた。

 数日後、KDEのMarketing Working Group(マーケティング活動グループ)のWade Olson氏も自らのブログ投稿で、例の再利用テーマは道徳上問題があり、社会契約に反するとしてテーマパッケージャを非難した。このブログへのコメントもOxygen側に好意的だった。やがて、アートポータルgnome-look.org上にある問題のテーマのWebページにも、このテーマパッケージャを非難するコメントが届き始めた。

 Oxygenのアイコンセットは、Creative CommonsのAttribution-ShareAlike 3.0またはGNU LGPLのライセンス下で利用できるものだった。どちらのライセンスでも他人による再利用が認められている。また、アイコンそのものはSubversionの公開リポジトリから入手可能なもので、ライセンス違反や盗用にはあたらない点はVignoni氏もOlson氏も認めている。

 この再利用アイコンテーマに対する非難の内容は、本来は最初にOxygenプロジェクトからリリースされるべきアイコンだという点に集中していた。まだOxygenの正式テーマとして一般公開されていない以上、ほかの誰からのリリースも認められないというわけだ。中には次のようなコメントもあった。「このアイコンの作成に2年を費やしているデザイナの立場はどうなるのだ? 彼らには、ほかの誰かにコピーされる前に自分たちのプロジェクトでその成果を公開する権利を与えるべきではないか?」

 しかし、この問いに対する答えは明らかにそして完全に「その必要はない」である。成果物を公開サーバ上に置き、フリーソフトウェアライセンスの下で提供することを選択した時点で、ほかの人がそれをどのように利用するかを管理する権利は失われるからだ。

 また、プロジェクトが“公開準備完了”を宣言する前にそのアイコンを勝手にリリースするのは良くないというもう1つの不満は、“早めにリリース、頻繁にリリース”の原則とまったく相容れない。どちらの面でも、アートワークは実行可能コードと何ら変わらないのである。

 フリーソフトウェアのライセンスとオープンソースの開発モデルがあらゆる人々に一定の管理権の放棄を強いているのにはそれなりの意図があり、それはコミュニティ型の開発作業を実現する鍵にもなっている。

ケース2:君の手を借りなくてもアイデアは十分にある

 もう1つの事件は、GIMPのUI Redesign(User Interfaceデザイン変更)プロジェクトで起きた。10月にGIMP UI brainstorm翻訳記事)で情報収集を行ったときには、(プロジェクトのメンバーと外部の人を区別する)“我々”と“彼ら”という表現がプロジェクト内で露骨に使われていたのが印象的だった。

 UIプロジェクトのWikiにも、チームとそれ以外の人との対比が繰り返し見られる。また、変更の実施をチームのメンバーだけに制限するために、新規アカウントは作成できなくなっている。

 “got ideas?(アイデアが浮かんだら)”という見出しの下には、普通ならオープンソースプロジェクトへの参加を促すメッセージを期待するところだが、代わりに記されているのは、興味を持った者にGIMP UI brainstormへのコメント投稿を促す次のような案内だ。「GIMP UI brainstormは我々のチームによって管理されています。頂いたアイデアは検討して我々の参考にさせていただきます」

 しかし、プロジェクトへの貢献をこうした形で制限するやり方は、直接的に拒絶するよりはまだマシである。8月、UI Redesignプロジェクトのことを知ったある参加希望者が、協力者を募集していたgimp-developerメーリングリストにメールを出した。だが、GIMP UI RedesignチームのリーダPeter Sikking氏からの返信には「申し訳ないが、今のところ人手は足りている」と記されていた。

 その返信メールのほかの部分やgimp-developerメーリングリスト宛てのその他の投稿でも、Sikking氏のコメントからはGIMP UI Redesignプロジェクトを自分のチームだけの活動と捉え、チームにはこれ以上誰も参加させないという考え方が伺える。

 確かに彼のチームのメンバーは優秀だが、ほかにも貢献に値する人物がいる可能性すら否定する態度は、フリーソフトウェアとオープンソースの理念を無視したものといえる。それは、バザールではなく伽藍方式の考え方である。

 フリーソフトウェアの世界では、Bill Joy氏の法則 ― ほかを当たれば自分以外にも優秀な人材はいくらでもいる ― が尊重され、現状の打破を明確に打ち出すために開発プロセスをオープンにしているのだ。

オープン性を恐れる者はFOSSの世界には向かない

 どちらのケースの問題もその根本的原因は、当事者たちが真にオープンな開発プロセスにコミットできていないことにある。

 このことはGIMP UIのケースでは明らかだが、Oxygenのケースは少しわかりにくいかもしれない。Vignoni氏とOlson氏を怒らせた直接の原因は、承認されていない者がアイコンを勝手に利用したことだった。そして、認められた者と認められていない者という区別がどこから生まれるかというと、それはやはり、Oxygenメンバーの“我々だけにその資格がある”アーティストのチームという考え方なのだ。

 Internet ArchiveWayback Machineを使えば、Oxygenプロジェクトのサイトを2005年まで遡って調べることができる。このプロジェクトにおいて、創設以来ずっと変わっていない点が2つあった。利用可能な画像がCreative CommonsのAttribution-NonCommercial-NoDerivesのライセンス下にある“プレビュー”だけであること、そしてチームが外部からの参加を求めていないことだ。

 こうしたOxygenプロジェクトの方針は、Webサイトのあちこちでいろいろな方法を使って参加者を広く募っているTangoプロジェクトとは対照的だ。また、GIMP UI設計変更チームのやり方は、GIMPプロジェクト全体から見ると異質である。GIMPプロジェクトでは、外部の多くの人々にバグレポートやアイデアの提供を呼びかけ、それらを受け入れているからだ。

 どちらの方法がうまく行きそうだろうか。ちなみに、ソフトウェアの自由はファイルのコピーだけに適用されるものではない。プロセス全体にあてはまるものだ。

 OxygenとGIMP UIチームがどのように考えていようと、外部からの参加を広く受け入れることでチームが弱くなることはなく、むしろ強くなる。これは、オープンソースソフトウェアの運動を生み出した理念の重要な部分である。ほかの人々の考えに(それが気に入ろうが気に入るまいが)耳を傾けることは、必須のポイントなのだ。

 Vignoni氏をはじめとするOxygenのアーティストたちが美しいアートワークを手掛けていること、またSikking氏と彼のチームメンバーたちがGIMPのインターフェイスをより良い方向へと導く優れた成果を上げていることは、どんな客観的基準で見ても明らかだ。しかし、それぞれのプロセスに制限を設けることで、彼らは自分たちとほかの人に害を及ぼしている。彼ら自身はアイデアの行き詰まりや利用可能なマンパワーの減少といった不利益を、そしてほかの人々は相互交流の機会喪失と新参者による協力の減少という不利益を被っているのだ。

 君の力を借りる必要はない、とgimp-developerへの応募者に伝えたSikking氏に悪気がなかったのは間違いない。以前、話したことがあるが、彼は誠実な勤勉家だ。だが、その応募者はgimp-developerメーリングリストへの投稿をやめてしまった。ぜひ教えてもらいたいのだが、彼は身を引く必要があったのだろうか。私自身はそうは思わないのだが。

Linux.com 原文