我很高兴地宣布，Better Auth 正在加入 Vercel。从一开始，这个团队就一直是我们最大的灵感来源，并且始终反映了我们开始从事 Better Auth 的许多原因。Vercel 与我们共同承诺保持身份验证的开源、框架和平台无关。联手将为我们提供更多资源和空间，专注于构建社区依赖的框架。我们还将能够更深入地投资身份验证的未来：一个代理在用户的代表上行动并需要安全、受限和可撤销的访问，同时将这些基本元素带到 Vercel 的产品中。我对我们的社区以及以不同方式激励我们的每一个人和帮助我们到达这里的人感激不已。三年前，我正在建立一个开源网络分析平台，需要添加身份验证。那时，每当我用 Next.js 开始一个项目时，我都会使用 NextAuth。大多数时候，我所需要的只是“使用 Google 登录”和一个简单的用户对象，所以它运行得很好。但对于那个项目，我需要组织（多租户）：邀请团队成员、角色、权限、适当的访问控制。我寻找可以与 NextAuth 一起使用的东西，但实际上没有什么选择。可选的方法是自己构建它或使用第三方身份服务。我花了几周时间将组织功能构建到项目中并围绕它重构了一切，结果我仍然不满意。不久之后，我开始尝试 next-org，一个在 NextAuth 之上添加组织支持并记录最佳实践的包装器。不断碰壁，API 从未感觉人性化，最终我在中途放弃了。然后我在任何地方都不断遇到同样的问题。我正在开发一个小的 Expo 应用程序，使用 NextAuth 添加 OAuth 感觉几乎是不可能的。后来，我想看看是否可以将一个 Next.js 项目迁移到 Svelte，但没有“适用于 Svelte 的 NextAuth”，所以迁移非常痛苦。那时，在 AI 成为日常话题之前，当 React 与一切的争论每隔一周就会爆发时，围绕 X 的一个反复出现的争论是我们是否应该自己搞身份验证，还是只使用一个服务。大多数人似乎都希望拥有自己的身份验证。几乎所有不这样做的理由归结为“我不想花时间构建功能 X”。所以我开始考虑建立一个框架无关的身份验证框架，具有一个简单的核心，供日常应用程序使用，且可以通过插件扩展任何所需的身份验证功能。我想出了 better-auth 这个名字，并向自己许下承诺：如果这个包名在 npm 上可用，那就是我构建它的信号。幸运的是，它可用了。所以我开始工作，时断时续，经历了大约 7 个月，同时也构建了更好的库，比如 better-fetch（我需要为 Better Auth 客户端）和 better-call（Better Auth 后端的简单 Web 服务器框架）。在大约四次重写整个框架，尽量撰写文档等之后，我在 X 上发布了一张截图，仅写了：“9 月 28 日。”那时我几乎没有关注者，但不知怎么的，那条帖子引起了人们的注意。我花了这一周时间最终定下来，并在 9 月 28 日发布了第一个版本。从第一周开始，人们就开始加入 Discord，提出问题，给出反馈，并且真的开始使用它。Better Auth 在前两个月保持 beta，直到 2024 年 11 月底的每个星期五，我发布了一个充满修复、改进和新功能的新版本，直到我们达到 1.0。大约那个时候，我对这一切变得非常认真。我想继续改善框架，保持与社区在 Discord 上的互动，保持 GitHub 的整洁，并学习人们通过功能请求和错误报告浮现出的每一个新身份验证概念。我认为这非常成功。人们对 Better Auth 的喜爱程度让人觉得依然罕见。我不断看到人们在 X 上称赞开发者体验、API 设计和文档——开发者社区开始制作 YouTube 教程，写博客文章，并向他人推荐这个项目。我曾经很虔诚地观看 Y Combinator 的视频。我在之前尝试过启动一个本地初创公司，但我希望在获得一个真正有效的项目后再申请 YC。Better Auth 给我这种感觉。虽然还不完全清楚它将如何成为一个商业模式，但我想我们会解决这个问题，如果有人要对我下注，那就是 YC。我申请了，和 Pete 面试，他很大方，给了我一次机会。我通过了。进入 YC 对于一个在埃塞俄比亚出生和长大的我来说是一个非凡的时刻。为了 YC 移居到旧金山感觉不真实。我花了很多时间在 X 上慢慢地在线，结果迅速熟悉了——旧金山基本上就是现实生活中的 X。在 YC 结束时，我们获得了由 Peak XV（前身为红杉印度和东南亚）主导的资本，并得到了超过 50 个基金和天使投资者的支持，围绕 Better Auth 建立了一家公司。就在那时，我开始思考超越开源的东西。