作者 | Denis Pushkarev

译者 | 核子可乐

策划 | 刘燕

大家好，我是 @zloirock （Denis Pushkarev），一名全职开源开发者。

其实我不爱写长文，这篇文章原本只想聊聊 core-js 的后续主要版本和发展路线图。但受到近期一系列事件的影响，这篇文章变得这么长。

我就直说了……我烦透了，免费开源软件的根基已经崩塌了。其实我可以直接转身离去，但面对这片自己曾经倾注了热情的社区，我还是想最后说点什么。

Core-js 项目前景

Core-js 是什么？

它是 JavaScript 标准库中最流行也最常用的 polyfill，为最新的 ECMAScript 标准和提案提供支持，包括古老的 ES5 功能到迭代器助手等前沿选项；就连与 ECMAScript 密切相关的 structureClone 等 Web 平台功能也离不开它的协助。

它是目前最复杂也最全面的 polyfill 项目。截至本文撰稿时，core-js 包含约 5000 个复杂度各异且彼此协同的 polyfill 模块 — 包括 Object.hasOwn、Array.prototype.at 到 URL、Promise 和 Symbol 等等。虽然在其它架构中，大家也可以把各模块作为单独的包来使用，但总归不如 core-js 这么方便。

它高度强调模块化——大家可以轻松、甚至自动选择只加载要用到的功能，而且 core-js 能在不污染全局命名空间的前提下起效（有人称这类用例为「ponyfill」）。

它在设计上充分考虑到了工具集成需求，并提供所需的一切支持——@babel/preset-env、@babel/transform-runtime 以及基于 core-js 的类 SWC 功能等。

就是因为有了 core-js，开发人员多年以来才能随意使用现代 ECMAScript 功能，只是大多数人并不知道背后的功臣就是它。 因为 core-js 在间接起效，所以用起来让人感觉支持是由转译器 / 框架 / 中间包（例如 babel-polyfill 等）实现的。

Core-js 并不是框架或者库，所以开发者不用了解相应的 API 或者说明文档就能享受它的好处。即使是直接使用，开发者也只需要导入某些行或者配置，之后就可以撒手不管了。深藏身与名的 core-js 会默默提供 Web 标准中的各类功能，包括开发工作中必不可少的各种 JS 标准库功能。

Core-js 的月均 NPM 下载量为 2.5 亿次，总下载量高达 90 亿次，1900 万次 GitHub 仓库依赖 — 这些都是相当惊人的数字。但这仍不足够概括 core-js 的真正热度。

我写了个简单的脚本，用来检查 Alexa 热门网站列表中 core-js 的使用情况。可以看到，这里包含的都是最明确的 core-js 用例和相应版本（仅限较新的几个版本）。

目前，在对全球 TOP 1000 网站进行统计后，脚本发现有 52% 的测试对象在使用 core-js。根据月度波动，实际结果可能会有几个百分点的变化。但这还只是使用现代浏览器在初始页面上进行的粗糙检测，有很多用例没有被真正纳入统计。人工检查后，数字还能再增加百分之几十。例如，以上截图中有很多公司的初始页面中包含 core-js 但却被我这脚本给漏掉了，例如：

在手动检查之后，前百大网站中有 75 到 80 个中包含 core-js，而脚本给出的数字则只有 55 到 60 个。把样本量进一步放大，统计缺失也会更加严重。

Wappalyzer 可以使用浏览器插件来检测技术使用情况，也包括 core-js。之前我做过测试，但现在他们的网站只提供约 500 万条公开结果。从现在的 Wappalyzer 来看，core-js 在 800 万个移动页面和 500 万个桌面页面当中，分别占比 41% 和 44%。而根据 Built With 的调查，core-js 在 TOP 10000 站点中的覆盖率为 54%。同样的，我并不确定这两项检查是否完整。

总而言之，我们可以自信地说，大多数流行网站都在使用 core-js。对部分大公司，即使他们的主站点上没用 core-js，它的身影也一定存在于某些项目当中。

那网站上普及度最高的 JS 库是什么？答案既不是 React 或者 Lodash，也不是其他备受关注的库或框架，而是“已显陈旧”的 jQuery。

