DUICUO

クラウドとオープンソース:技術の食物連鎖の進化

編集者注:この記事の原著者であるチャールズ・フィッツジェラルドは、シアトル地域を拠点とするエンジェル投資家であり、エンタープライズプラットフォームと戦略的投資に注力しています。彼は以前、MicrosoftとVMwareに勤務していました。

Marc Andresseessen 氏の「ソフトウェアが世界を飲み込んでいる」は、「オープンソースがソフトウェアを飲み込んでいる」、「クラウドがオープンソースを飲み込んでいる」、「マルチクラウドがクラウドを飲み込んでいる」などの主張を含む、完全な技術的食物連鎖を生み出しました。

[[283646]]

誰もが食物連鎖における自分の立場に満足しているわけではありません。頂点捕食者や重要な種族になりたいと思わない人はいないでしょう。特に、上記のランキングに異議を唱える人もいます。オープンソースは実際にはクラウドを「食い尽くしている」と主張するのです。

「オープンソースがクラウドを飲み込んでいる」という表現の意味は理解できませんが、よく耳にします。確かに「飲み込んでいる」というのは正確な表現ではなく、様々な解釈が可能です。しかしながら、オープンソース支持者がこの競争でなぜこれほど高い評価を得ているのかを理解しようとすると、すぐに曖昧になり、形而上学的な話にさえなってしまいます。確かにクラウドが収益の大部分を占めているかもしれませんが、これはオープンソースにとって道徳的な勝利と言えるでしょう。

パブリッククラウドはオープンソースソフトウェアを採用し、サービスとして運用しています。パブリッククラウドはオープンソースによって支えられていると言えるかもしれませんが、クラウドは依然としてリソースを消費しているように見えます。経済的な観点から見ると、クラウドは特定のプロジェクトを中心に構築された企業よりも、オープンソースビジネスに適しているように思われます。よく見てみると、オープンソースは、世界最大規模かつ最も裕福な企業への非常に寛大な慈善寄付と見なすことができるでしょう。

私たちの食物連鎖の二分法は、オープンソースとクラウドという根本的に異なる概念に起因しています。オープンソースの愛好家や企業は、ソフトウェアの特定の部分とその構築方法に焦点を当てています。一方、パブリッククラウドはソフトウェアの枠を超え、非常に広範な存在レベルで動作します。ソフトウェアはサービスの唯一の構成要素ではなく、重要な構成要素です。

パブリッククラウドは、大洋横断ケーブル、コンクリートスラブ、信頼性の高い電子フロー、数百万基のCPU、数メガバイトのディスクスペース、膨大なソフトウェアランタイム、合法的なステータス、そして24時間365日体制の運用とサポートを提供する大規模なコミュニティを組み合わせ、これらすべてをクレジットカードを持つ誰もが利用できる取引可能なユーティリティに統合しています。ソフトウェア開発者は、クラウドサービスが単なるソフトウェアのインスタンスではなく、運用そのものがその機能であることを理解していないことがよくあります。

クラウドの価値の大部分は、基盤となるソフトウェアとは直交しています。つまり、クラウドによって顧客は価値の低い/複雑性の高い操作から解放されるのです(これは、神聖なオープンソースソフトウェアと有害なプロプライエタリソフトウェアの両方に当てはまる特性です)。オープンソースソフトウェアは往々にして複雑性に偏り、時には非常に複雑になることもあり、そのためサービスのパッケージ化と提供がより魅力的になります。

クラウドによる予期せぬ非対称競争はオープンソース企業を困惑させ、ソフトウェアにおける競争優位性、つまりソフトウェアを誰よりも深く理解しているという強みが、彼らが期待していたような乗り越えられない堀ではないという事実に直面せざるを得なくなりました。自社製品が今やより広範な製品の単なる機能に過ぎないことに気づくのは楽しいことではありませんが、それがソフトウェアの現実です。オープンソースがクラウドを飲み込んでいると主張するのは、コーヒー農家がスターバックスを飲み込んでいると主張するのと同じです。意図的に(あるいは単なる妄想かもしれませんが)、消費者が購入するものの大部分を無視しているのです。

オープンソースが食物連鎖の競争に勝つかどうかについての議論は、結局は繰り返される主張に行き着くようです。「結局のところ、オープンソースの明白な栄光ゆえに、勝利は必然だ!」

