OSSはなぜ生まれ、誰が保守しているのか。その事情はソフトごとに異なる。そしてOSSがゾンビ化するリスクは、開発事情に大きく依存している。本パートでは開発事情によってOSSを大きく五つに分類。それぞれについて、ゾンビ化のリスクを分析する。

 本誌はOSSを開発事情によって以下の五つに分類する。「新機能追求型」「サポートビジネス型」「マーケティング型」「呉越同舟型」「特殊事情型」だ。それぞれのリスクを見ていく。

リスク高:新機能追求型

 既存の商用ソフトにはない新機能の実現を目指して開発された「新機能追求型」のOSSは、ゾンビ化するリスクが最も高い。

 ゾンビ化するパターンは大きく三つある。(1)新機能が他のソフトでも実現可能になることで、そのOSSの存在意義が無くなるパターン、(2)新機能を実現するOSSが乱立した結果、競争に敗北するパターン、(3)新機能を追求するあまり旧バージョンのサポートがおろそかになるパターンである。

 (1)のパターンの代表例は、Struts 1などのJavaアプリケーションフレームワークだ。標準仕様であるJava EEがOSSのフレームワークが備える機能をそのまま仕様に取り込み始めた結果、存在意義が無くなり、開発が停滞するOSSが出現した(図4)。

図4 「Java EE」の歴史
先行OSSの機能を本流が吸収
図4 「Java EE」の歴史
[画像のクリックで拡大表示]

 日本生まれのOSSフレームワークで、システム連携を容易にできる「Seasar2」も、2008年1月をもって新規バージョンの開発が終了した。Seasar2の商用サポートを提供している電通国際情報サービスは「顧客が存在する限り、バグ修正などのメンテナンスを継続する」(開発技術部の中村年宏プロジェクトリーダー)としている。しかし「数年前までは新規開発にSeasar2を使うケースもあったが、今は使っていない」(TISの油谷実紀 戦略技術センター長)という声が増えている。

10種類以上が乱立することも

 (2)の乱立パターンの代表例は、ビッグデータ処理ソフトHadoopの周辺ソフトだ。Hadoopをバッチ処理以外の用途に使うために、様々な周辺ソフトがOSSとして登場している。しかしこれらOSSの中には、同じ機能を実現する他のOSSとの競争に敗北し、開発が止まったものがある。