而且 core-js 负责支持的不只是网站前端，同时也被广泛应用在一切跟 JavaScript 有关的场景下。

但因为不显山、不露水，几乎没人意识到自己正在使用 core-js。我为什么要强调这一点？这可不是想邀功，而是向大家证明目前的开源生态有多恶劣。

从一张流行图说起

起源

2012 年，我开始把自己的开发堆栈转为全栈 JavaScript。那时候的 JS 还太过原始，IE 也仍是市场上份额最高的浏览器。ES3 时代的浏览器拥有不小的比例，最新的 Node.js 刚刚来到 0.7 版。必须承认，这时的 JS 还不适合编写严肃应用程序，开发人员需要使用 CoffeeScript 等语言的编译器解决 JS 在语法、标准库和 Underscore 等库的缺失问题。当然，这些慢慢都成了历史，关注未来的我决定全面拥抱即将发布的 ECMAScript 6 标准。

但陈旧的 JS 引擎太流行了，加上用户并不急于忙着更新换代，所以即使在实质上已经没有任何采用门槛，ECMAScript 在之后的很多年里也仍然依赖于 JS 引擎。但我们也可以尝试借助某些工具，挖掘出 ECMAScript 标准中的支持特性。那时候，解决语法问题还得靠转译器，标准库问题则依赖 polyfill。而各种现在大家离不开的工具包当时也才刚刚出现。

在此期间，ECMAScript 转译器大行其道并蓬勃发展。但与此同时，polyfill 则没能跟上用户和项目的实际需求。它们缺乏模块化特性，必须得污染全局命名空间才能正常起效，所以并不适合搭配库来使用。虽然选择由不同作者编写的 polyfill 库并搭配使用并不算特别复杂，但在很多场景下仍然阻碍重重。总之，其中缺少大量必要的基本语言功能。

为了解决这些问题，我从 2012 年开始为自己的项目开发起了解决方案，这就是后来的 core-js。我希望能让所有 JS 开发者工作起来更省心，所以在 2014 年 11 月，我把 core-js 发布为开源项目。而这，也许是我一生中最大的错误。

我显然不是唯一受语言功能缺失困扰的开发者，所以短短几个月后，core-js 就成了 JS 标准库实现 polyfill 的最优选项。当时的 core-js 被集成至 Babel 当中，而 Babel（当时还叫 6to5）的诞生比 core-js 只早几个月。

之前提到的问题同样困扰着这个年轻的项目。经历了更名，core-js 开始以 -babel-polyfill 的名义接受贡献。经过几个月的合作，出现了另外一款工具，并最终深化成了 bael-runtime。又过了几个月，core-js 被整合进核心框架当中。

为整个 Web 提供兼容性保障

我犯的第二个错误，就是没有认真推销自己或者项目。

Core-js 没有网站或者媒体账户，只有 GitHub 代码仓库。我没在开源会议上搞宣传，甚至连帖子都很少发。我只想做个既实用、又能支持现代开发堆栈的工具，这样就挺好。在它的帮助下，开发人员能够享受到最现代、最实用的 JS 功能，不用再坐等这一切被缓缓纳入 JS 引擎。另外，core-js 也消除了兼容性和 bug 隐患，于是项目开始广泛传播，很快得到几十个流行网站的采用。

但这还仅仅只是开始。

接下来就是持续多年的艰苦工作，我每天都要花几个小时来维护 core-js 和相关项目（主要是 Babel 和 compat-table）。

Core-js 绝不是那种写完之后就万事大吉的小库。 跟绝大多数库不同，它会受到 Web 状态的约束，需要对 JS 标准或提案中的变更、新的 JS 引擎版本、JS 引擎中的 bug 检测等做出反应。

于是乎，ECMAScript 2015 发布新提案、ECMAScript 推出新版本、新的非 ECMAScript Web 标准 / 引擎 / 工具等出现之后，core-js 也一直在随之变化。项目的演进、改造和对 Web 现状的适应从未停止，而普通用户几乎完全感受不到这一切。

只有工作规模在不断扩大，不断扩大……

长久以来，我一直在用各种方式寻找其他维护者，至少能找几位持续贡献者也行。但所有尝试，无一例外全部失败。

