阿里開源項目 Ant Design 錯了嗎！

科技 12-28

引：

Ant Design 今天（12月25）的聖誕門鬧得沸沸揚揚，Ant Design 內建的聖誕彩蛋在各個使用 antd 的產品中被「強制」彈出，令許多人措手不及，造成了很大的社會影響。但事實上，Ant Design 使用的是 MIT LICENSE，完全是一個使用者「後果自負」的協議。然而，Issue 里哭天喊地要開發者「負責」的輿論卻又一面倒。

在此，我要問一個問題：「Ant Design 錯了嗎？」

就我來看，毋庸置疑，錯了。

但這篇文章討論的是以下幾點：

1.Ant Design 犯了什麼錯？

2.開源的權利與責任的界限在哪裡？

3.我們應當怎麼從這個事件中獲取教訓？

1.Ant Design 犯了什麼錯？

從產品的角度來看，這個彩蛋，連彩蛋的定義都不符合。彩蛋（Easter Eggs）是一個隱藏在程序中的信息，而不是突然糊在你臉上的定時炸彈。所以從想出這個問題的那個人就已經不太對勁了。但我們拋開這個產品的問題，從實現上，這個文件也同樣是非常糟糕。作為一個組件級項目，很多人會對組件樣式做二次開發，這一坨硬編碼（Hardcoded）並沒有起到它彩蛋的作用，相反還把很多網站弄得一團糟。如果你試圖閱讀過 Ruby 的代碼，你往往會發現 Ruby 有那麼多錯誤命名的 C API 為什麼一直不把它改對呢？因為這種語言級別的東西，你無法確定用戶是怎麼使用的時候，就必須保持最低限度的兼容。Ant Design 也是如此。

然而「人主之患在莫之應，故曰：一手獨拍，雖疾無聲。」導致 Ant Design 問題的，不單單是彩蛋本身的錯，更大的是 Ant Design 開源社區開發流程的問題。或者換一句話說：是軟體工程的問題。

如果我們現在要往一個開源項目中加入一個不合適的東西，其實並不那麼容易。Ant Design 有基於 GitHub Pull Request 系統的 Code Review 機制。一個並非緊急的代碼，為什麼可以直接跳過 Code Review 直接推上去？Ant Design 作為一個組件級的基礎項目，到底應該怎麼設計測試？

這個 2017 年 12 月 25 日寫下的代碼，寫入到發作的這一年中，暴露的並不是誰的錯，而是這個項目本身就是一個錯誤。

2.如何運行一個開源項目？

Ant Design 錯了，需要檢討，需要反省，需要道歉。但另一方面，在 Issue 下大罵「要阿里負責，要阿里賠償」的則是走向了另一個極端。

今天的開源項目，在使用常見的 Copyleft 許可證的情況下，大多數（包含且不止包含MIT、BSD、GPLv2、GPLv3、AGPLv3、LGPLv3、MPL 2.0、Apache License 2.0、The Unlicensed）都在許可證中明確寫了，不包括任何保修的條款，使用者自行負責。這讓很多人聽起來匪夷所思，覺得 Ant Design 一個阿里的產品，怎麼也是阿里在背書。然而事實上，可能除了信譽，沒有規定任何東西是實質的背書。前幾天有人在 Ruby China 上開了個帖子問：

到某某網站上瀏覽時，發現上面說，以上版本均需獲取商業授權，方可做商業運營使用，既然是開源的，咋還涉及到商業授權啊，不理解，請指教。謝謝！

然而版權的實際情況卻恰恰相反。源代碼放出來只是讓你看，並不能讓你用。就像別人放在那裡的芒果，你不能尋思是別人不要了吧。代碼是不是開源，需要取決於使用什麼授權協議。哪怕是 GPL 的 RedHat 也有賣商業服務的。如果人家沒有設定任何授權協議的話，那就只能默認是 Copyright 私有了。而只有簽了具體包含保修責任的條款的協議後，對方才有保修的義務。不然，我自己寫著玩開源出來，你用的時候也已經同意免責了。你用出問題了為什麼要來找我呢？有問題你自己 fork 了改不就好了？

這就牽扯到了另一個問題：開源的社會價值。當一個開源產品，比如 Ant Design，有大量的用戶在使用的時候，對於這個開源社區的期待是完全不同的。這也是為什麼世界上大多數的大型開源項目，都有一個龐大的組織在維護著。其目的很大程度上，就是要維護代碼的可靠性，擔負起其社會價值。你覺得阿里價值觀能擔負起社會價值嗎？

