第1章 導入

目次

歴史
独占的なソフトウェアとフリーソフトウェア
意識的な抵抗
無意識な抵抗
「フリー」と「オープンソース」の違い
現状

ほとんどのフリーソフトウェアプロジェクトは失敗します。

しかし、失敗例について聞くことはあまりありません。 みんなの気を引くのは成功したプロジェクトだけだからです。 世の中には途方もない数のフリーソフトウェアプロジェクトが存在する [4] ので、たとえ成功するプロジェクトがその中のごく一部に過ぎなかったとしても、 多くのプロジェクトが成功しているように見えてしまうのです。 また、いつ「プロジェクトが失敗した」と判断するのかがはっきりしないのも 私たちが失敗について聞くことがない理由のひとつでしょう。 「そのプロジェクトが消滅した瞬間」というのを特定することはできません。 参加者が少しずつ他へ移っていき、プロジェクトで作業するのをやめるだけなのです。 「プロジェクトに対して最後に変更が加えられたとき」を知ることはできますが、 実際にその変更を加えた人は「それがプロジェクトに対する最後のコミットとなる」 とは決して思っていなかったことでしょう。 また、どれぐらい動きがなければ「止まってしまった」 とみなすのかについてもはっきりした定義がありません。 目だった動きが半年間なかったとき? ユーザー数の伸びが止まってしまい、結局開発者の数を超えることがなかったとき? 自分の参加しているプロジェクトが結局他のプロジェクトの焼き直しであることに気づいた開発者が、 現在参加しているプロジェクトを捨ててもうひとつのほうに移動したとしましょう。 そして移った先のプロジェクトをどんどん成長させていきました。 この場合、元のプロジェクトは「消滅した」のでしょうか? それとも「あるべき場所に移動しただけ」なのでしょうか?

このように複雑な側面があるので、 いったいどの程度の割合でプロジェクトが失敗しているのかを正確に知るのは不可能です。 しかし、過去10年を超えるオープンソース界での経験や SourceForge.net のデータからの推測、 そしてちょっとググってみた結果はどれも同じような結果となりました。 プロジェクトが失敗に終わる可能性は非常に高く、 おそらく90–95%くらいと見ていいでしょう。 かろうじて生き残ってはいるが、まともに機能していないプロジェクトも含めると、 この数字はさらに上がるでしょう。ここでいう「まともに機能していない」とは、 とりあえず動くコートは存在するが満足に使える代物ではなく、 開発が進んでいるようには見えないという状態のことです。

本書の目的は、そのような失敗を避けることです。 本書では、「どうやったらうまくいくか」だけではなく 「どうやったら失敗するか」についても説明します。 それを知ることで、問題が発生したときに軌道修正ができるようになるでしょう。 本書を読み終えられた皆さんは、オープンソース開発において陥りがちな 落とし穴を避けるさまざまなテクニックだけでなく、 成功しているプロジェクトの巨大化や保守をうまく扱うためのテクニックも身に着けていることでしょう。 成功というものはゼロサムゲームではありません。本書では、 いかにして競合プロジェクトを出し抜くかといったことは扱いません。 実際のところ、オープンソースプロジェクトを運営する上では 他の関連するプロジェクトとの協調が重要となります。 長い目で見れば、どのプロジェクトが成功しても フリーソフトウェア界全体の利益になることでしょう。

フリーソフトウェアプロジェクトが失敗に終わる原因は 独占ソフトウェアプロジェクトの場合と同じだと言い切ってしまえれば話は簡単です。 実際のところ、ソフトウェア産業におけるよく知られた問題 (たとえば非現実的な要件、あいまいな仕様、 まずいリソース管理、不十分な設計フェーズなど) はフリーソフトウェアでも起こりうることです。 これらのトピックに関しては既に大量の書物が存在するので、 本書ではそれと重複するような内容は避けるつもりです。 その代わりに、フリーソフトウェアに特有の問題について説明していきます。 フリーソフトウェアプロジェクトが行き詰まる原因としてよくあるのが、 開発者 (あるいはマネージャ) が オープンソースのソフトウェア開発に固有の問題を正しく認識していなかったことです。 彼らはクローズドソースな開発における問題への対応は慣れていたかもしれません。 でもそれだけではだめだったのです。

一番よくある間違いは、オープンソース自体で一儲けしようと非現実的な期待をしてしまうことです。 オープンソースにしたからといって、必ずボランティアの開発者が集結してくれるとは限りません。 また、すでに問題を抱えているプロジェクトをオープンソースにしたところで、 その問題が自然に解決するわけでもありません。 実際のところ、まったく正反対になります。オープンソースプロジェクトをはじめると、 これまで自分たちだけでやっていたときと比べて いろいろ複雑なことを考えなければならなくなります。 また、短期的には 費用もかさむ ことでしょう。 オープンにするということは、見知らぬ他人が読んでもわかりやすくなるようなコードを書くということです。 また開発者用のウェブサイトやメーリングリストを整備したりする必要もありますし、 最低限のドキュメントも書くことになるでしょう。 これらはどれも大変な作業です。 仮にどこかの開発者が「手伝ってあげようか?」と声をかけてきたとしましょう。 まだその人がどれほど協力してくれそうかわからない時点でも、 その人に対してプロジェクトについての説明をしたり質問に答えたりといった作業をすることになります。 Jamie Zawinski は、Mozilla プロジェクトの初期に発生した問題について次のように述べています。