几乎每位 JS 开发者都间接用到过 core-js，也知道 babel-polyfill、babel-runtime 或者框架 polyfill 的各种功能，但却没人听说过 core-js。在部分关于 polyfill 的帖子里倒是提到过 core-js，但用的表述是“一个小库”。

反正 core-js 没啥人气、也没啥讨论热度，既然它就在那静悄悄地干活呢，何必要费劲去帮忙维护？随着时间推移，我终于对整个社区绝望了，剩下就完全是凭着一股责任感继续独自工作。

几年之后，我发现全职做开源开发已经彻底没戏了——既没人愿意向开源贡献者付钱，也没多少人愿意拿出业余时间参与其中。

但我没办法，有时候 core-js 会整整耗上我几个礼拜的时间，但为了让社区能继续有强大的 polyfill 可用，我只能把经济问题先放在一边。

这就是我，不仅辞去了原本的高薪工作，后来还拒绝了好几份相当诱人的邀约。因为一旦接受，我知道自己就再没精力从事开源工作了。这就是我的全职开源生存状态，没有任何人愿意掏钱支持。

我其实还抱有一点期待，希望早晚能找到一份可以全身心投入的开源 Web 标准工作。为了撑起开源开发和日常工作，我只能定期找几份短工。

我回到了俄罗斯，这边生活成本比较低，所以我对收入的容忍度也就更强了。但这又是另一个错误——钱很重要，我稍后会具体向大家解释。

到 2019 年 4 月，我已经参与 core-js 项目一年半了，全职做开源也有半年左右。我心无旁骛地开发 core-js@3，对 polyfill 相关的 Babel 工具做了全方位改进，让它真正成为几乎无处不在的重要工具包。

意外终于来了

在 core-js@3 发布的三周之后，我遇上了重大变故。

那是四月的一个晚上，我凌晨 3 点开车回家，路上遇到两个喝得烂醉、穿着深色衣服的年轻女孩，她们当时正摇摇晃晃穿过一条昏暗的高速公路。我撞上了她们，后面的事情记不太清楚了。

有目击者说其中一个直接躺在车底，另一个在使劲想把她拽出来。虽然证人证明之前这两个人确实是在高速路上打闹，但这里是俄罗斯，只要你不是那种达官显贵的子女，那撞人者几乎必然要被判有罪。

行人是弱势群体，开车的人有责任注意路况。这就是我，一瞬间被打落谷底的普通人……检察官最终要求入狱 7 年，或者用钱跟“受害者”私下和解。事故之后又过了几周，我收到了“受害者”亲属给出的条件，按当时汇率计算赔款是 8 万美元。这还不算聘请律师的费用。

其实对于优秀的软件工程师来说，8 万美元也不能算是特别大的一笔钱。但那段时间，我一直埋头于 core-js@3 的发布，期间不光没人付钱给我，反倒把我之前的积蓄给掏空了。 所以我拿不出那么多钱，也想不到能从哪里快速筹钱。我的时间不多了。

求助于开源社区

当时，core-js 已经全面铺开。虽然我一直没能给 core-js 找到贡献者，但这毕竟是个需要主动维护的项目，不能一直停留在原地。一旦入狱，不光我自己完蛋了，core-js 也会成为那么多用户的大麻烦。那可是世界上一半的网站，必须重视起来。

在之前几个月，我曾经尝试筹集资金来支持 core-js 的开发（主要是在 GitHub 和 NPM 上发布了 README）。结果是……每月进账 57 美元。是的，这就是开源社区愿意给一位保障网络兼容性的全职开发者开出的报酬

我决定做个小实验——向 core-js 用户直接求助，就是那些在 core-js 失去维护后会受到影响的人们。我在 core-js 安装上添加了这样一条消息：

我知道自己很难通过捐款获得全部资金，但每一块钱对我都很重要。我还发了一条求职消息，希望能通过工资消化掉一部分。我在 NPM 安装日志里也写了求助信息，大家不爱看可以隐藏，为 core-js 付出这么一点点代价不算过分吧？我本来以为，有几周时间事情就会有转机，但事实再次证明我根本就不懂人性……

换来的只有恶言恶语

