- 商用オープンソース企業は、既存の有料製品にMITライセンスを付けた代替品だけでは長く持ちこたえにくく、オープンソースである必然性か、より優れた製品力が必要
- 非営利・スポンサー支援型のプロジェクトと異なり、オープンソースビジネスは収益がなければ採用、成長、継続的な開発を続けられない
- 初期段階の企業は無料ティアやオープンソース版を選びやすく、大企業はSaaSコストを予算項目として処理するため、安さだけで購買判断を覆すのは難しい
- オープンソースが強みを発揮するのは、クローズドソースが顧客の信頼を揺るがす透明性の問題や、多数の連携・プラグインを必要とする拡張性の問題があるとき
- PostHog、Medplum、SuperTokens、TableFlow、Minio、Airbyte、Elasticの事例は、オープンソースが監査可能性、セルフホスティング、コミュニティ貢献を通じて、より良い製品へ発展できることを示している
オープンソース代替だけでは不十分
- 「Stripe Billingのオープンソース版」「Chargebeeのオープンソース版」といった説明は、製品を素早く理解してもらうには有用だが、事業継続の根拠としては弱い
- 商用オープンソースツールは、すでに成功している有料製品のオープンソース代替という立ち位置だけに依存するのは難しい
- 開発者が製品を模倣してMITライセンスを付けるだけでは不十分で、オープンソースであること自体も成功を保証しない
- 議論の対象は、人気のある有料ソリューションと競合する商用オープンソースプロジェクト
- React、TypeORM、VSCodeのようにコミュニティ中心だったり支援を受けたりしている製品は優先順位が異なる
- ReactはMetaのようなより大きな組織の支援を受け、TypeORMは寄付で開発資金を確保している
- こうしたプロジェクトは本質的に事業体ではない
- オープンソース企業が成功するには、オープンソースであるべき明確な理由があるか、競合を上回らなければならない
成功基準は利用量ではなく収益
- 寄付や親会社の支援を受ける非営利プロジェクトを除けば、一般的なオープンソースビジネスの最終的な基準は収益
- 営利企業は収益によって人材採用、成長、持続可能性、継続開発のための原資を確保する
- 無料ソフトウェアを作りながら収益を上げる企業は前向きな事例であり、オープンソース企業も顧客を過度に搾取したいのではなく、事業を継続したいだけ
- MongoDBは4,600人以上の従業員を抱える大手データベース企業へと成長した
- その後、Cloud Providerがプロジェクトに貢献せずサービスを展開することを制限するため、SSPLライセンスへ移行した
- SSPLはOSI承認を受けていないが、実質的にはオープンソースに近いと表現される
- 長期的な成功を測る際には、採用率と売上を区別する必要がある
- プロジェクトの採用率が高くても売上を生み出せなければ消えていく可能性がある
- コミュニティがプロジェクトを引き継ぐだろうという期待を裏付ける証拠は、ほとんどないと見られている
安さは持続可能な勝負どころではない
- 価格に敏感な顧客だけを狙う戦略は、負け戦に近い
- Amplitudeのオープンソース版を作るという仮想例では、Amplitudeは高価で、初期企業には負担が大きく、大企業もコスト削減できるという理屈は成り立つ
- しかし初期企業は価格に敏感だからこそ、オープンソース版や無料ティアを選ぶ可能性が高く、それだけでは事業を支えるのに十分ではない
- より安い代替を作る戦略は、たいてい将来の破綻につながる切符に近い
- 大企業も通常、Amplitudeの費用で会社が傾くとは心配しない
- 契約交渉では予算内で価格を精査することはある
- しかし大半のSaaSは、結局はコスト項目の一つにすぎない
- より重要なのは、良いソリューションか、長期的に継続しそうか、運用しやすいかという点
- オープンソースソリューションのデプロイは運用が難しい場合がある
- 例外は、ソリューションのコストが全体予算の非常に大きな割合を占めるとき
- データベース使用量によってOracleコストが急増し、Oracle依存を減らさざるを得なかった企業がこれに当たる
- しかし多くのオープンソースソリューションは上位3つのコスト項目を置き換えるわけではないため、価格が最優先の判断基準になりにくい
オープンソースが勝つ第一の方法: 透明性
- オープンソースソリューションが強力になる代表的なケースは、クローズドソースが顧客とベンダーの間に不信を生む透明性の問題があるとき
- Amplitudeのオープンソース代替としてはPostHogがある
- PostHogはAirbus、DHL、Staplesを顧客に持ち、成長している
- 複数のプロダクトSaaSソリューションを組み合わせ、オープンソースとして提供している
- ブログのソースコードやroadmapまで公開されている
- PostHogは、分析ツールがIPアドレス、名前、セッション録画などの機微な顧客データを扱う点で、競合製品より優れた製品として位置づけられている
- GDPRやCCPAのようなデータ規制が増える環境では、第三者がこうしたデータを保存すること自体が負担になりうる
- PostHogは2つの選択肢を提供する
- 分析ソリューションを自社でセルフホスティングする
- PostHogを第三者として利用しつつ、データ保存方法や将来的にセルフホスティングへ移行できる仕組みに関する透明性を確保する
- 最もプライバシーに配慮した方法がセルフホスティングだとしても、多くの企業は依然としてホスティングモデルを選ぶ可能性がある
- その場合でも、ソフトウェアが行単位でどう動作するかを確認できる
- 必要なときにセルフホスティングモデルへ移行する手順も把握できる
- オープンソース企業は、第三者の必要性をなくして勝つのではなく、動作の公開監査を可能にすることで信頼を得る
透明性が重要な製品の例
- Medplumは、既存のクローズドな事業者と競合するオープンソースの電子健康記録プラットフォーム
- オープンソースであるため、プラットフォームが正確に何をサポートし、何をサポートしないかをユーザーが確認できる
- SuperTokensは、Auth0のような認証ソリューションのオープンソース代替
- ログインは、名前、メールアドレス、パスワードのような機微データを扱う
- オープンソースであることが、より大きな信頼の獲得に役立つ
- TableFlowは、FlatfileのようなCSVインポートプラットフォームのオープンソース代替
- Minioは、AWS S3ストレージのオープンソース代替
- S3には、スクリーンショットや構造化されたJSONファイルを通じて顧客のPIIが保存されうる
- ユーザーデータに誰がアクセスできるかを気にする企業にとって、Minioは代替になりうる
- AWSはAWS社員が顧客データに直接アクセスしないと主張しているが、クローズドソースではその主張は信頼の問題として残る
- Lagoも請求やプロダクト利用量情報を扱っており、この情報は機微なコンテンツに近いため、オープンソースを通じてユーザーの信頼をより築きやすいと考えられる
オープンソースが勝つ第二の方法: 拡張性
- オープンソースの大きな利点の一つは、ニッチな機能開発をコミュニティに開くこと
- 中核製品は通常、中央のエンジニアリングチームが維持するが、連携やプラグインはコミュニティ開発者が作り、ときにメインブランチへマージされる
- クローズドなソリューションは自前のエンジニアリングチームに依存しなければならず、同じ方法で拡張しにくい
- 多数のライブラリ、フレームワーク、アプリケーションと接続する必要があるシステムを作るオープンソース企業にとって、この点は特に有利
- AirbyteはオープンソースのELTプラットフォームで、コミュニティが追加したコネクタによって大きく成長した
- Elasticも、もともとオープンソースだったより大きな企業であり、多数のデータ連携を提供している
- SuperTokensは拡張性を中核の価値提案とし、コミュニティメンバーが珍しい認証プロバイダとの連携を作れるため、全員に利益がある
オープンソースが勝つ第三の方法: より良い製品
- 透明性と拡張性は、商用オープンソースが長期的により良い製品になることに貢献する
- オープンソースプロジェクトは、コミュニティのフィードバックと支援を活用し、クローズドなソリューションより速く進化できる
- PostHogはAmplitudeとFullStoryの代替として始まったが、その後はLaunchDarklyやPendoとも競合する大規模で包括的なソリューションへ成長した
- PostHogは1,500万ドル規模のSeries B投資を調達した
- この成長はここ数年で起こったもので、PostHogはコミュニティをその中核的理由の一つと見ている
- オープンソースプロジェクトは商用オープンソースに限られず、数十年にわたり製品改善の重要な原動力となってきた
- 一部のソフトウェアは、先行者利益の性質上、クローズドのままであり続ける可能性がある
- しかし、透明性と拡張性が問題になる領域では、オープンソースの後発組が現実的な脅威になりうる
3件のコメント
検索していて偶然見つけたのですが、こういう英語の直訳調の翻訳（「安さによって」）をAIがいつ直してくれるようになるのか、気になりますね。
本日（2026-01-12）のClaude 4.5 Sonnetでの実行結果です
「オープンソースは、より安いという理由で勝つわけではない」
プロンプト
オープンソースは、単に価格が安いという理由で勝つわけではない。
オープンソースの成功要因は、低コストではなく別のところにある。
オープンソースが優位に立つのは、低価格だからではない。
Hacker News の意見
ここでいう 利益（profit） という言葉は奇妙で曖昧
24年近くオープンソース／自由ソフトウェアのプロジェクトを運営してきて、そのうち17年ほどは売上もあったが、「利益」はなく、売上（revenue） だけがあった
一般に会社や会計士が見るように、利益とはプロジェクトに関わった人たちの報酬や費用を差し引いた後に残るお金だと考えている
この意味での利益が必要なオープンソースプロジェクトは、投資家が「リターン」を期待する資本投資を受けた場合だけで、そうしたプロジェクトもあるが大多数ではない
また、HN に載る記事らしく、全体的に Web／SaaS 寄りに偏りすぎている。信じがたいかもしれないが、オープンソースプロジェクトにはほかの種類もある
その文脈では、売上を得て費用を支払った後に残るものが利益であり、その費用には固定給、雇用契約、給与明細といったものが含まれる
事業が利益をどう使うかはさまざま。現金準備として積み上げて売上が低い月にも費用を支払えるようにしたり、新しいハードウェアのような資産を購入したり、追加採用を可能にしたりできる。思ったほど一般的ではないが、オーナーに配当として支払うこともできる
あなたの状況は詳細が少ないので推測するしかないが、1人で運営していてプロジェクトが小さく、従業員を増やす必要も意思もないなら、売上は実質的に個人所得に近い。多く受け取る月もあれば少ない月もある構造なので、この文脈では「利益」ではなく売上と見るのが正しい
特に、ほかの間接費がほとんどなく、税務目的で費用を追跡する意味もあまりないソフトウェアならなおさらで、帳簿自体をきちんと付けていない可能性もある。そういう状況なら、この記事に共感できない理由は理解できる。この記事はかなり別の状況を扱っている
純粋な投資家が継続的なリターンを求めなければ圧力は大きく減り、プロジェクトに合ったことをしやすくなる
だが野心的な企業と競争する製品領域では、成長も必要であり、合理的である可能性が高い
不況、機会、大きな支出に備えて利益を残すことは、単に合理的という程度ではない。関わる人や顧客が増えるほど、入ってくる売上をすべて燃やし尽くすべきではない理由は大きくなる
実際、大企業ではこの2つが互いに無関係な数字であることが多く、それぞれ誰に伝えるのか、またその伝達に適用されるルールによって定義される
「経営上の利益」のようなものもあり得るが、これは標準化も規制もされていない指標を総称する言葉だ。たとえば、ある事業が税務や投資家向け報告の目的では現金主義会計から離れていたとしても、既存の経営陣にとっては以前の方式による利益定義を追跡し続けることが有用な場合がある。習慣のためかもしれないし、キャッシュフローをよく示す、あるいは別の形で有用だからかもしれない
こういうのはポストモダンな問題の1つだ。SEC、IRS、銀行の担当者は「SEC上の利益」のような表現を受け入れず、「本当の」利益を求める。病院が施工会社に「本当は」いくらかかったのかを素朴に問い詰める地方政治家のようなものだ
いずれにせよ、筆者も SEC や IRS と同じように、自分の観点からの用語を使っている。「オープンソースは安いから勝つのではない」と言うときの「オープンソース」は、MongoDB のようなモデルのオープンソース事業を指している。だから投資家や成長目標といったものが前提になっている
記事内でもこの点は自ら明確にしているので、意味論的に唸り合う必要はあまりない
このビジネスモデルの問題は、OSS版と有料版のあいだに緊張関係を生むことにある
OSS版には優れていてほしいが、誰もSaaSやコンサルティングなどにお金を払う必要を感じないほど良くてはいけない
その緊張関係は結局、明らかに必要な機能が抜け落ちたり、規模をもって運用するために必要な機能・知識がスポンサー企業の収益化のためにクローズドソースとして隠されたりする方向につながるように見える
製品がインフラ寄りなら、ElasticやHashicorpのように、大手クラウド事業者にワンクリックサービスとして食われないよう、見ることはできるが手は出せないライセンスに変えるパターンもすでに定着している
記事が間違っているという意味ではないが、商業的に支援されたOSSが全員にとって良いkumbaya的なウィンウィンであるかのように装うのはやめてほしい。実際には、スタートアップが信頼を育てるためのグロースハックとして使い、売上を立てるべき時点が来ると、成長を助けてくれたコミュニティを何らかの形で締め付ける構造に近い
小さなモジュールを保守しながら、何年にもわたって多くの機能要望やサポート依頼を受けてきた。家賃を払えるほど稼げるようになるまでは、そうしたことにお金を取ることに少しも罪悪感はない
それどころか、Pull Requestのマージボタンを押すだけでも、私の時間が1秒でもかかるなら費用を請求する。コードには何か月も、何年も費やしており、そのコードを世の中に無料で公開した
追加機能や私の時間が必要なら、お金を払うべきだ
多くの会社がそれをできないからといって、このビジネスモデルが機能しないという意味ではなく、うまくやるのが非常に難しいという意味に近い
それでも、たいていの人は概ね善良だと考えるなら、こうした会社や人々が市場へのアプローチを誤った可能性も考える価値がある。悪意というより無能なのかもしれない
初日から、何が永遠に無料で、何がいずれ有料になるのかを透明に示しているなら、コミュニティを裏切ったとは見なさない
もちろん、ロードマップを守り、フィードバックや貢献に応じて調整することが前提になる
有料サポートや拡張機能は、いずれにせよソフトウェアが収益の大半を得る商業領域に残しておける
すべてのユースケースに合うわけではないだろうが、その必要もない。コンピューティングの大半は個人的なものであるべきだ
「MinIOは、ユーザーデータに誰がアクセスするかを気にする企業にとって良い代替案だ」という話があるが、ある会社がオープンソースソフトウェアでホスティングしていると主張しながら、実際には同じAPIエンドポイントを模倣する社内のクローズドソースソフトウェアを使うこともあり得るのではないか？
そうなると、AWSと同じ種類の信頼が依然として必要になる
セルフホスティングがセキュリティ意識の高さを意味すると仮定してはいけない。大半の企業でオンプレミスITはHVACや電気設備のように扱われているが、ただそれより面倒なだけだ
作業服を着た人なら誰でも、受付でサーバールームの鍵をだまし取れる
それは、提供者が自社サービスの裏で動いていると言うソースコードを共有している、という意味にすぎない
たとえそのコードが正確に一致していたとしても、「公式」サービスの裏で動いている唯一のコードである可能性は低い。そしてユーザーが自分でビルドして彼らのサーバーにデプロイすることもできない
オープンソースが本当に意味を持つのはセルフホスティングする場合だけで、そうでなければ実質的にはプロプライエタリソフトウェアと変わらない。すべては提供者への信頼、そして可能なら契約にかかっている
たとえば契約書に、データはこのオープンソースコードに入り、そこから出て他の場所へは行かないと書かれており、それを保証するための手順が列挙されていたとして、その全体が露骨な嘘なら、明確かつ執行可能な形で大きな問題になる
内部の従業員に隠すのも難しいし、人は入れ替わる。事実でなければ、そのような主張をする可能性は低い
筆者は、有料製品と競合するオープンソースソリューションを具体的に指していると明らかにしている
個人的には、この文脈でオープンソースが「勝つ」のかどうかは、まだ結論が出ていないと思う
この10年でオープンソース製品は大きく増え、ここ5年ほどは、その多くがオープンソースから離れていく姿も見てきた。MongoDB、Hashicorp スタック、Elastic、Red Hat、MinIO などがその例だ
真にオープンソースでありながら商業的にも競争力のある製品はあまり残っておらず、その多くは、これが実行可能なビジネスモデルであることを証明しようと奮闘している
数週間前に社内イベントでこのテーマについて発表し、数週間後には GoWest でも再び発表する予定だ
核心となる前提は、オープンソースライセンスは文字どおり自由を与えるが、企業がお金を払うに値する他のものは提供しないという点だ。プロプライエタリライセンスは企業が必要とするものを提供するが、自由を犠牲にする
自由や信頼性を妥協せず、その中間で機能する第3のモデルがあると信じている。オープンソースであり続けながら、企業が必要とするギャップをスポンサーシップで埋めれば、一部のプロジェクトでは可能かもしれない
今、Caddy のウェブサイトをこのメッセージに合わせて再設計しており、うまく機能することを願っている
MinIO について言っている「オープンソースから離れた」というのは、それを意味しているのか？
タイトルが間抜けだ。もちろんオープンソースは、より安いから勝つ
筆者が言おうとしているのは、オープンソースビジネスは安さで勝つわけではない、ということだ
オープンソースのコードベースは常に、より安いから勝つ。圧縮アルゴリズム、ネットワーク時刻デーモン、メディアトランスコーダにお金を払う人はいない。オープンソースがそうした市場を完全に消し去ったのだ
ただ、タイトルが文字どおり単語1つのせいで間違っているのがいら立つ
何か見落としたのかと思って、前の段落を読み返した
技術導入に影響を与えるエンジニアの立場では、オープンソースは理解可能であることで勝つ
同僚や自分がソースコードを見られれば、その製品が主張している機能を実現できるか判断できる
利用中にバグや想定外のユースケースに遭遇したら、少なくとも解決策を調べてバグ報告で提案できるし、あるいは PR を開くこともできる
そうすると素早い回避策を作れるし、たいていはバグ報告もできる
企業はコードそのものをそれほど気にしない。気にするとしても、事業継続条項がクローズドソースへの懸念の大半を減らせる
結局、Excel の代わりに OpenOffice Calc へ乗り換えた金融会社がどれだけあるだろうか？
AWS の市場参入戦略は、スタートアップや個人開発者に低コストの従量課金サービスを提供して引き込むことに依存しており、この部分は非常にうまくはまった。Airbnb、Stripe、Twitch などが大企業へ成長し、AWS とともに大きくなったからだ
低コストや無料と競争できるものは多くない。あとで上位市場へ移ればいい。ARM と Intel に聞けばよい
開発ツールの新興企業にとって、オープンソースは事実上、標準的な市場参入戦略になった。この記事が正しく指摘しているように、ビジネスモデルではないが
だから Snowflake 級に優れていて、Databricks のような自由・オープンソース陣営とも渡り合えるのでなければ、オープンコアモデルのほうがよい
自分たちでコンパイルできるなら、はるかに好まれる
物理サーバーに Postgres を自前で立てているなら、投資家は気にしないか、どれだけ多くの時間を無駄にしたのか厳しい質問をしてくるだろう。そのときは、かなり良い答えか、共感してくれる投資家が必要だ
ベンダーロックインに触れていないのが驚きだ。オープンソースの明確なセールスポイントである
もちろん組織や人によって違うし、信頼している会社ならロックインを気にしない人も多いが、決してゼロではない
Red Hat で OpenShift コンサルタントとして働いていたとき、ベンダーロックインを心配する役員にたくさん会った。彼らにとって OpenShift を選ぶのは当然の決定だった
ソフトウェア販売という領域に限れば少し関係する話だが、昔、設計がひどいゲームのユーザーインターフェース更新を売ったことがある
価格をゲーム本体の2倍に設定したのに、人々は買った。プロが設計したものだったからだ
プロのデザイナーである自分が本業の時間を割いて、その開発者にはおそらくできなかったことをやったのだ
当時販売していたデジタル流通プラットフォームのコメントで最も目立った不満は、更新が高すぎるというものだったし、人々は当然、価格設定について論評していた
だが、1つだけ明らかなことがあった。ゲーム本体が安すぎたのだ
人々が価格にだけ不満を言いながらも買い続けるなら、それ以外には不満を言うことがないという意味だ
鳥たちはいつでも無料の餌を欲しがる。鳥たちに合わせるべきではない
付け加えると、その更新は違法配布もされ、海賊版ユーザーの間でかなり広まった。顧客の大半はお金を払ってくれたので、むしろうれしかった
また、ほかでは提供されていなかった欲しい機能のまとまりを、自分が満たしていることも明らかだった。そうした問題は、人々が欲しがるものを作ったという症状としては、かなり良い問題だ
多くのオープンソースプロジェクトは、選択ではなく必要に迫られてオープンソースになるのだと思う
ある種の製品は、オープンソースとして作らなければ採用される可能性が少しでも生まれない
筆者は少数のエリート的なオープンソースプロジェクトに注目しており、それらは大多数のオープンソースプロジェクトを代表していない
一部の企業は適切なビジネス上・政府関係のコネクションを持っているため、製品ライセンスを簡単に高値で売れるが、そうしたところは少数派だ
ほとんどの人や小企業には、そのようなネットワークがない。適切なビジネスネットワークがなければ、少しでもお金を稼ぐのは難しい
製品がどれほど優れているか、誰かのコストをどれほど削減できるかは関係ない。誰も信じず、試してもみない。長期的な利益が非常に大きくなり得るとしても、採用の障壁が高すぎる
製品をオープンソースにすることは、足がかりを作るための唯一の方法だ。製品が人目に留まるごくわずかな可能性を与えてくれるからで、ときにはそれがすべてなのだ