2022 年伊始，开源届炸开了锅，这边还在费尽心思尝试各种检测与修复方法减少 Log4j 2 漏洞带来的辐射；另一边却陡然发现，数千个开源库满屏乱码，无数程序员一觉睡醒后陷入沉思。
在寻找根源时发现，这些错乱的开源库有一个共同特点，就是使用了开源的 NPM 包 faker.js 和 colors.js，继续深挖后，让人十分诧异的是，导致重大 Bug 的背后是这两个流行的开源库被其作者 Marak Squires 删掉了源代码。
所谓“冲动是魔鬼”，就在 Marak 对 faker.js 和 colors.js 两个项目进行一系列注入恶意代码、删库等魔幻操作之后，作为代码托管平台 GitHub 为了维护“和平与正义”，直接封掉了 Marak 的账号。
然而，事情并没有结束，时隔十天后，Marak 似有些心酸也颇有后悔之意地询问起 GitHub：
@GitHub，这是怎么回事？十天前，你取消了我发布到 NPM 并修复 colors.js 中的 Infinity Zalgo bug 的能力。
从未回复我的支持电子邮件。
我有 100 多个需要维护的软件包。
每个人都会不时犯下「编程错误」。
没有人是完美的。
冲动的根源
Marak 的言下之意也并不难理解，“你封了我十天了，我还有好多项目要维护，希望能给我解封一下。”但是对于 Marak 将有意损坏“faker.js”和“colors.js”两个开源库的行为归纳为「编程错误」这一说法，很多开发者直言不可原谅，更不用说这一态度可以让 GitHub 会去回复他的邮件了。
毕竟，Marak 一时的冲动的后果不仅是让很多项目受到时间、成本损失，也间接地劝退不少想要进入开源领域的爱好者们。
回看事情经过，还是得从 color.js 和 faker.js 两个项目谈起。
在包管理器 NPM 上，colors 每周下载量超过 2000 万次，且有近 19000 个项目依赖它。同时，faker.js 在 NPM 上每周获得超过 280 万次下载，并拥有超过 2500 位贡献者。两者都是在开源领域颇受欢迎的项目。作为两个项目的开发者之一，Marak 常奋战于开源一线。
不过，之前突发的一场大火似乎将 Marak 逼入绝境，也烧灭了他对开源精神的信赖。CSDN 此前也曾发文梳理过：
2020 年 9 月，Marak 彼时租借的房子突发大火，所有财产几乎被全部烧毁，无奈之下 Marak 在推特上发布求助，“我在一场公寓火灾中失去了所有东西，几乎无家可归，也无法访问我的大部分账户，所有的贵金属都不见了。如果有人能给 paypal@marak.com 一点钱，那将帮助我免于在街上冻僵。”
在十天之后，或因生活“走投无路”，Marak 开始在 GitHub 上谴责大型公司使用其开源项目却不回馈的行为，并直言：“我不会再用我的免费工作来支持财富 500 强企业了（以及其他较小规模的公司）。没什么好说的。趁这个机会，你可以给我发一份年薪六位数的合同，或者分叉项目，让别人来做。”
即使如这样“张狂”的话，但也石沉大海，并没有引起太多人的注意。
最终在 2022 年 1 月 8 日，Marak 选择了“极端”的方式，其在 color.js 项目的 v1.4.44-liberty-2 版本中添加了一个“new American flag module”并将其发布至 GitHub 和 NPM。受污染的版本 1.4.1 和 1.4.2 也出现在 npm 上。
代码中引入了一段无限循环，让所有使用了 colors.js 的程序都会在控制台无休止地打印各种非 ASCII 字符，导致乱码。
同样，一个被破坏的 6.6.6 版本的 faker.js 也被发布到 GitHub 和 NPM 上。
Trick or treat
至此，Marak 删库的意图是想要让那些拿着开源软件实现商业项目的大厂团队尝到苦头，希望大厂能够反过来找自己帮他们解决问题。但是 Marak 却大大低估了此事的后果，在其恶意破坏代码并被 GitHub 封号后，Marak 就后悔了。他在 1 月 7 日发 Twitter 表示：
NPM 已恢复为 faker.js 包的先前版本，但是 GitHub 已暂停我对所有公共和私人项目的访问。我有 100 个项目。
在 1 月 15 日时，Marak 再次发声：
我已经在本地修复了 Zalgo 错误并准备好发布 colors v2.2.2。它已经准备好 3 天了，我仍然无法发布到 NPM。
几乎无人支持 Marak 想要恢复发行权的请求
截至目前，GitHub 虽然解封了 Marak 的账号，但是其发行权仍然被剥夺。与此同时，此前被破坏的 faker 项目也已经被社区接手，目前该项目团队共有 8 名工程师，另外，他们还创建为 faker 创建了一个官网：https://fakerjs.dev/。Marak 费尽心思想要的一切以及过往的付出宛如竹篮打水一场空。
如今，Marak 虽然想用“每个人都会不时犯下编程错误，没有人是完美的。”的说法将自己的错误翻篇，但是更多认为他已经损害了开源生态系统的信任原则：
@praash 表示：我真的很想知道，他为什么被 GitHub 封号？他实际上违反了哪些条款？如果他没有明目张胆地弄出这个 Bug 来宣告他的行为，现在他是否还会被封号？
我认为意图是完全无关的。我不喜欢他幼稚的态度，但我确实在这个新的、明显不诚实的关于编程错误的声明中找到了一个相当强烈的讽刺点。一味地“责备开发者”并不足以令人信服。
@Nextgrid：为什么这需要禁止呢？这是他的 GitHub 存储库，据我所知，只要不侵犯版权、非法或不当，您可以将任何您想要的东西放在那里。
ice_cold_etoh：在做有争议的事情之前，你应该做好承担后果的准备，或者你一开始就不做，就这么简单。
@93 Escort Wagon："每个人都会不时犯编程错误。没有人是完美的。”不，绝大多数程序员从不故意将恶意代码添加到他们的项目中。
个人开源开发者如何生存？
针对围绕网友争论的开源开发者是否获得报酬这一问题，CSDN 在《2020-2021 年中国开发者大调查》报告中做过调研，其中 77% 的受访者表示不曾在开源上获得收入。
Digital Ocean 也曾对来自北美、欧洲和亚太地区的 4,440 名开源开发者进行了调研，数据显示，超过一半的受访者认为参与者应该为开源项目做出贡献（54%），而大约三分之一的人未做出选择。只有 12% 的受访者反对向个人支付捐款。
关于谁应该得到报酬的问题，不同的受访者之间也产生了重大的分歧。35% 的人认为维护者应该得到报酬，30% 的人主张贡献者应该得到报酬，25% 的人认为项目作者应该得到报酬。
值得注意的还有，与一些年长的开发者相比，年轻一代的程序员更支持为开源贡献的人支付费用。60% 的 18-24 岁的受访者认为人们应该为他们对开源的贡献而提供报酬，其次 53% 的 25-34 岁的人、51% 的 35-44 岁的人、42% 的 45-54 岁的人以及 34% 55 岁以上的人同意这样的做法。
另外，当提及谁应该为这些报酬提供资金时，一半受访者认为科技公司应该为开源贡献者们提供资金，而四分之一的人认为项目使用者或个人应该支付。
事实上，Marak 恶意破坏代码等行为破坏了开源精神的根本，但是“没有收入来源，用爱发电”也是开源发展中亟需解决的一大难题。对此，你怎么看待或维系开源贡献与个人收入之间的平衡？
参考：https://open-source.developpez.com/actu/330360/Marak-l-auteur-de-la-recente-corruption-du-registre-de-logiciels-npm-faker-js-et-colors-js-affirme-qu-il-s-agissait-d-une-erreur-de-programmation-et-souhaite-que-Github-leve-son-bannissement/
https://twitter.com/marak/with_replies
《新程序员003》正式上市，50余位技术专家共同创作，云原生和数字化的开发者们的一本技术精选图书。内容既有发展趋势及方法论结构，华为、阿里、字节跳动、网易、快手、微软、亚马逊、英特尔、西门子、施耐德等30多家知名公司云原生和数字化一手实战经验！
