当“open core”项目因与 EE 竞争而拒绝贡献时

原文 ↗ Hacker News 讨论 ↗

项目背景与触发事件

  • 讨论围绕一个“open core”项目拒绝了一项重要的社区 PR 展开，该 PR 增加了 SSO/SAML/OIDC 支持，并与其企业版（EE）重叠。
  • 这项 PR 挂了好几个月，维护者几乎没有回复，随后又以商业/“愿景”理由关闭，线程还被锁定，许多人都觉得这很不尊重。

Open core 模式 vs. 真正的开源

  • 有人认为，这说明“open core”往往意味着故意发布一个更差的免费版本，以保留变现空间。
  • 也有人回应说，如果没有付费功能，项目可能根本不存在；将功能放在 EE 后面被视为维持可持续性的必要手段。
  • 一些评论者强调，该项目采用 MIT 许可，因此从法律上说它确实是开源的，不管其商业模式如何。

SSO / “SSO 税” 与安全性

  • 许多人批评把 SSO 放到付费墙后面，称之为“SSO 税”，并认为安全功能不应被商业化。
  • 反方观点是：SSO 是企业的必需品，而不是个人的核心安全要求，因此很自然地可以作为价格区分点。
  • 一些自托管用户则认为，即便是小型部署，SSO 也是必需的，因为它能提供更稳健的 2FA/WebAuthn 和集中式账户管理。

贡献、权利感与维护者责任

  • 一方认为贡献者的努力是慷慨的，而在长期沉默后被拒绝既打击人，又沟通不当。
  • 另一方强调，维护者并不欠贡献者什么：PR 是负担，不是权利，大改动应该先讨论。
  • 争论集中在“权利感”上：期待基本沟通和非敌对式回应是否合理，还是对免费维护者来说已经要求过高？

Fork 与现实限制

  • 许多人指出，fork 就是预期中的安全阀：代码是 MIT 许可，任何人都可以实现并维护被拒绝的功能。
  • 也有人强调现实成本：持续 rebase、解决冲突、独立发布，以及处理分叉代码中的 bug 都很昂贵。

关于 open core 的更广泛结论

  • Open core 被视为天生充满张力：社区希望“尽可能好”的 OSS；公司则必须有意保留一部分价值。
  • 有些人最终表示，他们会避开 open core / 由公司支持的“可自托管”产品，或者至少对它们保持怀疑。