今日では、企業のプリンターや Web サーバーで Linux システムが稼働し、従業員は Firefox ブラウザーを使用し、さまざまなモバイル デバイスで Android オペレーティング システムが稼働しており、オープン ソース ソフトウェアを使用していない企業を想像するのは難しいでしょう。

オープンソース管理ツールプロバイダーであるBlack Duck Softwareによると、現在、業界には100万を超えるオープンソースプロジェクトが存在し、その数は増加し続けています。Black Duck Softwareは、世界最大のオープンソースソフトウェアディレクトリであるOhlohを所有しています。また、SAPが発表した調査レポートによると、オープンソースプロジェクトの数は平均して14ヶ月ごとに倍増しています。

しかし、オープンソース・プロジェクト間の活動レベルは大きく異なります。オロー氏は、オープンソース・ソフトウェア・ディレクトリで活動情報を検索できる100,375のオープンソース・プロジェクトのうち、80%のプロジェクトが活動レベルが低い、非常に低い、あるいは完全に活動していない状態にあると指摘しています。

これは、個々のオープンソース・プロジェクトに多額の投資を行い、それらを重要なビジネスシステムの一部として活用することを目指してきた企業にとって、間違いなく悪いニュースです。一方、ガートナーの調査データによると、2016年までに世界中の2,000社を超える企業のうち99%が、主要なシステムソフトウェア製品ラインでオープンソースソフトウェアを使用していると、ほぼすべての回答者が回答しています。

企業が将来性のないオープンソース プロジェクトを選択した場合、それは、ほとんど更新されないかまったく更新されず、セキュリティ パッチが不足しており、コミュニティのサポートを受けられない可能性のあるプロジェクトを選択したことを意味します。

さらに、不適切なオープンソースプロジェクトを選択した場合の影響は、開発レベルをはるかに超えてしまいます。例えば、オープンソースコードは様々なライセンスで配布されており、その中には企業の製品や開発計画と互換性のないライセンスが含まれている可能性があります。さらに、管理されていないオープンソースソフトウェアは、セキュリティリスク、監査、コンプライアンス上の問題を引き起こす可能性があります。

調達プロセスの抜け穴

開発者やエンドユーザーは、オープンソースソフトウェアが無料で、アップグレードが容易で、必要な機能を備えているため、アップグレードに積極的であることが多いです。最も重要なのは、調達プロセスに伴う煩わしさがないことです。その結果、多くの企業は、従業員が実際にどの程度オープンソースソフトウェアを使用しているかを全く把握していません。

オープンソースソフトウェアベンダーの中には、これを販売戦略として活用しているところもあります。パリに拠点を置くオープンソースのビジネスプロセス管理ソフトウェア企業、Bonitasoftの最高戦略責任者、ジャン＝リュック・ソラン氏は次のように述べています。「オープンソースソフトウェアの販売は個人に直接アプローチできるため、通常のソフトウェアと同様の意思決定プロセスや販売プロセスを活用できます。オープンソースソフトウェアの販売量が一定規模に達すると、企業に採用されるデファクトスタンダードとなります。ユーザー（通常は企業のCTO）からよく聞くのは、『本当は提携するつもりはなかったのですが、別のチャネルを通して参入して実現したんですね』という声です。」

ただし、エンド ユーザーや個々の開発者にとって、これらのオープン ソース ソフトウェア プログラムを使用することで、企業のニーズや長期的な開発目標が必ずしも完全に満たされるわけではありません。

2013年、Sonatypeは3,500人のITプロフェッショナルを対象に調査を実施し、開発者の60%がセキュリティを最優先事項と見なしていないことが明らかになりました。これは、ほとんどの開発者が高価なオープンソースソフトウェアを使用するための追加リソースを持っておらず、セキュリティは自分の責任ではないと考えている開発者もいたためです。

一方、ソフトウェア管理プロバイダーの White Source による調査では、オープンソース コンポーネントを含むソフトウェア プロジェクトの 23% にセキュリティ上のリスクがあり、オープンソース ソフトウェア プロジェクトの 85% が古いオープンソース ライブラリを使用していることが判明しました。