有人在我微博下嗆：

照右邊這個邏輯的話，廣大 MIT 框架作者應該紛紛往自己代碼加挖礦，這世界不需要開源，人與人也不需要信任。別人寫好的高級語言也別用啊，一起彙編起來。

然而事實上，如果你願意找一下，GitHub 上許多 MIT 項目是有暗藏挖礦的，甚至還有暗藏後門的。至於「別人寫好的高級語言也別用啊」也是如此，UNIX 創始人 Ken Thompson 在 30 年前獲得圖靈獎的獲獎演說中，就有提到這種類似的暗藏在 C 語言編譯器中的手段實現攻擊。這也是為什麼一方面 C 語言編譯器也有一套複雜的自舉發布流程，像 gcc 還會有嚴格的代碼審查機制來避免這種問題的發生。然而甚至硬體本身，也不是 100% 可信的。這不是「人與人的信任」問題，相反，就算 100% 相信別人不去做壞事，但是由於人都會犯錯，總會做出錯誤的東西，我們需要的是通過機制來避免它發生。

在以前一個非常有名的 NVIDIA 開源驅動的維護項目 bumblebee 中就有出現過開發者疏失，導致更新的用戶直接把所有的用戶文件不小心刪了個精光。甚至有人曾試圖通過給 Linux 項目提交 patch 的形式，將後門埋入操作系統中。並且這些看起來不經意的錯誤，甚至會使得一些人為的 Code Review 失效，所以 Linux 還有複雜的安全性和回歸測試來保證其可靠性。

如果這不是無意的行為，而是有意的。那麼對於開源世界，我們有個更簡單的方法：fork。我們只要分叉一個自己的版本，自己維護自己負責就可以了。MySQL 被 Oracle 收購後，雖然 Oracle 暫時還沒有做什麼壞事，大家為了謹防這種情況發生，就有一些開發者 fork 出了 MariaDB。

但是，我也反過來問一句：你 fork 後的項目，你真的能維護得更好嗎？

軟體工程是一個複雜而龐大的東西，把七個積木搭在一起，和把七千萬塊積木堆在一起是完全不同的系統工程問題。開源軟體的管理看起來鬆散，於是更需要設計合理的制度防範於未然。在挑選開源項目的時候，並不只是挑一個能用的就行了，對於其質量、維護能力、開源協議都必須是評估的內容。我不是在說「用開源的東西不審查代碼，出了問題活該」，但是什麼都不看，不出問題才奇怪吧？

3.教訓

為什麼包括谷歌微軟在內的大公司，在使用別人的開源項目時，都要經過內部審查。雖然不至於精確到每行代碼，但也要大致確認一下這個項目的狀況。這也是為什麼，Facebook 之前內部許可證事件沸沸揚揚，因為這真的很重要。就好像，警察在努力阻止盜竊案的發生，但我們自身平時就要做好防範，而不能大門敞開，出了事去罵警察吧。

然而現實的情況卻是，用 Ant Design 的本來就是一群想用個組件庫草草了事的人，根本沒有可能去參與到開源項目的審查中。而 Ant Design 目前草率的開發流程，確實也無法承擔如此大的社會責任。如果今天不是「偏右」的聖誕節代碼出了問題，明天後天一樣會出別的問題。如果今天是「偏右」辭退就來平息風波，那麼明天後天 Ant Design 還是會繼續出問題（畢竟是阿里嘛）。

今天 Ant Design 的問題是一個典型的軟體工程問題，讓任何一個個人來負責，都只是息事寧人的策略，並不能從根本上解決問題。對於一個「開發公司 HR 工具的離職談話功能推到開發者頭上；匿名表達對老員工，特別是對彭姓員工不滿，大老闆可能含沙射影地讓你滾；用腳本在公司網站搶月餅，可能違反價值觀」的公司，你指望它在軟體工程上有秩序嗎？

我覺得你在做夢。

總結一下：

1、開源項目本身並沒有所謂的「責任」的概念，你要有自己評估其可靠性的能力，並承擔風險。

2、評估可靠性不在於其背後是多大的公司，更在於其是否有健全的開發流程，因為人為疏失不可避免。

3、越是底層、組件級的項目對於可靠性的要求越高。

4、只要不是主觀上故意犯錯誤，我們更應該檢討我們的系統工程，而不單單是檢討個人。

來源：