“開源已死”？怕被 OpenAI 和 Mythos 把代碼挖成篩子，4 萬 Star 項目突然閉源！

整理｜華衛

“開源已死，我們從未想過自己會說出這樣的話。”

近日，為開發者和企業構建日程調度基礎設施的開源初創公司 Cal 突然宣布，正將其旗艦級開源項目轉為閉源模式，原因是該公司無力應對 AI 攻擊其開源代碼的風險。

Cal 聯合創始人 Peer Richelsen 表示，“開源安全以往一直依賴人工發現并修復各類問題，如今 AI 攻擊者卻在公然利用這種代碼透明性發起攻擊。”

開源 5 年被 AI“嚇退”，

黑客多了 100 倍?

自成立之初，Cal 就宣稱旨在打造 Calendly 的開源替代品，在 GitHub 上收獲 4 萬多 star，并堅持開源建設長達五年。其聯合創始人兼首席執行官 Bailey Pumfleet 曾寫道：“Cal.com 將作為開源項目運營，因為現有日程調度產品的局限性，唯有通過開源才能解決。”

現在 Cal 發展十分成功，自稱是規模最大的 Next.js 項目，這也印證了其當初的定位判斷。但如今，卻一夜之間因 AI 閉源了。

“開源代碼基本上就像是把銀行金庫的設計圖紙公之于眾。而現在研究這份圖紙的黑客數量，已經暴增了 100 倍。”Pumfleet 補充道，“了解事物的內部運作原理，并進行逆向工程來找到漏洞，要容易得多。”

Cal 還援引了 Hex Security 首席執行官 Huzaifa Ahmad 的觀點稱，“開源應用被攻擊利用的難度，比閉源應用要低 5 至 10 倍。在 Cal 看來，這一現狀正引發軟件行業生態的根本性轉變。代碼開源的企業，要么被迫承擔客戶數據泄露的風險，要么就得關閉代碼的公開訪問權限。”

與大多數商業開源初創公司一樣，Cal 原本將源代碼公開供人查看和修改，其一大核心賣點便是允許開發者驗證系統運行邏輯、根據自身需求進行適配，并在自有服務器上獨立部署。在此前“著佐權”協議 GNU Affero General Public License（AGPL）的授權下，Cal.com 支持這些操作，僅附帶一項條款：任何修改該軟件并將其作為服務運行的主體，都必須公開其修改內容。

Pumfleet 表示，像 Claude Opus 這類 AI 程序能夠全面檢索代碼并查找漏洞，因此該公司正將項目的開源協議從 GNU Affero 通用公共許可證（AGPL）變更為專有許可，以此保障項目安全。

“我們致力于保護敏感數據。我們想做一家日程調度公司，而非網絡安全公司。”他補充道，“Cal.com 處理著用戶的敏感預約數據，我們不會因為對開源的熱愛而拿這些數據冒這個風險。”

4 月初，Anthropic 的 Mythos 模型已證實，它可以識別和利用廣泛使用的軟件中的漏洞，甚至能夠侵入全球部分安全性最高的軟件系統。最典型的案例便是，Mythos 在極度注重安全的 OpenBSD 系統中發現了一處存在了 27 年的嚴重安全漏洞。作為一個以安全為中心的類 Unix 操作系統，OpenBSD 長期以來被認為是同類操作系統中最堅固的系統之一。

雖然目前 Mythos 功能僅限于通過 Glasswing 項目提供給特定合作伙伴，但其影響已經顯現。對于那些基于開代碼構建的公司而言，透明度和安全性之間的權衡正受到重新審視。現在，Cal 正成為率先響應這一轉變的公司。

不過，促使 Cal 做出這一激進轉變的并非完全是 Mythos。Cal.com 聯合創始人兼董事長 Peer Richelsen 表示，放棄開放式開發的決策早已開始醞釀。Pumfleet 解釋稱，“我們本就預見了這一趨勢。即便沒有 Mythos，只需讓 Claude Opus 這類上一代模型去分析開源代碼庫，就能輕而易舉地找到漏洞。”

“但時機令人擔憂”，Richelsen 這樣說道。

社區大吵：安全，還是另有所圖？

多年來，許多企業出于商業考量，已從開源許可轉向半專有許可模式。此舉或許算不上明智，但它們依然這么做了。而 Cal 的做法則是全新的，是因在 AI 黑客帶來的威脅面前不堪重負，才選擇徹底關停其商業開源項目。

Pumfleet 堅稱，“做出這個完全是出于開源帶來的安全隱患。我們依然堅定地熱愛開源，如果未來形勢發生變化，我們會重新采用開源。只是目前，我們不能冒客戶數據泄露的風險。”

當被問及這類風險究竟源于代碼公開可見，還是源于代碼維護方式時，Pumfleet 表示兩者都是原因，但開源狀態顯著加大了暴露風險。他說：“僅僅是代碼公開這一點，就會讓風險急劇上升。問題不在于只封閉代碼或者加強代碼安全，而在于我們兩者都同時在做了。但僅僅加強代碼安全并不足以降低風險。”

并且，Pumfleet 否認這一轉變是為了加強管控。“這一決定完全是出于安全考慮，”他說道，“即便開源，我們也能掌控產品，轉為閉源并不會給我們帶來太多實際收益。這純粹是為了降低安全層面的風險。”

