11 月 2 日，Hacker News 首页出现了一个很扎眼的项目：OccupySaaS。口号只有一句——“They laid us off. We're rebuilding their SaaS.” 截至我写这篇时，帖子已经拿到 490 分、306 条评论。
它不是一份宣言，而是两个能跑的仓库：ZeroAuthy（对标 Auth0）和 SalesCompel（对标 Salesforce），Apache-2.0，官网写得很直白：clean room、open source、drop-in replacement。
我把官网、两个仓库的 README、兼容性文档和 HN 高赞评论都看了一遍。结论先说：这是一个很好的传播样本，也是一个非常早期的工程样本。 它最值得看的不是“AI 复刻 SaaS”这个噱头，而是它把“兼容层”当成切口，以及它在净室流程上做的那些约束。
一、事情本身：被裁的人，回头拆老东家的收费站
OccupySaaS 把自己比作 2011 年的“占领华尔街”，只是把帐篷换成了终端。它的叙事很完整：
- per-seat 定价是对增长的税：每招一个人，就多一份账单；
- 锁定不是特性：私有 API、导出墙、突然涨价，把客户留在原地；
- “他们裁掉我们，我们继续 commit。”
项目 10 月中旬建仓，10 月底开始对外，11 月 2 日被 HN 推到首页。目前组织下有三个公开仓库：zeroauthy、salescompel、website，全部 Apache-2.0。
二、技术路线：先做“能替换”，再谈“更好用”
这是我觉得整个项目里最值得借鉴的部分。
常规开源替代品的打法是“我比你更好、更便宜、更现代”。但对企业客户来说，真正阻止迁移的不是功能，而是迁移成本：现有代码要改多少、数据怎么搬、培训要多久、出问题谁背。
OccupySaaS 反过来，先做兼容：
- 从公开材料写规格：公开 API 文档、OAuth 2.0 / OIDC 等开放标准、官方 SDK 的可观察行为、黑盒测试结果，先落成一份书面 spec；
- 拉起防火墙：写 spec 的人和写代码的人分开，每个仓库带 CLEAN_ROOM.md，每个 fixture 和引用记录 provenance；
- AI 按 spec 实现：contract first（openapi.yaml）→ 代码 → 测试，合并前人工 review；
- 用官方 SDK 做验收：兼容性实验室直接跑厂商自己的公开客户端 SDK，现有代码不改能跑通，才算完成。
这个“用官方 SDK 当 oracle”的思路很实用。兼容性不再是“感觉像”，而是一组可以回归的测试。
具体到两个项目：
ZeroAuthy（Go）目标是 Auth0 的 Authentication API 和 Management API。把现有 Auth0 SDK 的域名指到 ZeroAuthy 的 tenant，不改代码就能用。README 里列出的已完成项包括 OIDC discovery、JWKS、多租户、hosted login、authorization code + PKCE、client_credentials、轮换 refresh token、revoke/logout，并用 auth0-spa-js、auth0-react、nextjs-auth0 验证过；Management API、管理控制台、组织/角色、日志与事件流也在推进。仓库还声称已拿到 OpenID Foundation 的 Basic OP、Config OP、Form Post OP 认证。
SalesCompel（Go/PostgreSQL + Vue）目标 Salesforce。目前有租户隔离的 Account/Contact 持久化 CRUD、describe、受限查询、external-ID upsert、bearer 认证，以及一个离线兼容实验室。跑法就一行：
npm ci --prefix compat/clients/node --ignore-scripts
npm --prefix compat/clients/node run check
值得一提的是，SalesCompel 的 README 没有吹“已完成”。它老老实实列了 M0–M10 里程碑，写明“没有任何完整里程碑通过 exit gate”，M9 生产认证“未达到”，并给出 185–350 个额外 plan 工作量的粗估。这种坦诚在开源项目里反而稀缺。
三、冷水：三个必须看清的现实
第一，人和成熟度。 HN 上有人翻完 GitHub 后说，两个仓库看起来是“一个人加 Claude”。这话不好听，但数据摆在那：zeroauthy 153 star、9 fork，salescompel 126 star、5 fork；后者最后一次 push 停在 10 月 21 日。对比 Auth0 和 Salesforce 的体量，这只是刚刚起步。Star 数和“能上生产”之间，差着几十个数量级的运维、合规和边界情况。
第二，软件和服务是两回事。 HN 最高赞评论只有一句：“The mistake is thinking the first S is what people pay for when it is the second S.” 第一个 S 是 Software，第二个 S 是 Service。企业买 Salesforce，买的从来不只是 CRUD 界面，还有 SLA、7×24 支持、审计报告、数据迁移、培训、生态和“出事有人接电话”。开源把这些成本从账单里拿掉了，但没有让它们消失，只是转移给了使用方。另一条评论问得更直接：如果钱不是问题，为什么不用 Salesforce？
第三，净室是方法论，不是免责声明。 “只读公开文档、不碰前东家代码”能降低风险，但不能自动解决法律问题。API 的功能性复制在不同司法辖区有不同判例，商标、UI 素材、文档许可、专利、前雇主保密协议仍然各自生效；拿厂商公开 SDK 做 CI 兼容测试，也可能受其许可证条款约束。CLEAN_ROOM.md 和 provenance 是善意证据，不是法律意见。
还有一层叙事反噬。HN 上有人指出：这些人在职时正是 lock-in 的实现者，被裁之后才开始反对 lock-in；也有人问，硅谷工程师什么时候成了“99%”。这些质疑未必公平，但说明光靠情绪叙事撑不住项目，最后还是要拿 commit 和 production case 说话。
四、对国内开发者真正有用的三点
抛开立场，这个项目有三件事可以直接抄作业：
- 兼容层是被低估的切口。 不要一上来就做“更好的替代品”，先做“现有代码不改就能跑”的兼容层。数据库、中间件、API 网关、IM SDK、埋点协议，都有这个空间。迁移成本趋零，替换才可能发生。
- Contract-first，用官方客户端做回归。 先把 openapi.yaml 和兼容矩阵写出来，再把厂商官方 SDK 放进 CI。兼容性从口头承诺变成可重复的测试，这比写十篇“对标 XX”的 PR 稿有用。
- 把“不做什么”写进仓库。 允许什么、禁止什么、每个 fixture 从哪来，全部留痕。对商业公司同样适用：这既是给法务和客户的说明书，也是给贡献者的边界。
五、结论：盯 30 天，而不是盯口号
OccupySaaS 现在更像一个信号，而不是一个产品。它证明了一件事：在公开文档足够完整的前提下，AI 可以把“重建一个兼容服务”的启动成本压到几个人、几周的量级。但它也证明了另一件事：剩下最难的部分——支持、合规、迁移、信任——AI 一样绕不过去。
接下来 30 天值得看的不是又涨了多少 star，而是三个硬指标：有没有外部贡献者进来、有没有第一个真实生产案例、SalesCompel 的 M2/M3 有没有通过 exit gate。
如果只有 star 没有 commit，它是一次成功的行为艺术；如果兼容矩阵开始长肉，那它会变成很多 SaaS 公司真正该紧张的东西。
参考
- OccupySaaS 官网
- GitHub 组织 occupysaas
- ZeroAuthy 仓库
- SalesCompel 仓库
- Hacker News 讨论（2026-11-02）
- OpenID 认证列表
作者简介
资深架构师 | 全栈工程师，服务过全球超 10 亿用户，勇闯自媒体玩一玩～
个人代表作：
- MCP 一站式管理平台
- 零一智学
- 摸了个鱼