我知道肯定有人不想看这条求助信息，但没想到这却成了舆论的主流。一天之内，几百条消息、帖子和评论直冲我的天灵盖，千言万语汇成一句：让这个弱智 zloirock 和他的 core-js 滚蛋！

比这激烈的言语还很多，但这里就不多说了。我的生活已经是一团糟，何必再纠结于这些让人心烦的东西。

开发人员之所以喜欢用免费开源软件，就是因为它们既不要求、效果又好。 他们对这些软件是怎么来的、耗费了多少精神根本不感兴趣，也不关心背后贡献者自己的问题和需求。他们觉得在自己用惯了的产品里添加信息，是对其用户空间的侵犯，甚至是对他们的侮辱 。对他们来说，开源社区应该是台精密而且任劳任怨的机器——只管干活，不要出声。

所以成千上万的开发者开始辱骂我，声称我无权向他们寻求帮助。我的求助信息激怒了他们，甚至导致他们要求限制我对代码仓库和软件包的访问，最好把权限直接移交给他人。很明显，他们几乎没人了解 core-js 的作用、项目的规模，也没人愿意真的站出来接过维护的重任。“该有人为社区做点什么了”，但绝对不能是他们自己。看到这一切，我觉得不能被他们牵着鼻子走，反而决定长期保留这些求助信息。

肯定有公司在 core-js 的帮助下赚了钱吧，比如那些大企业？但他们的脑回路其实是这样的：

公司：“我们想用 SQL Server Enterprise。”

微软：“一次性支付 25 万美元，之后每月 2 万美元。”

公司：“没问题！”

...

公司：“我们想用 core-js。”

core-js：“好啊，npm I core-js 就行。”

公司：“爽！”

core-js：“你们愿意在经济上提供点支持吗？”

公司：“哈哈，没门。”

几个月后，因为受不了用户的抱怨，NPM 启动了 npm fund——这可不是真想解决问题，只是为了安抚人心。大家扪心自问，你多久会用一次 npm fund？你身边有人向 npm fund 捐过款吗？你见过有人愿意向我这样的库维护者伸出援手吗？不仅没有，这还给 NPM 后面的一系列神奇操作埋好了伏笔。

前后过了 9 个月，成千上万的开发者，包括那些高度依赖于 core-js 的项目开发人员，都了解到我的困境。但没人愿意帮忙，连接替我做维护都不行。 几个月内，我跟一些依赖 core-js 的重要项目的维护者沟通过，但没有任何进展——他们不想浪费这个时间。因此，我只能求助于几位跟开源没有任何关系的朋友，至少大家想想办法让我免除牢狱之灾。

期间其实是有几位用户和几家小公司帮助过 core-js 的，我要感谢他们。但 9 个月过去，我只勉强筹集到预期捐款的四分之一。

虽然骂声不断，但 core-js 的单日下载量在这段时间几乎翻了一番。

2020 年 1 月，我锒铛入狱。

提前释放

我不想回忆在监狱里的那段时光了，总之我参加了劳动改造、身体健康受到严重破坏，身边不是毒贩、小偷就是杀手。当然，我上不了网，连台电脑都摸不着。

大概 10 个月后，我就被提前释放了。

出狱之后，我看过几十篇文章、几百条帖子和上千条评论，内容基本可以总结为这样一句话：

这混蛋简直是最烂的维护者，在整个 GitHub 上简直绝无仅有。不知道他是怎么进去的，但我觉得他活该。

其实我也看到有人支持 core-js 的开发，提了问题、意见还发了私信，只是不像负面消息那么多。现在 core-js 更流行了，流行到超乎我的想象。

再次为 Web 的兼容性而战

我像以前一样回归了 core-js 维护岗位，但不再对靠这个项目找份固定工作抱任何期望。

Core-js 在资助平台上得到了一点支持，但不多，还不到开发 core-js 之前那个岗位的几分之一。但我就是一个人生活，所以基本够用。我愿意用困乏的生活换取全职搞开源……我不再考虑那数额庞大的诉讼费，不考虑自己的未来，我只关心 Web 能不能平稳走下去。当然，我希望有公司能给我个岗位，让我有机会直接参与 Web 标准方面的工作，能给 polyfill 和开源开发一点赞助就更好了。但也只是想想，不当真。

