そろそろSeasar2のガラパゴス戦略について語っておくか

Slim3のファーストリリース(今月中)の前に、Seasar2の開発で、どのような戦略をとったのか話しておきます。

2005/11/8、Seasar2.3のバージョンをリリースしました。このバージョンから搭載されたのが、コンポーネントの自動登録機能です。設定ファイル無しで開発できるようにする機能ですね。Springだと2.5から搭載されたcomponent-scan。
Spring2.5のリリースは、2007/11/19なので、実に2年以上差があります。オープンソースの世界では、みんなが手の内を見せ合っているので、誰かが新しい機能を実装した場合、それが良いものであれば、ライバルも直ぐにそれを取り入れ、それほど機能差がつくことはありません。
なぜ、従来のXML地獄を解消する「コンポーネントの自動登録機能」を実装するまでの期間にこれほど差が出たのか、それはガラパゴス戦略のせいなのです。

Seasar2.3のリリース後、ドキュメントの英語化もすすめていて、JavaOneでの発表後、海外のユーザ向けにもアピールするつもりでいました。で、JavaOneに行ってみての感想は、Springは、かなり海外のマーケットでは、人気があるなということでした。
がちんこで、勝負しても、手の内を見せ合っていれば、技術的な優位性は短期間で追いつかれてなくなってしまうので、最終的には、今のマーケットリーダー(Spring)が勝ち残るだろうと判断しました。

そこで、私のとった戦略は、日本国内に専念し、技術的な優位性を保ったまま、日本のDIコンテナのマーケットリーダーになることです。2006年当時は、日本のDIコンテナは、まだマーケットが小さく、リーダー不在だったから。
国内に専念し、情報も全部日本語にすることで、日本のユーザーにとっては敷居が低く、海外には情報が流れなくなります。隔離された環境で、独自の進化を遂げるガラパゴス戦略です。

独自の進化といっても、海外の情報はほとんどリアルタイムに手にすることができ、その上で次の手を考えることができるので、独自の進化というより、相手の打つ手を見たうえで自分の手を打ち、自分の打った手は相手に見えない状態といったほうがいいかもしれません。

これは、ずるい。
そう思われた方も多いと思いますが、これも1つの戦略です。グローバルなマーケットを狙わないというリスクも当然あります。その当時、Seasar2が生き残る可能性がもっとも高いと思う戦略を選んだのです。
後、三菱東京UFJがSeasar2を採用したというニュースを流せることがわかっていたのも、国内に専念しようと思った大きな理由の1つです。国内で有利に働くからね。

じゃ、今の日本のDIコンテナのマーケットがどうなっているかというと、オープンソースのプロダクトは、シェアとか調べるのが難しいのですが、2008年5月に某大手調査機関の調査ではSeasar2のほうが上、Linux Foundation Japanが調べたOSSの利用実績でもSeasar2(S2Dao)が◎にたいして、Springは○となっているので、一応、客観的には、Seasar2の方が多いのではないかと思います。

今のSeasar2のユーザは、SAStrutsを使っている人が多いのではないかと思いますが、上記の数字は、SAStrutsが使われるようになる前の話なので、今はさらにシェアはあがっているはずです。

後、Seasar2を評価するときに、HOT reloading(アプリケーションサーバを立ち上げたままで、変更したクラスをリロードする仕組み:前はHOT deployっていってたけどTomcatのHOT deployと同じようなものと勘違いされることが多いので言い方を変えました。今後はHOT reloadingというようにします)なしで評価しちゃだめですよ。

SAStrutsが使いやすいのも、HOT reloadingによるさくさく開発ができるからってのが大きいから。

Seasar2.3とSpring2.5は大体同じようなものですが、Seasar2.4からは、HOT reloadingができるようになっているので大きく違います。

Seasar2のユーザーは、自信を持ってSeasar2を使っていいよ。フルスタック(Seasar2, SAStruts, S2JDBC)でそう簡単には追いつかれないから。

日本の携帯のガラパゴス化が失敗したのは、日本のマーケットが飽和し、高い開発費をまかなえなくなったから。オープンソースの世界だと、開発費が高くつくことはない(Seasar2はもう開発をしていないので維持費はかなり低い)し、マーケットが飽和してもかまわないので、ガラパゴス戦略は必ずしも悪いものではないのです。