オープンソースコミュニティのコミュニケーション構造分析

これはエンピリカルアプローチとしての段階「観察の実施」の例である。粒度は「リポジトリ」となる。

分析の目的は、オープンソースソフトウェア（OSS）開発において重要な、開発者とユーザの協調作業を助けるコーディネータの実態を知ることである。「バグ管理」からは少し外れるように思えるが、観察の結果得られた事実はバグ管理の観点から非常に有益なものであるので紹介したい。

調査背景

近年、行政機関や教育機関においてOSSの導入が進みつつある。一般的なOSS開発は、開発者やユーザがwww上に形成したOSSコミュニティにおいて、ルールや指揮系統の少ない個人間のやり取りを通じて自由に行われている。開発の停滞や中止を余儀なくされる場合も多く、エンドユーザが継続的なサポート（バグの修正や機能追加など）を得られなくなることがある。社会基盤としてOSSが普及しつつある現在、OSSコミュニティにおける開発プロセスの実態や成功要因を明らかにし、OSSコミュニティの継続的な活動に対する見通しを得るための方法を構築することが強く求められている。

例えば、ある程度の秩序と規律を保ちながら共同作業を円滑に進めるためには、開発者とユーザとの間の橋渡し的役割を担うコーディネータの存在が重要であると指摘されている。しかしながら、コーディネータが開発者とユーザとの間でどのようなコミュニケーション構造を築いているのか、その実態は明らかではなかった。

分析

そこで、ソーシャルネットワーク分析おいてFreemanが提唱している3つの中心性（次数中心性、媒介中心性、近接中心性）指標を用いて、「OSSコミュニティの参加者同士が形成するコミュニケーション構造を分析し、その特徴を観察」してみた。対象としたのは3つの有名なOSSコミュニティ「Apache」「GIMP」「Netscape」である。

コーディネータの媒介中心性に基づく可視化例
（画像をクリックすると別ウィンドウに拡大図を表示します）

この図はそれぞれのコミュニティにおいて、メジャーバージョンのリリースが行われた一期間におけるコミュニケーション構造を、媒介中心性に基づいて可視化したものである。開発者やユーザとのコミュニケーションが多い上位5名のコーディネータ（上位コーディネータ）をあらわすノードとエッジは濃く強調して表示した。

ApacheとGIMPのコミュニティでは、上位コーディネータをはじめとして、コーディネータの多くが開発者とユーザの双方のコミュニティとバランスよくコミュニケーションをとっている様子がよくわかる。一方、Netscapeコミュニティでは、開発者のコミュニティのみ、あるいはユーザのコミュニティのみとのコミュニケーションしかとっていないコーディネータが数多く存在している。

こうした結果は、「伽藍とバザール」でEric Raymondが経験的に指摘してきた、「開発者同士の協調作業だけではなくユーザからのフィードバックをできるだけ多く取り込むことがOSS開発の成功には必要」という点を、より定量的に示したものといえる。実際、この図で示したNetscapeバージョン6は完成度が低く、バグを多く含んでいた。結果としてWebブラウザ戦争において致命的なダメージとなり、以降Internet Exploreにシェアを奪われることになったといわれている。

以上のように、「バグ管理」とは一見関係のない観察であったが、得られた事実はバグの要因分析にもつながるものであった。なお、開発におけるコミュニケーションについて、このような観察や分析が進むと、「開発チーム内での情報伝達の問題点の発見（新人とベテランのコミュニケーション不足など）」「外部組織との窓口になっている担当者の情報伝達の過不足の確認」「開発組織内の情報伝達効率の把握」といった点で、ソフトウェア開発支援への応用が期待される。

以上、第3回は、エンピリカルアプローチの最初の段階「観察の実施」を中心に、具体的な研究成果を紹介した。次回の最終回では、「法則の発見」や「支援の実現」に向けた研究成果を紹介する。 タイトルへ戻る