事件：一场还没发酵的"开源起义"
Tom's Hardware 报道了一个叫 OccupySaaS 的项目：一群不满订阅涨价和软件质量下滑的开发者，计划用 AI 辅助的方式，对常见 SaaS 服务做干净室（clean-room）开源重写。目前该项目在 Hacker News、Phoronix、Tom's Hardware 等几个技术媒体/社区已有报道，尚未大规模发酵，但技术路径本身值得聊。
首批目标是 Auth0 和 Salesforce 的替代品，分别叫 ZeroAuthy 和 SalesCompel。后续规划覆盖文档/Wiki、Issue 跟踪、Feature Flag、可观测性、客服系统——按分类对号入座的话，大概率对应 Confluence、Jira、LaunchDarkly、Datadog、Zendesk（此为媒体的推测）。
技术路径：为什么是干净室重写
这类服务跑在厂商服务器上，没有二进制可以反编译。所以重写的参考来源只有：公开文档、API、SDK 行为和适用的开放标准。项目也把伦理边界写得比较死：不反编译、不带前雇主的保密信息、不抄 UI 资产和商标。这套方法论的核心就是：看文档实现行为，不看代码。
技术选型是 Go 而不是 Rust，理由很务实：Go 能把所有依赖编译进单个二进制，拷贝到目标机器即可运行，天然适合打成 Docker 容器自托管。这个理由成立——自托管产品的部署摩擦是第一道生死线。
目标定位是 API 兼容的 drop-in 替换（据项目网站描述），这也是最难的部分。
真正的坑：黑盒行为复刻
托管软件是个黑盒，内部行为和 "gotchas" 不写在文档里。文章里举的例子很到位：就像主机模拟器为了兼容旧游戏必须复刻 bug 一样，一个 drop-in 替换要完全兼容，往往得复刻现有 API 的怪癖——文章点名了 Jira。
这些隐藏行为往往只有踩过坑的集成方才知道。AI 辅助开发在这里可能的价值是加速基于文档的实现工作，由人补齐这些隐藏行为——这是笔者自己的推断。这也解释了为什么项目发起人（自称有二十年经验的工程师 Thomas Meadows，据媒体援引其个人主页）强调自己的强项是项目管理——指挥 AI agent 干活的时代，工程管理能力确实被放大了。
我的判断：值得跟，但别神化
几点务实看法：
- 可持续性存疑。SaaS 的价值一半在代码，一半在持续运维（安全补丁、SLA、合规）。自托管把 "Someone Else's Problem" 变成了自己的问题。
- 但有商业闭环。项目用 Apache 2.0 协议，任何人都可以基于它提供托管服务——RHEL、GitLab、WordPress 都是先例。单机自托管是卖点，托管发行版才是商业模式。
- 合理预期。这类项目历史上成功的是替换轻量服务，深度绑定了业务流程定制的产品，重写只是起点，生态迁移才是成本大头。
给开发者的建议
如果你已经在被 per-seat 计费按着涨价的场景里（项目宣言的原话是 "per-seat licensing taxes growth"），可以先把目标服务拆成两块：协议简单、走开放标准的优先尝试替代；深度定制的先做数据导出预案。项目尚处早期，比较合理的跟进方式是关注它的进展和相关讨论，用 "迁移成本 vs 订阅成本" 做一次内部评估。
一句话总结：OccupySaaS 未必能真的"占领"SaaS，但它踩中了两个真实趋势——AI 辅助降低了重写的边际成本，以及订阅疲劳的积累。值得放进观察列表。
