- Supabaseは創業初期からオープンソースを選び、公開でプロダクトを作ることで、コミュニティ・採用・プロダクト拡張において予想以上に大きな利点を得た
- 代表的な懸念は、コード品質への批判、セキュリティ脆弱性の露出、競合による模倣だが、公開性は改善への参加や高速な反復にもつながりうる
- 採用では、リポジトリへの貢献が候補者の実際のコードと協業の進め方を示してくれ、Supabaseは32人の開発者を採用した後になって初めてアウトバウンド採用を始めた
- ニッチなユーザー向け機能、統合、アダプターはコミュニティが直接作れるため、プロダクトの範囲が広がり、社内チームの優先順位の限界を補える
- オープンソース企業の防御力は、コードを隠すことよりも、実行速度、ブランド、チーム、コミュニティを長期にわたって積み上げることから生まれる
Supabaseが最初からオープンソースを選んだ理由
- Supabaseは初日からオープンソースであり、創業者たちはPostgreSQL、Python、Bitcoin、Reactのような公開プロジェクトの長年の利用者であり支持者でもあったため、当時それは難しい決断とは感じなかった
- 公開の場でビジネスを作るのは負担が大きいだろうという予想に反して、プロダクトと会社を育てる過程で、予想外の利点がいくつも現れた
- これは開発者ツールまたはPaaS企業としての経験だが、多くの内容はソフトウェア企業全般にも当てはまる
- オープンソース化を妨げる繰り返しの懸念は大きく3つある
- 散らかった、あるいは未完成のコードを人に批判されるかもしれない
- ハッカーがセキュリティホールを見つけて悪用するかもしれない
- 競合が知的財産を盗むかもしれない
「自分のコードはひどい」という不安
- ひどいコードへの不安の多くは、実際には自尊心の問題に近く、誰かが時間をかけて見てくれるなら、その中に追求する価値のある何かを見つけた可能性が高い
- Stone Soupの話のように、良いアイデアをコミュニティと共有すれば、他の人たちがそれを受け取り、一緒に改善できる
- コミュニティは悪いコードをリファクタリングしたり置き換えたりでき、新しいコード品質ガイドラインを導入して、その後の貢献プロセスもより良くできる
- コードに文句だけを言って改善提案をしない有害なメンバーは、そもそも望ましいコミュニティメンバーではない
- オープンソースの貢献者は古いプロジェクトの「墓場」を持っており、それは似たものを作ろうとする人たちにとってアイデアとアプローチのライブラリになる
- ある人は特定の問題解決のやり方から着想を得られるかもしれない
- 少なくとも同じ失敗を繰り返す時間は減らせる
- 古いプロジェクトが評判を損なう可能性よりも、有用に使われるか、そもそも注目されない可能性のほうが大きい
公開コードとセキュリティ
- 公開コードでホスティングソリューションを運営する際の最大の恐れは、悪意ある行為者がコードを読んで脆弱性を見つけ、サービスをハックすることだ
- Supabaseの経験では、Linus's lawの「十分な目があれば、すべてのバグは浅い」という言葉は、セキュリティ問題にも当てはまる
- 初期から、匿名であることも多いセキュリティ研究者たちがコードとプラットフォームを調べ、潜在的な問題を見つける助けになってくれた
- SaaSを提供するなら、
/.well-known/security.txtに簡単な案内を置き、善意の研究者が潜在的な問題をどう開示すべきか分かるようにすべきだ
- 公開プロジェクトが独占的なコードベースより安全になりうる例として、Bitcoinが挙げられる
- Andreas M. Antonopoulosは2015年の講演で、クローズドな銀行システムはソフトウェア的に弱い免疫システムを持つと述べている
- クローズドなシステムでは、大きなセキュリティホールが長期間隠されたままとなり、最終的に悪用されたときに大きな被害につながりうる
- Bitcoinのようなオープンソースプロトコルでは、セキュリティホールは誰の目にも見え、エクスプロイトは早い段階で繰り返し発見され、その後パッチが当てられる
- 成功するソフトウェア企業は10年以上かけて作られることもあるため、長期的にはオープンソースのシステムのほうが、秘密主義の独占システムよりも安全な状態に近づく可能性がある
- 優れたセキュリティエンジニアの採用競争が非常に激しい時代には、公開レビューの価値はさらに大きい
競合と知的財産への懸念
- ソフトウェアにおいてアイデアは安く、価値はほとんど常にアイデアの実行から生まれる
- アイデアを世の中と共有すれば、誰がコードベースにアクセスするかを心配するよりも、より速く反復することに集中できる
-
専門家コミュニティを作る
- 成功する会社を作るには、たとえば10年という長い期間にわたって着実に実行し、顧客基盤を育てる必要がある
- この長距離レースにおいて、競合がコードベースを見て得る利点は、10年全体で見れば大きくない可能性が高い
- その間にコードベースは何度も反復され、リファクタリングされる可能性が高い
- 長期的には、自分たちのソリューションを世界で最もうまく反復改善できるチームとコミュニティを作ることが勝ち筋になる
-
市場で勝つ
- 大きく成長する総アドレス可能市場（TAM）が本当に追う価値のあるものなら、勝者総取りになる可能性は低い
- まず感動させられるユーザーセグメントを見つけ、素早く反復すべきだ
- 競合に気を取られる時間は、プロダクトやチームの改善に使える時間でもある
- 競合がオープンソースプロジェクトをフォークして、より速くリリースできるのだとしたら、その競争はいずれにせよ負ける運命だったとも言える
- ソフトウェアではIPや特許は執行が難しいことで知られているため、弁護士でソフトウェアのアイデアを守ろうとする心配を減らせば、時間・お金・精神的エネルギーを節約できる
- ビジネスは、ソフトウェアのアイデアを世界で最もうまく実装することで、よりよく守られうる
-
後期段階のクラウド競争
- プロジェクトがかなりの規模に達すると、ElasticやMongoのように、大手クラウド事業者がより強力な配布モデルでプロダクトを提供してくる状況に直面することがある
- 立ち上げたばかりの会社にとって最大の問題は、まずその地点まで到達することだ
- AWSが数十億ドル規模の製品群の1つからリソースを割いて、ホスティング製品で競争してくるほどなら、すでに非常にうまくいっている状態だ
- より建設的な対応は、誰と競っても優位に立てる領域を前もって見つけておくことだ
- 多くのクラウド事業者は**開発者体験（DX）**が良くないことが多いため、DXを中核能力にできる
- 6年後にGoogleが市場を奪いに来るとしたら、それまでの数年間でブランド・チーム・コミュニティがDavid対Goliathのような戦いに備えていなければならない
- こうした状況に不意打ちされないよう、最初から計画しておくべきであり、時間と集中力を使って勝つための戦略を作れる
- 競合がアイデアを探しに来るなら、常に一歩遅れており、特に初期のようにリソースが乏しい時期ほど、競争への不安により多くのエネルギーを使ってしまう
開発者採用での効果
- スタートアップが規模に関係なく抱える大きな問題の1つは、開発者採用の難しさだ
- ソーシングが難しい
- 開発者の評価が難しい
- 将来の同僚のレベルを納得してもらうのが難しい
- オープンソースは開発者採用の問題を軽減する助けになりうる
-
公開されたソーシング
- すべての開発者はオープンソースの恩恵を受けており、多くの開発者は興味深いオープンソースプロジェクトに貢献することで、その恩恵を返したいと考えている
- 貢献の理由は、良いコミュニティ、新しい技術の学習、見慣れないコードベースで難しい技術課題を解く楽しさなどかもしれない
- オープンソースプロジェクトへのコード貢献のハードルを下げれば、優れた開発者がそのプロジェクトを見つける可能性がある
- 貢献者はイシューの議論、バグ修正、問題の特定、PRレビューに参加できる
- すべての貢献者が求職中というわけではないが、多くの人はオープンソースコードをフルタイムで扱える見通しに惹かれるかもしれない
- Supabaseは2年以上運営し、32人の開発者を採用してから初めてアウトバウンド採用を始めた
- オープンソースはSupabaseの主要な人材発掘チャネルであり、今後もそうであり続ける予定だ
- リモート・非同期の会社では、オープンソース採用戦略によって候補者が自分の能力を自ら示せるため、その能力を検証しやすくなる
-
LeetCodeや課題テストの代わりになる実際の貢献
- 開発者が次の職場を探す際に最も不満を抱く要素の1つは、面接過程でLeetCodeの問題を解いたり、課題型テストを受けたりしなければならないことだ
- こうした方法は時間がかかって大変なうえ、実際の仕事で行う内容を代表していないことが多い
- 誰かがリポジトリに貢献すれば、すでに次の材料が得られる
- リモート・非同期環境で、チームやコミュニティメンバーとどうコミュニケーションするかの事例
- 実際のコード貢献の事例
- 候補者も会社側を見ることができる
- チームがコード品質を重視しているか確認できる
- 効果的にコミュニケーションしているか見られる
- 良い技術的判断をしているか見極められる
- Supabaseのリポジトリ経由で採用された人たちは、自ら不可欠な存在となり、既存リポジトリの開発を主導したり、新しいクライアントライブラリやSDKを立ち上げたりしたケースもある
- 彼らはZoomでLeetCodeの問題を解く必要がなかった
ニッチなユーザー向け機能と統合の拡張
- スタートアップを作るときは、最も大きな問題だけを解く時間しかないことが多い
- 速く動くには、ユーザーベースの**80%**が求めるものに集中すべきだ {p:80}
- 少数のユーザーが求める機能は、無期限に後回しにされがちだ
- システムがオープンソースであれば、こうしたユーザーが自ら機能を提供でき、ソフトウェアの有用性が高まる
- この効果は統合とアダプターでよく現れる
- ユーザーがAzureまたはVercelとの統合を望むことがある
- 別の誰かがその接続を作るための開発リソースを提供すれば、プロジェクトの全ユーザーが恩恵を受ける
同じ車輪を何度も作らない
- オープンソースのない世界では、技術企業は何度も車輪の再発明を繰り返すことになる
- Supabaseは新しいプロジェクトをオープンソースとして公開するだけでなく、新しく作る前に既存のオープンソースプロジェクトを支援しようとしている
- 自動車会社が独自の関数、独自のUI要素、独自のウィンドウライブラリ、独自のOS、独自のドライバーを使い、ほとんど見ることのないエラーメッセージを表示するような状況は、開発者の時間と労力の無駄だ
- Supabase Launch Weekは、チームとコミュニティが過去3か月にわたって取り組んできた成果の集合であり、オープンソース企業を運営する利点は、コミュニティの進む速度に表れる
- 詳しくはLaunch Week 4 postを参照でき、参加したいならSupabase GitHubを訪れられる
1件のコメント
Hacker News の意見
ここには持続可能な収益性に関する大きな前提が隠れていて、特に米国の開発者給与のような現実を考えると、実感とずれる部分がある。
要するに、オープンソース企業は雷に二度打たれなければならない。一度はオープンソースプロジェクトに、もう一度は会社に当たる必要がある。
Graphistry チームは日々オープンソースを愛し、扱っており、Apache Arrow と Nvidia RAPIDS につながるプロジェクトの立ち上げを支援し、Python/JS クライアントもオープンソースとして公開した。PyGraphistry[AI] はグラフ向けのスイスアーミーナイフのようなツールで、GFQL のように Cypher グラフクエリ言語を埋め込み可能で、データフレームネイティブかつ GPU アクセラレーション対応の形で実装したツールも含まれている。
しかし持続可能な成長は、主に企業、政府、データ企業にGPU グラフ可視化サーバーのクラウド/オンプレミスのセルフホスティングライセンスを販売することで生まれている。数年間持ちこたえた末、幸いこの事業は順調に成長しており、SaaS ホスティング収益だけでも小さなチームは維持できるが、チームの大半は賄えない。セルフホスティングライセンスの収益がなければ、イノベーションサイクルの大部分は消えてしまうだろう。
この記事は、宝くじに当たるような運、SaaS 市場の特性、技術的防御力の交差点を見落としているように感じる。Louie.AI と GFQL のリリースが私たちの場合にはオープンソースの事業可能性を変えつつあるので、不可能だという意味ではないが、ここまで来た経験からすると、この記事を読む新規創業者たちが心配になる。
[1] https://graphviz.org/
つまり「これからソースを公開します」と言ったら「いいですね、では契約を解約します」と言う顧客なのかが肝心だ。
「オープンソースのビジネスモデルを他の創業者と話すと、繰り返し出てくる懸念が三つある。汚い、悪い、未完成のコードを批判される可能性、ハッカーがセキュリティホールを見つけて悪用する可能性、競合が知的財産を盗む可能性」とあるが、四つ目が抜けていると思う。
Amazon/AWS が私のコードを基にサービスを商用化して販売し、何も支払わない可能性だ。
ユーザーとフィードバックをやり取りするときは礼儀を守るが、内心では「言うのは簡単だ。私は実際に作った。黙るか PR を送って」と思っている。驚くことではないが、そういう人たちはほとんど絶対に PR を送ってこない。
実際に作ることを続け、非難する人たちは受け流せばいい。
[0] - https://heywillow.io/
大企業が真似しようとしているなら、すでに勝っているということであり、それを緩和するための事前計画は必要だ。ただし記事を正しく解釈したなら、初期段階で集中したり心配したりすべき問題ではない、という意味に見える。
クラウド企業が他のオープンソース製品を取り込んでしまうのは、その製品が自分たちの成果物をきちんと保護するライセンスを選べていなかったからだ。
本当に深みのある良い記事だが、多くのプロジェクトが見落としていることが一つある。政府・公共部門に売ればよい。
米国政府には NSF 助成金のような技術プログラムが多く、民間機関・情報機関・州政府が互いに分断されているため、結果として非常に広大なソフトウェア調達の地形が生まれている。規制やコンプライアンスの参入障壁も思うほど高くなく、特に最初の数件を協力会社と一緒に獲得すればなおさらだ。通常は3〜5年契約でプロジェクトに資金を付けられる安定した保証付きの売上であり、収益性も非常に高い。
もっと多くのオープンソース企業にこれを活用してほしい。完全な民間企業がオープンソースライブラリを自社製品に組み込み、巨大なマージンを乗せて販売し、すべて持っていくことが多いからだ。
例: https://x.com/ssankar/status/1749202248700420587?s=20
政府にいたとき、実質的にはオープンソース地図 + オープンソース DB の組み合わせなのに1,200万ドルするソフトウェアをたくさん見た。別の基準では、PDF OCR に年間200万ドル、weights & biases のようなツールに年間3,000万ドルが付くのも見た。
ソフトウェア配布以外にもインセンティブがある。たとえば特定のバグやセキュリティ欠陥を優先的に修正することだ。情報機関は safetensors に大金を払った可能性が高い。
Supabase が取り得る四つの経路は、Cybercom への直接販売、DOS への直接またはチーム契約、VA に対する PWS 経由の販売、大手政府契約ソフトウェア企業への直接販売だ。
実行方法は、GS 14/15 または同等の相手にコールドメールを送る、元 GS15 を雇う、SAM.gov で適した入札を探したうえで GovPro.ai はフルサービスで、rogue は自前対応で提案書を作る、というものだ。
政府官僚組織が契約を最終承認する頃には、ほとんどのスタートアップはすでに資金が尽きている可能性が高い。
契約は収益性が高いこともあるが、官僚的手続きが非常に多く、それを扱った経験のある人が必要になる。万人向けの道ではなく、時間も交渉もかなりかかる。
巨大な官僚制はさておき、連邦政府は最大で、最も遅く、扱いにくい政府組織だ。米国内だけでも、学校、都市、郡、州、水道・消防地区、図書館など、何万もの別の政府主体がある。
公共部門に入りたいなら、最大のところに全振りするのではなく、小さく広くアプローチするほうがよい。
世界で最も収益性の高い政府部門は米国防総省だ。
しかし国防総省は信じられないほど官僚的で、スケジュールに敏感で、秘密主義にこだわる。
Supabaseのビジネスモデルは、自らをオープンソース企業としてマーケティングすることだが、実際には正気なら誰も本番用途で自前ホスティングしようとはしないだろう、というもの
微妙に欠けたドキュメント、微妙なバグ、微妙に欠けた重要機能のようなものがあるからだ。だからオープンソースという称賛は得るが、実際には実用的ではなく、単なるマーケティング手段だと思う
1つ目は心の余裕だ。今すぐ自前ホスティングしないとしても、サービスが気に入らなくなったときに抜け出す道が1つ増える。もちろん、生データへのアクセスも提供する必要がある
2つ目はコード品質だ。一見うまく動いているが本当にひどいコードを扱ったことがあるなら、公開しても恥ずかしくないコードを持つことがどれほど重要か分かるはずだ
3つ目はコントリビュートできる可能性だ。以前は大したことではないと思っていたが、実際に何度も経験してみると、機能の欠落、バグ、性能問題などがあるときに要望を出したり、自分で貢献したりできることは大きい。ほとんどのクローズドソースプロジェクトでは、機能要望を透明に出せるチャネルがあるだけでも運がいい方だ
ある閾値を超えれば、人々がフォークに労力を注ぐと決める可能性がある。MariaDBがその例だ
まさにその点があるから当社のマネージドサービスを安心して使える、と直接言ってくれた人たちもいた
合法的で本物のオープンソース企業になる方がはるかに簡単に見える
そういう意味ではなく、私の読み違いなら、残りの内容はむしろSupabaseを非常に好意的に見せている
商業的には可能ではないかもしれないが、現在の状態はオープンソースソフトウェアに期待できる基準を大きく損なっており、そうした方式を選んだ企業にも明確な長期的メリットは見えない
開発者が自分で実行しないとしても、実際に動いているコードを見られるようにしてくれる
Supabaseも好きだし、商用オープンソース全般も好きで、記事の多くの部分に同意する
だが「ソフトウェアではアイデアは安い。価値はほとんど常にアイデアの実行から生まれる」という部分は、ぎこちなく感じる
この表現は「すごいスタートアップのアイデアがあるんだけど、話す前にNDAに署名してくれる？」のような状況で聞いたことがある
しかしソフトウェアをオープンソースとして公開するなら、単にアイデアを提供しているのではなく、そのアイデアの相当な実行成果も提供していることになる
もちろんコードが実行のすべてではなく、営業・マーケティング・サポートなどに広がる。それでもこの記事はコードの価値を軽く見すぎていて、営業・マーケティングなどがなければ無価値だと示唆しているが、それは事実ではないと思う
価値を分けるなら、営業/マーケティング/顧客検証が90%、コードが10%程度だと思う。7桁台前半の売上があるブートストラップSaaSを運営しているが、コードは概してぐちゃぐちゃで、常に進化し続けるものだと言える
家は無料でコピーできないが、ソフトウェアはできる
開発者が報酬を受け取る対象は、コードを作る過程と、目に見えない細かな問題を解決する作業だ
だからソフトウェア販売はあれほど収益性が高い。ソフトウェアを売らなければ、それでお金を稼ぐことはできない。ソフトウェアは私たちが共有する現実の物理的な物とは違う
私にとって核心的な問いは、コードが十分に良いか、競合が真似するかではなく、持続可能な事業を作れるだけのお金を稼げるかだ
引用され、愛されているオープンソースプロジェクトは良い事業ではない: PostgreSQL、Python、Bitcoin、React
MongoとElasticは素晴らしいが例外だ。成功したクローズドソースのデータベース企業の方が、オープンソースのデータベース企業より多い
オープンソース企業は難しい。だがユーザーにとっては非常に価値がある
どのライセンスが「オープンソース」かという議論を脇に置くと、重要なのは、これらの企業が、広く使われている(A)GPL、Apache、MITのようなライセンスは、競合にマネージド/ホスティングサービスを作って規模で競争する余地を大きく残す、と判断した点だ。例えばAmazonのOpenSearchがElasticSearchをより安く提供したケースだ
[1] https://blog.opensource.org/the-sspl-is-not-an-open-source-l...
この質問は「当社はソフトウェアのソースを公開すべきか？」という意味で使われているように思う
しかし私にとっては、元の質問に答えることが、言い換えられた質問に答える道を与えてくれる。元の質問は、会社が売るソフトウェアではなく、使うソフトウェアの性質に関するものだ
個人的には、代替があるなら常にオープンソース製品を選ぶ。サポート費用を喜んで払ったり、プロジェクトに寄付したりするとしてもそうだ。ソースを自由に見られるアクセス権は、自分が絶対に修正するつもりのないソフトウェアでも根本的に重要だ
多くの人には極端な立場に見えることは分かっている。だが、電子レンジ、ドアノブ、トランスミッションを分解できないという考えが嫌いだ。元通りに組み立てられないかもしれないが、欠けたギアを見つけて90ドルの交換ではなく2ドルの修理で済ませられるかもしれない。あるいはトランスミッション付きのフランケンシュタイン電子レンジを作れるかもしれない
Webサーバーの機能を拡張したり、自分のプラグインがなぜホストアプリをクラッシュさせるのか理解したりすることは、私にとって重要だ。社会にとっても重要だと思う。だから私は自分のオープンソース原理主義にしがみついている。内蔵AIで5KB以内にHTTPS/4を処理する最新の超小型Webサーバーを見せられれば興味は湧くだろうが、オープンソースでなければ既存のスタックを使い続ける
こうした心構えのため、私が作るソフトウェアはオープンソースであり、ときには人々がその対価を払ってくれる
「6年後に Google がランチを奪いに来ようとするなら、この数年間ダビデ対ゴリアテの戦いに備えてきたブランド、チーム、コミュニティが必要だ」という部分について、自分の経験では、調達担当者にとってブランド・コミュニティ・チーム・開発者体験のようなものは、コンプライアンスに比べるとほとんど意味がない
Google のような既存ベンダーと正面からぶつかるなら、なおさらそうだ
Supabase の場合、実際にこの数年、こうした要件に対応するために SOC2、HIPAA、GDPR などのコンプライアンスを準備してきたので、的確な指摘だ
私たちの製品でもこの問題を考えてきた。いずれはすべてを MIT か Apache のうち、その時点で気に入っているライセンスでオープンソース化する予定で、その点はサイトにも公開している。AGPL やオープンコアのような方式ではない
しかし、そのような構造で製品から収益を上げるのはまったく不可能だと感じたし、以前の経験でもそうだった。コンサルティングなら可能だろうが、製品は違う。Supabase は巨額のベンチャー投資を受けており、ほぼすべての「大きな」オープンソースプロジェクトも同じだ
ブートストラップなら、特に野心的で難しいプロジェクトでは、しばらく請求書を出せない。人が無償で働ける期間には限りがあり、非公開コードで小さなチームが密にコミュニケーションを取り続ければ、成功したオープンソースプロジェクトに必要なオーバーヘッドを減らし、はるかに速く動ける
同じくらいの規模で、投資額 0 ドル、直近 5 年以内に始まり、フルタイムのチームメンバーが 2 人以上いて、3 年以上続いており、今でもこのアプローチを勧めているプロジェクトの例を聞いてみたい。どうやって生計を立てているのか気になる。Redis のようなことは、もう起きないと思う。少なくとも見たことはない。langchain のような単純なプロジェクトでさえ数千万ドルのベンチャー投資を受けているのだから、そういうプロジェクトこそ、数人のチームが複数の収益源で稼ぎながら取り組める候補だと思っていたくらいだ
私のソフトウェアはすべてパブリックドメイン、つまり自由ソフトウェアとして公開しているが、その中で成功したオープンソースプロジェクトやコミュニティになったものはない。自由ソフトウェアは何よりもまず理念であり、その次に実践や機能が来る
会社をオープンソース化するのは、開発者を対象にしているか、現実的に誰も自分でホスティングしないような製品を作っている場合でなければ筋が通らないと思う
Supabase はその両方の代表例だ。後者の例としては Plausible Analytics があり、自分でホスティングすることはできる。私も Coolify.io でそうしている。ただし、リリースから更新を取り込んでマージする独自の CI/CD システムを作らないと、アップデートを取り逃すことになる