Future of Cygnus Solutions: An Entrepreneur's Account

シグナスソリューションズ社の将来性
（創業者からの報告）

Michael Tiemann
マイケル・ティーマン
Translation by Akira Kurahone



　オープンソースビジネスのパイオニアであるシグナスソリューションズ社は、一九八九年に設立された。一九九八年八月の『フォーブズ』誌の調査によれば、規模でみると、現在、この分野で断然トップである。主力商品のＧＮＵＰｒｏデベロッパーズツールキットは、組み込み用ソフトウェア開発ツール市場において、優秀なコンパイラとデバッガによって評価を受けている。顧客の中には、世界有数の半導体メーカーはもちろんのこと、大手家電メーカーなどが名をつらねている。インターネットビジネス関連企業、情報通信関連企業、ＯＡ機器ビジネス、ネットワークビジネス、航空宇宙ビジネス関連、自動車メーカーなども含まれている。シグナスソリューションズ社は、カリフォルニア州サニーベイルに本社があるほか、アトランタ（ジョージア州）、ボストン（マサチューセッツ州）、ケンブリッジ（イギリス）、東京、トロント（カナダ）などにも支社を持っている。社員の中には、遠くは南半球のオーストラリアや、北米のオレゴン州などからリモート接続で勤務しているものもいる。シグナスソリューションズ社は、組み込み用ソフトウェア業界最大の民間企業であり、全体では、二つの公営企業を抜いて第三位に迫ろうとしている。一九九二年以来、65％以上の年平均成長率（Conpounded Annual Growth Rate）を記録し続け、「サンノゼ・ビジネス・ジャーナルによるもっとも成長の速い民間企業トップ100」に三年連続で掲載されている。そして現在は「ソフトウェア500」（全世界のソフトウェアビジネスの収益に基づくリスト）にも名をつらねている。
　このエッセイで、私は、わが社の成功の青写真となったオープンソースのビジネスモデルについてまず述べてみたい。その後で、わが社が将来の事業展望にむけて、このビジネスモデルをどう改良・拡大してきたかについて書いてみたい。
　一九八九年十一月十三日、カリフォルニア州のDepartment of Corporationから待ちにまった会社設立申請受理の通知が届き、我われは六千ドルの設立資金を供託して「シグナスサポート社」として事業に乗り出すことができるようになった。それは、二年あまり前からあたためられていた夢がかなった日であり、十年近くたったいまも続いている旅路の始まりでもあった。
　夢の始まりはじつに他愛のないものだった。「本を読むなら、最初から最後まで全部読みなさい」。父にそう忠告されたことがあるが、彼からさずかった他の忠告と同じように、私は都合のよいときだけそれを守った。そして、一九八七年、仕事に嫌気がさし、ＧＮＵソフトウェアに興味を持つようになったころに、リチャード・ストールマンが自費出版した“GNU Emacs Manual”を最初から最後まで読んだのである（この本が自費出版だったのは、当時、テキストの合法コピーを自由に作ることを読者に推奨する本を出してくれるような、心ある出版社がなかったからである。そして、いまだに、出版社の中には、このコンセプトを理解できないでいる会社がある）。
　これまでに様々なカスタマイズがほどこされてきているＥｍａｃｓは、単なるテキストエディタにとどまらない魅力的なプログラムである。Ｅｍａｃｓからは、Ｅメールの送受信ができる。ニュースグループへの記事の送受信もできる。シェルを起動することもできる。プログラムをコンパイルして、その結果をデバッグすることもできる。Ｅｍａｃｓ自体を駆動しているＬｉｓｐプログラムさえインタラクティブに使うことができる。創造力にあふれたユーザたち（または、同じように現状に飽き足らないやり手のプログラマたちが書き加えた面白い機能も付属している。その中のひとつである「ドクター」は、ジョン・マッカーシー（ＭＩＴ教授でＬｉｓｐ言語の生みの親）のＥＬＩＺＡプログラムをヒントにして作られた精神分析プログラムである。また、（海外ニュースの配信で有名なＡＰ（Associated Press）通信社をもじった「バラバラ通信」という意味の）“dissociated-press”は、テキストに書かれた文章をごちゃまぜにして難解な読み方やおかしな読み方を作りだすことができる。キャラクタベースのスクリーン上でハノイの塔の正解の動きを描いてみせるプログラムすらある。Ｅｍａｃｓの持つこのような奥深さと豊かさに惹かれて、私はもっと多くのこと知りたくなり、ストールマン著の“GNU Emacs Manual”を読み、ＧＮＵ Ｅｍａｃｓのソースコードを勉強することにした。
　ストールマンの本を読み進む間、私の脳裏にはひとつ疑問がずっとあった−なぜ、このような素晴しいプログラムを、自由に再配布できるフリーソフトウェアとして入手できるのか、という疑問である。これに対して、著者ストールマンは最終章の「ＧＮＵ宣言」において、彼なりの解答を私に与えてくれた。なぜＧＮＵを書く必要があるか、という一般的な疑問に彼は、次のように答えている。



　実際のところ、ストールマンは「ＧＮＵ宣言」の中でもっといろいろなことを述べているが、ここに引用するには紙面が足りない。興味のある方は、http://www.fsf.org/gnu/manifesto.html（http://www.gnu.org/japan/manifesto-1993j-plain.html）を参照されたい。右記のストールマンの引用は、一見すると社会主義的論争の一節のようにも聞こえるが、私はそこから別のことを読みとった。つまり、私はそこに、あるビジネスプランが姿を変えた形で書かれていると思ったのである。オープンソースは世界中のプログラマの努力を統合するものである。オープンソースのソフトウェアに関連して、カスタマイズ、機能向上、バグ修正、ユーザサポート等のサービスを提供する企業は、このような新種のソフトウェアに付随するユーザのニーズへの多様な対応性や経済的広がりをビジネス的に活用できる。そういう非常にシンプルな基本理念が「ＧＮＵ宣言」には書かれていると私は思った。
　ＧＮＵプロジェクトの推進母体であるＦＳＦ（Free Software Foundation）は、ＧＮＵ Ｅｍａｃｓ以外にも、魅力的なプログラムを提供していた。ＧＮＵデバッガ（ＧＤＢ）もそんなプログラムの一つだったが、これは、ＤＥＣ社（現在、コンパック社の一部）やサン・マイクロシステムズ社のデバッガが、Ｅｍａｃｓのような複雑なプログラムのデバッグに向かなかったので、ストールマン自身が開発せざるをえなかったものである。ＧＤＢは、大きなプログラムのデバッグが可能であっただけでなく、強力なコマンドや拡張機能がいろいろ備わっていたため、デバッグ作業が楽にできた。また、ＧＤＢは、ソースコードレベルでオープンなソフトウェアだったので、様々なプログラマたちによって、さらに多くの拡張が施され、より一層強力なデバッガに成長していった。つまり、ＧＤＢは、商用ソフトウェアにはない拡張性を持ち合わせていた。
　本当に衝撃的だったのは一九八七年六月にストールマンがＧＮＵ Ｃコンパイラ（ＧＣＣ）バージョン1.1を発表したときだった。私は、それをすぐにダウンロードすると、ＥｍａｃｓとＧＤＢのマニュアルから学んだ知識を総動員して、きわめて短時間のうちにＧＣＣの十一万行のソースコードに精通した。ＧＣＣは、初期リリースでＶＡＸとＳｕｎ３プラットフォームをサポートしていた。しかも、そのふたつのメーカーが提供していたコンパイラよりはるかに性能が良かった。そこで私は二週間かけて、ナショナル・セミコンダクタ社が新しくリリースした３２０３２マイクロプロセッサ搭載のマシン上にＧＣＣを移植した。結果は、ナショナル・セミコンダクタ社製のＣコンパイラより20％も速いものだった。それからさらに二週間、私はコンピュータにかじりついて、移植コンパイラの比較性能を40％にまで引き上げた（ナショナル・セミコンダクタ社のチップは、モトローラの６８０２０に対抗して１ＭＩＰＳになるはずだったのに、リリースされてみると、アプリケーションのベンチマークで0.75ＭＩＰＳにしかならなかったので、結局すたれてしまった、とよく言われる。しかし、0.75ＭＩＰＳの40％増しは、1.05ＭＩＰＳである。自社のコンパイラ技術がお粗末だったおかげで、ナショナル・セミコンダクタ社はどれほどの損害をこうむったのだろうか）。私はそのとき思った。プログラマが日常的に使う三大ツールは、コンパイラ、デバッガ、エディタである。ＧＣＣ、ＧＤＢ、そしてＥｍａｃｓは、商用ソフトウェアとして販売されている代替品より格段すぐれている。これらのものを商用ソフトウェアの代わりにビジネス的に提供できたら、そうすることの経済的な恩恵は別にして、いったいどのくらい儲かるのだろうか。
　ここでふたたびＧＮＵ宣言を引用しよう。



