{ Halloween I -- 1.14}

オープンソース・ソフトウェア:ソフト開発の(新たな?)手法

原文はhttp://www.opensource.org/halloween/halloween1.htmlをどうぞ。



原文:マイクロソフト社内部文書
注釈:エリック・S・レイモンド  翻訳:山形浩生


{  ハロウィーン文書の本体は、 Linux /オープンソース現象に対するマイクロソフトの対応かもしれないものについての、内部戦略メモである。

 (この注釈つきバージョンは「ハロウィーン I」と改名。これには続編の「ハロウィーン II」があって、これは特に Linux だけを扱った第二のメモに注釈をつけたもの。)

 マイクロソフトは、これらのメモが本物であることを公式に認めているけれど、ただの技術上の調査であって、マイクロソフトの方針を決めるようなものではないとして受け流している。

 でも、文末にある協力者の一覧には、マイクロソフトの大物として知られる人も何人か含まれているし、文書の書きっぷりを見ると、経営陣の上層部から協力をえて行われた調査のように見える。ひょっとすると、ビル・ゲイツに関心を向けさせるための方針決定用白書として委託された調査だという可能性もある(著者はどうやら、ゲイツがこれを読むことを想定していたふしがある)。

 いずれにしても、これはいままでマイクロソフトがオープンソースに対して見せてきた、見下すようなマーケティング上の言いぐさとはうらはらに、この会社が本当はなにを考えているかについて貴重な示唆を与えてくれるものだ――そしてその考えというのは、読めばわかるように、抜け目なさと組織的な近視眼との奇妙な組み合わせだ。

 これが意図的にリークされたものではないかという見方もあるけれど、それはほとんどあり得ないだろう。この文書にはまずい部分が多すぎる。法務省との訴訟で、反競争的な行いの証拠と見なされかねないところもある。さらにこの著者は、最初にコンタクトしたときにはこの文書を「認めも否定もしなかった」。ということはおそらく、マイクロソフトは事前に筋書きを用意していなかったと考えられる。

 著者はぼくのオープンソースコミュニティの力学についての分析をたくさん引用しているので、(伽藍とバザールノウアスフィアの開墾)ぼくがコミュニティ代表として応対することは十分に正当化されると思う :-)

(訳注:これを両方とも訳したのはぼくだから、じゃあこれをぼくが訳すのも十分に正当化されると思う(笑))





さわりを引用すると……


 この文書のさわりを引用してみよう。リンクも埋め込んである。ちなみに、文中の「 OSS 」というのは、この著者流のオープンソース・ソフトの略。FUD というのはマイクロソフトの十八番の戦術で、説明は ここ

(訳注:ここまで訳してられないので、説明。FUD は Fear, Uncertainty, Doubt の略。ライバル製品が出てきたときに、それに対して「まだ出たばかりでわからないよ」「だれも使ってなくてこわいよ」「ほんとにいいの? ん? ん?」とさまざまなメディア操作を使って相手製品に対する不安をかきたてて、それを蹴落とす手口のこと。)

* OSS はマイクロソフトにとって、短期的な収入とプラットホームに対する脅威をもたらすものである――これは特にサーバの分野で顕著となる。くわえて、 OSS に見られる特有の並行主義と自由なアイデアの交換は、われわれの現在のライセンス・モデルではまねのできないものであり、したがって長期的には開発者たちの意識や方向性に対しても脅威となる。
* 最近のケーススタディ(インターネット)では、顧客の目から見て OSS プロジェクトで商業ソフト並あるいはそれを超える品質が達成できるという劇的な証拠が出されている。
* (前略) OSS に対抗する方法を理解するためには、ある企業を標的とするのではなく、プロセスをねらわなくてはならないのである。
* OSS は長期的に信用できる(中略)それへの対抗策として FUD 戦術が通用しない。
* Linux やその他 OSS 支持者たちは、 OSS がその商業代替製品と少なくとも同じくらい――ときにはそれ以上――堅牢であるという議論を、ますます説得力をもって展開しつつある。インターネットは OSS 界のショーケースとして理想的で、だれにでも見て取れるものとなっている。
* Linux はミッションクリティカルな商用環境にも導入され、きわめて好評をはくしている。(中略)Linux はほかの Unix の多くを上回る性能(中略)Linux はこのままいけば、いずれは x86 UNIX 市場を独占することになる。
* Linux は、サービスやプロトコルが共有物になっている限り勝ち続けられる。
* OSS プロジェクトが多くのサーバ・アプリケーションに食い込めたのは、高度に共有化された単純なプロトコルが広く使われていたからである。これらのプロトコルを拡張して新しいプロトコルを開発すれば、 OSS プロジェクトの市場参入を防止することができる。
* OSS プロセスが、インターネット中の何千人もの集合的な IQ を集めて、それを有効に利用できるという能力は、まさに驚異的なものである。もっと重要な点は、 OSS のエバンジェリズムは、われわれのエバンジェリズムの試みよりもずっと高速に、インターネットの規模拡大と対応する形でスケーリングしているということだ。

この文書の読み方

{}で囲んであって緑で書いてあるコメントはぼく (Eric S. Raymond)のもの。原文のなかで重要と思った部分は、赤くしておいた。コメントはこういう重要部分の近くに入れてある。このコメントの索引を順に読んでいくと、文書を一通り流し読みできる。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

 重要な部分とは関連していないコメントもいくつか入れてあって、それは索引がついていない。こういう追加コメントは、文書をまるごと通して読む場合にだけ関係してくる。

 それ以外では、この文書はまったくもとのとおりになっている(タイプミスさえなおしていない)ので、みんなビル・ゲイツがオープンソースについて読んでいるのと同じものを読めるわけだ。ちょっと長いけれど、がまんがまん。自分の反対者がなにを考えているかをきちんと把握するためには、それだけの努力をはらう価値がある――そしていくつか、企業用語の中に埋もれた実に恐ろしい洞察もいくつかあるんだから。

(訳注:翻訳では、まあスペルミスは残せないのでごかんべんを。あとこの原文の html のおそろしい書かれ方にもご注目。Microsoft Word 97 の吐いたとっても壮絶な html になっていて、まず <hn> タグを一切使っていないんだよ、これが(涙)。全部フォントサイズで見出しっぽくしてるだけ。このフォントの指定が日本語ではまったくうまくいかないので、いちばんの大見出しだけはぼくが勝手に <h2> タグを入れてる。そうしないと、大見出しが小見出しより小さくて、あまりに読みにくいのですもの。
 さらに要所要所に変なタグがたくさん入っていて、それがシナ語のフォントになってる。こういうの:

<FONT FACE="卜悶" LANG="ZH-CN" SIZE=3><P ALIGN="JUSTIFY"></P>
</FONT>
 これが行送りのためにしこたま使われている。こういうのはなるべく残してあるので、(ただし ESR もたまりかねて、コメントつきでかなり刈り込んでいる)ソースも見てやってください。特にフォントのせいで一部の表とかとてもきたなくなっている。見やすくしたほうがいいのかも。lynx で見たらどう見えるのか、こわすぎてやっていない。急いでいるのでご勘弁を。)


脅威の程度評価

 ぼくの見たところ、このメモが提案しているいちばん危険な戦術は、なによりもプロトコルの脱共有化(de-commoditizing protocols)という陰湿な一言に尽きると思う。

 この文書の公開は、なにはなくともこの戦術が示唆している競争の死滅や消費者の選択の消失、コスト上昇、独占囲い込みについて、みんなに警告を発することになってほしいと思う。

 マイクロソフトが Java をのっとって、この技術が持つ「一度書いたらどこでも使える(write once, run anywhere)」可能性をダメにしようとした例との類似は明らかだろう。

ぼくの断片的なコメントの中で、この点については 長めの議論をしている。この戦術を止めるためには、オープンソース支持者たちはこんな点を強調するようにしなければならないと思う:

  1. 買う側は共有物市場にいたがる。売り手はそれを嫌う。

  2. 共有サービスやプロトコルは消費者にとってメリットがある。価格は低いし、競争を推進するし、選択の余地を広げてくれる。

  3. プロトコルを「脱共有化(De-commoditize)」するということは選択肢を減らし、価格をあげ、競争をおさえつけることになる。

  4. したがってマイクロソフトが勝ったりしたら、消費者は必ず損をすることになる

  5. オープンソースは共有サービスやプロトコルを推進する――それどころか、それに依存している。したがってそれは、消費者の利益と一致している。


この文書の履歴

VinodV メモの初の (V1.1) 注釈版は、1998 年 10 月 31 日から 11 月 1 日にかけての週末につくられた。この日付を鑑みて、さらにはこれを公開することでマイクロソフトにとっての最悪の悪夢が実現される助けとなることを祈って、「ハロウィーン文書」と命名。

V1.2 は非ASCII文字を削除。

V1.3は、この文書が本物だとマイクロソフトが認めたことを加筆。

V1.4 はもうちょっと分析を加えて、脅威の程度評価の部分を加筆。

V1.5 は前口上をちょっと追加。

V1.6 はコメントの一つにさらに加筆。

V1.7 は「うわさ話の再確認」文書への参照を追加。

V1.8 はハロウィーン II 文書へのリンクを追加。

V1.9 は HTTP-DAV サポートについてのコメントを追加。

V1.10 は、「いざというときだれを訴えればいい?」問題についてのコメントを追加。

V1.11 は、OS/2 の支持者 Tom Nadeau (文中では TN )の Learning From Linuxページから、洞察に富んだコメントを追加。

V1.12 は、匿名希望の元マイクロソフト社員から、非常に参考になるコメントを追加。

V1.13 は、Tim Kynardの考えに基づいて「ドタ作業(un-sexy work)」に関するコメントを追加。

V1.14 は、ちょっとしたお片づけ。 }

 

 

Vinod Valloppillil (VinodV)

Aug 11, 1998 -- v1.00

Microsoft 社外秘

目 次

目次 *

Executive Summary *

オープンソース・ソフト *

OSS とはなにか *

ソフトライセンス方式の分類 *

オープンソース・ソフトはマイクロソフトにとって重要 *

歴史 *

オープンソースのプロセス *

オープンソースの開発チーム *

OSS 開発組織運営方式 *

並列開発 *

並列デバッグ *

紛争解決 *

動機づけ *

コードの分裂 *

オープンソースの強み *

OSS の指数関数的性質 *

長期的な信用 *

並列デバッグ *

並列開発 *

OSS = 「完璧な」API エバンジェリズムとドキュメンテーション *

リリース速度 *

オープンソースの弱点 *

管理コスト *

プロセスの問題 *

組織としての信用 *

オープンソースのビジネスモデル *

二次的サービス *

「最初は赤字」――市場参入 *

下流サプライヤの共有化 *

先手必勝――いまつくって、儲けは後 *

Linux *

Linux とはなにか *

Linux は本物の、信頼性の高い OS および開発プロセスである *

Linux はサーバ市場における短期・中期的な脅威となる *

Linux はデスクトップ市場での脅威にはならないであろう *

Linux を打倒するには *

Netscape *

組織とライセンス *

強み *

弱み *

将来予想 *

Apache *

歴史 *

組織 *

強み *

弱み *

IBM と Apache *


Transfer interrupted!

$NB> OSS プロジェクト *

マイクロソフトとしての対抗策 *

製品の弱点 *

OSS のメリットを利用する――開発者の意識や方向性の面 *

OSS のメリットを利用する――マイクロソフトの内部プロセス *

OSS 的なメリットを提供する――サービスインフラ *

正面きって OSS を攻撃するには *