さらに、オープンソースプロジェクトではコミュニティのサポートが様々な問題を引き起こすことが多く、そのため一部の大企業は、重要な機能とサポートのために専門的なオープンソースソフトウェアプロバイダーを選択する傾向があります。しかし、Black Duckによると、開発者やITプロフェッショナルの45%がソフトウェアを選択する際に技術的なパフォーマンスと製品機能を重視しているのに対し、商用ベンダーのサポートを選択と意思決定の重要な基準とみなすのはわずか12%です。

個々のユーザーや開発者は、オープンソースソフトウェアを選択する際に、社内の他の部門が別のツールや互換性のないツールを使用しているかどうか、オープンソースソフトウェアのライセンスが適切かどうか、さらには必要に応じてソフトウェアを拡張できるかどうかなどを考慮しない場合があります。結局のところ、ツールが特定の開発者にしか馴染みのないコードで記述されている場合、社内の他のユーザーはそのツールを使用しなくなり、その開発者が退職した場合、企業は問題に直面する可能性があります。

管理不足

Sonatype は、現在 57% の企業でオープンソース ソフトウェアの使用に関する明確なガイドラインやポリシーが欠如していると指摘しています。

優れたオープンソース管理ポリシーでは、開発者やエンドユーザーに対して、オープンソース ソフトウェアをいつどこで使用するか、どのようなライセンスが必要か、いつ管理が必要かを伝えるガイダンスを提供する必要があります。

ソフトウェアが十分に重要である場合、オープンソース ソフトウェアを選択する際に正式な選択プロセスに従うことができ、オープンソース ソフトウェアを選択するプロセスは、プロプライエタリ ソフトウェアを選択するプロセスと多くの類似点があります。

Red Hatの最高情報責任者であるリー・コングドン氏は、「オープンソースのテレフォニーシステムのような大規模プラットフォームを選択する場合、コスト、機能、開発ロードマップ、ベンダーの安定性、そして設定された目標の達成可能性など、製品選定プロセスはプロプライエタリソフトウェアの場合と同じです。これらの要素は、プロプライエタリソリューションを評価する場合と同じです」と述べています。

しかし、オープンソースソフトウェアの選定プロセスは、プロプライエタリソフトウェアの選定プロセスとは主に2つの点で異なります。1つ目は、オープンソースソフトウェアベンダーは従来の商用ベンダーとは異なるということです。2つ目は、オープンソースソフトウェアの選定には、プロジェクトのコミュニティも考慮する必要があるということです。

コングドン氏は次のように述べています。「しかし、これは経営陣がすべてのオープンソースソフトウェアの選定プロセスに介入する必要があるという意味ではありません。オープンソースソフトウェアの選定を過度に管理することは、企業ITにおけるイノベーションを阻害し、ひいては企業IT全体に暗い影を落とす可能性があります。当社では、個々の開発者に一定の自由度と柔軟性を与えていますが、プロジェクトのニーズや当社のアーキテクチャチームが関与するプロジェクトに応じて、当社に適したソフトウェア選定の標準的なアプローチを構築しています。」

コミュニティ

オープンソース プロジェクトの成功または失敗は、コードを投稿する開発者、テスター、ドキュメント作成者、オンライン フォーラムで質問に答える人々、エンド ユーザーなど、そのプロジェクトを取り巻くコミュニティに大きく依存します。

オープンソースプロジェクトのコミュニティの規模と活動レベルを評価する方法はいくつかあります。Ohlohが提供するツールもその一つです。一般的な方法の一つは、オープンソースプロジェクトのホームページやウェブサイトでコードのコミット履歴を確認し、ディスカッションフォーラムの活発さを確認することです。

GitHubのビジネス開発・戦略担当役員であるティム・クレム氏は、「GitHub上にプロジェクトがある場合は、同社のウェブサイトでそのプロジェクトの活動状況を確認できます。例えば、jQueryでは、公開されている脆弱性と機能要件のリストがあり、そこで変更によるメリットについて議論されていることが多いです。最後のトピックが6ヶ月前に作成され、誰も反応していない場合、そのコミュニティは非常に活動が停滞していると考えられます」と述べています。

