Theo Browne：AI 为什么可能让开源商业更有竞争力

当闭源软件不再满足我的需求时，我无法自行修改，因此对它的信任正在下降。AI 让开源的商业判断更复杂：竞争者可以复制，客户可以自托管，攻击者也更容易检查代码。但我认为可定制性可能让开放产品更有竞争力，而不是更弱。

风险是真实的。开放代码可能帮助竞争者复制功能，让客户绕过托管订阅，也可能让漏洞更容易被发现或利用。我听说有开源项目需要处理大量安全报告和攻击尝试；如何权衡取决于产品及其运营条件。

我们尚未开源 T3 Chat。团队规模很小，公开托管服务需要承担安全和工程负担，出现故障的代价也可能很高。T3 Code 在用户自己的机器上运行，使用用户自己的订阅，因此风险评估不同。我希望获得开放的好处，但不能忽视支持它的成本。

为了说明商业逻辑，可以看看 Salesforce、AWS 和 Retool 这样的成熟平台。它们的规模部分来自满足各种客户需求。我接下来的例子使用虚构数字说明模式，并不是 Salesforce 的真实使用数据。

假设一款产品有 1,000 个功能，每位客户使用其中 50 个。也许其中 25 个是大多数客户共有的，另外 25 个则因客户而异。新竞争者可以很快做出共同核心，但只要缺少一个冷门功能，客户就可能拒绝迁移。

客户规模很大时，只有 1% 客户使用的功能仍可能服务许多组织；对小竞争者来说，同一个功能可能只服务一家客户。成熟厂商会随时间积累这些长尾需求。即使单个客户只使用产品的一小部分，整体功能广度仍让它们难以被替换。

插件是一种答案，但根据我的经验，插件架构很难设计和支持。扩展点无法预见所有需求，兼容性本身也会成为长期承诺。插件可以发挥作用，但无法消除决定哪些部分可扩展及维护接口的成本。

另一条路是把一个常见场景做得特别好。我以 Vercel 为例：开发者部署 Web 应用时，不必自己组装所有基础设施。关键在于，托管的应用仍是客户可以编写并连接其他服务的代码。

开发者可以用 Cloudflare 提供防火墙、Supabase 提供数据库，或用 Convex 处理后端查询。开发者不必等待托管商提供每一种功能，而是用代码组合服务。模块化在 AI 出现之前就已存在，AI 可能降低使用它所需的工作量。

我对应用软件公司的建议是：让客户在有用的核心之上实现自己的特殊需求。这个想法应用到软件产品，比应用到基础设施更难，尤其是客户已经拥有需要集成的系统时。它需要可组合的构件，也需要修改这些构件的方法。

T3 Code 是我们面向编程智能体的开源图形界面。录制视频时，用户需要自带服务商订阅或 API 访问权限，产品本身尚未直接变现。我提到它，是因为用户已经开始以团队未曾计划的方式试验和修改代码。

我报告当时约有 42,000 个打开过应用的不同安装标识、约 16,000 周活跃用户、近 9,000 个 GitHub star 和约 1,500 个 fork。Fork 数不等于独立活跃用户数，也不能证明每个 fork 都有定制；它表明有人有兴趣尝试仓库，并不能据此得出 10% 用户完成定制。

一位用户 Emanuele 将 T3 Code fork 为 DP Code，加入了多个终端窗格、分屏对话、队列和交接工作流等功能。我希望将其中一些想法带回主项目，尽管要让功能面向广泛用户稳定运行，还需要额外工作。

开源定制并不新鲜。我的论点是，AI 智能体可能降低修改现有代码库的成本，让更多人尝试量身定制的版本。但这并不消除审阅、测试、安全和维护的需要，尤其是当使用者无法理解每一处更改时。

设想一位客户喜欢 PostHog 的托管后端，却需要产品没有提供的可视化图表。我曾为特定图表等待支持，也曾因为缺失功能考虑离开。我不想自己运营整套分析基础设施，而希望定制团队使用的部分，同时继续使用托管服务。