興味深いリンク *

謝辞 *

改訂履歴 *

 

オープンソース・ソフト

ソフト開発の(新たな?)手法




Executive Summary

オープンソース・ソフト ( OSS ) は、既存のコード / 知識ベースに追加的な機能を高速に産み出し、それを導入したり、高速なバグ修正を行えるようにする開発プロセスである。近年、インターネットの成長とともに、 OSS プロジェクトはこれまで商業製品中心だった OS やミッション・クリティカルなサーバなどのような、深みと複雑さを身につけてきている。

このため、 OSS はマイクロソフトにとって、短期的な収入とプラットホームに対する脅威をもたらすものである――これは特にサーバの分野で顕著となる。くわえて、 OSS に見られる特有の並行主義と自由なアイデアの交換は、われわれの現在のライセンス・モデルではまねのできないものであり、したがって長期的には開発者たちの意識や方向性に対しても脅威となる。

{ なるほど、これでマイクロソフトが居眠りしているわけではないことははっきりした。

TN は、Java との関連でこれを説明している:
「はいはい、これは要するにどういう意味でしょうか? これはつまり、マイクロソフトは以下のいずれかに該当する製品ならすべて『脅威』とみなす、ということですね:

  1. MS 収入源の代替品となる製品:MS 製品以外に人がお金を出したくなる製品
  2. 代替プラットフォームとなる製品:MS の独占的立場を崩すかもしれない製品
  3. 開発者にとっての代替品となる製品:非 MS 製品向けソフトをみんなが書くようになる製品

 かれらの頭の中では、とにかく MS の代替品となるようなものは、すべて脅威なわけです。したがって選択の自由というのは MS にとっては、恐怖と唾棄の対象となります。MS を捨ててほかのプラットフォームに移行するのに、コストがゼロ(あるいはマイナス!)になる可能性すらあると考えると、MS は怖くて夜も眠れないわけですね。」 }

しかしながら、 OSS プロセスにはそれ以外の弱点があって、これを活用することで、アーキテクチャの改善(例:storage+ )やインテグレーション(例:schema )、使いやすさ、組織としてのサポートなどの主要な領域で、マイクロソフトは優位を獲得できる。

{ この提案サマリーがとてもおもしろいのは、この文書で後に登場するプロトコルの脱共有化(de-commoditizing protocols) などの具体的な提案にふれていないという点だ。

 ある元マイクロソフト社員が教えてくれた話しだと、ここやエグゼキュティブ・サマリーに出てくる「Storage+」への言及は、実は見かけよりずっと重要なものなんだそうだ。今後数年の MS の計画は、いまの FAT や NTFS ファイルシステムを完全に捨てて、Exchange をベースとした統合ファイル・データ・保存システムに移行することだという。かれらはまちがいなく、次の戦略的インフラとして一枚岩のモノリシックな構造を採用しようとしている。もしこれが成功したら、ユーザは完全に封じ込められてしまうことになる。 }




オープンソース・ソフトウェア

OSS とはなにか

オープンソース・ソフト( OSS )は、ある製品のソースとバイナリの両方が配布または入手可能な形になっているようなソフトであり、通常は無料である。 OSS はしばしば「シェアウェア」や「フリーウェア」とまちがわれるが、これらの製品それぞれのライセンスモデルとプロセスには大きなちがいがある。

ソフトウェアライセンス方式の分類

ソフト種類

             

商業ソフト

             

試用版ソフト

X

(機能は不完全)

X

非商業利用

X

(利用方法による)

X

         

シェアウェア

X-(強制のないライセンス)

X

         

無料バイナリ (「フリーウェア」)

X

X

X

       

無料ライブラリ

X

X

X

X

     

オープンソース (BSD式)

X

X

X

X

X

   

オープンソース (Apache式)

X

X

X

X

X

X

 

オープンソース ( Linux /GNU 式)

X

X

X

X

X

X

X

ライセンスの特徴

価格ゼロの導入

再配布可能

無制限利用

ソースコード入手可能

ソースコードの変更可能

コードベースに一般からの「チェックイン」が可能

派生したものもすべてフリーでなくてはならない。

 

ライセンス方式を大きくわけると以下のようなものがある:

商業ソフトは古典的なマイクロソフトの収入源である。購入されなくてはならず、再配布は禁止であり、ふつうはエンドユーザにはバイナリの形でしか提供されない。

制限付き試用ソフトは、ふつうは商業ソフトの機能が制限されたもので、無料配布され、商業コードの購入をうながすものとして意図されている。この例としては、60 日間で使えなくなる時限爆弾入り評価用製品など。

シェアウェア製品は機能は制限されておらず、自由に再配布可能だが、ライセンス条項によって個人も法人もいずれはそれを購入しなくてはならない。多くのインターネット用ユーティリティ(たとえば WinZip など)は配布方法としてシェアウェア方式を活用している。

非商業利用ソフトは、非営利の主体なら無料で入手できて再配布できる。企業などはこの製品を買わなくてはならない。この例としては、Netscape Navigator がある。

無料バイナリは、バイナリ形式でのみ自由に利用、配布ができるソフトをさす。Internet Explorer と NetMeeting のバイナリがこのモデルにあてはまる。

無料ライブラリは、エンドユーザがバイナリとソースコードを自由に利用、配布できるが、ライセンスに違反することなしには改変できないソフト製品をさす。例としてはクラスライブラリやヘッダファイルなど。

BSD式のオープンソース製品を開発して、バイナリもソースコードも自由に利用、再配布が認められる。ユーザはコードを改変してもいいが、開発チームは世間一般からの「チェックイン」を受け付けることはふつうはない。

Apache は BSD 式のオープンソース・モデルをさらに広げて、外部団体から核となるコードベースにチェックインを認める。

CopyLeft や GPL (General Public License) にもとづくソフトは、オープンソースのライセンスにさらに決定的な一歩を加えたものである。BSD や Apache 式のソフトはユーザにコードベースから分岐(フォーク)して、改変したコードに独自のライセンス条項を付け加える(たとえば商用ソフトにするなど)ことを認めるが、GPL ライセンスはあらゆる派生物もまた GPL コードにしなければならないとする。「このコードを好きにハックしてもいいけれど、そのかわり派生物もハック可能にすること」。

{ この最後の 3 つの区別のつけかたが、オープンソース・コミュニティの一般的な見方とは非常にちがった形で描かれている点は、注目にあたいする。

ぼくたちにとって、オープンソースのライセンスとそれがユーザや第三者に与える権利こそがいちばんだいじで、個別の開発手段はその場次第でいくらも変わり、それはライセンスのちがいとは特に結びついてはいない。ところがこのマイクロソフト流の文言では、いちばんだいじな区別は特権的な中央コードベースに対する write アクセスを持っているのがだれか、ということになっている。

これはずっと中央集権化された現実の見方を反映したもので、さらにはメモ著者の想像力ないし理解力の欠如を反映している。かれはぼくたちの分散開発の伝統を十分にgrokってない。まあ当然予想されたことではあるけれど…… }



オープンソース・ソフトはマイクロソフトにとって重要である

本稿は、オープンソース・ソフト( OSS )をとりあげる。 OSS は、2つの非常に重要な点で、ほかのライセンス形態(特に「シェアウェア」)と大きく異なっている:

    1. 核となるコードベースをまったくロイヤルティ料なしで入手する手段が必ずある。
    2. 無料配布バイナリとちがって、オープンソースは核となるコードベースを中心としたプロセス を推奨していて、ほかの開発者たちがコードベースを拡張するのを歓迎する。

OSS は次のような理由からマイクロソフトにとっての検討課題といえる:

    1. OSS プロジェクトが「商業レベルの品質」を獲得していること
    2. 多くの顧客環境で、 OSS にとっての主要な参入障壁になっていたのは、それが品質的に劣ると思われていたことだった。 OSS 支持者たちは、 OSS ではコード検査とデバッグ回数が増えるので、商業ソフトよりも高い品質のコードをつくれるのだ、と主張する。

      最近のケーススタディ(インターネット)では、顧客の目から見て OSS プロジェクトで商業ソフト並あるいはそれを超えるコード品質が達成できるという劇的な証拠が出されている。 しかしながらいまのところ、 OSS コードの質についての強力な証拠は、お話レベルのものにとどまっている。

      { いまの文章をまとめて読むと、「最近のケーススタディ」が全部「お話レベル」でない限りちょっと矛盾している。でももしそうなら、なぜそれを「劇的な証拠」なんて言うかね?

      どうも二番目の文章には、自己防衛的な「一歩下がって自分の議論の穴を埋めよう」的な動きがあるようだ。それでも、最初の分はマイクロソフトの譲歩としては(内部資料にしても)かなりのものだ。

      どのみち「お話レベル」というのは事実ではない。 「うわさ話の再確認:UNIXユーティリティとサービスの信頼性再検討(Fuzz Revisited: A Re-examination of the Reliability of UNIX Utilities and Services) 」を参照のこと。

      この論文から強力な文を三つ引用:

      「われわれがテストした商業版 UNIX のユーティリティに見られる欠陥率(failure rate)は(中略) 15-43% の範囲だった」「無料配布の Linux 版 UNIX では欠陥率が二番目に低く、9%。」「われわれの調査でいちばん低い欠陥率を示したのは GNU ユーティリティで、わずか 7% であった」
      TN のコメント:
       ここでの巧妙な区分の仕方にご注目(エリックも分析中で見落としていますが)。「商業ソフト並のコード品質」というのは、 どうやら真の意味での各種コード品質よりは「顧客の目」 (マイクロソフト自身の用語)を重視するものらしいのです。つまり、マイクロソフトやソフト市場一般にとって、ソフトウェア製品は、商業ソフト製品の「ルック&フィール」さえあれば「商業並の品質」があるのだ、というわけです。ある製品が商業水準のコード品質を持っているかどうかは、ひとえに、それが商業並のコード品質で書かれているという世間の見方にかかっていることになります。これはつまり、MS は魅力的で商業的なみかけの製品なら、なんでも真剣に対処する、ということです。MS は、それこそが典型的なあまり詳しくない消費者が「よいコード」の判断基準として使うものだと想定しているからです(そしてそれは正しい想定です)。

      ESR:おそらく TN の言うとおりだろう。ぼくがこれを思いつかなかったのは、オープンソースプログラマの通例として、インターフェースがどんなにきれいでも、やたらにクラッシュしていかれるようなソフトはクズだと考えているせいだろうね。

      }

    3. OSS プロジェクトは大規模で複雑になってきている
    4. OSS が対応してきたもう一つの参入障壁が、プロジェクトの複雑さである。 OSS チームは、これまでは商業的で、経済的に組織されて動機づけられた開発チームの独壇場だったような規模と複雑さを持ったプロジェクトに取り組んでいる。この例としては Linux OS 、Xfree86 GUI などがあげられる。

      OSS プロセスの活力は、インターネットと直結していて、分散化された開発リソースをものすごい規模で提供できるようになっている。 OSS プロジェクト規模をいくつか挙げると:

    プロジェクト

    コードの行数

    Linux カーネル (x86 only)

    500,000

    80,000

    SendMail

    57,000

    Xfree86 X-windows サーバ

    1,500,000

    "K" デスクトップ環境(KDE)

    90,000

    Linux のフルパッケージ

    10,000,000

  1. OSS はユニークな開発プロセスを持ち、強み・弱みも独特である

OSS プロセスは、その参加者の動機づけと、ある問題に対して持ち込めるリソースという面でユニークである。 OSS はしたがって、非常に興味深い、まねのできない資産を持っており、これについては十分に理解する必要がある。