GitHubは、プライベートおよびオープンソースのソフトウェアプロジェクト向けに仮想ホスティングサービスを提供しているほか、社内でもオープンソースソフトウェアを活用しています。Gitバージョン管理技術など、会社の成否を左右するプロジェクトに関しては、GitHubは通常、ソフトウェア開発を支援するコア開発者を雇用しています。Clem氏は、「これにより、特定のオープンソースプロジェクトへの理解が深まるだけでなく、Git技術の開発をリードしていくことも可能になります」と述べています。

もう 1 つの方法は、オープン ソース ソフトウェア開発者に直接連絡することです。

ウェブアプリケーション開発会社CaxyのCEO兼創業者であるマイケル・ラビスタ氏は、「私たちは、重要な開発者たちにアクセスし、質問する機会に恵まれています。オープンソースプロジェクトで問題が発生し、開発者にアドバイスを求めるメールを送った際に、1日以内に返信が来るのであれば、それはオープンソースプロジェクトにとって良い兆候です。返信が全くない場合は、そのプロジェクトのコミュニティが活発ではないという証拠です。」と述べています。

開発者の数が多いことも重要です。ラビスタ氏は、「ドイツ人の開発者が、誰も理解できない言語でコンテンツ管理システムを開発した場合、その開発者が辞めれば、それはプロジェクトの終わりを意味します」と述べています。

米国の医療機器メーカー、オリンパス ヘルスケア システムズのマーケティング戦略・分析マネージャー、ロス ヌナメーカー氏は次のように語っています。「オープンソース プロジェクトでは非常に悪い経験をしてきました。それは、強力なコミュニティ サポートがなかったか、オープンソース ソフトウェアを使用して作成された製品が特にひどかったためです。」

同グループは、1999年に構築されたウェブサイトの更新を希望していました。ウェブサイトは、ナビゲーションの問題や複数の所有者による管理など、様々な問題を抱えていました。当初、オリンパス ヘルスケア システムズは専用のプラットフォームを検討していましたが、最終的には多くの大企業で使用されているオープンソースのコンテンツ管理システムであるDrupalを選択しました。

Nunamaker：「Drupalコミュニティは急速に成長しており、低価格または無料のトレーニングコースや、多くのプロバイダーがプラットフォームを利用しています。オリンパスヘルスケアグループによるDrupalの導入も、Drupalコミュニティの別のユーザーによって促進されました。」

ヌナメーカー氏はまた、「顧客からよく、『オープンソース プロジェクトは無料なので、製品はもっと安くすべきだ』とか、『このコミュニティでは Drupal オープンソース プラットフォームを多くの人が使用していますが、どのようにセキュリティを確保できるのですか』と尋ねられます」と述べています。ホワイト ハウスもこのオープンソース ソフトウェアを使用しているという事実は、プロジェクトのセキュリティについて依然として懸念を抱いている人々にとって非常に説得力があります。

一方、今年、オリンパス ヘルスケア グループがDrupalを採用したことに続き、ファイザーとジョンソン・エンド・ジョンソンもDrupalの導入を開始しました。この分野では多くの企業が古いプラットフォームを捨て、新しいプラットフォームに移行しており、この2つの大企業が同じプラットフォームを選択したという事実は、Drupalが企業にとって優れた選択肢であることを示しています。

サプライヤーサポート

企業向けの多くの人気のオープンソース プロジェクトと同様に、Drupal にも主要プロバイダーである Acquia が存在します。

ヌナメーカー氏によると、オリンパス ヘルスケア システムズは実際にはウェブサイト制作を別の会社に委託したが、選定したプロバイダーがベストプラクティスモデルに基づいてウェブサイトを制作しているかどうかをアクイアに確認させる予定だという。さらに、大手プロバイダーは緊急時には24時間365日体制でサービスを提供できる。

W3Techsの調査によると、オープンソースプラットフォームであるDrupalは、コンテンツ管理システム（CMS）市場で5.4%の市場シェアを占め、第3位にランクされています。WordPressは60%の市場シェアで第1位、Joomlaは8.8%で続いています。しかし、ウェブサイト技術情報のクエリおよび分析ツールであるBuiltWith.com（100万規模の大規模ウェブサイトに特化）では、Drupalは14.5%の市場シェアで第2位にランクされており、Drupalはより大規模なエンタープライズ環境でより普及していることがわかります。