オープンソースはうまく働くものである。しかし、最も大切なことは、 何にでも効くような特効薬ではないということだ。 もし、ここに教訓があるとすれば、死にかけたプロジェクトをつかまえて、 オープンソースという魔法の妖精の粉をふりかけて、 すべてが魔法のようにうまく行くなどということはない、ということだ。 ソフトウェアは難しい。問題はそんなに簡単なものじゃない。

(http://www.jwz.org/gruntle/nomo.html より引用。 日本語訳は http://cruel.org/jwz/nomo.html)

それに関連する間違いとしては、見栄えの調整やパッケージ作成に手を抜くというものがあります。 「そんなのいつでもできるし、もうちょっとプロジェクトが落ち着いてからでいいよ」 というような考えです。 見栄えの調整やパッケージ作成といってもいろいろな内容が含まれますが、 どれも結局はプロジェクトへの参入障壁を下げることにかかわってきます。 新参者がプロジェクトに参加しやすくするには、 ユーザー向けドキュメントや開発者向けドキュメントを整備したり ウェブサイトを開いて初心者向け情報を掲載したり ソフトウェアのコンパイルやインストールをできるだけお手軽に行えるようにしたりといった作業が必要となります。 残念ながら、世の多くのプログラマーは これらの作業を二の次にしてコードだけに注力しがちです。 理由はいくつかあります。 まず、それが彼らにとってあまり重要な作業ではないということです。 それが役に立つのはこれまでプロジェクトにほとんどかかわってこなかった人たちであり、 今までプロジェクトに参加してきた人たちにとってはあまり意味のない作業だと感じられることでしょう。 結局のところ、実際にコードを書いている人にとってはパッケージなんて不要なのです。 彼らはそのインストール方法も管理方法も熟知しています。 だって自分自身でそれを書いているんですから。 次に、見栄えをよくしたり使いやすくパッケージ化したりするのに必要なスキルは、 コードを書くスキルとはまったく異なるものだということです。 人はみな、自分の得意なところに力を入れたがるものです。 苦手なことにちょっと取り組むだけでプロジェクトがよりよいものになるかもしれないとしても。 章 2. さあ始めましょう では、 見栄えをよくしたりパッケージを作成したりする方法について詳しく説明します。 そして、それをプロジェクトの最初期から行うべきである理由についても説明します。

次によくある誤解は「オープンソースではプロジェクト管理にあまり気を使わなくていい」 とか、逆に「社内開発の場合と同じようにプロジェクト管理をしておけば、 オープンソースプロジェクトも問題なく動くだろう」というものです。 オープンソースプロジェクトにおいてはプロジェクト管理があまり表に出ることはありません。 しかし、成功しているプロジェクトの舞台裏では、何らかのプロジェクト管理が行われています。 なぜ?理由を説明するため、ここでちょっとした思考実験をしてみましょう。 オープンソースプロジェクトに参加するプログラマーは、いろいろな意味でバラバラです —よく知られているように、一匹狼的な人種です—彼らはお互いに顔をあわせることもなく、 そのプロジェクトで何を達成したいのかという目標も個々に異なります。 このような集団で、何も管理をしなかったらどんなことになるでしょうか? 奇跡でも起こらない限り、すぐにバラバラになってしまうか明後日の方向に向かってしまうことでしょう。 私たちが思っているほど物事はうまく進みません。 それでは、いったい何を管理すべきなのでしょうか。 管理はおおっぴらにやるものではなく、 非公式に控えめに行うことになるでしょう。 開発者たちを結びつける唯一の理由は、 個別にやるよりも協調したほうがよりよいものができるという共通認識です。 したがって、管理者の目標は、開発者たちがこの考えを信じ続けられるようにすることとなります。 そのためには、標準的なコミュニケーション手段を定めることが大切です。 また、有能な開発者が「周りと違う」というだけで仲間はずれにされることのないように注意が必要です。 要するに、開発者たちにとって「またここに戻ってきたい」と思わせるようにしようということです。 そのための具体的なテクニックについて、本書でこれから説明していきます。

最後に「文化的な導き方の失敗 (failures of cultural navigation)」 と言われる一般的な問題について説明しましょう。 ほんの10年前くらいまで、いや5年前くらいまでは、 フリーソフトウェア文化について語るだなんて時期尚早だといわれていました。 でも今はもう違います。 徐々にフリーソフトウェア文化が目に付くようになってきました。 確かにそれは一枚岩のものではありません— 少なくともごく普通の文化と同様に意見の相違や派閥争いなどが起こりがちです —が、コアとなる部分は一貫しています。 うまくいっているオープンソースプロジェクトの大半は、 このコアとなる考えかたの一部あるいはすべてを持ち備えています。 彼らはよい振る舞いに対しては賞賛し、そうでないものについては非難します。 彼らは誰でもプロジェクトに参加しやすくなるような雰囲気作りを心がけています。 たとえ時にはそれが現在のメンバー間の連携を乱すことになったとしても。 彼らは何が失礼で何がそうでないのかをきちんとわかっています。 その基準は他の文化におけるものとは大きく異なっているかもしれません。 最も重要なのは、長年そのプロジェクトに参加している人たちがこれらの考えを身に着けており、 プロジェクトがどうあるべきかという指針を大雑把につかんでいることです。 うまくいっていないプロジェクトはたいてい、無意識のうちにこの基本から逸脱しています。 また、デフォルトの振る舞いがどうあるべきかという共通認識を持っていないことが多いです。 こうなると、いざ何か問題が起こったときに状態が急速に悪化してしまうようになります。 争いを解決するためのよりどころとなるべき確立された文化的行動様式を参加者が持ち合わせていないからです。

本書は実用的なガイドブックであり、 人類学や歴史学を扱う学術書ではありません。 しかし、こんにちのフリーソフトウェア文化の始まった背景についての 基本的な知識を身に着けておくと、本書での実用的なアドバイスがよりわかりやすくなるでしょう。 背景となる文化を知っておくと、オープンソースの世界をより広く深く歩き回れるようになります。 プロジェクトによっては独特の習慣や方言があったりするでしょうが、 そんな場合も気にせずに仲間入りできるようになるでしょう。 反対に、そのような背景を知らない人は、 プロジェクトを作成したりプロジェクトに参加したりする手続きを見て 非常に難しくてびっくりすることばかりだと感じられるでしょう。 フリーソフトウェアの開発にかかわる人は依然として飛躍的に増えつづけています。 したがって、後者に属する人 (つまり背景を知らない人) がたくさんいるのです。 つまり、主として新しい移民による文化だということです。 この傾向はもうしばらくは続くことでしょう。 もし自分も「背景を知らない人」のひとりだと思われるなら、 ぜひ次のセクションを読んでください。ここでは、 今後本書やインターネット上で登場することになる さまざまな議論の背景について説明しています (一方、すでにオープンソースの世界での活動経験があり、 その歴史についてもよく知っているという方は、 次のセクションは読み飛ばしていただいてけっこうです)。

歴史

ソフトウェアを共有するという考え方は、ソフトウェアが誕生した当初から存在しました。 コンピュータの黎明期には、各メーカーは「ハードウェアの革新によって 競合他社の上を行こう」と考えていました。そのため、 ソフトウェアは商売の材料としてあまり重視されていなかったのです。 いわば「ハードウェアのおまけ」という存在でしかありませんでした。 そのころにコンピュータを使っていたのは科学者や技術者ばかりで、 彼らは、コンピュータに同梱されているソフトウェアを修正したり拡張したりすることができました。 その修正パッチをコンピュータのメーカーに送るだけでなく、 同じマシンを使っている他のユーザーにも送っていたのです。 メーカーはそれに目くじらを立てることはなく、むしろそうすることを奨励していました。 彼らにとっては、どんな理由であれソフトウェアの品質が向上することはありがたかったのです。 そのおかげで自社のマシンがより魅力的なものとなり、 新規顧客が増えることになるでしょうから。

当時の状況と現在のフリーソフトウェア文化との間には多くの共通点もありますが、 決定的な違いがふたつあります。 まず、当時はまだハードウェアが標準化されていませんでした。 ちょうどコンピュータ自体が革新的な進歩を遂げつつある時期だったということもその理由のひとつです。 さまざまなアーキテクチャのコンピュータが存在するということは、 ある機種のために書いたプログラムがその他の機種では一切動かないということです。 したがって、ある機種のために書いたプログラムが世界中で使われるということはありませんでした。 当時のプログラマーは、特定のアーキテクチャ あるいはアーキテクチャファミリーについての専門技術を身につけようとする傾向がありました (一方現在では、特定のアーキテクチャというよりは 特定のプログラミング言語に関するエキスパートになろうとする人が多いように思います。 何かひとつのプログラミング言語をマスターすれば、 ハードウェアが変わったとしてもその知識が応用できるわけです)。 たいていの人は興味の対象があれこれ移り変わることがないので、 何か特定のコンピュータに力を入れ始めるとずっとそれに力を入れるようになりました。 その結果、周囲の人たちも同じコンピュータに興味を持つようになっていたのです。 そのマシンでしか使えないコードや知識が広まれば広まるほど、 そのマシンを作っているメーカーにとってはありがたかったのです。

そして2番目に、当時はインターネットがありませんでした。 当時は現在ほど共有に関する法的規制は厳しくありませんでしたが、 それよりも技術的な問題のほうが大きかったのです。 あるデータをどこかからどこかへ移動しようとすると、 現在に比べて非常に不便でやっかいでした。 研究所や企業によっては小さな構内ネットワークを持っており、 そこでは構成員の間で容易に情報を共有することができました。 しかし情報をどこの誰とでも共有しようと思ったら、 高い敷居を乗り越えないといけませんでした。 多くの場合、その敷居は実際に乗り越えられました。 時にはグループ同士で連絡をとり、ディスクやテープを郵便でやりとりすることもありましたし、 時にはメーカー自身が間に入り、パッチの取引所としての役割を果たすこともありました。 初期のコンピュータ開発者の多くが大学で働いていたことも幸いしました。 大学では、自分の得た知識をみんなに広めることがごく普通に行われていたからです。 しかし、データを共有するにあたって物理的な距離の隔たりが常に障害となりました。 お互いの地理的な距離、そして組織的な距離が遠くなればなるほど、共有がむずかしくなっていたのです。 現在の私たちのように、距離を気にせず情報の共有ができるなんてことはありえなかったのです。

独占的なソフトウェアとフリーソフトウェア

業界が成熟してくるにつれて、相互関係のあるいくつかの変化が同時に発生しました。 まず、さまざまなものがあったハードウェア設計が徐々に淘汰され、 いくつかの勝ち組に絞られていきました。 他より技術的に優れていたもの、他よりマーケティングが上手だったもの、 あるいはその両方を兼ね備えていたものなどが残ることとなったのです。 と同時に (これは全くの偶然というわけではありません)、 いわゆる「高級プログラミング言語」が台頭してきました。 これは、その言語で書いたプログラムを自動的に翻訳 (「コンパイル」) し、さまざまなコンピュータ上で動かすことを可能とするものでした。 ハードウェアメーカーも、当然このような動きを察知していました。 彼らの顧客は今や、特定のコンピュータアーキテクチャに囲い込まれることなく ソフトウェアを開発できるようになったのです。 これらの変化と同時に、各種コンピュータ間のパフォーマンスの差もほとんどなくなってきました。 また効率的でない設計のものは排除されていきました。 ハードウェアのみを収入源としているメーカーは、 将来の見通しがあまり明るく感じられませんでした。 つまり、コンピュータそのものは今や代替可能なものとなってしまい、 一方ソフトウェアこそが他との差別化の手段となったのです。 そんな流れの中では、ソフトウェア自体を販売したり 少なくともソフトウェアをハードウェアの必須部品として販売したり といった考えが出てくるのも当然でした。

ここにきて、各メーカーはソフトウェアのコードに対する著作権を より厳格に適用する必要に迫られることになったのです。 もしユーザーが自分たちでコードを自由に共有し改変し続ければ、 今やハードウェアの「追加機能」として販売されるようになったものを 自前で再実装してしまうかもしれません。 さらに悪いことに、そのコードは競合他社の手に渡ってしまうかも知れません。 皮肉にも、これらの出来事はちょうどインターネットが誕生したのと同じころに発生したのです。 ソフトウェアを共有する際の技術的な障害がようやく解消されたと思ったら、 そのときにはコンピュータ業界の常識が変わっていたというわけです。 少なくともメーカー側の視点で見れば、 ソフトウェアを自由に共有するのは望ましくないこととなっていました。 メーカーは規制に走りました。 自社のマシンを動かしているコードをユーザーに公開しなくなったり、 機密保持契約を結ばせることでコードの共有を不可能にしたりといったことを行いました。

意識的な抵抗

自由にコードを共有できた時代が終わりを告げようとしているころ、 少なくとも1人のプログラマーの心の中ではそれに反対する気持ちが固まりつつありました。 Richard Stallman は、マサチューセッツ工科大学の人工知能 (AI) 研究所に 1970 年代から 80 年代の初期にかけて在籍していました。 ちょうどそのころが、コードの共有が盛んに行われていた黄金時代でした。 AI 研は「ハッカー倫理」 [5] を前面に押し出しており、何かシステムに改良を加えた場合は それを皆で共有するのが当然のことであるとみなされていました。 Stallman は、後に次のように述べています。

わたしたちは自分たちのソフトウェアを「フリーソフトウェア」とは呼んでいませんでした。 なぜなら、そんな用語は存在していなかったからです。しかし、実際はそういうものでした。 他の大学や企業からやって来た人がプログラムを移植したり使ったりしたいときはいつでも、 わたしたちは喜んで許可していました。 もし誰かが珍しくて面白そうなプログラムを使っているのを見たら、 いつでもソースコードを見せてほしいと頼んでもいいので、それを読んだり、 書き換えたり、新しいプログラムを作るためにその一部を取り出しても構いませんでした。

(http://www.gnu.org/gnu/thegnuproject.html より引用。 日本語訳は http://www.gnu.org/gnu/thegnuproject.ja.html)

Stallman の周りにあったエデンの園は、1980 年代に入ってすぐに崩壊してしまいました。 周囲の業界で起こっていたさまざまな変化の影響が、AI 研にも到達したのです。 研究所にいたプログラマーの多くはスタートアップ企業に就職し、 オペレーティングシステムの開発に従事するようになりました。 やっていることは研究所時代と似ていますが、 今や彼らは独占的なライセンスのもとで働くようになったのです。 ちょうど同じころ、AI 研は新しいマシンを導入しました。 そこに搭載されていたのは独占的なオペレーティングシステムでした。

Stallman は、何が起こっているのかを広い範囲で目の当たりにしました。

VAX や 68020 のような当時の先進的なコンピューターは 専用のオペレーティング・システムを備えていましたが、 どれもフリーソフトウェアではありませんでした。つまり、 実行可能なコピーを入手するためだけでも非開示契約を結ぶ必要があったのです。

ということは、つまり最初にコンピューターを使うときには、 周りの人を手助けしないと約束する必要があるということでした。 協力し合うコミュニティーは禁じられてしまうのです。 独占的なソフトウェアの所有者によって作られたルールとは 「もしお前が隣人と分かち合うなら、お前は著作権法に反していることになる。 変更を加えたいのなら、われわれに頼み込んで作ってもらうことだ」 というものなのです。

彼は、この風潮に対して抵抗する決心をしました。 規模がかなり縮小されてしまった AI 研に残り続けるのではなく、 また新興企業でコードを書く仕事を得る (そんなことをしたら彼の作業の成果が一企業に閉じ込められてしまいます) わけでもありませんでした。 彼は研究所を退職し、GNU プロジェクトと Free Software Foundation (FSF) を立ち上げました。GNU [6] の目標は、完全にフリーでオープンなオペレーティングシステムと アプリケーションソフトウェアを作成することです。 ユーザーがコードをハックしたり他人と共有したりすることは決して妨げられません。 簡単に言うと、彼は AI 研にかつてあった (そして今は破壊されてしまった) 空気を新たに作り直そうとしていたのです。 今度は世界中を巻き込む規模で。 そして AI 研の空気が破壊されてしまったのと同じようなことを起こさないように。

新しいオペレーティングシステムの開発のかたわら、Stallman は新しい著作権ライセンスを考案しました。 自分のコードが永久に自由であることを保証するためです。 GNU General Public License (GPL) は、法律における見事な柔術です。 コードの複製や変更には一切の制限を設けません。コピーしたものやその派生物 (改造したものなど) の配布は同じライセンスのもとで行われなければならず、 いかなる制限も付加されてはいけません。 このライセンスは著作権法を利用していますが、 狙っている効果は伝統的な著作権とは正反対のものなのです。 つまり、ソフトウェアの再配布を制限するのではなく、たとえ作者であっても 再配布を制限すること 自体を禁止しているのです。 Stallman にとって、自分のコードを単にパブリックドメインにするよりも そのほうが好都合だったのです。 パブリックドメインにしてしまうと、誰かがそれを独占的なプログラム (あるいは、より規制のゆるい別のライセンスを適用したプログラム) に使用してしまうかもしれません。 そうされたところで元のコードは自由なままで残り続けるわけですが、 でも結局は Stallman の努力した結果が敵陣営 —独占的ソフトウェア—に利益をもたらすことになってしまいます。 GPL は、フリーソフトウェアに対する保護主義の一形式と考えることができます。 というのは、自由でないソフトウェアが GPL のコードを完全に好きなように利用することはできないからです。 GPL とその他のフリーソフトウェアライセンスとの関係については、 章 10. ライセンス、著作権、特許 で詳しく説明します。

数多くのプログラマー (Stallman の思想に賛同する人もいれば、 ただ単に自由にコードを使いたいだけという人もいました) の協力を得て、GNU プロジェクトは OS の基幹部品を置き換えるフリーソフトウェアを次々にリリースしていきました。 当時はすでにコンピュータのハードウェアやソフトウェアが標準化されていたので、 GNU のソフトウェアを自由でないシステム上で使用することもできました。 また実際に多くの人がそのようにしていました。 中でも最も成功したのが GNU テキストエディタ (Emacs) と C コンパイラ (GCC) でした。これらは、その思想に共感する人たちだけでなく 単にソフトウェアとして優れているからという理由で使う人たちも引き込むことになりました。 1990 年ごろには、GNU は自由なオペレーティングシステムをほぼ完成させつつあり、 残っていたのはカーネルだけでした。カーネルとはマシンを実際に立ち上げる部分であり、 メモリやディスク等のシステムリソースの管理を行うものです。

不幸にも、GNU プロジェクトが選択したカーネル設計は 当初予想していたよりも実装が困難なものでした。 カーネルの作成は遅れに遅れ、Free Software Foundation が完全に自由なオペレーティングシステムを公開する日はなかなかやってきませんでした。 そこに登場したのが Linus Torvalds です。 彼はフィンランド人の学生で計算機科学を専攻していました。 彼は世界中の有志と力をあわせ、より保守的な設計のフリーなカーネルを完成させました。 彼はそれを Linux と名づけました。Linux を既存の GNU プログラム群と組み合わせることで、 完全に自由なオペレーティングシステムを得ることができるようになったのです。 ここにきて初めて、独占的ソフトウェアを一切使用せずに コンピュータを立ち上げて作業ができるようになりました。 [7]

この新しいオペレーティングシステム上で動作するソフトウェアの多くは、 GNU プロジェクト以外が作成しています。実際のところ、 フリーなオペレーティングシステムを作ろうとしていたのは GNU だけではなかったのです (たとえば、後に NetBSD や FreeBSD となるコードはこの時点ですでに開発が進められていました)。 Free Software Foundation の存在意義は、 彼らが書いたコードだけにあるのではありません。 彼らは政治的メッセージを言葉巧みに伝えました。 利便性ではなく、信条としてのフリーソフトウェアを語ったのです。そのため、 プログラマーは政治的な面を気にせざるを得ないようになってきました。 FSF と意見が異なる人でさえ、立場が違うということを明確にするためには、 政治的な問題に足を突っ込まざるを得なかったのです。 FSF は、彼らのコードに GPL やその他のテキストを同梱することで彼らの思想を効率的に広めました。 彼らの書いたコードが広まれば広まるほど、 彼らのメッセージも広まることになりました。

無意識な抵抗

フリーソフトウェア運動の初期には、他にも多くの運動が起こっていました。 しかし、Stallman の GNU プロジェクトと同じくらいにイデオロギーを前面に押し出したものは ほとんどありませんでした。その中でも最も重要なもののひとつが Berkeley Software Distribution (BSD) でしょう。これは、徐々に Unix オペレーティングシステム —1970 年代の終わり頃まで AT&T における半ば独占的な研究プロジェクトでした— を再実装しようという動きで、カリフォルニア大学バークレー校のプログラマーがはじめました。 BSD グループは「プログラマー同士お互いに手を取り合って団結しなければならない」 といった政治的な声明は出しませんでした。 その代わりに彼らの才能と熱意でもってそのアイデアを実現させていきました。 さまざまな場所に散らばった開発者たちが協力し、Unix のコマンドラインユーティリティやコードライブラリ、 そしてオペレーティングシステムのカーネル自体についても1から書き直していきました。 そのほとんどはボランティアによるものでした。 BSD プロジェクトは、イデオロギーを前面に押し出さないフリーソフトウェアプロジェクトとして 最も有名な例です。また、 その後オープンソースの世界に残って活躍することになる多くの開発者のための訓練の場としての役割も果たしました。

別の盛んな共同開発の例としては X Window System があります。これは フリーでネットワーク越しに使用できるグラフィック環境で、 1980 年代半ばに MIT とハードウェアベンダーが共同で開発しました。 ベンダー側も、顧客に同じようなウィンドウシステムを提供したがっていたのです。 独占的ソフトウェアと対立するのではなく、X ライセンスでは フリーなコアのコード上に独占的な拡張を施すことを意図的に許可していました。 コンソーシアムの各メンバーはデフォルトの X をそれぞれ拡張し、 それによって競合する他のメンバーに対する優位を確保しようとしたのです。 X ウィンドウ [8] 自体はフリーソフトウェアですが、 その主な目的は、いわば競争する参加企業間の試合の場をならすことであり、 独占的ソフトウェアの支配を終わらせるといった意図はありませんでした。 もうひとつの例を挙げましょう。GNU プロジェクトの数年前に開発が始まった TeX です。これは、Donald Knuth によるフリーで高品質な組版システムです。 彼は、誰でもコードを改変して再配布できるというライセンスのもとで Tex を公開しました。 ただし、改変したコードを再配布する際には、非常に厳しい互換性テストをクリアしない限り "TeX" の名を使ってはならないという制限をつけました (これは、フリーなライセンスにおける "商標保護" の例です。詳細は 章 10. ライセンス、著作権、特許 で説明します)。Knuth は、自由なソフトウェアか独占的なソフトウェアかといった問題については 特に立場を表明していませんでした。彼は、単に 真の 目的 (コンピュータプログラミングに関する書籍の出版) を達成するためのまともな組版システムがほしかっただけなのです。 そして彼にとって、自分の作ったシステムを一般に公開しない理由はなかったのです。

すべてのプロジェクトやライセンスをここで挙げることはしませんが、 1980 年代後半にはさまざまなライセンスのさまざまなフリーソフトウェアが存在したということは ここまでの例でも十分に伝わるでしょう。 さまざまなライセンスが存在するということは、 フリーソフトウェアを公開する動機にもさまざまなものがあるということを表しています。 GNU GPL を選択したプログラマーであっても、 GNU プロジェクトほどにはイデオロギーを押し出していない人も存在します。 彼らはフリーソフトウェアの開発を楽しんでいますが、 その多くは、特に独占的ソフトウェアを敵視しているわけではありません。 この世から「ソフトウェアの囲い込み (software hoarding)」(Stallman がフリーでないソフトウェアを指すときに使用する用語) をなくすんだ! という道徳的な衝動にかられる人もいましたが、 単に技術的な興味からフリーソフトウェアを開発している人もいました。 また、同じ趣味を持つ人と共同作業をするのが楽しいとか、 有名になりたいとかいう理由の人もいたことでしょう。 しかし、このように本質的に異なる動機を持った人たちが お互いに悪影響を及ぼしあうことはありませんでした。 小説や絵画と異なり、ソフトウェアには最低限の基準 (きちんと動くこと、バグが存在しないこと) があったことも理由のひとつでしょう。 そのため、プロジェクトの参加者が共同で作業する際に 技術面以外の適性をあまり気にする必要がありませんでした。

開発者たちが手を取り合う理由がもうひとつありました。 フリーソフトウェア界が非常に高品質なコードを生み出していることがわかってきたのです。 時には、フリーでない同等製品より明らかに技術面で上回っているものもありました。 あるいは、少なくとも同等の機能を持っているものも多くありました。当然、 これは低コストで入手することができます。 フリーソフトウェアの思想に厳密に従うためにフリーソフトウェアを使用するという人は あまり多くなかったかもしれません。多くの人たちは、 単にそちらのほうが高性能だからという理由でフリーソフトウェアを選択していました。 そしてソフトウェアを使う人たちの中には、 そのソフトウェアの保守や改善のために時間と力を貸してくれる人が常にある程度以上いたのです。

この「よいコードを生み出す」という傾向はまだ普遍的なものとはなっていませんでしたが、 徐々に世界中のフリーソフトウェアプロジェクトでも同様の現象が見られるようになってきました。 ソフトウェアに強く依存する産業界でも、徐々にそのことに気づき始めました。 彼らの多くは、すでに日常の作業にフリーソフトウェアを使用していましたが、 それに気づいていませんでした (上級管理職が IT 部門の動きを常に把握しているとは限りません)。 企業は、フリーソフトウェアプロジェクトに対して より積極的、公共的な役割を担うようになりました。 彼らのために時間や設備を提供したり、 あるいはもっと直接的に資金を提供したりすることもありました。 うまくいった場合は、そのような投資が何倍にもなって返ってくるかもしれません。 そのプロジェクトにフルタイムで専念している一部の専門プログラマーに対して資金を提供することで、 プロジェクト全体 (無償のボランティアや他の企業に属するプログラマーなど) の活動の利益を得られることになります。

「フリー」と「オープンソース」の違い

産業界がますますフリーソフトウェアに注目するようになると、 プログラマーたちはまた新たな問題に直面することとなりました。 そのひとつは「フリー」という言葉の意味についてです。 「フリーソフトウェア」という言葉を聞いて、多くの人がそれを単なる 「無料のソフトウェア」というように勘違いしてしまいます。 確かにすべてのフリーソフトウェアは無料ですが、 [9] 無料のソフトウェアがすべてフリー (自由) であるとは限りません。 たとえば、1990 年代のブラウザ戦争の際に Netscape と Microsoft はともにブラウザを無償でばらまき、 市場のシェアを獲得しようと躍起になりました。 このどちらのブラウザも、"自由なソフトウェア" という意味でのフリーではありませんでした。 そのソースコードを見ることができなかったり、 あるいはたとえ見ることができたとしてもそれを改造して再配布する権利がなかったりしたのです。 [10] できることといえば、実行ファイルをダウンロードして動かすことだけでした。 これらのブラウザには、店頭で箱売りされているソフトウェア以上の自由などありませんでした。 単に価格が安かっただけです。

この「フリー」という言葉が混乱を招く原因は、 不幸にもこの英単語がいろいろな意味を持ってしまっていることにあります。 他の大半の言語では、価格が安いことと自由であることは簡単に区別できるでしょう (たとえばロマンス諸語を話す人にとっては gratislibre の違いは明確です)。 しかし、英語がインターネット上での標準言語として使われている現状では、 英語の問題は、ある意味ではすべての人たちの問題であるともいえます。 この「フリー」という言葉の意味の履き違えがあまりにも広まってしまったので、 フリーソフトウェア開発者は決まり文句をつくり出しました。 "フリー (free) とは、自由 (freedom) のことです。つまり、フリースピーチ (言論の自由) というときの「フリー」であり、フリービール (無料のビール) というときの「フリー」とは違います。" しかし、何度も何度もこれを説明しなければならないのは大変です。 多くのプログラマーが、この「フリー」というあいまいな単語のせいで 自分たちのソフトウェアが世間に正しく理解されないと感じるようになりました。

しかし、問題はもっと深いところにありました。 「自由」という言葉には道徳的な意味が含まれています。 自由であることが目的なのならば、フリーソフトウェアがよりよいものになろうが 特定の状況において特定のビジネスで有益になろうが、 そんなことはどうでもよかったのです。 単にその動機にちょっとしたよい副作用があっただけです。 心底は技術的でも商業的でもなく、道徳的な動機だったのです。 さらに「自由という意味のフリー」という立ち位置は、 フリーなプログラムのサポートもしたいが別の独占的ソフトウェアの商売も続行したい という企業にとってはちょっと不便なものでした。

このジレンマは、すでに自己喪失状態になっていたコミュニティーに突き刺さりました。 実際にフリーソフトウェアを書いているプログラマーたちは、 仮にフリーソフトウェア運動全体としての目標があったとしても そのために一致団結することはありませんでした。 彼らの考えには両極端のものがあったと言ってしまうのもちょっと違います。 そんな風に言ってしまうと、まるで彼らの違いが単一の基準だけにもとづくものだと勘違いされてしまいます。 しかし、些細な違いをとりあえず無視するなら、 彼らの考え方は大きく2種類に分けることができます。 一方のグループは Stallman の考え方に共鳴する人たちです。 ソフトウェア自由に共有できて自由に改変できることこそが最も重要で、 自由について語ることをやめた瞬間に本質的な問題から離れることになります。 もう一方のグループは、ソフトウェアそのものこそが最も重要であると考えており、 独占的ソフトウェアを敵視するような考え方は好みません。 すべての人がそうだというわけではありませんが、プログラマーの中には、 作者 (あるいは雇用主) は再配布権をコントロールできるようにすべきだと考えている人たちもいます。 再配布権を考える際に、道徳的な視点は不要だということです。

長い間、これらの違いをきちんと調べたり あえて明確にしたりすることはありませんでした。 しかしフリーソフトウェアがビジネスの世界に広まっていく中で この問題は避けられないものとなってきたのです。 1998 年に、「フリー」にかわる言葉として オープンソース が登場しました。 これは、後に Open Source Initiative (OSI) となるプログラマーの集団が定義したものです。 [11] OSI は、「フリーソフトウェア」という言葉が混乱の元であるというだけでなく、 「フリー」という単語が、より全般的な問題の徴候のひとつであると考えました。 フリーソフトウェア運動をより広めるためには、 何らかのマーケティング戦略が必要です。しかし、 道徳だの社会全体の利益だのといった言葉は 決して重役会議で扱われることはありません。 OSI はこのように言っています。

Open Source Initiative はフリーソフトウェアのマーケティングプログラムです。 イデオロギーについて熱弁をふるうのではない、 手堅く実際的な立場において「フリーソフトウェア」を広めるためのものです。 勝算のある中身はそのまま、 勝ち目の無い態度や象徴主義を変えたのです。……

ほとんどの技術者にとって、 必要なのはオープンソースの概念ではなくその名前についての説明です。 なぜ旧来の「フリーソフトウェア」ではなく 「オープンソース」なのでしょうか?

直接の理由のひとつは、「フリーソフトウェア」 という言葉が誤解を受けやすく、混乱の元になるということです。……

しかし、名前をつけなおした真の理由は、マーケティング上のものです。 私たちは、フリーソフトウェアの概念を一般の業界にも広めようとしています。 私たちはすばらしい製品を持っています。しかし、 過去においては私たちの立場はひどいものでした。 「フリーソフトウェア」という言葉はビジネスマンの誤解を招き、 反商業主義だとか、時には盗人呼ばわりされることもありました。

大手企業の CEO や CTO は、決して「フリーソフトウェア」 を購入することはありませんでした。 でも、今までとまったく同じ考えのもとで同じ人たちが作り、 同じライセンスを適用したものの名前を「オープンソース」 と変えたらどうなるでしょう?彼らはそれを購入してくれるのです。

ハッカーたちにとっては、これは信じがたいことでしょう。 技術者というのは、具体的で中身のあるものに置き換えて考える傾向があるからです。 しかし、何かを売るときにはイメージというものが重要なのです。

マーケティングにおいては、見た目が重要となります。 私たちが進んでバリケードを取り壊し、 喜んで産業界と一緒に仕事をしようとしているように見せることは、 私たちの実際の振る舞いや信念、そしてソフトウェア自体と同じくらい 価値のあることなのです。

(http://www.opensource.org より引用。 いやむしろ 以前は そこにあった、というべきでしょう。  —  OSI はこのページを削除してしまったようですが、 http://web.archive.org/web/20021204155057/http://www.opensource.org/advocacy/faq.phphttp://web.archive.org/web/20021204155022/http://www.opensource.org/advocacy/case_for_hackers.php#marketing で今でも見ることができます。 )

この文には、さまざまなツッコミどころがあります。 まず、「私たちの信念」とは書かれていますが、 その信念とはいったい何なのかということは巧妙に省略されています。 ある人にとっては、オープンソースの手法はよりよいコードを生み出すという信念かもしれません。 あらゆる情報を共有すべきだという信念の人もいるかもしれません。 「盗人」という言葉は、(おそらく) 違法コピーのことを指しているのでしょう。 この言い方には異議がある人も多いことでしょう。 元の所有者がまだそれを保持しているのだから 「盗人」はおかしいのではないかと思われるかもしれません。 フリーソフトウェア運動が反商業主義だと非難される可能性については説明していますが、 その非難が何かの事実にもとづくものなのかどうかには触れていません。

別に、OSI のウェブサイトが矛盾していて紛らわしいと言っているわけではありません。 そうじゃないんです。 これまでのフリーソフトウェア運動が欠いてきたものだと OSI が主張する、まさにそれの例になっているんです。 そう、「よいマーケティング」です。 「よい」とは、「業界で生き残っていける」という意味です。 Open Source Initiative は、多くの人々に彼らが待ち望んでいたものを与えました。 道徳的な十字軍ではありません。 フリーソフトウェアによる開発手法や経営戦略を語る上で必要な言葉です。

Open Source Initiative の登場によって、フリーソフトウェア界の情勢が変化しました。 長い間うやむやにされてきた両者にきちんとした名前をつけ、 内部の政治的な問題と同様に外部的な問題としても認識させるようにしました。 現在への影響は、両者が共通の背景を持つようになったということです。 多くのプロジェクトは両方の陣営のプログラマーを含んでおり、 またどちらに属するかはっきりしない参加者も同じくらい存在します。 これは決して、道徳的な話がなくなったというわけではありません。 たとえば、例の「ハッカー倫理」は今でもたまに話題にのぼります。 ただ、フリーソフトウェア/オープンソース の開発者が、 プロジェクトの他のメンバーに対して プロジェクトに参加する動機をおおっぴらに尋ねることはほとんどなくなりました。 貢献した人ではなく貢献の内容で評価されるようになったのです。 だれかがすばらしいコードを書いたとしましょう。 その人に対して「道徳的な理由でそれを書いたの?」とか 「金で雇われて書いたの?」「名前を売るため?」といった類のことは聞きません。 単にそのコードの内容を技術的に評価し、技術的に答えを返すだけのことです。 Debian プロジェクトは 100% フリー (もちろん「自由」という意味です) なコンピュータ環境を作ることを目標としていますが、 このように政治的な態度を明確に打ち出している組織でさえも、 フリーでないコードも提供しています。また、 方向性が完全に一致しているわけではないプログラマーとも共同作業をしています。



[4] 有名なホスティングサイトのひとつである SourceForge.net には、2004 年 4 月中旬の時点で 79,225 のプロジェクトが登録されています。 もちろん、これがインターネット上のフリーソフトウェアプロジェクトの総数である というわけではありません。 これは単に、その時点で SourceForge を選択したプロジェクトの数に過ぎません。

[5] Stallman は「ハッカー」という単語を 「プログラミングが大好きでそれを楽しんでいる賢い人」という意味で使っています。 最近よく使われるようになった「コンピュータに不正侵入する人」 という意味ではありません。

[6] これは "GNU's Not Unix" の頭文字をとったものです。 そしてこの中の "GNU" は何の略かといえば…… 同じです。

[7] 厳密に言うと、Linux が最初だったわけではありません。 IBM 互換機上で動作する 386BSD というフリーなオペレーティングシステムが Linux のほんの少し前に登場しています。 しかし、386BSD を動かすのは非常に難しいことでした。 Linux が騒がれた理由は、単にフリーなだけでなく インストールして動作させるのが簡単であったということもあります。

[8] 彼らは "X ウィンドウシステム" と呼んでほしいようですが、 現実には "X ウィンドウ" ということのほうが多いでしょう。 だっていちいちそんな長い名前を言うのは面倒くさいから。

[9] フリーソフトウェアを配布する際に代金を徴収することもあるかもしれません。 しかし、購入した人がそれを他人に無料で再配布するのを禁じることはできないので、 結局のところ価格は無料同然となります。

[10] Netscape Navigator のソースコードは、結局は 1998 年にオープンソースライセンスのもとで公開されることとなりました。 これをもとにして作られたのが Mozilla ウェブブラウザです。詳細は http://www.mozilla.org/ をご覧ください。

[11] OSI のウェブページは http://www.opensource.org/ です。