オープンソース開発の社会構造
NewsForge：KDE開発モデルとはどのようなものですか? オープンソース・プロジェクトに典型的なモデルですか?
Andreas Brand：KDEは典型的なオープンソース・プロジェクトです。メンバー構成と動機付けの仕組みを見る限りでは。中心にコアがあり、それを複数の周辺レベルが互いに混ざり合って取り囲む構造になっています。ボランティアは、コア開発者と周辺開発者に分類されます。開発者自体も、コアと周辺の両方で技術ドキュメントと翻訳のチームに分かれます。技術面に関しては、モジュール化ソフトウェアにアクセスするレベル、サブプロジェクトとメーリングリストのレベル、ホームページのレベル、そしてCVSリポジトリのレベルに分かれます。最重要のメンバーはCVSリポジトリ・サブプロジェクトにおいて中心的なソフトウェアを担当する開発者たちで、彼らは中心的なメーリングリストにアクセスします。このメンバーが指導的集団を形成します。
KDEコミュニティの調査結果は、それより規模の大きいオープンソース・コミュニティ（Ghoshらによる2002年の『 FLOSS調査と研究：開発者に関する調査 』やLakhaniとWolfによる2005年の『 なぜハッカーはあのように振る舞うのか 』）の調査結果と符合します。
KDEの組織構成、たとえばリリース調整担当者の位置付けなどは、他のプロジェクトと似ていますが、完全に同じではありません。決定の過程はプロジェクトによって違います。Linuxは博愛主義の独裁制ですが、Debianにはメンバーの「民主主義的」な投票制度があり、これはローマ帝国の元老院を思わせます。KDEには正式な意思決定機構はありませんが、開発の決定事項を扱うための特別なメーリングリスト（kde-core-devel）があり、またプロジェクトを去る者は後任を指名すべしというルールがあります。新メンバーを選出するには特殊なやり方ですね。小規模なワークグループとか非ボランティア組織や財団に見られる種類のものです。
NF：貢献者が好意的な評価を得ると「際立った人物」になるとあなたは報告していますが、「際立った人物」になることは、サブプロジェクトを大きくしたり、より多くのサブプロジェクトに関わったりする方向に必然的に結び付くとお考えですか? このような人物が影響力を通じて権力を持つとしたら、それは健全なのでしょうか?
AB：ソフトウェアへの取り組みが積極的なプロジェクト参加者は、多くの場合に盛んに意見を交換し、重要なタスクを手がけ、フレンドリーです。そういったことが好意的な評価につながるのです。こういった人々は、重要で複雑なソフトウェアを手がけ、複数のサブプロジェクトに取り組む傾向が見られます。しかも、責任感をもって仕事に携わり、多くの時間を投じます。これが、KDEのような規模の大きいボランティア・グループに見られる自然の成り行きです。
KDEでは、好意的な評価を得たからといって、権力の座に付くわけではありません。KDEの他のメンバーから評価されるということは、達成した仕事を鼻にかける態度が歓迎されないということです。KDEで重要な役割を持つメンバーの中には、KDEと連絡をとってプロジェクトに加わって初めて知るような名前が何人もいます。
KDEを観察するに、これは健全だと思われます。このような「際立った人物」がプロジェクトに携わって、ソフトウェア開発の邪魔にならずにプロジェクトをしっかりとまとめている限りにおいては。貴重なメンバーですが、問題の原因ともなりえます。たとえば、プロジェクトに居座って、新メンバーのアイデアを退けて彼らを怖がらせたりするのです。プロジェクトを向上させそうな特定のテーマについて論じることに異を唱えるかもしれません。
NF：KDEはボランティアを慰留したり、新たに獲得したりできると思いますか?
AB：KDEは、人が余暇を費やす他の娯楽やタスク、たとえば家族団らん、転職活動、学習の仕上げなどと競合します。去ろうとするメンバーを引き止めることは誰にもできません。強制的な参加ではなく、自由意志がKDEの大原則なのですから。ただし、KDEへの参加は続けたいが、労力は減らしたいと思う人はいます。こういった人々には、希望に沿った活動の場を与えるのが最適です。こうした事情があるので、新しいボランティアの獲得はとても重要なのです。
これまで、新メンバーはLinuxカンファレンスや雑誌記事などをきっかけに自発的に参加してきました。ほとんどの新人は、北ヨーロッパ出身の若くスキルの高いITエキスパートです。他の国々、たとえばアメリカ、インド、中国などでITエキスパートを獲得しようとしないのはなぜでしょうか? 年長のITエキスパートや非ITエキスパートをなぜ直接勧誘しないのでしょうか? 非ITエキスパートには、手始めに翻訳に参加してもらい、いずれグラフィックスやサウンドを担当してもらえるでしょう。もっとも、プロジェクトに深く関わるには特定のチャネルを通過することが、たとえば翻訳からソフトウェア開発へと進むようなことが必要です。
新メンバーを獲得するさまざまな方法を見るとわかるのは、このタスクを専門とするグループがないことです。このようなグループがあれば、新メンバー獲得の活動をインターネットのフォーラム、オンラインやオフラインの雑誌などで展開できるでしょう。
NF：ユーザコミュニティのニーズと開発者の自主的な活動にすれ違いはありますか?
AB：すれ違いの原因は、開発者とエンドユーザで関心を持つ対象が違うからです。開発者は、ブリコラージュ・メンタリティ（訳注：手持ちの限られた材料だけで必要なものを作り上げようとする心理構造）からソフトウェアの技術的な効率性を考えるのです。しかも、仕事に取り組む本人が最終的な決定を下すことが規範とされています。これと対照的に、エンドユーザはデザイン、安定性、使いやすさに価値を求めます。
ソフトウェアの安定性は、エンドユーザと開発者が共有する関心事です。この課題は、バグレポート・プログラムのBugzillaによりサポートされます。ソフトウェアの安定性については、問題を耳にしたことはまだありません。関心が分かれるのは、デザインや使いやすさなどの要素です。たいていの開発者は、複雑なソフトウェアをプログラミング作業に使うので、デザインや使いやすさを重要と思いません。また、使いやすさは、MicrosoftユーザがKDEに簡単に移行できるようにするソフトウェアのカスタマイズ性とも関係がある要素です。この視点を理解しない開発者も少なくありません。
エンドユーザが開発者と直接意見をやり取りすると摩擦が生じます。そういった場合、エンドユーザはしばしば正式なメンバーでないのだからとはぐらかされます。たいていの企業では、顧客と開発者の対話にマーケティング部門が介在し、その内容にフィルタがかけられます。KDEでは、使いやすさに関するグループが要求をフィルタにかけ、開発方針の素案を作成できるようです。このグループは、開発者とエンドユーザのニーズを代弁できます。ただし、開発者がこのグループの答申に耳を貸し、それを日々の作業に反映するぐらいの強い立場をこのグループは必要とするのですが。
ユーザのスキルが高ければ、直接の対話にはメリットがあります。ソフトウェアの品質を向上できるのです。これが宣伝効果を発揮し、新メンバーの参加を促します。おそらく、初心者を次のように区別すべきでしょう。使いやすさに関するグループと接触できる者、スキルの高いユーザ、開発者と直接連絡できる者、以上の3タイプに。
NF：企業では賃金が勤労の動機ですが、オープンソース・コミュニティでは金銭以外の要因が主な動機です。これはどのように作用しますか?
AB：企業では、従業員は給与に頼っているわけですから、気が進まない仕事でもいやとは言えません。給与のために働いているだけなので、好きで働いてる場合もあるでしょうが、それは例外です。通常、企業の開発モデルはプランニングされ、厳密にスケジュール化されます。KDEのやり方は違います。義務として何かをやらされる人はいませんが、楽しい作業はとてもはかどるものです。ありそうな失敗はどれも斟酌されます。他人に高く評価されるなら、バグの修正のような楽しくない仕事も苦になりません。制裁処分を受けることはめったになく、基本的な規範を踏みにじった場合とかプロジェクトの財産を私物化した場合などに限られます。制裁処分は企業ではもっと頻繁です。
自由意志には共同作業と共通の関心事という別のメリットもあるので、上からの管理は必要ありません。イデオロギーや政治の対立が起こらないということでもあります。したがって、ソフトウェア開発の大目標からの逸脱は起こりません。KDEでの作業は、開発標準やリリースプランのような制約に従って進むというより、試行錯誤に近いものです。
以上のような作用があるため、KDEには必然的に考え方の似た（と見込まれる）メンバーが自発的に集まり、役割を割り振られます。ほとんどの企業は社員の募集に困りません。人は生きるために働かなければなりませんから。
NF：自分の作成したものを配布する方法や製品を作成する方法をハッカーに個人的に決めさせることの重要性は何ですか?
AB:興味深い質問です。答えるのが難しいという意味で。ハッカーが利己主義的、理性主義的に振る舞う人物で社会とのつながりを持たないなら、共同作業はうまくいかないでしょう。また、この共同作業はインターネットに依存します。社会的交換 ─ 今のケースでは作業活動ですが ─ のような共通の関心事が欠かせません。共通の関心事があることが、仮想的なものであれグループの成立を促すのです。
個人が自宅で机に向かい、仮想グループの一員として共同作業に従事するのは、けっこうな試練です。プロジェクトの参加者に制裁処分や命令を下すことは誰にもできないので、各人の裁量範囲は広大です。ですが、参加者の誰もが明確に定められた特別な領域に責任を持つとか、連絡のやり取りが高度に効率的であるというのは、可能性でしかありません。仮想グループが大きくなると、新しい試練がプロジェクトに侵入してきます。新しい参加者に分担するため、たくさんのタスクがなければなりません。また、新しい調整の仕組みも必要です。プロジェクトが大きくなれば、扱わなければならない連絡、摩擦、ストレスも増えるからです。ですから、分業が横方向だけでなく、縦方向にも起こります。
タスクとソフトウェアのモジュール化は、水平方向の管理を楽にします。指導的集団に属するメンバーは、他のプロジェクト、Free Software Foundation、企業との関係といった、戦略的管理タスクを担います（垂直方向の管理）。プロジェクト全体を代表するのが彼らです。新しい責任を担う地位も生まれます。地位と役割が増えれば、メンバーを地位に割り当てる決定の仕組みが必要です。また、プロジェクト・メンバーの多数意見を反映できるような、なんらかの「投票制度」も不可欠です。KDEでは、メーリングリストでの討論が投票制度として機能します。他のプロジェクトでは、独裁制、民主主義制などの制度が生まれています。
NF：そういったさまざまな懸念がありながら、KDEプロジェクトを成功へと導いたものは何ですか?
AB：KDEプロジェクトとその成功を観察する場合、いくつかの時期と要因を区別しなければなりません。プロジェクトの初期では、創設メンバーたちは以前に所属したオープンソース・プロジェクトのソフトウェア開発者とコネクションがあり、彼らをプロジェクトに引き入れました。これが最初のバージョンの成功につながり、この成功がかっこうの宣伝になったのです。また、幸運にも彼らはちょうどよい時期にちょうどよい場所にいました。Linuxは急激な成長を見せていましたが、使いやすいグラフィカル・ユーザ・インタフェースはまだありませんでした（他のグラフィカル・インタフェースはあったのですが、どれもエキスパート向けでした）。単なる幸運であるばかりか、その隙間をうまく埋めたのです。
この後もサクセス・ストーリーは続きます。プロジェクトが上昇気流に乗ったのです。新しい優れた機能が追加された新バージョンの登場がさらに宣伝効果を上げ、新メンバーの獲得につながります。新メンバーの獲得が新しいアイデアと機能の向上につながります。KDEとGNOMEの競争がこの循環の原動力になったとする意見もありますが、私はそうは思いません。KDEのメンバーから直接聞いたのですが、この競争は大きなテーマではなかったのです。複数の動機の1つに過ぎません。また、GNOMEとは協調する関係にもありました。別の動機 ─ 彼らの言葉によると ─ は、コアライブラリとオブジェクト指向言語C++（これはライブラリのモジュール化を実現することによりソースコードの再利用を可能にする言語ですが）を絶えず強化することでした。
NF：では、結論ですが、これがプロジェクトを組織する最適な解法だと言えるのでしょうか?
AB：経営学の専門家が企業に推奨するような最適な解法があるとは思いません。特定のタスクに限定される最適な解法ならあるかもしれません。つまり、高い効率の得られる解法という意味です。ですが、このような解法は特定の組織の文化や企業の固有の事情に適合する必要があり、そうでなければ企業の事情に合うよう修正する必要があります。
これをオープンソース・プロジェクトに当てはめた場合、問題が生じた時点で新しいルールが導入されることに気が付くでしょう。問題のいくつかは、オープンソース運動や企業などの特定の環境で起こる問題や、メンバーの増加や作業の分配などの組織上の問題に結び付きます。環境や組織上の問題は、たいていのプロジェクトでは多くの場合に同じです。ですが、だからといってすべてのプロジェクトが同じルールを作ってこういった問題を扱うわけではありません。プロジェクトの創設メンバーは、最初のコードを書くだけでなく、問題への対処の仕方を決めるプロジェクト組織の文化を確立するのです。この文化に基づいて規則の体系が形成され、1つの規則がパズルのピースのように組み立てられます。
言い換えると、あるプロジェクトで有効な規則が、別のプロジェクトでは邪魔になるかもしれない、ということです。LinuxはKDEと同じ問題を抱えますが、こちらは博愛主義の独裁制で統制されています。プロジェクト・リーダーを選挙で選ぶことは、Linuxでは逆効果となり、独裁制への脅威となるでしょう。これは、模範的な立場とはなんら関係のない考え方です。模範という論点を考慮すれば、民主主義的な選挙は独裁制よりましだと思います。ですが、どちらが適正かはプロジェクトに従事する人しだいなのです。
NF：お時間をいただきありがとうございました。今後の研究に期待しております。
AB：こちらこそ。今回の調査報告はPELM Webサイトで閲覧できます。全文はドイツ語でしか読めませんが、英語の要約があります。他に、KDEの共同作業について書いた最近のドイツ語の新聞記事も公開しています。
原文