之后的两年间，项目取得了不少成果，但基本还是顺着之前的老路在走。我维护的仍然是 core-js@3，可它确实变得更好了。大家也能猜到，这些工作还是藏在幕后，普通用户根本接触不到。

基础性工作就是这样，整天跟标准和提案打交道，唯一能抚慰人心的就是自己的很多建议被写进了 ECMAScript 提案。但这不是我个人的成就，更多是拥护者和用户们的成就。我需要面对各种引擎，通过 bug 跟踪器找问题，在成百上千的环境 / 构建 / 测试套件组合中不断自动加手动测试，确保标准库能随处正常运行并收集兼容数据。通过一套几天内开发的设计原型，core-js 兼容数据终于能在内外部工具的支持下快速转化为详尽数据集。我还得设计各种项目内尚未出现的功能和原型，诸如此类。

前面已经提到，core-js 在大部分流行网站中广泛存在，提供了一套几乎完整的 JavaScript 标准库，并修复了各种错误实现。用 core-js 打开网页的次数，甚至大于 Safari 与 Firefox 打开网页的次数。所以从某个角度来看，core-js 可以说是最流行的 JavaScript 运行时之一。

维护 core-js 期间，我几乎成了所有现代和未来 JS 标准库功能的首个实现者，几乎所有功能中都有我的反馈和相应修复。Core-js 成为试验 ECMAScript 各类提案的最佳平台。一次又一次，用户们是在体验过 core-js 的提案实现之后，才对原始提案做出反馈。

JavaScript 的理想发展方式，就是让 TC39 与 core-js 继续为它保驾护航。例如，TC39 会邀请 Babel 等项目成员作为专家，但 core-js 明显得不到这样的重视。相反，我个人或者 core-js 这边提出的问题常常被忽略，甚至 TC39 的成员会公开给我使绊子：

现在最大的麻烦，就是怎么阻止 core-js 作者掺和进来。

过了一段时间，NPM 那边决定“支持”。在 2020 年底，作为 npm fund 继任者的 npm@7 中，安装后脚本将无法在控制台上输出信息。于是乎，人们看不到我的求助内容了，再加上大家感受不到自己在使用 core-js，所以支持者的数量开始下降。真正得益的，只有直接使用我的成果来开发具体项目的人们。

另外，还有一个重要因素。虽然资助额下滑，但 core-js 的质量却更高了。Core-js 库维护得怎么样？几乎没有公开报告的 bug，即使出现也几乎会被立即修复。库已经给了大家所需要的几乎一切，那还何必继续捐钱支持呢？毕竟在多数人看来，这不过是个“小库”，所以许多之前支持过 core-js 都慢慢停止了。

Core-js 代码中其实有我的版权。文章开头提到，目前约有半数网站在用它，经常有人在有害站点 / 应用程序的源代码中看到它，只是不知道这个“core-js”究竟是什么。后来警察曾给我打过电话，甚至有人据此敲诈勒索。这个过程很痛苦，真的。

美国和加拿大的记者曾多次联系我，因为他们在美国各大新闻和政府网站上发现了 core-js。抱着搞个大新闻的心态，他们在发现我并不是想象中那种“干预美国选举的邪恶俄罗斯黑客”后，毫不掩饰自己的失望之情。

随着时间推移，网上对我的谩骂倒是少多了，但也还是有。只是其中大部分不再通过 GitHub 问题或者 Twitter 帖子，而是直接给我发邮件或私信。前几天，就有开发人员给我发了条私信，说我是开发者社区里的寄生虫，赚了很多钱却啥也不管。他甚至把我描绘成那种靠收买法官而逍遥法外的杀人犯。他诅咒我本人和我全家。其实这也没啥，每个月我都会收到好几条类似的消息。毕竟去年，就有人说我是“来自俄罗斯的法西斯分子”了。

你觉得，core-js 一个月能帮我赚多少钱？

我在全职维护 core-js 期间，不算其他短工项目的收入，我每个月的回报大概是 2500 美元——只相当于我能找到的其他全职岗位的四分之一到五分之一。

