围绕 Cal.com 的开源争议，最新进展比口水仗更有信息量：官方已经把原来的开源代码基座单列成 Cal.diy，仓库仍在 calcom 官方 GitHub 组织下，不是第三方 fork。公开信息显示，这次调整包含几项核心动作：仓库更名、移除 Enterprise Edition 功能、移除 license checks、许可证从 AGPL-3.0 改为 MIT。

这让原本容易被说成“开源在退、控制在进”的故事，变得更具体了。Cal.com 现在做的，不太像彻底关门，也不是把整套能力重新交回社区；更像一次官方主导的重新分层：社区底座更开放，企业能力更集中。这比空泛的“支持开源”或“背离开源”更接近事实。

新线索相对此前讨论，真正补强了三点：一是官方没有放任民间分叉，而是自己切出了社区版代码基座；二是 MIT 替代 AGPL，法务和集成门槛确实下降；三是边界不是写在营销文案里，而是直接落实到代码和仓库结构里。判断因此也要跟着收敛：这不是控制权全面后退，而是控制方式换了。

发生了什么：Cal.diy 是官方社区版，不是“原样放回去”

从公开提交和仓库说明看，Cal.diy 的变化并不含糊。除了名称从 Cal.com 转成 Cal.diy，更关键的是一整组配套动作：移除 EE 功能、移除 license checks、许可证改 MIT。同一轮改动里，还去掉了 docs 目录、部分 org 相关代码、SAML/SSO、platform navigation、premium username 等内容，Docker 镜像也切到了 calcom/cal.diy。

这意味着现在开放出来的，不是过去那种一边标着开源、一边在代码里处处设商业边界的混合体，而是一个被明确“社区版化”的底座。

对搜索读者最关键的一点是：Cal.diy 不是新的品牌包装，而是产品分层落到了仓库层、功能层和许可证层。 这和单纯改 README、改销售口径，不是一回事。

为什么重要：MIT 降低了摩擦，但没有把企业能力一起放出来

许可证从 AGPL 改成 MIT，是这次最实在的变化。

AGPL 对很多公司最大的阻力，不在能不能用，而在法务、分发和私有集成上的不确定性。MIT 就直接得多：你想自托管、嵌进现有产品、做私有修改，阻力都小得多。对技术团队来说，这不是抽象的“更开放”，而是审批链更短、二开顾虑更少、商业集成更容易落地。

但 MIT 只解决“能不能更轻松地拿来用”的问题，不解决“你拿到的能力有多少”的问题。Cal.diy 这次同时移除了 EE 功能和一批组织级能力，所以它传递的信号很清楚：开放范围扩大了，可用功能范围却收窄了。

这也是新线索对旧判断最重要的修正处。过去如果只看到安全、授权或商业化争议，很容易把问题理解成“开源是否守住”。现在看，更准确的说法是：Cal.com 没有把开源彻底撤掉，而是把开源从“带商业钩子的半开放产品”调整成“更干净的社区底座”。边界更清楚，野心也更清楚。

谁最受影响：开发者受益最大，组织级用户要重新核对清单

这次变化最直接影响两类人，但真正值得展开的是其中两类决策者：做集成和二开的技术团队，以及准备把它当企业级调度系统的组织用户。

对前者，Cal.diy 的吸引力是现实的。

  • 想把预约能力嵌进自家 SaaS、CRM 或垂直工具里的团队，现在更容易重新评估 Cal.diy
  • 想做私有部署、内部改造、自定义流程的工程团队，MIT 会减少不少法务和授权顾虑
  • 原来因为 AGPL 犹豫的团队，现在至少有了重新建模成本和收益的理由

这些团队关心的不是口号，而是三件事：能不能合法放心集成、能不能私改、能不能长期跟主线演进。Cal.diy 在前两项上给了更明确的答案。

对组织级用户，结论没那么乐观。SAML/SSO、部分 org 能力、复杂治理能力既然已经被剥离，就不能再把社区版当成“免费可替代企业版”的默认选项。你的需求如果已经涉及统一身份、权限、协作和治理，Cal.diy 更像一个基础件，而不是完整方案。

换句话说，同样是“更开放”，开发者拿到的是自由，企业采购方拿到的更多是边界说明书。

接下来该看什么：不是 star 数，而是社区版能不能单独活下去

现在能确定的是仓库切分、许可证变化和部分功能剥离。还不能确定的，恰恰决定这次调整最后会被看成诚意，还是一次更聪明的商业切层。

更值得观察的是这三件事：

  • 社区版更新节奏是否稳定.如果 Cal.diy 只是一次性拆仓库，长期维护跟不上，MIT 的吸引力会很快打折
  • 迁移和版本关系怎么处理.现有自托管用户如何从旧仓库过渡，兼容性是否平稳，这直接影响技术团队的切换成本
  • 商业边界能否持续清晰.如果未来又出现功能混放、边卖边卡、条款和代码反复横跳，当前这次分层的信用会被消耗

这也是为什么我不愿把它写成“彻底回归社区”。证据不支持。更贴近现实的判断是：Cal.com 正在做一套更典型的商业开源安排——把底座放开，靠企业能力和分层运营保留商业控制。

这条路本身不稀奇，关键在于它这次做得比很多同类案例更直白：不是靠模糊条款吊着社区，而是把“你能拿什么、不能拿什么”切到仓库里。对开发者，这反而省时间；对企业客户，也少了误判。

如果把争议放回原点，问题已经不是“开源还守不守得住”这么简单。真正该问的是：当 AI 让安全和自动化风险都在上升时，公司愿不愿意给社区一个可持续、可开发、可部署的底座，同时把商业边界讲明白。Cal.diy 至少说明，Cal.com 选的不是全面收回，而是分层治理。

刀口见骨，胜过含糊其辞。对用户来说，清楚比姿态更值钱。