Comments
Description
Transcript
企業戦略としてのオープンソース
DISCUSSION PAPER NO. 17 企業戦略としてのオープンソース −オープンソースコミュニティの組織論と 外部資源を利用した研究開発の発展に関する考察 2000 年 7 月 科学技術庁 科学技術政策研究所 第１研究グループ 加 藤 み ど り この DISCUSSION PAPER は、所内での討論に用いるとともに、関係の方々からのご意見を頂くことを目的に作成した ものである。また、この DISCUSSION PAPER の内容は、執筆者の見解に基づいてまとめられたものであることに留意 されたい。 執筆者： 加藤みどり 第１研究グループ科学技術特別研究員 （平成 11 年 1 月∼平成 12 年 3 月） Open Source as a Corporate Strategy -A study of the open source community from an organizational theoretic perspective and the development of R&D with external resources July 2000 Midori KATO 1st Theory-Oriented Research Group National Institute of Science and Technology Policy (NISTEP) Science and Technology Agency 目 次 ページ 1 はじめに.............................................................................................................................................1 2 Open Source......................................................................................................................................2 2.1 Open Sourceの歴史的経緯....................................................................................................2 2.2 Open Source Community(OSC)の仮説的分析1 ∼Linuxカーネル開発コミュニティへの組織論的アプローチ...................................5 2.2.1 組織構造 ........................................................................................................................7 2.2.2 組織文化 ......................................................................................................................12 2.2.3 マネジメントコントロール ......................................................................................14 2.2.4 OSCにおけるマネジメントの意義..........................................................................16 2.3 OSCの仮説的分析2∼R&Dプロジェクトとしての評価.................................................19 2.3.1 Linuxカーネル開発コミュニティと企業のR&Dプロジェクトの相違...............19 2.3.2 知識の流通とコミュニケーションコスト ..............................................................20 3 ビジネスにおけるOpen Sourceの実際........................................................................................24 3.1 現在のLinuxビジネスの構造...............................................................................................24 3.2 Open Source浸透の背景......................................................................................................26 3.3 ディストリビュータと開発コミュニティへの出資と提携.............................................28 3.4 大手企業によるLinuxのサポート.......................................................................................31 3.5 企業主導のOpen Sourceプロジェクト..............................................................................33 3.5.1 Netscape CommunicationsのMozilla.org.................................................................34 3.5.2 Sun MicrosystemsのJava2..........................................................................................37 3.5.3 AppleのDarwin計画...................................................................................................39 3.5.4 IBMのOpen Sourceへの取り組み............................................................................41 4 企業戦略としてのOpen Source....................................................................................................43 4.1 ビジネスモデルとR&D戦略の関係∼コア技術とセンター技術...................................43 4.2 R&Dにおける外部資源の利用...........................................................................................46 4.3 Trillianプロジェクトの事例 ................................................................................................48 4.4 Open Sourceライセンスとビジネス..................................................................................51 4.5 企業によるOpen Sourceに必要な条件..............................................................................54 5 新しいR&D戦略に向けて.............................................................................................................56 6 おわりに...........................................................................................................................................58 参考文献 ...........................................................................................................................................59 付録 ...........................................................................................................................................62 1 はじめに Open Source(注1)とは、ソフトウエアのソースコードをすべて公開しながらおもにネット ワーク上で開発を行う手法の総称である。1998年初めに始まったOpen Sourceムーブメント は、既存の大手企業を巻き込み、クローズドな技術が競争力の源泉であるとの発想に基づい た従来のR&D戦略を大きく変貌させた。 企業によるOpen Sourceプロジェクトの実施は、R&Dにおける外部資源の利用、R&Dお よびビジネス戦略という観点から新しいものである。 企業のR&Dにおける外部資源の利用は、共同研究、提携、アウトソーシングなどという 形で古くから行われていたが、その多くは自社内の技術を中心に据え、限られた企業間関係 の中で技術あるいは資源を補完するというものであった。あるいは提携やコンソーシアムな どにより確立した標準技術をコントロールし、その後のビジネスの展開を有利にしようとい う戦略的意図に基づいていた。企業によるOpen Sourceは、技術をすべて公開し、また不特 定多数の外部資源を利用するという点において、従来のR&Dやビジネスの方法論にあては まらない。 本稿は、このような新しいR&Dの動向を対象とした研究に先立ち、議論の提供を目的と した予備的・実験的な調査研究である。本稿の前半では、Open Sourceの中でも最も有名な Linuxカーネル開発コミュニティの事例を文献から調査し、ボランタリな開発者たちの文化 や、ネットワーク上での共同開発におけるマネジメントを考察する。また、緻密な計画がな くともLinuxカーネル開発がR&Dプロジェクトとして速く品質の高い製品を産み出している 理由を議論する。後半では、企業のOpen Sourceへの関与という最新の事例を検討すること により、Open Sourceとビジネスモデルとの関係、およびOpen Source戦略のねらいについて 考察する。最後に、外部資源を利用したR&Dの今後について検討する。 (注1) 詳しくは http://www.opensource.org/ を参照 -1- 2 Open Source 2.1 Open Sourceの歴史的経緯 Open Sourceの中で広く一般にも知られているのがLinuxカーネル(注2)開発プロジェクトで あろう。もっとも、こうした手法やソースコードを共有する文化は、特にUnixソフトウエア 技術者、およびUnixを基盤とするThe Internet(注3)においては古くから普遍的なものであり、 Open Sourceと正式に命名されたのは1998年なってからである。彼らはネットワーク上での コミュニケーションを、実務の面からも社交においても、古くから使いこなしてきた。 Open Sourceプロジェクトに参加するプログラマたちは、hacker(注4)文化と呼ばれる独自の 文化を形成・共有し、コミュニティとしてネットワーク上に存在してきた。 インターネットは分散および多様な環境下で確実にネットワークがつながることを目的と して開発されてきたため、標準技術や、関係者全員による運用上のルールの遵守が必要にな る。現在のインターネットの標準となっている規格やソフトウエアには、Open Sourceによ るものが多く存在する。インターネットの標準技術は約20年前にほぼ完成されたが、当時、 それらがOpen Sourceと呼ばれていたわけではない。当時の技術開発の様子を、電子メール 技術の確立に多大な貢献をしたCrocker［1］は、「ARPANET (注5)の標準化の方法は熱意で (注2) カーネルとはOperating System(OS)のコアとなる部分を指す (注3) ARPANETで培った技術を元に構築された米NSFNETをバックボーンとする学術研究 用ネットワークの総称で、現在商用利用されているインターネットの母体となった。 (注4) 多くのマスコミはCracker（システム侵入などセキュリティ破り全般を行う人）を Hackerと表現して報道しているが、これは正しくない。RFC1983: FYI(For Your Information)18 , 08/16/1996では、hacker は"A person who delights in having an intimate understanding of the internal workings of a system, computers and computer networks in particular. The term is often misused in a pejorative context, where "cracker" would be the correct term. See also: cracker."と定義されている。 詳しくは,例えばYAMANE Shinji氏のwebサイトhttp://www.vacia.is.tohoku.ac.jp/~syamane/articles/hacker.html（"hacker is *not* cracker"）を参照。 (注5) 1969年に米国防総省の高等研究計画局(ARPA)が導入したコンピュータネットワーク。 各地に分散したUnixコンピュータ同士をTCP/IPで相互接続するという形態は、まさに現在 のインターネットの原型である。 -2- 就職活動するようなもので、誰かにあるアイディアがあってその実装が気に入った他の人が それを使うという過程で、つまり自由採用による標準化」と表現している。技術開発の過程 で、より多くの人に、より優れていると認められたものが自然と標準化していく様子が伺え る。また、RFC（Request For Comment）と呼ばれるインターネットに関わるさまざまな技 術の仕様・要件は、すべて文書で公開されている。RFCもまた、多くの人に公開され、コメ ントや修正を受けながら制定されていった。 インターネットの技術のほとんどはUnix上で開発されており、Open Sourceはこのような The Internetの歴史、およびUnixプログラミングの歴史と切り離して考えることはできない。 電子ネットワークというメディアにおけるコミュニケーションの特性も、Open Sourceに 大きな影響を及ぼしている。Open Sourceコミュニティにおもに用いられてきたのは、メー ル、ネットニュース、ftpである(注6)。特によく用いられるメーリングリストは、同時に多 くの人へ即座に情報を発信できる同時性・即時性というマスメディアと似た特徴を持つが、 その双方向性はマスメディアにはない性質である。また、インターネットにおける情報発信 のコストは非常に低い。さらに、ftpやwebは、情報の発信元である1箇所で変更するだけで、 その変更が即座に全ての読者に対し有効になるという特徴を持つ。しかし、こうした電子ネッ トワークの特徴は、デメリットに転じることも多い。情報の発信が多くなればS/N比（Signal Versus Noise Ratio）が上がり、特定の情報を探すコストは大きくなる。さらには、ほとん どの人にとって迷惑でしかない情報も、故意あるいは無作為に関らず、役に立つ情報と同じ く容易に発信できてしまう。このような理由に加え、以前はネットワーク資源が貧弱であっ たこともあり、インターネット上のコミュニケーションには古くから「ネチケット(注7)」と 呼ばれるマナーが推奨されてきた。ネチケットも、可能な限りの簡潔さを好み、またインター ネット上のコミュニケーションを知り尽くしたコミュニティの知恵の蓄積物である。 Open Sourceムーブメントは、フリーソフトウエア開発の保護・育成を目的にFSF(Free Software Foundation)を設立し、GNU(注8)プロジェクトを開始したStallman(注9)らによる啓 (注6) WWW(World Wide Web)はインターネットの歴史において比較的最近になってから登 場した。現在ではもちろんWWWは非常によく用いられている。 (注7) http://www.edu.ipa.go.jp/mirrors/netiquette/fauj/netiquette.html -3- 蒙活動に影響を受けている。ユーザはソフトウエアを「実行、コピー、配布、研究、変更、 そして改良する自由を保証されるべきである」［2］と主張するStallmanによる「フリーソフ トウエア」の定義［2］は厳密で、さらには反商業主義的な思想も反映されている。こうし た思想に基づき、知識の占有および商用利用を前提とする現在の知的所有権保護の目的とは 対極をなす、著作物を自由(注10)にしておくためのCopyleft(注11)の概念や、現在も実際にフ リーソフトウエア、Open Sourceソフトウエアによく適用されているGPL(General Public License)の制定を行ったのもFSFである。FSFがOpen Sourceコミュニティに及ぼした影響は 非常に大きい。しかし、一般にはフリーソフトウエアの定義は必ずしも一意的でなく、また 解釈に対するプログラマの立場もさまざまである。現在のOpen Sourceの定義［3］は、 Open Sourceを推進する非営利組織Open Source Initiative(OSI) (注12)によってなされたが、 Stallmanが主張するフリーソフトウエアとの違いをより明確にすることがひとつの目的であ り、ビジネスでの使用を視野に入れたものとなっている。 世界中で様々なOpen Sourceプロジェクトが稼働中だが、その波はソフトウエアに留まら ず、1999年には「オープンハードウエア［4］」いう携帯型コンピュータのOpen Sourceプロ ジェクトが日本で発足し、2000年春には発売が予定されている。このMorphy Oneプロジェ クトは、GNUが定めたGPLに基づき、その精神は十分に尊重しながら解釈をハードウエア に適用している。 (注8) http://www.gnu.org/home.htmlを参照 (注9) http://www.fsf.org/people/rms.htmlなどを参照 (注10) Stallmanは自由の意味として、 1. 誰もが自由に複写、配布できること 2. 誰もが自由に修正できること の2点を挙げている。 (注11)ユーザの自由を保障するために行使される著作権、あるいはその概念。 詳しくはhttp://www.gnu.org/copyleft/copyleft.htmlを参照 (注12) 1998年12月に設立されたOpen Source運動推進のボランタリな組織で、コミュニティ の有名人PerensとRaymondが発起人となっている。 -4- 2.2 Open Source Community(OSC)の仮説的分析1 ∼Linuxカーネル開発コミュニティへの組織論的アプローチ ここでは新しいR&Dモデルとして、OSCの中からLinuxカーネル開発コミュニティを取り 上げ、実験的に公開文書やインタビューから考察を加えてみよう。 LinuxとはIntel系チップ、Alpha、SPARC、PowerPCなど複数プラットフォームで稼働す るUnix互換のOSである。もともとはi386以上を搭載したIBM PC/AT互換機と称されるハー ドウエアが主要な対象であったことから、FreeBSD(注13)などとともにPC-Unixと総称され ることもある。2000年3月現在1000万人超とされるユーザを抱えるLinuxは、当時ヘルシンキ 大学の学生であったLinus Torvaldsによって1991年に開発が開始された。Linuxは、専用Unix プラットフォームやMicrosoftのWindows NTプラットフォームの代替オペレーティングシス テム(注14)として、これらをはるかにしのぐ成長率(注15)で普及している。 Linux開発コミュニティは、おもにメーリングリストによって活動を行っており、全ての 人に対してオープンな立場を取っている。カーネル開発コミュニティは、発足当初は小規模 なものであったが、以降拡大の一途を辿っている。図1には1996年以降のLinux-kernelメーリ ングリストへの投稿数の推移を示した。Open Sourceが一般にも認知されるようになった 1998年に、投稿数が急増している。 Linuxに関るOSCの範囲は非常に広く、カーネル開発以外にも様々な人がコミュニティに 貢献している。図2に示したのは、その便宜的な分類の一例に過ぎない。図2における開発コ ミュニティやユーザグループなどの各要素は互いにオーバーラップしており、階層構造を取っ (注13) バークレーUnixの流れをくむフリーのUnixで、やはりPC上で稼動する。 (注14) よくWindows95/98などとの比較がなされるが、これらはクライアント・サーバ環境にお いてクライアント用途に分類されるOSである。一方LinuxはUnix、NTなどとともにサーバ用 途に分類されるOSであるため、LinuxとクライアントOSとの比較は現状では的を射ているも のではないと言えよう。しかし、GUIの充実による直感的に操作できるデスクトップ環境の 構築や、オフィス向けアプリケーションソフトの無償配布などにより、クライアントOSとし ても普及を目指す動きも既に起こっている。 (注15) International Data Corporation（IDC） の調査によれば、1998年の出荷ライセンス本数 の前年度比成長率は、Windows NTが27%増、Linux以外のUnix全体では4.1％なのに対し、 Linuxは212.5％であった -5- ているわけではない。 こうしたコミュニティは自律的、自己組織的に発達していったものであり、おそらくはコ ミュニティに属する個々人がより合理的な形態を求めて発展・解消の歴史を繰り返した末に 現在の形に落ち着いたものである。 70000 60000 50000 投 稿 数 40000 ︵ ポ ス 30000 ト ︶ 20000 10000 0 1996 1997 1998 1999 図 1 Linux-kernelメーリングリストへの投稿数の推移 （http://www.geocrawler.com/archives/より作成） カーネル開発 開発コミュニティ アプリケーショ ン・ツール開発 ディストリビューション開発 プロジェクト Linuxコミュニティ 文書（翻訳、HowTo） 普及、セミナー ユーザコミュニティ ディストリビューション別 ユーザーズ グループ 地域別（地域LUG） その他 図 2 Linuxコミュニティの一例 -6- 2.2.1 組織構造 組織構造の定義は複数存在するが、その多くは職能別組織・事業部別組織など複合的な組 織からなる大企業を想定したものである。今回の考察対象のOSCは研究開発という単職能の 組織であるから、管理部局および管理者間の権限とコミュニケーションのライン、およびこ れらのコミュニケーションと権限のラインを流れる情報と資料というChandler［5］の古典 的な定義を借りて分析を進めることとする。 Raymondは"The Cathedral and the Bazaar"［6］の中で、有力な指導者の監督の下、計画的 にプロジェクトを進める従来の開発手法を伽藍の建築に、一方人々が自由に出入りでき、強 力な指導力が働くわけではないLinux開発コミュニティの開発手法をバザールに例えている。 確かに同コミュニティには入退の制限はほとんどない(注16)ようであるが、経営組織論でい われる水平型組織やネットワーク型組織に相当するわけではない。むしろ、Linuxの生みの 親であるLinus Torvaldsを頂点とし、その下に共同開発者（コアチーム）、貢献者、デバッ ガおよびテスタ、潜在的な貢献者が連なるような、図3に示すピラミッド型の階層構造が示 唆される。 Torvaldsへのインタビュー［7］によれば、回答当時のコアチームは約10名(注17)であった。 コアチームはTorvaldsによって任命され、異義がなければコミュニティの総意という形で信 任される。Raymond［8］によれば意思決定者はTorvaldsおよびコアチームのみであり、コ アチームの中で意見が分かれる場合は、Torvaldsが最終決定権を持つ。 コアチームの他に、個々のプログラムの担当責任者である、MAINTAINERと呼ばれる人 たちがいる。MAINTAINERは自分が担当するプログラムの管理・調整を行なうが、意思決 定権はあくまでコアチームが持つ。143のMAINTAIN項目に対し、MAINTAINERとして MAINTAINERSファイルに名前が掲載されているのはカーネルバージョン2.2.14 で118名で ある。 カーネル開発に貢献したとされてCREDITSファイルに名前が載せられている貢献者 (注16) 後述するコアチームのメンバになれば、何の断りもなく退出するのは慣習的に不可能と されている。 (注17) Linuxのコアチームは、他のOpen Sourceプロジェクトと比較して、その選出方法もメ ンバの存在自体もあいまいだとされている。 -7- (contributor)は、カーネル2.2.14 で273人である。貢献者が貢献者の階層にいるのは、あくま でソースコードがカーネルに採用された結果としての事象であり、ソースを提出したからと いうわけではない。後述するが、OSCにおける貢献とは、カーネルに採用されるソースコー ドを書くことだけではなく非常に幅広いものである。しかし、ここでは開発活動に対象を絞っ て、コアチームを除いたMAINTAINERおよびカーネル貢献者を狭義の貢献者としよう。 表1には、MAINTAINERSファイルから作成した、担当項目数別のMAINTAINERの人数 を示した。ただし括弧内は、CREDITSファイルにも名前が掲載されている人の数である。 バージョン2.2.14におけるカーネルへの貢献者とMAINTAINERの人数の合計は、320名超で あった。 表 1 MAINTAINERSと担当項目数 担当項目数 1 2 3 4 5 人数 99(52) 16(12) 1(0) 1(1) 1(1) Torvalds (magnate) core team (project leader) kernel contributor (senior leader) debugger /tester (junior leader) audience or user (potential volunteer) 図 3 Linuxカーネル開発コミュニティの仮説的組織図 -8- 貢献者の下には、新しいバージョンがリリースされるとすぐさまバグ取りを行い、様々な 環境でテストを行い動作結果を報告する層がいる。最下層にはメーリングリストに登録はし ているが、読むのに専念している人たちがいる。 コアチームとMAINTAINER以外の参加者には、基本的に「仕事」に対する所与の責任は なく、自分の好きな種類とレベルの仕事を選ぶことができる。もともとはコアチームも MAINTAINERも誰かから責任を課されていたわけではなく、各人の自主的な関与による優 れた仕事が周囲から評価され、コミュニティの中で責任を負う立場にあるべき人物として認 められたのである。もし、彼らが何らかの理由で責任を全うできなくなったり、または責任 対象の仕事への興味を失った時は、速やかにその意を公開し、コミュニティの総意による正 当な後継者を選ぶことによって彼らは円満にその地位を辞すことができる。 Raymond［6］は同コミュニティを「中央集権的ではない」と表現しているが、意思決定 者が明示されており、かつ構成員に対してその数がかなり少ないことを考慮すると、少なく とも意思決定にかかわる権限構造は中央集権的である。なお、「管理者と複数の共同開発者 が意思決定にあたるのは、OSCでは一般的」［9］である。 OSC内のコミュニケーションには特徴がある。ひとつは、無駄なコミュニケーションを非 常に嫌い、避けることである。カーネル開発メーリングリストを購読する前に必ず読むべき とされる"Mailing List FAQ"(注18)には、無駄なコミュニケーションを取らないよう、また無 駄なコミュニケーションによって参加者に迷惑をかけないよう繰り返し注意を促している。 しかしながら、この注意はOSCに限らず、ネットワーク上で人が集まる場では一般的に観察 されるものである。したがって、こうした注意はOSCの特徴に由来するというより、ネット ワーク上でのコミュニケーションの特質に由来するものと考えた方が妥当であろう(注19)。 もうひとつの特徴は、コミュニケーションの方向である。Raymond［8］はメーリングリ (注18)FAQ(Frequently Asked Question) (注19) インターネットが非商用利用されていた時の参加者は学術関係者がほとんどであったり、 またネットワーク資源が限られていたこともあり、このような無駄のないコミュニケーショ ンに関する考え方や文章表現上の注意（ネチケット）は相当程度徹底されており、特別なこ とではなかった。最近ではインターネット利用者の急増でそのような教育が追いつかず、利 用者全体から見ればこうしたマナーなどを強要される場は少なくなってしまい、逆に特徴と なっている。 -9- スト内の人々を、Torvaldsを含むcore member（コア・メンバ）とそれ以外（周辺）に分け、 「コア・メンバと周辺との間のコミュニケーションのみが存在し、周辺同士はコミュニケー ションを取らない」としている。一方Torvalds［7］は、「サブエリアに分かれたコアチーム 全員に関係ある問題はめったにないのでメーリングリストはなく、相談する時に彼らとは（専 用の）メーリングリストではやり取りしていない」としている。Raymondが言うcore memberと、Torvaldsが指すコアチームが全く同じものかどうかは不明であるが、実際の開発 メーリングリストには、非コアメンバ同士のコミュニケーションも、コアメンバ同士のコミュ ニケーションも多々存在する。予備調査として、カーネル2.2に関る開発を行ってきたとされ る68週間のメーリングリストのログ(注20)のダイジェスト版を取り上げてみると、非コアメ ンバの提案に複数のコアメンバ・非コアメンバからさまざまな意見が出され、最終的にコア メンバが意思決定する、あるいはコアメンバの提案に非コアメンバが要望や修正案を提出し、 コアメンバがそれをまとめたものを正式プランとするなどのパターンを見出すことができる。 また調査期間内においては、発言数が多い順に並べた上位10数名は、MAINTAINERSある いはCREDITSファイルに名前がある人、あるいは重要な仕事を行っていることが広く認知 されている人ばかりである。Raymondの表現は、何らかの決定事項に関するコアメンバ対非 コアメンバのコミュニケーションの典型的図式であると解釈するのが妥当なのではなかろう か。 すなわち、このコミュニティ内には、Torvalds対コアメンバ、およびTorvaldsを含むコア メンバ対一般参加者という垂直方向の2種類のコミュニケーションがおもに存在し、水平方 向のコミュニケーションは従属的であることになる。こうした現象は、開発という機能に対 する合理性・効率性の追求と、前述したネットワーク上でのコミュニケーションの特徴が大 きく関与していると考えられる。すなわち、「コアメンバ全員に関係ある問題はめったにな いため専用メーリングリストが存在しない」のは、Torvaldsによるカーネルのサブシステム への巧みな分割と、コアメンバへの高度な権限委譲がそれを可能にしているからと推察され る。「互いが独立性を保ったモジュールに分割した」［10］のでなければ、「同時平行的に (注20) カーネル開発メーリングリストの過去の議論の内容は、http://kernelnotes.org/、 http://kt.linuxcare.com/kernel-traffic/などから読むことができる。 -10- いくつもの作業を推進するのが非常に難しく」なり、また「変更が施されたファイルを一つ 一つ点検し、他に悪い副作用がないことをいちいち確かめなければならない」状況に陥るた め、結果的に水平方向のコミュニケーションを取らざるを得なくなるからである。また、コ アメンバ対一般参加者という構図は、知識が相対的に少ない人が余計な発言をせず、かつ、 知識あるいは権限を持つ発言すべき人がきちんと発言するという組織のポリシーを参加者の 多くが遵守した結果であろう。 すなわち、彼らは統制の取れていない大人数のコミュニケーションから起こる混乱(注21) を避け、電子ネットワークというコミュニケーションメディアの特徴を最大限に活かした開 発方式とそれに適したコミュニケーションの方法を選択してると思われる。Torvaldsとコア チームのコミュニケーションはまれに非公開だが、開発に必要な情報はすべて公開されるの で、直接コミュニケーションに関与せずとも参加者全員が、過去の経緯と進捗状況を開発の 主体者と共有することは極めて容易である。Linux開発コミュニティにおける秩序だったコ ミュニケーションは、階層型組織より知識創造に向いているとされる水平型組織やネットワー ク型組織が前提としているものとも、あるいは電子上でのコミュニケーションに暗黙に想定 されている縦横無尽なものとも相当異なると言えよう。 このように、Linux開発コミュニティの組織は階層構造を取っていると言える。また同組 織は、権限の階層および職務権限の明確な規定、規則と手続きの明確化、専門的知識を重視 した人材登用、文書主義など、官僚制組織の特徴とされる多くの構造的要素を持つ点は興味 深い。情報の流通をコントロールして不要な混乱を回避し、組織としての効率性を向上させ るという組織の目的は一致しているのであるから、官僚制組織との類似点が多いこと自体は 妥当であろう。しかしながら、官僚制組織を含めた従来の階層型組織と異なるのは、貢献者 以下の構成員にとってコミュニティからの退出を含めた「所属」選択の自由、電子ネットワー クを効果的に利用することによる情報の非局在化とコミュニケーションコストの低さ、理念 の共有などの点である。また、現在の開発方法やコミュニティの運営方針、さらには自分の 処遇について批判的な意見を述べる人が少なからず存在し、またそのような話題では多くの (注21) n人が相互にコミュニケーションを行うと、そのパスはn・(n-1)/2で表され、構成員が増 えるに従ってコミュニケーションパスは理論上指数関数的に増加する。 -11- 人が参加しての白熱した議論が続く傾向があることから、無駄なコミュニケーションは嫌わ れるが、批判をも含めた自由な議論は必要との共通認識があるようである。官僚制組織には、 上述した構造的要素を追求するほど予期せぬ非効率性や非人間性といった逆機能が働くこと が知られているが、Merton［11］によればこの逆機能は、官僚制の組織構造それ自体から生 み出されるものではなく、人々がそれに過剰に適応したものの見方や考え方を発展させるこ とからくるものである。OSCが持つ自律を是とする独特の組織文化が組織としての合理性の 維持を可能にし、その結果、高い効率を達成している点が官僚制組織とは本質的に異なると いえる。 2.2.2 組織文化 コミュニティの構成員は、まずOpen Source Policyへの共感者で、Linuxに興味を持ち、 The InternetやUnix由来のHacker文化とマナーを身につけている。身につけていない人には メーリングリストの不特定の参加者から教育的指導があるといったように、コミュニティの 構成員は文化や価値観を共有している。その中でも世界レベルの優れた技術を持つ参加者は、 皆からの尊敬の対象となっている。彼らのような優秀な技術者を集め、特定の企業の研究開 発プロジェクトに参加させるのはまず不可能であろう。構成員は非常に自律的であり、また そうであれとする行動規範が文書としても明示されている。 The Internet、あるいはOpen Sourceの世界では、「先人の偉大な努力に感謝し、自分がな し得る成果を育ててくれたコミュニティに還元しよう」といった内容がしばしば語られる。 こうした思想は、実際にソフトウエアを開発していなくても非商用時代からインターネット に親しんでいた人たち、例えば日本の一般的な企業におけるネットワーク管理者などにも脈々 と引き継がれ、さらに彼らからも伝播されている。 コミュニティへの貢献は大いに奨励されるが、強制されるわけではない。また、貢献はそ の人の能力にあったものでいいとされる。OSCに限らずコンピュータ関係のコミュニティは、 問わず膨大な量と種類のドキュメントと、過去の種々のドキュメントを保管したアーカイブ （書庫）を作成するという特徴を持っている(注22)。開発コミュニティおよびユーザコミュ ニティはそれぞれの目的に合致したドキュメントを作成する。開発コミュニティが作成する -12- ドキュメントには、ソフトウエアに添付されて配布されるオンラインマニュアル、各種説明 文書などの他に、開発業務に必要な知識がほぼ網羅されている。これに対し、ユーザコミュ ニティの作成するドキュメントは貢献者の多さを反映し、種類も量も開発コミュニティを上 回ることも多い。ユーザコミュニティ作成のドキュメントは相対的に啓蒙的な要素が大きく、 開発コミュニティが作成した文書を自国語に翻訳するなど、特に初心者に対する教育に非常 に役立っている。開発コミュニティももちろん、ユーザコミュニティのこうした貢献の重要 性を認識し、また評価している。 公開および蓄積されたドキュメントは、コミュニティ内において高次に共有される。ドキュ メント類もソフトウエアと同様、多くの読者の目に触れることにより、間違いが修正され、 また提供される情報も多くなり、その価値が高まりながら蓄積されるというメカニズムが働 いている。 開発コミュニティおよびユーザグループはそれぞれ公式および非公式のwebサイトを持ち、 公式および有用な文書はすべてそのページから辿れるようにリンクが張り巡らされている。 こうしたサイトには、種々のドキュメントを検索できる機能があることが多い。また、無駄 なコミュニケーションを嫌う文化に不慣れな初心者への教育的配慮として、初心者向けのド キュメントが用意されている。メーリングリストへの参加者は、こうしたドキュメントに一 通り目を通してからの登録を奨励される。メーリングリストでの発言は、参加後しばらくメー リングリストでの他の参加者の発言を読み、さらに過去の議論やドキュメントを検索してか ら行うように、さらに強く奨励される。大きなコミュニティではドキュメントやサービスが 充実していることも多く、さらに多くのユーザ、すなわち将来の共同開発者予備軍が集まり やすいという傾向も見受けられる。 開発コミュニティにおいて貢献者になるには、複雑あるいは非明示的な組織的手続きを踏 む必要はない。明示された手続きにのっとり、ただ優れた報告をしたり、優れたコードを提 (注22) WindowsやMacintoshなどのパソコンユーザコミュニティも、同様に膨大なドキュメン トやアーカイブをインターネット上に蓄積し、共有する行動様式を持っている。OSやコミュ ニティによりその特徴はさまざまである。インターネットというメディア上ではこのような ドキュメントの蓄積は極めて合理的な手段であるので、もしUnixコミュニティが存在しなく とも自然発生的に同様の行動が取られていたかもしれないが、製品登場の順序から、Unixや インターネットコミュニティの行動が伝播したのであろう。 -13- 出すればいいだけである。その後、公認された開発者が判断を行い、採用されれば貢献者の 名前はソースコードと共にCREDITSファイルにて公開される。貢献が重なればその人の評 判は高くなり、さらに続けばコミュニティの総意のもとという名目で、「昇進」が用意され る(注23)。仮に、この昇進が不適切だと判断する参加者が多ければ、メーリングリストには 異議の投稿が多数なされるであろう。このように、Peer Review［6］(注24)により「適材的 所」の人事が成立するメカニズムが働くのである。多くの「自称」貢献があふれると、プロ ジェクトの混乱や評価者の負荷の増加につながるとの懸念はあるが、「ノイズを嫌い謙譲を 美徳とする」［9］組織文化の共有、あるいは対応の変更により最悪の事態を回避している のであろう。 意思決定者も、直接的、あるいは間接的にPeer Reviewで選ばれており、「いいことをし たらほめる」［6］のは意思決定者の鉄則である。先のマナー違反者への訓戒と併せて、信 賞必罰の原則が働いていると言ってよいであろう。貢献をした人は公の場で、彼らを最もモ チベートするとされている名誉を与えられる。また、彼/彼女の行動とそれに対する評価は参 加者全員に平等にオープンである。これは評価の基準も同様にオープンであることを意味す る。 このような組織文化の特徴は、ネットワーク上での開発を合理的、効率的であらしめ、か つ参加者のモチベーションを高めるように運営するために、長い年月をかけて形成されてき た結果であろう。 2.2.3 マネジメントコントロール Raymond［9］によれば、一般にHacker文化においては、「プロジェクトの管理者の仕事 の大半は他人のコードを判断することであり、大物はその地位を保つために、あらゆる機会 においてやわらかい話し方とユーモアをこめた卑下を要求される。」多くの人がTorvaldsは 控え目で好感の持てる人物であり、またいわゆる強いリーダーシップを発揮するタイプでは (注23) Linux カーネル開発コミュニティにおいては、コアチームはTorvaldsが選任するためコミュ ニティの総意が働かないとの批判もある。 (注24) ここではその分野の専門家たるコミュニティ構成員による相互評価の意味 -14- ないと評しており、彼のリーダーシップはRaymondの記述にかなり近いと思われる。適切で 公正な判断、高い技術力、謙譲の美徳が、OSCのリーダーの地位の基本的な構成要素であろ う。 Open Sourceプロジェクトの成否は、いかに多くの人が参加するかによってかなり左右さ れるので、特にプロジェクト開始前から直後においてはリーダーの示す開発ビジョンや設計 思想は非常に重要であろう。TorvaldsはLinuxの開発が始まってからしばらくは、自らが率先 してプログラミングを行っていたそうであるが、現在はプロジェクトをコントロールするた めの細かい指示は出していない。Torvaldsの最近の重要な業務は、次期バージョンのリリー ス時期や開発の方針および目標の提示、カーネル採択の意思決定などとされている。プロジェ クトが順調に進行している現在、Torvaldsがコミュニティのビジョン、あるいは世界観を示 す存在であることは、求心力という点で最も重要なリーダーシップであろう。 リーダーとしてのもうひとつの重要な役割は、高い価値を持つ情報と人材の選別である。 OSCにおいては、意思決定者に強力な権限があるからこそソースコード、人材共に思い切っ た選別が可能になる。不適切な判断をし始めたリーダーを有するOSCは、一般的な企業内組 織より非常に早く、崩壊に至る可能性が高い。 この2つのマネジメントに対し、構成員間および外部との調整または管理の必要性は相対 的に低い。 Torvaldsに限らず一般的なOSCのリーダーに意思決定権限が集中している理由は、無駄の ないコミュニケーションを確保し、高品質なソフトウエアを開発するには、それが合理的だ と広く認識されているからであろう。また、Torvalds［9］が「Linuxが移植されるたびに、 別バージョンのソースコードが誕生する。そのようなLinuxのカーネルをサポートするため には、それらすべてのバージョンのソースコードを逐一把握していなければならない」と語っ ているように、権限を集中させることによりプロジェクトの分岐を押さえようという理由も あるだろう。もともとOSCには、プロジェクトの分岐をできるだけ避け、リーダーが交代す る場合は、コミュニティ全体の承認のもとに「所有権を正当に引き継ごうとする慣習がある」 ［9］とされている。 なお、Raymond［6］によれば、一部の開発コミュニティはこうした「優しい独裁者モデ -15- ルを捨てて」いる。例えば世界のwebサーバの50%以上が搭載している「Apacheのプロジェ クトでは、共同開発者が相談して意思決定を行う合議制のスタイルを採用している。また、 応用性が非常に高いとされるスクリプト言語Perlの開発プロジェクトにおいては、最高意思 決定者の役割は共同開発者が持ち回りで務める」という。 開発コミュニティ構成員に対してのリーダーの仕事は、通常の企業や従来の経営学が想定 するものよりかなり少ない可能性が高い。また、いわゆる「リーダーシップのジレンマ」も ほとんど解消されている。その一因には、構成員が自律的で、組織文化が共有されており、 入退が自由であるというコミュニティの特徴があろう。しかし、だからこそリーダーは対す る評価は厳しく、不適切な発言や判断が続けば指摘があるか、指摘がなくとも正しい判断を する優秀な人物は退出し、リーダーは交代に追い込まれるか、さもなければそのプロジェク トは衰退する。 2.2.4 OSCにおけるマネジメントの意義 バザール開発方式は「みんながてんでんばらばらに動いている」［6］とマネジメントや リーダーシップがないように表現されがちであるが、構成員が自律的で組織文化が共有され ているため、強いリーダーシップの重要性が相対的に低いだけで、マネジメントおよびリー ダーシップは存在すると考えられる。セルフマネジメントの文化が、リーダーシップを一部 代替しているとも言えよう。しかし、すべてのOSCがLinuxほどの成功をおさめているわけ ではない。次章のMozilla.orgの事例と比較すると、開発が順調に進むためには、技術の中身 の他に、適切なマネジメントやリーダーシップは不可欠であると言ってよいだろう。 経営組織論における代表的組織として、奥村［12］は階層型組織とネットワーク組織との 2つを取り上げ比較している。表2は奥村による比較を参考に、筆者がOSCを検討・追加した ものである。筆者が加筆したセルは網がけで示している。 -16- 表 2 OSCと従来の組織類型との相違 次元・組織類型 ハイアラルキー組織 ネットワーク組織 OSC 権威の決定 権威者 権威者 構成員の総意 メンバーの行動 制限的 自律的 自律的だが、文化遵守に 関しては極めて制限的 メンバー間の関係 垂直的 支配-従属 水平的 対等 垂直的 支配-従属関係はない 行動の統合 タイト ルース 組織文化に対しタイト 要素の結合・分離 時間がかかる 柔軟にできる 時間がかかる 分離はできるだけ避ける 構成員の総意が必要 組み替えの誘因 権限によって 創発的に 合理性の欠如 組み替えの組織的手続き 非明示的 権限によって ある程度明示的 一部の人によって 明示的手続きと 構成員の承認が必要 環境適合 安定的←決定論的世界観 不確実性下 ←確率論的世界観 分散←自律的世界観と 文化の共有 経済性 規模、効率性 少種大量生産 速度、多様性、創造性 多種少量生産 効率性、速度 同時平行的 評価 上から下へ一方的 一部双方向的 メンバーの総意 情報の源・性質 上層情報 静的情報←収集によって 場面情報 動的情報←関係によって 決定に関しては上層情報 報告に関しては場面情報 情報の流れ 上から下へ 横から横へ 上下方向のみ 共有は全員で 同時的、即時的 情報のコントロール 権威者により、権威を保 持するため ないことを目指す 組織文化として自律的に コントロール、開発の合 理性が目的 組織のパラダイム （他律的）分業 協業 自律的分業 （結果としての協業） 組織と戦略の関係 戦略から組織へ 組織から戦略へ 戦略とコミュニケーショ ンの質から組織へ 組織の中心 1つ←一元的価値観 固定的 多数あるいはない ←多元的価値観 時間とともに変化 リーダーと組織文化 組織員の アイデンティティー 属する組織から 与えられる 自分が、属する組織を選 ぶことによって決める 自分の組織選択と メンバーの総意 報酬 金銭と地位 金銭と地位 名誉、仲間内の評判 -17- 水平型（フラット型）組織とネットワーク組織はの区別はしばしばあいまいである。奥村 ［12］も、「大量生産・大量販売の戦略を実行するには最適」なピラミッド型の組織に対し、 知識創造型の組織として水平型組織を取り上げている。水平型組織、あるいはネットワーク 型組織では、「縦の命令・報告といった上下関係に基づかず、横、斜めの融通無碍なコミュ ニケーション関係を取る」とされるのが一般的であった。本章で考察したように、OSCの組 織構造は階層型である。コミュニケーションは上下どちらから発せられてもよいが、上下方 向にほぼ限定されたむしろ統制的なものである。しかし情報が共有される範囲には限定はな い。また、OSCは構成員の専門技術に関する知識レベルが非常に高く、自律的であるという 観点からも、従来の経営学による組織の類型があてはまらないことがわかる。 OSCは、創造的作業に向いているとして野中［13］が主張するハイパーテキスト型組織と も多くの点で本質的に異なる。決定的に異なるのが、コミュニケーションである。野中はミ ドル・アップダウンのマネジメントスタイルを持つハイパーテキスト型組織のコミュニケー ションを「対話とメタファー/アナロジーの使用」により特徴づけているが、OSCではこの ような情報の曖昧さおよびノイズを極力避けようという強い力が働く。 OSCにとって特に重要だと思われるのが、モチベーションのマネジメントであろう。彼ら をモチベートするとされているのは、有意義なコミュニティに貢献したという満足、レベル の高い知的好奇心の充足、名誉などとされている。筆者は、その他に彼らを動かすのは「よ ろこび」という感情の共有だと考えている。文化を共有した上で、知識を速くつくりだすよ ろこびももちろんだが、コミュニティの一員として「共有しているという感情」が、特に潜 在的貢献者を成長させるように見える。 Linux開発の成功は、Open Sourceであるという理由だけでは語れない。Open Sourceプロ ジェクトの中でも、より小さい規模でも失敗したものもあり、また商用利用に関してLinux ほどの成功を収めたものは少ない。OSCの組織構造と文化、コミュニケーションが非常に特 徴的であるということは、Open Sourceという場に適した組織とマネジメントが存在し、そ れがR&Dプロジェクトとしての成功に少なからず貢献していることを示唆している。そし て、その組織は従来の分類にあてはまらない新しいものである。 -18- 2.3 OSCの仮説的分析2∼R&Dプロジェクトとしての評価 2.3.1 Linuxカーネル開発コミュニティと企業のR&Dプロジェクトの相違 Linuxカーネルの開発速度は非常に速いと言われるが、正当な評価を下すためには、プロ ジェクトに関る人員の規模、性能の向上幅などを含めて検討しなければならない。また、プ ロジェクトの効率は一般的に式1のように定義される。 プロジェクトからの回収利益 プロジェクトの効率 ＝ プロジェクトへの投下資源 ････（式1） 注：所要期間もコスト換算して資源に含める プロジェクトの生産性を議論するには、結果的に不採用になったカーネルの開発に費やさ れた時間などを投下資源として考慮する必要がある。投下されている資源は非常に大きいと 推測されるため、これを無視すれば正確な結果を得られないが、測定は非常に困難であるた め議論自体が現時点では不可能である。しかしながら、Linux開発コミュニティにおいては、 製品であるカーネルのバージョンアップとリリースが頻繁であることは間違いないであろう (注25)。また、開発に要した時間に対して品質が高いとは言えそうである。 OSC内のコミュニケーションと開発手法は非常に洗練されており開発速度も十分高いと思 われるが、こうした能力と、企業のR&Dプロジェクトのように期限厳守と限られた資源と いう大前提の下で品質を一定レベルまで向上させる能力とは、また別のものであろう。企業 のR&Dに当然要求されるプロジェクト内外のメンバや組織間の調整作業も、OSCではさほ ど考慮する必要はない。 従って本節では、Linuxカーネル開発コミュニティ内部のみを対象にし、電子ネットワー ク上のコラボレーションとして相対的に速いとされる開発速度と、緻密な計画がなくとも高 品質な製品の開発を可能にするメカニズムに焦点を絞って考察することとする。 (注25) 付録（Linux version 2.x カーネルに関する情報、http://www.linux.or.jp/kernel.html）を 参照のこと -19- 2.3.2 知識の流通とコミュニケーションコスト OSCコミュニティに限らず、研究開発の速度が速いということは、そのプロジェクトにお いて開発に関る知識の流通および転移速度が速いからである。オープンであるということは、 プロジェクトが魅力的であるなら、優秀な人材、すなわちある問題についての適切な解を持っ た人の絶対数が多いことを意味する。開発コミュニティの構成員は一般に技術にも文化にも 造詣が深く、また、開発ビジョンはTorvaldsを初めとするコアチームから明示されるため共 有が容易である。従って、彼らは細かい指示が与えられなくとも、個々の判断による適切な 開発行なうことができる。このような開発者の間で、新しい知識が公開されながら（大人数 ゆえ）すさまじい速さで流通し、その新しい知識にさらに複数の人から新たな価値が付け加 えられる。それと同時に、刻々と価値を更新される知識が、意欲ある構成員全員に共有され る。さらに、リリースやレスポンスが速いということは、コミュニティの活気や刺激につな がる。メーリングリストへの参加者が多ければ発言数も多くなり、またそれが活気となって より多くの参加者を招き入れる好循環が生成される。 一方で、大人数の開発チームに起こりがちなコミュニケーションの混乱や負荷を巧みに避 ける仕組みがある。Brooks［14］はソフトウエアの開発において「人と月(注26)が交換可能 になるのは、多くの作業者の間でコミュニケーションを図らなくても、仕事が分担できる場 合だけである」とし、むやみに開発者を追加しても開発期間が短縮されないどころか、かえっ て長引かせる危険性を指摘している。その理由は、「コミュニケーションを図ることで増え る負担は、教育・訓練および相互コミュニケーションの二つの部分からなる」からである。 ここで、OSCにおける教育と相互コミュニケーションを考えてみよう。前述したように、 ユーザグループも含めたOSCは大量のドキュメントを作成し、共有および高次利用する慣習 を持っている。これは、コミュニケーションの負荷を減らす意味でも非常に有効である。さ らに、開発コミュニティではなくとも電子ネットワークをある程度使いなれた人が集まる場 で発言する時、すなわちコミュニケーションを取ろうとする時には、事前に蓄積されたドキュ メントやメーリングリスト上でのやり取りをよく読むよう、あらゆる場面で繰り返し指導が (注26) ここでは工数（ある仕事を行うのに必要な延べ時間で、人数と時間の積で表される） における人数と時間の意味 -20- なされる。こうした場では、通常は重複などの無駄な情報発信は非常に嫌われるが、教育は その対象外であることが多い。電子ネットワークというメディアにおけるコミュニケーショ ンの長所を活かし短所を助長させないよう、例えばある新参者が過ちを犯せば、他の新参者 に対する教育効果を狙って敢えて同じ指導が繰り返される。開発コミュニティにおいてコミュ ニケーションを始めようとする人の多くは、ユーザグループなどにおいてコミュニケーショ ンのマナーを既に身に付けており、事前に必要な技術情報や開発経過を自主的に学習してか ら参加するという段取りを心得ているので、開発コミュニティが改めて教育する必要はほと んどないと言っていいだろう。また、階層構造と権限を明確化することで、相互コミュニケー ションを実質上制限しているが、メーリングリストを読めばこれまでの開発過程をほぼすべ て把握することが可能であるため、開発に必要な情報の不足はほとんど起こらない。既存の 開発者にとっては、教育コストを払う必要がほとんどない仕組みを作り上げている。こうし た理由から、参加者の絶対数の多さが、開発のスピードアップへと無駄なく転換されるので ある。 Linuxは他のOSCと同様、複数のプロジェクトが並行して進行している。例えば、カーネ ルは開発版と安定版(注27)に分かれ、開発版はTorvaldsが、また安定版はAlan Cox(注28)が責 任者となっている。開発版には次々と新しい有望なカーネルが採択されるため、リリースが 頻繁に行われる。新バージョンがリリースされると、すぐさま多くの参加者によってテスト とデバッグが行われ、その結果が次々と報告される。開発版におけるこのプロセスで評価さ れたものだけが、安定版に組み込まれるという仕組みが採用されている。 階層構造は、R&Dの各プロセスの性質と合致するよう合理的に、かつ自律的に構成され ている。Vixie［15］によると、一般的なソフトウエアの開発工程は、1.要求分析、2.システ ム設計、3.詳細設計、4.実装、5.結合テスト、6.総合テストおよび実地検証、7.保守に分けら れる。 (注27) 開発版と安定版はバージョン番号で区別される。2番目の数字が奇数なら開発版、偶数 なら安定版である。 (注28) Alan Cox は現在5項目のMAINTAINERでもあり、メーリングリストでの発言数も常 に群を抜いてトップである。極めて初期からの貢献者で、開発コミュニティの中でも最も有 名な人物である。 -21- Linux開発コミュニティにおける意思決定者は、1万人とも言われるメーリングリスト参加 者に比較して非常に少数である。一方、最も人数が必要とされるデバッグとテストには非常 に多くの人が参加している。このプロセスにおける開発者の絶対数とテスト環境の多様性は、 堅牢性をはじめとする製品の品質と、開発速度向上に決定的な影響を及ぼす。つまり、少数 精鋭と人海戦術を巧みに使い分けている。また、議論および入退出の自由と、強力な権限を 共存させることにより、多くの提案の中からより優れたものをより少ないコミュニケーショ ンコストで選別できる配慮が施されている。組織内外の調整などにわずらわされることなく、 もっとも重要な業務である意思決定を行うことができるように、組織の構造と組織過程を設 計しているのであろう。こうした組織構造および過程に、完成度の高いものを時間をかけて 出すより、バグが多少あっても"Release Early, Release Often" ［6］を優先させるという方針 を組み合わせ、「よってたかって」の手直しを促進させることにより、知識の流通・生成メ カニズムの回転速度をさらに速めている。 カーネルのモジュール化も、プロジェクトの成果向上に非常に重要な役割を果たしている。 モジュール化そのものは新しい設計思想ではないが、Torvaldsが適切にモジュール化したこ とにより、モジュール同士の独立性が高まり、横方向の調整業務と、それに伴って発生する 開発作業およびコミュニケーションを大幅に減らす結果となっている。おそらく過去のソフ トウエア開発の豊かな経験が、開発と環境に合理的な組織文化や行動規範を形成し、優秀な 製品をつくりだしたものと考えられる。 ソフトウエアの開発に必要な情報の中で、大きな割合を占めるソースコードは、コラボレー ションに用いるメディア（この事例では電子ネットワーク）で流通する形態に変換するコス トがほとんど不要である。すなわち、開発に必要な知識のこのような性質も、プロジェクト から高い成果を得るために重要な役割を果たしている。 Open Sourceコミュニティの考察から抽出された、開発プロジェクトから速い開発速度で 高い成果を得る要件は、ネットワーク上のコラボレーション一般に展開することが可能であ ろう。特にコミュニケーションコスト低減に関する施策は、電子ネットワークにおけるR& Dプロジェクトの生産性向上の検討に直接参考になるであろう。 例えば、プロジェクトに関与する人員が多いほどプロジェクトのアウトプットが向上する -22- のは、コミュニケーションと教育の管理がそのプロジェクトの許容範囲内の低いコストで行 われている場合に限られる。 効率的なコミュニケーションはどのような形態のコラボレーションにも必要であろうが、 特に電子ネットワーク上のコミュニケーションは大量の情報発信が極めて容易であるがゆえ のデメリットも内包する。このデメリットに由来するコミュニケーションの混乱を避け、ソ フトウエア以外の分野のR&Dにおいても、必要な知識をやりとりする主要なコミュニケー ションメディアで流通可能な知識については、この手法が理論的に適用可能であろう。また、 R&Dにおいて必要な知識のうち、コミュニケーションメディア上を流通可能な知識の比率 を高めることも生産性向上につながる。ハードウエアの研究開発に関する知識は、直接電子 ネットワークでやりとりできるものと、何らかの変換が必要なものに分けることが可能であ るが、Open Sourceの手法を営利を追求するR&Dに採用するかどうかは、この知識を使用す るメディアで流通する形態に変換するコストの大きさによるであろう。 -23- 3 ビジネスにおけるOpen Sourceの実際 1998年半ばから、米大手コンピュータ関連企業はLinuxビジネスへの関与を急激に深めて 行った。この関与は、ディストリビュータへもしくはコミュニティへの出資または提携、 Linuxのサポート、Open Sourceプロジェクトの主催の3つの形態に大きく分類できる。1998 年初にはLinuxのサポートを行っている企業は極めて限られていたが、2年後の2000年3月現 在では、Linuxをサポートの対象に含めない大手企業は、日本企業を含めごく少数であろう。 本章では、それぞれの関与の形態について事例研究を行う。 3.1 現在のLinuxビジネスの構造 Linuxを取り巻くビジネスの構造は、図4のように表すことができる。カーネル開発のコミュ ニティが中心にあり、カーネル以外のさまざまなソフトウエアは個人、コミュニティ、非営 利組織、営利企業が開発している。ただし、基本的なソフトウエア群のほとんどはコミュニ ティが開発している。容易に動作環境を構築できるように、カーネルと使用頻度の高いソフ トウエアやドキュメントなどをパッケージ化したものをディストリビューションと呼ぶ。ま たディストリビューションを配布しているディストリビュータは、以前は個人や非営利団体 が多かったが、最近は営利企業が増えている(注29)。ただしディストリビュータの企業とし てのあり方は、企業成立の経緯、開発への関与、コミュニティとの関係、提供するサポート の種類などの点で多岐にわたっている(注30)。商用ディストリビューションには、無償で配 布可能な基本的なソフトウエア群に加え、インストールガイド、商用ソフトウエア、サポー トサービスなどが含まれている。ユーザグループなどによる、ボランティアベースで独自の (注29) 因果関係は明らかではないが、Linuxユーザ人口の増加と商用ディストリビューション の増加は時期的に一致している。少なくとも企業ユーザの増加は商用ディストリビュータの サポートが推進したと筆者は考えている。 (注30) 世界でもっともシェアの高いRedhat Software社、欧州でトップシェアを誇るS.u.S.E.な どはコミュニティの優秀なプログラマを社員として雇用し全面的にLinuxの開発に従事させる など、コミュニティとの関係は非常に深い。また、企業としてもコミュニティとのよい関係 を保つため、大きな配慮を払っている。 -24- ディストリビューション開発や、母国語化を行うプロジェクトもある。この場合は、企業が 代行して販売業務を行っていることが多い。ディストリビュータの外側には、Linuxに関す るサポート、ソリューションビジネスを行う企業がいる。これらの多くは既存のコンピュー タ関係企業である。 ここで、あるビジネスの中心となる技術をセンター技術と考え、上述した企業および組織 の関係をLinuxに関る分業として見直せば、カーネル開発コミュニティはセンター技術の研 究開発、アプリケーションを開発する組織はセンター技術以外の研究開発、ディストリ ビュータはマーケティングと一部の流通、さらにそれを外部から取り巻く企業が営業、サー ビス、サポートを担当するという産業の分業構造を見出すことができる。 システム構築 サポート アプリケーシ ョン開発 保守 カーネル 開発 ディストリビュータ ディストリ ビュータ アプリケーシ ョン開発 出資 商用ソフト開発 コミュニティ 非営利組織 営利企業 図 4 Linuxビジネスにおけるコミュニティ・企業の分布 -25- 3.2 Open Source浸透の背景 Open Source自体は古くからあった手法であるが、ビジネス界がこぞってその価値に着目 し出したのは、Netscape Communications社が同社のwebブラウザソフトウエア(Mozilla)を Open Source化した1998年初からである。MozillaのOpen Source化宣言に関する報道は、証 券アナリストやライバル企業の懐疑的なコメントがほとんどであった。それからわずか2年 ほどの間に、大手企業はLinuxへの投資、サポートの開始などを経て、自らOpen Sourceプロ ジェクトを主催し、あるいはコミュニティに無償でソースコードを提供するまでになった。 知識の独占こそがビジネスの源泉であるという常識を覆し、大手企業がOpen Sourceに積極 的に関与するようになった背景を考えてみよう。 まず、コンピュータ関連企業が、そのビジネスモデルを、ハードウエアまたはソフトウエ アなどの有形財の「売り切り」から、システムインテグレーションやソリューションなどサー ビス中心のものへと転換した時期に合致したことがあげられる。ネットワークにおいておも にクライアント用途であるパーソナルコンピュータ（パソコン）と、その周辺機器の価格低 下は非常に急激であり、単なるハードウエアの販売では十分な利益をあげることが次第に困 難になった。価格低下に伴いクライアントの普及も急速であったが、クライアントの増加は サーバの需要を高める。よって、コンピュータ企業はハードウエア分野においては付加価値 の高いサーバ機に重点を置くようになっていった。一方、ソフトウエア分野では一部の企業 による寡占化が進み、利益の局在化が進んでいた。このような環境の変化を受け、コン ピュータ企業は、ネットワーク構築などのソリューション、サービスで収益を確保するビジ ネスモデルへ移行しつつあった。企業と顧客とのインターフェースをハードウエアやソフト ウエアなど有形財の販売からサービスへと転換した、図5に示されるサービス志向型のモデ ルである［16］。企業は、顧客にとっていかに適切なハードウエアとソフトウエアを選択し、 カスタマイズされたパッケージを構成するかによって、その能力が問われる。彼らが提供す るサービスは、技術的に複雑で高度なものであるが、使用に際して必要になる顧客の学習の 負担や、スイッチングコストは企業が提供する場合が多い。 -26- ハードウエア ソフトウエア 企業 サービス 顧客 図 5 サービス志向型ビジネスモデル サービス志向型ビジネスモデルは、Linuxのサポートビジネスにもそのまま適用可能であ る。また、サポートするOSの数が多いほど対応可能なネットワークの対象が広がるため、 競争を有利に進めることができる。サーバ分野におけるOSとして成長率が最も高いLinuxを 企業が受け入れる条件が整っていたのである。 第二に、パソコンビジネスにおけるMicrosoft、あるいはWintelの支配構造を、サーバビジ ネス・ネットワークビジネスに持ち込ませたくないとの意図が複数の企業にあったと考えら れる。無償でしかもオープンであるLinuxにおいては、Microsoftが得意とするライセンスに よるビジネスモデルは成り立たず、ライセンス料も発生しない。実質上の標準を持つ企業の コントロール権が強い産業構造から抜け出すチャンスであるとの認識が、より多くの企業に Linuxのサポートという協調行動を取らせた可能性がある。 第三に、企業とコミュニティの知識の逆転がある。これまでは企業は個人との知識格差を 利用してビジネスを成立させていた側面がある。しかし、ソフトウエア産業においては、企 業内の一般的なエンジニアよりもはるかに高い知識を持つ人達が集まるコミュニティが存在 していた。彼らの多くは商用以前のインターネットの発展に関っており、電子コミュニケー ションツールを一般より非常に早期から使いこなしていた。これが知識レベルの高いコミュ ニティを形成した大きな要因である。非常に高い知識を持つ個人はどの産業にも存在するで あろうが、ソフトウエア産業においては、コミュニティとして存在した歴史が長い。個人と 集団では、知識レベルが同じであっても企業サイドに与えるインパクトはかなり異なる。 OSCが企業に与える影響力は徐々に大きくなり、また企業側は彼らの知識の高さやOpen -27- SourceのR&Dプロジェクトとしての優位性を認め、彼らを活用可能な外部資源と認識した のであろう。 最後に、ビジネス界におけるLinuxの普及には、ライセンスが大きく影響していると考え られる。詳しくは4.4で述べるが、Linuxには派生物の公開と著作権者への還元を義務づけて いるGPL(General Public License)が適用されている。このライセンスを遵守するかぎり、 Linuxのソースコードは常にすべての人に対してオープンであり、また分岐バージョンの乱 立は起こらない。この分岐の可能性の低さが、企業にLinuxを選ばせていると考えられる (注31)。 3.3 ディストリビュータと開発コミュニティへの出資と提携 Linuxの商業的発展にとって、ディストリビューションの発明は流通革命とも言えるほど の価値があった。ディストリビューションが一般的でなかった頃は、ユーザが必要なファイ ルを選択してftpサイトから入手した後、何段階かの操作を要するインストールを行っていた。 一連の作業には、ある水準以上の高度な知識と時間、および当時としては贅沢なネットワー ク環境を要求されるため、ユーザは限られてしまっていた。しかし、ディストリビュータに よるディストリビューションは一連の問題をほぼすべて解決したため、さほど高い知識を持 たない人でも容易に動作環境の構築ができるようになり、Linuxユーザを爆発的に増加させ た一因となったのである。 現在はディストリビュータと既存のコンピュータ関連企業が渾然一体となった産業構造を 構築しているが、OSCがビジネス界に今ほど認識されていなかった頃は、ディストリビュー タはコミュニティと企業の橋渡しを行う立場という意味合いがかなり強かった。コミュニティ は営利活動を行っておらず、その文化は経済行為となじみが薄いこともあって、一般企業は ディストリビュータをOpen Sourceへの入り口および重要なビジネスパートナーとして認識 し、1998年9月頃から次々と出資および提携を開始した。出資を通して既存の大手企業は、 まずLinuxのサポートビジネスを提供することが可能になった。一方、知名度と信用を持つ (注31) 最近では企業とコミュニティが協力して組み込みOSとしての実用化開発を進めており、 この場合にライセンス問題がどうなるかは注目に値する。 -28- 大手企業の出資を受けたディストリビュータは、Linuxとともに市場での自社の認知度を一 気に向上させることになった。また、いくつかのディストリビュータは、後に株式公開を行 い、莫大な資金を手にした。 Linuxの性能の高さは、企業のネットワーク管理者など一部の人の間ではよく認識されて いたが、サポート企業の不在が企業における普及の最大の阻害要因であった。しかし、大手 企業がサポートビジネスを正式に提供したため、Linuxはビジネス界にも認知され、企業の サーバ用OSに正式採用されるなど、ビジネスユーザが急激に増加した。 表3には、大手企業によるディストリビュータおよび開発コミュニティへの主要な出資お よび提携の一覧を示した。この中には、もともと将来有望なベンチャー企業に出資するコー ポレートファンド活動に力を入れているIntelやHewlett-Packard(HP)のような企業もあれば、 未公開企業に初めて出資したDellもある。また独自のUnixと専用ハードウエアを持つIBM、 SGI、HP、Sun Microsystemsの4社はいずれも出資あるいは提携を行なっている。 -29- 表 3 大手企業によるLinuxディストリビュータへの投資（主要なもののみ） 投資・提携元/時期 IBM Oracle Intel 投資・提携先 備考 98.6 Apache (a) 提携[17] 99.2 Red Hat,Inc.(b) 出資・提携[18] 99.3 Pasific Hitech (c) 提携[18] 99.3 S.u.S.E. 提携[18] 99.3 Caldera Systems 提携[18] 98.9 Red Hat Software 提携・出資（99.6、金額は非公開）[19][20] 98.9 S.u.S.E. 提携[20] 98.9 Pasific Hitech 提携[20] 98.9 VA Research (d) 提携・出資（金額は非公開）[20][22] 98.9 Red Hat,Inc. 出資[21] 99.2 Cygnus (e) 提携・資金援助 99.3 VA Research 2回出資、総額$250万[21] 99.1 Pasific Hitech 出資 S.u.S.E. 英ベンチャーキャピタルのApax Pertnersとあわ せて$1200万を出資 99.12 Netscape Communications 98.9 Red Hat,Inc. 出資[21] HewlettPackard 99.1 Red Hat,Inc. 提携 Novell 99.3 Red Hat,Inc. 出資[18] Compaq Computer 99.3 Red Hat,Inc. 出資[18] Cygnus 99.3 Corel (f) 提携[22] Dell 99.4 Red Hat,Inc. 提携・Dellが未公開企業に出資するのは初 ［23］ SGI 99.6 VA Linux Systems $2500万を出資 Sun Microsysystems 99.8 Caldera Systems 提携 (a) ApacheはLinuxディストリビュータではなく、webサーバ用ソフトウエアとして実質標準のApacheを開発す るOSCであり、webビジネス上注目度が高い (b) 旧社名はRed Hat Software Inc. (c) Pasific Hitech Inc.はのちにTurbo Linux Inc.に改名 (d) VA Research社はディストリビュータではなく、これまで唯一のLinux専用ハードベンダであった。1999年に VA Linux Systems社に改名 (e) μITRONを持つCygnus Solutions社は1999年にRed Hat社に買収された。これによりRed Hat社は組み込み OSビジネスに参入したとされている。 (f) CorelはNetwareで有名なNovell社と関連が深いソフトウエアハウスで、以前からMac/Windows用ソフトウエ アを開発している。これを機に、Linuxディストリビュータにもなった -30- 3.4 大手企業によるLinuxのサポート ディストリビュータへの投資と並行して、大手企業は次々とLinuxへのサポートを表明し た。このサポートは大きく2つに分けられる。ひとつは、自社の持つソフトウエアおよびハー ドウエアををLinuxに対応せること（それぞれ移植と動作保証）、もうひとつは、いわゆる サポートサービスビジネスを行うことである。サポートサービスは、単にLinuxをインストー ルしたマシンの販売から、Linuxと他OS混在環境下でのシステムインテグレーションやソ リューションビジネスまでと、非常に多岐にわたる。 大手企業として、最も早くからLinuxコミュニティと協力的な関係にあったのは、Oracle 社と向けのNetscape Communications社であろう。Ntescape社はLinux向けブラウザソフトウ エアNetscape Communicatorを提供していた。同ソフトウエアのダウンロード数をOS別でみ ると、Linux向けのものが最も多かったという。 大手企業が持つ主要アプリケーションソフトウエアをLinuxへ移植する動きは、1998年の 夏に本格化した。まず企業向けデータベースの分野において、Oracle、Informixなどの大手 が次々と移植を開始した。同年9月にはIBMが年内に移植を終了する計画を発表し、この時 点で、Microsoft以外のすべての大手データベースサーバベンダがLinuxへの対応を発表する というあわただしさであった。 データベース各社に続き、他の分野においてもソフトウエアをLinuxへ移植する企業が相 次いだ。また、Linux上での周辺機器の動作保証を行う企業も現れた。現在、ハードウエア メーカの多くは、動作保証は行わないものの、webサイトなどでLinuxにおける自社製品の動 作状況の情報提供を行っている。こうした企業は、自ら動作試験を行うとともに、ユーザか ら提供された情報をwebサイトに反映させ、ユーザとの間にコミュニケーションを発生させ ている。もちろん、コミュニティは企業の動きに先立ち、どのハードウエアがLinuxで動作 するかという動作実績リストを作成しているが、企業の積極的な対応はユーザグループのメー リングリストにもしばしば報告される(注32)。 Sun Microsystem社はStar Office社を買収することにより、Star Office社がかつて持ってい -31- たオフィス向け統合ソフトウエア（オフィススイート）Star Officeをweb上で無償提供して いる。これはMicrosoftのOfficeの競合品に相当する。ソースコードも公開されているStar OfficeはLinux、OS/2、Solaris、およびすべてのバージョンのWindowsに対応しており、さら にMicrosoft Officeとのファイル互換性がある。 1998年9月初旬に、Linuxのサポートサービスビジネスに最初に参入したのはOracleであっ た。同月下旬にはNetscapeとIntelがディストリビューションへの出資を通じて追随し、1999 年3月頃までには、IBM、DELL、HPなど米大手企業はほぼ全て正式にサポートサービスを 行うと発表した。 日本の大手コンピュータ関連企業は1999年3月頃から、おもに関連会社を通じて試験的サー ビスを開始した。当初、一部の企業は「サポートは行うが動作保証しない」としていたが、 すぐに正式かつ全面的なサービスへと切り替えた。現在ではほとんどの大手企業が、Linux を正式にサポートし、Linuxを含むシステム構築などのソリューションビジネスを行ってい る。 早い段階からLinuxのサポートを表明してきた企業には、既存のOS上で苦戦を強いられて いた企業も見受けられる。データベース分野でのInformix、日本語入力ソフトウエア分野で のジャストシステムなどである。 (注32) もちろん、Linuxのサポートや、積極的な情報提供を行う企業は、一般的にユーザから 評判がいい。こうした企業は、顧客数は多くはないがターゲットを的確に絞った非常に効率 的なマーケティングを行っているとも言える。しかもターゲットは一般ユーザに影響を及ぼ すと言われているAdvanced Amateurで、職場のネットワーク管理などを担当している場合も 多く、ネットワーク構築に関する意思決定権を持つこともしばしばである。 -32- 3.5 企業主導のOpen Sourceプロジェクト 企業が主体となったOpen Sourceプロジェクトは、Netscape Communicationsがまず開始し、 Sun Microsystems、Apple、IBMなどが続いた。これらが正しいの意味でのOpen Sourceか否 かは、各プロジェクトが採用したライセンスがOSI(Open Source Initiative)の定めるOpen Sourceの定義に合致するかによって決まる。Sun、AppleのようにOSIに承認されていない例 もあるが、本稿では企業戦略としてのOpen Source採用という観点から、擬似Open Sourceプ ロジェクトのケースも含めて検討する。 表4に、2000年2月までにOpen Sourceプロジェクトを行うと発表した大手企業とその内容 を掲載した。同年3月の時点では、プロジェクトの成果が不明なものが多く、またその目的 や戦略意図もさまざまであり、企業主体のOpen Sourceに一般的な評価を下すのは難しい。 次項以降では、企業によるOpen Sourceプロジェクトの中から代表的な4つの事例を取り上げ て検討を加えよう。 表 4 大手企業主導のOpen Sourceプロジェクトと開始・発表時期 発表日 企業名 プロジェクトの内容 1998.2.23 Netscape Communications Mozilla.org発足 1998.12.2 Sun Microsystems Java2のOpen Source宣言 1998.12.14 IBM SecureMailerのコード公開 1999.3.16 Apple Mac Server OS XをOpen Source化 1999.4.26 SGI OpenValtをOpen Source化 1999.5.18 Hewlett-Packard Open Source化予定のe-speak発表 1999.10.26 Novell digitalmeをOpen source化 -33- 3.5.1 Netscape CommunicationsのMozilla.org Netscape Communications社は、企業がOpen Sourceを主催する最初の例として大きな話題 になり、企業の目をOpen Sourceムーブメントに向かわせる重要な役割を果たした。 Netscape社は、1998年1月に『Communicator 5.0』以降、製品ソースコードのライセン スを無料供与し、ソースコードをネット上で公開すると発表した。この前後、同社は1998年 4月に行なった正式なOpen Source宣言への準備のために、Open Sourceコミュニティの有力 者であるTorvaldsやRaymondらにアドバイスを求めた。Hamerly=Pazuin=Walton［24］に よれば、同社社員、コミュニティのメンバ、弁護士団がライセンスについて非常に密度の濃 い議論を行なったという。この議論を経て、2月下旬にはMozilla.orgが発足した。hotwiredの 報道［25］によれば、この時点では、 ○ウエブブラウザであるCommunicatorのソースコードをNetscape社の管理から開放し開発 者に委ねる ○Mozilla.orgはCommunicatorの開発を行い、Netscape社からは独立した立場の開発者のため のリソースセンターとしてサービスを提供する ○Mozilla.orgのスタッフやリソースはNetscape社が提供する などの方針が決まっていた。また、クライアント製品グループ担当Hamerly副社長は、「新 しい『.org』サイトは営利団体が所有することになるが、最終的には外部の会社に移行する」 予定、および、「Netscape社はCommunicatorソース開発部隊のひとつに過ぎなくなる。行 く行くは、ネット開発者のコミュニティが発展して成熟し、『Communicator』には外部か ら取り入れられたモジュールが増えていき、Mozilla.orgはコーディネーションを行う代理店 となるだろう」との見通しを述べている。 このような経過でMozilla.orgは1998年4月にOpen Source宣言を行い、Open Sourceコミュ ニティは熱狂的にこれを受け入れた。これを機に、Open Sourceに対する企業の関心は一気 に高くなった。また、コミュニティ側も極めて近い将来のLinuxの商用利用を見越して、高 邁な理想を掲げ持つGNUフリーソフトウエアの思想の一部である反商業的な解釈を意図的 -34- に回避するように、Open Sourceの定義を発表し、OSIを発足させた。 OSIはこのプロジェクトが有するライセンスMozilla Public License(MPL)をOpen Sourceラ イセンスとして承認したが、MPLにはGNUフリーソフトウエアの思想にそぐわない部分が あり、Open Sourceコミュニティの中にはOSIの判断に否定的な態度を取る人もいた。 プロジェクト発足当時のロードマップによればNetscape社は、Mozilla.orgが開発するであ ろう新技術に基づいたCommunicator5.0のベータ版を1998年末にリリースする予定であった。 このベータ版には、ブラウザの中核技術であるレイアウトエンジンに従来のものをそのまま 使う予定であった。しかし、プロジェクト発足後数ヶ月、彼らはMozilla.orgが開発した新エ ンジンGeckoを採用すると方針を転換した。GeckoはNavigatorより非常にサイズが小さく高 速であり、採用するメリットは大きかったが、従来エンジン向けに書かれたソースコードは 無駄になり、そのため開発のスケジュールが大幅に狂ったとされている。同年11月末に America OnLine(AOL)がNetscape社の買収を発表した時、一部でMozilla.orgの独立性や、存 続すら危ぶまれる声があったが、プロジェクトリーダのZawinskiが「MozillaはNetscapeでは ない」とその独立性を強調した［26］。同年12月初めには、Mozilla.orgの成果である新エン ジンGeckoがリリースされ、再び新製品を心待ちにする声が大きくなった。しかし、1998年 末を過ぎ、さらにはプロジェクト発足後1年経った時点でも新製品は発表されなかった。 1999年4月にZawinskiは辞表［27］を公開し、Mozilla.orgが失敗であったと述べた。 1999年中にNetscape社は何度か、Communicator 5.0のリリース予定に関する修正発表を行 なったが、これはいずれも実現しなかった。1999年秋にも、2000年の初めには同製品をリリー スするとの発表があったが、2000年3月現在でもやはりリリースされていない。しかし、 2000年3月に、Netscape社はGeckoを採用したNetscape6をリリースすると発表し［28］、発 足後2年でようやくMozilla.orgの成果が日の目を浴びることとなった。 Mozillaの事例とLinuxの事例との比較は、企業主導のOpen Sourceプロジェクトに必要なマ ネジメントを検討する上で非常に有用であろう。厳密な比較は詳細な事例研究を経て行なう べきであるが、現時点で入手可能な公開情報からマネジメントに起因する失敗の理由をいく つか推測しよう。 Open Sourceにおいては参加者の数が製品の質に大きな影響を及ぼしうるが、Zawinski -35- ［27］によるとMozilla.orgにいた開発者は、Netscape社の社員が100人程度なのに対し、外 部の開発者が30人を超えたことはなかった。Mozilla.orgに参加したNetscape社の社員の多く は、同社の次期製品であるNetscape Communicator4.Ｘの開発を兼任で行っていたことを考 慮すると、100人という戦力は多少なりとも割り引いて考えねばならない。 クローズドを大前提とし内部人材に頼る従来の開発とOpen Sourceでは、当然のことなが ら開発方針がかなり異なるため、そのマネジメントは微妙かつ重要である。しかし、マネジ メントがうまく機能せず、兼任開発者が混乱あるいは板挟みになっていた可能性もある。 Mozilla.orgが発足する以前、「開発者が、バージョン4.06、4.5、Raptorを搭載していないバー ジョン5.0の各ブラウザ、そしてRaptorの4つの開発ラインに分けられてしまった。 ....我々が 4.06と4.5を公開したのち、ようやく5.0とRaptorを統合するとの決定が出た。」 ［29］と指 摘する元従業員もいる。Gecko採用に関する意思決定の混乱も、もともとのNetscape社の開 発方針を整理しきれていなかった状態をそのままMozilla.orgに持ち込んだことが影響したと 考えられる。 外部から人材が集まらなかった点にも注意すべきであろう。MozillaのOpen Source宣言に 対するOSCの反応は非常に好意的であったことを考えると、最大30人という外部参加者の少 なさは意外な感がある。その原因のひとつに、ライセンス問題があげられている。 Hamerly=Pazuin=Walton［24］は、「Navigatorの中に他企業が知的所有権を持つソースコー ドが使われており、Netscape社はその企業に著作権を放棄してもらうよう交渉したが、応じ てもらえなかった。そのため、完全にオープンなライセンスにすることができなかった。い くつかのコードはライセンスの所有者と話し合いがつかず、削除せざるを得なかった。」と している。また、Netscape社のMozilla.orgに対する関与の強さが、束縛を好まないコミュニ ティから敬遠されたとも考えられる。少なくとも、Mozilla.orgのOpen Source宣言に対する コミュニティの反応は非常に好意的であった。 プロジェクト開始当初から、Mozilla.orgの独立性を危ぶむ声はあった。傍観者を含む多く の人が素朴に、「なぜスタッフや管理をNetscape社に？」という疑問を抱いていたのは事実 である。この体制ではNetscape社の関与が強まるだけでなく、開発コミュニティの総意でス タッフを選んだことにはならない。すなわち、「適材的所」のメカニズムが働かなかった可 -36- 能性が高い。また、企業に所属する社員が、バグのあるとわかっているものをリリースすべ きではないという通常の企業責任の概念から逃れることは難しいと容易に想像される。 Mozilla.orgは"Release Early, Release Often"という神髄を発揮できないまま、外部に成果をア ピールできず、開発者が集まらないという悪循環に陥っていたのではないだろうか。 Open Sourceプロジェクトのミクロレベルのマネジメントとは切り離して検討すべきであ るが、AOLによるNetscapeの買収も、Mozilla.orgの進捗を遅らせた大きな要因である。 Zawinskiの辞任の後、「技術で世界を変えたいNetscape社の文化と、単にブランドが欲しかっ たAOLの文化のあまりもの違いに失望」［30］するなどして、Netscape社を退社した Mozilla.orgの主要メンバが相次いだ［30］［31］。Open Sourceプロジェクトと主催企業の 独立性が高ければさほど問題にならないかもしれないが、もともと営利を追求する企業と OSCの文化はかなり異なっている。Mozilla.orgはNetscape社の社員が大多数を占めていたた め、AOLの影響は避けられなかった。 AOLによる買収は想定外であったとしても、Netscape社はOpen Sourceを十分には理解せ ず、それに適した体制を整えきれない状態で、Mozilla.orgを発足させてしまった可能性は高 い。また、開発に関するマネジメントの混乱あるいは不在と、Netscape社とMozilla.orgの分 離が不十分であったことが、開発の遅れを促した大きな原因であると思われる。今後は、コ ミュニティとは乖離した文化と判断基準を持つ営利企業が、自らが主催するOpen Sourceプ ロジェクトにどのように関与していくべきかについてのさらに詳細な分析が要求される。 3.5.2 Sun MicrosystemsのJava2 Sun Microsystems社のJava2(注33)に対しては、開発コミュニティのメンバから、ライセン (注33) Sun Microsystems社の開発したプログラミング言語「Java」の第2版。ネットワーク環境 で利用されることを強く意識している。Javaで開発されたソフトウェアは特定のOSやマイク ロプロセッサに依存することなく、どのプラットフォームでも動作する。Javaで記述された ソースコードはJavaバイトコードと呼ばれる中間形式にいったん変換され、この状態で配布 される。実行時にはJava仮想マシンと呼ばれるソフトウェアによって、そのプラットフォー ムで実行可能な形式(ネイティブコード)に変換され、実行される。どのプラットフォームでも 動作させるために最大公約数的な機能しか使用できないため、プラットフォーム固有の強力 な機能を利用することはできない。このような欠点を補うため、特定のプラットフォームで しか動作しないがその分高速で、プラットフォーム固有の強力な機能を利用できるJava開発 環境を提供しているメーカもある。 -37- スをよりオープンにするようにとの苦言が絶えない。また、標準化作業を共同で行っている 企業も、同様の主張を展開するとともに、標準化を急ぐようSunに再三申し入れを行ってい る。Java2に適用されているSun Community Source License（SCSL）は改良は自由であるも のの商用利用の際にはSunによる互換性試験に合格しなければならず、さらにSunが使用料も 徴収するというもので、Open Sourceと言うより家元制度に近いものである。 コミュニティ参加企業のなかでも標準の制定を強く望む姿勢を示しているIBM、HewlettPackard(HP)、Novell、Intelらは、標準化への作業を続ける一方で独自のJavaコンパイラを 開発し、無償で公開し始めた。例えばHPは、一度は独自に開発したJavaクローンを標準と して提供しようとしたが撤回し、現在では無償で公開してる。IBMもJavaクローンと各種の ツールを開発し、やはり無償で公開している。一方で、彼らはコミュニティと同様、Sunに はライセンスを改訂するよう注文を付け続けた。Javaの標準化は混迷し、1999年12月には、 ライセンス問題が解決できないとしてSunは欧州の標準化団体ECMA(European Computer Manufacturers Association)から仕様を引き上げてしまった。ECMAは、書面でSunのこの行 動を強く非難した。残された企業集団には一旦はSun抜きでJavaの標準化をはかろうとする 動きもあったが、結局Sunに判断を委ねた格好になっている。結論が未だ出ない2000年2月に は、Linuxの有力ディストリビュータ4社が、IBMのJavaツールを正式採用すると発表した。 Open Sourceに対する企業の姿勢の違いが、Open Sourceコミュニティに近いディストリ ビュータを争奪する形で表れている。ライバル企業がコミュニティとその周辺で支持を高め ていくのを見たからか、SunはJavaの開発管理の権利を徐々に開放し、さらに開発環境を Open Source化する計画を発表しているが、Javaコミュニティの要求とはまだかけ離れた状 態にある。 Sunは1999年にLinuxと競合関係にあるSolaris8(注34)のソースコードを公開し、さらに2000 年3月には無償にした。しかし、Solarisのソースコードの一部も他社が著作権を所有するた めSCSLと同様のライセンスを使用しており、完全なOpen Sourceとは言えない。 SunがJavaとそのの標準化を提唱した当時、プラットフォームに依存しない動作が保証さ (注34) SunSoft社(Sun Microsystems社の子会社)が開発・販売しているUnix系OS。Sun 社製のコ ンピュータで動作するほか、PC/AT互換機で動作するバージョンもある。 -38- れるという概念は非常に斬新で、そのライセンスは十分にオープンでなものであった。 Microsoftの支配に疲弊感を強めていたその他の企業にとって、SunとJavaは反Microsoftの旗 手的存在でもあった。こうした企業たちはJavaのライセンスの革新性に大きな期待を寄せ、 「オープンな」Javaを作ろうとの機運に満ちていた。しかし、1998年にビジネス界にもOpen Sourceムーブメント波及すると、Javaのライセンスは一気に「オープンではない」ものとなっ た。Open Sourceライセンスの適用を当然のように要求する企業群と、Java発足当時から方 針をほとんど変えていないSunの間の齟齬は非常に大きいように見受けられる。 3.5.3 AppleのDarwin計画 Apple社は1999年3月にOpen Source計画"Darwin"を発表した。この計画は、Appleの次期サー バ用OSである"Mac OS X Server"の一部をOpen Sourceにしようというものであり、発表の場 にはOSCの著名人も複数参加した。その中でもRaymondは、Darwinが採用したApple Public Source License(APSL)を、「完全にオープンで他社が手本にすべきモデルだと評価した」 ［32］。 しかし、発表の翌日には早速、Perens(注35)をはじめとするコミュニティの主要人物3名か らAPSLについて公開質問状［33］が出された。この質問状は、Appleがライセンスをいつで も撤回できるなどの制限事項があるにもかかわらず、これをOpen Sourceと呼ぶのは不適切 であるなど、数点のAPSLの欠陥を指摘するものであった。Appleはコミュニティと何度か交 渉した後、Perensらに指摘された部分を一部修正したAPSLを、Darwin計画の発表の1ヶ月後 に再発表した。これでOSIから支持は得られたものの、APSLは正式なOpen Sourceライセン スとは承認されていない。 Darwinで公開されたソースコードは、もともとOpen Sourceソフトウエアであったものを 元にAppleが開発を加え製品として発売したもの(注36)であり、Appleによって変更されてい ない部分もAppleの著作権で保護されている。この点を取り上げて、AppleはOpen Sourceに (注35) PerensはRaymondとともにOSIを設立した、OSC の中心人物の一人である。Perensと連 名で公開質問状を出したAkkerman、Jacksonもやはりコミュニティの主要人物である。この 例が示すように、OSの中でもライセンスやビジネスに対する意見は必ずしも一致しているわ けではない。 -39- 深い理解を示していないと指摘する人は少なくない。 Appleは、同社が開設した開発者向けwebサイト(注37)でOpen Sourceを採用した理由とし て、Open Sourceはある種類のソフトウエアの開発に非常に有用であること、多くの開発者 が開発を楽しめる機会を提案したかったことの2点を挙げている。同社はOpen Sourceが一般 に認知されるかなり以前からUnixベースのOSを開発するとの構想を発表しており、1996年 末にNeXT社を買収したことにより、これは実現に向けて動きだした。当時のロードマップ によれば、現在のOS X に相当するOSとして、1997年後半にディベロッパ向けのバージョン をリリースする予定であった。Darwin発足の背景にはOpen Sourceムーブメントの時期が、 ずれこんだこの計画に合致したことも理由のひとつであろう。また、一部に根強い人気があ るものの現在のパソコン市場ではマイナーな存在であるAppleハードウエア向けのソフトウ エア開発者の減少を食い止めたい意図もあったのであろう。Appleによれば、計画発表後1ヶ 月で2万人の開発者が登録したとされる。この数字が正しければ、開発者からの人気は Mozillaと比べて相当高いことになる。また、擬似Open Sourceライセンスであるという理由 で貢献者が減少したとの報告も特に聞かれない。さらに、Open Sourceが一般にも認知され てきたせいか、当時の報道はAppleの決断を概して好意的に伝えた。 このような状況から、AppleのOpen Source戦略は、既存のOpen Sourceコミュニティの優 秀な開発者の取り込みではなく、むしろOpen Sourceムーブメントを利用して、元々熱心な 信奉者(Mac Evangelist)やこのプラットフォームから離れつつある開発者を再度Appleに強く 引き付けるためのものと考えるのが妥当であろう。OSCやビジネス界におけるAppleの好感 度や注目度も上昇したようである。これらがAppleの意図するところであるなら、Appleの戦 略は成功したと言ってよいだろう。AppleはMacOS X Serverの開発は順調だとするが、プロ ジェクトの最終的な結果は今後を待たねばならない。 一方で、Appleは1999年4月にDarwinの一環であるマルチメディアコンテンツ配信ソフト ウエアQuickTimeのソースコードを公開した。OSCはこの公開を好意的に受けとめ、公開か (注36) AppleがこのOpen Sourceソフトウエアを取り込んで開発したソフトウエアをAppleの 著作権で保護しているが、これは元となったソフトウエアの著作権に基づいており、合法で ある。 (注37) http://www.publicsource.apple.com -40- ら3ヶ月足らずでLinux上でも同ソフトウエアが動くよう移植作業を完成させた。Darwinは本 来のOpen Sourceの意義に沿っているとは言えないが、APSL修正への迅速な対応も含め、 Appleのこのような態度は、真の意図はともあれOSCへ一定の配慮と敬意を払ったものとし て評価されてよいだろう。 3.5.4 IBMのOpen Sourceへの取り組み 2000年3月現在で、企業主導のOpen Sourceプロジェクトを最も成功させているのは International Business Machines Corp.(IBM)であろう。IBMのOpen Sourceへの取り組みは、 1998年6月にIBMが自社のアプリケーションサーバWebSphereにApacheをバンドルして販売 し、またOpen SourceであるApache HTTP Projectへ参加することから始まった。IBMは Apacheを採用する代わりに、自社が開発したwebサーバ用ソフトウエアを捨てた。当時の一 般的な企業の幹部は、フリーソフトウエアやOpen Sourceソフトウエアを企業の基幹業務に 用いることに非常に懐疑的という状況においての決断であった。 IBMはさらに、同年12月にSecure Mailerというメールサーバ用ソフトウエアのソースコー ドを公開した。この時点でのライセンスはOpen Sourceの定義に合致しなかったため、 PerensらはIBMにその旨を指摘した［34］。これを受けてIBMはコミュニティの主要メンバ に相談した上でライセンスの修正を行い、OSIから承認を得るに至ったIBM Public License (IPL)をSecure Mailerに適用した。その後ライセンスに関する問題を解決したIBMは、現在 では、主催するOpen Sourceプロジェクトに対しいずれもGPLを採用している。これは大手 企業としては初めてのことである。 IBMは社内にBurbeg［35］を中心とするOpen Sourceを調査する専門組織を新設し、約1年 間かけて徹底的に調査した後にコミュニティへの参加を表明した。Burbegによれば、現在で はOpen Sourceプロジェクト専任のIBM社員もいるという。また、IBMは複数の場で「OSC に尊敬の意を表し、彼らのルールを遵守する」と発言しており、そのことば通り、IBM社員 が開発したApacheなど複数のソフトウエアのソースコードをコミュニティに還元している。 2000年3月現在で、10以上のOpen SourceプロジェクトがIBMのOpen Source向けポータルサ イトα-Works(注38)に登録されている。 -41- IBMはソフトウエアだけでなく、ハードウエアに関する技術も積極的に開示している。表 5にはOpen Sourceに限らず、IBMが技術をオープンにしたおもな例を掲載した。IBMが独自 ライセンスではなく、Open Sourceの中でもフリーソフトウエアの思想が最も反映されてい るGPLを採用した理由、また、技術を公開する理由については、次章において、R&D戦略 やビジネスモデルとの関係という観点から考察する。 表 5 IBMの技術公開にかかわる発表 発表時期 1998.6 1998.12 内容 アプリケーションサーバにApacheをバンドル、Apache HTTP Projectに参加 SecureMailerのコード公開 1999.3 日本IBMがLinuxソリューション提供を発表 1999.5 Deep Computing研究所開設 Visualization Data ExplolerをOpen Source化 1999.6 Linux用Javaツールを公開（ダウンロードは無償） 1999.6 IBM Classes for Unicodeを新ライセンスでリリース 1999.6 1999.7 1999.7 Core Connect発表（バステクノロジー） ライセンス改訂 チップ製造新マスク技術を他社に無償提供する予定を発表 1999.8 Trillianに加入発表 1999.9 Common Program Interface Forum結成 1999.9 開発者向けポータルサイトのα-Works開設 2000.1 エンタープライズサーバ事業部内にLinuxグループ新設、全プラットフォームを Linuxに対応、アプリケーションとミドルウエアをLinuxに移植 2000.1 IBMのJava採用でLinuxディストリビュータ4社が合意 注：網がけのセルはハードウエアに関するもの (注38) http://www.ibm.com/alphaworks -42- 4 企業戦略としてのOpen Source 4.1 ビジネスモデルとR&D戦略の関係∼コア技術とセンター技術 あるビジネスの中心的存在となり、そのビジネスを最もコントロール可能である技術を「セ ンター技術」と定義すると、かつてひとつの理想とされたR&D戦略とは、クローズドなセ ンター技術を自社で独占した上で、可能であればさらにその周辺も何層もの独自技術で固め たものであった。この場合、企業はセンター技術をはじめとして、そのビジネスに関するほ とんどの技術をコントロールしながらビジネスモデルを構築することが可能である。その企 業のコア技術がセンター技術に一致しているか、あるいはコア技術とセンター技術を組み合 わせれば、ビジネスモデルはより強固なものとなる。また、基礎的フェーズから研究開発を 行っていれば、やはりそのビジネスに関連する技術へのコントロールや独占の度合をより高 めることができる。いずれの場合も莫大な収益を得ることが可能なため、企業は典型的なセ ンター技術である標準の獲得をめざし、あるいは基礎的なフェーズから技術を築き上げるべ く、自前の資源で、クローズドかつ独自のR&Dを行うべく努力を重ねてきた。 しかし、一社でこのようなR&Dを行なうには、非常に多くの資源と時間を要する。過去 の標準をめぐる競争においては、独占を追求した結果不採用になった時のリスクは非常に高 く、また、企業は長期的に消耗戦を強いられることが少なからずあった。さらには、技術的 に優れたものがセンター技術となる保証もない。このような過去の事例からの学習が、多く の企業に協調的なリスク回避行動を取らせ、標準制定にはコンソーシアムや提携などの「仲 間づくり」戦略が採用されるようになった。コンソーシアムをコントロール可能なごく一部 の企業にとっては、独占という最大のリターンは得られないが、仲間を集めることによりセ ンター技術を獲得できないリスクはかなり小さくなる。一方、自力でセンター技術を立ち上 げる力がない企業にとっては、コンソーシアムに加入することにより、利益は薄いが自らの 経営資源をさほど消費せずにそのビジネスに参入する権利が得られる。 こうして標準化が進めばビジネス規模は巨大化する。また、単にモノやサービスの単純な -43- 販売だけでは収益が得られなくなった企業は、より複雑化、システム化したビジネスモデル を追及するようになる。この進化したビジネスモデルは、技術の複合化、システム化をも促 し、企業に従来よりも多数の技術をより速く確立するよう要求した。しかし、このような巨 大で複雑なビジネスに必要な技術を1社のみで提供するのは難しく、企業は外部組織との何 らかの連携を必要とする。典型的であるのが、パソコンビジネスにおけるMicrosoft社および Intel社と、その周辺でビジネスを行っているソフトウエアハウスやハードウエアメーカとの 関係である。Windowsがこれだけの売上規模を達成するには、ハードメーカはもちろん周辺 機器やネットワークインフラなど、Microsoftが単独では提供しきれない製品とビジネスが必 要であった。すなわち、周辺ビジネスを行なう企業は、センター技術を所有せずとも、セン ター技術を所有する企業との補完的な関係の構築により、収益の獲得が可能になった。しか し、やはり彼らは、センター技術を持つ企業が構築したグランドモデルの周辺部に組み込ま れたに過ぎず、ライセンス料などの「しょば代」はその収益性を圧迫する。他社にコントロー ルされたセンター技術に自社のコア技術を組み合わせた収益性の高いビジネスモデルを築く ことは難しく、収益はセンター技術の所有者に集中しがちである。 一方、最近ではセンター技術の所有を当初から放棄したビジネスモデルが増えつつある。 例えば、webのアクセス履歴から個人の嗜好を推測し、最適の広告を提供するOne to One Marketingでは、顧客はブラウザを、マーケティング側はデータベースを用いるが、双方と も実質上の標準となっているのは無償で公開されているソフトウエアである。ブラウザとデー タベースの技術の間には大きな隔たりがあるため、両者を結びつける、アプリケーションサー バというミドルウエアの一種の技術が必要となる。IBMはアプリケーションサーバビジネス の有力なプレーヤの1社であるが、IBMにおいてミドルウエアで活躍しているのが、一度は 競争力を失ったとされるメインフレームである。 このビジネスにおいては、図6に示すようにセンター技術とコア技術は一致せず、データ ベースもwebブラウザもOpen Sourceであるものが提供されている。このようなビジネスモ デルを構築している企業にとって、センター技術がオープンであることはむしろ都合がいい。 -44- アプリケーションサーバビジネス メイン フレーム は個々の技術を表す web センター技術 DB コア技術 コアではない社内技術 図 6 センター技術とコア技術が一致しないビジネスモデルの例 ライセンス料を支払う必要もなく、たとえ技術が変更されてもその内容をすべて知ることが できる。それどころか、場合によっては内部資源を消費することなく、外部資源による技術 の向上までもを期待できる。Microsoft支配の下で、センター技術と自社の強い技術を組み合 わせるビジネスモデルを構築せざるを得なかった彼らにとって、Open Sourceソフトウエア を用いたビジネスモデルを受け入れる体制はすでに整っており、また他社が所有するセンター 技術を使うよりはOpen Sourceの方がはるかに好ましかったことになる。このような理由で、 企業は続々と「無償の」Open Sourceへ関与していったのであろう。 Open Sourceに取り組む企業にとって、センター技術を所有せずともコントロールする手 段が、ディストリビュータと開発コミュニティへの出資・提携であろう。コントロールが可 能な範囲と与えうる影響はセンター技術の所有者に比較してかなり小さいが、センター技術 の所有には、前述した大きな負担とリスクを負わなくてはならない。少なくともコンソーシ アムに隷属的に参加せざるを得ないような企業にとっては、ディストリビュータへ出資する 方が、まだビジネスをコントロールできる余地があるだろう。Open Sourceソフトウエアか ら直接的に収益を得るのは不可能であるが、オープンだからこその利点も多数存在する。例 えば、技術の中身は全て公開されており、理解が容易である。また、魅力ある技術ならば開 発者が多く集まり、開発の所要時間と人件費を節約することができる。ユーザの数が多けれ ばビジネス規模の拡大につながりやすく、Open Sourceを採用している企業に対してはユー -45- ザの評価も高い。Open Sourceに関与している企業は、センター技術をOpen Sourceに「借り」 たビジネスモデルと、独自のセンター技術を所有するビジネスモデルのそれぞれの投資リス クと期待収益を考慮した上で、Open Sourceを選択したのであろう。 Open Sourceに関するビジネスモデルをすでに学習した企業の中には、前章で取り上げた IBMのように、将来センター技術になり得る技術を開発初期段階からオープンにするものも 現れた。彼らの戦略は、携帯電話を無料で配布し、自社の通信網に顧客を組み入れ通話料を おもな収益源とする戦略とよく似ている。携帯電話モデルよりさらに優れているのは、オー プンな技術を多くの人の目に触れされることにより、外部資源による品質の向上やビジネス の拡大が期待できる点である。オープン化の流れを利用した、巧妙な誘導と囲い込みの戦略 と言えよう。しかし、パートナーや顧客をタイトに囲い込もうとはせず、企業間の関係が従 来よりゆるやかで柔軟である点が従来の囲い込み戦略とは異なる。 4.2 R&Dにおける外部資源の利用 コア技術とセンター技術が一致しないビジネスモデルを選択すれば、センター技術を外部 調達せざるを得なくなる。ここで、企業間の関係性のオープン度と技術のオープン度に着目 して、技術の外部調達を図7のように分類してみよう。図7における縦軸は多組織間で行われ る協力的R&Dの対象となる技術が、参加者の間でオープンかクローズドか、また、横軸は 協力的R&Dを行なう組織の関係がオープンか限定的か（あるいは不特定多数か特定少数か） を意味する。 センター技術の所有を前提とするビジネスモデルの時代にも、外部資源を利用したR&D は行われてきた。一社の中でクローズドかつ独占的に行われてきたR&Dを、図7のIIのよう に限定された企業間の関係の中で技術をオープンにするか、またはIIIのように技術をクロー ズドのまま広く一般の企業にライセンス供与を行う形で発展させるというものである。従来 は、内部技術と資源を中心に据え、あくまでそれらを補完する、あるいは自社が保有してい ない分野の技術を外部から調達するケースが多かった。しかし最近では、投資額の増大や加 速する事業スピードに社内のR&Dが立ち行かなくなるのを見越して、極めて早い段階から -46- 外部資源を戦略的に利用する、自社と同分野の技術や資源を外部に求める例が増加している。 すなわち、図7における実線の矢印が示すように、内部と外部の区別が従来より薄れるよう な外部資源の利用が増えている。 技術 open (white Box) II I 系列 共同研究 アライアンス Open Source 企業間の関係 open (不特定多数） closed (特定少数） 標準存在下での ライセンス ビジネス 一社独占 III IV closed (black Box) 図 7 外部資源を利用したR&Dの分類 図7のIに相当する企業が行うOpen Sourceプロジェクトは、技術と、R&Dパートナーとの 関係（あるいは企業間の関係）の双方をオープンにしたという点で、過去にはなかった新し い類型である。企業が特定の個人と共同研究を行なったり、不特定多数からアイディアを募 るという例は過去にもあったが、不特定多数の個人とのR&Dにおける協業は全く新しいケー スである。 なお、収益確保のためはクローズドな方向に戻らざるを得ないので、企業が取りうるR& D戦略は、対象となるビジネスの局面によって、図7における点線の矢印が示すように各象 限を移動するというダイナミズムを持っている。 -47- 4.3 Trillianプロジェクトの事例 Trillianプロジェクト(注39)とは、Intel社が開発したサーバ/ワークステーション向け次期64 ビットプロセッサItanium上で稼動するLinuxを開発しようと複数の企業とOSCによるOpen Sourceプロジェクトである。プロジェクトの発足は、1999年4月である。 2000年2月2日現在のTrillian参加メンバーは、Intel、VA Linux Systems、SGI、HewlettPackard(HP)、IBM、欧州素粒子物理学研究所(CERN)、Red Hat (Cygnus)、S.u.S.E.、 Turbolinux、Caldera Systemsである。このうちIBMは1999年8月に、ディストリビュータ4社 は1999年12月に参加を発表した。この4社はいずれも大手で、4社の合計で1998年のLinux世 界出荷金額の76%を占めた。VA Linux Systems（旧VA Research社）は1993年からLinux向け ハードウエアの販売を行っており、Linux企業としては長い歴史を持つ。また、SGI、HP、 IBMの3社はいずれも独自のUnixと専用のハードウエアを販売している。 TrillianはGPLを採用しており、ソースコードは一般にも公開されている。上記企業の他に、 OSCから個人として開発に参加しているプログラマもいる。 過去にUnixの分裂をめぐって激しい争いをしてきた企業が一堂に会して共同研究を行って いる事態を、業界は驚きをもって迎えた。中にはOpen Sourceの思想があったからこそ可能 になったとOpen Sourceを手放しで評価する人もいる。しかし、過去にも競合関係にある複 数の企業による協調的な研究開発は存在した。 Mowery=Teece［36］によれば、過去15年間に、国内企業同士のprecommercialな研究コ ンソーシアム、産学協同研究、国際間の戦略的提携の3つの形の協力的な関係が研究開発に おいて発展した。ここで、Mowery=Teeceによる従来の協調的な研究開発の比較項目を借り て、Trillianの戦略的意義を考察してみよう。表6はMowery=Teeceの記述を筆者がまとめた ものである。また表7は筆者による従来のコラボレーション/コンソーシアムと、企業による Open Sourceプロジェクトの比較である。 (注39) http://www.linuxia64.com/ -48- 表 6 研究開発における企業の協力的な関係の比較 協力対象分野 対象技術の性質1 対象技術の性質2 目的 コンソーシアム 研究 precommercial 特定の製品に 関らない 一企業では行い難い 長期的研究 戦略的提携 開発、生産、 マーケティング commercial 特定の製品に 関る 特定の技術標準による ビジネス支配 Trillian 開発 commercial 特定の製品に 関る 早期標準確立によるビ ジネス支配？ 表 7 研究開発における企業の協力的な関係の比較 項目 従来のコラボレーション/ コンソーシアム 企業によるOpen Source プロジェクト パートナー 特定少数 （企業がほとんど） 不特定多数（コミュニ ティ、個人...） 時間の節約 有効 非常に有効 費用の節約 有効 有効 消耗的競争の回避 有効だが、時に 激しい消耗戦に 消耗的競争とは あまり関係なし 戦略グループの形成 （潜在的ユーザの増加） 可能 非常に有効 企業イメージの向上 無関係 非常に有効 パートナーのコントロール 可能かつ比較的容易 時に非常に困難 技術的補完の目的 重視し、 また達成されやすい 重視しない 技術の独占 可能（一企業より可能性が 高い） 不可能 技術の標準化 可能 標準化は比較的容易 技術からの直接収益 可能、時に非常に高収益 不可能 Grindley［37］は、precommercialな研究コンソーシアムとして有名なSEMATECHの会員 企業間の一致した見解として、特定の製品技術ないし製法技術に焦点を当てた研究テーマは 不可能ではないまでも難しいとする。Trillianの場合は特定の製品に対する技術の開発であり、 その目的は非常に明解である。また、対象技術から収益は得られないものの、既にビジネス に取り入れられている技術を扱っており、対象技術はcommercialの性質を持つといっていい -49- だろう。Trillianに参加した企業はすべて米国企業であるが、これが意図されたものか偶然か は不明である。これらの比較および、「特定の技術標準を背景とする優雅な時流を作り出そ うとする［37］」とされる戦略的提携の一般的な目的と合致しているであろうことから、 Trillianはコンソーシアムよりはむしろ戦略的提携に近いと考えられる。しかし、従来の戦略 的提携の副次的効果とされる相手企業からの学習はほとんど期待していないであろう。 Open Sourceである以上、プロジェクトに参加せずとも技術的な学習は可能だからである。 Itaniumは1994年に発表されて以来、開発が遅れに遅れたチップである。2000年1月には、 Crusoeという全く新しい設計コンセプトのチップがTransmeta社から発表され、従来のチッ プを駆逐するのではないかと大いに期待を集めている。これを生産しているのが、Crusoe向 けの新しい生産技術を持つIBMであり、IBMがTrillianに参加した時点では、すでにCrusoeの 存在を知っていたことになる。さらに、IBMはItaniumの競合製品となる独自のチップ Power4も、2000年3月に発表している。それにもかかわらず古いチップに投資を行うのは、 次世代のサーバビジネスにおいてLinuxを標準技術にするメリットを見出しているからであ ろう。 しかしながら、技術をオープンにしてしまえば、標準は確立できてもライセンスビジネス は成立しなくなる。それでもLinuxを採用したのは、サーバ市場においてUnixより高い成長 率を持つWindows NTを提供するMicrosoftの支配を避けたいという、参加企業に共通した認 識があったからでもあろう。Open Sourceの手法を使えばコミュニティという外部資源を利 用してより速く標準技術を確立することができ、それにより産業構造の成立のプロセスを、 参加企業に有利になるようにコントロールすることが可能になる。参加ディストリビュータ は、いずれもLinuxビジネスにおいて既にIBMあるいはIntelと提携関係にあることに注意す べきであろう。 技術をクローズドにするタイプの提携においては、共同開発の対象となる技術そのものの 競争優位は保たれ収益を上げることができるが、産業に及ぼしうる影響力は比較的限定され ている。一方Open Sourceを採用すれば、対象技術そのものから収益はあげられないものの、 その技術のユーザが一気に広がる可能性がある。 すなわち、企業はOpen SourceのR&Dプロジェクトとしての優秀さを認めながらも、決し -50- て手放しで賞賛するだけではなく、巧みに企業戦略の一環に取り入れていると考えられる。 共同で開発し、技術を一般に公開しても、独自にクローズドで開発するよりはより期待収益 が高いと参加企業は判断しているのである。オープン化/マルチプラットフォーム化が進んだ この分野においては、センター技術から直接収益を得るビジネスモデルは既に有効ではなく、 Open Sourceに関与する企業は新しいビジネスモデルを確立しているからであろう。 4.4 Open Sourceライセンスとビジネス Linuxと同様におもにIBM PC互換機上で稼働するUnix互換のOSにFreeBSDがあるが、両 者の性能は一般にほぼ変わらないか、あるいはFreeBSDの方がより優れているとの声もある。 しかし、ビジネス界においてはLinuxの方が圧倒的に認知されている。マスコミに取り上げ られた経緯なども注目度の差に大きな影響を及ぼしているのは確かであろうが、ここで両者 のライセンスを比較してみよう。 表8に、Perens［3］による擬似ライセンスを含む各Open Sourceライセンスの比較表を転 載した。 表 8 オープンソースライセンスの比較 License 非フリーソフトウ エアへの組み込み 可否 変更部分の非公開 および作者への非 還元の可能性 誰によっても再ラ イセンスできるか 原著者には、変更 部分に適用される 特別な権限がある GPL no no no no LGPL yes no no no BSD yes yes no no NPL yes yes no yes MPL yes yes no no Public Domein yes yes yes no ここで最も注目したいのは、GPLが変更部分を非公開にすることを禁止している点である。 GPLは、元のソフトウエアを一部含む、または元のソフトウエアから派生したソフトウエア -51- を頒布する場合は、同じGPLの下にソースコードを公開することを義務づけている。Apple やSun Microsystemsのような擬似Open Sourceライセンスを適用している企業は、大量かつ 優秀な外部資源を無料で利用することにより得た成果の知的所有権を自分のものにすること が可能である。また、そこから独占的な利益を得ることもできる。一方で彼らは、コミュニ ティから批判を受けたり、協力が得られなくてもやむを得ない。しかしながら、独占的に保 有する競争優位のある知識を、ライバル企業による模倣を恐れて知的所有権で保護しそこか ら収益をあげるという考え方は、従来のビジネスにおいては極めて常識的な発想であろう。 模倣されまいと、自分たちは用いる可能性は少ないがライバル企業が出願するであろう技術 をあらかじめ想定して、本命の技術とほぼ同時期に知的所有権の申請を行うという「特許戦 略」を、極めて有効に用いてきた企業もある。 LinuxとFreeBSDのライセンスにおいても最も異なるのは、やはり派生物に対する態度で あろう。FreeBSDのBSDライセンスは、派生的物の広告に、カリフォルニア大学バークレイ 校で開発されたソフトウエアを含んでいる旨の告知を入れなければならないという制限が加 わる(注40)ものの、派生物の公開と著作権者への還元を義務づけてない。また、BSDライセ ンスはソースコードをフリーでないソフトウエアに取り込んで利用することを許している。 よって企業は、BSDライセンスのソフトウェアの変更部分を非公開にした上で、独占的に販 売することが可能となる。これでは恐らくTrillianのようなプロジェクトに積極的に参加する 企業は現れないであろう。 Unix分裂の歴史を経験しているだけに、分岐バージョンに対する企業からの警戒も強いは ずである。GPLが適用されているLinuxの分岐の可能性は非常に低い。Linuxの正式バージョ ンを承認できるのはTorvaldsだけであり、それ以外は非公式バージョンである。仮にLinuxの 非公式バージョンを作成し商用利用したことが知られれば、作成者は倫理的にコミュニティ にいることができなくなり、Linuxに関するその後の経済活動が一切絶たれることになる。 BSDコミュニティにも正式バージョンを承認する同様の権限はあるが、コミュニティの意思 にかかわらず、前述のようにBSDの別バージョンの作成はライセンス面から可能である。 GPLとBSDにはそれぞれ長所と短所があるとされているが、企業がOpen Sourceを行なうに (注40) 現在は、この宣伝条項を含まない新しい BSDライセンスが存在する。 -52- 際して都合がいいのは、派生物の公開の義務があり、分岐の可能性が極めて低いGPLなので あろう。 では、企業はどんなリターンを期待してGPLを適用し、技術を公開し続けることを選択し たのであろうか？GPLを課されたソフトウエアから直接利益を得ることは不可能である。し かしながら、他社の模倣による収益機会はほぼ防ぐことができるはずである。元となるソフ トウエアのソースコードを全く使わず同様のソフトウエアを開発するのは、費用対効果が低 いであろうし、流用すればGPLによって公開しなければならないからである。それどころか、 GPLを適用していれば、他企業が開発した成果物を元の企業が利用してもまったく問題ない。 いったん公開するという決断を下すことができれば、それ以降に発生するデメリットはほと んどないことになる。GPLを適用した公開技術と、自社が保有する非公開かつ高い競争力を 持つ技術（時にはコア技術）を組み合わせて競争優位を有するビジネスモデルを構築するこ とができれば、表7に示した企業によるOpen Sourceプロジェクトのメリットをほぼ全面的に 享受することが可能になる。さらに、公開技術が基盤技術のように広く用いられる性格のも のであればユーザは必然的に増えるので、そのビジネスモデルは従来の非公開技術を中心に したものより競争優位を持つようになる可能性がある。 シャピロ=バリアン［38］は「オープンな標準を管理するにはスポンサーが必要」であり、 「分裂や粉砕といった目に遭いやすい」としている。Linuxに関与する企業は、オープンな 標準の複雑でわずらわしい管理をコミュニティに任せたと考えれれる。そのいくばくかの代 償としてコミュニティに資金援助を行い、自社の人材を提供している。OSCにおいては、 Open Sourceソフトウエアのビジネスにおける利用を望んではいるが、積極的に関与しよう とはしていないという意見が大勢を占める。Unixの分裂を経験した企業は、分岐を嫌うOSC の文化と、Linuxに適用されているGPLがあれば、いつ崩れるかわからない企業間の協調的 関係で標準のコントロールを行なうよりは安全と判断したのであろう。 -53- 4.5 企業によるOpen Sourceに必要な条件 本節ではこれまでの議論を整理し、企業がOpen Sourceを採用する理由と、企業による Open Sourceプロジェクトがビジネスとして成立しうるを仮説として提出する。なお、この 仮説は、完全なOpen Sourceでなくとも、IBMによる技術公開のようなオープンなR&D戦略 にもほぼそのまま適用できると考えられる。 まず、企業がOpen Sourceを採用するメリットは、自社内のクローズドな開発と比較した 時の開発のスピードと質の高さ、および社内リソースの節減であろう。一方デメリットは、 一様に動機づけられているわけではない外部人材に頼らざるを得ないため、プロジェクトの コントロールやマネジメント、スケジュール管理が困難な場合があることであろう。 Open Sourceプロジェクトの対象となるのは、多くの人が使う技術、インフラ的な性格を 持つ技術（あるビジネスのセンター技術）であろう。使用が予想される人数が多い技術ほど、 オープンにする価値はあるだろう。IBMのBurbeg［35］は技術を、Operating System、 Systrem Service、Application Middleware、Application Softwareの4つに分類し、Operating SystemおよびSystrem Serviceに関してはOpen Sourceが有効であるが、Application Middlewareは不明、Application Softwareでは少なくともここ10年はOpen Sourceによる大き な動きはないであろうとの見通しを語っている。 R&D戦略の観点からは、一社でR&Dを行うには何らかの不都合が生じる場合にOpen Sourceを選択する可能性が出てくる。具体的には、一社では負担しきれないような多額の投 資が必要な場合、技術の難易度が高すぎるあるいは技術の範囲が広範なために一社による R&Dでは成功確率が著しく低い、あるいはビジネスのスピードが非常に速く一社によるR& Dに頼っては機会損失する可能性が高い場合などが考えられる。 事業戦略の観点からOpen Sourceの採用を推進するのは、他の戦略グループとの競争を有 利に進めるために、対象となる技術の立ち上げが最優先事項である場合、またそのビジネス の性格上、規模の確保が成功の決定要因である場合があげられる。後者は従来の標準化・規 格化競争と本質的に同じ性格を持っており、潜在的なユーザでもある仲間をいかに増やすか -54- が焦点となる。Open Sourceを採用すれば、センター技術のR&Dを外部にまかせ、自社のリ ソースを関連したコア技術のR&Dに振り向けること、また、標準化あるいは産業構造の確 立のプロセスを自社に有利に進めることが可能になる。 Open Sourceプロジェクトから投資を回収できる必要条件として、さらに、コア技術を組 み合わせたビジネスモデルの確立があげられる。典型的であるのが、サービスを顧客とのイ ンターフェースに置いたビジネスモデルであるが、このサービスのビジネスモデルがハード ウエアおよびソフトウエアの競争力の喪失を経て出現するのであれば、Open Sourceの対象 となる技術はブレークスルーの性質を持つ必要はなく、むしろ従来の技術ロードマップの延 長上にある成熟度の高いものが多くなるだろう。今後企業によるOpen Sourceが戦略として 一定の評価を得たとしても、真に革新的・破壊的な技術を当初から企業が公開するとは考え にくく、非コア技術であり上記の事業戦略の観点から普及を第一の目的とするものなどがあ げられる。 企業がOpen Sourceプロジェクトを成功させようと考えるなら、コミュニティの文化に対 する理解と尊重は必須である。既存のR&D組織/マネジメントとOpen Sourceプロジェクトは、 しっかり分離した方がよい。Open Sourceプロジェクトを、従来の企業の価値基準を用いて 評価しても意味がなく、多くの場合、事態は悪い方向へ動くであろう。どのような理由があ ろうとも、企業としてのOpen Sourceプロジェクトへの関与は慎重に行うべきである。また、 Open Sourceライセンスにはいくつか種類があるが、どれを適用するかは対象技術を用いる ビジネスの戦略に応じて検討すべきであろう。 企業主催のOpen Sourceプロジェクトが増えれば、有限である優秀な開発者の争奪戦が始 まり、プロジェクト同士が競争せざるを得なくなる。すなわち、これまではせいぜい当事者 間での評価しかなされていなかった企業のR&Dプロジェクトが、不特定多数が自由に出入 りする外部市場で評価されるという事態が生じる。 -55- 5 新しいR&D戦略に向けて ビジネスモデルの変化に応じて、R&D戦略も変化する。ビジネスモデルの過渡期にあた る現在は、ひとまず新しいビジネスモデルへの移行を遂げた企業が好調な業績を挙げている ように見える。しかし、ある環境に適したビジネスモデルが普及すれば、同じモデルにおい ての同質的競争が始まる。サービスそのものは模倣されやすく、何をもって差別化するかが 競争の鍵となる。サービス指向のビジネスモデルにおいては、技術やR&Dの重要性が薄れ たとの指摘もあるが、従来のように製品や技術的効能を前面に押し出した競争ではないので、 外側から技術が見えにくくなっているだけである。むしろ、競争はより複雑になっている。 競争優位のある技術、独自の技術が差別化に有効であること自体は変わらない。しかし、競 争力のあるビジネスモデルは、複数の技術の高度な組み合わせによって成立している。こう した技術を一企業が単独で開発したのでは、ビジネスチャンスを逃すのは明白であろう。 このようなビジネスモデルを構築するには、R&Dにおける外部資源の利用がますます重 要になる。ビジネスモデルとの整合性、および、短期と長期、オープンとクローズド、社内 と社外など、性質が異なるものの「組み合わせ」の視点がR&D戦略に必要になるだろう。 まず、自社の強みを十分に発揮できるような技術の選択が必要である。強く魅力的な技術 があれば、世界中から優秀な人材が勝手に集まってくる。オープンであればなおさらである。 強い技術は、強い相手と組むパスポートとなりうる。 次に、以下のふたつの意味において社内人材の囲い込みにこだわらないようにすべきであ ろう。積極的な外部人材の登用と、社内の（特に優秀な）人材のオープン化である。非常に 優れた人材はそう多くは存在せず、またLinuxの事例でみたようにひとつのプロジェクトに 多数必要なわけではない。一社で大きなビジネスを独占するのはほぼ不可能である以上、大 きな可能性を持つビジネスに関する企業間の協調的なプロジェクトなどの機会があれば、優 秀な人材を参加させることは、産業全体はもちろん、センター技術のコントロール権限が強 くなるので、その企業にとっても利益をもたらすであろう。そのような人材を社内に囲いこ んでセンター技術のR&Dが遅れ、ビジネスチャンスを逃すより、積極的に開放してR&Dに -56- あたらせ、その間に自社はセンター技術とコア技術の組み合わせで他企業に競争優位を保て るような戦略立案や、そうしたコア技術のR&Dに専念した方が効率的なケースが増えるだ ろう。研究成果についても、人材と同じことが言える。自らが人材や研究成果をオープンに すれば、外部の資源もより簡単に利用可能になる。Open Sourceはオープンリソースにつな がるのである。この場合には、オープンにすべきものとクローズドにすべきものの適切な選 別が戦略の成否を分ける。 3つめは、技術の組み合わせに関する戦略である。技術の成熟度に応じてビジネスモデル や企業間の連携の形態も変わるであろう。成熟度が高い技術を中心としたビジネスほど、他 企業との分業、協業が必要になってくる。自社でコントロール不能になったセンター技術に、 どのようにコア技術やさらに外部の技術を組み合わせて、ビジネスモデルを構築すべきであ ろうか。 社外の研究成果を吸収・活用するには、社内のR&Dに対する補完的な投資やマネジメン トが同時に必要だという一連の研究がある。また、Veugelers=Cassiman［39］は「R&Dに ついて社外情報より社内情報を信頼する企業は、そうでない企業が社内R&Dまたは外部調 達のどちらか一方を選びがちなのに対し、双方を組み合わせる戦略を取る傾向があり、外部 調達した技術を吸収するには社内のR&Dが必要」とする。これらは、外部技術に過度に頼 る危険性を示している。従来は「製品の市場投入までのスピードは、過去の技術的知識が貯 えられた会社の貯蔵庫から知識を引き出す開発チームの能力に依存［40］」していたが、こ れからは組み入れるべき社外の技術に対しても配慮する必要が生じる。 また、短期的な収益がこれまで以上に重視され、R&Dにおいてもフレキシブルな外部資 源の調達が要求される一方で、「プロトタイプシステム構築に使える構成替えの容易な技術 のプラットフォーム（技術の集合体）は、技術への継続的な投資から生まれる［41］」よう に技術には蓄積が必要であるから、R&D戦略の一部はある程度長期的にならざるを得ない。 短期的な収益を追求し、技術の外部調達に力を入れすぎれば、長期的には総合的なR&Dの 能力が低下するかもしれない。R&D戦略と企業戦略の統合の重要性は以前から指摘され、 今後さらに切実なものになっていくだろうが、R&Dの長期戦略はおそらくビジネス戦略と の調整を最も必要とされるだろう。 -57- 6 おわりに 本稿では文献よりOpen Source Communityの組織構造とR&Dプロジェクトとしての優秀性 を検討した。また、企業が、Open Sourceを含めたR&Dにおける外部資源の利用を行う際の 条件を仮説として提出した。また、企業によるOpen Sourceの事例を通じて、外部資源を利 用した企業のR&Dシステムの未来を議論した。 今後はインタビューやフィールドワークを通じたより緻密なOSCの分析を行い、本稿での 検討の信頼性を高めるとともに、企業のOpen Sourceに関する事例を追跡検討し、仮説を検 証しながら理論的研究へと発展させることが要求される。また、極めて近い将来に、Linux の組み込み用途開発が本格化すると思われる。組み込みOSとしてのライセンスのあり方や、 企業間の学習と戦略の変化、家電製品において圧倒的なシェアを誇るTRONとの比較などは 興味深い課題である。 企業のR&Dは、閉じられた企業の内側のみで行われるのではなく、他企業、大学、コミュ ニティ、個人との多彩な共同作業によるものになっていくだろう。主体となる組織は、不定 形でテンポラリな新しい共同体である。Rある企業に所属しながらも他企業のプロジェクト に参加したり、特定のプロジェクトのみに参加する短期間の契約を結ぶなど、&Dプロジェ クトへの参加形態や関与の仕方も多様化するであろう。 まだ論として不十分な点はお許し願いたい。また、誤りがあるとすれば、すべて筆者に帰 するものである。不備は承知していたが、Open Sourceの精神にのっとり、すばやいリリー スを優先した。peerだけでなく、様々なお立場の方から忌憚ないreviewをいただければ、ま ことに幸いである。 謝辞 Open Source Communityの議論に多大な示唆を与えてくれた趙 東一氏に深く感謝いたします。 -58- 参考文献 ［1］Crocker，「デヴィッド・クロッカーと電子メールの発展」，インターネットヒスト リー，オライリー・ジャパン(1999)． ［2］Free Software Fundation：http://www.gnu.org/philosophy/free-sw.html，What is Free Software?，1999年9月10日アクセス． ［3］Perens："The Open Source Definition"，http://www.hams.com/OSD.html，2000年1月10 日アクセス． ［4］OHPA(Open Hardware Palmtop Computing Association)：http://www.morphyone.org/ ， Morphy One- The world's first open hardware palmtop PC! ，1999年12月24日アクセス． ［5］Chandler，経営戦略と組織，実業之日本社（1967）． ［6］Raymond，"The Cathedral and the Bazaar"，http://www.tuxedo.org/~esr/writings/ cathedral-bazaar/，1999年9月10日アクセス． ［7］「商業的でない開発スタイルこそ本来のあるべき姿だ」，日経コンピュータ別冊 企 業ユーザーのためのLinux完全ガイド，日経BP社，1999年． ［8］Raymond，「オープン・ソースとLinuxが企業システムに与えるインパクト」，日経 Linux発行記念講演会での質疑応答（日経ホール），1999年5月26日． ［9］Raymond，"Homesteading the Noosphere"， http://www.tuxedo.org/~esr/writings/ homesteading/，1999年9月10日アクセス． ［10］Torvalds，「Linuxの強味」，オープンソースソフトウエア，オライリー・ジャパン (1999)． ［11］Merton，社会理論と社会構造，みすず書房（1961）． ［12］奥村昭博，「経営戦略と組織」，企業戦略論，有斐閣（1996）． ［13］野中・竹内，知識創造企業，日本経済新聞社(1996)． ［14］Brooks，人月の神話，アジソン・ウェスレイ・パブリッシャーズ・ジャパン(1996)． ［15］Vixie，「オープンソース開発におけるソフトウェアの工学的側面」，オープンソース ソフトウェア，オライリー・ジャパン(1999)． ［16］加藤みどり，「サービス化戦略のパラダイム」，サービス経営，同友館(1999)． ［17］IBM，"Move Helps Companies Turn Simple Web Sites Into Powerful By Month"， ebusiness Solutions，1998.6.22 -59- ［18］Dow Jones Business News，"IBM，Compaq, Novell Buy Interests In Linux Distributor Red Hat"，1999.3.9． ［19］M2 PRESSWIRE，"Oracle expands commitment to Linux"，1998.9.8． ［20］The Wall Street Journal，"Investments in Linux Operating SystemTo Be Announced by Some Key Firms"，1999.3.1． ［21］Dow Jones Online News，"Intel, Netscape Invest In `Freeware' Concern Red Hat"， 1998.9.28． ［22］M2 PRESSWIRE，"LINUXIT： LinuxIT announces agreement between Cygnus and Corel Corporation to port Corel software to Linux"，1999.3.12． ［23］The Wall Street Journal Europe，"Dell Takes Stake In Linux Developer Red Hat Software"，1999.4.7． ［24］Hamerly=Pazuin=Walton，「Navigatorのソースコード公開 Mozillaの物語」，オー プンソースソフトウェア，オライリー・ジャパン(1999)． ［25］ホットワイアードジャパン：Mozillaを導くネットスケープの草の根運動，http:// www.hotwired.co.jp/news/news/technology/story/272.html，1998年2月27日アクセス． ［26］ホットワイアードジャパン：「Mozilla.orgはネットスケープではない」，http:// www.hotwired.co.jp/news/news/Technology/story/1688.html，1998年11月25日アクセス． ［27］Jamie Zawinski ："resignation and postmortem."，http://www.jwz.org/gruntle/ nomo.html， 1999年4月5日アクセス． ［28］Netscape Communications：NETSCAPE'S REVOLUTIONARY GECKO BROWSER TECHNOLOGIES ADOPTED BY IBM, INTEL, LIBERATE, NETOBJECTS, NOKIA, RED HAT, AND SUN MICROSYSTEMS， http://home.netscape.com/newsref/pr/ newsrelease799.html，2000年3月22日アクセス． ［29］CNET JAPAN：Mozillaの主要人物がまた脱退，http://japan.cnet.com/News/1999/Item/ 990406-7.html，1999年4月4日アクセス． ［30］ソフトバンクZDNet：Netscapeの興亡1∼3，http://www.zdnet.co.jp/news/0003/10/ netscape1.html∼http://www.zdnet.co.jp/news/0003/10/netscape3.html，2000年3月11日アクセス． ［31］CNET JAPAN：また人材を失ったモジラ，http://japan.cnet.com/News/2000/Item/ 000114-4.html，2000年1月14日アクセス． -60- ［32］ホットワイアードジャパン：オープンソースへの動きを擁護するアップル，http:// www.hotwired.co.jp/news/news/Technology/story/2167.html，1999年3月19日アクセス． ［33］Perens=Akkerman=Jackson：The Apple Public Source License - Our Concerns，http:// www.perens.com/APSL.html/，1999年3月19日アクセス． ［34］Perens：Is Your Software In Danger of Termination?，http://www.perens.com/ Termination.html ［35］Burbeck，"IBM's Road to Open-Source Software"，IBM総合フェア2000における講演 （2000年3月3日，幕張メッセ）． ［36］Mowery and Teece，「戦略的提携と企業の研究活動」，中央研究所時代の終焉，日経 BP社，1998年． ［37］Grindley，Mowery，and Silverman，"Sematech and Collaborative Research:Lessons in the Design of high-Technology Consortia"，Journal of Policy Analysis and Management， 13 (1994)． ［38］シャピロ=バリアン，ネットワーク経済の法則，IDGコミュニケーションズ （1999）． ［39］Veugelers and Cassiman，"Make and buy in innovation strategies: evidence from Belgian manufacturing firms"，Research Policy(28)，1999． ［40］Leonard-Barton，"Core Capabilities and Core Rigidities:A Paradox in Managing New Product Development"，Strategic Management Journal(13)， 1992． ［41］Mayers and Rosenbloom，「企業における研究の役割の再検討」，中央研究所時代の 終焉，日経BP社（1998）． -61- 付録 カーネルリリース一覧 （Linux version 2.x カーネルに関する情報、http://www.linux.or.jp/kernel.htmlより1999.2.23∼ 2000.3.13分を掲載） 開発版カーネル 2.3.51 がリリースされました. (2000/03/13) 開発版カーネル 2.3.50 がリリースされました. (2000/03/08) 開発版カーネル 2.3.49 がリリースされました. (2000/03/03) 開発版カーネル 2.3.48 がリリースされました. (2000/02/27) 開発版カーネル 2.3.47 がリリースされました. (2000/02/21) 開発版カーネル 2.3.46 がリリースされました. (2000/02/17) 開発版カーネル 2.3.45 がリリースされました. (2000/02/14) 開発版カーネル 2.3.44 がリリースされました. (2000/02/13) 開発版カーネル 2.3.43 がリリースされました. (2000/02/11) 開発版カーネル 2.3.42 がリリースされました. (2000/02/02) 開発版カーネル 2.3.41 がリリースされました. (2000/01/30) 開発版カーネル 2.3.40 がリリースされました. (2000/01/21) 開発版カーネル 2.3.39 がリリースされました. (2000/01/11) 開発版カーネル 2.3.38 がリリースされました. (2000/01/08) 開発版カーネル 2.3.37 がリリースされました. (2000/01/07) カーネル 2.2.14 がリリースされました. (2000/01/05) 開発版カーネル 2.3.36 がリリースされました. (2000/01/05) 開発版カーネル 2.3.35 がリリースされました. (1999/12/29) 開発版カーネル 2.3.34 がリリースされました. (1999/12/20) 開発版カーネル 2.3.33 がリリースされました. (1999/12/15) 開発版カーネル 2.3.32 がリリースされました. (1999/12/14) 開発版カーネル 2.3.31 がリリースされました. (1999/12/8) 開発版カーネル 2.3.30 がリリースされました. (1999/12/6) 開発版カーネル 2.3.29 がリリースされました. (1999/11/24) 開発版カーネル 2.3.28 がリリースされました. (1999/11/12) 開発版カーネル 2.3.27 がリリースされました. (1999/11/11) 開発版カーネル 2.3.26 がリリースされました. (1999/11/7) 開発版カーネル 2.3.25 がリリースされました. (1999/11/2) 開発版カーネル 2.3.24 がリリースされました. (1999/10/28) 開発版カーネル 2.3.23 がリリースされました. (1999/10/23) カーネル 2.2.13 がリリースされました. (1999/10/20) 開発版カーネル 2.3.22 がリリースされました. (1999/10/15) 開発版カーネル 2.3.21 がリリースされました. (1999/10/11) 開発版カーネル 2.3.20 がリリースされました. (1999/10/9) 開発版カーネル 2.3.19 がリリースされました. (1999/10/4) 開発版カーネル 2.3.18 がリリースされました. (1999/9/10) 開発版カーネル 2.3.17 がリリースされました. (1999/9/7) 開発版カーネル 2.3.16 がリリースされました. (1999/9/1) カーネル 2.2.12 がリリースされました. (1999/8/26) 開発版カーネル 2.3.15 がリリースされました. (1999/8/26) 2.0 系カーネル 2.0.38 がリリースされました. (1999/8/26) カーネル 2.2.11 がリリースされました. (1999/8/10) 開発版カーネル 2.3.13 がリリースされました. (1999/8/10) -62- 開発版カーネル 2.3.12 がリリースされました. (1999/7/28) 開発版カーネル 2.3.11 がリリースされました. (1999/7/21) 開発版カーネル 2.3.10 がリリースされました. (1999/7/8) 開発版カーネル 2.3.9 がリリースされました. (1999/6/30) 開発版カーネル 2.3.8 がリリースされました. (1999/6/23) 開発版カーネル 2.3.7 がリリースされました. (1999/6/21) カーネル 2.2.10 がリリースされました. (1999/6/14) 2.0 系カーネル 2.0.37 がリリースされました. (1999/6/14) 開発版カーネル 2.3.6 がリリースされました. (1999/6/9) 開発版カーネル 2.3.5 がリリースされました. (1999/6/2) 開発版カーネル 2.3.4 がリリースされました. (1999/6/1) 開発版カーネル 2.3.3 がリリースされました. (1999/5/17) 開発版カーネル 2.3.2 がリリースされました. (1999/5/14) カーネル 2.2.9 がリリースされました. (1999/5/13) 開発版カーネル 2.3.1 がリリースされました. (1999/5/13) 開発版カーネル 2.3.0 がリリースされました. (1999/5/11) カーネル 2.2.8 がリリースされました. (1999/5/11) カーネル 2.2.7 がリリースされました. (1999/4/29) カーネル 2.2.6 がリリースされました. (1999/4/17) カーネル 2.2.5 がリリースされました. (1999/3/29) カーネル 2.2.4 がリリースされました. (1999/3/24) カーネル 2.2.3 がリリースされました. (1999/3/8) カーネル 2.2.2 がリリースされました. (1999/2/23) -63-