　決して読みやすくはないが、ＧＮＵ宣言は理にかなった文書である。この中でストールマンは、ソフトウェアの本質、プログラミングの本質、そして専門知識という偉大なる伝統について論じている。その上で、金銭的な結果はさておき、自由に共有された情報は倫理的にも道義的にも、自由に伝えられなければならないと結論づけている。この点について、私はストールマンとしばしば論じてきたが、私なりの結論として次のように考えている。ユーザがソフトウェアを使用し、配布し、変更する自由を制限しようとするビジネスモデルは、それがいかなるモデルであっても、結局はこの自由を制限することはできない。ユーザの自由を制限しようとするビジネスモデルは、倫理的な理由からではなく、競争上の問題や市場原理的理由からけっして生き延びることはできない。
　当初の間、私は、ストールマンと同じようなやり方で持論を主張しようとした。つまり、プラスの面を強調することにし、共有の自由があれば、もっと少ないコストでもっとすばらしい技術を開発できると説明した。基盤を共有したうえでのオープンスタンダード化を通じて経済規模をもっと拡げられることなどを説明した。しかし、人びとはきまってこう答えた。「いいアイデアですが、うまくいかないでしょう。フリーソフトウェアに金を出そうなんて人はいませんからね」。それでも二年の間、私は表現に工夫をこらし、持論に磨きをかけ、旅費を払って招いてくれる世界中の人びとにメッセージを伝え続けた。そして「いいアイデアですが……」という反応に直面し続けるうちに、みんながいいアイデアだと思ってくれるなら、それはいいアイデアにちがいない。また、うまくいくと思う人がいないということは、ライバルが出現しないということだ！、という第二の考え方がひらめいた。



　物理学の教科書でニュートンの法則がこんなふうに紹介されることはないだろうが、数学的に言えば、右記の等式はF=MAと同じくらい妥当である。このような形で等式を表現する目的は、逆算する操作を適切に選べば、その操作の結果が意外なものに見えようと、等式の妥当性を主張できるということである。私の考えでは、オープンソースソフトウェア関連のサービスをビジネス的に提供するというアイデアは、右記の等式のようなものである。このアイデアが実現不可能に見える人たちは、マイナス記号に驚くあまり、それが相殺できる種類のものであることを見落としている。



　第二の考え方がひらめいたので、私は、もうひとつの、それもきわめて仮定的な問題に対する答を出せたら、スタンフォード大学の博士課程を中退して会社を興す準備に入ることにした。その問題とは、そのとき無一文だった私に、ある技術を買いとるだけのお金があったら、それをもとにビジネスをはじめるだろうか、というものだった。そして、私は、サン・マイクロシステムズ社の技術、ＤＥＣ社の技術、その他もろもろの自分の知っている技術を買い取って会社を始めたらどうなるかを考えてみた。私の会社は、ＧＮＵ関連のビジネスを提供する会社とやりあってどのくらいもつだろうか？　初期投資ぐらいは回収できるだろうか？　そして、オープンソースのソフトウェア関連のビジネスと反対の立場がいかにつまらないものかを悟ったとき、私は自分のビジネスプランの機が熟していると感じた。



　さて、我われは、オープンソースのビジネスをしているが、ここではそれを支える理論と、我われがそれをどのように実践しようとしたかをふりかえってみよう。
　まず、有名な言葉をふたつ引用する。





　ノーベル経済学賞というのは、アダム・スミスの学説をもっともわかりやすく言い換えた経済学者が毎年もらうのだ。こんな冗談を私がよく言うのも、自由市場経済学の概念があまりにも広漠としているからだ。しかし、こんな冗談の裏にも重要な真実がかくされている。つまり、ソフトウェア市場には、無限の経済的可能性が未開発のまま残されているということである。そして、より本質的な意味で自由市場システムを利用すれば、それを開発できるということである。
　アダム・スミスの時代は、自由市場経済のおかげで個人的な旅行や商取引が可能になった時代だが、国家間の商取引といったより規模の大きい商取引は厳しく規制されていた。そのため、実業家の多くが、支配的な王制に幻滅し、それまでの政府のように彼らの経済活動に口出ししない政府を自分たちの手で作った。実際の話、合衆国憲法の基本的構想とビジョンを決定したのも自由を求める気持ちであった。今日においても、地球規模の経済や政治の世界の出来事は、そのおおもとに、自由を求める人々の気持ちがあるように思われる。自由というものがこれほどまでに引っ張りだこなのはなぜだろうか？　自由であることによって、なぜこれほどまでに経済が発展したのだろうか？　これについて少し考えてみよう。



　一九八九年頃、商用ソフトウェアとして提供されていたプログラミングツールは、誰の目からみても、まったくお粗末の一語につきた。それらは機能的に稚拙だった。利用可能な機能も、使用上の制約があまりにも多すぎて、プログラムがちょっと複雑になっただけで、すぐに使いものにならなくなった。ユーザサポートもお粗末で、大量のハードウェアや大規模なサイトライセンスを購入できるといった資金の潤沢なところでもない限り、機能面での制約で問題に直面しても、しかるべき対応を講じてもらえなかった。そして、どのメーカーも独自の方法で自社製ツールを実装していたので、そのようなツールをあるプラットフォーム上で使用してしまうと、知らないうちに、開発プログラムがそのプラットフォームに極端に依存するようになってしまった。要するに、自由市場経済のメリットが何であれ、それがソフトウェア市場で機能しておらず、従来のビジネス慣行に沿って商用ソフトウェアを販売するビジネスモデルが間違っていることは明白だった。そして、従来のビジネスモデルがここまで間違っていたからこそ、それを研究することがきわめて重要になった。
　いまも昔も、商用ソフトウェアベンダーの社内は自由市場経済の様相を呈している。そこでは、負けず嫌いのエンジニアや製品開発グループが、予算や優遇処置をめぐって自由に競い合っているからだ。しかし、この壁の外に一歩出ると、商用ソフトウェアの使用と配布は、ライセンス契約書や特許、そして企業秘密などによって厳しく規制されている。マクロではなくミクロのレベルで自由が実践されていることで資源がどれほど無駄になっているのだろうか？　効率がどれほど落ちているのだろうか？　ソースコードレベルでユーザをサポートする会社を興すことによって、我われはその答を出そうとしたのである。



