N-A
commented
10 years ago コミュニティを学ぶための資料
コミュニティを学ぶ
| Team Geek | コミュニティ・オブ・プラクティス | 組織パターン | Fearless Change |
|---|---|---|---|
| オライリー | オライリー | amazon | amazon |
 |
 |
 |
 |
OSSコミュニティを学ぶ
アートオブコミュニティ
| アート・オブ・コミュニティ |
|---|
| http://www.oreilly.co.jp/books/9784873114958/ |
 |
伽藍とバザール Eric S. Raymond
The Cathedral and the Bazaar: Japanese http://cruel.org/freeware/cathedral.html
| 伽藍とバザール |
|---|
| http://www.amazon.co.jp/o/ASIN/4904807022/ |
 |
| ※山形氏の翻訳を4章と5畳を加えて製本した物 |
10.2 オープンソースをすすめる差別化要因
『伽藍とバザール』で提出された分析から見て、オープンソースのメリットが高いのは次のようなときだと予想できる。(a) 信頼性、安定性、スケーラビリティがとても重要な場合、そして(b) デザインや実装の正しさが、独立ピアレビュー以外の方法ではきちんと検証できない場合（この 2 番目の基準は、現実的にはちょっとでも複雑なソフトならほとんどの場合にあてはまる）。
中略
オープンソースがクローズドソースよりも大きなリターンを生み出すのは、それが(d)共通のコンピュータ・通信インフラを確立するか可能にする場合である、ということになる。
最後に、ユニークなサービスや、非常に差別化されたサービスの提供者たちは、自分たちのやり方が競合相手にまねされるのをおそれるインセンティブが高い。かなめのアルゴリズムや知識ベースがよく知られているようなサービスベンダの場合は、それが低いだろう。つまりは、(e)カギとなる手法（あるいはそれと機能的に等価なもの）が一般的なエンジニアリング知識の一部であるときのほうが、オープンソースが有力になりやすい。
インターネットの中核ソフト Apache と、Linux の ANSI 標準 Unix API 実装は、この 5 つの基準すべての見事な見本になっている。こういう市場がオープンソースへと進化する道筋は、DECNet、XNS、IPX みたいなクローズドなプロトコルで帝国を築こうとする、15 年にわたる試みの失敗に続いてデータネットワーキングが TCP/IP に再統合されたのを見てもよくわかる。
一方では、オープンソースがほとんど意味をもたないのは、価値を生み出すソフト技術を独占的に保有していて（これで条件(e)は立派に満たされる）それが (a) 失敗や欠陥があまり問題にならなくて、 (b) 独立ピアレビュー以外の方法で簡単に検証できて、 (c) ビジネスの生死を左右するものではなく、(d)ネットワーク効果や遍在性によって、その価値が極端に増えたりしないような企業の場合だ。
まとめると、オープンソースをすすめる差別化要因としては次のようなものがある。
(a) 信頼性、安定性、スケーラビリティがとても重要な場合。 (b) デザインや実装の正しさが、独立ピアレビュー以外の方法ではきちんと検証できない場合。 (c) そのソフトがその利用者のビジネス展開を決定的に左右するような場合。 (d) そのソフトが、共通のコンピュータ・通信インフラを確立するか可能にする場合。 (e) その核となるメソッド（あるいは機能的にそれと等価なもの）が、よく知られた工学的な知識の一部であるとき。
ハッカーになろう Eric S. Raymond
How To Become A Hacker: Japanese http://cruel.org/freeware/hacker.html
ハロウィーン文書 Eric S. Raymond
The Halloween Document: Japanese http://cruel.org/freeware/halloween.html
OSS プロジェクトを始めるのはむずかしい
エリック・レイモンド曰く：
バザール形式で最初からコードを書くのが無理だというのは、まあはっきりしているだろう。バザール形式でテストしたりデバッグしたり改善したりはできるけれど、プロジェクトを最初からバザール式で始めるのはすごくむずかしいだろう。リーヌスはそんなことはしなかったし、ぼくもしなかった。あなたが生み出そうとしてる開発者コミュニティは、いじるために何か動いてテストできるものを必要としているんだ。
レイモンドの議論は、はっきりした前例／目的がないとき（または多すぎるとき）にプロジェクトを開始・維持するむずかしさにも拡張できる。
バザールの信用
インターネット上には明らかに、OSS コミュニティの数よりはるかに多いソースコードの断片がある。こういう「死んだソースコード」と躍動するバザールとの差はなんなのだろう。
ある論考 (http://www.mibsoftware.com/bazdev/0003.htm) は、次のような「信用」の判断基準を提示している：
「（前略）参加者の最低数でこれを考えようとするのはまちがっている。Fetchmail や Linux はいまでこそ多数のベータテスタがいるけれど、最初はほとんどいなかったはずだ。
いずれのプロジェクトも持っていたのは、少数の熱狂的支持者と、納得のいく約束だった。この約束は一部は技術的なもので（このコードはちょっと努力すればすばらしいものになるよ）、一部は社会的だった（おれたちの仲間になったら、おれたちなみに楽しい思いができるぜ）。だからバザールが発達するのに必要なものは、いずれ立派なバザールができあがるという信用なんだ！
バザールが信用できるために存在すべき、鍵となる評価基準には以下のようなものがあると提案したい：
- 大きな将来のノウアスフィア ――プロジェクトはクールなもので、その知的な報酬が、開発者の投資する時間に十分見合うものでなければならない。 Linux OS はこの点が優れている。
- 大きな悩みを解決する ――プロジェクトは、開発者の大群衆にとって重要かつ導入可能でなくてはならない。Apache web サーバはこの見事な例である。
- まずは問題のそこそこの部分を解決せよ ――問題を解決しすぎてしまうと、 OSS の開発コミュニティをただのテスターの役割におとしめることになってしまう。 OSS になる前に解決した問題があまりに少なければ、「納得のいく約束」が減ってしまい、作業を効率よくあんばいするためのコンポーネントの枠組みが提供できない。
{ この3点はとてもよく考えられていて、ぼくの『伽藍とバザール』での描き方よりさらに改善されている。「大きな将来のノウアスフィア」と「大きな悩みを解決する」とのかれの区別しかたは、言い方としてとてもうまい。 }
飽和点に達した後の開発
この問題を JimAll に話したところ、かれは「テールライトを追いかける」という完璧なアナロジーを提供してくれた。ろくに組織化もされていない群衆から、なにか統制のとれた行動を引き出すには、よく知られた目標を示してやることだ。テールライトを提供すると、曖昧なビジョンに具体性を与える。こういう状況では、テールライトがあることで強い核となるリーダーシップの代役が果たせる。
もちろん、この内的な組織化原理がもはやなくなってしまえば（そのプロジェクトがひとたび技術の最先端の「飽和点」に達してしまえば）、新たなフロンティアに向けてみんなを押し進めるために必要となるマネジメントのレベルはとてつもないものとなる。
{ ばかおっしゃい。オープンソースの世界では、いいアイデアを持った人物が一人いればそれでことは足りてしまう。 オープンソースの要点の一つは、技術革新をダメにしてしまうエネルギー障壁を下げることだ。ぼくたちは経験的に、著者の掲げる「とてつもないマネジメント」こそこうした障壁のなかでも最悪のものだということを発見している。
オープンソースの世界では、革新者はなにをやってもいいし、それが評価される唯一の尺度は、ほかのユーザがその新技術で実験したいと名乗りをあげて、しかもそれを気に入ってくれるかというだけだ。インターネットはこのプロセスを支援するし、オープンソース・コミュニティの協力的な伝統は、まさにこれを推進するようにできている。
「テールライトの追っかけ」や「強力な核となるマネジメント」に変わる第三の道（そしてこの二者よりもずっと効果的な道）は、成長する創造的アナーキーだ。そこでは千人のリーダと万人の追随者がいて、それがみんな同業者の査読の網で結ばれて、出ると同時に現実性をチェックしてしまう。
マイクロソフトはこれには勝てないよ。たぶんこれを本当に理解することさえできないだろう。少なくとも腹に落ちるまでわかることはないはず。 }
Linux はすでにいろいろな点で最先端の UNIX と肩を並べる飽和水準にまで達しているので、おそらくこれこそがかれらの直面する唯一最大の興味深いハードルとなるであろう。
{ Linux コミュニティはすでにこのハードルを越えただけでなく、それを完全に破壊してしまっている。この事実こそが、オープンソースが閉鎖ソース開発に対して持つ長期的な優位性の核心にあるんだ。 }
ドタ作業
OSS の将来において見るべきおもしろい点がもう一つあって、それは商業レベルの製品を完成させるのに必要な「ドタ作業」をどこまでうまく処理できるか、ということだ。
{ この種の仕事を「ドタ作業」（unsexy）呼ばわりするのは、なかなかおもしろい 盲点を示すものだ。ぼくの経験からいうと、ほとんどあらゆる仕事について、 どこかのだれかがそれをおもしろい、充実した仕事だと感じてそれをやって くれるものだ。 たとえば上に出てきた Unicode サポートの話を考えてみよう。次の3人のなかで、 最高のいちばんしっかりした Unicode サポートを実装してくれそうなのはだれだろうか：
- ジョー・M・サーフ、上司がWUS （ウィンドウズ Unicode サポート）をかれに割り振る。
- アナ・ナン、マレーシアに住んでいて、各種のアジア言語で情報を見るのに、 どうしてもマルチリンガルサポートが必要。
- ジェフ・P・ハッカー、インディアナ在住で、複数アルファベットをしっかり サポートするときの問題に魅了されている。
おそらくはアナかジェフだろう（もちろん技能などその他の条件はいっしょとする）。だってかれらは自分の悩みを解決しようとしているんだから。どう考えてもジョーではない。
さて、アナやジェフを開発にひきこむとすれば、どっちの開発モデルだろうか――クローズドか、オープンか？
簡単な質問だよね。 }
OS 界でいえば、ごく小さな基本的機能、たとえばパワー管理やサスペンド／レジューム、管理用インフラ、ユーザインタフェース（UI）のお化粧、深いUnicodeのサポートなどがこれに該当する。
Apache の場合、これはたとえばウィザードなどの初心者向け管理機能などかもしれない。
統合化作業、アーキテクチャ作業
各モジュール間の統合化作業は、 OSS チームが直面する最大のコストとなる。98年5月に Nathan Myrhvold から送られたメモでは、ソフト開発のあらゆる側面のうち、ブルックスの法則がいちばんきいてくるのがこの統合化作業であるという。
これまでは、 Linux は従来の Unix が押し進めてきた統合化／コンポーネント化モデルによって大いに メリットを被ってきた。加えて、Apache の構成は、HTTP プロトコルや Unix のサーバアプリケーションの設計が、比較的単純でミスに強い仕様になっていたために、かなり単純化されている。
核となるアーキテクチャや統合化のモデルに対して変更を必要とするような技術革新は、 OSS チームが受け入れるにはとてつもなくむずかしいものとなるだろう。なぜならそれは、かれらの前例とスキルセットの価値を同時に低下させてしまうものとなるからだ。
{ この予想は、オープンソース開発がデザインの前例に致命的に依存していて、したがって後ろ向きになるのは避けられないという、作者の既出の発言 と表裏一体の関係にある。いささか近視眼的だね――どうやらPython、Beowulf、Squeak (何百もの技術革新的なプロジェクトから敢えて三つ例をあげただけだけど）のようなものは、この人のレーダーにはひっかかってこないらしい。 マイクロソフトがこれを信じ込み続けてくれることを祈るばかりだ。だってそうすれば連中の対応も見当はずれになるから。これはかれらが（たとえば） Linux カーネルの SMP 化のような技術革新をどう解釈してくれるかにかかってくる。
おもしろいことに、著者はこの点でさっきと言ってることがちがう。
ある元マイクロソフト社員の話だと、「捨てることをあらかじめ予定」というのは、実はマイクロソフトでの明確な方針にかなり近いんだそうだ。ただしそれは、問題をなおすための方針ではなくて、マーケティングを有効にするためのもの。かれが参加していたプロジェクトは、MS Exchange にWebベースのフロントエンドをつけるプロジェクトだった。最初の素案（14ヶ月かかってつくったもの）は既存のフリーWebメール（Yahoo、Hotmailなど）にくらべてまったく劣ったものだった。これに対する公式回答は「（肩をすくめる）ま、いっか。とりあえずは市場シェアだけ稼いで、その後三、四年かけて技術的な問題はなおしていけばいいよ」
かれはさらにこうつけ加えている。インターネットエクスプローラ 5 は、あるベータリリースの直前に、なおすつもりでいたバグが 300K 個 (誤植じゃないよ、300K個だよ) ほど残っていた。で、このデバッグの相当部分は、単に予定の（新）機能をどんどん取り除いて、それを将来の（一、二年先の）リリースにまわすことで達成されたそうな。 }
組織としての信用
OSS は、消費者がソフト提供者に期待するような サービス をどうやって提供するのだろう。
サポートモデル
製品サポートは、 OSS パッケージの潜在顧客がまっさきに心配する点であり、商業再販業者がなによりも強調する点でもある。
しかしながら、 OSS プロジェクトの大多数は、それぞれのコンポーネントの開発者によってサポートされている。このサポートインフラを、商業製品で期待されているレベルにまでスケールさせるには、かなりの苦労が必要となるだろう。IIS vs Apache で見ると、ユーザと開発者の距離は数層倍も異なっている。
{ この最後の文のあいまいさはなかなか意味深だ。もし著者がこのまま続けていたらかれはApache が市場において IIS をぼこぼこにやっつけている点を認めなければならなくなったはずだ（ Apache のシェアは 54% で上昇中。 IIS のシェアは 14% あたりで低下中）。 これを進めると、非常に不愉快な（マイクロソフトにとって）選択を迫られることになっただろう。ひょっとすると Apache の非公式なユーザサポート・チャンネルや「組織としての信用」は、実はマイクロソフトの IIS 組織が提供するよりましな結果を産み出すんだろうか。もしそうならば、原理的にはそれがほかのオープンソースプロジェクトにあてはまらないという説は理解しがたい。
別の可能性は、Apache はあまりに優秀で、サポートだの「組織的な信用」だのをそもそも必要としないというものだ。これはこれでなお（マイクロソフト的には）悪い。これはつまり、マイクロソフトの重装備サポートやマーケティング軍団が、実は単に巨大な悪投資で、40 年でボロボロになるスターリン時代のアパートみたいなものだということになるからだ。
この二つのあり得る説明は、オープンソースの支持者たちにとっては別々の（だが並行した）戦略を意味している。一つは、優秀すぎてサポートなんかあまりいらないソフトをつくることだ（とはいえぼくたちは、こんなことは言われるまでもなくやるし、これまでだってやってきた）。もう一つは、いままでサポート用のメーリングリストやニュースグループ、FAQなどの非公式ながらきわめて有効なチャンネルを通じて、すでにやっているようなことをもっと強力に進めることだ。
ある元マイクロソフト社員はこうつけ加えている：NT5（じゃなくてWin2Kでしたっけ :-) が出ると、マイクロソフトは IIS の市場シェアが大きく増えましたという主張をすることになっているそうな。なぜかというと、 IIS5 は NT カーネルと直接リンクするようにつくられていて、IISが外部のTCP トラヒック（メールや http など）をすべて担当することになるからだ。 MS オフィスも、NT や Exchange とやりとりするときには、IIS を通じてやることになって、だから内部の LAN トラヒックはすべて、IIS の利用実績ですと主張できるようになるからだ。さて、この風船がぶちあげられる前につぶせるかどうか、一つやってみましょうかね。 }
短期・中期的には、この要素だけでも OSS 製品をユーザコミュニティのいちばんの選択から追い落とすことになるだろう。
戦略的な未来
OSS プロジェクトを消費者が全面的に受け入れるに当たって影響してくる、非常に深刻な問題としては、 OSS の開発サイクルにおける戦略的な方向性の欠如が挙げられる。 手持ちの機能群をレベルアップする形での改良においては、 OSS 製品は非常に信用がおけるものの、将来の機能 については、その開発を保証するような組織的な対応はまったくない。
{ そのとおり。オープンソースコミュニティでは、新機能は個々のハッカーの新しいもの探しと領域探し行動によって突き動かされる。これはどうしてバカにできる勢力ではない。インターネットの Web もそうやってできた――「組織的な対応」のおかげではなく、どこかのだれかが「お――こうなったらすごいじゃん……」と思いついたからだ。 でもマイクロソフト的世界観で「組織としての信用」がそんなにでかい存在であることは、ぼくたちにとっては幸運なのかもしれない。連中が、そんなものが不可欠だと信じ込んでそれについて心配して費やす時間やエネルギーは、ぼくたちに対して本当に有効な対抗手段につぎ込まれたりはしないわけだから。 }
Linux コミュニティが、企業のデジタル神経システムを構築するのを手伝うために「契約する」というのは意味があるだろうか？ Linux はどうやって昔の API 用に書かれたアプリケーションが新しい OS で動くことを保証できるだろう。次のバージョンの Linux がこれまで対応していたものに対応しなくなったら、だれを訴えればいいだろう。 Linux は、ほかの主体と戦略的提携をしたりできるだろうか？
{ じゃあ、もし NT 5.0（失礼、「ウィンドウズ 2000」でしたっけ）が予定通り出荷しなかったら、だれを訴えればいいの？ マイクロソフトは互換性のなさとか各種ポカをいろいろやってくれてるけれど、それでマイクロソフトから賠償金を少しでも勝ち取れた人が一人でもいるの ? 新しい OS での動作保証についての質問はなかなか皮肉だ。だって、ぼくは、DOS と Windows 3.1 と Windows 95、Windows 98、NT 4.0 のすべてで何の変更もなしに動くソフトを寡聞にして知らないもの。
著者はここでいささか実際の出来事においついていないようだ、インテルにいるマイクロソフトの相棒さんたちにきいてごらん。かれらはこのメモが書かれて 2 ヶ月もしないうちに、Red Hatに劣位出資をしたんだよ。 }
第一回コミュニティを考える会をF2Fで行いました。その議事メモをここに共有します。 日時:2014/7/9 参加者:本橋さん、高柳さん、森 開催場所:知のフリマ、東京ハート
いつも話をしている場所
facebookグループのコミュニティを考える会 https://www.facebook.com/groups/564835673624598/
話したこと
人の集まりの話をした
コミュニティとしての集まり
もともとコミュニティとは制約ベースの集まりを指していた。制約とは血縁や地理、状況である。パターン・ランゲージのフォースも制約である。
目的ベースの集まり
コミュニティとは別の考えが目的ベースの集まりである。利益、技能のために集まり、プロジェクト型である。
ITコミュニティとしての集まり
この十数年で旧来のコミュニティと、プロジェクトのふたつを併せ持ったITコミュニティが誕生してきた。
OSSコミュニティとしての集まり
OSSコミュニティはLinuxを初めとする極めて効果的な成果物を生み出している。ただその動機は「ただ楽しいからby Linus」である。
目標× 監視× やる気× 組織化× リソース× 楽しいから◎
コミュニティのOPENとCLOSEの話をした
コミュニティによってオープンなコミュニティとクローズなコミュニティがある。 コミュニティはオープンさとクローズさのどこかに位置することになるが、時間が経つことにつれてクローズさへ向かう傾向がある。
クローズな場はよく知る人たちにとっては安心感を得るが、新規の参加者にとっては疎外感を感じる。これが問題になるのはオープンを掲げるコミュニティに参加しようとした人が実際には打ち解けなかったり、排除されてしまう場合だ。
コミュニティが壊れるとき
参加者として、コミュニティの進む方向性に一貫性がないと感じた時である。 大義名分は参加への動機である。
例
ある知識の人たちが話し合うことを主題に集まったが、その後集めた人に対してビジネスをしようとして、参加者は一気に離れた。
売上を上げるための場として集まっていたが、どんどん内輪になってビジネスの会話がなくなり興味が亡くなってしまった。
コミュニティの構造の話をした
次のアクション
・みんなでコミュニティの本を書く