数年前、テクノロジーウェブサイトZDNetの記事で、著者は「オープンソースは、エンタープライズソフトウェアにとって新たな、デフォルトのビジネスモデルに成長したのだろうか？」という疑問を投げかけました。それからわずか数年しか経っていないにもかかわらず、今振り返ると、Redis、MongoDB、Confluentといった企業が繁栄し、もはやオープンソースの価値を疑う人はいないことを考えると、この疑問は少々奇妙に思えます。

しかし、オープンソースは昨今、論争の的となっています。例えば、MariaDBのCEOであるマイケル・ハワード氏は、これらのクラウドコンピューティング大手企業が様々なオープンソースリソースを略奪する「露天掘り」を行っていると批判しました。火のないところに煙は立たず、最新の論争の波は先週、AWSが強化されたオープンソースElasticsearchディストリビューションを発表したことから始まりました。ZDNetの記者スティーブン・J・ヴォーン＝ニコルズ氏が報じたように、激しい舌戦の中で、ElasticとAmazonは共に世論を支配しようとしています。

オープンソースがソフトウェア業界にどのような変革をもたらしたかについては、もはや説明する必要はないでしょう。例えば、ニューヨークはウォール街のおかげで「テックシティ」とみなされるようになりましたが、以前は技術がサイロ化していることで知られていました。オープンソース化以前は、技術の壁により、企業は高性能なメッセージ配信からコンピューティンググリッドやデータベースに至るまで、ITインフラとソフトウェアを独自に開発する必要がありました。誰も他者と交流しようとはしませんでした。

その後、ウォール街の企業は、特にコアインフラソフトウェアや機械学習アルゴリズムといった、自社の知的財産の価値が高い分野では、車輪の再発明を避けたいため、オープンソースを優先する必要があることに気づきました。また、自社の技術をより移植性の高いものにしたいと考えていたため、オープンソースソフトウェアを使うことで優秀な人材を失うことも避けたいと考えていました。それ以来、ウォール街の企業は、従業員がオープンソースに関する知見をオープンに議論することを厭わなくなり、むしろ独自のオープンソースプロジェクトを立ち上げることさえ奨励するようになりました。ほぼ毎晩、街中で様々な集まりが開催され、オープンソースの実践者たちがイノベーションを共有するようになりました。

しかし、オープンソース企業は、プロジェクトの人気が高まるほど、より大きな「成長痛」に直面することになるでしょう。例えば、MongoDBは3億ドルの投資を誰にも奪われたくありません。これらのオープンソース企業にとって、他者による模倣は真の学びと敬意の表れかもしれませんが、同時に将来の利益にとって大きな脅威となります。オープンソース企業は、他者の踏み台や犠牲になりたくありません。

MongoDBやRedisのような企業は、プロジェクトが多くの支持を集めているため、脅威を感じているのが現状です。一方、Clouderaのような企業は、プロジェクトの魅力が低いため、全く脅威を感じていません。そのため、ClouderaはAWSとAzureを寄生虫ではなく、パートナーとして捉えています。

Adobeの開発者エコシステム責任者であるマット・アセイ氏は、最近のホットな話題について頻繁にコメントしています。最近の投稿で彼は、オープンソースコードをダウンロードしたり使用したりする開発者のほとんどは、既に通常の仕事を持っているため、コードに手を加えたり貢献したりする時間はないと述べています。そのため、ライセンスの変更、特にサードパーティのSaaSサービスの実行を禁止するような変更は、彼らにとって無関係です。

現在の戦いにおいて、Amazonは新たな戦線を開き、NetflixやExpediaといった顧客企業と協力し、Elasticsearchプロジェクトの新たなオープンディストリビューションを開発し、すべてのリソースをオープンソースプロジェクトに提供しています。Amazonは、Elasticがオープンソースとプロプライエタリのコードを混在させることで問題を混乱させていると主張しています。しかしElasticは、異議を唱えているのはAmazonであり、すべてのクラウドプロバイダーではないと主張しています。

Elasticsのビジネスモデルは、当初からオープンソースソフトウェアとプロプライエタリソフトウェアの組み合わせに基づいています。Elasticsearch、Kibana、Logstash、Beatsといったコア製品はすべてApache 2.0オープンソースライセンスに基づいています。議論の焦点となっているのは、セキュリティ、アラート、監視、レポート、グラフ分析、機械学習を扱うElastic Stackの機能（拡張機能またはプラグイン）です。以前はX-Packsと呼ばれていましたが、これらはクローズドなプロプライエタリソフトウェアと見なされており、当初は一部の機能は無料で、その他の機能は有料サブスクリプションでのみ提供される、典型的なオープンコア製品を目指していました。これらの機能がプロプライエタリであることを考えると、サードパーティのエコシステムがそれらを置き換えるために登場したのも当然と言えるでしょう。