　次のように割り切ってソフトウェアを開発しているベンダーもいる。ユーザのほしがるソフトウェアを一度作ってしまえば、その複製や配布はお札を刷り増す行為に似ていなくもない。生産コストはただ同然で、利ざやは100％に近い。思うに、一九八〇年代にソフトウェアがそこまでお粗末な状態になったのは、ソフトウェアベンダーの多くがお札を刷り増すビジネスモデルの完成に夢中になり、自社製のソフトウェアが市場に出回ったあとのことに無関心だったからだろう。彼らは、ソフトウェアサポートという概念を、ソフトウェアの製造工程の不備によるできそこないの副産物と見なし、ユーザサポートのための出費を最小限おさえ、最大限の収益をあげようとした。
　そのようなビジネスモデルはユーザを失望させただけでなく、ソフトウェアそのものにとっても不幸だった。すぐにでも容易に実装できる機能がしばしば（マーケティング的に）「非戦略的」であるとの理由で切り捨てられた。ソースコードにアクセスできない顧客にとって、自分たちでも実装できる機能さえ、それがいつになったら提供されるかは常に推測の域をでなかった。そして、役に立たないがユーザアピール度の高い機能をごちゃごちゃ詰め込むことが市場競争であるとはきちがえ、ユーザに代わってソフトウェアの競争原理のなんたるかを定義しようとしたメーカー（とそのマーケティング部門）によって、自由市場経済原理は完全に本末転倒されてしまった。





　この世を住みやすい場所にする方法について卓抜な理論を持つことと、そのような理論を軌道に乗せるためにお金を使うことは同じではない。当時、ソフトウェア業界ではユーザサービス主体の会社はまれな存在だったが、他の分野には学ぶべき事例がたくさんあった。
　ここで、アメリカ（およびイギリス）の慣習法と弁護士業務の関係について考えてみよう。これらの国では、慣習法を行使しようと思うすべての者がそれを自由に行使できる。Ｒｏｅ対Ｗａｄｅの判例をライセンスしなければ、その判決を使って自分の主張を展開できないわけではない。しかも、判例は、それが判決として下されるまでにどれほどの費用がかかっていようと、いったん下されてしまえば、誰もが自由に利用できる。しかし、このような自由がある社会で、弁護士はもっとも高い報酬を要求する職業の一つだ。専売特権を持っているわけでもない弁護士が、なぜそのように価値ある存在としてみなされるのであろうか？
　弁護士が社会的に価値ある存在としてみなされるのは、優秀な弁護士を雇えば、自分に有利な判決を勝ち取れるからであり、それが新しい先例として法体系の一部に組み込まれるからである。この社会は、法律を遂行する行為そのものだけでなく、そのような行為の累積に価値を認めている。司法はいきあたりばったりのものではなく、歴史が積み重なってできたものなのである。
　これは、業界標準をオープンソースソフトウェアによって確立し、それを維持していくという考え方に少し似ている。この方法で正しい標準を作り出すことは非常に高くつく。しかし、もっと高くつくのは、正しい標準を持たずに仕事をすることや、おかしな標準を維持しようすることである。優秀な人材にソフトウェアを開発させ、それを先例として将来の標準作りに生かすことは非常に価値のあることである。我われは、会社を始めるにあたって、このような価値の存在を顧客が理解してくれると信じていた。ソフトウェア業界のデファクトスタンダードとなる高密度なオープンソースプログラムを我われに開発させてくれると信じていた。


創業時代のシグナスソリューションズ社
　理論の構築が完了し、それを実行する時がきた。ソフトウェアをサービスする会社を興すことは、商売についての知識があれば、それほどむずかしはくない。あいにく、創業者の三人はみなビジネスの素人だった。



　我われは、ノロ・プレス社から出版されている本を参考に会社を設立した。社則を作り、その他の様々な手続きをすませた。そして、初年度、無駄使いを惜しんで節約した一セントがそののち数千ドルの利益となって返ってきた（専門家の助言を求めたほうがよかったかどうかは定かでない。初めてそのような助言を受けたときには一時間で数百ドルもかかったし、その助言に基づいてしたことも、その後、数万ドルものお金を専門家に払って結局訂正しなければならなかったからだ。たいていの場合、それは、我われが相談した多くの弁護士がとりわけ無能だったためというよりは、当時の我われが会社にまつわる法的な問題の奥深さをよく理解しておらず、適切な助言を得られなかったためと言ったほうがよい）。
　まったく新しいビジネスモデルを考案した我われは、財務、会計、マーケティング、販売、顧客情報、サポートについても独自のコンセプトを作りあげた。それらはみな、会社創立の年には大いに役に立った。しかし、何もかもが混乱し、誰もがビジネスを軌道に乗せるのに必要な仕事に打ちこんでいたころには有効だったコンセプトも、事業の拡大にともない全面改訂が必要になった。



　ビジネス展開の混乱を避けるため、我われは商売の前提をできるだけ簡略化することにつとめた。つまり、我われは、すでに技術的に定評のあるソフトウェアに対して、すでに技術的に可能とされているサポートを提供することにし、利益は数をこなして得ることにした。見積もりでは、顧客が自社スタッフでできることの二倍から四倍の高品質のサポートを約束した。サービス料金も、通常かかる費用の半分から四分の一しか取らないことにした。オープンソースソフトウェアにまつわるその他もろもろの側面は、漠然としていて営業的でないと判断し、あまり全面に押し出さなかった。我われは、よりよいツールをより安く提供することだけを目標に、徐々に契約を増やしながら、その方法を学んでいった。
　我われは、最初の契約を一九九〇年二月に結んだ。そして同年の四月末までには、十五万ドルを越える契約を結んでいた。そこで五月になった時点で、当社のサポートに関心を寄せてくれそうな五十の顧客候補に案内状を送ってみた。六月にはさらに百の案内状を送ってみた。すると我われのビジネスはにわかに現実味をおびはじめ、初年度の終わりには、七十二万五千ドル分のサポート契約と開発契約を結んでいた。そして、我われのビジネスチャンスはいたるところにころがっていた。
　これほどうまくいったにもかかわらず、我われはいくつかの深刻な問題に直面していた。我われは、顧客が社内の人材を使ってまかなう場合の半分から四分の一のコストでサポートを提供していた。ということは、七十二万五千ドル分の契約とは、通常換算すると、百五十万ドルから三百万ドル分に相当する契約だったが、それをこなすのにシグナスソリューションズ社には、セールスマンが一人、パートタイムの大学院生が一人、それに、イーサネットケーブルの敷設からレターヘッドの校正までなんでもこなす三人の創業者の、合計五人の社員しかいなかった。数をこなして利益を得るには、ビジネスの規模をどれだけ拡大しなければならないのだろうか？　いまの成長率でいくと、それを実現するまでに、どれだけ徹夜しなければならないのだろうか？　それは誰にもわからなかった。我われには、財務やマネジメントの手本となるものがなかったからである。


ＧＮＵ Ｐｒｏツールキットについて
　我われは、仕事に追われて燃え尽きてしまう前に、会社の規模を拡大しなければならないという結論に達した。そして、エンジニアの頭で考え、その目的を達成する一番の近道は、もっとも小粒なオープンソースの技術でありながら、ひとつのソリューションとして提供可能な技術を見つけて、それにビジネスの焦点をしぼることだと判断した。特定の技術に焦点をあて、提供するサービスを絞れるだけ絞れれば、会社の規模を拡大するのが容易になると考えたからである。



　我われは、特定の技術に焦点を絞るために、シェルユーティリティを検討してみた。ファイルユーティリティやソースコード制御プログラムなどに焦点をあててサポートサービスを提供することも検討してみた。インテル用のフリーカーネルを開発することさえ計画してみた。しかし最終的には、ＧＮＵコンパイラとＧＮＵデバッガを製品として提供することに落ち着いた。当時、32ビットコンパイラを商用ソフトウェアとして販売している会社は十社あまりあった。サン・マイクロシステムズ社、ＨＰ社、そしてＩＢＭ社なども、自社製コンパイラを開発している部門を持っていた。我われは、これらの競争相手となりうる会社がいくつあるか数えてみて、32ビットコンパイラ市場を占有できれば、会社の規模を拡大して、当初の計画だったクールな仕事のすべてに取りかかれると考えたのである（我われは、オープンソースビジネスの分野で、ＩＢＭシステムをアウトソーシング方式でフルサポートするＥＤＳ社のような存在になりたいと思っていた）。
　ＧＮＵコンパイラはすでに、数十のホスト環境と、これも十を超えるターゲットＣＰＵアーキテクチャをサポートしており、当時のコンパイラの中ではもっとも移植が行なわれているもののひとつだった（これらの移植作業のうち、六つは私が行なったものである）。一方、ＧＮＵデバッガは、五つのネイティブプラットフォーム（デバッグしているバイナリプログラムとデバッグマシンが同じ環境のこと。これに対して、違うマシン用のバイナリをデバッグすることをクロスプラットフォームあるいは組み込みという）上で動作していたが、組み込み用システムがサポートできるようにも書き換えられていた。我われは、素人の浅はかさで、製品を作るということは、様々なプログラムやソフトウェアをひとつの配布パッケージとしてまとめ、ＲＥＡＤＭＥファイルを書き、インストールスクリプトを作成して、テストし、出荷することにすぎないと考えていた。しかし、現実はもっともっと大変だった。
　第一に、ＧＣＣはバージョン1.42からバージョン2.0への移行の真っ最中だった。ＧＣＣのバージョン１は、モトローラの６８０００系のＣＰＵやＶＡＸなどのＣＩＳＣアーキテクチャマシン上で動作する他のコンパイラより優れていたが、ＲＩＳＣプラットフォーム上で競争できるようにするためには、かなりの最適化が必要とされていた。私が一九八八年にＧＣＣをサンのＳＰＡＲＣステーションに移植したとき、ＧＣＣはサン純正コンパイラより20％遅かった。一九八九年、私は、命令順序を最適化する機能を実装し、このギャップを10％にまで縮めた。そして、同じ年に、分岐命令を最適化する機能を実装することによって、Ｓｕｎ純正コンパイラとの差を５％以下にすることに成功した。ＣＰＵアーキテクチャがＣＩＳＣからＲＩＳＣへ移行しつつある時代に、我われは、あらゆる点で最高のコンパイラを手渡すビジネスから、顧客に複雑な検討を強いる製品を売るビジネスへと移行した。それはもはや単純で直接的な商売ではなかった。
　第二に、私が一九八七年の秋に世界初のネイティブコードＣ＋＋コンパイラとして書いたＧＮＵ Ｃ＋＋（Ｇ＋＋）が時流に乗り遅れはじめていた。Ｃ＋＋はＣよりもはるかに複雑なコンピュータ言語であり、私がシグナスソリューションズ社を設立したときにもまだ拡張されし続けていた。また、一九九〇年には、さらに複雑な新機能がいくつか「標準」として追加されたが、シグナスソリューションズ社の仕事に忙殺され、私にはＧ＋＋を最新の仕様にしておく時間がまったくなかった。
　第三に、ＧＤＢ（ＧＮＵデバッガ）は、あちこちに多種多様なバージョンが存在していた。ＧＣＣとＧ＋＋は、決められた一か所からリリースされていたため、ソースコードに適切な一貫性があったが、ＧＤＢはソースコードレベルでいろいろなバージョンが存在していた。ＧＤＢの場合は、それを積極的に保守する人がいなかったために、世界中の人びとが必要に応じて自分だけのバージョンを作ってしまい、結果的にいろいろなバージョンが多数できてしまった。商用ソフトウェアの利点は「本物の」バージョンが一つだけ存在することだが、オープンソースソフトウェアは、同期のとれていないリリースバージョンが複数存在し、どれをとっても正当な「標準バージョン」ではなくなってしまう可能性がある。オープンソースの対抗勢力はこう主張するかもしれなかった。
　第四に、実際のところ、我われには完全なツールセットがそろっていなかった。アセンブラやリンカーなどのバイナリユーティリティ（いわゆるbinutil）はあったが、それはＧＣＣとＧＤＢのサポートされている一部のプラットフォーム上でしか動作しなかった。ＧＣＣがサポートされているプラットフォームで、ＧＡＳ（ＧＮＵアセンブラ）やＧＬＤ（ＧＮＵリンカ）もサポートされているプラットフォームであって、かつＧＤＢのサポートされているプラットフォームがいくつあるかということになると、その数はまったくゼロだった。
　第五に、我われはＣライブラリを持っていなかった。このことは、サン・マイクロシステムズ社製のマシンやＨＰ社製のマシンといったネイティブプラットフォーム上で我われのシステムを使ううえでは問題ではなかった。しかしスタンドアロンで動作するアプリケーションでＣライブラリの機能を使う必要がある組み込み用システムの開発者にとっては一大事だった。
　第六に、ライバルたちは我われのジャストインタイム方式の生産技術には太刀打ちできなかったが、彼らはすでに自社製品をそれぞれのニッチマーケットで非常に効率的に販売していた。自分たちの製品を製造し販売することによって、我われは側面攻撃作戦を変更し、こちらの十倍から百倍の収益をあげている会社に正面攻撃をしかけなければならなかった。
　そして、最後に、我われの自信という問題があった。急速に進化する多くのツールを統合する立場にいた我われには、こちらのサービスが必要とされていることがはっきりわかっていたものの、懐疑論者からいろいろ言われていたからである。彼らは、オープンソースの製品という概念そのものに食ってかかり、及第点の製品を作ればたちまちサポートビジネスなど不要になって、半年後には廃業に追い込まれると指摘した。そして、それから四年の間、我われのビジネスはそんなふうに攻撃され続けた。



　一か八かやってみる。我われにはそれしかなかった。そして、全員で相談して、半年分の作業見積の「二倍働いて」目標を達成することにした。私は昼は社長として働き、夜はＧＣＣ2.0とＧ＋＋の開発作業に協力した。シグナスソリューションズ社の第二の創業者であるデビッド・ヘンケル-ウォレス（通称ガンビー（Gumby）は、ＣＦＯ（最高財務責任者）とサポート責任者としての仕事の他に、バイナリファイルユーティリティとライブラリ関連の開発作業を担当した。そして、第三の創業者であるジョン・ギルモアはＧＤＢがらみの作業を担当した。我われは新しく社員を採用し、（1）修正ファイルや作成ファイルをすべてＣＶＳに入れてもらうようにした（ＣＶＳ（Concurrent Versioning System）とは、複数の開発者や、複数のディレクトリ、複数のグループ環境においてソフトウェアの修正やリリースを管理するシステムのこと）。（2）対応予定の数百のプラットフォーム上で使用するインストレーションスクリプトやコンフィギュレーションスクリプトを書いてもらった。（3）ソフトウェアの機能評価テストを自動的に行なえるようにしてもらった。そして、（4）加速度的に増えつつあった新規契約の履行を助けてもらった。
　六か月後、事業はどうにか拡大したが、我われの厳格な（限定的とも言える）一点集中主義に飽き足らなくなるものも現われた。そこで我われは、販売努力と技術努力のほとんどをＧＮＵ製品に傾ける一方、その他の仕事もこなすことにし、ネットワークセキュリティソフトウェアのＫｅｒｂｅｒｏｓやＧＮＵ Ｅｍａｃｓエディタ関連の技術サービスを提供することにした。当時まだ開発中だったバグレポート管理システムおよび自動検証プログラムの契約も結んだ。
　ジョン・ギルモアは、インターネット上で次のように告知した。「ＧＤＢのメンテナンスをすることにしたので、実装済の機能で次期バージョンに反映してほしいものがある人は、それが実際に実装されているソースコードを私のところまで送ってください。どうしたら次期バージョンに反映できるか考えてみます」。六週間後、ギルモアの手元には百三十七種類のＧＤＢ（ほとんどがバージョン3.5の改良版）が集まった。そして、そのどれもに新機能がいつか実装されていた。ギルモアは、それらをすべて包むＧＤＢ4.0の設計にとりかかった。そんなことはできっこない。そう言った私はどうかしていたのかもしれない。

ツール読み込み書き込み
コンパイラASCIIASCII
アセンブラASCIIバイナリ
アーカイババイナリバイナリ
リンカバイナリバイナリ
Sizeバイナリバイナリ
Stripバイナリ バイナリ
Binary バイナリ バイナリ
Nmバイナリ バイナリ
デバッガバイナリ
表6-1

　ヘンケル‐ウォレスは、バイナリファイルユーティリティを共通ライブラリ化することにした。そして、そのライブラリには、既存のオブジェクトファイルとデバッグフォーマットをすべて記述することにした。このような決定を彼がなぜ下したのかは、我われのコンパイラの開発環境で使用されるツールの特徴をちょっと考察すればすぐわかることである（表６−１）。
　それぞれのツールは、独自の方法でバイナリファイルフォーマットの読み書きを実行するように作られていた。そして、それぞれに、ａ・ｏｕｔ、ｂ・ｏｕｔ、ｃｏｆｆ、ｅｃｏｆｆ、ｘｃｏｆｆ、ｅｌｆ、ｉｅｅｅ６９５といった多様なバイナリフォーマットをサポートするようになっていた。しかも、これらのツール全体では、一種類のバイナリファイルフォーマットしかサポートされていなかった。ということは、モトローラの６８０００系のＣＰＵアセンブラ用のａ・ｏｕｔを手直しすれば、そのａ・ｏｕｔバイナリフォーマットで読み書きを実行するツールにも同様の手直しを施さなければならなかった。あるいは、オブジェクトファイルごとに特殊な修正を施さなくてはならなかった。そのような修正は、ユーティリティの仕様によって、ａ・ｏｕｔファイルの読み書きに関係するコード部分の変更だけで済ませられることもあれば、全体的なコードの書き換えになる可能性もあった。
　すべてのファイルフォーマットを単一のソースコードの実装でサポートするライブラリを作れば、異なるオブジェクトファイルを透過的に扱え、かつ首尾一貫した方法でメンテナンスできる。我われのビジネス面での目標であった規模の拡大を早期に達成するにはその方法でいけることが望ましかった。もちろん、ａ・ｏｕｔ形式のオブジェクトファイルとｃｏｆｆライブラリをリンクさせてｉｅｅｅ６９５実行可能ファイルを生成できることをデモして見せられたら、それはそれでかっこいいことだった。ガンビーはライブラリの開発にとりかかると、実際にどう設計したらよいかをストールマンと相談した。ストールマンの意見は、それを実現するにはすべてのツールを全面的に書き換えなければならなず、メンテナンスもほとんど不可能に近いから、そのようなライブラリの開発は困難、というものだった。ストールマンからそう言われたときにガンビーが、これはそれほど「Big F*cking Deal（こむずかしい仕事）」ではないと言った。この言葉が、このライブラリのＢＦＤという名前の由来である（我われは、顧客に対して、ＢＦＤはBinary File Descriptor（バイナリファイル記述）の略称であると説明した）。
　ジョン・ギルモアとガンビーが開発に取り組んでいる間、私は相変わらず、現金収入をとだえさせないために契約をとり続けなければならなかった。四半期ごとに、私は、新たな高い目標を設定し、多くの契約を獲得しようと努めた。私には、より多くの人手が日銭稼ぎの仕事に必要だったが、優秀なエンジニアはみな、私の直接管理していない製品開発に日夜あけくれていた。そんな中で、販売部門と技術部門の間の緊張が高まると同時に、オープンソースのビジネスモデルが狂いを生じ始めたように見えた。ＧＮＵソフトウェア関連の開発をすればするほど、インターネットコミュニティがらみの収益が少なくなったからである。そしていつしか我われは、ＧＮＵ関連ツール類の開発の50％以上を行なうようになっていた。
　しかも、それは一時的な状況ではなかった。最初の“Progressive Release”ができるまでに、なんと一年半も要したからである。重大な意味を持つその日、私は初めて、ＣとＣ＋＋の完全な開発ツールキットがひとつのソースコードで実装されていることを知らされた。そして、そのソースベースを基に、Ｓｕｎ３とＳｕｎ４という二つのプラットフォームをサポートできることが告げられた直後、私は唖然とした。我われのプログラマは、全員総がかりでふたつのプラットフォームをサポートできるものを開発したが、私には、彼らがかけたよりも少ない時間で、ＧＣＣを六つのマシン上に移植し、ＧＤＢを三つのマシン上に移植し、ネイティブコードのＣ＋＋コンパイラとデバッガを書いた経験があったからである。

日付リリース名ネイティブ組み込み総プラット
フォーム数
1992. 3p1202
1992. 6p2505
1992. 9p351015
1992.12p452025
1993. 3q153035
1993. 6q254550
1993. 9q375360
1993.12q486775
1994. 3r1107585
1994. 6r2108090
1994. 9r3108595
1994.12r41090100
表6-2

　時間はかかったものの、完成されたものは次の二点において優れていた。（1）多くの便利な新機能が実装されたおかげで、ツールの性能が以前よりも改善された。（2）ツールを書き直しただけでなく、コンフィギュレーションスクリプトや自動検証機能を実装し、開発環境全体を充実したおかげで、ほとんどのホスト／ターゲットマシンの組み合わせに対応できる見通しがついた。また、あらゆる組み込み用システムをサポートできる見通しがついた。
　このツールは実際に検証され、以下のような素晴しい実績をあげている（表６−２）。
　エンジニアたちがこのＧＮＵＰｒｏツールキットの開発に打ち込んでいる間、我われ販売チームはそれをどう売ったらいいかの戦略を練っていた。そんな中、一九九一年に、我われは、ビジネス学専攻の女子大生を一人採用した。アプライド・マテリアルズ社からレイオフされたばかりの彼女は、ソフトウェア販売のノウハウを学ぶ目的で勤めはじめたせいか、母国語は英語でなかったものの、飲み込みが速かった。社内で週末にＣでのプログラミングを勉強していたとはいえ、彼女は我われの知っているたぐいのプログラマではなかった。それでも彼女は、我われのオープンソースのアプローチを広めるのに大いに貢献してくれた。「プレゼンするので見に来ませんか？」　好成績な売上を半年ほど続けたあとで彼女はそういって私をさそった。そして同行した客先で、私は、本当にびっくりさせられてしまった。私はそれまでずっと、技術者のやり方でオープンソースを売っていた−テクニカルな利点を強調する売り方をしていた。ところが彼女は、我われが取り組んでいる仕事の本質的な複雑さや、我われが提供しているツールを使った場合のビジネス面のメリットを強調する方法でプレゼンをしていた。私は、シグナスソリューションズ社の技術者が客先の技術者に比べ、いかに優れているかを強調するような営業をしていた。ところが、彼女は、たいていのマネージャが耳をふさぎたくなるようなことは口にせず、その代わりに、移植やサポートやメンテナンスを我われにやらせたら、彼らの技術者がどんなに得をするかというような話をしていたのである。この彼女のアプローチをじかに目にしたおかげで、我われは、自分たちに仕事を依頼するメリットを顧客に説明できるようになれた。社内の人材に仕事をさせるよりは我われに任せたほうがいい理由を説明できるようになれた。技術力と営業力が結びついたことで、我われはついに多額の売上を記録するまでになった（表６−３）。

受注（$K）利益率（％）累計年平均成長率
1990: 725εN/A
1991:15001106%
1992:2800296%
1993:4800387%
1994:5700467%
表6-3



　このような努力から、新しいいくつかの重要な技術が誕生し、インターネットのコミュニティに還元され、そして新たな標準となった。それらは、三つ引数を与えて、プログラムをコンパイルしたいマシンやシステムの種類を記述するコンフィギュレーションスクリプトを作成するＧＮＵ ｃｏｎｆｉｇｕｒｅやｃｏｎｆｉｇｕｒｅスクリプトを作成するためのより高度なスクリプトを自動作成するａｕｔｏｃｏｎｆの他、（バイナリファイルやオブジェクトファイルの生成を管理する）Ｍａｋｅプログラムに与える入力ファイルの内容となるスクリプトを自動生成するａｕｔｏｍａｋｅやデグレード防止のための自動検証を行なう機能を提供するＤｅｊａＧＮＵやバグレポート管理システムであるＧＮＡＴＳなどである。
　現在、ＧＮＵＰｒｏツールキットがサポートしているホスト／ターゲットマシンの組み合わせは百七十五にのぼる。そしてこの数字は、市場にこれ以上の組み合わせが存在しないことによるものであって、我われの技術的限界によるものではない。
　ＧＮＵＰｒｏが非常に広範なユーザ層を獲得すると、我われに対抗してＧＮＵソフトウェアの技術サポートを有料で提供する意向を表明する企業まで現われた。しかし幸いなことに、今度も我われは、オープンソースのビジネスモデルのおかげで命拾いできた。というのも、我われは百人以上の技術者を擁しており、そのほとんどがＧＮＵソフトウェアの原作者またはメンテナンス責任者であった。しかも彼らが、シグナスソリューションズ社でサポートエンジニアとして働いていた。つまり、技術サポートで我われと競合しようとするところは、それだけの質の技術者をそろえない限り、「ＧＮＵの真の供給源」という地位から我われを引きずり降ろすことはできない（シグナスソリューションズ社は、ＧＣＣ、ＧＤＢおよび関連ユーティリティに施された変更の80％以上を手がけてきている）。もちろん、競合企業も、一つずつ新しい機能を追加して、それに対する対価を顧客に求めることはできる。しかし、そうして機能拡張されたソフトウェアもオープンソースであることに変わりなく、どのような付加価値が追加されようと、シグナスソリューションズ社もソースコードレベルでそれにアクセスでき、もしそれが優れたものであれば我われの手で実装できる。たいして魅力的なものでなければ無視することもできる。勝つか負けるかの戦いを繰り広げなければならない商用ソフトウェアの世界と違って、オープンソースの世界の戦いは「メビウスの帯」の上で繰り広げられているようなもので、メンテナンスに力を注いでいる側にすべてが流れるようになっている（メビウスの帯−帯状の紙をひとひねりして両端をつないだ輪。この輪の上で一周すると、反対側の面の上にでる。もう一周すると、もとの面の上にもどる）。したがって、競合企業がＧＮＵ市場で「便乗的なビジネス」を展開し、戦略的に優位な立場に一時的に立てることがあっても、長い目で見れば、得をするのはシグナスソリューションズ社なのである。一九八九年に創業し、誰よりも早くオープンソースのビジネスを始めた我われは、競合企業の十年先を行っているのである。




　想像もつかないだろうが、我われは、五人の組み込み用システムプログラマを束ねるマネージャを技術サポートする仕事を一万ドルで請け負うとしたり、自社のビジネスモデルで株式公開できるかを考えたりしていた。オープンソースのビジネスモデルは、優秀で革新的なソフトウェア開発グループに我われを売り込む最良の手段だった。しかし、大企業相手の市場では、同じモデルがこんどは大きな障害となった。我われは、ジェフリー・ムーア（Geoffrey Moore）が著書の『Crossing the Chasm（淵を越える）』で言ったことを身を持って感じることとなった。
　そのことを私がはっきり意識したのは、我われの組み込み用システムツールの話をしに、ある開発グループを訪ねたときである。フォーチュン100に入る大企業のために無線通信システムを構築していた彼らは、独自の評価基準を用いて、自分たちの技術度だけでなく、取引相手の技術度を様々な形で算定していた。そして彼らの取引相手は、大部分のところが「きわめて優良ないし優良」にランクされていた。しかし、組み込み用ツールを納入していた会社だけは、この制度が実施されるようになってからこのかた三年連続で、あらゆる評価基準において「不良ないし不満」のドンジリにランクされていた。それにもかかわらず、この開発グループは、我われと取り引きをしようとしなかった。彼らの顧客からもらったものを含む様々な推薦状、機能面での優秀性、低価格。とにかく好条件という好条件がすべてそろっていたにもかかわらず、我われの提供するソリューションが既存の方式のものではないというだけで、彼らは我われの組み込み用ツールに手を出したがらなかったのである。利用しないような技術評価をなぜ実施するのだろう？　私はそう自問したが、そうすること自体が見当違いだった。よくよく考えてみれば、彼らはごくあたりまえの反応を示しただけであり、取り引きが不成立だった理由を彼らのせいにしても、この問題は解決しないのである。そのためには、こちらのマーケティングや宣伝方法を改める必要がある。そのとき私はそう悟った。
　こういった外部要因の問題以外にも、我われは問題を抱えていた。多くの顧客は、現状がどうであれ、我われがサポートビジネスを拡大するのに足る数の社員を確保できるとは思っていなかったからである。そして彼らはまったく間違っていると同時にまったく正しかった。ことエンジニアの雇用に関しては、彼らは間違っていた。多くの開発プログラマにとって、エンジニアを創業者とし、オープンソースのビジネスモデルにのっとり独自の文化を構築しながら、オープンソースの世界をリードする技術者集団を率いるシグナスソリューションズ社で働けることは、非常に魅力的な話だった。そのため、わが社におけるエンジニアの離職率は、全国平均（とりわけシリコンバレーの平均）の四分の一から十分の一ほどであった。
　しかし、ことマネージャの雇用に関しては、まったく事情が違っていた。我われは、他社で現役マネージャとしている人たちに誘いをかけた。しかし彼らは、シグナスソリューションズ社に対して、我われの顧客が持っていたのと同じ先入観を抱いており、我われと一緒に働くことに興味を示さなかった。興味を示した連中は、何か別の目的があってそうしてくる連中だった。結局、エンジニアリング部門のマネージャが二人になったとき、技術者の数は五十人を越えていた。この二人は、オープンソースソフトウェア会社におけるマネージャの役割のあるべきすがたを模索し、自分の職務をまっとうしようと尽力した。そして彼らが悪戦苦闘するなか、社内のコミュニケーション、工程管理能力、人事管理能力、そして従業員の満足度といったものはすべて低下していった。
　これも皮肉な話だが、我われは、なんでもかんでもオープンソースにして（従来のビジネス慣行に沿った）クローズドなコンポーネントをビジネスに取り入れようとしないマネージャも不適格者とした。我われにとって、オープンソースはビジネス戦略であってイデオロギーではなかった。我われには、オープンソース製品とクローズドソース製品の両方を柔軟に使い分けて、会社の総合的な目標を達成しようとする人物でなければ、マネージャとして働いてもらうつもりはなかった。
　結局我われは、オープンソースのビジネスモデルのなんたるかをたちどころに理解できる人材を探しもとめるべきではない、という結論に達した。シグナスソリューションズ社の必要とするマネージャになってもらう人たちには、失敗することを許さなければならない（つまり、彼らの失敗もコストに計上しなければならない）。そして、彼らには自分の失敗から学んでもらわなければならない。これまで他社でマネージャとして勤務していた人ほど、自分の経験にあうようにシグナスソリューションズ社のやり方を変えようとする。それが彼らがこの会社で成功できない原因だった。これまでの経験を生かせると同時に、ここでの経験から学べるマネージャを見つけることは至難の業だった。しかも、我われはそのような人材を何十人も必要としていた。
　オープンソースのビジネスモデルには、いろいろ克服すべき課題があったが、シグナスソリューションズ社は素早く体制を立て直した。見込み違いや手違いで顧客を失うこともあったものの、年間契約更新率は、一九九三年以来、ドル換算でほぼ90％を保っている。顧客を失う原因のトップは、プロジェクトが終了したことによる「引き上げ」である。他の会社なら失敗したような状況で我われが生き延びられたのにはふたつの要因があった。（1）肩書や経験年数の如何にかかわらず、シグナスソリューションズ社のエンジニアは全員が顧客への責任を果たす重要性を認識していた（顧客のサポートだけに専念した）。（2）すべてが失敗に終わっても、顧客がソースコードを持っていたため、顧客自身で後始末ができた。したがって、当時のすさまじい状況にかかわらず、期待どおりにならなかったために貧乏くじを引いた顧客はほとんどいなかった。商用ソフトウェアを使う会社に頼んで貧乏くじを引いてしまった話や、サポートのないオープンソースソフトウェアでひどい目にあったところの話を当時よく耳にしたが、シグナスソリューションズ社はそれらと好対照をなすケースであった。


ｅＣｏｓの自主開発を行なうための資金調達
　組み込み用システムの世界では、少数の会社がチップを製造し、少数のＯＥＭがその大部分を買って、自社の組み込み用システム製品用に使っているのが現状である。面白いデバイスを作っている中小企業は数多くあるが、彼らのビジネス規模は、新しいチップの設計やソフトウェアソリューションを要求できるほどではない。
　半導体メーカーとＯＥＭの間には何百というソフトウェアメーカーがあり、そのすべてがソフトウェア製品を販売している。たとえば、いまの市場には、百二十以上の商用版リアルタイムＯＳ（以下ＲＴＯＳ、Real Time
Operating Systems）が出回っている。調査会社のＩＤＣによれば、どのＲＴＯＳも、マーケットシェアは６％以下である。十年前のＵＮＩＸ市場も多くの企業がひしめき割拠分断されていたが、現在の組み込み用システム市場は、それよりも二十倍に分断されているだけで、状況自体は当時に似ている。このような状態は、自由市場経済につきものの退行現象をもたらし、組み込み用システム市場は過剰性、非互換性、不当に高い価格といった問題でいっぱいだった。ＲＴＯＳメーカーは、開発に時間がかかりすぎるか、費用がかかりすぎるか、はたまたどちらもかかりすぎるといった問題をかかえていた。半導体メーカーとＯＥＭは、ＴＴＭ（time to money）を促進するような標準化を求めていた。
　組み込み用システムの市場において、我われは市場第一位の会社の二倍の速度で成長し、ライバルである上位四社の成長率を一桁におさえていた。我われは日の出の勢いだった。しかし、我われはマーケットリーダーとしての扱いを受けていなかった。それらしく振る舞おうともしていなかった。そんな状況下の一九九五年、私は組み込み用システムにおける問題点を主要な顧客と何度も話し合った。その結果、我われのＧＮＵＰｒｏツールキットでは、既存の顧客の問題にしか対応できないことがわかった。市場が求めていたのは、標準ＣライブラリやリアルタイムＰＯＳＩＸ ＡＰＩとコントローラチップとの間で、コントローラチップのハードウェアの仕様を抽象化するレイヤ（モジュール群）であった。これがわかったとき、わが社の製品を発展させ、大きくはばたかせるチャンスがそこにあると思った。
　我われは鉛筆を削り、技術的にわかっていることを書きだしてみた。しかし、百二十以上ものＲＴＯＳが市販されているという事実に加えて、千以上もの企業が独自のＲＴＯＳを社内で使用しているという事実は、専門的なレベルではまだ「ひとつのサイズですべてに間に合うもの」が実現されていないということを意味していた。また、ロイヤルティの問題もあった。市販のＲＴＯＳの使用に課せられるマシン一台ごとに対するロイヤルティの支払いが企業の利ざやを食っていたのである。この問題を認識していた我われは、自分たちの開発するＲＴＯＳはロイヤルティをとらないことにすべきである、と考えた。要するに、ビジネスの視点から見て、我われは、世界に通用するまったく新しい技術を開発し、それをただで手放さなければ、自社のソリューションを前提とする市場を形成できなかったのである。経営陣が決行に踏み切るまでには、一年間の熟慮を必要とした。
　そして経営陣は、この戦略を進めることに決定したあと、「それでどうやって稼げるか」を考えなければならなかった。我われのＧＮＵＰｒｏの使用を前提とする市場は成長しつつあった。しかし同じビジネスモデルをどう使ったら、組み込み用オペレーティングシステムの市場を獲得できるのだろうか？　我われにはまだそこがよく見えなかった。
　そこで我われは、一筋縄ではいかない問題に直面したときに誰もが使う、いろいろ想定しながら解決策を導きだすという奥の手を使うことにした。つまり、金もうけの方法を考えるのは後回しにし、顧客の問題を解決し、市場でナンバーワンになるために実行すべきは何かをまず考えたのである。（1）我われは、このすばらしい新技術を開発しなければならない。（2）その技術を基にシステムを構築して、とにかくユーザが使えようにしなければならない。（3）市場に売り込むチャンスがなくなってしまう前に、（1）と（2）を完了しなければならない。しかし、ソフトウェアの開発にはお金がかかった。しかも、期限限定でプロダクトを完成させなければならない開発プロジェクトには、とてつもないお金が必要だった。
　ベンチャーキャピタルはそういう資金を提供していた。しかしシグナスソリューションズ社を設立したとき、我われはみな、彼らが自分たちの仕事を理解することはないと決めつけていた。理解したとしても五年以上たってからのことだろうし、そのときに助けてもらっても何にもならないと勝手に思い込んでいた。ラッキーなことに、どちらの考えにおいても我われは間違っていた。
　というのも、シグナスソリューションズ社で最初の社外役員に就任していたフィリップ・コートが、一九九二年に入ってすぐ、一流どころのベンチャーキャピタルをいくつか私に紹介してくれたからである。私は、彼らとの話し合いの席で、我われのビジネスモデル、技術力、そして将来の目標について率直に説明した。シグナスソリューションズ社は自己資金での運営を目指しているので、運転資金を借りる必要のないことも率直に告げた。彼らに私の口からいろいろ告げずとも、会社の規模が毎年80％ずつ拡大し、収益率を１％ずつ増加させていることが、（私の考えでは）事業が順調に成長していることの何よりの証だった。実際の話、ベンチャーキャピタルの世界で活躍するソフトウェア業界アナリストのロジャー・マクナミーでさえ、「おたくのビジネスモデルには驚かされると同時にあきれています。それがうまく機能していることに驚いているのですが、考えれば考えるほど、それを最初に考えつかなかった自分にあきれてしまうわけです」と言っていた。
　外部に頼らずに資金問題を解決できると考えるのは気分がよかったが、実際のところ、我々はＧＮＵＰｒｏビジネスからの収入だけではまかないきれないほどの新規事業チャンスにめぐまれ、一九九六年には、新しい資金調達計画と新しいパートナーを必要としていた。
　我われがグレーロック・マネージメントとオーガスト・キャピタルのベンチャー・キャピタル二社と手を組むことにしたのは、彼らがシグナスソリューションズ社の事業内容と運営方針を理解し、適切な指導と規律によって我われがなしうることを理解してくれたうえで、計画の実行にたる資金を調達してくれたからである。我われは、一九九七年前半にひとつのソフトウェアメーカーに投資された金額では最高額の六百二十五万ドルの融資を彼らから受け、計画の実行に本腰を入れはじめた。

　　そういうのは好きじゃないんだ。生焼けのハムエッグなんて、そうさ好きじゃないんだ。 ドクター・スース

　技術チームは臨戦態勢だったが、経営チームは資金の利用法を検討し続けていた。初めのうち、我われは、ｅＣｏｓ（Embedded Cygnus OS）のアーキテクチャとそれを商品化するためにとるべきビジネスモデルとの接点を見出せなかったからである。技術面から見れば、「ひとつのサイズですべてに間に合う」アーキテクチャを作るうえで、このリアルタイムＯＳがどれほどの機能的な拡張性や柔軟性（デバイスドライバの選択の幅や、メモリサイズ等の環境への対応）を持つかが鍵を握っていることは明らかだった。営業面から見れば、組み込み用システムの開発に有効な統一標準を作るうえで、「ひとつのサイズですべてに間に合う」アーキテクチャが鍵を握っていることは明らかだった。しかし、我われは、その開発費用を技術部門が負担すべきなのか、それとも営業部門が負担すべきなのか決めかねていた。そして、一年半にわたって、技術部門と営業部門がそれぞれの問題に取り組んでいる間に研究開発費はかさみ、多くのマネージャがオープンソースのビジネスのパラドックスの妥協点を見出せないまま現場を去っていった。
　計画されたとおりの新技術の社内デモが最初に行なわれたとき、我われは自分たちが開発した世界初のオープンソースアーキテクチャを初めて目にすることができた。それは私にとって、ＧＣＣを初めて目にしたときと同じくらい興奮をおぼえる出来事であった。
　オープンソースソフトウェアは、真のプログラマにとってありがたいものである。また、オープンソースソフトウェアが標準になることはエンドユーザにとってすばらしいことである。しかし、プログラミングに精通した人たちがオープンソースソフトウェアを使ってできることと、一般ユーザができることは同じではない。我われが、ｅＣｏｓを、プログラミングに精通した人たちのコミュニティで受け入れてもらえる製品にしたかったことはもちろんであるが、組み込み用システムの開発者の間でも広く受け入れてもらえるものにしたかったのも事実である。我われの理想は、顧客となるＲＴＯＳ開発者に力を貸すことだった。現在手動で行なわれているＲＴＯＳの再構築作業から彼らを解放するために、ｅＣｏｓの基本的な機能を自動的に確認・実行できる高度なツールを提供することだった。この目的を実現するために我われは、ｅＣｏｓの制御をソースコードレベルでできる高度なツールを開発し、また、そのツールで制御できるようにｅＣｏｓのソースコードを書くことによって、ＣやＣ＋＋のコードをエンドユーザが自分で追わなくても、ソースコードレベルの作業をすることができるようにした。ｅＣｏｓは、コントローラチップのドライバだけの最小セットのもの（700バイト）から、インターネットのネットワーク機能やファイルシステムを含んだフル装備の構成（50キロバイト）まで選択することができる。この柔軟な構成こそ、我われの成功の証しである。
　我われにとって、オープンソースは単なるキャッチフレーズではない。それは、ｅＣｏｓの技術的な原動力である。オープンソースである我われの製品は、性能面で他社製品より十倍優れている（オブジェクトレベルで様々な構成を選べることによって、メモリスペースを十倍節約できる。ソースコードにアクセス可能なＲＴＯＳにおいては、プログラマの作業効率を十倍から百倍も高められる）。そして、いままでのところ、市場からは非常に好ましい反応が返ってきている。
　ＧＮＵを基盤とするかつてのビジネスではいろいろと不可能なこともあったが、ｅＣｏｓはシグナスソリューションズ社と世界のために様々な可能性をもたらしてくれるに違いない。


未来への展望
　オープンソースソフトウェアは、技術的市場が元々持ちあわせている効率を引き出すことができる。しかし、その作用のしかたは、組織的でありながら予測がつかず、いわばアダム・スミスの言うところの「見えざる手」のような働きをする。オープンソースビジネスでは、この「見えざる手」が市場全体を救済すると同時に、個々の企業がミクロ経済的目標を達成する手助けとなる。オープンソースビジネスで最大の成功をおさめるところは、インターネットコミュニティから最大限の協力を引き出せる形で技術力を伸ばせるところであり、ユーザコミュニティがつきつける技術面・ビジネス面の課題をうまく解決できるところだろう。
　オープンソースソフトウェアから生まれたインターネットは、新たなオープンソースソフトウェアを生み出す大きな原動力となっている。人びとがインターネットやオープンソースを利用し続けるに従い、学問的な知識の開発方法や利用方法がルネサンスによって変化したのと同じように、ソフトウェアの開発方法や利用方法も変化していくことであろう。そして私は、オープンソースソフトウェアが与えてくれる自由があれば、ほかには何も望まない。