ソフトウェアはコモディティ化に向いている。電子データとして流通が可能なため物理的な距離を簡単に超えられる。ソフトウェアでは、オープンソースが知識の媒質として働き、シェアされることで高機能化された。しかし、オープンソースばかりがコモディティ化ではない。
サービス型コンポーネント
オープンソースにしなくともオープンになれる方法がある。それがGoogle MapやAmazon Webサービスに代表される"APIの公開"だろう。これは梅田さんが指摘するWeb2.0という姿だ。My Life Between Silicon Valley and JapanのWeb 2.0、Remix、Mash-upsより、
Web 2.0の世界とは、この文章中にあらわれる「Remix」という言葉や「Mash-ups」という言葉に象徴されるように、ウェブ上に存在する無数の無関係なサイトのデータやサービスを、誰もが自由に組み合わせて新しいサービスを増殖させていくことができる世界なのである。「ウェブ上に存在する無数のサービスやデータ」は、「ある種のグローバルOS」へと変貌していくということである。
つまり、"APIを通じてサービスとして扱えるコンポーネント"＝サービス型コンポーネントにとっては、オープンソースにすることよりも、使いやすいオープンなAPIを用意することが重要なのだろう。そうすればコミュニティのオープン性は保たれるわけだ。AmazonもGoogleも公開されたAPIに対するフィードバックを受けながら更新を繰り返しているだろう。
オープンソースであることに越したことは無いけど、十分に高機能であるならその必要性もないもかもしれない。ちゃんと動いてくれればそれでいいわけである。
フレームワーク型コンポーネント
一方で、APIを通じて利用するわけではなく、そのコンポーネントを組み込んで利用するというパターンがある。それをフレームワーク型のコンポーネントと呼んでみる。フレームワーク型コンポーネントにはStruts、Spring、HibernateなどのWebアプリケーションフレームワークやGeronimoやJBossのようなサーバコンテナ、そしてEclipseのような開発ツールが含まれることになる。
これはオープンソースであることが望まれるだろう。フレームワーク型コンポーネントは、利用者のアプリケーションの一部として強く依存している。そのため細かい使い勝手を理解する必要性が発生するためオープンソースであることが望ましい（POJOであっても、POJOを動かす環境が必要であるという意味では依存していると考えて欲しい）。
オープンソースとオープンなAPI
オープンソースとオープンなAPIは、どちらにしてもソフトウェアのコモディティ化を進めてくれるだろう。どちらが良いと言うよりも、バランスをうまく取る必要性があると感じる。たとえばパッケージアプリケーションであればカスタマイズのために、"APIを公開するべき部分"と"コードを公開する部分"という切り分けがあっても良いと感じる。もちろん、サービスとフレームワークの区切りがどこなんだという課題はあるだろう。
SOAが実現されてくると、こうした切り分けが注目されるはずだ。センスの良いAPIが求められるわけである。いや、むしろ柔軟にAPIを変化させるといった方が重要かもしれない。一部のDIコンテナでは、"DIコンテナで組み上げられたPOJO達"を１つのサービスとして捉え、その単位で1つのJARファイルとしてデプロイするというアイデアが試されている。こうすればサービスの構成単位を柔軟に変更できるため、APIの変更も容易になる（実際にはPOJO同士の複雑な依存性の解決など実用に至るまでの検討点は多いのだが）。
オープンソースだけでなく、オープンなAPIにも目を向けるべきだろう。なんか、漠然としたエントリになってしまったのは、それだけ僕の中でも漠然としているということだろう。もしかしたら、Web2.0というだけでなく、アプリケーションアーキテクチャ2.0と呼べるものなのかもしれない。
