OSSの昨日今日明日
1998年3月31日、米国Netscape社は同社の主力製品であるコミュニケーターV5.0のソースコードを公開した。商用ソフトウェアのソースコードを公開するという前代未聞の行動は後にオープンソースとして広く知られることになるが、その当時はごく一部のプログラマの注目を集めるに過ぎなかった。もちろん、日本の日刊紙（日経をはじめとするマスコミ）は、その重要性についてまったく理解も注目もしていなかった。
webのあちら側には当時の記録、日本語でのレポートが残っている。最近、その記録を発見したので、引用しながら8年後の今について考えてみよう。8年前のオープンソースを理解することが8年後のオープンソースを理解することにつながるかどうかは正直わからない。しかし当時の理解を検証することによって、我々が当時理解していなかった事を知ることができ、それが今後の8年を俯瞰することに役立つかもしれない。
http://web.archive.org/web/20000823214952/www.best.com/~yoshioka/d/98/sd199808.html
モジラの解剖
「これはベータ・リリースでも、またアルファ・リリースでさえもなく、エンド・ユーザー向け製品では有り得ないような未完成の機能や多数のバグが含まれている」http://www.mozilla.org/download-mozilla.htmlより
商用ソフトウェアを公開するという蛮勇は当時の常識をはるかに超えていた。（現在では想像もつかないクレージーな行動であった）
従来からフリーソフトという言葉はありましたがモジラのグループはむしろオープンソースという言葉を使っています．フリーソフトという時のフリーの意味の曖昧さが嫌われているからです．
http://www.catb.org/~esr/open-source.html
フリーというのは無料(no money charged)という意味なのか，それとも誰でも自由に変更してもよい（free to be modified by anyone）という意味なのか，そういう曖昧さがあります．さらにはフリーソフトというのが企業人にとって受け入れられにくいと感じているようです．そこでソースコードが公開されているという意味でオープンソースという言葉を発明したわけです．
Eric RaymondはNetscapeのソースコードの公開に外部コンサルタントとして影響を与えたが、彼やVA LinuxのLarry AugustinらはMozillaのソースコードのライセンスを従来からあるフリーソフトウェアという名前ではなくオープンソースという言葉を与えた。後にRichard Stallmanはオープンソース陣営がソフトウェアの自由の側面を軽視しすぎていると厳しく批判することになる。
今風に言えばオープンソースソフトウェアというのはフリーソフトウェア2.0なのであろう。Richar Stallman ではなくて、Linus Torvaldsだし、GNUではなくLinuxだし、ソフトウェアの自由ではなく、利便性。
このような開発プロセスは様々なちょっと違ったバージョンを多数発生させるのではないかという危惧がありますが，mozilla.orgが交通整理をする事によってそのような事態が発生する事を防止しています．実際，エリック・レイモンドのエッセイはオープンソースによる開発プロセスがどのように成功するのかを記していますが，mozilla.orgもそれを踏襲しようとしています．
ソースコードが公開されて自由に変更できるならば、理屈の上では多数のバージョンが発生するのではと考えられていたが実際はそのような事は起こらなかった。
これは注目に値する。
独自のバージョンを開発することを（オリジナル版からの）フォークすると言う。当初予想されたよりフォークが少なかったのはなぜか？
オープンソースの場合その価値は参加者の過多によって評価できる。多くの参加者を得たオープンソースは、より多くのフィードバックを得て、より多くのバグ修正や機能拡張をする可能性が大きい。仮に独自機能を追加してフォークした場合、その瞬間の参加者はゼロであり、参加者からのフィードバックを得る可能性が極めて少ない。その結果、進化の速度は多くの参加者を持つオープンソースより低く、ソフトウェアの魅力を高めるコストが非常に高くなる。そしてソフトウェアの魅力が乏しければより多くの利用者を得る事ができなくなり進化のスピードが遅くなる。
オープンソースソフトウェアの作者は既存のソフトウェアの進化発展系でいくのか、まったくの独自路線で行くのかの選択を迫られる。独自路線で行く場合は上記のコストを負担することを迫られる。一方既存のソフトウェアの発展系の場合、そのようなことはない。
多くのプログラマは、独自路線を行くのではなく（すなわちフォークするのではなく）、既存のソフトウェアの改良という路線を踏襲することを選択した。独自路線に行くことに強いインセンティブがない。それよりも既存のソフトウェアに機能を追加した方が、いろいろな面でメリットがあった。自分のソフトウェアはコミュニティによってメンテナンスされるので、持続的に発展する。結果として定番のオープンソースはますます機能が追加され価値が高まった。
バザールモデルは思いのほかうまく機能するのである。
どのようにモジラの発展に貢献するか？
一つはコードを書く．単純な原理原則です．私たちプログラマは何を言ったかで評価される評論家ではないのです．どのようなコードを書いたかで評価されるプログラマです．何かをしたかったらコードを書く．それは新機能の開発でもいいし，バグの修正でもいい．自分のしたい事をする．誰かがあなたに何かをしろと命令するのではないのです．コードを書くということで貢献できなければ，モジラのテストに参加したり，あるいはメーリングリストで議論に参加したりさらには各国語版のモジラを作ったりというような形で貢献できるわけです．
いずれにせよ，自分にできることを自分がしたいからするというのがモジラ流の貢献の方式です．誰かに強制されたり義務があってやるとかそういう話ではないのです．
ここに古典的なボランティアによるオープンソースへの貢献モデルがある。すなわちコードを書いたりテストをしたりすることによる貢献である。その活動を仕事とするという前提はない。ボランティアが好きなことを好きなペースで誰にも命令されずに実行するというモデルである。
98年当時はオープンソース開発を仕事にするという環境はまったくなかったのである。
その意味でオープンソースのプロはいなかったわけだ。
好意ある独裁者
モジラになにを入れて何を入れないかを決定するのはそのオーナーですが，その決定に納得できない人がいるかもしれません．その場合，全く別のモジラを作る事は原理的には可能だし，そのような別版のモジラができる可能性もないとは言えないです．しかし，mozilla.orgがよい仕事をすればそのような事態が発生する可能性は極めて低いです．mozilla.orgはオーナーの事を好意ある独裁者と呼んでいます．「独裁者」というのはオーナーが最終的な判断を下すという意味において．「好意ある」というのは，独裁者は「正しい事」を試みようとする点において．もし独裁者が正しい事をしていなかったとしたら，それは無視をされ最終的にはオーナーではなくなります．このような仕組みが果たしてうまくいくのかという懐疑的な見方もあります．しかし，ネットスケープ社はオープンソースの発展のモデルからそれがうまく行くと確信しているようです．このプロセスが本当にうまく行くかどうかはもう少し時間がたってみないと判らないですが，私自身は非常に面白い試みだと思っています．
これも、非常にうまくいった。コミュニティの優しい独裁者は結果として懸命な采配を振るい続けた。驚異的なことである。
定番のオープンソースは、コミュニティのガバナンスを自立的に維持し、ソースコードを改良しつづけ、ユーザを獲得しつづけた。このような仕組みが破綻もせず機能しつづけているというのは奇跡である。
日本のマスコミはNetscapeのソースコード公開の重要性をまったく理解していなかったと先ほど書いたが下記にasahi.comの記事がある。
http://web.archive.org/web/19990203093735/http://www.asahi.com/tech/silicon/report980401.html
98年当時の梅田望夫のフォーサイトに執筆した記事を引用したかったのだが発見できづ、残念。
尻切れトンボになったが、当時のオープンソースに対する理解はまあ上記のようなもので当たらずとも遠からずである。
