背景：成功してるOSSでは開発者が組織的な形態をとっている 目的：オープンソースプロジェクトの隠れた社会構造について我々の実験で議論し，プロジェクト？の問題について議論する アプローチ：４つの仮説（質問）をたてる -RQ1:OSSプロジェクトのソーシャルネットワークにはサブグループのような隠れたコミュニティ構造は見られるのだろうか -RQ2:プロダクトに関する議論をする時は，他の議論をする時よりコミュニティ構造がstrongerである -RQ3:あるサブコミュニティに参加する人々は，異なるグループの人々よりも直接collaborateしているのだろうか -RQ4:サブグループ内の人々のソフトエンジニアとしての活動はおよそcohesive(結合)タスクのまわりに組織されている？ 分析手法 -RQ1:ネットワーク図を書いて次数分布から分析 -RQ2:プロダクトに関するメール内容とプロセスに関するメール内容の差がどれくらいあるかをWilcoxon test(2つの群の標本集団において，それらの母集団平均値に差があるか検定)で検定 -RQ3:同じグループ，もしくは異なるグループの2人が同じファイルに携わっているかどうか -RQ4:同じグループの2人がコミットしたファイル間の距離（フォルダがツリー状のときにどれだけ近くにファイルが存在するか）結果： -RQ1:yes -RQ2:yes -RQ3:yes -RQ4:?? 感想 必ずしもこれが正解ではない バグ報告者のコメントも見てないから OSSの人気のあるものを使っただけだからこれがどこでも通用するとは限らない ■ABSTRACT 複雑で大きくて成功しているOSSは開発者間のバザール内において組織的な形態をとっている どのようにOSSプロジェクト自身が成功しているのか？ コミュニティ構造を見抜く 様々なソーシャルネットワークをe-mailから隠れたサブコミュニティを抜粋し，数値を出す "chapels"はOSSとしてのバザールのように自発的に現れる 協調作業においてつながり技術的な議論を行いサブグループを見つける ■1.INTRODUCTION ■2.BACKGROUND OSSプロジェクトはlarge developer poolとqualityで構成されている メーリングリストの参加者を対象とし，それぞれのプロジェクトは成長し，安定し，複雑で大きい規模，歴史もあるプロジェクトである 開発者のプロジェクトって〜 もし全体的に特徴があるなら，個人間がコミュニティを形成している コミュニティ構造はソーシャルネットワークにおいてどのように発見されるのだろうか？ 関連研究 ●RQ1：OSSプロジェクトのソーシャルネットワーク内に結合力のあるサブグループの形態に隠れたコミュニティ構造の痕跡はあるのだろうか (OSSプロジェクトのソーシャルネットワークにはサブグループのような隠れたコミュニティ構造は見られるのだろうか) 参加者グループが組織的な形態である一方，この結果は興味がない，もしくはコミュニティの目的にいくつかの方法が関係しているグループの中に分裂しているのを 除いたのは グループが分裂しているのを除いた コミュニケーションやコーディネーションはたくさんの異なる目標を供給する開発者間のメーリングリストで活動する 開発者は〜な議論をしている process dissscussionにおけるトピックはばらばらにすべきでない サブグループにおけるソーシャルネットワークの崩壊は議論の崩壊につながる ●RQ2：コミュニティ構造はプロダクト関係の議論をしているときが重要？ (プロダクトに関する議論をする時は，他の議論をする時よりコミュニティ構造がstrongerである) 異なるグループの人々よりも，近いところで協力したグループ内の人々に期待する 異なる2つの方法で分析する First：もし同じグループ内の人々が直接collaborateしてるようだったらaskすることができる 例えば，同じファイルで働いているかどうか． SecondはRQ3で調べる ●RQ3：サブグループ内の人々は異なるグループの人々よりも（同じサブグループの人々と）直接collaborateしているのだろうか？ (あるサブコミュニティに参加する人々は，異なるグループの人々よりも直接collaborateしているのだろうか) グループがわかりやすいタスクをどことなく共同しているかどうか尋ねることができる ●RQ4：サブグループ内の人々のソフトエンジニアとしての活動はおよそcohesive(結合)タスクのまわりに組織されている？ ■3.RELATED WORK ■4.METHODS AND ANALYSIS 開発者のメーリングリストとソースコードを取得しました 3か月間の参加者のソーシャルネットワークを作りました 参加者を分類した妥当性は各段階で定量的に評価する ■4.1.Project Selection たくさんメジャーリリースしてる 数千の参加者が開発者メーリングリスト使ってる ＜プロジェクトの特徴＞ ■4.2.Mining the Raw Data ヘッダーの何を送信に，何を受信にしたか 3か月窓など ＜データのマイニング方法＞ ■4.3.Finding Community Structure ぐしゃってなってるネットワーク構造からコミュニティを見つける方法はいろいろあって，Newmanのやり方を紹介している． Newmanのやり方はエッジの重みについて考えていないらしい ソーシャルネットワークではエッジの重みもみないといけない！ ■4.4.Filtering Messages 2つに注目する １． 複雑なシステムだと親友同士で知識を共有するのは難しい だから各々のプロジェクトで数人の人で共有している これらの人はプロジェクトのリーダ的存在 リーダーはプロジェクトに長くいて，ほとんど全てのメーリングリストにコメントしている リーダーが協調作業している 本研究の手法→社会地位やソースコードにどれだけ貢献しているかを調べるためにリンク形体を分析する ２． 議論の内容に注目する varible names,functions,classes,filenamesを含むキーワードを静的解析ツールを用いてリポジトリにおける全てのバージョンのソースコードから抽出した プロジェクトのコミュニティ構造の強さを分析 式(1)を使って図2を作る 図4でPerlのコミュニティ構造（エッジの重みなし）を見るだけでもサブグループに分けられる Newmanはネットワークにおいて0.3というmodularity valuesやコミュニティ構造の強さを指し示した． 我々は図5においてfiltering messageの前後の両方の範囲の値を見つけた ★モジュール方式の重要性 統計的なモジュール方式の値って重要なの？ どのように人々を結びつけ，コミュニケーションを図っているのか 人々は故意にコミュニケーションをとりサブコミュニティを形成しているのだろうか 我々は同じような特性ををもつランダムグラフを分析することによって得ることができる値を観察し比較することで質問を評価する RQ1の裏付けがとれた ■4.5.Effect of Product and Process Topics コミュニケーションを制約する時サブコミュニティが形成される 図５は開発者メーリングリストで使用しているすべてのメッセージ，functionやfilenameに限るメッセージから，長期に渡るPostgreSQLで見られるモジュール化を示した． 表2ではproduct topic e-mailだけを含む時得られるモジュール化の平均増加を示す 我々はfilteredと unfilteredの違いを調べた サブコミュニティの中のグルーピングはソースコードについて議論する時，かなり強い 成功プロジェクトに関する仕事によって，サブグループにfocusする傾向にあるが，プロセスに関する議論は概して問題である RQ2の裏付けはとれた ■4.6.Community Structure and Activity Focus e ■ ■ ■ ■ ■ ■ ■