说好的敬畏每一行代码呢？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 的读者们，你们认为要如何杜绝类似事件再次发生呢？