技術的に見てオープンソースプロジェクトが適切な選択肢であったとしても、それに見切りをつけなければならないことがあります。この記事では、別のオプションを探すべきタイミングを見極める方法について説明します。

オープンソースソフトウェアの選択肢が数多く存在するのは素晴らしいことですが、どれを選択すべきなのかを判断するのは容易ではありません。また、役に立たなくなった製品やテクノロジーと同じように、代わりになるものを探すべきタイミングを見極めるのも困難です。

そのタイミングは、プログラムが期待どおりに動作しなくなるか、プログラムの技術アーキテクチャーが自社のIT環境に適さなくなったときのように明らかな場合もあれば、判断基準がわかりにくい場合もあります。

最初に問題になるのは、変化を起こして代わりになるものを検討すべきタイミングです。ほとんどの場合、プロジェクトに疑問を感じるのは、既存のソフトウェアが常に問題の原因になっているか、プロジェクトが困難な状況に陥っているように思われるときですが、プログラムで障害が発生するかプロジェクトが破綻するまで待っていると、十分な情報に基づいて代わりになるものを判断する時間がなくなってしまいます。

ここからは、現状を維持すべきなのか、早急に見切りをつけるべきなのかを見極める方法について説明していきます。

 

代表例: SDIとSDN

一部の領域では、ほぼすべてがオープンソースソフトウェアベースとなっていますが、それはニーズに合ったものが見つかったということを意味するため、問題はありません。ただし、それは同時に難しい選択をしなければならないということを意味するため、フラストレーションにもなります。

ここで問題を明らかにするために、話題になっているあるネットワーキングの領域について考えてみましょう。Cisco社の著名なエンジニアであるIan Wells氏は、Open Infrastructure Summitで幅広いオープンソースのソフトウェア デファインド インフラストラクチャ(SDI)プログラムとソフトウェア デファインド ネットワーク(SDN)プログラムを例に挙げ、そうしたプログラムが十数個あることを明らかにしました。同氏からは、Central Office Re-architected as a Datacenter、Open Network Automation Platform、OpenSwitch Network Operating System、Open vSwitchなどが挙げられましたが、問題を複雑化させる要因として、いくつかのプロジェクトは、SDNプログラム、Tungsten Fabric (旧OpenContrail)、OpenDaylight、Trellisといった、ほぼ同じような領域をカバーしており、SDNのエキスパートでさえ、非常に多くのプロジェクトに困惑することがあります。

これに関してはまず、SDIの最終目標がテクノロジーの管理を容易にすることにあるにもかかわらず、ITチームがわかりにくく複雑な多くのプロジェクトを評価してから、情報に基づいて判断を下さなければならないということが問題になります。下調べに時間がかかるだけでなく、プロジェクトのサポート担当者についても検討する必要があり、ゼロから立ち上げるとなると、さまざまな懸念が生じてきます。また、既存のハードウェアインフラストラクチャをサポートする必要がある場合は、他にも検討しなければならないことがあります。

通常、数多くあるプロジェクトはどれも同じ問題を解決できると主張していますが、それぞれのアプローチは異なります。そのため、(ソースコードを調べるなど)各プロジェクトをチェックしてニーズに合ったものを見極める必要があります。

どのプロジェクトが役に立つのかを判断するにあたっては、技術の詳細にこだわるのではなく、次のようなシンプルな質問の答えについて考えることが重要です。

• 役に立つのかどうか。
• 必要とする機能を備えているのか。
• 目的どおりに機能するかどうか。
• 機能しないのであれば、いつか機能するということをどの程度確信できるのか。改善できるのか。修正できるのか。

これらの質問の答えが「はい」であればリソースを投入し、「いいえ」であればニーズを満たす別のプロジェクトを探します。

ただし、オープンソースについては自社に最適なテクノロジーを探すだけで終わりではありません。

これに関しては、それらの中でどれが役に立つのか、どれを使用したいのか、展開できるのか、すでに他の人が展開していないか、プロジェクトに取り組む人が展開してないか、ユースケースはあるのか、付け焼き刃的なものではないか、誰かが不純な動機から作成した(個人的な)プロジェクトではないか、といったことを自問しなければなりません。

