オープンソースのサポート：どのような場合に有料サポートを使用すべきか

　現在では、多くの大企業がある種のオープンソースソフトウェアをデータセンターで利用していると考えられます。それが何台も並んだLinuxサーバーにせよ、対照的ないくつかのLinuxインスタンスにせよ、またはWindows上で稼動するApacheだけにせよ、オープンソースは広く普及しています。では、オープンソースソフトウェアについて何か助けが必要になった場合はどうしているでしょうか。単純な設定に関する問題だけでなく、「ドキュメント通りに動作しない」といった問題や、バグが発生した場合などです。方法はいろいろありますが、それは本当に価値があるものでしょうか。

　まず、現在の状況をはっきりさせておきましょう。商用ソフトウェア（クローズドソースソフトウェア）のサポートは、以前に比べて良くも悪くもなっていません。一方、オープンソースではその「コミュニティ」（つまりフォーラムやメーリングリスト）がサポートにおいて大きな役割を果たしています。しかし、最近はオープンソースでも専門的なサポートを行う機関とその保証が求められるようになってきています。こちら側に落ち度はないのに基幹サーバーがダウンした場合、メーリングリストはあまり有用ではありません。エラーメッセージやよくある間違いならばたいていは解決策が見つかりますが、ほとんどの場合は、自分でどうにかして対処しなければならないバグだと判明するだけです。

　バグを見つけても、直ちにアップデートの公開を開発者に依頼することはほとんど不可能なので、自分自身で事態を収拾する必要があります。オープンソースソフトウェアでバグを見つけた場合の対処方法がいくつかありますので、以下に示します。

• 他のバージョンを使用する。付属のライブラリの更新が必要になる場合が多い。
• 他のサーバー上で使用する。できれば別のLinuxディストリビューションにする。
• 最新の公式リリースから自分用のバージョンをコンパイルする。
• 既に同じ問題を解決したユーザーがいないかどうかGoogleで検索する。

　「対処できないバグ」以外にも多くの問題があることは間違いありませんが、今回はサポートに関する問題について考えていきましょう。

　オープンソースソフトウェアでは、サポートを利用するにあたりいくつか困難を乗り越えなければならないことがよくあります。これは別に、商用ソフトウェアのユーザーの方がレベルが低いとか、商用ソフトウェアの方が安定しているという意味ではありません。コンプリートソリューションとして一括提供されるソフトウェア、たとえばオリジナルバージョンのJREを同梱しているものなどは、動作の信頼性が比較的高いと言えます。このようなソフトウェアでは、たとえば管理者が使用ディストリビューションの対応JREを更新することにした場合でも互換性の問題は発生しないので、心配事が1つ減ります。他にも対処すべき互換性の問題は数多くありますが、クローズドソースでもオープンソースでもソフトウェアのディストリビュータは製品にできる限り多くのコンポーネントを含めることで、最も一般的な問題に対処できるようにしています。

　この考え方には、多くの人が異論を唱えています。商用ソフトウェア業界ではこのような「内包型」の概念が広まってきていますが、オープンソース（特にコミュニティのみのもの）では適切な依存ファイルの用意をLinuxディストリビューションに頼る傾向にあります。そこで、ソフトウェアのサポートを行う企業が登場してきました。

　news.comのMatt Asay氏は、クローズドソースソフトウェアのサポート回線はオープンソースビジネスのそれとはまったく違う使われ方をしていると指摘しています。つまり、クローズドソースのユーザーは、ソフトウェアデプロイメントのインストールとセットアップを行う段階で頻繁にサポート回線を利用する傾向があるのに対し、オープンソースでは、機能の要請やバグの報告を行ったり、アプリケーションをカスタマイズして統合性を改善したりするときの方が、サポートがよく利用されているというのです。そう聞くと、オープンソースのユーザーはソフトウェアをあれこれいじり回して楽しみ、本来とは違ったものにしようとしているのではないかと考える人もいます。一部の状況下でそうした実例はありますが、それは常例というよりも例外です。実際には、一般的にオープンソースソフトウェアの方が汎用性があるので、ユーザーはその技術の興味深い応用方法を探しているのです。

　したがって、オープンソースソフトウェアのサポートで真に必要とされるのは信頼性です。統合性、規模拡張、カスタマイズ、バグなどは、どれもサポートを必要とする重要事項ですが、最終的に重視されるのは信頼性です。各企業は、関連性がないように見える変更を行っても自社の稼動中のサービスに影響が出ないことを確信する必要があります。従業員に過重労働を課して問題緩和策を探させなくても、簡単に問題を把握してすぐに解決策が見つかるようにする必要があります。

　ここにニッチが生まれます。既に、一般的な問題のソリューションを提供する専門企業もいくつか出てきています。わかりやすい例で言えば、こうした企業はRed Hat Enterprise Linuxよりさらに一歩踏み込み、特定のソフトウェアスタックのサポートを行います。これにより、オペレーティングシステム全体を取り扱うのではなく、いくつかのソフトウェアにまたがる混在型の依存性に焦点を絞ることができます。すべてを紹介することはできませんが、たとえばSourceLabsとOpenLogicはどちらもこのビジネスモデルを導入しています。

　SourceLabsは、SASHというオープンソースのJavaミドルウェアプラットフォームを提供します。SASHではSpring、Axis、Struts、Hibernate、Tomcatなどを採用し、サポートも付属しています。関連のパッチと付属製品は、動作保証されたパッケージで提供されます。SASHのフレームワークでは、サポートが用意されていて、随時テストと検証済みの最新版も入手できます。これは優れたパッケージソリューションの一例ですが、おそらく単独で使用しようとした場合には管理が難しくなるという事情もあるでしょう。

　一方OpenLogicは、LAMPスタック、開発ツール、Javaサービスのほか、膨大なアプリケーションをサポートします。こちらのサポートモデルの方が、多くの人が「サポート」という言葉から思い浮かべるものに近い内容です。24時間7日間対応のコールセンターを開設し、どのアプリケーションに関連する問題も支援しています。開発者のサポートも行っていて、必要なコンサルティングや有益な研修を実施しています。さらに、テストと検証済みのオープンソースパッケージが数百種類付属しており、手軽なサポートが保証されているので、ユーザーはこれらを安心してインストールできます。

　オープンソースソフトウェアは、もはやかつてのような未知の存在ではありません。主要なLinuxディストリビューションは、この10年間で機能が大きく向上し、基幹アプリケーションは多くのサポートオプションによって支えられています。オープンソースの導入に関する問題は依然としてありますが、前述の2社ならばたいていの問題は容易に解決できるので、あまり簡単にあきらめないでください。あわてて結論を出すと、チャンスを逃すことになりますよ。