この記事の着想の源は、ハイブリッドクラウドが「クラウド市場のすべてを変えた」というIBMの誇張された主張を勇敢に擁護した若いIBM社員でした。IBM社員で、特に仕事以外でわざわざ会社を応援する人は多くありません。ですから、彼の努力には(たとえそれがいかに絶望的に思えても)拍手喝采せざるを得ません。しかし、彼の主張は「オープンソースがクラウドを飲み込む」というマントラの繰り返しに過ぎず、オープンソースの本質的な正しさと優位性を信じているだけで、顧客のより広範な懸念、個々の価値提案、バリューチェーンにおける位置付け、あるいは潜在的な経済効果といった要素は考慮されていません。

そこでこの記事では、あらゆる方面からの悪意ある攻撃を集め(そして、オープンソース純粋主義者、オープンソースだが真のオープンソース改革者ではない人々、そしてこの記事で言及されているすべての企業を激怒させることを願って)、この議論をより深く理解しようと試みました。(ちなみに、私はプロプライエタリライセンスソフトウェアの全盛期にマイクロソフトで働いていたので、オープンソースソフトウェアの最も基本的なルールさえ理解していないかもしれません。)

AWSとオープンソース

現在の議論は、主にAmazonと、サバンナのガゼルのような複数のオープンソース企業、特にElasticとMongoDBを中心に展開されています。AWSは一貫して「お客様の声」をメッセージングの軸としてきましたが、Elasticのような人気のオープンソースプロジェクトをベースにした独自のサービスや、MongoDBと互換性のあるサービスを提供しているため、これらのプロジェクトに関連する比較的成功している商用オープンソース企業と競合しています。Elasticの場合、AWSはElasticが独自ソフトウェアとして保持していた機能を備えた、新たなオープンソースディストリビューションを惜しみなく提供しています。

これらの「獲物」からの反応は、大胆に挑発的なブログ投稿から、AWSが表向きはオープンソースソフトウェアを使っていることを妨害しようとする必死のライセンスプロジェクトまで、多岐にわたりました。Cockroach LabsやRedis Labsといった他の企業も、独自の新しいライセンスを導入しました。これは、オープンソースの存在主義と哲学に関する議論を再燃させました。オープンソースとは言論の自由に関するものなのか、それともプロジェクトの主要貢献者のための自由な堀を持つ権利も含むのか?結局のところ、オープンソースの達人たちは、「競合相手がいない限りオープンにする」というアプローチを否定しているようです。

さらに、オープンソースソフトウェアを機能させているのはAWSだけではありません。GoogleとMicrosoftも、オープンソースソフトウェアを基盤とした数多くのサービスを展開しています(そして、自社のソフトウェアの一部もオープンソース化しています)。彼らの取り組みの中には、新たなオープンソースの反キリストとしての役割を担うAWSと対比させるだけのものもあります(これは、DatabricksやHashicorpといったオープンソース企業との緊密なパートナーシップを通じてサービスを展開している、かつての反キリストであるMicrosoftを喜ばせています)。

クラウドの出現は、多くのオープンソース企業に自社のサービスをより真剣に受け止めさせるようになりました。ElasticとMongoDBはどちらも、大規模なパブリッククラウド上で成功を収めたクラウドサービスを提供しており、自社のソフトウェア運用において他社に優る存在ではないと断言できます。AWSの導入がこれらの企業のサービスに恩恵をもたらしたと考える人もいます。

しかし、根本的な問題は、顧客が特定のソフトウェアを開発するOSS企業が提供する「より良い」パーソナライズされたサービスを好むのか、それともパブリッククラウドが提供する「十分な」バージョンを好むのか、ということです。パブリッククラウドはオリジナルのソフトウェアを開発していないかもしれませんが、グローバルにサービスを提供し、すべてのサービスを単一の画面で管理できます。すべてのサービスに対して単一の課金体系があり、補助サービスとのより深く容易な統合が可能で、顧客獲得コストも低くなります。先ほども述べたように、問題は「商用オープンソース企業は、パブリッククラウドの巨大で破壊的な影響力に耐え、あるいはその価値に耐えることができるのか」ということです。このテーマについては多くの真剣な議論が行われており、私の記事よりも長い記事もあります。

「完全交換」

A16Zのピーター・レヴィン氏は、この問題に対する我々の反応は過剰だと考えている。「パブリッククラウドプロバイダーの脅威に焦点を合わせすぎているように思います。これらのプロバイダーはオープンソースプロジェクトをホストしているかもしれませんが、私の知る限り、今のところ、クラウドプロバイダーに完全に置き換えられたオープンソース企業はありません。」