つまり、プロジェクトについて検討するだけでは十分ではなく、実際にソフトウェアがどのように使用されるのかに目を向ける必要があるのです。

 

オープンソースのライフサイクル

オプションを比較する方法の1つとして、ハイプサイクルにおけるプロジェクトの状態を確認することが挙げられますが、Wells氏、そして同じくCisco社の著名なエンジニアであるKyle Mestery氏は、オープンソースネットワークの開発の観点からGartner社のハイプサイクルの手法について見解を述べています(図を参照)。この手法を理解すれば、プロジェクトを利用するタイミング、成功がもたらされるタイミング、およびプロジェクトに見切りをつけるタイミングがわかるようになるかもしれません。

オープンソースネットワークのハイプサイクル。クレジット: Ian Wells氏およびKyle Mestery氏(Cisco社の著名なエンジニア)

オープンソースプロジェクトが始まると、多くの情報が得られます。そしてそれらが大きな力となり、取り組まなければならないのはXBANGであるなどと宣言して作業を進められるようになるわけですが、その理由は、プロジェクトが成熟すると問題(少なくともSDIやアプリケーション開発などに関連する問題)が解決されていくからです。

ただし、そううまくいくはずはなく、Mestery氏が言うように、「ピーク時の興奮は大きすぎる可能性があり、全体的な成功が保証されるわけではないのです」。

そのため、話題になっている新しいプロジェクトには注意しなければならず、そうしたプロジェクトは役に立つようになる前に勢いがなくなってしまう可能性があります。

Mestery氏は、最初の興奮は必ず収まってくると述べていますが、それはプロジェクトが失敗に終わったり、ニーズに合わなかったりするということを意味しているわけではありません。ただし、上の図に示されているように、ソフトウェアは必ず不満の時期を経ることになりますが、これに関しては問題ありません。

 

不満を抱いている人に対する愛情

Mestery氏によると、人は興奮が収まると、他のより新しく魅力的なプロジェクトに移っていきます。ただしプロジェクトは、期待に沿っていれば発展し続けてベータテストに進み、最終的には本稼働に移行します。

ここで、プロジェクトが「不満の集積」の段階を迎えたときに何が起きるのかに注目してください。人はこのままプロジェクトに取り組み続けるでしょうか。そうであれば、Mestery氏は「悩む必要はなく、関心が薄れたときには具体的な作業は完了している」と述べています。

これはいわゆる不満のあるプロジェクトであり、こうしたプロジェクトでは非常に役に立つコードが見つかることがあります。ここでは注意して状況を見守ることが重要です。開発者は引き続きプロジェクトに積極的に取り組んでいるでしょうか。プロジェクトはニーズを満たしているでしょうか。ソフトウェアは本稼働に移行しているでしょうか。そうであれば、あなたと開発者はここでそのまま流れに乗るべきであり、そうしないのなら新しいプロジェクトを立ち上げる必要があります。

Wells氏が言うには、プロジェクトによって問題が解決されるかどうか、そしてプロジェクトに技術的価値とビジネス価値があるかどうかが重要であり、これらに当てはまるプロジェクトは、不満の段階を抜け出して「融合」の段階へと進んでいきます。そしてMesteryは、「テクノロジーはこの段階で環境の一部として受け入れられる」と説明しています。

オープンソースプロジェクトは、他者に利用を促す必要がなくなった時点でIT環境に融合されると考えることができます。そしてMestery氏によると、融合の先には基盤となる何か別のものを探すコモディティ化の段階があり、ソフトウェアライフサイクルのこの段階では、「ユーザーはテクノロジーを使用していることを実感してはいないものの、テクノロジーを使用している」と同氏は述べています。これを示すわかりやすい例としては、Secure Socket Layer (SSL)が挙げられます。

 

プロジェクトが間違った方向に進んだ場合

すべてのプロジェクトがSSLのように受け入れられて当たり前になるわけではありません。

