整理｜华卫

“开源已死，我们从未想过自己会说出这样的话。”

近日，为开发者和企业构建日程调度基础设施的开源初创公司 Cal 突然宣布，正将其旗舰级开源项目转为闭源模式，原因是该公司无力应对 AI 攻击其开源代码的风险。

Cal 联合创始人 Peer Richelsen 表示，“开源安全以往一直依赖人工发现并修复各类问题，如今 AI 攻击者却在公然利用这种代码透明性发起攻击。”

1 开源 5 年被 AI“吓退”，黑客多了 100 倍?

自成立之初，Cal 就宣称旨在打造 Calendly 的开源替代品，在 GitHub 上收获 4 万多 star，并坚持开源建设长达五年。其联合创始人兼首席执行官 Bailey Pumfleet 曾写道：“Cal.com 将作为开源项目运营，因为现有日程调度产品的局限性，唯有通过开源才能解决。”

现在 Cal 发展十分成功，自称是规模最大的 Next.js 项目，这也印证了其当初的定位判断。但如今，却一夜之间因 AI 闭源了。

“开源代码基本上就像是把银行金库的设计图纸公之于众。而现在研究这份图纸的黑客数量，已经暴增了 100 倍。”Pumfleet 补充道，“了解事物的内部运作原理，并进行逆向工程来找到漏洞，要容易得多。”

Cal 还援引了 Hex Security 首席执行官 Huzaifa Ahmad 的观点称，“开源应用被攻击利用的难度，比闭源应用要低 5 至 10 倍。在 Cal 看来，这一现状正引发软件行业生态的根本性转变。代码开源的企业，要么被迫承担客户数据泄露的风险，要么就得关闭代码的公开访问权限。”

与大多数商业开源初创公司一样，Cal 原本将源代码公开供人查看和修改，其一大核心卖点便是允许开发者验证系统运行逻辑、根据自身需求进行适配，并在自有服务器上独立部署。在此前“著佐权”协议 GNU Affero General Public License（AGPL）的授权下，Cal.com 支持这些操作，仅附带一项条款：任何修改该软件并将其作为服务运行的主体，都必须公开其修改内容。

Pumfleet 表示，像 Claude Opus 这类 AI 程序能够全面检索代码并查找漏洞，因此该公司正将项目的开源协议从 GNU Affero 通用公共许可证（AGPL）变更为专有许可，以此保障项目安全。

“我们致力于保护敏感数据。我们想做一家日程调度公司，而非网络安全公司。”他补充道，“Cal.com 处理着用户的敏感预约数据，我们不会因为对开源的热爱而拿这些数据冒这个风险。”

4 月初，Anthropic 的 Mythos 模型已证实，它可以识别和利用广泛使用的软件中的漏洞，甚至能够侵入全球部分安全性最高的软件系统。最典型的案例便是，Mythos 在极度注重安全的 OpenBSD 系统中发现了一处存在了 27 年的严重安全漏洞。作为一个以安全为中心的类 Unix 操作系统，OpenBSD 长期以来被认为是同类操作系统中最坚固的系统之一。

虽然目前 Mythos 功能仅限于通过 Glasswing 项目提供给特定合作伙伴，但其影响已经显现。对于那些基于开代码构建的公司而言，透明度和安全性之间的权衡正受到重新审视。现在，Cal 正成为率先响应这一转变的公司。

不过，促使 Cal 做出这一激进转变的并非完全是 Mythos。Cal.com 联合创始人兼董事长 Peer Richelsen 表示，放弃开放式开发的决策早已开始酝酿。Pumfleet 解释称，“我们本就预见了这一趋势。即便没有 Mythos，只需让 Claude Opus 这类上一代模型去分析开源代码库，就能轻而易举地找到漏洞。”

“但时机令人担忧”，Richelsen 这样说道。

2 社区大吵：安全，还是另有所图？

多年来，许多企业出于商业考量，已从开源许可转向半专有许可模式。此举或许算不上明智，但它们依然这么做了。而 Cal 的做法则是全新的，是因在 AI 黑客带来的威胁面前不堪重负，才选择彻底关停其商业开源项目。

Pumfleet 坚称，“做出这个完全是出于开源带来的安全隐患。我们依然坚定地热爱开源，如果未来形势发生变化，我们会重新采用开源。只是目前，我们不能冒客户数据泄露的风险。”

当被问及这类风险究竟源于代码公开可见，还是源于代码维护方式时，Pumfleet 表示两者都是原因，但开源状态显著加大了暴露风险。他说：“仅仅是代码公开这一点，就会让风险急剧上升。问题不在于只封闭代码或者加强代码安全，而在于我们两者都同时在做了。但仅仅加强代码安全并不足以降低风险。”

并且，Pumfleet 否认这一转变是为了加强管控。“这一决定完全是出于安全考虑，”他说道，“即便开源，我们也能掌控产品，转为闭源并不会给我们带来太多实际收益。这纯粹是为了降低安全层面的风险。”