{ TN のコメント:
これはなかなかおもしろい言葉遣いです――「まねのできない資産」――これが意味しているのは、マイクロソフトの行動原理はもっぱら、他人のやることをまねすることだ、ということですね。 }

歴史

オープンソース・ソフトは、ホビイストや科学コミュニティにそのルーツを持ち、開発者・ユーザたちの無制限なソースコードの交換を特徴としている。

インターネット用ソフト

OSS の最大の事例はインターネットである。インターネット最初期のコードは、Tim O'Reilly インタビューで語られているように、昔もいまもほとんどが OSS に基づいている (http://www.techweb.com/internet/profile/toreilly/interview ):

TIM O'REILLY: ぼくたちがまず手始めに伝えようとしたメッセージは、「オープンソース・ソフトは使いものになる」ということでした。(中略) BIND は、インターネット上の唯一最大のミッション・クリティカルなソフトとして、圧倒的な市場シェアを誇ります。Apache も最大の Web サーバです。SendMail はおそらくメールサーバの80%くらいを持っているでしょうし、おそらくインターネット上のメールで SendMail の世話になっていないものは一通たりともないでしょうね。

Free Software Foundation / GNU プロジェクト

現代的で組織化された OSS の最初の事例の称号は、ふつうは MIT の リチャード・ストールマン に与えらている。1983年暮れ、ストールマンはフリーの UNIX OS をつくりだすことを目的として、Free Software Foundation (FSF) ―― http://www.gnu.ai.mit.edu/fsf/fsf.html ―― を設立した。FSF は一連のソースやバイナリを、GNU なる愛称のもとにリリースしている(GNU は再帰的に "Gnu's Not Unix" の略とされている)。

もともとの FSF / GNU 活動は、完全に OSS な UNIX をつくるという最初の目的を達成できなかった。しかしながら、いくつかの有名で広く普及したアプリケーションやプログラミングツールを提供しており、それは今日も使われている。例としては:

CopyLeft ライセンス方式

FSF/GNU ソフトは、「コピーレフト」ライセンス方式を導入した。これによって、GNU ソフトのソースコードを隠すのは非合法となったばかりか、さらには GNU ソフトから派生したもののソースコードを隠すことまで非合法とされた。このライセンスを記述した文書は General Public License (GPL) として知られる。