「完全な置き換え」というのは婉曲表現ですが、ついにこの議論に引き込まれました。マルチクラウドの平原で現在狩られている獲物の潜在的な運命に焦点を当て、デイビッド・アッテンボローとの議論を続けるのではなく、スコアボードを見て、オープンソースとクラウドの間で繰り広げられているいくつかのゲームで何が起こっているのかを見てみましょう。まだ終わっていないゲームもありますが、結末はますます明らかになってきています。

実際、大手OSS企業の中には、最近になって売上の勢い、重要性、評価、そして独立性を失った企業もいくつかあります。それらの企業に残った噛み跡の大きさや形から判断すると、これは新たな頂点捕食者、つまりクラウドの仕業のように思えます。

OSS推進派はこの食物連鎖の競争に勝利した。特にソフトウェアブームと株価記録の高騰期において、これらの企業の将来性が暗い理由を説明する必要がある。OSSは「完全に置き換えられた」わけではないが、Hadoop企業のPivotalと、つい最近になって最大のオープンソース企業となったRed Hatの苦境は注目に値する。

Hadoop産業複合体

つい最近まで、Hadoopとその商用リーダーたちは大きな注目を集めていました。Cloudera、HortonWorks、MapRは合計で15億ドル(それぞれ10億ドル、2億4,800万ドル、2億8,000万ドル)を超える資金を調達しました。これには、IntelによるClouderaへの2度目の投資という印象的な出来事も含まれています。

ClouderaとHortonworksはともにIPOで3億3500万ドルを調達しました。しかし、業績不振により両社は合併を余儀なくされました。今年初め、両社はひっそりと合併し、創業者はひっそりと両社を去りました。両社の時価総額は、合併発表時の52億ドルから、本稿執筆時点では約25億ドルに減少しました。しかしながら、非公開のままであったMapRは後にHPに売却され、HPは「非常に有利な取引だった」と豪語しました。

Hadoopは、巨額の費用を投じて「データレイク」を構築したものの、導入と管理に苦労し、ビジネスリターンを得るどころか、顧客にとって大きな痛手となりました。一方、ビッグデータ関連企業は、安価で利便性の高いクラウドコンピューティングに移行しました。マシュー・ロッジ氏が述べたように、「皮肉なことに、Clouderaにはクラウド時代がありませんでした」。

もう一つの仮説(つまり、クラウドがオープンソースを飲み込むのではないという仮説):Hadoopは単に過大評価されていただけだ。一部の人は、Hadoopが様々な既存のデータベース技術に取って代わると主張した――TAMにとっては素晴らしい話だが――しかし、Hadoopは結局、あらゆるデータトランザクションの集大成に過ぎず、何も達成できなかった。貴重なデータを湖に投げ込むという比喩も適切ではない。Hadoopから学ぶ教訓は、「次なる大物」となるような壮大な技術的約束には、改めて警戒すべきだということだ。

極めて重要な

Pivotalは、Pivo​​tal Labs、SpringSource、Greenplumといった買収に加え、VMwareによるこれらの事業への投資、そしてCloud Foundryのゼロからの構築によって成り立っています。Pivotalは2018年4月のIPOで5億5,500万ドルを調達し、1株あたり15ドルで上場しました。最高値は74億ドルでしたが、その後、「販売実行」の問題と「複雑な技術見通し」により、数四半期にわたって目標達成を逃しました。VMwareからの買収提案を受けた時点で、時価総額は22億5,000万ドルに急落していました。皮肉なことに、当初サービスとして設計されたCloud Foundryは、自社でサービスを展開・管理しなければならない企業に製品を販売するという複雑なプロセスに陥ってしまいました。そして、企業はクラウドという選択肢を選んだのです。

もう一つの仮説は、Pivo​​talが同じくオープンソースの「DockerNetes」に買収されたため、クラウドや同社の短期IPOはPivotalとは何の関係もないというものです。この説は、クラウドサービスの販売ではなくコンサルティングサービスの販売に忙殺されていた経営陣によって支持されました。

レッドハット

最後に、長年オープンソースの擁護者であり続けてきたRed Hatがあります。Red Hatは、オープンソースのウェブサイトで優れたビジネスを構築できることを最初に(そして長きにわたり)証明した唯一の企業であり、最も成功した事例でもありました。しかし、この「モデル」は私たちの議論の範囲を超え、まもなくIBMミドルウェア博物館の単なる脚注の一つとなるでしょう。なぜでしょうか?それはクラウドのおかげなのです。

