クローズドソースのソフトウェアに対する信頼が低下する中、オープンソース化が企業にとってもたらすビジネス上の優位性について解説している。競合によるクローンやセルフホスト、セキュリティといったリスクを認めつつも、AI時代においてはオープンソースのエコシステムが不可欠であると主張する。具体的には、ユーザー自身がフォークしてカスタマイズできる「ビルディングブロック」としてのソフトウェアの重要性を挙げ、T3 CodeやVercelなどの成功例を交えながら、将来のソフトウェア開発のあり方とオープンソースの可能性について深く掘り下げている。
クローズドソースへの不信感とオープンソースの可能性
最近、クローズドソースのソフトウェアに対する信頼がどれほど失われつつあるかについての動画を公開しました。私が望む未来は、ますますオープンなものになっているように感じます。それは、開発会社の押し付けに縛られるのではなく、自分で変更を加え、自分に合ったバージョンのものを使える未来です。私は多くのクローズドソースのソフトウェアに対してたくさんの不満を抱えており、それは日に日に大きくなっています。そして、その原因は間違いなくAIにあります。今や企業は好きなものをとにかく出荷できるようになり、品質へのこだわりが薄れているため、私が使うツールの品質も低下しているのです。しかし、これはあくまで私個人の話です。ビジネスの側面から見るとどうでしょうか。時間が経つにつれて、ビジネスケースはますます怪しくなっています。コードがオープンソースであれば、AIエージェントがセキュリティの脆弱性を見つけて攻撃するのははるかに簡単になります。また、無名の個人がエージェントに指示を出してフォークし、自分でホストしてしまえば、あなたにお金が入ることは決してありません。さらに、他の企業があなたの仕事をクローンし、彼らのエージェントにあなたの製品を分析させて、自社のサービスに組み込むことも非常に簡単になります。
では、なぜわざわざビジネスをオープンソース化するのでしょうか。これは非常に素晴らしい質問であり、私は企業としてのオープンソースの優位性について、かなり強力に主張していきたいと思います。アプリをオープンソース化することが、開発しているもののリスクプロファイルを高めることには同意しますが、もしそうしなければ、破滅してしまうかもしれないと私は考え始めています。私は、一緒に仕事をしている企業のほとんど、特に投資先の企業に対して、できる限りオープンソースに全力で取り組むようアドバイスしてきました。そして、その理由を皆さんに早くお話ししたくてたまりません。これまで、私が今から語ろうとしている熱弁は、私が一緒に仕事をして投資している企業に優位性を与えるために、あえて内密にしていた情報でした。しかし、考えれば考えるほど、この情報を無料で公開すべきだと気づいたのです。私のポートフォリオにある企業がこの情報を知っていることの利点は大きいですが、将来的にさらに優れたオープンソース製品が増えることを願って、誰もがこれを知っている状態にしたいと考えるようになりました。ただ、私のコードと情報を無料で提供する以上、誰かに費用を負担してもらわなければなりません。
エージェント時代に向けたCIツール「RWX」
というわけで、今日のスポンサーの紹介のために少し休憩を挟みます。もし、CIを壊すようなコードをプッシュしたことがないという方は、この広告をスキップして構いません。さて、偽物の開発者たちが部屋から出て行ったところで、今日のスポンサーであるRWXについてお話ししたいと思います。これは、エージェント向けに実際に準備された新しいCIのやり方です。どういう意味かというと、彼らが提供するスキルから始めましょう。これが本当に素晴らしいのです。彼らはランループと呼ばれるものをセットアップさせてくれます。ランループを使えば、エージェントがCLIコマンドを実行し、高度なキャッシュ機能などをすべて有効にしたフルCIを回すことができます。これにより、エージェントはコミットする前に素早くフィードバックを得ることができるのです。変更をコミットしてプッシュし、CIが実行されるのを待ってからエラーをエージェントにコピペして戻す代わりに、すべてを修正するまでループで実行させ続けることができます。これを、構築しようとしている機能の失敗するテストを追加するコミットと組み合わせれば、エージェントが実際にその機能を修正することを基本的に保証できるようになります。考えれば考えるほど、彼らのCLIで提供されているようなシンプルな実行コマンドを使って、GitHub Actionsをローカルで実行できない現状がおかしく思えてきます。RWXに移行すれば、ローカルで実行できるようになるため、もう二度と元には戻りたくなくなるでしょう。GitHub CLIにアクションを実行する方法があったらと想像してみてください。なぜ彼らがそれを用意していないのか分かりませんが、RWXが提供してくれていることにとても感謝しています。それだけでも十分素晴らしいのですが、ダッシュボードとパフォーマンスがさらに魅力を高めてくれます。キャッシュされたために実行されたステップと実行されなかったステップを示す小さな図を見ることができます。また、作業を並行してキャッシュ可能なツリーに分割できるため、不要な作業を実行せずに済んだり、あるポイントに到達した後に複数の作業を並行して実行したりするのがはるかに簡単になります。タイムラインビューを見れば、なぜ時間がかかりすぎているのかが一目瞭然です。そして、一度それらのキャッシュされた実行にヒットするようになれば、結果は驚くほど速くなります。初期のセットアップと実行には2分かかりましたが、その後のチェックではわずか22秒しかかかりません。現在のCIはチームの足を引っ張っていますが、本来はエージェントの作業を加速させるものであるべきです。今すぐsoyv.link/rwxで修正してください。
オープンソース化のリスクと現実
さて、なぜ誰もが自分のビジネスをオープンソース化すべきなのでしょうか。まずは、これに反対する事例を挙げることから始めましょう。最初にも触れましたが、簡単にまとめると、競合によるクローンは非常に現実的なリスクです。もしあなたが製品にクールな機能を追加し、競合他社が彼らのエージェントにあなたのリポジトリを指定してこれを作り直せと指示できれば、あなたは終わりです。セルフホスティングも現実的なリスクです。顧客があなたのインフラではなく自社のインフラで実行してしまえば、最終的に顧客にはなりません。そして最も大きなリスクの一つは、特に最近のさまざまな神話が広まった後では、セキュリティのリスクです。エージェントはシステムの逆コンパイルや脆弱性の発見を比較的うまくこなしますが、オープンソースプロジェクトに対してははるかに優れています。例えば、Cal.comがこれに非常に苦労していることを私は知っています。なぜなら、Cal.comは完全にオープンソースであるため、膨大な数のセキュリティ報告や攻撃の試みを受けているからです。
ここで私が知っていることをすべて踏まえ、これらの問題がいかに大きいかを理解した上で、この点から目を背けたくはありません。これらはすべて、オープンソース化を検討しているなら考えるべき現実的な問題です。正直なところ、これが私たちがまだT3 Chatをオープンソース化していない理由でもあります。皆から最も多く寄せられているコメントだということは知っています。私自身、本当にT3 Chatをオープンソース化したいと思っています。私たちがそうしていない理由は、セキュリティリスクと、私たちが抱えているリソースの限界が組み合わさっているからです。私たちは2.5人のチームであり、私がその0.5人分を担当していますが、忙しすぎて0.5人分すら満足に働けていない状態です。JuliusはT3 Codeの改善に全力で取り組み、MarkはT3 Chatのサポートで完全に手一杯です。今T3 Chatをオープンソース化すれば、私たちは破滅してしまうでしょう。しかし、T3 Codeはユーザー自身のマシン上でユーザーのサブスクリプションを使用するため、ここでセキュリティが完璧でない小さな問題があったとしても、すべてのユーザーの生活やインフラを破壊することをそれほど心配する必要はありません。一方でT3 Chatの場合、数秒で何百万ドルも失う可能性があります。それが、私たちがオープンソース化していない理由です。それでも、メリットがいかに大きいかを知っているため、オープンソース化できたらいいのにと歯痒い思いをしています。
勝者となる巨大SaaSとその限界
では、そのメリットとは何でしょうか。私がオープンソースについて考えるとき、企業に言い続けていることは何でしょうか。ここでは、今誰が勝者なのかという興味深い角度から始めたいと思います。市場の見方や投資先の選び方について疑問に思っている方のために、私のビジネス分析をお話しします。普段、このチャンネルはコードやソフトウェアの構築方法についての発信がメインであり、市場のビジネス状況についてどう考えているかを発信する場ではないため、あまり話しすぎないようにしています。しかし時折、ビジネス関連について熱く語る機会があり、皆さんもそれを楽しんでくれているようです。ですので、オープンソースに行き着くまでの完全な資本主義的なルートを語るこの部分も楽しんでいただければ幸いです。私の話を聞いてください。また、私が今と言っているのは、必ずしも現在の特定の状況を指しているわけではなく、歴史的に誰が勝者であったかを指していることに注意してください。以下の企業が勝者であることには、皆さんも同意していただけると思います。AWSは明らかに勝者です。Salesforceも非常に明白で巨大な勝者です。Retoolについては少しお話ししますが、これも興味深い例です。ご存じない方のために説明すると、Retoolは現在AIツールとしてリブランディングしていますが、以前は社内のあらゆるデータソースを統合し、社内のレビューチームやカスタマーサポートが、会社が依存している何らかのデータベースを更新するためのカスタムダッシュボードやウィジェット、ソリューションを簡単に構築できるようにするツールでした。開発者ではない人や少し技術的な知識を持つ人が、世界中のあらゆるデータソースと統合するダッシュボードを簡単に作成できるようにする、一種の接着剤のようなツールでした。私は非常に明確な理由があってこれらの企業を選びましたが、少なくとも2022年の時点では、これらすべての企業が明らかに非常に大きな勝者であったことには皆さんも同意していただけると思います。
では、なぜ私はこれらの企業を選んだのでしょうか。例えばSalesforceを例に挙げてみましょう。仮にあなたが自殺行為とも言えるような無謀な挑戦をして、Salesforceと競合したいとしましょう。Salesforceが持っているすべての機能を考える必要があります。これから挙げる数字は完全に架空のものですが、私の言いたいことはうまく伝わると思います。Salesforceには1000の機能があるとします。Salesforceができることや統合できることが1000個あるわけです。しかし、ある特定の顧客はそのうちの50個程度しか使用していません。皆さんはこれを見て、狂っていると思うでしょう。すべての顧客がそのうちの50個の機能しか使っておらず、機能が1000個もあるのなら、その比率は非常におかしいですよね。顧客は機能の5%にしか触れていないのです。これは狂っているように聞こえます。Salesforceには何十万人ものユーザーがいて、この巨大なシステムを構築し維持するために少なくとも数千人のエンジニアが働いているのに、どの顧客もせいぜい5%しか使っていないのです。これは明らかに理にかなっていません。機能を削るべきですよね。
しかし、ここからが面白いところです。繰り返しますが、これらは架空の数字ですが、実際の数字を見た経験から言えば、傾向は私が説明しているものとほぼ一致するとお約束します。ある顧客が使用するその50個の機能のうち、半数は大半の顧客によって使用されています。つまり、顧客の80%が同じ25の機能を使用しているとしましょう。顧客の大部分はこのコアセットを使用しているのです。しかし、残りの25の機能はどうでしょうか。残りの25の機能は、1%未満の顧客にしか使用されていません。つまり、この50個のうち半分、全体の2.5%はほぼ全員に使用されており、残りの950個の機能は残りの顧客ベースにほぼランダムに分散しているのです。では、競合他社を作ろうとするとどうなるでしょうか。当然、誰もが使っている25の機能から始めます。そして顧客の元に行き、「あなたがSalesforceを使っているのを見ました。ぜひ私たちのプラットフォームに乗り換えてください。私たちはより安く、より速く、より信頼性が高いです。乗り換えてもらうには何が必要ですか？」と尋ねます。すると彼らは「なるほど、私たちが望む機能はすべて揃っているようですね。待ってください、チームの一人だけが使っているあの特定のカスタム機能はどうですか？」と言います。「あ、はい、それはまだありません。」「ああ、それならやっぱりSalesforceを使い続けることにします。」という展開になります。そしてこれが何度も繰り返され、顧客が求める50の機能のうち49を備えていたとしても、最後の1つの機能を使用する人が少なすぎるため、たった1人の顧客のためにそれを追加することを正当化できず、結局顧客を獲得できないことに気づくのです。これは、その市場で圧倒的なシェアを持ち、数千人の従業員やエンジニアが開発に携わっている巨大企業の多くに当てはまるケースです。彼らは長年ビジネスを続けてきたため、顧客が特定のものを必要とするたびにそれを構築してきました。100万人の顧客がいれば、そのうちの1%が使用する機能でも1万人の顧客に使用されることになります。しかし、顧客が100人しかいなければ、1%が使用する機能はたった1つのチームにしか使用されません。それではビジネスとして成り立ちません。これが、歴史的に強力なSaaS企業が圧勝してきた理由です。彼らは最初の顧客基盤を獲得すると、顧客を引き留めるために奇妙な機能を次々と追加していきます。そして、無作為な顧客が求める特有の機能をすべて競争力のあるスピードで構築できる企業は他に存在しないため、顧客は決して離れることができなくなるのです。しかし、その状況が今、変わりつつあります。
プラグインシステムの限界とVercelの成功
必要なすべての機能をどうやって実現するか、チャットで解決策を推測している人たちがすでにいるのが見えました。私は以前、プラグインアーキテクチャを構築したことがあります。あれは本当に地獄です。プラグインシステムをどれほど柔軟に作ったとしても、それに対応できない何かを求める人が必ず現れます。そして、その50の機能のうち少なくとも1つは、あなたが構築できると考えているプラグインや拡張機能のシステムでは機能しないのです。チャットのみんなもすぐに気づきましたね。プラグインは地獄です。プラグインシステムは本当に最悪です。完全な地獄です。1つのプラグインがアプリ全体をダウンさせる可能性は十分にあります。まさにその通りです。プラグインは機能する可能性もありますが、アーキテクチャを正しく設計するために多大なエンジニアリングの労力を必要とします。終わりのないサポートの悩みやコストを引き起こし、最終的には顧客が求めるすべての機能をカバーすることすらできません。
しかし、この方向性で成功を収めた企業も存在します。Salesforceはその1つだと言えるでしょう。Retoolは明らかにこの分野で最大の企業の1つであり、独自のプラグインシステムを構築するとともに、ユーザーが統合したいと思うあらゆるものに対応するプラグインを提供しています。しかし、その場合、ある程度ロックインされてしまいます。プラグインシステムを変更しようとすれば、一部の顧客にとって何かが壊れ、彼らを失うリスクが生じます。非常に強く縛られてしまうのです。では、これにどう対処すればいいのでしょうか。歴史的には、解決策はただすべてのエンジニアを雇い、誰もが望むすべての機能を追加し、他の誰もあなたと同じ機能を持っていないため競争できず、顧客は離れられないという状況を作ることでした。もし、特定のコア機能だけを必要とする市場のサブセットを特定し、競合他社の実装が不十分な機能が十分にあり、そこに食い込むことができれば、それは機能する可能性があります。これは、Vercel対AWSのような関係で実際に目にしていることです。Vercelは大部分がAWSの上に構築されており、AWSができることの大部分を欠いています。しかし、GitHubとうまく統合しながら、小規模から大規模までウェブアプリケーションをスケールさせてデプロイしたいという開発者のユースケースは非常に一般的です。技術的にはAWSに含まれるすべてのサービスで対応可能ですが、AWS上でそれを実現するための道のりは決して快適なものではありません。正しく設定するには多大な労力がかかり、特にいつでもランダムに複数のプロジェクトを立ち上げたい場合は、自ら失敗して台無しにしてしまいがちです。VercelはNext.jsアプリのデプロイを簡単にするために設立されました。彼らのチームは、ウェブ開発者がAWS内の複雑な要素にどう対処すればいいか分かっていないという欠点に気づいたからです。そして分かっていたとしても、設定が遅くて面倒でした。これらの理由から、VercelはAWSの上に自らの市場を確立し、現在も非常にうまくいっています。しかし、Vercelがうまくいった理由はもう1つあります。それは決してプラグインシステムを作ったからではありません。
では、なぜVercelはあれほどうまく機能したのでしょうか。簡単に言えば、あなた自身がコードを書くからです。Vercelはウェブアプリのバックエンド用のコードや、ユーザーに配信するバイナリ用のCDNをホストしていますが、彼らのサーバーでホストされるコードを書くのはユーザー自身に任せています。そのため、Vercelがやってくれないことは、どこか別の場所でやればいいのです。Cloudflareをファイアウォールとして使いたければ、どうぞ自由に使ってください。Supabaseをデータベースとして使いたければ、どうぞ。Convexを使ってデータベースやバックエンドのクエリをすべて処理したければ、それも構いません。私自身、Vercelでデプロイしているアプリの多くは、バックエンドがVercel上にはありません。Vercelを実質的にCDNとして、そしてドメインのホスティングとして使用し、バックエンドの処理はすべてConvexが行っています。つまり、VercelはAWSができることの95%以上を欠いているにもかかわらず、自らが提供する機能を非常にうまくこなすため、ユーザーはVercelから始めて、足りないものがあればコードを通じてプラグインのように接続すればいいのです。ここでの違いに注意してください。私はプラグインとは言っていません。コードでプラグインのように接続すると言っているのです。いわば、プラグインシステムを構築するのはあなたの仕事です。Vercelは単にコードが実行される場所を提供しているにすぎません。AIシステムが登場する前から、市場はすでにこの方向に動き始めていました。不要な複雑さを持たず、簡単に始めて維持し、スケールアップできる方向です。必要なものは他から持ってくればいいのです。AWSでさえ、ある意味この方法で構築されており、特定のサービスができることには限界があります。そして他のことをさせたければ、AWS上の別のサービスを利用します。Amplifyのように、ほとんどの機能を統合した1つのサービスを提供しようというAmazonの試みは、見事に失敗しました。これらのプラットフォームのモジュール式の性質は、その成功にとって非常に重要です。当然のことながら、Vercelがあなたのコードをホストしている以上、これはVercelのようなホスティングプラットフォームにとっては理にかなっています。コードを好きなものに接続できれば、それで問題ありません。しかし、Vercelは単なるインフラという1つのビジネス形態にすぎません。SalesforceやRetoolについてはどうでしょうか。それらはアプリケーションです。多くの複雑な要素と統合しなければならないアプリケーションです。今日、それらとどうやって競争すればいいのでしょうか。ここからが、私の過激な意見の始まりです。
ユーザーに主導権を渡す：T3 Codeの事例
これは、Y Combinatorのデモデーに向かうUberの中で、オープンソースについて私がどう考えているかという一部の創業者からの質問に答えようとしていたときに、私の中でひらめいたことです。すでにこの方向で考えてはいましたが、その瞬間に枠組みがカチッとはまり、それ以来ずっと書き留めておきたいと思っていました。実際、記事を書き始めたのですが、代わりに動画にすることにしました。最も簡単に言えば、顧客自身に彼らの特有の機能を構築させなければならないということです。製品に狂ったような機能をすべて組み込むのではなく、顧客が自分たちのものを可能な限り簡単に統合できるようにしなければなりません。Vercelの場合、これは十分に簡単です。彼らはあなたのコードをホストしているだけなので、何でも統合できます。しかし、インフラプラットフォームを持っていない場合や、すでにインフラを持っている企業と連携しようとしている場合、これははるかに複雑になります。まだ何のソリューションも持っていないときにVercelを採用するのはずっと簡単ですが、すでに持っている場合ははるかに難しくなります。そのため、よりモジュール式で、よりビルディングブロック（構成要素）指向の、そして私はあえて言いますが、よりオープンな方法で考え始める必要があります。
ご存知ないかもしれませんが、私たちはすべてのバイブコーディングGUIのオープンソースの代替としてT3 Codeを公開しました。ただ、誤解のないように言っておきますが、今のところこれで利益を得る方法はありません。T3 Codeでは、CodexやClaudeなどのプラットフォームから自分自身のサブスクリプションを持ち込む必要があります。Claude CodeのサブスクリプションやCodexのサブスクリプション、あるいはAPIを用意し、自分のマシンにCLIをインストールしてセットアップする必要があります。そして私たちは実質的に、CLIのグラフィカルなラッパーとして、より優れたGUIを作っただけです。なぜなら、私はターミナルが大好きですが、インタラクティブなやり取りをする際にはGUIがある方がはるかに好ましいと個人的に思っているからです。全体的に圧倒的に快適です。これを試した私の知り合いは全員、ターミナル派の人でさえも、この方法がこうした作業を行う上で優れていると納得して受け入れています。私たちはオープンソースでGitHub上で公開していますが、ここで共有したい数字が、この状況を理解する助けになると思います。T3 Codeの全期間での登録者数は約4万5000人です。正確には約4万2000人ですね。登録と言っても、アカウントを作成したわけではありません。アプリをインストールした際に一意の識別子が使用されたという意味です。そして、4万2000人が1度はアプリを開いています。現在、週に約1万6000人がアプリを使用しており、これは全く新しい開発ツールとしては非常に良い数字です。しかし、私が話したいのはその数字ではありません。私が話したいのはこちらの数字です。私たちは約9000のスターを獲得していますが、同時に1500のフォークもされています。週間ユーザーの10分の1がフォークしているのです。これがどれほど狂っているかお分かりでしょうか。ユーザーの10%がフォークし、何らかのカスタマイズを行っているのです。彼らは自分でそのフォークを実行し続けているかもしれませんし、途中でやめて公式アプリに戻ったかもしれません。あるいはPRを送ろうとしてそのままになっているかもしれません。しかし、これはT3 Codeを何らかの形で変更またはカスタマイズしようとした試みが1500回あったということです。私はこれにすっかり圧倒されてしまいました。これが起きて以来、ずっとこの数字を見つめ、これについて深く考え続けています。これほど多くの人がT3 Codeを自分好みにカスタマイズしているという事実が、私の根本的な考え方を完全に打ち砕きました。
毎日、私はEmanuelのような人たちの投稿にタグ付けされます。彼はT3 Codeを限界までカスタマイズし続けています。彼は今、自身のフォークに深くのめり込み、それをDP Codeと呼ぶようにすらなりました。そして今、彼は複数のターミナルを開けるtmuxの機能をそこに組み込もうとしています。T3 Codeにはターミナルの機能はあまりありません。Command + Jで下部に小さなターミナルが開く程度です。しかし彼は今、製品にtmuxを組み込んでいます。彼はすでに分割チャットを構築し、複数のターミナルとチャットをすべて横に並べて同時に表示できるようにしました。複数のチャットを同時に行えるようにもしました。独自のキューシステムも構築しました。コマンドやプラグインも導入しました。そして、ここでの彼の表現が素晴らしいのです。彼はT3 Codeで遊んでおり、それを愛しています。「遊んだり構築したりするためのスケルトン（骨組み）として最高だ」と。TheoとJuliusが作ったものを愛していると表現してくれています。「Codexアプリを適切なスキルとUIを備えたサーバーとして追加することに決めた」と。彼はコードベースで遊ぶのがどれほど楽しいかについて語っていました。モバイル版のCodex開発にも取り組んでいるようです。本当に素晴らしいです。彼は自分自身で一から作ることもできたはずですが、代わりに私たちが作ったものをフォークし、さらに深く追求し続けているのです。彼はハンドオフ機能まで追加しましたが、これは本当に私が本家に導入したいと思っているものです。ここには、公式のT3 Codeプロジェクトに追加したい、本当にクールなものがたくさんあります。当然、私たちはこれらの機能をあらゆるユースケースでうまく、そして確実にする必要があるため、一般的な意味で完璧にするにはさらに労力がかかります。しかし、ユーザーがソースコードをダウンロードし、自分好みにカスタマイズし、そして彼らが作ったクールなものをすべて共有してくれることが、どれほど素晴らしいことかお分かりでしょうか。魔法のようです。そして、これまでこのようなレベルで起こったことはありませんでした。もちろん、オープンソースは常に存在していました。人々は常にカスタマイズすることができましたが、そのカスタマイズのコストは劇的に下がりました。それは、私がここまであまり言及してこなかった「AI」という存在のおかげです。突然、コードベースさえあれば、開発者でなくてもコードベースに機能を追加できるようになったのです。
Mitchell Hashimotoの視点：ビルディングブロック経済
だとすれば、もうプラグインなんて誰が必要とするのでしょうか。私がここで思い描いている未来は、Emanuelがやっているようなことが、開発者としてプロジェクト全体をクローンし、変更を加え、メインからプルして自分で最新の状態に保つというようなものではない世界です。私が想像しているのは、すべての顧客が自分自身のフォークを実行している未来です。もし、PostHogのような製品があったらどうなるでしょうか。ちなみにPostHogはオープンソースです。PostHogは比較的簡単にセルフホストできますが、私は絶対にやりません。なぜなら、自分自身でClickHouseのクラスターを管理するなんて面倒なことはしたくないからです。私には全く魅力的ではありません。しかし、もし自分自身でチャートシステムや機能を組み込めるのであれば、突然、私にとって非常に魅力的なものになります。PostHogで特定のチャートや視覚化が欲しくて、彼らのサポートチームと2〜3週間もやり取りをした挙句、最終的に「それは十分重要だとは思いません」と言われたことが何度あったか数え切れません。あれは本当に嫌でした。私はPostHogが大好きですが、どうしても欲しかった1種類のチャートがなかったため、離れることを考えた瞬間がありました。これは狂っています。しかし、私は自分のPostHogをホストするつもりはありません。そのすべてを管理したくないからです。それでも、私のPostHogをカスタマイズし、私と私のチームが使うバイナリに変更を加えながら、引き続き彼らのバックエンドやサーバー、その他のすべてに依存したいとは絶対に思います。そして、このように考えているのは私だけではありません。私が意図的に言及しなかったもう1つの大きな勝者は、HashiCorpです。HashiCorpは、企業が大規模なソフトウェアを構築するために依存しているTerraformやその他の多くのツールを維持している企業です。MitchellはHashiCorpの創設者であり、特にTerraformの作成者でもあります。そして彼は現在、私たちが愛用しているターミナルであるGhosttyの作成者としておそらくさらに広く知られています。Ghosttyは非常に人気があります。まだ使っていないとしても、あるいは今コンピューターで開いていないとしても、皆さんのほとんどが一度は耳にしたことがあるはずです。ちょうど今日、彼は私が1ヶ月間伝えようとしてきたこのポイントを強調するような記事を書きました。「ビルディングブロック経済」です。ソフトウェアを構築し、大規模な普及を実現するための最も効果的な方法は、もはや高品質なメインライン（主流）アプリではありません。そうではなく、他の人が品質よりも量を重視して構築することを可能にし、奨励するビルディングブロックによるものです。Ghosttyは18ヶ月で100万人のデイリーユーザーを獲得しました。一方、Ghosttyのターミナルバインディング層全体を駆動するライブラリであるlibghosttyはどうでしょうか。これは独自の独立したプロジェクトでもあり、インストールして独自のターミナルを作成したり、他の製品に独自のターミナルを追加したりするために使用できます。そしてこれは、わずか2ヶ月で数百万のデイリーユーザーを獲得しました。つまり、18ヶ月かかったGhostty自身を、Ghosttyのコア部分がわずか2ヶ月で追い抜いたのです。これがどれほど異常なことかお分かりでしょうか。エージェントが好むのはビルディングブロックであり、時間が経てばビジネスもまたビルディングブロックを好むようになります。もしあなたのチームが、製品にない機能によって作業をブロックされることがなくなり、代わりにそれを必要とするPMが、アプリの一部として自分でそれを立ち上げることができるようになれば。それは状況を大きく変えます。Mitchellの記事全体を読みたい気分です。よし、やりましょう。
「これを直接経験し、他のエコシステムでも目撃したことで、商業的か非商業的かに関わらず、今日の製品やソフトウェア開発の実践に対する私の見方は根本的に変わりました。」と。繰り返しますが、これはオープンソースのサイドプロジェクトを作っているからできることではありません。ビジネスにとっても重要だと彼が考えていることなのです。X（旧Twitter）から移動しましょう。あそこは記事を読むのに最適な場所ではありませんし、Mitchellの文章をここで読みたいですからね。彼はまた、この記事がAIによって書かれたものではないことも強調しています。私も可能な限りAIを使って文章を書かないようにしています。ずっと前にブログで一度だけ適当な記事を書きましたが、おそらく非公開にするつもりです。基本的に、私はAIが文章を書くことをあまり好んでいません。私はすべての執筆と動画のスクリプトを自分の手で書いています。この動画でさえスクリプトは書いておらず、ただ考えていることを話しているだけです。だから彼がこの記事をいい加減に書いていないことにとても興奮しています。
彼が次に書いているセクションは「インポートが増えている」というものです。彼はそれが使われている方法を表現するために「ビルディングブロック」という言葉を使いました。なぜなら、それらは過去数十年とは全く異なる方法で組み立てられているからです。「私はライブラリやフレームワークという言葉は使いません。なぜなら、それはアプリケーションにまで及ぶからです。例えば、GhosttyのGUIアプリは、これまで以上に多くのフォークが行われ、カスタマイズされたパッチが上乗せされています。これは素晴らしいことです。今日の工場はエージェント主導です。あなたがそれについてどう感じようと、私はこれを客観的な真実として述べています。これらの工場から出てくるものの99%は全くのゴミだと主張することはできるでしょう。しかし、生み出されているものの圧倒的な量について反論することはできません。技術スタックや業界を越えて、数字はどこにでもあり、それは否定できません。AIはすべてをゼロから構築するのも悪くありませんが、高品質で、ドキュメントが充実しており、実績のあるコンポーネントを繋ぎ合わせることに非常に長けています。そしてAIは、明確に別の指示を与えられない限り、可能であればそうすることを好みます。これが今日のソフトウェアのビルディングブロックという性質です。私たちはこれまで以上に、既製のコンポーネントを手に取り、それらを繋ぎ合わせているのです。」と。
面白いことに、今日私は、Claude Codeに特定の技術を指示しなかった場合、彼らがどのような技術を選ぶかという別の興味深い記事を取り上げました。そして彼らは大部分において、これらのモジュール式でカスタマイズ可能なソリューションを非常に好みます。例えば、独自のステート管理を実装することは推奨していません。65%の確率でZustandを推奨します。彼らは、あなたが自分でAWSを理解してデプロイメントを行うことも推奨していません。JSで作業している場合、100%の確率でVercelを推奨します。モデルは、自分たちが望む方法で組み立てられ、npmでインストールでき、自分たちで制御・所有できるツールを好むのです。そしてここで推奨された最も人気のあるツールは「カスタムとDIY」でしたが、それ以外は、確実にインストールして使用できるものをすべて推奨しています。VercelやResend、Sentryのように有料のバックアップがあるかどうかは気にしていないようです。彼らは最良だと考えるもの、そして最も扱いやすいと考えるものを推奨しており、それは多くの場合、npmでインストールできるものです。
記事に戻ります。「もちろん、人間も常にこれを行ってきました。私のキャリアを通じて、人間のソフトウェア開発者は実績のあるプリミティブ（基本的な要素）の上に構築することを好んできました。しかし、コンポーネントをうまく組み合わせてそれらを繋ぎ合わせるための、コンポーネントの理解という参入障壁は、エコシステムを制限するほど高いものでした。」これは非常に重要なことです。私の古い動画に、このようなコメントがどれだけ寄せられたか数え切れません。「ウェブ開発のあらゆる動きにどうやってついていっているのですか？毎週のように登場する新しいフレームワークにどう対処しているのですか？72種類もあるステート管理ライブラリの中から、一体どうやって選んでいるのですか？」と。トップ3について何か知っていれば、選ぶのはそれほど難しくないのですが。しかし、人々は深刻な決断疲れに陥っていました。組み合わせることができる素晴らしいモジュール式のツールがたくさんあったにもかかわらずです。例えば、あの古き良きT3 Stack。私たちがT3 Stackを作った理由は、相性が良いと分かっているツールを組み合わせやすくするためでした。ああ、あのサイトは本当にアップデートが必要です。平均的な開発者は、すべてのソリューションを見つけて正しいものを選ぶのがすでに苦手でした。開発者ではない人にそれを頼むのはさらに最悪ですが、AIははるかに上手です。そしてMitchellがここで言うように、その障壁は事実上今やなくなったのです。
「エクスポートも増えています。これらの工場から出てくるのはもちろんソフトウェアです。大量のソフトウェアです。当然、マイナス面もあります。」マイナス面は明白なので、これに多くの時間を割くつもりはありませんが、それが存在することは認識しておきたいです。セキュリティ、脆弱性、不安定さ、負荷を支えるシステムがどのように機能するかについての全体的な理解の欠如。しかし、膨大な量のプラス面もあります。「品質の基準は低くなります。多くのユーザーに使用されるメインラインアプリは、すべての機能を他のすべての機能と比較検討しなければなりません。それらはどのように相互作用するのか？長期的なビジョンに合致しているか？何百万人ものユーザーのためにこれを維持できるか？1人から数百人のユーザーを対象とするファクトリーアーティファクト（工場で作られた成果物）は、これらを気にする必要がありません。その結果、より速く、より緩く出荷することができます。また、認知度も高まります。メインラインアプリはすべてを行うことはできません。彼らは通常、ほとんどのユーザーが必要とし、使用するユースケースに最適化します。」ここについては私は完全に同意しません。これらの巨大アプリの多くは、重要な顧客のために大量のカスタム機能を維持するのに手一杯になっていると思います。そしてそれもまた、起きている変化だと私は考えています。「ファクトリーアーティファクトは、ユーザーの小さな断面に対して最適化することができ、その結果、これらのユーザーはビルディングブロックの認知度を高めることができます。」彼はGhosttyでこれを大いに実感しています。非常にニッチなコミュニティが、彼らの奇妙なユースケースを解決する独自の特定のターミナルやツールを手に入れているからです。「メンテナンスの負担は大幅に軽減されます。本番環境の重要な部分を提供しているため、機能のリクエストに対して『結構です』と断るのがこれまで以上に簡単になります。」彼はこれについて公開で不満を漏らすほどスパムリクエストを受け、人々に自動で「No」と返信するボットまで作りましたが、今では、彼らが自分でフォークして自分のやり方でできるため、断ることにあまり罪悪感を感じなくなりました。
「そしてR&D（研究開発）は外部委託されます。メンテナーとして、他の人が何をしているかを見て、機能する概念実証を確認し、メインラインに何を持ち帰るかを決定することが今やとても簡単になりました。口先だけの話は減り、実行されることがずっと増えています。そして他の人が実行している間に、あなたは最高のアイデアをいいとこ取りすることができます。」あなたがビルディングブロックを提供し、彼らがアイデアを提供しているのですから、これは完全に公平なトレードオフです。非常に理にかなっています。Mitchellは、これがソフトウェアと製品開発に対する彼の見方を変えつつあると言います。私自身、これ以上同意できることはありません。彼はビルディングブロックを作成し、その上にアプリケーションやフォークが作られることを奨励することについて、はるかに目的意識を持つようになりました。彼はこれがより幸せなコミュニティ、より大きなコミュニティ、そして最終的にははるかに優れたメインラインのソフトウェアをもたらすと考えています。「高品質なアプリは消えませんし、高品質なアプリはこれらのビルディングブロックの開発者によって作られており、それらも消えることはありません。ほとんどのソフトウェアカテゴリーにおいて、パーソナライズされた適当なソフトウェアを望まず、洗練され、よくメンテナンスされ、十分にサポートされたアプリケーションを求める多数派のグループは常に存在すると彼は考えています。その代わり、彼はメインラインアプリがより安定し、機能セットにおいてより目的が明確になりつつあると考えています。ビルディングブロック経済のおかげで、安定性ははるかに大きく多様なユーザーグループからもたらされます。機能セットは、外部委託されたR&Dの巨大なエコシステムからもたらされます。メインラインアプリは依然として評価され、高品質で、よくメンテナンスされていますが、それは特定のグループに向けられたものになります。」
しかし、ここからが問題であり、これは私が彼の考えを非常に知りたいと思っていることです。なぜなら、彼はTerraformの商業化に成功したからです。彼はここでの商業化についてどう考えているのでしょうか。「次に続く明白な疑問は、これが商業化にとって何を意味するかです。クローズドソースの商用ソフトウェアは圧倒的に不利な立場にあるように見えます。なぜなら実際にそうだからです。エージェントは、クローズドで商業的なものよりも、オープンで無料のソフトウェアを容易に選ぶでしょう。この記事の執筆時点では、それは客観的な真実です。人気のあるモデルを使って実験を行っている独立した研究機関は、多様な環境下で、モデルが商業的な代替品よりもオープンで無料の選択肢を選ぶことを繰り返し発見しています。」今のところ、彼はここに対して具体的な答えを持っていません。製品やソフトウェア開発とは異なり、彼は現在、商業化可能な製品を直接構築していないからです。彼はすでにお金を稼ぎ、幸せなのです。彼には考えがありますが、あらゆる困難なことと同様に、答えはニュアンスに富んでいます。彼は権威的に語っているような幻想を与えたくないため、これについては言及を避けるつもりです。彼自身が実践し、さらに多くのことを学んだ時に、共有してくれるとのことです。助けてくれなくてありがとう。正直でいてくれて感謝します、Mitchell。
ええ、変化はすでに起こりました。私たちは、ビルディングブロックとソフトウェア工場が私たちの周囲のすべてを支配していることを受け入れ、その結果を受け入れ、内面化しなければなりません。私たちは逆の方向に走り、それに逆らう飛び地を作ることもできますし、完全にカオスに身を委ねることを選ぶこともできます。彼を知る人は、彼が行動において極端ではなく、文脈に応じて異なる意見を持っていることを知っています。彼の言いたいことは、単に変化が起こったということであり、私自身これ以上同意できることはありません。
ソフトウェアの自己フォークとpatch.mdの提案
Mitchellは商業的な側面には触れなかったので、私の経験やこの分野の他の企業の経験から、何がうまくいっているかについて少しお話しします。最も考えなければならないのは、定着性（スティッキネス）です。何があなたのソリューションを人々が好むものにしているのでしょうか。歴史的には、ユーザーが依存して離れられなくなるような特定の機能を組み込むことでした。しかし、これからはそうではなくなっていくでしょう。なぜなら、人々はただ独自のカスタムソリューションを構築するようになるからです。私はFrame.ioに十分腹を立てていたので、自分自身の代替品（Lawn）を作りました。そして最も難しかったのは、それを作ることではありませんでした。最も難しかったのは、私が価格設定を付けてそれを出荷し、他の人も使えるように人々に販売するためのすべての設定をすることでした。もし単にこれを社内だけで動かしたかったのなら、そうしていましたし、少なくとも2倍の速さで終わっていたでしょう。そして今、Lawnは多くの人にフォークされ、彼ら自身のビジネスに使われており、私は彼らが自分のコンテンツビジネスのために特定の方法でLawnを使いたいと思ったときに、今のところ一銭もお金を得られていません。Snazzy Labsや、元LTTのJakeことJacaのような人たちが、ビデオレビューのパイプラインのためにこれを内部でフォークして使い、それをとても気に入ってくれています。私はそれは素晴らしいことだと思います。しかし、それをどうやって商業化するかが課題なのです。私は彼らに、彼らが抱えている問題を解決できるビルディングブロックのセットを提供しましたが、ピースが欠けていました。ファイルの保存方法を考え、Auth（認証）の設定方法を考え、支払い機能を追加したいならその方法を考え、データベースやステートの管理方法など、これらすべてを解決しなければなりませんでした。そして、彼らは誰もコーディングができません。だから、彼らはエージェントを使ってこれらを行うしかなかったのです。そして彼らは成功しました。しかし、時間はかかりました。
では、Lawnのようなものを構築するとしたらどうなるでしょうか。サーバーやバックエンド側、そしてすべての動画情報の取得には私たちにお金を払ってもらうとします。しかし、あなたが実際に操作し使用するレイヤーは、望むなら完全にあなたが所有し、あなたが拡張するのも非常に簡単だとしたら。もし、私たちが顧客であるあなたのためにLawnをセットアップするときに、それが独自のカスタムドメインやサブドメインに接続され、あなたが実行しているビルドが実際のオリジナルプロジェクトのフォークであり、何かを追加したり変更したりしたいときは、ただそうするように指示するだけだとしたらどうでしょうか。ソフトウェアをフォークすることが、ソフトウェア自体の一部であるとしたら、それはどのようなものになるでしょうか。個人的には、それは非常に高い定着性をもたらすと思います。もし私のソリューションを試してみて気に入ったけれど、欲しいものが欠けている場合、それがオープンソースであればフォークできますし、オープンソースでありながら製品内でそれができるよう組み込まれていれば、アプリ内でフォークできます。あるいは、インフラ側は扱いたくないけれど、コードベースは自分のやり方でホストしたい場合、フォークして自分の好きなようにホストし、バックエンドには私たちのシステムを使って動かすことで、私たちにお金を払い続けることができます。ソフトウェアが真の意味でオープンでなくてもこれを実現する方法は確実にありますが、それがどれほどうまく、確実に見機能するかは分かりませんし、ソースコードが流出するのも簡単すぎるため、最初からそういった問題に対処しない方が良いと思います。
もう1つ、私が胸の内に秘めていて、動作するバージョンができるまでは世界に公開しないつもりだったアイデアがあります。でも、もう公開してしまおうと思います。これは後悔するでしょうね。こんなことを考えていると口にしたことすらすでに後悔していますが、現時点では私自身がそれを実現するには忙しすぎるため、アイデアを世に出したいのです。しかし、こんなに早く共有してしまうことで、私は大金を失うことになるかもしれません。その前に、少しだけ広告の時間を取らせてください。
今日のスポンサーはG2Iで、彼らの採用がいかに優れているかを伝えるために私にお金を払ってくれています。そして彼らは本当に素晴らしいです。だからこそ、Bataroundが新規採用の成功率を50%から90%以上に引き上げつつ、プロセスをスピードアップするのを支援できたのです。彼らが私に話してほしいのはそのことですが、私はそれを無視します。なぜなら彼らはもっとクールなことをしているからです。どうも、ディスカウント版のTheoです。彼はいちばん重要な広告の部分を忘れていました。それは、AI EngineerとReact Miamiの両方が来週開催されるという事実です。React Miamiについては皆さん聞いたことがあるでしょう。今年最高の開発者カンファレンスです。しかし今年は、4月20日から始まるAI Engineerのわずか3日前に開催されます。これは信じられないほど素晴らしいカンファレンスになるでしょう。AI分野の非常にクールな人々がたくさん集まります。実は私が参加する最初のカンファレンスでもあります。彼らのウェブサイトに行ってスピーカーリストを見れば、非常に豪華な顔ぶれであり、私はその一週間を本当に楽しみにしています。まだチケットを手に入れていないなら、絶対に手に入れるべきです。soyv.link/miamiにアクセスし、プロモコード「theo50」を使って、両方のカンファレンスに行ってください。私を信じてください。行く価値はあります。行かなければ後悔しますよ。今すぐやってください。チケットは急速になくなっています。とにかく行ってください。広告を挟んで申し訳ありません。熱心でない人を振り落としたかったのです。ここまで動画を見てくれた皆さんへのご褒美です。
私たちはすでに、claude.mdやagent.mdについては知っています。soul.mdについて知っている方もいるかもしれません。私はこれらについて、特にsoul.mdについて深く考えてきました。普通の人が自然な言語（プレーンイングリッシュ）で編集できるテキストファイルとして、その振る舞い、特性、使用方法が定義されるように設計されたソフトウェアというアイデアです。私の提案は、これが標準的なものになってほしいと本当に願っているのですが、「patch.md」です。聞いてください。私は前回のオープンソースに関する動画で、Yashaの構築方法がいかに私の常識を覆したかについて話しました。彼がプロジェクト内のすべてのパッケージを、好きなように編集できる追加のコードとして扱い、patch-packageを使用して変更を適用し、自分たちのユースケースに合わせてパッケージを調整するのを見たのです。
しかし、これには問題があります。パッケージがアップデートされ、変更したいコードの場所が変わったり何かがずれたりした場合、パッチを書き直さなければなりません。では、それを修正するにはどうすればいいのでしょうか。例えば、T3 Codeに「カスタマイズ」というボタンを隅に追加したとしましょう。それをクリックすると、フォークされたT3 Codeが「T3 Codeカスタム」のような形であなたのマシン上で別に起動し、ソースコードに変更を加えることができます。それは疑似的な開発モードのようなもので、変更が行われると新しいUIが表示されます。その後、Juliusがさらに10万行のコードと500のコミットをプッシュし、あなたの変更したものはすべて壊れてしまいます。エージェントにマージコンフリクト（競合）を解決させようとすることは可能ですが、失敗したらどうなるでしょうか。カスタマイズを行うたびに、それが1か所だけでなく2か所で変更されるとしたらどうでしょう。当然、コードを編集してあなたが望む機能を実現しますが、それと同時に、あなたが加えた変更の意図を「patch.md」ファイルにエンコード（記録）するのです。
patch.mdは単に、あなたがアプリに追加したすべての機能を説明するものです。そして将来、アップデートは単に新しいバイナリをダウンロードしてうまくいくのを祈るだけのものではなくなります。未来では、あなたはメインから変更をプルダウンします。もしきれいに適用できれば最高です。そのまま進んでください。もしできなければ、「エージェントを使ってアップデートを実行」というボタンを押すことができ、エージェントがマージコンフリクトの解決を試みます。もし失敗したり何か問題があったりした場合は、「きれいに解決できませんでした。ご希望であれば、バックグラウンドで別のインスタンスを実行し、過去にあなたが追加したこれらの機能を再適用します。その後、望み通りに機能するか確認していただき、完了したら移行します」と伝えます。
アップデートボタンがもはや単なるアップデートボタンでなくなったらどうでしょうか。最新のコードをクローンし、どの変更がきれいに適用でき、どれができないかを確認し、新しいバージョンにあなたの特定の変更が追加された状態になるまで、エージェントがあなたをガイドしてくれるプロセスになったらどうでしょう。そして、あるディレクトリに、あなたがT3 Codeに求めるすべてを記述したこのファイルがあったら。すべてのソフトウェアが自己フォークし、自己カスタマイズし、マージコンフリクトが発生したときに自己修復する未来はどのようなものでしょうか。このことを思いついてから、私は考えるのをやめられなくなりましたが、自分自身で構築するには忙しすぎます。これは私たちがT3 Codeに追加したいロードマップに乗っており、これが機能するためには正しく設定しなければならない小さなピースがたくさんあります。しかし、私は「patch.md」という言葉を生み出したかったのです。これこそが、普通の人が自分の好みに合わせてソフトウェアを編集できるようにし、企業がユーザーが使っているすべての奇妙なフォークを壊すことなく開発を続けられるようにする道だと固く信じているからです。
未来は私たちがオープンにする
ユーザーの90%がフォークしているとしたら、未来はどうなるでしょうか。これをどう解決するのか。ユーザーが望むものを手に入れられるようにしつつ、セキュリティが弱く、サポートも不十分で、統合もされていない状態に取り残されないようにするにはどうすればいいのか。ここには当然、多くの失敗する可能性が潜んでいます。これは私たちが歴史的に持ってきたソフトウェアの考え方とは大きく異なりますが、昔のUnix哲学もそうでした。私は、使っているアプリをそのアプリ自体の中でフォークでき、欲しいものを手に入れるために一から自分の世界を構築し直す必要がない未来をとても楽しみにしています。そして少なくともそれが実現すれば、今T3 Codeにある314件のプルリクエストをクローズすることへの罪悪感がずっと減るでしょう。全くもう。
皆さんにとって、この提案はおそらく答えよりも多くの疑問を投げかけるものであり、私も同じ疑問を抱いています。これは私がずっと深く考えてきたことですが、実際に手を動かす時間はなく、動作するバージョンを共有するまで待つことに疲れてしまいました。だからこそ、皆さんもこのことについて考えられるように、これを世に出したかったのです。エージェントを使った並行開発の次元を作り出すために、作業中のものを全方向に広がる無限のキャンバスを持つアプリというアイデアを出したのと同じです。他のすべてを先にやらなければ、カスタマイズすることはできないでしょう。このアイデアが皆さんの一部に響き、将来、リプライで面白い実例を見られることを願っています。
私たちは依然として、大企業が顧客のごく一部しか使っていない何百、何千もの機能を維持するために大量のエンジニアを抱えている世界に住んでいます。しかし物事はこの方向に向かっており、私は久しぶりに、数ヶ月後ではなく1年後に私たちがどこにいるかを予測しようとしています。でも正直なところ、これはたった3〜4ヶ月しかかからないかもしれないと考え始めています。そして当然、人々はここでパーソナルAIについても大いに考えています。スキルやプラグインを追加するだけでなく、自分のニーズに合わせて変更を加えることでカスタマイズする、最小限で信頼性の高いエージェントというアイデアです。ソフトウェアの可鍛性（柔軟に形を変えられる性質）は、平均的なユーザーがそれを変更できなかった時代には重要ではありませんでした。しかし、平均的な人がプロンプトによって機能を生み出せるようになった今、それを可能にするプラットフォームが勝者となるでしょう。そしてこれは、そこへ至る一つの道にすぎません。
では、私の主張をまとめましょう。なぜビジネスをオープンソース化するのか。顧客があなたのためにリサーチを行ってくれるからです。1%しか使われない機能をサポートする必要はありません。エージェントはOSSツールをより好みます。そして私が個人的に最も気に入っているのは、その周りに形成されるコミュニティです。T3 Codeで起きている素晴らしいことの数々を見るのは、本当に心温まる体験でした。Twitterのリプライに現れ続ける何百ものフォーク、アプリを使って人々が行っている狂ったような試み。Mariaのように、T1 Codeを使ってターミナルにそれを詰め込むような人々でさえもです。これは、オープンな方法で構築している場合にしか起こりません。
そして、これらの要素はすべて互いに連鎖しています。コミュニティが大きくなればなるほど、エージェントはそれを好みます。エージェントが好めば好むほど、より多くの顧客を獲得できます。顧客があなたのためにリサーチしてくれればしてくれるほど、より多くの機能を統合する（あるいは統合しない）ことができます。これらすべてが互いにフィードバックし合っているのです。既存の製品を手に取り、それを価値あるものにしているコアな部分を見つけ出し、カスタマイズ可能で拡張性のあるオープンな方法でそのコア機能を再構築し、そして世界がそれを使って何をするかを見守るという信じられないほどの機会があなたにはあります。
そして私は、ここで自分が正しいことを本当に、本当に願っています。なぜなら、私自身の時間とお金を大いに賭けているからです。これは私のいつもの「まあ、これは良さそうですね」という程度の推奨ではありません。私がポートフォリオを構築する上で中心に据えている考え方です。もし私がここで間違っていたら、私の子供たちは大学に行くお金を得られません。しかし、もし私がここで正しければ、私の子供たちは大学を所有するでしょう。だから、本当に私が正しいことを願っています。
しかし、これが未来になるためには、フォークやAIハッキングへの恐怖のせいでより閉鎖的になるのではなく、よりオープンな未来にするためには、皆さんが私と一緒にこの道を進んでくれる必要があります。私たちは世界に、オープンこそがこれを行う正しい方法であることを示さなければなりません。そして私にはそれができると分かっています。皆さんはすでに私に証明してくれました。皆さんがT3 Codeに行ったことを通じて私を納得させることができたなら、私たちは世界をも納得させることができるはずです。職場で憎んでいるあのツールの、オープンなバージョンを作ってください。自分が生き残るために必要なピースを作り、そのパーツに基づいて他に誰がそれを使ってくれるかを見てください。
私たちがそのようにすれば、未来はオープンになります。それを実現するために皆さんの力が必要です。いつも聞いてくれてありがとうございます。長くなりましたが、これは私にとって非常に重要なテーマであり、今ならその理由を分かっていただけたと思います。皆さんがどう感じたかぜひ教えてください。そして素晴らしいものを作り続けてください。できれば、オープンな場所で。それでは次回まで。ピース、オタクの皆さん。
コメント