說好的敬畏每一行代碼呢？Antd代碼彩蛋炸翻一圈人

對於開源項目來說，一個細微的改動就會影響到無數使用該項目的產品、公司、生產環境。阿里是中國開源的先鋒公司，對於事故的處理也一直都很有擔當，阿里雲“敬畏每一行代碼，敬畏每一份託付”曾是公關文的典範，但Antd項目彩蛋變炸彈這件事兒，我們卻只能表示遺憾和可惜。開源項目的責任如何看待？怎樣避免類似事件再次發生？

12月25日，正當人們沉浸在節日的氣氛中時，部分開發者突然發現他們開發的Web網頁的界面發生了變化，按鈕上方出現“積雪”，經過探索發現這是前端UI組件庫Ant Design（簡稱antd）提前埋入一個未經聲明的“彩蛋”，事件迅速發酵，引起了巨大爭議。

事件背景

現在讓我們再來回顧一下整個事件的發展過程：

12月25日上午，Antd的用戶發現網站上一個正常的按鈕上方出現了“積雪”的logo，如下圖所示：

經過查看，Antd的用戶在工作後臺上發現按鈕的class多出一個chrismas，title變成Ho Ho Ho，然後再去查看antd源碼，發現：

最開始，開發者以爲是被黑客代碼植入了，在反覆檢查之後才確定是代碼中埋入了定時的“聖誕節彩蛋”。

不久，此事就開始在知乎和Antd issue上引起討論，很多開發者表示憤怒與不滿。

很多開發者認爲，Antd是一個通用庫，不應該在裏面加彩蛋，尤其Antd大都是2B的，它的用戶對安全、穩定、可控性的要求更高，發生一些細微的錯誤都可能影響一個公司的業務，再者，如果今天被隨意加入一個彩蛋，那麼明天就可能被人引入病毒，這讓開發者很是恐慌。最後，這個彩蛋沒有下線機制，讓開發者無所適從。

有開發者半開玩笑說，如果不是聖誕節而是中國的傳統節日也許就不會引起那麼大的爭議了，因爲有些單位有明令禁止過洋節的規定，試想一些，如果這些禁止過洋節的網站（如個別政府網站）的按鈕都是聖誕節的logo，後果可想而知。

更有傳言，個別程序員因爲此事被用來祭天。

當事人的迴應

由於事態持續發酵，昨天下午，在Antd開源庫中加入這些彩蛋代碼的工程師偏右在知乎上對此事做出了迴應：

Ant Design 聖誕彩蛋起源自 2018 年 9 月 10 日我的一次提交：https://github.com/ant-design/ant-design/commit/00aebeb9756afecc884ad48486084836b9a2707a

代碼實現會在 12 月 25 日當天給所有按鈕添加積雪效果，並增加 Ho Ho Ho! 的瀏覽器默認提示信息。這完全是我個人的一意孤行且愚蠢的決定，是我的錯誤給大家造成了不良影響，非常抱歉。

同時，他還給出了修復這個問題的方案：

目前聖誕節彩蛋影響的Antd版本包括：3.9.3、3.10.0~3.10.9、3.11.0~3.11.5

爲此，Antd團隊發佈了修訂版本：3.9.4、3.10.10、3.11.6，相關用戶只需更新至相應的版本即可，使用了語義化版本的直接重新安裝 node_modules 並重新下載即可。

螞蟻前端負責人玉伯也在知乎迴應（摘錄）：

這件事確認是由我們在代碼中預埋的彩蛋導致，現在明確認定這一舉動是錯誤的。

這個彩蛋有多麼欠妥我們不再贅述，對大家造成的各種影響，antd 開發團隊致以誠摯的歉意。感謝所有熱心用戶提出的批評指正，感謝你們的中肯建議。

開源得益於大家的信任，我們會立刻開展覆盤並深刻吸取這次教訓，並重新 review 代碼更新評審機制。後續 antd 代碼庫裏不會再加入與功能無關的代碼，請大家持續監督。

不過，關於後續處理等，InfoQ聯繫了螞蟻金服相關人士，他們不願公開。

如何看待開源項目的責任

如今的開源，早已不是自由軟件時代的理想主義。很多公司都參與到開源中來，它們的動機，除了一些回饋社區和分享精神外，還摻雜着商業和利益上的考量，其中包括：

• 通過領導關鍵開源項目，成爲某行業事實標準，從標準中獲取利益；
• 開源核心代碼，基於核心代碼提供付費的諮詢和外包、資源服務；
• 通過開源項目，提升團隊成員的技術能力和凝聚力，打造技術品牌，方便對外做技術招募。

不過，在遍地商業化的開源裏，前端的開源又有其特殊性，因爲前端的技術很難直接帶來利益，上面的三種好處裏，最多佔第三條。

這導致前端開源有一定的隨意性，之前在前端開源領域也發生過人爲原因的影響非常大的惡意事件：

• left-pad事件：作爲很多項目的依賴的作者基於個人原因將項目從NPM包管理器中刪除，導致很多項目和網站無法正常工作；
• event-stream事件：一個令人尊敬的開源作者因爲項目衆多缺人維護，將項目權限轉送他人後竟然被植入比特幣錢包後門。

前端開源代碼缺乏商業化元素，讓一部分人認爲隨意修改代碼並沒有責任，對於一些個人的小型項目來說這麼說並沒有錯。antd的修改本身並不會帶來直接損害，但在宗教性節日在生產環境做無法下線的“彩蛋”，顯然欠缺考慮，並帶來一系列的間接損害。

而且，antd在宣傳時自稱爲企業級開源項目，這樣隨意修改代碼顯然與企業級的承諾相違背。同時，antd是公司級的開源項目，這樣欠缺考慮的修改也損害了背後公司在開源上負責任的形象。最後，能力越大，責任也越大，antd作爲很多項目的底層依賴，在做功能修改後未告知用戶，在用戶發現後沒有迅速解決問題而是用不當言辭繼續激怒用戶。

這些纔是我們對於antd批評的主要原因。

怎麼避免類似事件再次發生？

從antd的issue區可以看到，事件在很短時間內就演變成一場狂歡，這其中固然有因爲當事人在Github上的迴應不當導致事件失控的原因，也不乏一些人帶節奏或者借題發揮，這顯然已經超出了界限。在這裏，我們也呼籲讀者不要參與，不要傳播那些惡意段子圖。

現在，我們應該思考的，是怎麼避免類似事件再次發生。

經過此次事件後，想必國內公司在操作開源項目時會更加謹慎。對於底層依賴型的代碼，我們要儘量保持穩定，不要隨意修改代碼。

其次，在修改導致任何功能變化的代碼後，一定要在changelog裏體現出來，這纔是負責任的做法。

最後，完善開源項目的管理流程，要有人能夠把關代碼，不讓一些欠缺考慮的代碼合併到主線。如果真想做好開源，這些是必須要做到的。

對於開源項目的用戶來說，要跟蹤所有依賴代碼的所有更改顯然是不太可能做到的，這就要求在技術選型時要慎之又慎，在不同的場景選擇不同的技術，在面對嚴肅的場景時，一定要選擇成熟/穩定/可靠的技術，這也能從一定程度上避免問題。在面向年輕用戶時，選擇更新潮的技術，這樣即使出現問題也有更高的容忍度。

InfoQ的讀者們，你們認爲要如何杜絕類似事件再次發生呢？