プロジェクトは失敗に終わることもあります。実際のところ、オープンソースプロジェクトはその大部分が功を奏しておらず、たとえば、RedMonk社のアナリストであるDonnie Berkholz氏の数年前の報告によると、GitHubプロジェクトでは、全体の98%超で2年目以降開発が行われていません。

また、大規模なオープンソースプロジェクトでさえ方向性を見失うことがあり、最も有名な例としては、AndroidベースのオペレーティングシステムであるCyanogenModが挙げられるのではないかと思います。非常に人気が出て1,000万人を超えるユーザーを獲得したCyanogenModは、コードが優れており、実際のところLineageOSとして存続してはいるものの、創設者が商業化に失敗し、メインプログラムは消え去ってしまいました。

別の例としては、かつて広く知られていたもののOracle社に見捨てられてしまったプログラムであるOpenOfficeが挙げられます。OpenOfficeのプログラマは、Microsoft OpenXML形式との互換性を持たせるといった調整を行って改善を図り続けましたが、他のコードコミッターがこうした変更を無視したため、作業を続けてきたプログラマは結局、現在大きな成功を収めているLibreOfficeにコードを分けることになりました。

ここでの教訓としては、管理が不十分だと優れたソフトウェアでも消え去ってしまう可能性があるということが言えます。ただしオープンソースの場合、優れたプロジェクトは消え去ってしまうとは限らず、役に立つコードは引き続き使用されることになります。

ほとんどのオープンソースプロジェクトは、他のコンピューティングプロジェクトと同じ理由で失敗に終わっており、断念されたGitHubプロジェクトに関する2017年の調査において、調査報告書の著者は、「今日のオープンソースプロジェクトがプロジェクトの特性(41件、保守性の低さなど)、プロジェクトチーム(39件、主要なコントリビューターの時間不足や関心のなさなど)、および環境(30件、競合企業や法的な問題によってプロジェクトが奪われたなど)に関する理由で失敗に終わっている」ことに気付きました。

Mestery氏とWells氏によると、プロジェクトは次のような理由で断念されています。

• 完了して役に立たなくなった。
• 解決すべき問題の選択を誤ったか問題が変わった。
• 開発者がプロジェクトに見切りをつけて新しい「優れたプロジェクト」に移行したため、価値を高めるのに役立つコミュニティがなくなった。

最初の2つのシナリオは、皆さんが思っているより頻繁に起きており、これについてWells氏は、次のように述べています。「どんな理由であれ、問題が明確でアプリケーションにあるか、もしかすると解決する必要がなくなったのかもしれません。たとえば、データセンターで10メガビットのリンクを使用する方法がわかり、その後それを最適化するための作業が終わると、何か新しいことを始めるときが訪れるのです」。

Mestery氏とWells氏によると、失敗に終わる可能性があるプロジェクトは、次のようなポイントを確認することで見極められます。

• プロジェクトに多様なコミュニティがないか。
• アクティブなコミッターは何人いるか。数人しかいない場合、それらのコミッターが飽きてしまうとどのようなことが起きるのか。
• 委員会がすべてのコミットを管理しているのか、特別な知的財産権を求めているのか。コミュニティが個人または企業のコントリビューターを尊重してないか。
• プロジェクトで継続的テストを使用しているか。

エキスパートが言う「多様なコミュニティ」には複数の意味があり、その定義によると、皆さんが思うようにプロジェクトの参加者は1つの性別や人種に縛られません。また、プロジェクトには複数の企業の開発者が参加するという意味もあり、1社だけがプログラムを開発していると、その継続性は疑われます。

プロジェクトにはあらゆるものを受け入れる文化も必要であり、視野が狭くなるほど、プロジェクトが失敗に終わる可能性が高くなります。

他のプロジェクトに目を向けてみると、成功を収めているプロジェクトには行動規範があるということがわかります。プログラムは、マシンを生み出すコードではなく人によって作られます。どのプロジェクトにもプロジェクトの邪魔をしようとする厄介者がおり、行動規範のないプロジェクトでは個人的な問題に臨機応変に対応しなければなりませんが、そうした取り組みは無残に失敗するケースが少なくありません。

