[[まつ本]]

*IPSJ イノベーションプロセスのスタディ 特集号 [#i9c873dd]
-IPSJ~
http://www.ipsj.or.jp/08editt/journal/tokushu/08-H.html~

-締め切り:2007年7月2日12時(月) %%2007年6月30日(土)%%~
電子投稿~
http://www.ipsj.or.jp/08editt/journal/submit/index.html

-タイトル~
OSSコミュニティにおけるイノベーションプロセスの理解:中心性分析の適用~

-原稿
&attachref(ipsj_ip2007_投稿用.pdf);

*査読結果(↑クリティカル) [#vd7337f3]
 ______  
 |←過密| 
   ̄ || ̄     オワタ┗(^o^ )┓三 
   ||         ┏┗  三 
  ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄

+分析対象とするメディア(MLとネットニュース)の違いを認めることができない.~
特にネットニュースそのもの衰退時期と重なっていることから,対象メディアの衰退である可能性がある
+各プロジェクトの成功・衰退の根拠がない
+仮説1「成功コミュニティでは,時間の経過に伴いコミュニケーションネットワークが過密化する.」に対して,「成功コミュニティでは」という前提がかかる理由が分からない
+「上位10%の平均」という処理についての妥当性の主張がかけている
+仮説1に「過密化」とあるが,何を持って過剰に密になるのか?~
また,表現上ネガティブな含意があるため不適切ではないか
+仮説1は新規参入者に対しての考慮が欠けている
+ケーススタディの一般化可能性について示してもらいたい
.一般化の可能な点と,モデルの改善が必要な点があるはずであり,「おわりに」で記述するべき
+イノベーションの解明という特集号のテーマに沿わない
+図1に対しての違和感

**コメント [#maf8d978]
+防御不足.~
メディアの違いが弱点という話は議論済みで,何か防御策を立てるべきであった~
ただし,ネットニュース衰退というのは盲点.
+防御不足.~
+指摘されてみるとやはりおかしい.~
衰退プロジェクトでも同じことがいえる気がする.
+これも想定済み,防御不足.~
+やはり「過剰」な形容詞は危険球.「大幅」とか「空前絶後」とかプギャー
+盲点.~
たしかに参加人数が増えれば増えるほど薄くなる感じがする.~
本質的には指摘3と同じ話
+考慮不足.
+イノベーションの解明という点では成功プロジェクトそのものを精査すればよいとのこと.
+よくわからん

**原稿修正案 [#p02a062f]
+対処は2通り
--各OSSコミュニティの主とする議論の場がMLとNNであったという旨を明記する.
--本質的に異ならないという点を主張する.~
たとえば「メッセージの受信方法はMLは受動的であり,NNは能動的であるというメディアの差は確かに存在する.~
ただし,本稿では各メディアへの発言者(つまり能動的な行為)に着目しているため,MLであるかNNであるかの差異は無視される?」
+_
--そもそも流れを変える~
現「成功・衰退の原因を明らかにする」→ショッキングすぎる.そもそも明らかにできていない.~
案「成功・衰退プロジェクトの様を観察する」→時間の変化とともに各コミュニティにどのような変化がおきているかをSNAを使って観察する.
--何か根拠を示す~
可能か?~
衰退でなくMozillaに変わっただけと突っ込まれたら死ぬ~
+x「成功コミュニティでは〜過密化する」~
o「成功コミュニティでは〜ある程度の規模を保ちつつ密度が高くなる」~
+案3つ
--参考文献で軽くスルー
--ねちねちと言い訳
--生データを載せる(平均値処理をしない)~
たしか結果はほとんど変わらんかった
+「過密化する」を消す.「密度が高くなる」.
+そもそもの潜在的な開発者・ユーザには限度がある.いわゆる「さちる」状態になる.
だから,一定までは新規参加者の増加に伴い密度が低くなるものの,そこから密度が高くなり出す?
+「成功・失敗の要因を明らかにする」から一般化の話がでるのか~
「観察」ストーリーにすれば一般化とか無視できるか~
+はいはいわろすわろす
+?

**Done [#w5365cdc]
-2007/06/06~
アウトラインの議論
&attachref(outline.ppt);~
-2007/06/10~
結果の議論
&attachref(原稿議論_070611.txt);~
**結果の解釈 [#z86848e6]
&attachref(graph.png,zoom,600x400);
+近接中心性:Apache,GIMP:は右肩上がり~
時間とともにネットワークが密に,コミュニティが成長~
~
+近接中心性:Netscape:開発者が一番低い~
開発者ネットワークが薄い・弱い,開発者同士のやり取りが出来ていない~
~
+メール数:GIMP:初期は開発者のメール数が多いが,中心性は高くない,平坦~
小さいネットワークで巨大なエッジを張っている,ローカルで密な会話,特定開発者への負荷が集中,負荷が分散できていない~
~
+媒介中心性:Apache,GIMP:コーディネーターが右肩上がり~
コーディネーターが順調に働いている.媒介してる~
~
+人数:Apache,GIMP:ユーザは減ってるが近接中心性は上昇~
一見ユーザの減少,ユーザネットワークの成長,ユーザの質の向上~
~
+リリース時期:Apache,GIMP:時期とあわせて何か変化してるとはいえない~
こまめなリリースが多いため,ネットワーク構造の変化は小さい.バザール方式の「こまめで早めなリリース」が原因か~
~
+2001/10:GIMP:人数・メールの上昇,中心性の減少~
サーバーの不具合~
~
+2005/08:Netscape:コーディネーターが0人に~
Netscape8の登場.同時にコーディネーターが死亡.やる気なくなった.崩壊へ...~
~
+媒介中心性:Netscape:コーディネーターとげとげ~
実際はコーディネーターの人数が少ないのが原因.建前でモチベーションが一定していないと捕らえることも可能だが~
~
**参考 [#tf09c429]
http://cruel.org/freeware/cathedral.html~
http://www.f.waseda.jp/negoro/paper/01-11opensource.html~
http://oss.mri.co.jp/floss-jp/floss_jp.html~
**memo [#ide70352]
-シュンペーター=イノベーションの神~
http://ja.wikipedia.org/wiki/%E3%83%A8%E3%83%BC%E3%82%BC%E3%83%95%E3%83%BB%E3%82%B7%E3%83%A5%E3%83%B3%E3%83%9A%E3%83%BC%E3%82%BF%E3%83%BC
-イノベーションとは?~
--アッターバック~
「イノベーションが起きにくい時期と大きな変化が起きる2つの時期がある」~
--野中郁次郎~
「個人と組織の自己改革」~
「知識は重要だが,知識の創造も重要」~
--シュンペーター
---新しい財貨、あるいは新しい品質の財貨の生産~
---新しい生産方法~
---新しい販路の開拓~
---原料あるいは半製品の新しい供給源の獲得~
---新しい組織の実現~
~
「知識だけでなくマネジメントという道具を使ってイノベーションが起きる」~
→ OSS は非マネジメント → 成功するのはなぜ? → 本稿は〜~
-伽藍とバザール~
--バザール方式~
「参加者を限定しないこと、参加者の独自性を尊重すること、階層的な組織ではなく個人が中心となったルールや命令系統の少ない方法で進められるのが特徴である。Linuxの場合は、最終的な取りまとめをするリーナス・トーバルズが交通整理をする協調的なコーディネータの役目をしている。」wikipedia~
--_
OSSはバザール~
Apache,GIMPもバザールの成功例~
Netsacpeはバザールの失敗例~
コーディネーターが働いてないのがNetscapeの失敗の原因か?~

**JIS補助漢字パッケージ [#j48a826d]
UMS.sty &attachref(ums.tar.gz);~
柗

*memo [#p50d8c7e]
- 分析結果をどう使うか?どう現実に役立てるか? --  &new{2007-11-12 (月) 16:12:39};
- 対象プロジェクトの選び方に節操がない. --  &new{2007-11-12 (月) 16:20:57};
- データ収集に依存しすぎ --  &new{2007-11-12 (月) 16:21:11};
- ↑データ収集に依存しすぎ --  &new{2007-11-12 (月) 16:21:11};

#comment

トップ   編集 差分 履歴 添付 複製 名前変更 リロード   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS