『オープンソースソフトウェア 彼らはいかにしてビジネススタンダードになったのか』を読んだので、ご紹介します。
OSS（Open Source Software、オープンソースソフトウェア）の歴史を学ぶために、この本を読みました。
以下、印象に残った箇所の引用とメモです。
オープンソース運動にとって、プロトコルなどの標準化プロセスをオープンにすることと、すべてのドキュメントを公開することは不可欠である。オープンソース運動のような分散型の開発作業では、標準ドキュメントを使って作業内容の仕様を明確にする。標準ドキュメントがなければ、開発の意思統一がとれず、作業はばらばらで収集のつかないものになってしまう。オープンスタンダード、オープンドキュメント、そしてオープンソースは、もともとパートナーの関係にあるものである。インターネットを生み出したこのパートナーシップは、これからも多くの偉業をなしとげるにちがいない。
📝上手く活用したい。
📝（余談）自分が大学ではじめて触れたGNU Emacsの成り立ちを知れて、知的好奇心が満たされた。
フリーソフトウェアの理念は、ある種のビジネス慣行とは相容れないものである。しかし、ビジネスそれ自体を否定するものではない。我われは、ユーザ側の自由を尊重するビジネスには成功してほしいと思っている。
📝現在、自分はOSSビジネスモデルを探っているので「フリーソフトウェアの理念」を尊重して取り組んでいきたい。
多くの開発プログラマにとって、エンジニアを創業者とし、オープンソースのビジネスモデルにのっとり独自の文化を構築しながら、オープンソースの世界をリードする技術者集団を率いるシグナスソリューションズ社で働けることは、非常に魅力的な話だった。そのため、わが社におけるエンジニアの離職率は、全国平均（とりわけシリコンバレーの平均）の四分の一から十分の一ほどであった。
📝似たような状態にしたい。
これも皮肉な話だが、我われは、なんでもかんでもオープンソースにして（従来のビジネス慣行に沿った）クローズドなコンポーネントをビジネスに取り入れようとしないマネージャも不適格者とした。我われにとって、オープンソースはビジネス戦略であってイデオロギーではなかった。我われには、オープンソース製品とクローズドソース製品の両方を柔軟に使い分けて、会社の総合的な目標を達成しようとする人物でなければ、マネージャとして働いてもらうつもりはなかった。
📝この観点は参考になるし、そう思う。
結局我われは、オープンソースのビジネスモデルのなんたるかをたちどころに理解できる人材を探しもとめるべきではない、という結論に達した。シグナスソリューションズ社の必要とするマネージャになってもらう人たちには、失敗することを許さなければならない（つまり、彼らの失敗もコストに計上しなければならない）。そして、彼らには自分の失敗から学んでもらわなければならない。これまで他社でマネージャとして勤務していた人ほど、自分の経験にあうようにシグナスソリューションズ社のやり方を変えようとする。それが彼らがこの会社で成功できない原因だった。これまでの経験を生かせると同時に、ここでの経験から学べるマネージャを見つけることは至難の業だった。しかも、我われはそのような人材を何十人も必要としていた。
📝マネージャーの採用難易度が高い。
オープンソースのビジネスモデルには、いろいろ克服すべき課題があったが、シグナスソリューションズ社は素早く体制を立て直した。見込み違いや手違いで顧客を失うこともあったものの、年間契約更新率は、一九九三年以来、ドル換算でほぼ90％を保っている。顧客を失う原因のトップは、プロジェクトが終了したことによる「引き上げ」である。他の会社なら失敗したような状況で我われが生き延びられたのにはふたつの要因があった。（1）肩書や経験年数の如何にかかわらず、シグナスソリューションズ社のエンジニアは全員が顧客への責任を果たす重要性を認識していた（顧客のサポートだけに専念した）。（2）すべてが失敗に終わっても、顧客がソースコードを持っていたため、顧客自身で後始末ができた。したがって、当時のすさまじい状況にかかわらず、期待どおりにならなかったために貧乏くじを引いた顧客はほとんどいなかった。商用ソフトウェアを使う会社に頼んで貧乏くじを引いてしまった話や、サポートのないオープンソースソフトウェアでひどい目にあったところの話を当時よく耳にしたが、シグナスソリューションズ社はそれらと好対照をなすケースであった。
📝ワーストシナリオを考えると、OSSビジネスモデルは良い選択肢。
オープンソースソフトウェアは、技術的市場が元々持ちあわせている効率を引き出すことができる。しかし、その作用のしかたは、組織的でありながら予測がつかず、いわばアダム・スミスの言うところの「見えざる手」のような働きをする。オープンソースビジネスでは、この「見えざる手」が市場全体を救済すると同時に、個々の企業がミクロ経済的目標を達成する手助けとなる。オープンソースビジネスで最大の成功をおさめるところは、インターネットコミュニティから最大限の協力を引き出せる形で技術力を伸ばせるところであり、ユーザコミュニティがつきつける技術面・ビジネス面の課題をうまく解決できるところだろう。
📝この本が出版されてから、25年経っても変わって無い観点という理解。
オープンソースソフトウェアから生まれたインターネットは、新たなオープンソースソフトウェアを生み出す大きな原動力となっている。人びとがインターネットやオープンソースを利用し続けるに従い、学問的な知識の開発方法や利用方法がルネサンスによって変化したのと同じように、ソフトウェアの開発方法や利用方法も変化していくことであろう。そして私は、オープンソースソフトウェアが与えてくれる自由があれば、ほかには何も望まない。
📝原動力を味方に付けたい。
オープンソースプロジェクトで一番多いのは、それに携わっている人たちが自分のやっていることを楽しんでいるというケースである。彼らは、自分が作ったものをできるだけ大勢の人に使ってもらいたいとの思いから、ソフトウェアをただで配ることが多い。再配布時の制限もつけないことが多い。こういった人たちは、往々にして、いわゆる「商品として出回っているソフトウェア開発ツール」を使える環境にいない（たとえば、コードカバリッジアナライザ（code coverage analyzer）、バウンズチェッキングインタープリタ（bounds-checking interpreter）、メモリインテグリティベリファイア（memory integrity verifirer）などを使える環境で開発作業をしていない）。彼らは、コーディングやパッケージ化は喜んでする。ソフトウェアのよさを説いてまわることも喜んでする。しかし、品質管理や要求仕様のまとめをちゃんとすることとか、開発スケジュールを厳守することにはあまり関心がない。 以下では、ソフトウェア開発の工学的アプローチに含まれる工程をもう一度取り上げ、開発資金を持たぬオープンソースプロジェクト、つまり「ボランティアでする仕事」において、どんなことが実際に行なわれているかを考察してみよう。
📝OSSをやる場合、プロジェクトマネジメントの考え方をチューニングする必要がある。以降の「ソフトウェア開発の工程」はすべて一読していただきたい。
レッドハット・ソフトウェア社のビジネスチャンスは、ブランドネームを浸透させることにあった。利便性のあるものを提供すること、高品質なものを提供すること、そして、オペレーティングシステムのあるべき姿を顧客のイメージに焼きつけられれば、レッドハット・ソフトウェア社にもチャンスはある。高品質の製品とユーザサポートをたえず提供し続けることができれば、レッドハット・ソフトウェア社は、Ｌｉｎｕｘユーザが無条件に好むブランドになることができる。
📝ビジネスチャンスは、ブランドネームを浸透させることにある。
たいていの先進国では、手近にある蛇口をひねれば飲料水が水道から出てくる。それなのになぜ、エヴィアン社のフランス産飲料水が数百万ドル分も市場で売れているのだろうか？ それはつまり、我われが、水道水は信用できないのではないかというばかげた不安を抱いているからである。 多くの人が五○ドル出してＲｅｄ Ｈａｔ Ｌｉｎｕｘの「オフィシャル」ボックスを買うのも、そっちのほうが無料でダウンロードできるものや、たったの二ドルで手にはいるＣＤ－ＲＯＭ版非公式コピーより信用できるからである。我われレッドハット・ソフトウェア社は、自社ブランドを売り込む市場を作るために、多くのＬｉｎｕｘユーザを獲得しなければならない。しかし、レッドハット・ソフトウェア社は、人類の大部分が飲む水を売る商売をしているエヴィアン社のように恵まれたビジネス環境にはいない。それはどう克服すべきなのだろうか？
📝水を売る商売、信用を売る商売に学ぶ。
ブランドは、技術力を売りものにするビジネスでは大きな力となりうる。その証拠に、いくつかのベンチャーキャピタルが、最近になってオープンソースソフトウェア関連のビジネスに投資している。いままでのところ、そのような投資対象のすべてに共通する特徴は、企業もしくはその製品の知名度が高いことと、製品の質の高さが認知されていることである。要するに、ブランドの確立に成功した企業である。
📝ブランドの確立が肝。
企業は、開発プロジェクトの救済を目的としてオープンソースの採用を検討するかもしれない。知名度を上げることを考えてそうするかもしれない。あるいは、ひとつの製品に有終の美を飾らせるためにそうするかもしれない。しかし、これらはいずれも、オープンソース方式を採用する理由としては適切でない。オープンソース方式の採用にあたっては、どのような製品であったらオープンソースとして成功するかを独自に調査し、その結果を厳密に検討しなければならない。
📝OSS方式を採用前に、独自調査と検討は必須。
自社製品またはそのコンポーネントのオープンソース化を決定するには、それがどのような部類のソフトウェアであるかを明確に把握しなければならない。ソフトウェア全体における位置づけを把握する簡単な方法は、まず、「インフラストラクチャの部類」と「エンドユーザアプリケーションの部類」を左右に割り振る直線を上から下に一本引く。
📝自社製品の位置づけを把握する方法。
さて、自社製品と競合製品の位置づけが済んだら、用紙に描きだされた分析結果をもとに、直線を上下に真直ぐ引いて、オープンソース化する部分としない部分を用紙上で分割する。つまり、この直線こそ、オープンソース化することであなたが標準化しようとしているソースコードの部分と、非公開のままにしながら需要を喚起しようとしているソースコードの部分の境目であり、両者のインターフェイスであり、本当の意味で、あなたの会社の製品のプラットフォームにあたる部分なのである。
📝自社製品の本当の意味でのプラットフォームの部分がわかる。
ちょっと複雑なオープンソースプロジェクトとして、ウェブショッピングを可能にするプラグインモジュール（common shopping cart plug-in）の開発が考えられる。簡単なプロトコルを実装したネットワークデーモンを開発するのもちょっと複雑な部類に入る。そのようなプロジェクトを推進するのに最低限必要と思われる人的資源を、彼らに求められる役割と技術ごとに記述すると、次の五つに分類される。
- 必要とされる人的資源（1）インフラストラクチャをサポートする人間。
- 必要とされる人的資源（2）プロジェクト参加者から寄せられてくるソースコードを統括的に管理し、その実装について全責任を負う人間（コードキャプテン（Code captain））。
- 必要とされる人的資源（3）バグデータベースをメンテナンスする人間。
- 必要とされる人的資源（4）各種ドキュメントおよびウェブコンテンツをメンテナンスする人間。
- 必要とされる人的資源（5）エバンジェリスト／戦略家。
ここにあげた五つの役割は、だいたい常勤者三人分の仕事に相当する。
📝最新のLicense事情は書かれてないが、今も使われているLicenseについても言及されており、勉強になる。
ビジネスの観点からすると、ＢＳＤ方式のライセンスは、今後の使用・再配布の許可や制限について心配する必要がないため、既存のプロジェクトに参加する形でオープンソース化を推進する場合にはうってつけの選択である。あなたは、この種のオープンソースソフトウェアに（自社が知的所有権を持つ）コードを組み合わせて使うことができる。プロジェクトのためになる－したがって自分のためになる－と思うコード以外は提供しない選択も可能である。
ＢＳＤ方式のライセンスは、非常に寛大である。しかし、そこまで寛大になるには様々なリスクを負わなければならない。このライセンスは、自分で独自に機能拡張した部分のソースコードを、元のプロジェクトに還元させるようには書かれていない。そして、Ａｐａｃｈｅにおいても、複数の企業が独自に派生的な技術を開発し、中にはプロジェクトに提供してほしいようなものもあったが、実際には提供されていない。とはいえ、もし独自に機能拡張した部分を還元するようにライセンスで義務づけられていれば、それらの企業がそのような技術の開発に着手するようなこともなかったかもしれない。 つまり、戦略的に言えば、この種のライセンスが適用されるプロジェクトでは、十分な勢いを維持しながら開発作業を進めていく必要がある。参加メンバーが、（知的所有権を有する部分を含む）自社のコードを提供することで、プロジェクトがより大きな価値を生み出せると思えなければならない。これはなかなか難しい問題である。特に、厄介なのは、参加企業が、コーディングの量を大幅に増やすことにしたときである。その企業が、それだけ貢献する見返りはあるのだろうかと考え始めたりすると、「うちはどの参加者よりも貢献しているのに、なぜそれを共有しなければならないのか」ということになる。もちろん、そのような企業は、第三者の協力をとりつけて自身の技術的な目標を効率的に達成する最善の方法を見出せずにいるので、そう考えたりするのだが、この問題を解決する特効薬はいまのところ存在しない。
ＭＰＬでは、ＭＰＬのライセンスのもとに配布されたソフトウェアを修正・変更した場合、その部分はフリーで公開されなければならない。そのため、オリジナルへの変更は、オリジナルの開発プロジェクトに還元されるようになっている。ＭＰＬでは、オリジナルをソースコードとして配布されたファイルと規定している。これは重要である。なぜなら、この規定によって、企業は、商用ライブラリへのインターフェイスを作成しても、インターフェイス部分をＭＰＬするだけで済むからである。ＭＰＬライセンスは、オープンソースのソフトウェアを他の商用ソフトウェアに含ませやすい形で提供できる。 ＭＰＬにはいくつかの条項があり、プロジェクト全体と開発者の双方を、提供ソースコードの特許にかかわる問題から保護している。ＭＰＬでは、企業や個人がソースコードをプロジェクトに提供する場合には、そのソースコードによって将来発生するであろう特許権に対する主張を放棄することになっている。
📝現在はMPL-2.0
ＧＰＬは、ビジネスに好都合なライセンスでない。しかし、信じる信じないは別として、営利を追究するうえで魅力的な側面を持っている。
これをビジネスモデルとして実行している企業もある。たとえば、カリフォルニア州バークレーにあるトランスバーチャル社は、このモデルを採用して、Ｊａｖａ仮想マシンや完全なクラスライブラリを含む商用バージョンのＪａｖａ開発キット簡易版を開発している。このような開発モデルに対しては、プロジェクト参加者の多くから反感を買いやすいとか、ＧＰＬバージョンと商用バージョンが別々のコードを持つようになってしまう危険性があると指摘する人たちもいる。しかし、プロジェクト参加者を公正に扱い、彼らの努力と貢献に対して金銭などでの見返りを申し出れば、このモデルは機能し、（結局、増収につながる）というのが私の意見である。
📝GPLは、ビジネスで使いにくいLicenseと思いきや、ビジネスモデルとして実行している企業もようだ。
オープンソースの開発方式は、特効薬ではない。したがって、すべてのソフトウェアの開発を成功に導けるわけではない。オープンソースのプロジェクトを進めるには、それにふさわしい条件が整っていなければならない。それ自体が生命を持つような勝算のあるプロジェクトに着手するには多大な労力が必要とされる。オープンソースのプロジェクトを提案する人は、いろいろな面で少しだけフランケンシュタイン博士を見習い、こちらで薬品を調合したり、あちらで電圧をかけたりしながら、モンスターに生命を与える必要がある。成功を祈る。
📝多大な労力が必要。
📝「オープンソースの定義」についての理解の助けになる。
いろいろ課題はあるものの、オープンソースは勝利すると私は見ている。コンピュータサイエンスの学生たちに知識習得の場を提供しているＬｉｎｕｘは、彼らが卒業すると同時に社会にも出ていく。各種研究機関では、科学手法に欠かせない情報の共有を実現するために、オープンソースモデルを採用している。オープンソースにすればソフトウェアが簡単に共有できるからである。ビジネスの世界がオープンソースモデルを採用したのは、反トラスト訴訟を恐れることなく、協力して問題解決にあたれるからである。また、コンピュータプログラミングに詳しい一般の人間に自由にソフトウェアを改良してもらって、その恩恵に浴することができるからである。
📝今やOSSが世の中に溢れているので、恩恵を受けるためにはマーケティングが必要。
ネットスケープ社では、コミュニケータのソースコードの本体を「Ｍｏｚｉｌｌａ」というコード名で呼んでいた。（ネットスケープ社の元々の名前であるモザイク・コミュニケーションと日本の伝説的な怪獣ゴジラとをかけ合わせて）Ｍｏｚｉｌｌａという言葉を最初に考え出したのは、このブラウザの開発チームの一員であったジミー・ザインスキー（Jamie Zawinsky）である。Ｍｏｓａｉｃよりもはるかに強い怪獣はすさまじいでスピードで開発されたが、それとともにＭｏｚｉｌｌａという言葉もすさまじいスピードで社内に広まり、このブラウザの正式コードネームとなった。やがて、大きな緑色の怪獣は社内のジョークのネタになり、会社のマスコットになり、しまいには誰もが知っているマスコットキャラクタとなった。こうして、Ｍｏｚｉｌｌａという名前は、ナビゲータのソースコードのオープンソース版を表わすことになった。ナビゲータをオープンソース化する計画の目的は、「怪獣を自由にする」ことにあったのである。
📝Mosaic + Godzilla = Mozilla というネーミングの考え方はどこかで使いたい。
コンピュータは人間が使う道具である。ということは、ハードウェアやソフトウェアを設計する作業は、突きつめれば人間のため、すべての人類のために設計することにほかならない。 この道は長く、平坦ではない。だがそれをやってのけるのが我われの責務である。
オープンソースがあなたとともにあらんことを！
📝良いメッセージング。
以上、OSSビジネスモデルを実践していきたい、現場からお送りしました。