大企業、サービスプロバイダ、ネットワークプロバイダ、ソフトウェア開発者の SDN イニシアチブをコンサルティングするとき、オープンソースのビジネスモデルを採用すべきか、オープンソースの SDN エコシステムに参加すべきかを尋ねられることがよくあります。正しい "答えは多くの要因に依存し、企業によって異なります。組織の当面の目標と長期的な目標、市場での地位、長期的な SDN の戦略的で市場的な意義などです。
特定のオープンソース・ソリューションに投資するかどうかを決定する前に、代替案の実行可能性と、顧客やパートナーにとっての価値を創造するという観点から見たソリューションの長所と短所を把握することが重要であることが強調されました。
顧客価値の創造
顧客価値の創造とは、エコシステム内のエンドユーザーに対する価値の創造です。例えば、新しい機能の提供や、既存のプロセスやシステムに対するオープンソース技術へのアクセスなどです。
a) オープンソース・プロジェクトの管理における安定性と透明性、安定したエコシステム、b) 期待に応える機能性、c) 既存のIT環境への統合、d) ソリューションの提供、e) 幅広い開発者コミュニティ。
パートナーのための価値創造
パートナーの価値創造とは、オープンソースプロジェクトに機能やプラグインを追加するなど、特定のエコシステムの支持者のためにエコシステムで価値を創造することです。
a) オープンソース・プロジェクトの管理における安定性と透明性、安定したエコシステム、 b) パートナーのソリューションを採用する新しいユーザー/顧客を引き付ける十分な勢い、 c) 開発者の幅広いコミュニティ、 d) オープンソース・ソフトウェアが、開発者のソフトウェア開発作業量を削減する、 e) オープンソース・プロジェクトが、オープンソース・ソフトウェアの使用を希望するパートナーと競争関係を作らない。e) オープンソースプロジェクトは、オープンソースソフトウェアの使用を希望するパートナーと競合しないこと。
3つのオープンソースエコシステム
オープンソースの力によって駆動されるエコシステムにおいては、顧客価値を創造する方法、そしてパートナーに価値を創造する方法を考えるために、まずオープンソースのエコシステムの構造を理解する必要があります。簡単にまとめると、オープンソースのエコシステムには主に3つのタイプがあります：
緩やかなプロジェクトと組織構造によって管理されるプロジェクト
一般的に、最も影響力のあるオープンソースプロジェクトは組織によって運営されていますが、最初は緩やかなプロジェクトであることが多いです。開発者コミュニティが成長し、オープンソース・プロジェクトの顧客価値が明確になり、パートナーに対する関与のルールがより強固になるにつれて、緩やかなプロジェクトは、組織的に管理されたプロジェクトへと進化することがよくあります。組織的に管理されたオープンソース・プロジェクトには、同じエコシステムで生き残る数多くの新興企業をサポートできるという特徴があります。
ベンダー管理品目
ベンダがオープンソースプロジェクトに直接または間接的に50パーセント以上貢献している場合、 プロジェクトはベンダ管理下にあると言われます。ベンダーは通常、営利企業です。さらに、オープンソースプロジェクトを主導し、ビジネスモデルを見つける必要があるベンダーは、次のような形態をとることがあります。
ベンダが管理するオープンソースのエコシステムが組織的に管理されるエコシステムに変わることがほとんどない理由は、ベンダが開発コミュニティの多様性を制限し、開発者がそのコミュニティの外で他のスキルを磨く機会を減らしてしまうからです。 これは SDN コミュニティにとって何を意味するのでしょうか？
現在の SDN オープンソースコミュニティはベンダーに支配されています。
今日最も人気のある SDN オープンソースプロジェクトを見てみると、そのほとんどがベンダーによってコントロールされていることがわかります：
投光器：ビッグスイッチ
インディゴ：ビッグ・スイッチ
LINC: InfoBlox
オープンvSwitch: Nicira
トレマ：NEC
例えば、OpenFlowはOpen Networking Foundationによって推進されていますが、今日、ONFはソフトウェアの開発や保守を行っていません。はベンダーが管理するオープンソースプロジェクトに依存しています。
SDN オープンソース: 商用化への道における潜在的危険性
ベンダが支配するオープンソースプロジェクトを戦略的なレベルまで引き上げ、それらに投資することは、SDN スタートアップ、ネットワーキングや仮想化のベンダ、プログラマ、そして多くの理由で参加する顧客にとってリスクの高い試みであることは確かです：
1.参加ルールはベンダーが設定し、ユーザーの知らないところでベンダーが自由に変更できます。
2.エコシステム内の友好的でない企業によるオープンソースプロジェクトの主要ベンダーの買収は、エコシステム全体を商業化のリスクにさらします。買収後、これらの企業は「やりたい放題」になります。将来のリリースでライセンス規則を変更し、サードパーティからの新機能や標準を否定的に受け入れることができます。
3.ビジネスモデルは、常に支配的なベンダーに有利に働く - 定義上、ベンダーが管理するオープンソース・プロジェクトは、支配的なベンダーがエコシステムから最大限の利益を得ることを可能にします。また、ベンダには、自分たちに不利なルールを変更する能力があるため、エコシステムの他のメンバーの利益に深刻な影響を与えます。他のベンダーが管理するオープンソースプロジェクトをサポートする企業への資金調達が困難な理由の1つは、ベンチャーキャピタルが、早い段階でライバルになる可能性のある企業に依存する企業に投資する勇気がないことです。ベンダーがよく使う "トリック "は、サードパーティのアプリケーションが多くのユーザーを惹きつけると、開発者に自分のプロジェクトのためだけに開発するように促すというものです。
リスクは、パートナーに対するものと同様に、顧客にもあります。しかし、アプリケーションに多くの代替手段があれば、顧客にとってのリスクは軽減されます。例えば、SNORT はソースファイアの主導で開発されましたが、SNORT の代替となるアプリケーションは IDS のように数多くあり、エコシステムは比較的小規模です。
ベンダーが支配するオープンソースプロジェクトは、パートナーにとってよりリスクが高くなります。特に、意思決定プロセスが透明でないこと、外部コミュニティのサポートが不足していること、現在のプロジェクトのリーダーが競合他社に買収される可能性があることなどが挙げられます。MySQLがOracleの傘下に入ったことをお忘れなく。
SDN の最大のリスク: Floodlight と Indigo の広範な顧客ベースとパートナー。
これが、ベンダーが管理するオープンソース・プロジェクトが、顧客やパートナーにとって災いをもたらす理由です。あなたが成長のために懸命に働いてきたクールな会社が、顧客やライバルに買収されれば、配当はなくなり、あなたはベンダーに縛られるか、ダモスの剣があなたの頭上にぶら下がることになるでしょう。
はんけつをくだす
SDN 市場で直面している問題は非常に微妙なものです。より多くのベンダが管理するオープンソースプロジェクトが SDN プロジェクトで使用されるにつれて、これはそのエコシステムのユーザにより大きなリスクをもたらします。
もしあなたが顧客で、解決するためにちょっとした戦略が必要な問題を抱えているのであれば、ベンダーが提供するオープンソースソフトウェアを使うのが賢明です。もしその問題がビジネス上の決断に関わるものであれば、多くのフリーランス開発者が関わるプロジェクトなど、他の選択肢に目を向け、サプライチェーンのビジネスモデルにベンダーを含めないこと、つまりベンダーに使用料を支払わないことを検討してください。
ベンダーが管理するオープンソースプロジェクトのパートナーであれば、ベンダーと良好な関係を築くことが賢明です。顧客がライセンスを提供する必要がある場合、まずパートナーにソリューションを提供してもらい、その間にライセンスを購入するか、独自のソフトウェアを開発するのが得策です。オープンソースプロジェクトが成功した場合、ライバルがあなたの依存するオープンソースのエコシステムを併合する可能性が高いことを認識しておく必要があります。
もしあなたがCiscoなら、Big Switchをまだ見ていないとしたら驚きです。もしあなたがCiscoやVMware以外の大手ネットワーキングや仮想化ベンダーなら、市場はまだどこもチャンスのあるブルーオーシャンなので、早めに複数の選択肢に目を向けてください。
最後に、ベンダーが管理するオープンソースプロジェクトにどのように参加し、どのレベルで参加するかは、簡単には決められないかもしれません。一つの道を最後まで貫くことはできません。今日は合っていても、明日はうまくいかないかもしれません。競合他社についても同様です。どのような場合でも、顧客のために価値を創造することを忘れず、ベンダーの管理するオープンソースプロジェクトに参加することを選択した場合のバックアッププランを準備しておいてください。
