2026 年 4 月 14 日，Cal.com 正式发布闭源公告，将核心生产代码从公开仓库迁移至私有仓库。这一决策在开源社区引发广泛讨论，其核心论据并非商业模式转变，而是 AI 安全威胁。以下从技术角度分析这一决策的实质影响，并为不同用户群体提供具体迁移建议。
从 MIT 到闭源的许可证演进脉络
Cal.com 的许可证变更并非突发，其演进轨迹反映了商业开源项目的典型路径。最初采用 MIT 许可证吸引开发者社区，2025 年转向 AGPLv3 并引入企业版，试图在开源贡献与商业变现之间建立平衡。此次闭源决策则彻底改变了这一平衡，将生产环境代码与社区代码分离。
根据官方公告，原有公开仓库将重命名为 Cal.diy，继续以 MIT 许可证维护。这意味着当前 GitHub 上的 cal.com/cal.com 仓库将成为社区分支，而企业版用户将获得私有仓库的访问权限。值得注意的是，官方明确指出两个代码库已出现显著分歧，包括认证系统和数据处理模块的核心重写。
AI 安全论点的技术评估
Cal.com 将闭源决定定性为安全决策而非商业决策，其核心论点是 AI 大幅降低了漏洞发现的门槛。在传统安全模型中，攻击者需要资深黑客投入大量时间分析代码；而现代 AI 可以系统性地扫描开源代码库，快速识别安全弱点。
官方博文中引用的关键证据是 AI 在数小时内发现 BSD 内核中一处存在 27 年的漏洞。这一案例确实展示了 AI 驱动的代码审计能力，但需要从多个维度审视其有效性。首先，开源项目的漏洞发现从来都不是新鲜事物，自动化代码扫描工具如 Coverity、Semgrep 早已存在，AI 的提升在于规模和速度而非本质。其次，闭源并不能消除漏洞风险 —— 闭源软件同样面临供应链攻击、逆向工程和内部泄露等威胁。真正的安全改进需要依赖持续的安全审计、漏洞赏金计划和快速的补丁更新机制，而非简单的代码可见性控制。
对于调度系统这类处理敏感日程数据的应用，安全重要性毋庸置疑。但关键问题是：闭源是否是最有效的安全手段？行业最佳实践表明，多层防御、零信任架构和持续监控往往比隐藏代码更为有效。
开发者与企业的实际影响
对于已在生产环境使用 Cal.com 的开发者和管理员，需要立即评估几个关键维度。开源版用户应检查当前部署的版本号和功能依赖，因为代码库分离后，社区版将不再自动获得企业版的安全更新和新功能。自托管用户可以继续使用 Cal.diy 分支，但需要明确这将成为一个独立的、社区驱动的项目，不再由 Cal.com 官方团队主导开发。
企业级用户面临更复杂的决策。如果需要官方支持和技术保障，应联系 Cal.com 销售团队获取企业版许可，确保访问私有仓库和商业支持服务。评估其他开源替代方案也是必要步骤，包括可能从 Cal.diy 分支分叉的社区版本。
对于依赖 Cal.com 构建集成或插件的开发者，需要确认 API 兼容性是否能在未来版本中保持稳定。官方文档显示 API 端点可能随闭源调整而变化，建议锁定特定版本或准备备用方案。
开源生态的系统性影响
Cal.com 的决策折射出更广泛的行业趋势。AI 安全初创公司正在产品化漏洞发现能力，这确实改变了开源项目的风险模型。然而，闭源并非唯一答案 —— 部分项目选择增强安全审计流程，部分则通过分层许可证策略在商业版和社区版之间建立防火墙。
对于开源维护者，这一案例提供了重要的参考框架。在做出类似决策时，应清晰沟通变更理由，提供平滑的迁移路径，并确保社区分支拥有足够的技术延续性。Cal.com 至少在形式上做到了这一点：通过 Cal.diy 保留了一个可用的开源版本。
从长远来看，AI 驱动的安全威胁将促使更多项目重新评估开源策略。但开源的核心价值 —— 透明度、社区协作和创新加速 —— 并不会因此消失。关键在于找到平衡点：在保持开放的同时，建立更强大的安全基础设施。
行动清单
对于受影响的用户群体，建议采取以下步骤：立即盘点当前 Cal.com 部署的功能需求和使用场景；评估 Cal.diy 是否能满足基本需求；如需企业级支持，联系官方获取闭源版本的许可信息；关注 GitHub 仓库动态，了解社区分支的发展方向；制定回滚或迁移预案，应对可能的兼容性问题。
Cal.com 的闭源决策是否为行业趋势的先兆，还有待观察。但对于依赖开源基础设施的开发者而言，理解这一决策的技术逻辑并制定相应策略，比单纯争论开源与闭源的优劣更具实际价值。
资料来源：Cal.com 官方博客（2026 年 4 月 14 日）