Wired誌は、この方式とその狙いについて次のようにまとめている (http://www.wired.com/wired/5.08/ Linux .html):

General public license または GPL は、ユーザがコピーレフトされたプログラムを売ったり、コピーしたり、変えたりするのを認める――そしてそれに版権をつけることもできる――でも、自分の変更部分をも売ったり複製したり、さらにはもっと変えたりする自由も、いっしょにつけなくてはならない。さらに自分の変更部分のソースコードも自由に入手可能にしなくてはならない。

二番目の条項――派生物のソースコードを公開せよという部分――は、CopyLeft ライセンスのもっとも議論がわかれる(そして潜在的にはいちばん成功した)側面である。




オープンソースのプロセス

商業ソフト開発プロセスは、経済的な目的を中心とした組織化によって大きく特徴づけられる。しかしながらオープンソースの根底にある動機はしばしば金銭ではないので、われわれへの脅威の性質を理解するためには、オープンソース開発チームのプロセスとその動機づけについての深い理解が必要となる。

言い換えると、 OSS に対抗する方法を理解するためには、ある企業を標的とするのではなく、プロセスをねらわなくてはならないのである。

{ これはとてもだいじな洞察で、ぼくとしてはマイクロソフトにはこれを見落としてほしかった。本当の戦いは、 NT vs. Linux ではないし、 Microsoft vs. Red Hat/Caldera/S.u.S.E. でもない――それはソース非公開開発 vs オープンソースなんだ。つまり伽藍 vs バザール。

 これの反対もあてはまる。だからこそ、マイクロソフトをマイクロソフトだからといって叩くのは、的外れなんだ――マイクロソフトは症状であって、病気の本質ではない。 Linux ハッカーがもっとこの点を理解してくれたらと思う。

 現実問題として、この洞察はつまり、マイクロソフトのプロパガンダマシンはこれから特定の競争相手にではなく、オープンソースのプロセスと文化に向けられるだろうという意味になる。みんな、腹くくっとけよ……}

オープンソース開発チーム

インターネットを中心とした OSS チームの主要な特性は以下のとおり:

OSS 開発組織運営方式

コミュニケーション――インターネット規模

OSS チームの組織運営は、インターネット特有の協力にきわめて依存している。典型的な手法は、インターネットの共働技術を縦横に駆使している:

Linux や Apache 規模の OSS プロジェクトは、非常のスキルの高い開発者が集団である問題に取り組めるようになってはじめて成立可能となる。結果として、 OSS が処理できるプロジェクトの規模とインターネットの成長とには、直接の相関がある。

共通の方向性

通信メディアに加えて、チームの方向性を内在的に組織づける要因がもう一群存在する。

共通の目標

共通の目標は、開発チーム全員にとっての分散意志決定に先立つ、ビジョン表明と同じものである。単一のはっきりした方向性(例:「Unix をつくりなおせ」)のほうが、複数のわけのわからないもの(例:「すばらしい OS をつくろう」)よりもずっと効率がいい。

共通の前例

Linux OS のような巨大 OSS プロジェクトが、急速かつ協調的に成長してきた理由を説明するには、前例の存在こそが最重要要因である可能性が高い。全 Linux コミュニティは、何年にもわたりほかのさまざまな Unix について共通の経験をしてきているので、なにがうまくいってなにがうまくいかなかったかについて見分ける――しかもケンカにならない形で――のが容易なのである。

テキストエディタのコマンド構文をどうすべきかについての論争は存在しなかった――みんなすでに vi を使っていたから、開発者たちはコマンド名空間を切り分けて開発していっただけである。

歴史的な、完璧な岡目八目を持っていることで、強力かつ内在的な構造が提供されている。もっと前向きの組織においては、この構造を提供するのは強力でビジョンをもったリーダーシップとなる。

{ これは一見すると、著者がこれをゲイツに読まれることを予想して加えた、ビルへのごますりコメントにしか見えない――おそれを知らないリーダーというイコンの前でへこへこしている著者の姿が目に見えるようだ。

もっと一般的にいえば、これはオープンソース・コミュニティが独自のビジョンを持ったリーダーを産み出す能力を見くびっているという点で、非常に深刻で、ぼくたちが利用可能なものかもしれない。Emacs も Perl も World Wide Web も、「岡目八目」で生まれたものなんかじゃない――そして比較的保守的な Linux カーネルの設計でさえ、過去のモデルをつくりなおしただけの後ろ向きのものだと見るのはまちがっている。

つまるところこれは、オープンソフトに対するマイクロソフトの対応が、ぼくたちの行動面や、ぼくたちが世界に対して自分たちの活動をどう表明していくかという点で、技術革新を強調したりすることで見当はずれのものになる可能性を示している。 }

共通のスキルセット

NatBro は、 OSS 開発の前提条件として、共通に受け入れられているスキルセットの必要性を指摘している。この点は、共通の前例現象と密接に関連している。かれのメールから:

重要な特徴は(中略) OSS が活用して強化している共通の UNIX/gnu/make スキルセットだ。参入障壁がいまよりずっと高かったら、このプロセスすべてはうまく機能しないだろう。(中略)そこそこの技能しかない UNIX プログラマでも、 Linux や OSS 製品の多くではすばらしいことができるように成長できる。言い換えると―― OSS 界にいる開発者にとって、自分にとっての悩みを解決するのは大して難しくはない。いろんなものは似たように組み立てられ、デバッグも似ているから。

前例が最終目的を示す一方で、共通のスキルセットという属性は、その目的を達成するために必要とされるプロセスのなかで活用できる人数を表している。.

伽藍とバザール

オープンソース支持者エリック・レイモンドによる非常に影響力の高い論文が、1997年5月に公開されている(https://cruel.org/freeware/cathedral.html)。レイモンドの論文は、Netscape CTO(当時)の Eric Hahnによって広く引用され、これのためにかれらがブラウザのソースコードを公開するようになったとされる。

レイモンドは自分自身の OSS プロジェクトを解剖して、将来ほかの OSS プロジェクトが利用できるような一般則を導き出している。レイモンドの法則をいくつか挙げると:

よいソフトはすべて、開発者の個人的な悩み解決から始まる。

これは OSS プロセスにおける開発者たちの、中心的な動機の一つをうまくまとめている――その開発者個人が直面している、目の前の問題を解決することだ。これによって OSS はマーケティングやサポート組織からの絶え間ないフィードバックがなくても複雑なプロジェクトを発達させられるようになっている。

{ TN コメント:
つまり、オープンソースソフトはすばらしい製品をつくろうというのが動機で、マイクロソフトはグループインタビューや心理調査やマーケティングに動機づけられているってことですか。まあ今さら教えてもらうまでもなかったことですが…… }

何を書けばいいかわかってるのがよいプログラマ。なにを書き直せば(そして使い回せば)いいかわかってるのが、すごいプログラマ。

レイモンドは、伝統的な開発環境よりはもっと厳格なオープンソース・プロセスでのほうが、コードを再利用する可能性が高いとしている。それは常時、すべてのソースコードへのアクセスが保証されているからだ。

オープンソースのコードが広く提供されているので、特定のコードの切れ端を探すための探索コストは下がる。

「捨てることをあらかじめ予定しておけ。どうせいやでも捨てることになるんだから」

フレッド・ブルックス『人月の神話』第 11 章からの引用。 OSS の開発チームはしばしばものすごく離れたところにいるため、 Linux の多くの主要サブコンポーネントは、最初は複数のプロトタイプがあって、そこからリーヌスによる選択と洗練を経て単一のデザインになっていった。

ユーザを共同開発者として扱うのは、コードの高速改良と効率よいデバッグのいちばん楽ちんな方法。

レイモンドは、 OSS プロジェクトがメリットを最大化するためにはしっかりしたドキュメンテーションと強い開発者サポートがだいじだとしている。

コードのドキュメンテーションは、商業開発者が無視しがちな領域とされてるが、それは OSS では致命的なまちがいとなるとされている。

はやめのリリース、ひんぱんなリリース。そして顧客の話をきくこと。

これはマイクロソフトのマニュアルからそのままでてきたような古典的な命題である。しかし OSS 支持者たちは、かれらのリリース・フィードバックのサイクルは商業ソフトにくらべて何倍どころか何乗も高速になる可能性があると付け加えるだろう。

{ こいつはなかなか楽しくゴーマンな言いぐさだ。まるでぼくがなにやらマイクロソフトのバイナリだけのリリースに触発されたとでもいわんばかり。

しかし別のポイントも読みとれる。著者は、ソースコードのリリースの重要性を頭ではわかっているのに、まさにそのソースコードの早期リリースこそがいかに強力なレバーになっているのかという点を真にグロクしていない(心底、つかみきっていない)。マイクロソフト的な前提の中で暮らしている人には、もとより期待すべくもないのかもしれないけれどね。

TN コメント:
 ここでのちがいというのは、各リリースサイクルごとに、マイクロソフトは必ず 自分のいちばん無知な顧客の意見をきく、ということです。 こうすることで、ソフトはリリースごとにまぬけな代物になっていって、 非 PC 人口をさらに取り込むポイントになるわけです。一方、Linux や OS/2 の 開発者たちは、いちばん賢い顧客の意見をきく傾向にあります。 これはどうしても、OS のぱっと見のよさを低下させてしまいますが、長期的な メリットは高めてくれます。世代を追うごとにひどくなる製品を売り続けられるのは、マイクロソフトのような独占企業の特権なのでしょう。かれらの製品は、非常に幅の狭い、消費者ベースの中でもいちばん技術に疎い層に的をしぼっていて、どうしても技術的な優秀性は犠牲にならざるを得ないのです。 Linux と OS/2 は、技術的に優れたものを見分ける力のある顧客にアピールします。マイクロソフトが、コンピュータを使ったことのない人々にもコンピュータをもたらすことで産み出す善は、それが経験豊かなユーザにもたらす呪いによって帳消しになってしまいます。なぜなら、かれらの独占的な立場は、新規ユーザだけでなく全ユーザをいちばん低いところにそろえてしまうからです。

Note: これはつまり、マイクロソフトは PC 市場全体を「無理矢理」拡大しているということです。マイクロソフトが大いに恐れているのは、だれかに自分たちの背後にはりつかれて、高信頼性で高速で安全なだけでなく、使いやすくて楽しくて、生産性も高めてくれるような製品を作られてしまうことなのです。こうなってしまったら、マイクロソフトはただの先人でしかなくなって、露払いをしただけで、マイクロソフトが切り開いた領土に、もっと優れた製品の第二波が入植することになってしまいます。まあ、わたしとしてはなかなかいい手だと思いますが。

 だからわれわれとしても、マイクロソフトのいいところは学んで、新規ユーザの意見にもたまには耳を傾けるべきでしょう。でもそればっかりやりすぎて、マイクロソフトに対する技術的な優位性を失ってはいけません。

ESR からの返答コメント。ここで TN は、使いやすさと技術的な優秀性が必ず相反するものだという前提をおいているみたいだけれど、ぼくはそれには同意しない。きちんと設計してやれば、これは両立する。でも手持ちのリソースも限られて、設計能力も中から下となると、確かにこの両者は相反するものになりがちだ。だから、TN の分析は、ここで敢えて引用するだけのポイントはついていると判断した。 }

ベータテスタと共同開発者の基盤さえ十分大きければ、ほとんどすべての問題はすぐに見つけだされて、その直し方もだれかにはすぐわかるはず。

これがレイモンドの OSS プロセスに対する洞察の核心部分だろう。 かれはこの法則を「デバッグは並列処理可能だ」とも言い換えている。これについては後述。

{ ふん、少なくともそのくらいは ちゃんと読めたようだね。 }

並列開発

ひとたびコンポーネントの枠組みが確立されたら(たとえば中心となる API や構造が定義されたら)、 Linux のような OSS プロジェクトは複数の小チームを活用して、個別の問題を独立に解決していこうとする。

開発者たちはホビイストであることが多いので、複数の競合する努力に「予算をつける」のは問題とはならないし、 OSS プロセスはいろいろ出てきたなかからいちばんいいと思われる実装を選べることで利益を被る。

ただし、これは以下の点に大きく依存することに注意:

並列デバッグ

エリック・レイモンドの提出する中心的な議論は、ソフト開発のほかの部分はともかく、コードのデバッグはプロジェクトに関わる人間の数とほとんど正比例して効率があがる活動だということである。オープンソースのコードをデバッグするにあたり、管理や調整作業はほとんど/まったく存在しない――これが OSS にとってブルックスの法則から逃れる鍵となっている。

レイモンドは、 Linux のデバッグプロセスについてリーヌス・トーヴァルズの表現を収録している:

はじめにこの法則を書いたときは、どんな問題も「だれかには明白だ」という書き方をしていた。リーヌスはこれに異議を唱えて、問題を理解してそれをなおす人物は、必ずしもどころかふつうは、その問題を最初に記述する人間ではないと言った。「だれかが問題を見つける。そしてそれを理解するのはだれか別の人だよ。そしてぼくは、問題を見つけることのほうがむずかしいと述べたことは記録しておいてね」。でも肝心なのは、見つけるのもなおすのも、だいたいすごく短期間で起きるってことだ。

言い換えると:

「デバッグは並列処理可能だ」 Jeff [Dutky <dutky@wam.umd.edu>] の知見では、デバッグするにはデバッガは開発コーディネータと多少のやりとりは必要だけれど、デバッガ同士では大した調整は必要ない。だから、開発者を追加することで発生する、幾何級数的な複雑性と管理コスト増大という問題には直面しないですむというわけだ。

 並列デバッグのメリットの一つは、バグとその修正は従来のプロセスにくらべてずっとはやく見つかり、広まるということである。たとえば TearDrop IP アタックが web にポストされると、 Linux コミュニティがそれに対してまともな修正をダウンロード可能にするまでに 24 時間とたっていなかった。

「衝動的デバッグ」

わたしとしては並列デバッグに関するレイモンドの仮説を拡張して「衝動的デバッグ」というのを加えたい。 Linux OS の例でいえば、OS そのものをインストールする行為にはほとんど必ずといっていいほどいっしょにデバッグ・開発環境をインストールするという行為が含まれている。したがって、あるユーザ/開発者が別のだれかのコンポーネントにバグを見つけたら――そして特にそのバグが「深刻でなければ」――そのユーザはすぐにコードにパッチをあてて、インターネット共働技術を使い、そのパッチをコード管理者に高速に広めることができる。

 別の言い方をすれば、 OSS プロセスは GNU ツールから派生した共通の開発・デバッグ手法のおかげで、デバッグプロセスへの参入障壁をきわめて低くしているのだ。

紛争解決

大規模な開発プロセスはすべて紛争にであい、それを解決しなくてはならない。しばしばその解決は、プロジェクトを進めるために恣意的な判断として行われる。商業チームでは、企業の職階とパフォーマンス査定がこの問題を解決する。 OSS チームではどう処理されているのか?

Linux の場合、Linus Torvalds がプロジェクトの文句なしの「リーダー」である。かれは大きなコンポーネント(例:ネットワーク、デバイスドライバなど)を何人か信頼できる「副官」たちに移譲して、副官たちがそれを実質的に何人かの「エリア」(例:LANドライバ)所有者に移譲してゆく。

ほかの組織について、エリック・レイモンドは次のように書いている:(http://www.post1.com/home/hiyori13/freeware/noosphere.html)

一部のすごく大きなプロジェクトは、「やさしい独裁者」モデルを完全に捨てている。これをやる方法の一つは、共同開発者たちを議決委員会にしてしまうことだ( Apache がこうしている)。別の方法としては、独裁権を巡回方式にすることだ。ここではコントロール権は、上級共同開発者たちのサークルのなかで次から次へとまわされる( Perl 開発者たちはこういう形の組織を採用している)。

 

動機づけ

この章では、 OSS の開発者たちが OSS プロジェクトに貢献したいと思う主要な理由について概観する。

目の前の問題を解決

これは基本的に、レイモンドの最初の経験則を言い換えたものだ――「よいソフトはすべて、開発者の個人的な悩み解決から始まる」

多くの OSS プロジェクト――たとえば Apache ――は、目先の問題を解決しようとして出発した開発者の小集団から始まった。個人が自分のシナリオにあわせてコードを加えるにつれて、コードがだんだん改良される(例:あるNIC用のドライバがないと気がつく、など)

教育

Linux カーネルは、ヘルシンキ大学での教育プロジェクトから育ってきたものだ。同じように、 Linux /GNU システムの多くのコンポーネント(X windows GUI、シェルユーティリティ、クラスタリング、ネットワークなど)は教育機関にいる個人によって拡張されてきた。

{ この同じ著者が、あとになると Linux 連中どもは新しいアイデアをなかなか吸収できないなんて書いてるんだぜ! }

エゴの満足

OSS 開発の動機づけとしてもっとも実体がなく、しかしもっとも重要なものは、純粋なエゴの満足である

「伽藍とバザール」でエリック・レイモンドはこう述べる:

Linux ハッカーたちが最大化している「効用関数」は、古典経済的なものではなく、自分のエゴの満足とハッカー社会での評判という無形のものだ。

そしてもちろん、「ほかのひとからハッカーと呼ばれないうちはハッカーではない」。

ノウアスフィアの開墾

レイモンドの公開した二番目の論文――「ノウアスフィアの開墾」(http://www.post1.com/home/hiyori13/freeware/noosphere.html)は、経済的に動機づけられたやりとり(例:金銭のための商業ソフト開発)と「贈り物の交換」(例:栄光を求めての OSS )との差について論じている。

「開墾」は、ある所有物を最初に「発見」したり、それに対して大きな貢献をいちばん最近に行った人間になることによって取得することを指す。「ノウアスフィア」とは大ざっぱに、「あらゆる作業の空間」と定義される。したがってレイモンドの主張では、 OSS ハッカーの動機づけは、作業の総体のなかで最大の領域を獲得することである。いいかえると、賞のいちばん大きい部分を自分のものにする、ということだ。

{ これは些末ながらかなりの読みまちがい。ぼくの理論にはまったく出てこない、領域の「大きさ」が入っている。これは著者の個人的なまちがいかもしれないけれど、ぼくはこれがマイクロソフトの競争至上文化を反映しているんじゃないかと思う。 }

「ノウアスフィアの開墾」より引用:

過剰は上意下達関係を維持困難にして、交換による関係をほとんど無意味なゲームにしてしまう。贈与の文化では、社会的なステータスはその人がなにをコントロールしているかではなく、その人がなにをあげてしまうかで決まる。

...

というのも、こうして検討すると、オープンソース・ハッカーたちの社会がまさに贈与文化であるのは明らかだからだ。そのなかでは「生存に関わる必需品」――つまりディスク領域、ネットワーク帯域、計算能力など――が深刻に不足するようなことはない。ソフトは自由に共有される。この豊富さが産み出すのは、競争的な成功の尺度として唯一ありえるのが仲間内の評判だという状況だ。

もっと簡潔にいえば: (http://www.techweb.com/internet/profile/eraymond/interview):

SIMS: するとあなたの求めていた稀少性というのは、関心と見返りの稀少性だということですか?
RAYMOND: ずばりその通り。

愛他主義

これは議論のわかれる動機であり、わたしとしてはどこかの段階で、愛他主義はレイモンドの唱えるエゴの満足説に「退化」してしまうのではないかと思える。

一部はこの愛他主義から派生する別のもっと小さな動機づけとして、マイクロソフト叩きがある。

{ マイクロソフト社員自らこれを認めたというのは、なんとすばらしい! もちろん、かれはなぜそういう結びつきが存在するかを分析はしていない。だってそれはちょっとやばすぎるかもしれないもんね…… }

コードの分裂

あらゆる大規模開発チームにおける大きな脅威――そして特に、インターネット規模の開発チームということで生じるプロセスの混乱により一層拍車がかかる脅威――は、コード分裂のリスクである。

コード分裂とは、開発プロジェクトのいろいろなやりとりの中で、プロジェクトのコードベースに複数の共存できないバージョンが生じてしまうことである。

たとえば商業ソフトの世界では、Windows NT コードベースの強力で単一の管理は、商業UNIXの実装 (SCO, Solaris, IRIX, HP-UX など) などで見られる分裂したコードベースに対する最大の優位性の一つと考えられている。

OSS における分裂――BSD Unix

OSS 界の中で、分裂したコードのいちばんの例が BSD Unix である。もとものと BSD UNIX は、カリフォルニア大バークレー校によって教育目的で、無料の UNIX OSをつくろうという試みだった。しかしバークレーはこのコードベースの非学術利用に対して厳しい制限をつけた。

{ この著者のBSD分裂史の記述は、でたらめである。 }

完全にフリーな BSD UNIXをつくるため有志による(閉鎖的な)開発チームが FreeBSD をつくった。さまざまな理由から FreeBSD チームと対立した開発者たちが、OS をいじって別の変種をつくりだした (OpenBSD, NetBSD, BSDI)。

BSD ツリーが分裂にいたった要因として大きなものは 2 つある:

これらの動機はいずれも、開発者が BSD 社会全体を犠牲にしてでもコードを分裂させて報酬(お金でもエゴでも)を集めようとするような状況をつくりだす。

Linux における分裂(の不在)

BSD の例とは対照的に、 Linux カーネルのコードベースは分裂していない。なぜ Linux コードベースの一貫性が保たれているのか、その理由としては以下のようなものが挙げられる:

リーヌス・トーヴァルズは Linux 界における有名人であり、かれの決定は最終的なものとされている。対照的に、BSD 派生の活動では、このような有名人リーダーは存在しなかった。

リーヌスは開発チームから、公平で筋の通ったコード管理者と思われており、 Linux コミュニティにおけるかれの評判はかなり強力である。しかしリーヌスもあらゆる判断に関与するわけではない。通常はサブグループが、自分たちの――しばしばかなり大きな――相違点を自分たち同士で解決して、コード分裂を防いでいる。

BSD の閉鎖的なメンバーシップとは対照的に、だれでも Linux には貢献できるし、その人の「地位」――ということはつまり Linux のより大きな部分を開墾する能力――はその人のそれまでの貢献によって決まってくる。

間接的とはいえ、これはコード分裂をおさえるもう一つの理由になっている。分裂した少数派コードベースが、メインの Linux コードベースの技術革新速度を維持できると保証できるような、信頼性の高いメカニズムはほとんどないと言っていい。

Linux の派生物は必ずなんらかのフリーな形で入手可能でなくてはならないので、 Linux ツリーを分裂させた少数派にとっての長期的な経済的メリットは低くなる。

エゴ的な動機づけのため、 OSS 開発者は最大のノウアスフィアにいちばん大きくかけるようになる。コードを分裂させれば、どうしてもその後の新しいコードツリーの開発者にとって達成できる空間は縮小してしまう。




オープンソースの強み

OSS 製品の中核的な強みでマイクロソフトとして考慮すべきなのはどのような点だろうか。

OSS の指数関数的な性質

われわれの OS ビジネスと同じように、 OSS の生態系もいくつか指数関数的な性質を見せる:

OSS プロジェクトすべてが直面する最大の制約条件は、そのプロジェクトに時間を割いてくれるほど興味を持つような開発者を十分に見つけることである。これを可能にするものとして、インターネットはOS級のプロジェクトに十分なだけの人を集めるにあたっては絶対に不可欠だった。もっと重要なことは、これらのプロジェクトの成長エンジン が、インターネットの到達範囲の成長であったということだ。共働く技術の改良も、 OSS エンジンを直接的に潤滑している。

言い換えると、インターネットの成長は既存の OSS プロジェクトをいっそう大きくして、さらにはもっと「小さめの」ソフト領域における OSS プロジェクトも実現可能なものにするであろう。

商業ソフトと同じく、さまざまなカテゴリーにおいて、たった一つのいちばん優れた OSS プロジェクトが、長期的には競合する OSS プロジェクトを殺してその IQ 資産を「獲得」する。たとえば Linux は BSD Unix を殺しつつあり、その中核的なアイデアをほとんど吸収してしまった(そして商業 UNIX のアイデアも)。この特徴は、ある特定のプロジェクトで最初に動いたものに大きな優位性をもたらす。

OSS プロジェクトが大きいほど、そのノウアスフィアに大規模で高品質なコンポーネントを貢献することによる名声も大きくなる。この現象は、それぞれの分野で「勝者がすべてをかっさらう」という OSS プロセスにも貢献することになる。

プロジェクトが大きくなるほど、開発、テスト、デバッグもたくさん受けられるようになる。デバッグが増えれば、それを採用する人も増える。

長期的な信用

バイナリは死に絶えるがソースコードは永遠なり

すぐれた OSS 生態系の持つもっともおもしろい含意はその長期的な信用である。

長期的な信用とはなにか

長期的な信用は、その企業がどうやっても絶対に短期的に廃業に追い込まれることがない場合に生じる。この力は、競合相手がその企業にどう対応するかを変えてしまう。

{ TN コメント:
 ここでの「廃業に追い込まれる」という用語にご注目。 MS は、ほかの企業を廃業に追い込むことが、ただの「おまけの害」――つまり優れた製品を販売する副作用――だとは思っておらず、それが事業の直接的な目標だと思っているわけです。これを位置づけてみると、経済理論やふつうの正直な顧客重視の企業人であれば、ビジネスというのは自動車レースのようなものだと考えます。いちばん速い車にいちばん優れたドライバーが乗れば勝てるわけです。でもマイクロソフトのビジネス観では、それは殲滅ダービーみたいなものになります。競争相手をなるべくだくさんはじき出し、さらに状況をあやつって、競争相手たちがお互いにつぶしあうようにし向けるわけです。自動車レースでは、ゴールインする車はたくさんあって、賞金をもらえるドライバーもたくさんいます。殲滅ダービーでは、勝ち残るのはたった一人。これで「マイクロソフト」と「選択の自由」がまったくの別世界なのがおわかりいただけるでしょう。 }

たとえば、エアバス社は明文化された政府支援によって長期的な信用を獲得した。結果として航空会社からの受注をめぐって入札を行うときも、ボーイングはエアバス相手のときよりロッキード相手のときのほうが、短期的な非経済的な見返りを受け入れる見込みが高くなる。

ソフト産業固有の言い方におおざっぱにあてはめるなら、 ある製品/プロセスが長期的な信用を持つというのは、それへの対抗策として FUD 戦術が通用しないということである。

OSS は長期的に信用できる

OSS システムは、ソースコードが何百万もの場所や人から入手可能となっているために、信用がおけると見なされている。

{ ここでぼくたちはマイクロソフト的世界観にどっぷり浸かることになる。この種の考え方に対する典型的なハッカーの反応は、吐き気を催す、というものだろうけれど、これはぼくたちが対処方法を学ぶべき否定的なマーケティング手法の使用においての手段となるような、傍若無人さを反映しているんだ。

この2つの発言について本当に おもしろいのは、マイクロソフトはぼくたちに対する有効な戦術として FUD を使うのをやめるべきだと示唆している、ということだ。

ぼくたちの多くは、マイクロソフトが FUD をどんどん使わないのは、司法省の反トラスト訴訟のせいだろうと思いこんでいた。でも、もしゲイツ閣下がこのメモのここのところを受け入れたなら、マイクロソフトとしては FUD はきかないからもっと根本的な対抗策を作りだすべきだと考えているかもしれない。

これはいい知らせでもあり悪いしらせでもある。いい知らせは、マイクロソフトが攻撃的マーケティングをやめてくれるかもしれないということだ。この武器はこれまで、かれらの明らかに劣った技術よりはずっと強力な武器となっていた。悪いしらせというのは、少なくともぼくたちに対する限り、FUD をやめるほうがかれらとしては優れた戦術だということ。かれらはエネルギーを無駄遣いするのをやめて、本当にもっと有効な対応策を考えついてしまうかも知れない。}

Apache がなくなってしまうという可能性は、WordPerfect がなくなるという可能性に比べて数層倍小さい。Apache の消滅は、そのバイナリの消滅とは結びついていない(バイナリの消滅は、購買行動が変わったりすればあり得る)。むしろ、そのソースコードと知識ベースの消滅と結びついている。

裏返していえば、顧客としては5年後にも Apache があるというのを知っている――そのユーザ/開発者コミュニティから最低限の関心が維持される限り。

ある Apache 顧客は、e-コマースのサイトを OSS で動かしている理由としてこのように語っている。「だってオープンソースですから、開発者を一人二人はりつけておけば自分でいつまでもメンテできるじゃないですか」

コード分裂の不在が長期的信用につながる

GPL とそのコード分裂嫌いは、顧客として自分が特定の商業 Linux を採用しても進化の「どん詰まり」にいるのではないと保証してくれていることになる。

ソフトウェアでの FUD 論戦を張る場合には、「進化のどん詰まり」というのが核となるのである。

{ おっしゃる通り――そしてここにはまたもや、目をむくような抜け落ちがある。もしこの著者が本当に正直だったなら、かれは OSS 支持者たちだって十分にこの議論をひっくり返してマイクロソフトをつぶしてしまえるということを書いたはずだ。

この著者自身が認めているように、 OSS はこの点ではまったく弱点を持たない。ところが、こないだ改名されたばかりの「Windows 2000」の爆裂級複雑さと開発のずるずる遅れは、こっちこそ進化のどん詰まりであることを示唆しているのだ。

著者は敢えてそれを指摘してはいない。でもぼくたちはそれを指摘すべきだ。 }

並列デバッグ

Linux やその他 OSS 支持者たちは、 OSS がその商業代替製品と少なくとも同じくらい――ときにはそれ以上――堅牢であるという議論を、ますます説得力をもって展開しつつある。インターネットは OSS 界のショーケースとして理想的で、だれにでも見て取れるものとなっている。

{ これって、ほとんどが無報酬でほとんど全員が片手間にやってるような一握りのアマチュアと、この業界に完全に組み込まれて、技術マーケティング稼業の最高のスペシャリストたちがやってるような、何百万ドルものプロパガンダ装置との勝負なんだよ。

それでそのアマチュアどもが「ますます説得力をもって展開しつつある」だって。ぼくたちはホントに勝ってるんだって、マイクロソフト自身が認めてくれてるわけだ。 これって、そのベースになってる製品についても何事かを物語ってたりしないかな? }

特に、大規模で技術に強い組織で、業務を OSS に依存しているところ(例:ISP など)は、自分たちが業務の障害となるようなバグを、商業プロバイダのスケジュールなどまったく心配せずに、自ら直せる見込みがあるということで非常に安心していられる(たとえば UUNET は、Teardrop 攻撃がはじめて公に行われてから 24 時間以内に、使用している Linux マシンに Teardrop 攻撃対策用のパッチを入手、コンパイル、インストールできている)。

並列開発

別の言い方をするなら、「 OSS では開発者資源は実質的に無料」なのである。潜在的な開発者のプールが巨大なので、ある問題に対して複数の異なる解決法やバージョンを同時に試してみて、最終的にいちばんいいのを選ぶという方法が経済的になりたってしまう。

たとえば、 Linux の TCP/IP スタックはおそらく3 回書き直されている。特にアセンブラで書かれているコンポーネントは、たえず細やかなチューニングを受けて改良され続けている。

OSS = 「完璧な」API エバンジェリズムとドキュメンテーション

OSS の API エバンジェリズム/開発者教育とは、基本的に開発者にそもそものソースコードを渡すことで行われる。閉鎖的なソースモデルでの API エバンジェリズムは、基本的には信用に依存するしかないのだが、 OSS の API エバンジェリズムでは、開発者自身が腹を決められる。

NatBro と Ckindel は、ここで開発者の能力に応じた分裂があると指摘している。「熱意の高い開発者」は OSS 式のエバンジェリズムで安心するが、初心者/中間レベルの開発者――開発者コミュニティの多勢――は信用モデルと組織としての評判のほうを好む (例:「マイクロソフトは X という API はこうだと言っているよ」等)

{ ほとんどの開発者が「信用」モデルを好むかどうかは、非常におもしろい問題だ。

現場で 20 年やってきた経験からいうと、これはまちがっている。一般的に、開発者はコードのほうを好む。技術に明るくない上司どもが「信用」なんぞを好むほどに無邪気である場合であっても。マイクロソフトは、どうやら自分たちの「組織としての評判」が大したものだと信じたいようだ――それってないものねだりでは?

一方でかれらが正しいのかも知れない。オープンソース・コミュニティのぼくたちは、この可能性を無視しきるわけにはいかない。たぶんこれに対しては、高品質のドキュメンテーションを開発することで対応できると思う。こうすれば有名な著者(あるいはオライリーやアジソン・ウェスレイのような評価の高い出版社)の「信用」が、API を決めている組織に対する「信用」の代わりになれるだろう。 }

リリース頻度

強力にコンポーネント化された OSS プロジェクトは、開発者がコードを書き終えたらすぐにサブコンポーネントをリリースできる。結果として、 OSS プロジェクトは高速かつひんぱんに改訂される




オープンソースの弱点

OSS プロジェクトの弱点は、以下の3つの大きな分野におさまる:

管理コスト

OSS にとって最大の障害は、プロジェクトが技術革新の度合いと規模に応じて幾何級数敵に増大する管理コストの問題だ。これはつまり、 OSS プロジェクトが技術革新できる速度には限界があるということを意味している。

OSS プロジェクトを始めるのはむずかしい

エリック・レイモンド曰く:

バザール形式で最初からコードを書くのが無理だというのは、まあはっきりしているだろう。バザール形式でテストしたりデバッグしたり改善したりはできるけれど、プロジェクトを最初からバザール式で始めるのはすごくむずかしいだろう。リーヌスはそんなことはしなかったし、ぼくもしなかった。あなたが生み出そうとしてる開発者コミュニティは、いじるために何か動いてテストできるものを必要としているんだ。

レイモンドの議論は、はっきりした前例/目的がないとき(または多すぎるとき)にプロジェクトを開始・維持するむずかしさにも拡張できる。

バザールの信用

インターネット上には明らかに、 OSS コミュニティの数よりはるかに多いソースコードの断片がある。こういう「死んだソースコード」と躍動するバザールとの差はなんなのだろう。

ある論考 (http://www.mibsoftware.com/bazdev/0003.htm) は、次のような「信用」の判断基準を提示している:

「(前略)参加者の最低数でこれを考えようとするのはまちがっている。Fetchmail や Linux はいまでこそ多数のベータテスタがいるけれど、最初はほとんどいなかったはずだ。

いずれのプロジェクトも持っていたのは、少数の熱狂的支持者と、納得のいく約束だった。この約束は一部は技術的なもので(このコードはちょっと努力すればすばらしいものになるよ)、一部は社会的だった(おれたちの仲間になったら、おれたちなみに楽しい思いができるぜ)。だからバザールが発達するのに必要なものは、いずれ立派なバザールができあがるという信用なんだ!

バザールが信用できるために存在すべき、鍵となる評価基準には以下のようなものがあると提案したい:

飽和点に達した後の開発

この問題を 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 チームが受け入れるにはとてつもなくむずかしいものとなるだろう。なぜならそれは、かれらの前例とスキルセットの価値を同時に低下させてしまうものとなるからだ。

{ この予想は、オープンソース開発がデザインの前例に致命的に依存していて、したがって後ろ向きになるのは避けられないという、作者の
既出の発言 と表裏一体の関係にある。いささか近視眼的だね――どうやらPythonBeowulfSqueak (何百もの技術革新的なプロジェクトから敢えて三つ例をあげただけだけど)のようなものは、この人のレーダーにはひっかかってこないらしい。

マイクロソフトがこれを信じ込み続けてくれることを祈るばかりだ。だってそうすれば連中の対応も見当はずれになるから。これはかれらが(たとえば) Linux カーネルの SMP 化のような技術革新をどう解釈してくれるかにかかってくる。

おもしろいことに、著者はこの点でさっきと言ってることがちがう

ある元マイクロソフト社員の話だと、「捨てることをあらかじめ予定」というのは、実はマイクロソフトでの明確な方針にかなり近いんだそうだ。ただしそれは、問題をなおすための方針ではなくて、マーケティングを有効にするためのもの。かれが参加していたプロジェクトは、MS Exchange にWebベースのフロントエンドをつけるプロジェクトだった。最初の素案(14ヶ月かかってつくったもの)は既存のフリーWebメール(Yahoo、Hotmailなど)にくらべてまったく劣ったものだった。これに対する公式回答は「(肩をすくめる)ま、いっか。とりあえずは市場シェアだけ稼いで、その後三、四年かけて技術的な問題はなおしていけばいいよ」

かれはさらにこうつけ加えている。インターネットエクスプローラ 5 は、あるベータリリースの直前に、なおすつもりでいたバグが 300K 個 (誤植じゃないよ、300K個だよ) ほど残っていた。で、このデバッグの相当部分は、単に予定の(新)機能をどんどん取り除いて、それを将来の(一、二年先の)リリースにまわすことで達成されたそうな。 }

プロセスの問題

OSS のデザイン/フィードバック手法に内在する弱点は以下のとおりである。

改訂サイクルのコスト

OSS プロセスの鍵の一つが、商業ソフトよりもずっと多い改訂サイクルを持つということだった( Linux はカーネルの改訂版が一日に一回以上も出たりするので有名だった!)しかしながら商業顧客にきいてみると、改訂版は多いより少ない ほうがいいと言われる。

{ これってマイクロソフトの改訂版があんなに高価じゃなければ、答えもちがってきたんじゃないかな?

だからこそ商業 Linux パッケージがあるんだ――急速な開発プロセスと、そんなものをいちいち追っかけたくない顧客とを仲介するために。カーネルは一日一回ずつ改訂するかもしれないけれど、Red Hat は半年に一度しか改訂しない。 }

「非専門家」からのフィードバック

Linux OS はエンドユーザ向けに開発されているのではなく、むしろほかのハッカー向けに開発されている。同様に Apache web サーバも、実際問題としてはきわめて大規模で技術水準も高いサイト運営者向けであり、部局内のイントラネット・サーバ用にはできていない。

ここで重要となってくるのは、 OSS は明確なマーケティングや顧客からのフィードバック部分を持っていないので、要望リスト――ひいては将来的な機能の開発――はもっとも技術水準の高いユーザにばかり支配されることになってしまうという点である。

MSFT の開発グループが何度となく思い知らされたことは、使い勝手やUIは製品においてゼロからつくりあげなくてはならず、あとから貼りつけるわけにはいかないということだった。

{ こいつは一言申し上げなくてはなりますまい――というのも理論的にはこれは非常に正しいのだけれど、マイクロソフトが実際にやっていることに照らすとおぞましいほどにまちがっているからだ。このまちがいぶりは、ここでにおわされている UI を強調するという(マイクロソフトの)戦略において、つけこめる弱点を意味している。

「ゼロからはじめて」使いやすさを組み込む方法には二種類ある。一つはマイクロソフト方式で、UI に定義づけられてそれですべて決まってしまうような一枚岩のアプリケーションを設計することだ。これは「ウィンドウズ病ソフト」――融通のきかない、ぎくしゃくしたバグまみれの化け物ソフトで、外見ばかりがよくて中身空っぽ、という代物を創り出してしまうことが多い。

このようにつくられたプログラムは、一見すると使いやすそうに見えるけれど、でも長期的にみると派手に時間とエネルギーをとられてしまう結果になる。これが唯一続けられるのは、じゅうたん爆撃式のマーケティングのおかげであり、その主な目的はユーザを幻惑して、(イ)バグは機能である、または(ロ)バグはみんなバカなユーザが悪い、または(ハ)バグはすべてユーザが次のアップグレードまで我慢すればなくなる、と信じ込ませることだ。このアプローチは根本的に破綻している。

もう一つの方法は Unix/インターネット/Web のやりかたで、エンジン(実際の作業を担当)と UI(見せ方とコントロールを担当)を分けることだ。このアプローチでは、エンジンと UI がきちんと定義したプロトコルにしたがってやりとりすることが必要となる。この好例がブラウザ/サーバのペアだ――エンジンはエンジンに特化して、UI は UI に特化している。

この二番目のアプローチでは、全体としての複雑さはおさえられて、信頼性は高まる。さらにインターフェースを進化、改善、カスタマイズするのも容易だ。これはまさに、それがエンジンとそんなに緊密にカップリングされていないためだ。観客に応じて複数のインターフェースを作っておくことさえできる。

最後に、このアーキテクチャは企業向けアプリケーションに自然につながってゆく――これはサーバから離れたところからでも、リモートで使ったり管理したりできるアプリケーションだ。このやりかたはうまくいく――そしてこれは、オープンソースがマイクロソフトに対抗する自然なやり口だ。

ここで鍵となるポイントは、もしマイクロソフトが UI でオープンソースと張り合う気なら、やらせておけ、ということだ。だってぼくたちは自分たちのやり方のままで、この戦いでも勝てるんだもの。連中は、いままで以上に入念なウィンドウズのモノリスをつくりあげて、それはあなたをアプリケーション・サーバのコンソールに溶接してしまうだろう。ぼくたちは、インターネットと web を活かしたクリーンな分散アプリケーションを書いて、UI は出し入れ自由なユーザの選択肢にして、発展できるようにしておけばいい。

でもここで注意すべきなのは、ぼくたちの勝利は、UI とエンジンが通信するためのきちんと定義されたプロトコル(たとえば HTTP )の存在に依存するということだ。だからこそ、このメモのあとのほうに出てくる「プロトコルの脱共有化」というのはきわめて陰険なのだ。これには十分に防御を固める必要がある。 }

ここで見ておくべきおもしろいトレンドは、商業 OSS プロバイダ(たとえば Linux 界では RedHat、Apache 界では C2Net)がこのフィードバックサイクルにどのように影響してくるかということである。

組織としての信用

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に劣位出資をしたんだよ。 }




オープンソースのビジネスモデル

過去 2 年で、 OSS を売る企業が出てきたり、もっと重要なことに、フルタイムの開発者をやとってコードベースの改良をしたりするような企業がでてきたことで、 OSS はまたもや大きな転機を迎えている。こういう給料を正当化するようなビジネスモデルとはなにか?

多くの場合、これらの質問への答えは「なぜおれは自分のプロトコルやアプリや APIを標準化団体に提出すべきなのか」という質問への答えと似ている。

二次的サービス

OSS ウェアのベンダーは、顧客に対する販売、サポート、インテグレーションを提供する。これは実質的に、その OSS ウェアのベンダーをパッケージ商品製造業者からサービスプロバイダに変身させることになる。

「最初は赤字」――市場参入

「最初は赤字」式の OSS ビジネスモデルは、二つの目的で使用される。

OSS の新興企業――とくに OS の企業――は、 OSS 製品の開発への出資を、マイクロソフトに対する「最初は赤字」戦略と見なしている。

Linux 販売業者、たとえば RedHat、Caldera などは、成果をすべて OSS コミュニティにリリースするようなフルタイムの開発者を公然と喜んでやとう。こういう活動に双方が出資することで、Red Hat と Caldera は実質的に共謀していることになる。おたがいに直接競合もするけれど、それより Linux 市場をのばすことで短期的な収入がもっと増えると考えているわけである。

間接的な例になるが、オライリー社もラリー・ウォールを雇っている。かれは PERL のリーダーであり、フルタイム開発者でもある。PERL 解説書のトップ出版社は、もちろんオライリーである。

短期的には、特にその OSS プロジェクトが成長曲線のいちばんの成長期にいるときには、こうした投資はプラスの ROI(投資収益率)をもたらす。長期的には、ROI に基づく動機づけのために、こうした開発者も OSS をリリースするよりは独占拡張をつくる方向に動くかもしれない。

下流サプライヤの共有化

これは「最初は赤字」ビジネスモデルと非常に密接に関わる。しかしながら市場を急成長させてそこそこのサービス収益をあげるのではなく、こちらのビジネスは下流のサプライヤを共有化することで、自分たちのバリューチェーンの収益を上げようとする。

このいちばんいい例はいまのところ、 Whistle Communications や Cobalt Micro のような thin サーバのベンダーで、かれらはそれぞれ SAMBA と Linux の開発者に積極的に出資している。

Whistle も Cobalt も、ハードウェアの出荷台数で収入を得ている。結果として、 OSS に出資すれば、かれらは OS ベンダーに「税金」を払わなくてはならないいまの PC 市場を避けることができる( NT Server の小売り価格は $800 だが、Cobalt のねらう MSRP は $1,000程度)。

最初期の Apache 開発者たちは、手持ち資金の少ない ISP や ICP によって雇われていた。

もう一つもっと最近の例としては IBM の Apache への協力がある。HTTP サーバを共有物と宣言することで、IBM は Apache とバンドルするもっとややこしいアプリケーションから収益を集中してあげようと考えている(そして同時に、 Apache の膨大な市場シェアにアクセスしようとしている)。

先手必勝――いまつくって、儲けは後

OSS の指数関数的な性質――成長する OSS プロジェクトが同じ空間のほかのプロジェクトを飲み込む――は、先取り型ビジネスモデルを示唆している。つまりいま OSS に直接投資すれば、後から出てくる競合プロジェクトを先取り・排除できるということだ――特にそのプロジェクトが API エバンジェリズムを必要とするなら。これは OSS における「先手必勝」メリットをつかむというのと同じことである。

さらに OSS プロセスにおける開発者のスケール、リリースのサイクル、信頼性面での優位性は、巨大な社内開発スタッフを雇えないことが多い小さな新興企業にとっては天の助けである

この空間でのスタートアップの例としては、 SendMail.com (sendmail MTA の商業サポート版を作っている)や C2Net (商用版暗号化機能つき Apache をつくっている)があげられる。

ここで注意すべきなのは、うまくいった新興企業が OSS プロジェクトを 自分で創始する 例は一つもないということだ。いずれの例でも、 OSS プロジェクトそのものは新興企業が形成される 以前から存在していた。

Sun Microsystems は最近、JINI プロジェクトを OSS プロジェクトのかたちで提供すると発表。これは先取りドクトリンの応用として見ることができるかもしれない。




Linux

以下、数節をつかって、もっとも有力な OSS プロジェクトをいくつか分析する。とりあげるのは Linux 、 Apache、そしていまは Netscape の OSS ブラウザである。

Linux OS については、もっと詳細な評価を第二のメモ「Linux OS 競合分析」で行う。ここでは Linux についてわたしが見いだした内容の、トップレベルのまとめを提供する。

Linux とはなにか

Linux (リーナックスと発音)はインターネット上のオープンソース OS としてトップのシェアを誇る。 Linux は UNIX OS で学ばれてきた 25 年強にわたる教訓を強力に活かして生まれてきた。

最大の特徴:

Linux は本物の、信頼性の高い OSおよび開発プロセスである

オープンソースソフト( OSS )製品の多くと同様に、 Linux の本当の鍵はできあがった製品そのものではなく、それをとりまくプロセスのほうである。このプロセスが信頼性を高め、さらには顧客の Linux 投資に対して、将来的にも安心だという印象をつくりだしている。

{ お見事、ぼくでもこんなに上手にまとめられないよ :-). }

Linux はサーバ市場における短期・中期的な脅威となる

マイクロソフトが Linux から受ける主な脅威は、NT サーバに対してのものである。

Linux の NT サーバ(およびその他の UNIX )に対する将来的な強みは、以下の主要な要因によって加速されている。

Linux はデスクトップ市場での脅威にはならないであろう

Linux は中長期的にもデスクトップ市場での脅威にはならないであろう。理由はいくつかある。

Linux を打倒するには

OSS プロジェクト一般に見られる弱点(たとえば統合コストやアーキテクチャのコストなど)を攻撃するのに加えて、Linux 特有の攻撃手法としては以下のようなものがある:

NT vs. Sun における製品の問題は、すべて Linux にも適用できる。

Linux の基盤は、現在は共有ネットワークとサーバインフラである。拡張機能(たとえばファイルシステムにおける Storage+、ネットワークでの DAV/POD)を現在の共有サービスに織り込むことで、われわれはハードルをあげてこの商売のルールを変えてしまえる。

{ ここでも、 Linux はどうすれば勝てるか のコメントのときと同じように、マイクロソフト戦略の実際の概要が企業用語の霞のなかから立ち上がってくるのが見えてくる。そしてそれは、相当に薄汚い代物だよ。醜悪すぎて、ぼくがこれを書いているのがハロウィーンの真夜中過ぎだというのがあまりにドンピシャすぎるくらいだ。

この著者がいわんとしているのは、つまり「共有ネットワークとサーバ」インフラ(これは TCP/IP, SMTP, HTTP, POP3, IMAP, NFS などのオープン規格を使っている)を堕落させて、同じ名前を持っているかもしれないけれど、マイクロソフトによる顧客と市場操作の道具へと凋落してしまったようなプロトコルを使わせるようにしよう、ということだ(著者がマイクロソフト社員たちに対して「ハードルをあげて商売のルールを変えてしまえ」とけしかけているのは、本当はそういうことなんだ)。

ここで言う「拡張機能を織り込む」ってのは、独自拡張をつっこむ(あるいはぜんぜんちがったプロトコルにしてしまう)というのをきれいに言い換えただけだ。そしてマーケティングでそれを「標準」と称して市場にあふれかえらせる。実際はクローズドで、ドキュメント化もされていないか、オープンであるかのような幻想を与えるために申し訳程度の仕様記述がされているだけ。その目的は、新プロトコルをだまされやすい企業バイヤーのチェックリストにいれさせると同時に、サードパーティーがマイクロソフトのプログラムの相当物を書くのをほとんど不可能にしてしまうことだ(そして成功した人がいても、買収されてしまう)。 この手口は、「採り入れて拡張」と呼ばれている。マイクロソフトがこいつをやるのは、これまでにも見てきたし、連中はこれが実にうまい。そしてこれが機能すると、マイクロソフトは独占状態にロックインできる。顧客がバカを見る。

(この標準汚染戦略は、マイクロソフトが Java をゆがめて、Java というブランドを破壊しようとしたときの手口と見事に一致している。)

オープンソースの支持者たちは、これに対抗するためには、ずばりどうして顧客がバカをみることになるのか(競争の低下、コスト上昇、信頼性低下、機会喪失)を指摘することだ。オープンソース支持者はまた、その反対案がなぜ優れているか――つまりオープンソースやオープン規格がなぜベンダーの競合を高め、コストを低下させ、信頼性をあげて機会をうむかを説明してもいいだろう。

ここでもまた、マイクロソフトがこのメモですでにうちあけたように、インターネットこそがぼくたちの虎の子だ。だからぼくたちとしてこの「採り入れて拡張」に対抗する最高の防戦手段は、これはマイクロソフトがインターネットをつぶそうとしているんだと指摘することだ。 }




Netscape

ブラウザ業界での信用を更新すべく、 Netscape は最近になって Mozilla ソースコードをリリースして、OSS コミュニティをそのまわりにつくりあげようとしている。

組織とライセンス

Netscape の組織とライセンス提供モデルは、おおざっぱに Linux コミュニティと GPL に基づいているが、少しちがうところもある。まず、 Mozilla と Netscape Communicator という別々のコードベースがあって、 Netscape のエンジニアがそれのシンクロを行っている。

完全な GPL とは異なり、Netscape は Mozilla のコードベースに対しての変更を最終的に拒絶したり、あるいは強制的な変更を加えたりする権利を保留している。そして大きなコンポーネントの「エリア監督」として(いまのところは) Netscape のエンジニアたちが指名されている。

強み

OSS コミュニティ内の反 MSFT 感情を利用する

ほかの OSS プロジェクトにくらべて、 Mozilla はマイクロソフトのエスタブリッシュメントに対するもっとも直接的で短期的な攻撃であるとみなされている。この要因だけでも、開発者たちを Mozilla コードベースに引きつける要因としては大きなものになる。

信頼性の強化

Mozilla ソースコードが提供されたことで、ブラウザ業界における Netscape の信頼性はわずかながら上昇した。 BharatS が http://ie/specs/Mozilla/default.htm:で指摘したように:

「コードをリリースしたことで、かれらは Wordstar が消滅したような形では、この世から消滅したりはしないということを保証したことになる。 Mozilla ブラウザは、今後十年間は十分に生き延びるだろう。そのユーザベースは縮小したとしても。」

大きな悩みを解決

ブラウザは広く使われ、普及している。したがって、「目の前の問題」を解決したいと思っている人や、あるいはバグをなおしたいと思っている人のプールはかなり大きいかも知れない。

弱み

飽和点をすぎた開発

Mozilla はすでに、 IE4/5とほとんど肩をならべる水準に達している。したがって、開発チームを暗黙のうちにまとめるための、追いかけるべき強い前例が存在しない。

Netscape は、自社の最高の開発者数名を、Mozilla コードベース管理の仕事にフルタイムであたらせている。Mozilla が新しい地平を開拓するにあたり、これがどう貢献するか(あるいはまったく貢献しないか)興味深いところである。

ノウアスフィアが小さい

おもしろい弱点として、OSS ブラウザにとって残された「ノウアスフィア」の規模があげられる。

    1. スタンドアローン型のブラウザは、基本的にもう終わっている。
    2. スタンドアローン型のブラウザで、今後開発すべき大きな目立つ領域は、もはや残っていない。言い換えると、Netscape はすでに問題のおもしろい 80% 分を解決してしまっているのだ。Netscape のコードの残り 20% をデバッグ・修正したところで、エゴの満足はほとんど・まったく得られまい。

    3. Netscape の商業的な利害が、ノウアスフィア貢献者の効果を低下させる。

Linux コードベースにおけるリーヌス・トーヴァルズのマネジメントは、最高の Linux をつくるという目的に向けられていると言えるかもしれない。ところがそれに対して Netscape は、Netscape の商業的・ビジネス上の利害に基づいて、コードマネジメントに関わる決断を行う権利をはっきりと留保している。開発者のコードは、重要な製品をつくるためにではなく、 Netscape の株価に奉仕させられているわけだ。

統合化のコスト

おそらくは Mozilla 的試みにおける唯一最大のつまずき石は、ユーザはブラウザの機能が高度に統合されていることを期待するということだろう。すでに述べたように、統合開発・試験は並列処理不可能な活動であり、したがってこれは、OSS プロセスがむしろ有害に作用する分野である。

ときに、IE5+ における新たな作業のほとんどは、単に新しいコンポーネントをブラウザそのものに統合することだけでなく、むしろそれを OS 内に統合する作業に費やされている。これと対抗するのはとてつもない苦労を強いられるはずだ。

将来予想

以上から論じられるのは、いまのところ非常に成功している Apache や Linux とはことなり、 Netscape の Mozilla の試みは以下のようになるということである。

ソースコードがリリースされたのがほんのしばらく前(1998 年 4 月)だったことを考えると、Mozilla に対する関心はすでに薄れつつある気配が見られる。まったく科学的とは言い難いながら、そうした証拠を 4 月から 6 月にかけての Mozilla メーリングリストのボリュームの低下などに見ることができよう。

Mozilla メーリングリスト

1998 年 4 月

1998 年 6 月

減少率(%)

追加機能の要望

1073

450

58%

UI 開発

285

76

73%

一般的な議論

1862

687

63%

なお、Mozilla メーリングリストの社内ミラーは、http://egg.Microsoft.com/wilma/lists にある。

{ いっひっひ、この「egg」っていうマシン、実は Linux マシンなんだよ。 }



Apache

歴史

以下は http://www.apache.org/ABOUT_APACHE.htmlの要約である:

1995 年の 2 月、Web 上でいちばん普及していたサーバソフトは、イリノイ大アーバナ・シャンペン校の NCSA で開発されたパブリックドメインの HTTP デーモンだった。しかしながら、この httpd の開発は 1994 年半ば以降は足踏み状態となり、多くのウェブマスターたちが独自の拡張やバグ修正を開発していたため、共通の配布パッケージが必要となっていた。こうしたウェブマスターの小集団が、私的な電子メールを通じて連絡をとりあい、自分たちの加えた変更を(「パッチ」として)協調させるために集まった。1995 年 2 月末頃には 8 人の中核貢献者たちが、最初の Apache グループの基礎を形成。1995 年 4 月、Apache 0.6.2 がリリースされた。

1995 年の 5-6 月にかけて、新しいサーバ・アーキテクチャ(コードネームは「Shambhala」)が開発された。これはモジュラー構造となり、拡張性を高めるような API、プールベースのメモリ割り当て、アダプティブ・プリフォーキング・プロセスモデルを採用。グループは 7 月にこの新しいサーバベースに切り替えて、 0.7.x からの機能を移植し、これが 8 月には Apache 0.8.8 (およびその仲間)となった。

グループが組織されてから一年もたたないうちに、Apache サーバは NCSA の httpd を追い越して、インターネット上でトップのサーバとなった。

組織

Apache 開発チームは、中核メンバーおよそ 19 名と、なんらかの形でバグ報告やパッチを提供した全世界の何百人もの web サイト管理者で構成される。Apache のバグデータは以下で見られる:http://bugs.apache.org/index

Apache チームの採用しているコード管理と紛争解決手続きはhttp://www.apache.org:に見られる。

リーダーシップ:

貢献者の中核グループ(非公式に「コア」と呼ばれる)がプロジェクト創始者たちによって構成されており、ときどきコアメンバーがめざましい貢献者を推挙してほかのメンバーが賛成すれば、その人物もコアメンバーに迎えられる。

紛争解決:

コード改変はメーリングリストで提案され、通常はアクティブ・メンバーによる投票で決まる。リリースサイクル中にコード変更をコミットするには、+1 (賛成票)が3つと -1 (反対票)がゼロなくてはならない。

強み

市場シェア!

Apache は今日のインターネットにおいて、Web サイトの圧倒的なトップシェアを誇る。トップシェアを持つが故に、かれらはこの市場の方向性について、きわめて強力な支配を及ぼしている。

具体的には、Web サーバ界における Apache の市場シェアは、以下のような競争上のハードルを創り出している。

サードパーティーのサポート

Apache 用のツールやモジュール、プラグインの数は、ますます勢いをつけて増え続けている。

弱み

性能

短期的には、 IIS は SPECweb で文句なしに Apache に勝てる。さらに将来には、IIS はカーネルに組み込まれて NT との深い統合を活用できるようになり、この優位性はさらに拡大すると予想される。

Apache のほうはといえば、あらゆる OS 環境用のポータブルなコードをつくらなくてはならないという要請が重荷となってくる。

HTTP プロトコルの複雑さとアプリケーションサービス

Apache が足場を固めてのびていけた理由の一つは、 HTTP プロトコルがきわめて単純だからである。つつましやかな web サーバ上にレイヤーされる機能がますます増えるにつれて(たとえばマルチサーバ・トランザクションのサポートや POD など) Apache チームがどうやってそれに追いつこうとするのか、みものである。

たとえば ASP サポートは、企業イントラネットにおける IIS 導入の要である。

IBM と Apache

最近、 IBM が WebSphere アプリケーションサーバにおける Apache コードベースのサポートを表明した。マスコミは大騒ぎしたものの、その具体的な結果はまだはっきりしていない:




その他 OSS プロジェクト

その他の OSS プロジェクトとしては以下のようなものが挙げられる:




マイクロソフトとしての対応

全般として、マイクロソフトとしての OSS 現象への対抗を考えるには、もっと検討と議論を行う必要がある。本文書の目的は OSS のプロセスを教育分析することであり、したがってわたしが以下の章で挙げる対策のオプションや検討課題は、非常に場当たり的なものでしかない。

製品の弱点

マイクロソフトが近い将来で OSS プロジェクトに「押され気味」になりそうなところはどこだろうか。

サーバ vs クライアント

サーバのほうがクライアントより OSS 製品に押されやすい。その理由としては:

OSS のメリットを利用する――開発者の意識や方向性の面

OSS プロセスが、インターネット中の何千人もの集合的なIQを集めて、それを有効に利用できるという能力は、まさに驚異的なものである。もっと重要な点は、 OSS のエバンジェリズムは、われわれのエバンジェリズムの試みよりもずっと高速に、インターネットの規模拡大と対応する形でスケーリングしているということだ。

{ つまり、マイクロソフトは頭脳の面でも、マーケティングの面でも、オープンソースに遅れをとっている――そして自分でもそれがわかっている! }

マイクロソフトはいかにして、 OSS 製品に執拗に向けられる開発者の意識や方向性をつかまえることができるだろうか。

すぐに考えられるのは以下のようなアイデアだ:

OSS のメリットを利用する――マイクロソフトの内部プロセス

マイクロソフトはこうした OSS 事例からなにを学べるだろうか。もっと具体的には、どうすれば社内的に OSS の開発環境を再現できるだろうか。この論のさまざまな査読者は一様に、われわれもマイクロソフトを理想化された OSS コミュニティとして扱うべきなのに、さまざまな理由からそうしていないという点を指摘している。それらの理由とは:

「マイクロソフトの OS で仕事をしている開発者は、エクセルについてこうしたほうがいいと思っていても、どうしようもない。逆にエクセル開発者は、OS 側で気になる点をどうにもできない――ビルドの仕方やインストール方法をつきとめるだけで何ヶ月もかかるし、どのみちまともにソースコードを入手できる見込みも低い」

「開発者はほかの部分とはまったく独立して自分の部分の作業をしなくてはならないので、コンポーネントの内部的な抽象化はよくドキュメント化されていて、公開・公表されていなくてはならないし、またコンポーネント自体もずっと堅牢でなくてはならない。コンポーネントは自分がどういう形でコールされるかまったく見当もつかないからだ。 Linux 開発チームが、多数の開発者を参加させつつも、統合の問題があまり生じていないのは、こうした堅牢さがあらゆるレベルで貫徹しているからだ。こいつは長期的に見て、全体としての安定性にとってはすばらしいことだし、実際にその成果は出ている。」

ここで悩ましいのはもちろん、こうしたメリットを得つつも、 OSS プロセスのコストを発生させないためにはどうしたらいいかということだ。こうしたコストこそまさに、そうした障壁がそもそも設けられた理由でもある:

OSS 的なメリットを提供する――サービスインフラ

プラットホームと開発コミュニティをサポートするには、多大なサービスインフラが必要となるが、これは OSS には提供できない。たとえば PDC、MSDN、ADCU、ISV、IHV などである。

OSS コミュニティで「MSDN」に対応するものといえば、品質もピンキリの API 文書を載せた Web サイトのゆるい連合軍である。MS は開発者へのエバンジェリズムを実践するにあたり、web を本気で使い倒すことでチャンスを得られるだろう。

正面きって OSS を攻撃するには

一般的に、マイクロソフトは OSS プロジェクトの中核部分の弱点をつくことで勝つことができる。

プロトコルやアプリケーションの脱共有化

OSS プロジェクトが多くのサーバ・アプリケーションに食い込めたのは、高度に共有化された単純なプロトコルが広く使われていたからである。これらのプロトコルを拡張して新しいプロトコルを開発すれば、 OSS プロジェクトの市場参入を防止することができる。

David Stutz が非常にいいことを言っている。マイクロソフト並のデスクトップ統合水準と競合するために、 OSS プロジェクトにおいては「共有プロトコルは実際にはその統合の手段となっている」。こうした OSS プロジェクトの統合にあたってのアーキテクチャ面でのモデルを急速につくりあげている、IETF のさまざまなワーキンググループでは、大量の IQ が費やされているのである。

{ いいかえれば、「プロトコルやアプリケーションを脱共有化してオープンソース・ソフトをくい止めるためには、オープンプロトコルを封じ込めて、 IETF を抹殺しなくてはならない、というわけだ。

ある元マイクロソフト社員の追加コメント:MS が W3C のワーキンググループに人を送るのは、RFC を改善するというのは目的の半分にすぎない。残り半分の目的は、これから決まる標準を先にのぞいて、それをあらかじめ「拡張」しておいて、そしてその「公式」の標準がかれらの「拡張」と同時期に決まるようにして、「公式標準はもう時代遅れ」と主張できるようにするためなんだそうだ。

ここでもまた、オープンソース支持者としていちばんいい反論というのは、顧客に対していろんなものが「脱共有化」されたら得するのはベンダーで、顧客側は損をするんだと指摘することだ。 }

マイクロソフトの活動のなかで共有プロトコルを拡張するようなものの例としては以下が挙げられる:

統合化を魅力的なものにせよ――特にサーバで

専用サーバの勃興は、我が社の収入に直接影響を与える、きわめて強力で深刻な長期的脅威である。この脅威に対処するポイントは、サーバ・プラットホーム上で価値を持つような統合シナリオをつくりだすことである。David Stutz は以下のように指摘する:

ここでの話は結局のところ、共有サーバビジネスに勝つのは、最高のネットワーク統合技術とプロセスを持ったものだということだ。埋め込み型システムやモバイル接続、支配的なネットワーク・プロトコルが融合してきているため、サーバの数(特に「専用サーバ」??)は爆発的に増大する。汎用共有クライアントは参入するとおいしい商売になるだろう――これは専用共有サーバビジネスと比べて小さなものだろうか?

組織的な信用




興味深いリンク

謝辞

この報告書と Linux 分析について、以下の多くの人々がデータや下読み、思慮深いメールや分析を提供してくれた:

Nat Brown

Jim Allchin

Charlie Kindel

Ben Slivka

Josh Cohen

George Spix

David Stutz

Stephanie Ferguson

Jackie Erickson

Michael Nelson

Dwight Krossa

David D'Souza

David Treadwell

David Gunter

Oshoma Momoh

Alex Hopman

Jeffrey Robertson

Sankar Koundinya

Alex Sutton

Bernard Aboba

 

改訂履歴

Date

Revision

Comments

8/03/98

0.95

 

8/10/98

0.97

改訂履歴表を追加

JoshCo からのコメント織りこみ

8/11/98

1.00

修正をさらに加え、PaulMa の検討用にうちだし




ハロウィーン文書トップ
YAMAGATA Hiroo (hiyori13@mailhost.net)