レッドハットは数十億ドルの売上高、潤沢な利益、数十億ドルの銀行預金、そして二桁の成長率を誇り、昨年までは高成長株として評価されていました。IBMは340億ドルでレッドハットを買収しましたが、これはソフトウェア企業買収史上最大の額でした。IBMは支払い過ぎたと私は考えています(ワトソンが価格設定に関与した可能性もある)。しかし、レッドハットの経営陣と株主がIBMから資金を受け取ったという事実は、クラウド時代における同社の将来に対する彼らの自信のなさを浮き彫りにしています。6ヶ月前に史上最高値を記録した株価で撤退する意思を示したことは、評価額を回復するどころか、それを上回ることさえできないという自信の欠如を示唆しています。彼らは現金を受け取り、IBMの根強く止められない衰退を覆すレッドハットのような復活劇(もしかしたら賢明な判断だったのかもしれません)を排除しました。

以前にも述べたように、Red Hatにも独自の課題がありました(買収価格の面では、IBMとその株主に大きなメリットをもたらす完璧な解決策を見出したのです)。IBMにとってRed Hatは宝石のように輝いていたかもしれませんが、クラウド関連の問題も抱えていました。Red Hatは商用オープンソースの好例ですが、これはほとんど無関係です。Red Hatは、テクノロジー業界の非常に伝統的な問題、つまり世代交代という問題に直面していました。収益の大部分は「インフラ関連製品」、すなわちRed Hat Enterprise Linux(RHEL)サーバーOSから得られていました。コンピューティングが顧客のデータセンターからパブリッククラウドへと移行する中、RHELはそれに追いついていませんでした。クラウドはLinux上で動作するという話を耳にしたことがあるかもしれません。確かにそうですが、RHEL上では動作しません。AWS、Azure、GoogleはRed HatにLinuxのライセンス料を支払っていません(顧客が必要に応じてRHELをゲストOSとして実行することは許可していますが、ライセンス料を支払う根拠はますます薄れつつあります。ハイパースケールクラウドに必要でないのであれば、なぜそうするのでしょうか?)。 Red Hatの中核事業の成長が鈍化し、2四半期連続でウォール街の期待を下回ったことで、縮小するTAMは2018年にようやく問題の兆候を見せ始めました。これは成長株に典型的に見られる問題であり、時価総額の3分の1が消失したことからも明らかです。こうした失敗と将来の見通しの不透明さが相まって、Red HatはIBMに打診する時期だと判断したのかもしれません。

もうひとつの仮説は、Red Hat の経営陣が、素晴らしいクラウド戦略があると聞く耳を持つ人全員に伝え、その強力なクラウド戦略を強化するためにどの企業と提携できるかを業界全体で検討し、IBM を選んだというものです。

歴史の終わり

「成功は悪い教師だ」という格言は、ビル・ゲイツ氏を含め、広く真実だと考えられています。オープンソースの現状は、21世紀初頭のマイクロソフトの状況と驚くほど似ています。同社は好調で、現状維持に甘んじていました。しかし、オープンソースソフトウェアとSaaS(Software as a Service)がこの快適な世界を揺るがすと、同社は変化を拒み、旧来の世界秩序を優先しました。

クラウドの台頭は、一部のオープンソースソフトウェア企業から驚くほど似たような反応を引き起こしました。完璧なモデルがあると思った瞬間に、それは破壊されるのです。オープンソースはソフトウェアの歴史の終わりではありません。歴史の終わりをめぐる議論は、特にテクノロジー分野においては非常に苛立たしいものです。なぜなら、テクノロジーはほぼ常にトレンドを追うからです。実際、オープンソースは脆弱なビジネス戦略であり、実行可能なビジネスモデルというよりも、プロジェクトとソフトウェア企業間の緩い関係に依存しているからです。

マイクロソフトや過去のソフトウェア開発者たちが、最終的には変化を受け入れ、受け入れざるを得なかったように(成功例もあれば失敗例もあった)、商用オープンソースの世界でも同じことが言えます。矛盾する証拠に直面した時、自分が理想だと信じているものや不朽のパターンに固執するのは良い戦略ではありません。適応するか、死ぬかのどちらかです。

オープンソースは開発モデルとして存在しています。オープンソースではないインフラや開発ソフトウェアを想像するのは難しいですが、それに対応するビジネス戦略については、まだ多くの課題が残されています。オープンソースの次の大きな取り組みは、少なくとも重要なワークロードにおいては、マルチクラウドを実現することかもしれません。しかし、関連する新しいビジネスモデルは、サービスを主要な提供モデルとして捉え、クラウドサービスの特性、つまり統合レベルに真剣に取り組む必要があります。