然而，Cal 的做法还是迎来了不少开发者的质疑。“从长远来看，开源软件的安全性最佳。”“闭源并不能提高安全性。事实上，大多数安全研究人员甚至懒得去研究源代码，因为根本没必要。”许多开发者纷纷出来说道。

另一拨开发者则认为，应该利用 AI 来保障软件安全并使其变得更好。“如果这些工具好到让你担心它们会被用来暴露你的安全漏洞，也许你应该使用这些工具自己找出安全漏洞，然后修复它们，而不是通过隐藏来宣称安全。”

“借助 AI 的新技术，所有开源代码库的检查和修复速度将比任何闭源系统快 100 倍。”“开源软件并没有因为 AI 更容易逆向工程你的代码库就消亡。AI 同样可以轻易地逆向工程你的闭源系统。解决方案不是隐藏源代码，而是提高透明度、发布安全公告和加强安全加固。”

对于这类看法，Pumfleet 的回应是：“只是我觉得目前的 AI 还不够稳定。我们之前提到过，不同的 AI 扫描器会给出不同的结果。AI 很有可能完全漏掉一个 bug，然后在同一个 PR 里又抓到另一个 bug。”

还有网友评价，“如果 AI 读取你的开源代码对你的业务造成损害，那么你很可能把开源当作一种增长策略，而不是一种理念。现在关闭开源并不能保证安全。这只会减少那些真心实意加固代码的开发者，以及更多恶意攻击者利用 AI 攻击你的生产服务器。”

3 与开源版早已切割，核心组件数月前移出重写

尽管其商业项目不再开源，Cal 还是推出了 Cal.diy。这是面向爱好者推出的完全开源版平台，目前采用宽松的 MIT 许可证。Pumfleet 称，“Cal.diy 是 Cal.com 的核心部分，负责所有日程调度功能，只是剔除了全部企业级特性。”

具体来说，虽然 Cal.diy 保留了核心的日程安排引擎和预订基础设施，但移除了与商业产品相关的诸多功能，包括团队管理、工作流程、分析和企业身份验证。该开源项目可以在处理高敏感数据的闭源应用之外，供开发者进行试验和二次开发。

值得一提的是，支撑 Cal.com 托管平台的代码库，与公开版本的代码库早在随着时间推移逐渐出现差异，越来越多的商业及企业级功能是在开源代码仓库之外单独开发的。此次，这种分离状态算是正式明确下来了。

Cal 也表示，近几个月来已在公开代码库之外重写了核心组件，导致开源项目与实际生产环境使用的系统出现差异。“话虽如此，我们的主代码库如今已和开源版分道扬镳，因为我们重写了认证、数据处理等关键安全模块。我们只是希望保留 Cal.diy，以尽可能宽松的协议免费向社区开放并共享。”

实际上，对 Cal 来说，将核心平台转为闭源也引发了一个显而易见的问题：Cal.com 创立的初衷，至少在初期是成为对标 Calendly 的开源替代方案，此举是否会有疏远用户的风险？

Pumfleet 表示，“我们内部已和部分客户沟通，他们都很感激我们正采取措施，尽最大努力保障其数据安全。我认为不会有大量客户因此流失，因为归根结底，客户更关心的是数据安全，而不是软件是否开源。”Cal.com 还确认，作为过渡，目前使用自托管服务的客户将获得私有本地 GitHub 仓库的访问权限。

事实证明，AI 对开源项目和开发者而言确实是一把双刃剑。不仅是开源代码本身，开源商业模式也正因 AI 而发生根本性变革。关于 AI 对开源项目日益加深的影响，此前已有诸多讨论。本就时间紧张的开源维护者们，还要应付大量由机器生成、伪装成贡献的“AI 垃圾内容”。

而如今，能够系统性挖掘软件漏洞的 AI 系统相继出现，更是将这一议题推向了更严肃、以安全为核心的讨论方向。那么，今后其他没有足够资源应对大量 AI 黑客攻击的小型企业，是否会效仿 Cal？

“我确实了解到，许多和我们背景相似的商业开源公司，都在重新评估开源模式。”Pumfleet 对此说道。

参考链接：

https://www.zdnet.com/article/ai-security-worries-force-company-to-abandon-open-source/

https://thenewstack.io/cal-com-codebase-security-ai/

声明：本文为 InfoQ 翻译整理，不代表平台观点，未经许可禁止转载。

今日好文推荐

会议推荐

QCon 全球软件开发大会·2026 北京站将于 4 月 16 日 -18 日正式举办。本届大会以“Agentic AI 时代的软件工程重塑”为主题，聚焦 100 重磅议题，汇聚来自阿里、腾讯、字节跳动、小米、百度等一线科技企业与创新团队的技术专家，围绕 AI 工程化、系统架构与研发模式演进展开深入探讨。更多详情可扫码或联系票务经理 18514549229 进行咨询。