« スクリプティング with JavaEE:JRuby on Rails寄稿 | メイン | [JSUG]9/7 SpringBatchコードハックス勉強会 »

オープン性のポートフォリオ

 ウィキノミクスを読んでいると繰り返し出てくるのが「どこまでオープンであるべきか」「どこまで共有してよいか」という問いかけです。本の中でも、これをポートフォリオとして管理すべきだと書かれています。


オープン性のポートフォリオとは
 こちらのサイトによれば

ポートフォリオとは、証券用語辞典を引くと“Portfolio 資産管理”と出ています。ひとりひとりの投資家が、現在持っている金融資産をトータルで指す言葉です。

それぞれの投資家が必要とする年間の収益と、それに見合ったリスクの度合いに基づいて分散投資されることになります。

投資先を一箇所に集中させずに、できるだけ分散させた金融商品で資産運用を行うこと、つまりリスクを回避すること、これがポートフォリオを作成する最大の目的です。

ということです。より戦略的に書けば金融商品ごとの安定性や収益性を考慮し、相関の低い組み合わせることでリスクを低減しながら投資を行うことをしめします。転じてオープン性のポートフォリオとは、企業は持つソフトウェアや手法全体のことであり、機密性や収益性を考慮し、それぞれのオープン性を管理することといえます。


なぜポートフォリオとして管理するか
 オープン化は強力な武器となります。IBMのLinux、Eclipseをはじめオープン化を行うことで長期的なパフォーマンスを確保することができましたす。クローズに守りすぎてしまうと進化のドライバーとなるべき人たち(研究者やコントリビューター)まで締め出してしまう。

 一方で、すべてオープン化してしまうとオープンすぎるがゆえの問題も生じます。投資の対価が得られないことから投資額が減少してしまったり、すぐに開示要求が来てしまうことから過度の秘密主義を促進してしまうことなどです。

 ようはバランスが重要なわけです。


何を、どのようにオープンにするか
 では自分たちにとって適正なバランスとはなにか。といってもバランスの取り方に正解はありません(金融投資と同じ)。というわけでソフトウェアでメジャーな事例を考えてみます。

 IBMは2つの手法を使いわけるようです。1つは商用利用が可能で改変後の開示義務がないApache Licenseによるオープンソース化。もう1つはソースコードはオープンにはなるがIBMが権利を持ち商用化を前提としたCommunity Driven Commercial Development processです。
 プロダクト適用のレベルでいっても、OSSをそのまま使うLinux、ほぼそのまま適用しているであろうばApache(WebSphere HTTP Server)やGeronimo(WebSphere Application Server Community Edition)、実験的な実装をしているようにみえるTomcat(WebSphere)など様々です。

 SUNのOSSっぽいライセンスは評判が悪いわけですが、現状ではSolaris、SPARCチップアーキテクチャがオープンになり、Java SEとJava MEはGPLで公開されました(これも、細かい話がいっぱいあるのですがめんどいので説明は省きます)。あ、こいつはBSDライセンスですね;-)。

 面白いのはMySQLの考え方です。MySQLはGPLライセンスと商用ライセンスのどちらかを選択するこデュアルライセンス方式になっています。簡単にいえば、お金を払うとGPLライセンスの改変後公開義務から解放されます。GPLは厳しいことで知られているので、以下のような場合でソースコードを公開したくない場合は有償ライセンスを購入する必要があります(参考:ライセンスについて)。
■MySQLを含んだソフトウェアを顧客に販売し、顧客が自身のマシンに当該ソフトウェアをインストールする場合
■ソフトウェアを顧客に販売し、そのソフトウェアを使う顧客が自身のマシンにMySQLをインストールする必要がある場合
■MySQLを含んだハードウェアシステムを構築、顧客に販売し、当該ハードウェアシステムを顧客の場所に設置する場合

 SugarCRMではOpen source版をMozilla Public Licenseを派生させたGPLライクなSUGARCRM PUBLIC LICENSEで配布しています(次のバージョンからはGPL v3になるみたい)。そのほかにサポートや機能追加をしたEnterprise版やProfessional版を販売しています。

 他には(成功したとはいえない)Linuxにおけるディストリビューターの考え方が有名です。あとはSpringframeworkにおけるInterface21はコンサルビジネスなどで儲かっているようです。
 
 こういった事例の研究が学術的に進んでくれば、もうすこしシンプルなパターンが見えてくる気がします。


オープンな文化を受け入れること
 最後に忘れてはならないこと。このポートフォリオは戦略的に考えられるべきですがオープンにすればメリットがあるというものではありません。オープンにするということはコミュニティの文化を受け入れることです。それができないのにオープンにしても意味がありません。
 オープンにするというのは、単にコードや手法をオープンにするということだけではなく企業の文化や組織をオープンにすることなのですから。


482224587Xウィキノミクス マスコラボレーションによる開発・生産の世紀へ
ドン・タプスコット/アンソニー・D・ウィリアムズ 井口 耕二
日経BP社 2007-06-07

by G-Tools

トラックバック

このエントリーのトラックバックURL:
http://www.arclamp.jp/mt33/mt-tracback.cgi/2346

コメントを投稿

(いままで、ここでコメントしたことがないときは、コメントを表示する前にこのブログのオーナーの承認が必要になることがあります。承認されるまではコメントは表示されません。そのときはしばらく待ってください。)

About

2007年08月23日 23:45に投稿されたエントリーのページです。

ひとつ前の投稿は「スクリプティング with JavaEE:JRuby on Rails寄稿」です。

次の投稿は「[JSUG]9/7 SpringBatchコードハックス勉強会」です。

他にも多くのエントリーがあります。メインページアーカイブページも見てください。

Creative Commons License
このブログは、次のライセンスで保護されています。 クリエイティブ・コモンズ・ライセンス.
Powered by
Movable Type