2009-08-22
■ オープンソースにすると企業は損をするんじゃないですかという質問 
セキュリティ＆プログラミングキャンプ2009のわたしの講義で、「オープンソースにすると企業は損をするんじゃないですか」という本質をとらえた質問がでて、講師陣が、いきなりいろいろ議論を始めた。
企業の行動原理は、利益の追求だから、利益を生まないアクティビティは原則として行わない。オープンソースも例外ではない。
利益＝売上-経費 なので売上が増えるか、経費が減るかという観点から投資判断をする。当たり前ですな。
例えばマイクロソフトが自社の製品をオープンソースにすると、売上が伸びるか、あるいは経費が減るかというと、どちらもそうとは言えないので、マイクロソフトが自社製品をオープンソース化することは考えられない。先日マイクロソフトがHyper-V向けのLinuxドライバをGPLで公開したことが話題になったが、Linuxドライバを公開する事が自社のHyper-Vの魅力を増し、売上向上を期待して公開したということであろう。ライセンスはLinuxの場合、GPLにならざるおえない。公開するかしないか、どのようなライセンスを選ぶかは技術的な問題というよりも経営的な判断である。
大手ハードウェアベンダーがLinux開発に貢献するのは、例えば自社のハードウェアの売上を伸ばしたい、あるいは独自OS開発のコスト負担には耐えられないので、OSS(Opensource Software)プロジェクトに参加することで経費を削減したいなどの思惑があるのだろう。
出来合いのOSSプロジェクトに参加することで、ゼロから開発するよりも早く開発できて開発費も削減できる。この意味では損はしない。得である。問題は自分の作ったソースを公開するか、しないか、どのライセンスを選ぶかである。
ゼロからソフトウェアを作る場合、それをプロプライエタリにして公開しないという選択肢は、それはそれでリーズナブルな選択なのでここでは議論しない。
既存のOSSの場合、BSD的な独自拡張部分の公開の義務のないライセンスがいいのか、GPLのような、変更部分も含めて公開義務のあるライセンスがいいのか、どちらを選択するのが理にかなっているかという問題である。
会場の講師から、自社でルータを作ったときにBSDライセンスで、ソースコードの公開をしなかったという事例の発言があった。独自技術にこだわりがあって、それを公開するとノウハウが流出するという懸念から公開をしなかったというお話であった。公開しないことにより、売上が伸びたかというと、別にそれは関係ないし、経費が削減されたかというとそういうこともなかった。むしろ、OSSの元の方がどんどんバージョンアップしていったのだけど、独自拡張の部分は、開発コストの関係で、バージョンアップに追随するのが難しかったということであった。最終的には経営判断なのであるが、メンテナンスコストも含めて考えると、BSD的な独自部分を公開しないという方法は中期的にはコスト高なのではないだろうか。
GPLの場合、独自技術を隠蔽することが難しいという懸念はあるが、自社で開発した部分をコミュニティに公開してメインラインにマージしておけば、メインラインがどんどんバージョンアップして行っても、ほとんどコストゼロで機能拡張に追随できる。これは開発コストを激減する。魅力的な機能がコミュニティによってどんどん開発されるので、その商品の魅力が増すことも期待できる。
一方で独自追加部分が競合他社にも無償で利用される。それを懸念するむきもある。フリーライドされるという懸念である。フリーライドされたからといいって、自社開発コストが増えるかというと、そうではなくて、他社製品が売れて、自社の製品の売上が下がる可能性がある。自由市場経済である以上それはしょうがない。しかし、仮に競合がその機能をさらに拡張したとしたら、その機能も公開しなければならないので、その機能についての開発費は削減できる。プラスマイナスゼロである。最初にその機能を作った組織には影響力やノウハウの蓄積というアドバンテージがあるので若干プラスという感じである。
BSDと比較してGPLは、独自技術を隠蔽しにくいので、技術革新がどんどん蓄積され、無駄な重複開発がなくなり、コミュニティ全体としての生産性が極めて高い。BSDはそれぞれの開発組織が蛸壺にハマりやすく、コミュニティが分断され重複開発が発生する。
■ WISH2009に行ってきた 
日本の「Webを元気にする」WISH2009というイベントに行ってきた。
http://agilemedia.jp/wish2009/
会場が分からなくて、九段下をうろちょろして、汗だくになり、結局九段下交差点の交番で聞いた。お巡りさんありがとう。30分はまよったな。
会場は超満員、立ち見あり。遅刻していったので、席は当然ないのだが、一番前の急遽しつらえた椅子が空いていたのでずんずん前に行って座った。近所にokdtさんとかyasuyukimaさんがいた。
どのサービスも面白かったなあ。ハードを使ったプレゼンは掴みはすごいねと思った。
面白いサービスをビジネスにする経営層が日本には足りないと常日頃思っているので、このネタをぜひ商売にしてほしいとなどと考えたのだけど、どーすればいいのか回答はない。
結論もオチもなくてすいません（ぺこり）
・誰のために作られたソフトウェアか
・最初から公開されることを意図したつくりになっているか
・そのソフトウェアは「他者の権利」を侵害してはいないか
・そのソフトウェアを作るのにかかった経費は「原価性」が高いかどうか
・かかった経費を「投資」として扱う際に、まっとうな理が立つか
細かい話、と言われそうですが、企業が出す際にはこういう点も含めた（というよりは、むしろこういう点の）議論が必須ですね。
これらの部分がクリアになれば、あとは技術的な面での議論に注力できるのではないかと。
というのはちょっと無理がありませんかね。
他の部分の修正によって互換性がなくなったあげく、誰もメンテできなくなって、とりあえず、放置されるというのは普通に良くあることです。悲しいことに。
結局、自分たちでメンテに工数を割くことができない企業をオープンソースが加勢してくれるなんて言うのは幻想だと思います。
むしろ、自主的なコミット(労働力の提供)があってこその、オープンソースとの連携・協業ではないでしょうか。
コメントありがとうございます。企業がソフトウェアを発表する時には、オープンソースであろうが、クローズにするかに関わらずご指摘の点は重要ですね。公開されることを意図した作りというのがちょっと微妙ですが。
>通りすがりさん
他の部分の修正によって互換性がなくなるというのは、時としてありますね。しかし、その確率は、上流にマージしていない場合とした場合では、した場合の方が小さいと期待できます。メンテの工数がゼロになるというのはさすがに言い過ぎでしょうが、少なくすることはできるかと思います。
互換性については、リグレッションテストを同時に作成し、上流にマージしておく事で、ある程度自動的に発見できるようになります。
>marblejenkaさん
コメントありがとうございます。当該図書が手元にないので「補完財の価格破壊」が何を意味するか理解していませんが、OSSの戦略的価値については、今回の議論ではふれていません。
・プロプライエタリなコードを含んでいないか、また分離することが容易か
というだけの話です。
特に、企業内で使われている（クローズドな）ライブラリがあることを前提としたつくりとか、クローズドなコードをコピペしている場合には、そこの修正工数とかが結構バカにならんという認識です。
その他はどちらかというと、財務面（コンプラ面）の懸案事項という認識です。