オープンソースソフトウェア(OSS)のクオリティがある程度のレベルに達したことから、企業の間ではソフトウェアを選ぶ上で、Linux OSをはじめとするOSSを選択肢に入れるケースが増えている。だが、オープンソースとの付き合い方が分からないという声も多い。特に、2、3年前の訴訟問題では、OSSを使っていく上での潜在的リスクも明らかになった。そんな迷いに対し、Brian McCallister氏は「(オープンソースといっても)商用ソフトウェアとほとんど変わらない」とアドバイスする。

McCallister氏はオープンソースプロジェクトApacheのコミッターとしてオープンソース開発に関わる一方で、システム開発企業の米Chariot SolutionsでOSS導入支援を手がけている。7月末、ドイツ・シュツットガルトで開催された「ApacheCon 2005 Europe」でのセッションで、McCallister氏は、オープンソースをどう使えばよいか、注意点は何かという疑問に対し、自身の持つ数々の指標やガイドラインを紹介した。

McCallister氏は開口一番、「オープンソースといっても、商用ソフトウェアと変わらない」と述べる。オープンソースをいつ・何に・どう使うかの判断基準は、商用ソフトウェアを選ぶ場合とほとんどかわりはないというのだ。その上でMcCallister氏は、「オープンソースをいつ使うべきか?」「オープンソースという選択肢をどう評価すればよいか?」「オープンソースを選択した際の注意点は何か?」の3つに関して話を進めた。

いつ使う?

最初の“いつ使うか”は、それ以外の選択肢となる、社内開発か、商用ソフトウェア購入か、との比較が必要となる。社内開発と比較した場合、社内の作業が異なる。社内開発では、アーキテクチャ設計、開発、トレーニング、保守をすべて行うことになり、オープンソースでは、評価・選択、トレーニングを行う。メリットとデメリットはそれぞれだ。「パッケージを使わないことで狙うメリットは何か、パッケージ選択を適切に行えるのかなどを見極めること」とMcCallister氏は言う。

商用ソフトウェアとの比較の場合、オープンソースのメリットは、初期投資が少なくてすむ点、ソースコードが開示されているため、開発者が使いやすくバグを自分で修正できる点などがある。商用ソフトウェアのメリットとしては、ライセンスが煩雑でない点、専門知識を持つ人が必要ない点など。McCallister氏は、「基準を設定し、同じ基準で評価すること」とアドバイスした。

評価のポイントは? 注意すべき点は何か?

次のステップが評価だ。オープンソースにせよ、商用ソフトにせよ、パッケージを使用するという道を選ぶことになった場合、「評価すべき点はほとんど同じ」とMcCallister氏。評価項目として、プロジェクト、投資レベル、アーキテクチャ的投資、ライブラリ、開発ツール、インフラ、ライセンス、ドキュメンテーション、開発コミュニティ、ユーザーコミュニティ、サポート、成熟度の12点を挙げた。これに基づき、自社独自の選択ガイドラインを設けるわけだが、特にオープンソースで重要となるのが、ライセンス、コミュニティ、サポート、成熟度の4つだ。

1. ライセンス

   商用ソフトウェアでももちろんライセンスは生じる。パッケージを選ぶ限り、ライセンスは避けられない道だが、オープンソースはそのライセンスの種類により制約が異なるので、ある程度の知識が必要となる。オープンソースのライセンスは、BSD、LGPL、GPL、その他の4つの種類に大分できる。
   • BSDタイプ : 無償。コードを改変したものを再配布可。著作権表示が条件。Apache、FreeBSD、PostgreSQLなどが利用
   • LGPL : 無償。再配布可だが、ソースコードを改変した場合はLGPL/GPL下で開示。他のソースコードからリンクした場合に、リンクする側にLGPLを適用する必要はない。OpenOffice.org、JBossなどが利用
   • GPL : 無償。改変や再配布は自由だが、GPLライセンス下でコードを開示しなければならない。Linux、MySQLなどが利用。
   • その他 : Open Source Initiativeの定義を満たすものは多いが、よく利用されているとは限らない。詳細はさまざまであることから、条項を確認する必要がある。Apple Public Source LicenseやSUN PUBLIC LICENSE PUBLIC LICENSEなど。
   McCallister氏は、「ライセンスに関しての疑問は、徹底的に解決すべき。なるべく弁護士を利用して、クリアにしておくこと」とアドバイスする。選択の際に考慮すべき点として、オープンソースを使うだけなのか、それを利用して拡張する計画があるのか、それを再配布や販売する計画があるのか、などを挙げた。

2. コミュニティ

   コミュニティには開発者とユーザーの2つがあるが、ともにプロジェクトを知る上で重要な材料となる。プロジェクトの生命は、ソースコードではなくコミュニティ。「たとえば、新しい貢献者に対する態度から、特徴を探ることができるのではないか」とMcCallister氏はアドバイスする。評価点は、どのくらい活発か、多様性があるか、コミュニケーションはどのように行われているか(メーリングリストか、フォーラムか、会議か)、成功事例はあるか、などが挙げられるという。

3. サポート

   サポートに関しては、無償と有償の両方がある。無償はコミュニティから得られるもので、有償は、オープンソースサポートを専門とした会社や個人開発者もある。対象となるオープンソースにどのようなサポートがあるのか、事前に調べておくべきだ。

4. 成熟度

   リリースサイクル、開発コミュニティの活発度(=人気度)、サポートとドキュメンテーションの度合い、などが評価点となる。

ガイドラインの作成

McCallister氏は、パッケージを利用する際に指標とするためのガイドラインを作成することを推奨する。オープンソースの場合は、このガイドラインにコミュニティとの関わり方も定めておくべきだという。これを決定するにあたり、重要となるのは、自社がそのオープンソースプロジェクトをどう利用するのか、だろう。それに加えて、コミュニティ側の期待を理解しておくこと、どのように支援を得るか(メーリングリストなのかフォーラムなのかなど)を理解しておくことなども必要という。「得られる情報がどのくらい詳細か、ログインとパスワードが不要かなどがポイントとなる」。また、「多くのコミュニティはボランティアベースで機能しており、すぐに支援に応じるとは限らない。忍耐も必要」ともアドバイスした。

このようにしてオープンソースを利用した後は、プロジェクトの再評価だ。社内にパッケージ(商用、オープンソースの両方)活用のベストプラクティスを構築することは、次に選択する際にさまざまな作業の軽減につながる。

このように、オープンソースであろうと、商用ソフトウェアであろうと、選択、利用、再評価というステップは同じだ。オープンソースを導入する予定がある・ないに関わらず、一度社内で、自社にとっての効果的なパッケージ利用法を考えてみるのもよさそうだ。