但我愿意接受这一切，因为这能让 Web 变得更好。而且我觉得这一切只是暂时的，等问题和 bug 减少了，等产品的质量达到一定高度，咱这项目肯定能得到重视，对吧……对吗？

几个月后，月均收入减少到大约 1700 美元——其中 Tidelift 那边有 1000 美元，Open Collective 有 600 美元，Patreon 大概是 100 美元。除了这笔固定收入，还会有些比较稳定的一次性捐款，平均下来每月还有 100 美元吧。

至于加密货币，这倒是个挺时髦的通道。但自始至终，我的加密钱包只收到过 2 笔转账，总金额是 200 美元，上次收钱还是在一年多以前。GitHub 赞助者？这里可是俄罗斯，没这回事的。PayPal？俄罗斯人用不了 PayPal。但就算之前在国外，core-js 在这边的收益也就收到过大概 60 美元。开源补贴我也申请过很多次，但完全没有回音。

Bower 那边的每月捐款大概有 400 美元，这是另一个开源社区。我很感谢各位支持者，因为你们的捐赠，我才能在 core-js 上继续坚持下来。

但可以看到，这里没有任何一家大公司，也没有来自前 1000 名网站列表的企业。老实讲，目前的支持者主要是个人，还有几家小公司，每月付给我几美元。

但千万别说他们不知道我缺钱，我在网上看到过好多类似的图了：

一年前，Tidelift 不再给我发钱。他们说受政治局势影响，他们使用的 Hyperwallet 不再支持俄区（但我之前试过，只要改一下个人设置就能使用，直到上个月才彻底被封禁）。为了安全起见，他们会暂时把钱存起来。之前几个月中，我试着把这笔钱转进银行卡或者 Hyperwallet 账户，但对方只是回复说他们会尽量帮忙。到去年年底，他们干脆连邮件都不回了。现在我收到的结果如下：

“您在 Hyperwallet 的账户已被封禁，因此我们无法支付。我们将立即中止您的转账协议。若您的 Hyperwallet 账户解封，请立即联系我们。”

好笑的是，我之前一年的钱就这么没了。所以从今年起，我的月收入不是 1800 美元，而是只有 800 美元了。 虽然他们不回我的邮件，但通过网站查询，我发现那边仍然在收捐赠者们发给我的钱。

不知道如果同样的状况发生在其他用户身上，大家会做何反应。

另外，我从 OpenCollective 上收到的每月资金从 600 美元减少到了 300 美元左右。很明显，Bower 的财政储备快断了，所以这个月我总共能拿到大约 400 美元。

之前几个月，我衡量了一下自己在 core-js 上投入的时间。事实证明，每月大约是 250 个小时，相当于是一天都没休息。没有任何一份正经的全职工作会是这个样子。250 小时，换来 400 美元……每小时折合不到 2 美元。哪怕是在情况稍好的去年，时薪也就是 4 美元上下。虽然我有时候会缩短自己花在项目上的时间，但波动不会很大。

我仍然愿意为保障整个 Web 的兼容性承受这一切，包括没有福利、没有保险。

搞开发的，肯定不缺钱、不缺 offer 吧？

没错，各大 IT 巨头的高级软件工程师岗位确实薪酬可观，我也收到过不少 offer。但是，这些选择都会影响到我对 core-js 的维护和贡献。

除了常见的威胁、指责、要求和侮辱，我还经常听到类似“别搁这要饭了，找个班上”之类的话语。有趣的是，他们中有很多人年收入超过 30 万美元（我跟他们的同事交流过，所以这点属实），而 core-js 的存在大大降低了他们日常工作的难度。

一切都变了

当初为 core-js 奉献一切的时候，我是一个人。但现在我有了家庭，一年前儿子也出生了。现在，我得为他的生活和发展考虑。

我妻子有时候也会想要一双新鞋、想要个包，想买部 iPhone 或者一块 Apple Watch。我的父母年纪也大了，在经济上需要我的支持。

很明显，指望继续维护 core-js 来满足这些需求根本就不可能。我的储备金确实顶了一阵子，但现在也用完了。

很多人指责我“别再开源社区混了，这是自我放弃。好好找个班上吧。某某才干了一年开发，技术根本就不行，但挣的已经是你的好几倍了。”

