投稿日:

オープンではないオープンソース

最近、オープンソースソフトウェア(OSS)の成熟度を評価する、という業務が増えてきている。OSSはサーバ用途ではかなり普及してきたのになぜ今、と思われるかもしれない。今回はその理由とともに、評価を通じて実感できてきた最近のOSSコミュニティの特徴を述べたい。

OSSの成熟度とは？

まず、OSSの成熟度について触れておこう。典型的なOSSは世界中の個人・企業の開発者が協力して開発している。開発は基本的にはボランティアベースで行われているため、OSSによってはバグや脆弱性が放置されている、バージョンアップがストップしている、ということがありうる。また、ドキュメントが不十分、サポートがコミュニティのメーリングリストや掲示板のみであるため企業ユーザにとっては不便、ということもある。片や、しっかりしたOSSのコミュニティでは、バグや脆弱性対応、機能追加をスピーディに、かつ、計画的に行っているし、ドキュメントも商用ソフトウェアに劣らないレベルで整備されている。さすがにサポートはコミュニティベースだが、このようなOSSの場合には、たいてい有償でサポートサービスを提供している企業があり、しっかりとしたサポートを受けることができる。

このように一口にOSSといってもレベルはかなり異なる。商用ソフトウェアであっても多かれ少なかれ同様のばらつきはあるのだが、OSSよりは小さいし、また、企業内部の状況はわからないので問題が顕在化していないということもある。OSSの場合は個人ひとりで開発しているものからIBMのような大企業が会社を挙げて関わっているものまであるのだから、ばらつきが生じるのはやむを得ない。個人レベルのいつ開発が終わってもおかしくないような状況から、人気が出てきて開発者が増え、しっかりとした開発体制が整えられ、システマチックに開発が進められる。こうしてOSSの「成熟度」は高まっていくのである。

OSSの成熟度を評価する手法

以前のコラムでも紹介したように、OSSの成熟度を評価する手法はいくつもある。それらの手法の目的は、興味を持ったOSSが企業ユースに耐えうるかを「ある程度」客観的に評価するためである。以前国内の事例を紹介したので、今回は海外で開発された手法をいくつか紹介しよう。

まず、QualiPSoはEUのFramework Programmeと呼ばれる研究開発プログラムの支援を受けたプロジェクトである。QualiPSoプロジェクトでは法的な側面、ビジネスモデル、相互運用性などOSSに関係する幅広い研究を行っており、成熟度評価はその一部である。QualiPSoが開発した手法はソフトウェア開発能力を測るCMMを参考にしており、評価項目としては、ドキュメントの整備状況、構成管理、バグ数、テスト品質、プロジェクト管理、リスク管理など、数百にものぼる評価項目が用意されている。筆者の所感としては、厳密な評価を目指すあまり、項目数があまりにも多いと感じる。外部の第三者が評価するにせよ、コミュニティ自らが評価するにせよ、かなりのコストがかかるのは間違いない。

他の手法はより現実的な手法である。QSOS、Navica OSSM、OpenBRR等の手法はせいぜい数10の評価項目である。これでも複数のOSSを比較したり、新規に導入する検討材料とするのには十分な評価ができる。

OSSの成熟度評価が増加する理由

さて、最初に戻るが、ここ数年で成熟度評価に関する業務が増加している理由は次のように考えている。

まず、OSSが注目され始めた2000年代前半は、成熟度評価以前に、「そもそもOSSって何？誰が開発しているの？ハッカーって誰？無料じゃ品質が悪いのでは？」などなど、疑問ばかりであった。したがって、OSS開発者とはどのような人かという調査が日米欧で行われ（FLOSS調査）、OSSを解説した教材や書籍も発行された。

2000年代半ばになるとLinux、Apache、MySQL、PHPを使ったいわゆるLAMPシステムが普及し、企業の基幹システムにもLinuxが導入され、OSSの知名度と信頼感は一気に上がった。この頃使われたOSSは、Apache Foundationのような歴史のあるコミュニティが開発したOSSか、あるいはEclipseのような大企業(Eclipseの場合はIBM)が商用ソフトウェアをオープンソース化したものが中心であった。母体がしっかりしている少数のOSSを多くの企業が活用している状況であり、コミュニティの成熟度を自分で評価しなくとも多くの導入事例があるかをみれば良かった。

2000年代後半になると、OSSによって成功した企業を後追いして、自社のソフトをOSS化したり、自らの開発したOSSを商材に起業する企業が次々と現れた。一方で、利用する側も他社との差別化を図るため、新しいOSSを発掘する必要が出てきた。となると必然的に開発期間が短く、開発母体も大企業ではないことが普通となり、成熟度を評価する必要が出てきたのである。

オープンではないオープンソース

実際に最近登場したOSSを評価してみると、コミュニティが以前とはかなり異なることに容易に気づく。従来からのOSSは企業中心で開発しているOSSであっても、活発なメーリングリストや掲示板があり、企業外の人が開発の中心に関わっている。企業は「中心」であっても、コミュニティとともに開発していくという姿勢が見られるOSSが一般的であった。ところが、最近登場したOSSは「企業だけのOSS」であることも多い。つまり、ソースコードは公開され、メーリングリストや掲示板があったとしても、開発は社内で進められ、外部からの貢献を受け入れようとする姿勢が見られないことがあるのだ。

公開した企業としては、自社のアイディアや技術力をアピールして売上を伸ばし、ベンチャーキャピタル等から資金を集め、最終的に株式公開なり大企業に買収してもらえれば万々歳、なのかもしれない。オープンソースには違いないのだからそれを非難してはいけない。クローズドな開発体制が気に入らなければ、ソースコードを拝借して別のプロジェクトを立ち上げても構わないのだ。それができるのがオープンソースである。

とはいえ何となく釈然としないのは筆者だけだろうか。開発の中身が見られないと、余程の訴求点が無い限り評価の点はどうしても下がる。起業したばかりのベンチャー企業なのだから信頼が低いのはやむを得ない。前述のような企業は開発をオープンにして仲間を増やしてビジネスを拡大するよりも、ごく少数の投資してくれる人を求めているように見える。一攫千金か着実な成長か、選択するのはその企業の自由だが、夢破れると同時にソフトウェアが消えていってしまうのは社会全体としては大きな損失である。

本文中のリンク・関連リンク：