昨年、ElasticはOpen Coreモデルに関する意見の相違が見つかったため、いくつかの変更を行いました。その1年前、ElasticのCEOであるShay Banon氏はブログ記事で、オープン化のタイムラインを倍にすると、有料コンテンツと無料コンテンツの間に明確な線引きができてしまい、コミュニティに悪影響を与えると述べていました。彼は、この線引きは機能の幅広さに影響を与えるだけでなく、テストの不一致にもつながると指摘しました。彼は、これらの特性が絡み合っている場合、断片化されたコードは分断された都市と同じくらい想像できないものだと述べています。

問題は、混沌への道が善意、より正確に言えば、非常に理想的な意図で舗装されていることです。Elasticのアプローチは称賛に値します。独自のソースコードを公開ダウンロード可能にすることで、サードパーティが商用SaaSサービスとして提供する可能性を制限しています。しかし、AWSが主張するように、ダウンロードフォルダ内のファイルはApache 2.0とElasticのライセンスコードが混在しており、事態をかなり複雑化させています。

Elasticは、ElasticライセンスとApacheライセンスコードは別のフォルダに保存されており、その違いは非常に明白だと主張しています。しかし、私たちの見解では、その違いは非常に微妙です。さらに、たとえElasticがApacheライセンスコードとElasticライセンスコードの間に明確な区別を設けるために壁を作ったとしても、Amazonがそこで止まらないという保証はありません。

この間、MongoDBとConfluentもそれぞれの計画の実現を加速させていました。合意に至らなかったため、MongoDBはオープンソース・イニシアチブから撤退し、その後、4.0プラットフォームのあらゆる側面をカバーするSSPLの推進を開始しました。一方、Confluentは、Apache Kafkaのコンポーネント（KSQL、Confluentコネクタ、RESTブローカー、コントロールセンター、その他いくつかのコンポーネントを含む）を含むConfluentコミュニティ内でのライセンスを推進しています。

さらに、Redisは昨年夏、RedisモジュールでCommons条項（データベース自体ではありません）をリリースし、その後、Redis Source Available License（RSAL）と呼ばれる新しい条項の下で制限を緩和しました。ここで朗報なのは、Redisが率直に意見を述べていることです。つまり、RSALがオープンソースライセンスであると主張しているわけではありません。

これらはオープンソース企業が直面する課題です。従来のプロプライエタリソフトウェアと比較して、オープンソースソフトウェアやプロジェクトはターゲット市場を広げ、大規模なコミュニティを構築する重要な機会を提供し、ユーザーがインストール基盤を確立することを可能にします。しかし、この諸刃の剣の裏には、これらのプロジェクトが非常に人気があるという側面があります。オープンソースプロバイダーにとって永遠の課題は、競争力の維持です。新しいリリースパイプラインが速ければ状況はそれほど悪くないかもしれませんが、競合他社が追いつくと話は別です。例えば、AWSはかつてHadoopのバージョンサポートで遅れをとっていましたが、後に最も安定したApacheバージョンのリリースから30日後に対応しました。この時点で、時間はもはやオープンソースベンダーの味方ではありません。

もう一つのリスクはフォークであり、ベンダーはプロジェクトをサポートするコミュニティを自ら切り離さざるを得なくなります。これは、コミュニティによって管理されていないオープンソースプロジェクト、特にベンダーにとって大きな課題です。MongoDBはその好例です。MongoDBはプロジェクトの旧バージョンをベースに新機能を開発しますが、AmazonやPerconaといったサードパーティはSSPLに縛られない旧バージョンをベースに新機能を開発しています。コードはフォークされるため、これがコミュニティの分断につながるかどうかが問題となります。ElasticのBanon氏が懸念しているのは、無料のオープンソース版のユーザーと有料のエンタープライズ版のユーザーをどのように分離するかという点です。

オープンソース企業は、防衛に活用できる知的財産を必要としています。しかし、Red Hat（間もなくIBM傘下となる）は今のところ例外であり、純粋なオープンソース企業がコミュニティ主導のプロジェクトに基づく製品でいか​​に成功できるかを示しています。一方、Clouderaは、この状況を打破し、新たな例外となることを目指しています。

では、オープンソースライセンスの新しいバリエーションは、エコシステム全体にとって解決策となるのでしょうか？ここでの危険な点は、クライアント側の法務担当者や契約執行担当者がライセンスに飽きてしまい、抵抗を示す可能性があることです。

オープンソースベンダーにとって重要なのは、ユーザーの懐疑心を招きかねない行為を避け、確立されたオープンソースライセンスを堅持することかもしれません。そして、それらをベースに独自のコンテンツを開発し、オープンソースプロジェクトに付加価値を与えます。同時に、付加価値コンポーネントの抽象化も独自性があり、オープンソースコンテンツに最適化されている必要があります。限定的なプロプライエタリコードのリリースは継続しますが、それがオープンソースであると偽ってはいけません。もちろん、オープンソースモデルが老朽化していることを考えると、これは容易なことではありません。再び変革とアップデートが必要になるかもしれません。