所以我真的受够了。我喜欢开源，喜欢维护 core-js。但我到底为什么要坚持，为了谁在坚持？

请允许我做个小总结：

我保证没有兼容性问题，并从 2014 年起为大多数 Web 提供各平台上的前沿功能。我几乎把所有时间都投入了进来，但现在连吃饭都成问题。我没看到任何感激和致谢，反而被恶言恶语持续痛击……我的工作不是让他们的生活更美好了吗？通过使用 core-js 节约并赚取几百万美元的公司，对 core-js 的资金需求完全熟视无睹。即使是在我最危急的情况下，人们对我的求助仍然冷漠以对，甚至落井下石。我不但没机会跟参与 Web 标准和浏览器开发的同行们一起改善 JavaScript，反而成了他们的眼中钉。

其实对负面言论，我已经心如止水，否则我早就离开开源社区了。

我可以容忍标准制定者对我的忽视，毕竟我的贡献对象首先是用户，之后才是 Web 崩溃时影响到标准开发者。

但钱很重要，钱可太重要了。我受够了以牺牲自己和家人生活品质的方式白做贡献。我要保护我的家人，让我的孩子能过上幸福的生活。

Core-js 上的工作几乎占用了我所有的时间，比全职岗位还多。 它保障了大多数流行网站的正常运行，这项工作也值得一份适当的报酬。我不会再继续无偿，或者以每小时 2 美元的低薪工作了。对于现在的我，时薪至少要达到 80 美元。这个要求并不过分，eslint 团队成员一小时就赚这么多。如果开源项目需要，我也愿意付清诉讼费并离开俄罗斯——但我现在没钱。

我经常看到这样的评论：

这个项目每月都需要资助，否则就得不到维护、没有更新、修复不了 bug 和安全漏洞。这是个很好的项目，别让它就这么毁了。

未来方案

听你们的，下面我打算采取这样的方案。

根据反馈，core-js 接下来将选择以下发展思路之一：

适当的财务支持

希望读到这篇文章的企业、小公司和开发者能认真考虑现有开发堆栈的可持续性，并适当为 core-js 提供支持。有你们的帮助，core-js 将得到适当维护，我也能专注于添加更多新功能。

随着工作规模越来越大，我一个人肯定是不够的。有些工作，比如提高测试覆盖率、增加说明文档之类，虽然简单但却要耗费大量时间。所以我想用捐赠款至少招一到两位开发人员（最低是在校学生，有经验更好）。

考虑到额外的人手和其他费用，我觉得目前一个月 3 万美元就足够了。能有更多的钱当然好，可以让产品质量继续提升、开发进度再上个台阶。如果钱达不到，我也愿意继续一个人维护项目，但在效率上肯定没法跟团队相比。

我可能会去找份工作，从事开源和 Web 标准方面的工作。

这样我会存点钱，给后面的开源贡献积攒资本。

如果始终得不到用户的适当支持，core-js 将转为商业项目。

目前的 core-js 包没法做商业延展，所以后续的主要版本很可能会变更许可证。免费版将面临很大限制，一切额外功能都要收费。Core-js 还将保持发展，项目范围内会有更多新工具来保障 Web 兼容性。这种方式会大大缩小 core-js 的传播空间，也会给很多开发者带来问题。但即使能有一小部分转化成付费客户，都足够让我养家糊口了。

慢慢退出，让 core-js 自生自灭。

我其实认真规划过转为商业项目后的路线，也有不少理想的岗位选择，但这些都会大大消耗我的个人时间。当然，我不会立马完全停止对 core-js 的维护，但作为志愿者我能付出的时间肯定不如之前。按目前的工作选项推断，那我每月能参与维护的时间只有几个小时。这意味着 core-js 将不再发展，最多是修修小 bug 和更新一下兼容性数据。一段时间后，core-js 将逐渐失效并宣告死亡。

我仍然怀抱美好的愿望，希望大家能选择第一种方式。毕竟 core-js 已经成为现代数字基础设施中的关键组成部分之一，但从过往的经历来看，我也做好了走其他几条路的心理准备。谢谢大家。

原文链接：

本文转载来源：