Terraform 和 Ghostty 的创建者 Mitchell Hashimoto 描述了相关的构件经济。Theo 引用他的说法：Ghostty 在 18 个月内达到约百万日活用户，而 libghostty 更快地传播到其他产品。这些是讨论中报告的数字，涉及不同产品和不同时间段。

Hashimoto 的观点是，构件可以是库、框架，甚至是供他人改造的应用。智能体能够快速组合有文档的组件，而 Ghostty 等项目也出现了定制 fork。我认为这扩展了开发者原本就在使用的模块化软件实践。

我引用了一项实验：在其测试条件下，编程智能体经常选择 Zustand 和 Vercel 等模块化工具。这些选择取决于提示词、模型和样本，不能证明所有智能体总是偏爱开源工具或某个特定厂商。

T3 Stack 曾尝试帮助开发者选择能一起工作的组件。即使好工具已经存在，人们仍会因选择太多而疲惫。智能体可以帮助组合和解释方案，但仍会犯错，是否适合、依赖是否合理仍需要人判断。

Hashimoto 承认，快速产出的软件存在安全漏洞、不稳定，以及使用者不了解关键系统等风险。小型定制工具的范围可能比主流产品更窄；维护者也可以观察可运行的 fork，决定哪些想法适合回到主项目。私人 fork 的初始门槛较低，并不意味着维护工作消失。

当用户有实际办法自行修改时，维护者可能更容易拒绝功能请求。Fork 也能提供研发原型。Hashimoto 仍预计许多用户会选择打磨完善、有人支持的主流应用；构件可以补充这些产品，而不一定普遍取代它们。

商业化仍是难题。Hashimoto 说自己还没有具体答案，我认可这种区分。关于智能体偏好免费或开放选项的说法，需要针对具体模型和任务提供证据；企业仍需找到客户愿意持续付费的服务。

我因对一款视频审阅产品感到不满，构建了替代品 Lawn。让内部版本运行起来，比为其他客户打包托管和定价更容易。有人 fork Lawn 用于自己的视频工作流，而没有向我们付费；我认为他们成功是好事，但接下来要解决可持续的商业模式。

这些用户仍需解决存储、身份验证、数据库管理，可能还包括支付。如果我们收费运营视频基础设施和后端，而客户拥有并定制前端，会怎么样？即便用户控制自己使用的代码，托管服务仍可能有价值。

客户可以在自己的域名上运行 fork，让智能体添加缺失功能，同时继续使用服务商的后端。我认为这可能增强黏性，因为定制成为产品关系的一部分。但这只是商业模式设想，不能证明客户一定愿意付费，也不能证明更新会很容易。

我的下一个提议是一个名为 patch.md 的文件。它会用自然语言记录定制更改背后的意图，同时保留实际代码修改。这个想法借鉴了 patch-package 等工具，但试图解决一个常见问题：上游代码移动或变化后，补丁可能无法继续应用。

设想一个 Customize 按钮：它创建本地 T3 Code fork，并让智能体修改。以后上游项目更新时，更新流程先尝试应用现有更改；如果失败，智能体可以尝试合并，或根据描述在新版本上重新实现这些功能。

然后由用户检查结果并决定是否迁移。我把这个想法称为 patch-in-place：让定制保持可用，同时帮助用户跟上更新。这是尚未实现的提议；文字描述或智能体辅助合并都不能保证正确性或安全性。

难题很明显：大量客户 fork 如何获得安全修复、持续得到支持，并与系统其他部分集成？我花时间思考了这个想法，但还没有实现。它需要实验、测试和处理失败的方法，而不能假设每一次冲突都会自行修复。

我更广泛的预测是：随着更多人能让智能体实现自己的需求，可塑的平台会越来越有价值。Pi 是我联想到的一个极简、可定制智能体例子。我不知道时间表，也不知道这一模式是否适用于所有品类，但我正在围绕这种可能性投资。

开源商业模式的理由是：用户可以围绕有用的核心探索小众需求、分享原型并形成社区，而公司可以出售托管或支持等服务。风险和经济账仍需要解决。我希望更多人构建有用的开放替代品，再看看大家会用它做出什么。