Hacker News 中文摘要

RSS订阅

Cal.diy:Cal.com的开源社区版 -- Cal.diy: open-source community edition of cal.com

文章摘要

Cal.diy是Cal.com的开源社区版,仅供个人非生产用途自托管,需要较强的服务器管理能力。商业用途建议使用Cal.com企业版。该项目采用MIT许可,自托管需自行承担风险。

文章总结

Cal.diy:面向所有人的开源日程管理平台

项目简介

Cal.diy 是 Cal.com 的社区开源版本,移除了所有企业/商业代码,采用 100% MIT 许可协议。它专为希望完全掌控日程管理基础设施的个人和自托管用户设计,无需任何商业依赖。

核心特点

  • 纯开源:无企业版功能,代码完全开放
  • 无许可限制:开箱即用,无需 Cal.com 账户或许可证
  • 社区驱动:欢迎直接贡献代码
  • 技术栈:基于 Next.js、tRPC、React、Tailwind CSS、Prisma 和 Daily.co 构建

与 Cal.com 的区别

  • 移除了团队、组织、SSO/SAML 等企业功能
  • 无需许可证密钥
  • 采用单一 MIT 许可,无"开放核心"模式

部署方式

  1. Docker 部署

    • 支持 Docker Compose 快速启动
    • 需配置 PostgreSQL 数据库和加密密钥
    • 提供 ARM 架构镜像支持
  2. 云平台部署
    支持 Railway、Northflank、Vercel(需专业版)、Render 和 Elestio 等平台一键部署

开发指南

  • 环境要求:Node.js ≥18.x,PostgreSQL ≥13.x
  • 快速启动
    bash git clone https://github.com/calcom/cal.diy.git yarn install yarn dev
  • 测试账户:提供默认测试用户(free@example.com/pro@example.com 等)

重要集成配置

  • Google 日历:需配置 OAuth 凭据和回调 URL
  • Zoom 会议:需申请客户端 ID 和密钥
  • Microsoft 365:需配置 Azure 应用注册
  • Daily.co:需添加 API 密钥启用视频会议

安全提示

  • 自托管需具备服务器管理和数据库安全知识
  • 生产环境必须替换默认加密密钥
  • 建议启用内容安全策略(CSP)

贡献与许可

  • 接受问题修复、文档改进和新功能开发
  • 遵循贡献者公约(Contributor Covenant 1.4)
  • 采用 MIT 许可证,无商业代码限制

注意:Cal.diy 仅限自托管使用,官方不提供托管服务。商业用户建议使用 Cal.com 企业版。

(注:原文中关于具体环境变量配置、数据库迁移步骤等详细技术细节已精简,保留核心功能说明和关键操作指引)

评论总结

以下是评论内容的总结:

  1. 对Cal.com开源策略变化的质疑

    • 用户指出Cal.com从鼓励企业使用开源版本转变为限制其使用,认为这是"诱饵调包"行为。
      引用:"Wow what a 180 from just a year ago..." (FlamingMoe)
      引用:"I just cannot trust a company that does a bait and switch like this." (FlamingMoe)
  2. 对Cal.diy的定位困惑

    • 用户不清楚Cal.diy与Cal.com的关系,认为这是公司为防止社区分叉的举措。
      引用:"Wait, I didn't even realize Cal.diy is owned by Cal.com..." (OsrsNeedsf2P)
      引用:"Please do not use Cal.diy — it's not intended for enterprise use." (raphaelcosta)
  3. 推荐替代方案

    • 用户推荐calrs等替代产品,认为它们更简单且有潜力。
      引用:"I just installed calrs... It absolutely rocks!" (_ache_)
      引用:"are there notable open source forks..." (swyx)
  4. 对开源精神的讨论

    • 用户批评Cal.com违背开源精神,主张真正的社区所有权。
      引用:"FOSS || GTFO" (lrvick)
      引用:"...it's not proper Open Source in spirit, only in form" (j1elo)
  5. 对代码质量和安全性的担忧

    • 用户批评代码质量差,并对系统安全性提出疑问。
      引用:"Good grief that codebase is absolute hell..." (ale)
      引用:"what's expected to be the authoritative data provider/storage?" (fencepost)
  6. 对品牌表述的批评

    • 用户对"开源社区版"的表述感到不适,认为其缺乏社区代表性。
      引用:"Who decided this was the one?... the copy gives me the ick" (dwedge)