然而，Cal 的做法還是迎來了不少開發者的質疑。“從長遠來看，開源軟件的安全性最佳。”“閉源并不能提高安全性。事實上，大多數安全研究人員甚至懶得去研究源代碼，因為根本沒必要。”許多開發者紛紛出來說道。

另一撥開發者則認為，應該利用 AI 來保障軟件安全并使其變得更好。“如果這些工具好到讓你擔心它們會被用來暴露你的安全漏洞，也許你應該使用這些工具自己找出安全漏洞，然后修復它們，而不是通過隱藏來宣稱安全。”

“借助 AI 的新技術，所有開源代碼庫的檢查和修復速度將比任何閉源系統快 100 倍。”“開源軟件并沒有因為 AI 更容易逆向工程你的代碼庫就消亡。AI 同樣可以輕易地逆向工程你的閉源系統。解決方案不是隱藏源代碼，而是提高透明度、發布安全公告和加強安全加固。”

對于這類看法，Pumfleet 的回應是：“只是我覺得目前的 AI 還不夠穩定。我們之前提到過，不同的 AI 掃描器會給出不同的結果。AI 很有可能完全漏掉一個 bug，然后在同一個 PR 里又抓到另一個 bug。”

還有網友評價，“如果 AI 讀取你的開源代碼對你的業務造成損害，那么你很可能把開源當作一種增長策略，而不是一種理念。現在關閉開源并不能保證安全。這只會減少那些真心實意加固代碼的開發者，以及更多惡意攻擊者利用 AI 攻擊你的生產服務器。”

與開源版早已切割，

核心組件數月前移出重寫

盡管其商業項目不再開源，Cal 還是推出了 Cal.diy。這是面向愛好者推出的完全開源版平臺，目前采用寬松的 MIT 許可證。Pumfleet 稱，“Cal.diy 是 Cal.com 的核心部分，負責所有日程調度功能，只是剔除了全部企業級特性。”

具體來說，雖然 Cal.diy 保留了核心的日程安排引擎和預訂基礎設施，但移除了與商業產品相關的諸多功能，包括團隊管理、工作流程、分析和企業身份驗證。該開源項目可以在處理高敏感數據的閉源應用之外，供開發者進行試驗和二次開發。

值得一提的是，支撐 Cal.com 托管平臺的代碼庫，與公開版本的代碼庫早在隨著時間推移逐漸出現差異，越來越多的商業及企業級功能是在開源代碼倉庫之外單獨開發的。此次，這種分離狀態算是正式明確下來了。

Cal 也表示，近幾個月來已在公開代碼庫之外重寫了核心組件，導致開源項目與實際生產環境使用的系統出現差異。“話雖如此，我們的主代碼庫如今已和開源版分道揚鑣，因為我們重寫了認證、數據處理等關鍵安全模塊。我們只是希望保留 Cal.diy，以盡可能寬松的協議免費向社區開放并共享。”

實際上，對 Cal 來說，將核心平臺轉為閉源也引發了一個顯而易見的問題：Cal.com 創立的初衷，至少在初期是成為對標 Calendly 的開源替代方案，此舉是否會有疏遠用戶的風險？

Pumfleet 表示，“我們內部已和部分客戶溝通，他們都很感激我們正采取措施，盡最大努力保障其數據安全。我認為不會有大量客戶因此流失，因為歸根結底，客戶更關心的是數據安全，而不是軟件是否開源。”Cal.com 還確認，作為過渡，目前使用自托管服務的客戶將獲得私有本地 GitHub 倉庫的訪問權限。

事實證明，AI 對開源項目和開發者而言確實是一把雙刃劍。不僅是開源代碼本身，開源商業模式也正因 AI 而發生根本性變革。關于 AI 對開源項目日益加深的影響，此前已有諸多討論。本就時間緊張的開源維護者們，還要應付大量由機器生成、偽裝成貢獻的“AI 垃圾內容”。

而如今，能夠系統性挖掘軟件漏洞的 AI 系統相繼出現，更是將這一議題推向了更嚴肅、以安全為核心的討論方向。那么，今后其他沒有足夠資源應對大量 AI 黑客攻擊的小型企業，是否會效仿 Cal？

“我確實了解到，許多和我們背景相似的商業開源公司，都在重新評估開源模式。”Pumfleet 對此說道。

https://www.zdnet.com/article/ai-security-worries-force-company-to-abandon-open-source/

https://thenewstack.io/cal-com-codebase-security-ai/

聲明：本文為 InfoQ 翻譯整理，不代表平臺觀點，未經許可禁止轉載。

會議推薦

QCon 全球軟件開發大會·2026 北京站將于 4 月 16 日 -18 日正式舉辦。本屆大會以“Agentic AI 時代的軟件工程重塑”為主題，聚焦 100+ 重磅議題，匯聚來自阿里、騰訊、字節跳動、小米、百度等一線科技企業與創新團隊的技術專家，圍繞 AI 工程化、系統架構與研發模式演進展開深入探討。更多詳情可掃碼或聯系票務經理 18514549229 進行咨詢。

今日薦文

你也「在看」嗎？