最近は誰もがオープンソースに興味を持っています。Microsoftは3D Movie Makerソフトウェアをオープンソースライセンスでリリースしました。Spotifyは数多くのプロジェクトをリリースし、貢献しており、プロジェクトのメンテナーを支援するための基金を設立したばかりです。中世（1998年）のゲームエンジンのコードまでオープンソース化されています。
参照: 採用キット: バックエンド開発者(TechRepublic Premium)
これらのプロジェクトや数百万ものプロジェクトが存在する中で、当然の疑問が湧いてきます。それは「なぜ？」という問いです。あるいは、なぜこれらのプロジェクトの大部分が重要なのか、そして誰にとって重要なのか、という問いです。結局のところ、ほとんどのプロジェクトはKubernetesにはなり得ません。
しかし、オープンソースに20年以上携わった今、私はこれが間違った質問であることに気づき始めています。
爆竹の例
AWSが2018年にリリースしたオープンソースのマイクロ仮想化プロジェクト、Firecrackerを例に挙げましょう。Firecrackerはほぼ普遍的に優れた技術として称賛されましたが…その後、ほとんど人々の目に触れなくなりました。初期のコミュニティでの成功についても記事を書きましたが、それも（Firecrackerの使いやすさを向上させるWeave Igniteなど）親しいAWSパートナーによるものでした。Firecrackerのコミュニティの影響力を高めるため、私はAWSがGoogleに倣い、コードだけでなくFirecrackerのガバナンスも公開することを提案しました。
AWS は私の意見に耳を傾けませんでしたが、今回が初めてではないものの、私の意見は無視されたようでした。（これは、私が間違っていたかもしれないということを丁寧に表現したものです。）
2022年現在、Firecrackerは多くのクールな場所で静かに使われ始めています。「静かに」というのは、そもそもインフラのことを大声で叫ぶ人がいるでしょうか？しかし、尋ねてみると、Stripe、Fly.io、System Initiativeなど、興味深いユーザーがいくつか浮かび上がってきました。もちろん、Firecrackerへの貢献者のほとんどがAWSに勤務しているというのは、今でも変わりません。
しかし、たとえFirecrackerがAWSというたった一つのコミュニティに留まっていたとしても、おそらくその価値はあったでしょう。実際、これは私がAWSで働いていた頃に主張していたことと基本的に同じで、コミュニティの関与の有無に関わらず、Firecrackerをオープンソース化する明確な顧客志向の理由があると主張していました。オープンソース化によって、FirecrackerはLinuxコミュニティとうまく連携し、顧客にとってより緊密な「複合的な製品ゲイン」を実現できました。
数百万の爆竹
では、このFirecrackerの例を、1億を超えるGitHub（およびその他のオープンソース）リポジトリで展開してみましょう。これは、次世代のKubernetesになることを目指しているわけではありません。それぞれのオープンソースプロジェクトにおいて重要なのは、個々の開発者、企業、あるいはより広範なコミュニティのニーズを満たすことです。
時には、そうしたニーズは大きなものになることもあります。Lyftのエンジニアリングリーダーであり、Envoyの創設者でもあるマット・クライン氏との会話の中で、彼は「オープンソース化する人のほとんどにとって、それは実際にはマイナスです」と強調しました。「投資をせず、PR、マーケティング、採用など、あらゆることを行わなければ、ただ放り投げるだけになってしまうからです」。クライン氏にとって、Envoyへの業界全体からの大きな関与は、彼（ひいてはLyft）の投資に見合うだけの価値のあるプロジェクトにするための助けとなりました。
参照:知っておくべきオープンソースと Linux の用語 40 選 (TechRepublic Premium)
しかし、誰もがそのようなリターンを得る必要があるわけではないと言えるでしょう。Firecrackerの場合、コードをオープンソース化し、顧客との連携だけで十分だったと、私は考えました。一方、Kubernetesを通じてマルチクラウドの実現を推進しようとしていたGoogleの場合は、大規模な取り組みが必要でした。プロジェクトごとにニーズも成功の尺度も異なるからです。
では、あなたは次のKubernetesではないのでしょうか？それはそれで構いません。また、次のFirecrackerでもないのでしょうか？これもまた構いません。オープンソース開発者にとって重要なのは、自らのニーズにとって健全なプロジェクトとは何かを理解し、他人の成功の定義に惑わされないことです。
開示: 私は MongoDB で働いていますが、ここで述べられている意見は私自身のものです。