LinuxやPythonなど、いくつかのプロジェクトはBenevolent Dictator for Lifeの管理モデルをベースとすることで成功を収めていますが、それらは例外であり、一般的ではありません。

また、知的財産の問題も非常に重要です。Confluent、Elastic、MongoDB、Redisなど、一部の「オープンソース」プロジェクトをクラウドフレンドリではないオープンコアライセンスモデルに移行するときは特に厄介で、MariaDB社のCEOであるMichael Howard氏は、このアプローチを「オープンソースのストリップマイニング」と呼んでいます。

Wells氏は、「誰もがソフトウェアライセンスの問題について考えたくないと思っているものの、ライセンスの側面に目を向ける必要がある」と述べており、プロジェクトを評価するときは、誰がどの権利を持っているのかという点に注意を払わなければなりません。

これについて、Linux FoundationのCore Infrastructure Initiativeの2つのプロジェクトでリーダーを務めるDavid A. Wheeler氏は、次のように述べています。「質問をしてくる人がいなかったり、誰も寄与していなかったり、新規導入がないように思えたり、依存関係が増えていないように思えたり、使用されている兆候が他に見えなかったりした場合は、大きな問題が起きる可能性があります。何の問題もないかもしれませんが、プロジェクトが消滅しようとしているのかどうかを確かめる価値はあります」。

最後に、根本的な問題はプロジェクトが目指すべき方向に進んでるかどうかという点にあります。プロジェクトの逸脱、またはその他の理由で要件が満たされないのであれば、損失を食い止めてより適切なアプローチを探すための準備を整える必要があります。

 

プロジェクトが失敗に終わった場合

一部のプロジェクトはもはや存在すらしておらず、コードに何か役に立つものが含まれているかもしれませんが、プロジェクト自体が消滅してしまっているのです。

これについてWheeler氏は、「大きな成功を収めたオープンソースプロジェクトでさえ、事業計画が変わったり、新しいテクノロジーやイノベーションに取って代わられたりすると、最終的にクリエーターやユーザーの役に立たなくなる可能性がある」と述べています。

では、このようなプロジェクトを見極めるにはどうすればいいのでしょうか。Linux Foundationによると、もう役に立たないプロジェクトやそうなりかけているプロジェクトには、次のような問題があります。

• 開発側の方向性とこれまで関わってきたコントリビューターの失われたエネルギーに埋められない差がある。
• プロジェクトを継続すべきなのか、終了すべきなのか、それともプロジェクトに完全に見切りをつけるべきなのかについて、チームのメンバーやコミュニティから質問されることが減っている。
• 認識された問題を解決したり、セキュリティ脆弱性を解消したりするために、コミュニティがもうコードにパッチを適用したり、コードをアップデートしたりしていない。
• ユーザーがもうパッチやメンテナンスアップデートを求めていない。

自社にとってコードが重要なのであれば、それを分けることを検討してみてください。LibreOfficeの開発者の役に立ったこの方法は、あなたの役にも立つ可能性があります。

コードを読み解く時間があり、そのプロジェクトがニーズに合っていると思えるなら、先に進んで深く掘り下げてみてください。ただし、多大な努力を払うことなく成果が得られるなどと思ってはなりません。

 

プロジェクトが完全に終了した場合

これらすべての側面について検討したら、役に立つプロジェクトを探すための準備を整える必要があります。プロジェクトの最も話題になっている部分に目を向けすぎることなく、プログラムの強みと(少ないかもしれませんが、ある場合は)弱みを見極めることが重要です。そうすれば、自社の成功に必要なオープンソースプログラムが見つかります。

 

オープンソースプロジェクトを利用する(プロジェクトに見切りをつける)タイミング: リーダーのためのアドバイス
 

• 話題になっている新しいプロジェクトには注意しなければなりません。
• 特に多様なオープンソースコミュニティを信用することが重要です。
• オープンソースプロジェクトは危険な兆候を示していることがあるため、それらを探すことが重要です。

_{この記事/コンテンツは、記載されている個人の著者が執筆したものであり、必ずしもヒューレット・パッカード エンタープライズの見解を反映しているわけではありません。}