Discourse 不会转为闭源

Cal.com 宣布,他们将关闭其代码库,不再提供开源产品。他们的理由是,人工智能使得开源对 SaaS 公司而言变得过于危险。代码以近乎零成本被人工智能扫描并利用,而透明度如今正演变为暴露风险。


这是针对原始条目 https://blog.discourse.org/2026/04/discourse-is-not-going-closed-source 的配套讨论主题。
37 个赞

谢谢你,Sam。我很感激你如此直面这个问题。我一直在关注最近的 AI 相关新闻(尽管我可能无法完全跟上),这个问题确实一直萦绕在我的心头。请继续出色地工作。:discourse:

14 个赞

这里充满了敬意。长期以来,我内心深处一直对 Discourse 有这方面的担忧。感谢你们站在正确的一边,继续不劣化核心产品。出于多种原因,我无法想象短期内会有 AI 监管出台,但目前的形势确实非常严峻。

希望你们都明白,大家多么感激你们既不自托管产品,又不会像许多“开源”产品那样,恳求用户掏钱才能解锁基本功能。:meow_heart:

14 个赞

突然关闭你的源代码并不能神奇地修复代码中尚未被发现的所有现有安全问题。但这确实会阻止社区帮助修复这些问题。

除此之外,这对所有帮助你的产品成长的人来说也是一种极不尊重的行为。为什么我之后,甚至永远都不会再与 cal.com 或其爱好者“分支”cal.dyi 有任何关联?他们刚刚抛弃了所有建立起来的信任。

8 个赞

感谢这篇博客文章,读起来很有趣,Sam :slight_smile:

这件事已在互联网上广泛传播,但安全威胁(“我们的模型太危险了”)真的是不发布它的主要原因或真实原因吗?

有些人认为这更像是一次公关噱头,尽管并未完全否定这些模型的潜在实力。例如:On Anthropic's Mythos Preview and Project Glasswing - Schneier on Security

我当然对这些复杂话题一无所知,但当我看到文章在各大新闻网站和在线社区中迅速传播时,我会保持谨慎。我推测其中可能有一些被夸大的说法,或者某些信息需要澄清,并非完全属实。

我毫不怀疑这些模型能够极其快速地发现并可能利用漏洞,您甚至通过 Discourse 的代码示例强调了这一点。


关于文章本身,我想指出一点让我感到奇怪的地方:

闭源一直是 SaaS 领域一种比人们愿意承认的更弱的防御手段。Web 应用并非一次性发布后就可以隐藏起来的东西。它的很大一部分内容会在每次请求时直接交付到用户浏览器中:JavaScript、API 契约、客户端流程、验证逻辑以及功能行为。攻击者已经可以检查所有这些内容,而 AI 使得这种检查的成本大幅降低。关闭仓库可能隐藏一些服务器端的实现细节,但并不能让整个系统变得不可见。它主要起到的作用是减少能够全面审查系统的防御者数量。

随后,后文又提到:

闭源可以带来一定程度的隐匿性,但隐匿性是脆弱的。代码会被泄露,二进制文件会被逆向工程,API 会被映射,攻击者仅通过询问运行中的系统就能获取大量信息。真正的防御不是永远隐藏代码,而是构建在审查到来时依然能够经受住考验的软件和运营实践。

当我读到第二段时,我有一种似曾相识的感觉。
我向上滚动页面,发现这两段话非常、非常相似。它们表达的是同样的观点,只是措辞不同。

我理解总结的必要性,但在这种情况下,我确实感觉自己在几段之前就已经读过几乎相同的内容了。

5 个赞

这真是一篇鼓舞人心的文章,Sam。这让我为在 Discourse 工作感到自豪。

[拼命想着该说什么才能让自己听起来不那么像马屁精……]

说不定现在就去干点活儿。:wink:

18 个赞

读到这里真的让我深受触动。那句关于选择勇气而非躲在锁闭的门后的话,如此有力。感谢您13年来始终支持开源,并提醒我们开源的意义所在。这些话语将铭记于心。

9 个赞

说得太好了!

https://releases.discourse.org 也能用,而且现在看起来真不错 :smiling_face_with_sunglasses:

9 个赞

太棒了!内容清晰易懂,非常实用,做得好!

5 个赞
4 个赞

如果开源已经死了,那为什么他们还在使用它?为什么他们还没有从 PostgreSQL 迁移到 Oracle 数据库?为什么团队还没有从 Linux 迁移到 MS Windows?等等。

他们的整个应用程序、中间件,甚至大部分基础设施都是基于开源构建的。

5 个赞

这是一个非常棒的公告和话题。

我理解 AI 加速零日漏洞利用的风险。

我并非低估这项工作,只是想知道 Discourse 是否会考虑为更新引入某种相对实时的 CI/CD 流水线?

也许 Meta 和 Discourse 托管的站点已经实现了这一点,我特别想到的是自托管场景:可以通过功能标志在发布时启用更新,或者通过自动化流程延迟更新。

或者,这或许会体现为一个可独立于其他更新启用的自动化安全更新功能。

无论如何,请允许我继续表达对 Discourse 软件及其背后团队的感谢与赞赏。谢谢!

2 个赞

这里之所以不是个好主意,是有充分理由的:

1 个赞

没错!这意味着他们继承了该中间件的漏洞,而这些漏洞无论他们选择如何隐藏,都会被公开披露。

这完全是一场巨大的闹剧。每个本科生都知道“通过隐匿实现安全”是行不通的。

Discourse 证明了,完全有可能在保持开源的同时,构建可持续的 SaaS 业务,并在漏洞态势中保持同步,而不是试图逃避它。

5 个赞

很高兴看到 Discourse 不仅继续保持开源(这一点我从未怀疑过),还决定在此表明立场。:heart: 我不介意他们的决定,这是他们自己的选择,但整个公关包装的做法令人极其沮丧。

AI 代码生成和漏洞挖掘让我认识到,我们仍在与那些自远古以来高管们就持有的、错误却流行的观念作斗争。在本例中,就是针对开源的“通过隐匿实现安全”的论点。

2 个赞