非営利団体Open Source Mattersの代表であるポール・オーウィグ氏は、「コンテンツ管理システムJoomlaの良し悪しは別として、根本的な問題は、開発を推進する有力な商業組織が存在しないことです。Joomlaには世界中にボランティアコミュニティがあり、私たちはそれを高く評価していますが、商業的な支援を受けているプロジェクトと比較すると、その信頼度は比較的低いです」と述べています。Open Source Mattersは、主にJoomlaプロジェクトに組織的および法的支援を提供しています。

オープンソース・プラットフォームのもう一つの代表的な例としてLinuxが挙げられます。Linuxも主要ベンダーによってサポートされています。Red Hatに加え、SUSE LinuxとUbuntuの開発元であるCanonicalも、それぞれのディストリビューションの開発をリードしています。

たとえば、SUSE は Linux ディストリビューションだけをサポートしているのではなく、SUSE Linux Enterprise Server では約 2,000 個の他のオープンソース ソフトウェア パッケージもサポートされています。

ツールを選択する際、SUSE は顧客に代わってどのソフトウェアを選択するかを決定できます。

SUSE Linuxのシニアプロダクトマネージャー、マティアス・エッカーマン氏は、オープンソースプロジェクトを選定する際には主に3つの要素を考慮していると述べています。「第一に、私たちがサポートし、お客様に提供するオープンソースソフトウェアがアクティブで適切にメンテナンスされているかどうか。第二に、セキュリティ重視の基盤に基づいて構築されているかどうか。第三に、その適応性、ドキュメントの完全性、そしてオープンソースソフトウェアがユーザーに受け入れられ、肯定的なフィードバックを得ているかどうかです。」

エッカーマン氏は、SUSE はオープンソース企業であり、オープンソース コミュニティに深く関わっているため、プロジェクトの選択において一定の優位性があると述べました。

Red Hatと同様に、SUSEの従業員はLibreOffice管理ソフトウェアスイートの開発と構築に情熱を注いでいます。「当社の開発者は、特定のコミュニティにおいて重要な役割を担っています」とエッカーマン氏は述べています。

ライセンス

オープンソース プロジェクトを選択する際に最も難しい問題の 1 つは、適切なライセンスを選択することです。エンド ユーザーと開発者は、多くの場合、特定のオープンソース プロジェクトに対して十分な制御権を持っておらず、これは法務および規制当局の介入が必要となる領域です。

例えば、一部のソフトウェアは非商用利用のみにライセンスされており、多くのソフトウェアパッケージは、すべての派生物をオープンソース化することを要求するライセンスの下で配布されています。場合によっては、オープンソースソフトウェアやプロジェクトの中には、明確なライセンスが存在しないものもあります。

Hadoopの開発とサポートに注力する企業、Hortonworksの企業戦略担当副社長、ショーン・コノリー氏は次のように述べている。「Hadoopコミュニティにはオープンソースプロジェクトが数多く存在しますが、これらのオープンソースプロジェクトがどのようなライセンスを選択しているかについて、実際に注意を払う人はいません。」

米国を拠点とする決済ソリューションプロバイダーであるLoopPayにとって、ライセンスは極めて重要です。同社のソフトウェアエンジニアリング担当副社長であるDavid Meyer氏は、「オープンソースプロジェクトを本番環境で使用できるようにする必要があります。製品の再販や他の場所での再導入の際に、ライセンスによって制限されることは避けたいのです」と述べています。

マイヤー氏は、最も重要なことは、意思決定者が開発者の推奨だけに基づいてオープンソース ソフトウェアを購入するのではなく、最終的にオープンソース ソフトウェアの購入を決定する人が強力な技術的基礎を持っているか、決定を下すのを手伝ってくれる技術専門家がいることであると述べました。

マイヤー氏は次のように述べています。「以前、経験の浅い若手エンジニアたちにオープンソースプロジェクトを探す手伝いを依頼しました。彼らはこれらのプロジェクトに非常に熱心で、ぜひ活用すべきだと強く勧めてくれました。しかし、これらのプロジェクトは2年間も活動しませんでした。同じようなオープンソースプロジェクトを安易に利用すると、最終的には、製品が依存するオープンソースコンポーネントがメンテナンスやサポートを受けられなくなり、プロジェクトは失敗する運命にあることに気づくでしょう。」 (王玄訳)