近日，开源已死为开发者和企业构建日程调度基础设施的怕被开源初创公司 Cal 突然宣布，正将其旗舰级开源项目转为闭源模式，把闭源原因是代码该公司无力应对 AI 攻击其开源代码的风险。
Cal 联合创始人 Peer Richelsen 表示，挖成“开源安全以往一直依赖人工发现并修复各类问题，筛万如今 AI 攻击者却在公然利用这种代码透明性发起攻击。项目”
自成立之初，开源已死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 这样说道。
多年来，许多企业出于商业考量，已从开源许可转向半专有许可模式。此举或许算不上明智，但它们依然这么做了。而 Cal 的做法则是全新的，是因在 AI 黑客带来的威胁面前不堪重负，才选择彻底关停其商业开源项目。
Pumfleet 坚称，“做出这个完全是出于开源带来的安全隐患。我们依然坚定地热爱开源，如果未来形势发生变化，我们会重新采用开源。只是目前，我们不能冒客户数据泄露的风险。”
当被问及这类风险究竟源于代码公开可见，还是源于代码维护方式时，Pumfleet 表示两者都是原因，但开源状态显著加大了暴露风险。他说：“仅仅是代码公开这一点，就会让风险急剧上升。问题不在于只封闭代码或者加强代码安全，而在于我们两者都同时在做了。但仅仅加强代码安全并不足以降低风险。”
并且，Pumfleet 否认这一转变是为了加强管控。“这一决定完全是出于安全考虑，”他说道，“即便开源，我们也能掌控产品，转为闭源并不会给我们带来太多实际收益。这纯粹是为了降低安全层面的风险。”
然而，Cal 的做法还是迎来了不少开发者的质疑。“从长远来看，开源软件的安全性最佳。”“闭源并不能提高安全性。事实上，大多数安全研究人员甚至懒得去研究源代码，因为根本没必要。”许多开发者纷纷出来说道。
另一拨开发者则认为，应该利用 AI 来保障软件安全并使其变得更好。“如果这些工具好到让你担心它们会被用来暴露你的安全漏洞，也许你应该使用这些工具自己找出安全漏洞，然后修复它们，而不是通过隐藏来宣称安全。”
“借助 AI 的新技术，所有开源代码库的检查和修复速度将比任何闭源系统快 100 倍。”“开源软件并没有因为 AI 更容易逆向工程你的代码库就消亡。AI 同样可以轻易地逆向工程你的闭源系统。解决方案不是隐藏源代码，而是提高透明度、发布安全公告和加强安全加固。”
对于这类看法，Pumfleet 的回应是：“只是我觉得目前的 AI 还不够稳定。我们之前提到过，不同的 AI 扫描器会给出不同的结果。AI 很有可能完全漏掉一个 bug，然后在同一个 PR 里又抓到另一个 bug。”
还有网友评价，“如果 AI 读取你的开源代码对你的业务造成损害，那么你很可能把开源当作一种增长策略，而不是一种理念。现在关闭开源并不能保证安全。这只会减少那些真心实意加固代码的开发者，以及更多恶意攻击者利用 AI 攻击你的生产服务器。”
尽管其商业项目不再开源，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 对此说道。
参考链接：
声明：本文为 InfoQ 翻译整理，不代表平台观点，未经许可禁止转载。