■データの見方 ・sum ： 一人当たりのメール数 ・n.mail ： メール総数 ・num ： ユニークな人数 ・赤＝コーディネータ ・青＝開発者 ・緑＝ユーザ ■GIMP ・コーディネーター数は常に一定である ・特に最初の期間はメール数は多いもののネットワーク構造としての特徴が出ていない． これは同エッジ内で大量にやり取りをしていた場合に起きる． つまり，狭い重いネットワークのとき → 開発初期なので当然？ ・リリースの前（5ヶ月）くらいにコーディネーターのClosenessが上昇 バグ報告とか意見とかを取り入れている？ ■Netscape ・コーディネーターが安定しない コミュニケーションが安定しない とげとげのグラフ ■GIMP ・ユーザーが少ないのにも関わらずコーディネーターが多いということは コーディネーターがユーザーからの意見をきちんと吸い上げている ・サーバーダウン時期がある 開発後期にある中心性が一気に下がるゾーン ■全体 ・最初のほうは極端に仲がいいノード同士と疎なノードがばらばら 一定の開発者がほとんどの開発を請け負っている．負荷分散ができていない 一方で，後半はべたべたなネットワークに 皆で開発．つまり負荷分散 ・特にコーディネーターのClosenessは右肩上がり これらは中心性を見ないと分からない現象，メール数、人数のような非SNAではわからん ・コーディネーターの母数はNetscapeで20-50人程度 Mozillaも50人くらい，Gimpは20くらい ○C2DU（「コーディネーター → 開発者のメール数」と「コーディネーター → ユーザのメール数」） について ・今までは議論の検証のために使うという前提であったが，時系列に見ることにも意味がありそう - Apache ユーザーからの意見を吸い出せている リリース期間に開発者へ知識を吐き出せている - GIMP Apacheと同等 ユーザーから吸い出していない？ - Netscape 激しい とげとげ系 -------------------------------------------------------------------------------- ■仮説 1. 成功プロジェクトはコーディネーターうまく機能している． 検証 → Apache,GIMPのコーディネーターのClosenessが高い 検証 → C2DU 2. イノベーションを起こすためにはコミュニティが一定のモチベーションを保ち続けなければならない 停滞しないとか？ 検証 → いがいが で実証 3. コミュニティが成熟するにつれ，コーディネータがうまく機能 成熟系 Closeness → コーディネーターが右肩上がり ------------------------------------------------------------------------------- ■その他メモ等 ・成功と失敗の比較はできていない Netscape＝失敗といえないため ・In, Out 無駄．見ないほうが良い？ Allだけで十分か ・コミュニティのネットワーク - 開発者は小さくて密 ユーザーは巨大で疎 これが一般的 Netscapeはユーザーが巨大で密．特殊な形 ・Apache - 2003年10月あたり リリース時期でもないのに開発者が活発 異常？ 重大なセキュリティホールが出たとかその他情報は一切なし．不明 - 2.1 はテストバージョンであり，リリースという概念がない 2.1 に引いている線はなくてよいか - Apache 2.0.35が正式リリース 2002年4月くらい ・GIMP - 2.0 2004年3月 1.2 以来3年ぶり - 1.3 gdgd版っぽい - 1.4 ない does not exist ■分からんかったリスト（再掲含む） ・GIMP - 最後の次数の上昇は原因不明 - リリース5ヵ月後くらいに開発者のClosenessが上昇する 時間差がある なぜ？ そもそも「リリース後5ヶ月」というフラグは正しいか？ - ユーザの議論の場は GIMP.talk が別にあり つまりメーリングリストでユーザ数が少ないのはそれが原因 ・Apache - 2003年10月リリースでもないのにClosenessの盛り上がりがある - 2004年2.1リリース時には盛り上がらない → テスト版だからか？ - ■やりたいことリスト ・コーディネーターの箱ひげの推移 ・今回はネットワーク図に関する議論は行わなかった． 次，各プロジェクトの特徴的な時期のネットワーク図を確認すること