React项目实现企业开源的真义

对企业而言，发布和维护开源项目都是需要耗费大量心力的。在为 React（一款由 Facebook 开发的知名开源 JS 库）工作四年后我对此深有体会。我最开始只是一名外部贡献者，加入 React 团队后，又从工程师做起，最终升为团队管理。和大多数的 Facebook 开源项目一样，React 起初只是为内部使用而开发的，见识到它在简化 UI 代码的开发和维护上的作用后，我们决定将它与全世界分享。

事实证明，React 是 Facebook 的一次令人难以置信的成功，而这成功背后也隐藏了巨大的挑战。举例来说，尽管 React 非常受欢迎，但它仍处于一个竞争激烈的领域，这使得我们在开发新版本时需要小心再小心。

我们尽量不去做重大改动，原因很明显，人们没有时间或者不愿去适应一个变更太快的产品，甚至可能会一气之下改用其他竞品。但反过来想，如果我们固步自封，那么 React 将会落后于其他更新潮，更有创新性的产品。React 会像它的前辈们一样，被后浪拍死在沙滩上。

庞大的用户群体也让我们在做出任何决定时都会收到反对的声音。在你规模还很小的时候，你可以取悦任何人，一旦你规模做大，满足所有人就变成了不可能 的任务。这一现象并不仅局限于 OSS（开源软件）。这就意味着，在准备更新版本时，我们同样需要仔细考虑我们的沟通策略。在 2018 年 10 月的 React 大会上公布 React Hooks 之前，我们特意避免公开发表任何 React Hooks 的消息。这是因为我们担心在只有部分设计的情况下，可能会让用户错误理解我们的设计。于是我们在直到项目完善后才将它公布于世。一个项目越是受欢迎，就越难在不刺激到用户的情况下实验新想法。

当 React 还是个刚出生的小婴儿时，大多数的用户都是出于个人喜好选择了它。而在它几乎算是行业标准的现在，很多人用 React 是因为没得选，可能是因为团队中有人在用，也可能是授课教授选择了它，而这类用户往往都并不了解 React 的独特优势。因此，更多的新用户都会带着挑剔的眼光看待 React，期待着新的补丁出现。React 的用户群之大，相关文章之多，让新用户（有时甚至会有老用户）在找帮助时都摸不清楚哪些资源才是可信的。当然，所有资料的贡献者都是好心的，但这并不能保证这些资源都是高质量的。

很多公司都指望通过发布一个任何人都可贡献代码的开源软件来吃红利，但就据我所知，这种做法实际几乎从未成功过。回应问题，回答使用问题，仔细规划新版本发布的时间线，这些都要花时间来做。哪怕是代码贡献，这个被誉为能让企业开源的决策收获可观回报的大奖，也总是盛名难副。新的贡献者既不像核心团队一样对现有代码了如指掌，也不像他们那样对项目的远大愿景有着清晰的认知。外部贡献者的代码总要经过修改才能使用，即使是一些较为优秀的拉取请求也是要过几轮审查的，对审查者而言，你永远无法确定贡献者会不会更新，以及何时才会更新。这种情况下，通常还是自己写程序比较快。

此外，绝大多数的拉取请求都只是顺手做的贡献。某人在做某项目时，发现了他们正在使用的某开源工具的一个 bug 或者限制，于是他们提交一个小补丁，覆盖了他们所遇到的独特情况。通常这类的贡献者是不会做回头客的，而肯回来帮忙的都是好人。在帮忙的过程中，他们会逐渐了解你，了解你项目版本间的微妙差异，他们对项目的可靠性和长期的成功有了个人的投入。在 React 中，我们对新的贡献者总是很友善，希望他们或许会回来继续帮忙。但无论我们对他们有多么欢迎，鲜少有人会有精力或意愿继续贡献代码，这可以理解，每个人都有他们各自的生活，而有意义的贡献是需要花费时间的。

以上提及的困难点都是成功项目才会遇到的，但开源项目难免会失败。原因有很多，可能是这个项目解决的问题太过小众、不常见，或者是它针对的问题已经有了个更好的解决方案。开源项目的创建者也许无法证明自己项目的实用价值，或者是没有提供足够的文档，尤其是没有对新用户的指引。项目可能需要复杂的设置或者前置基础架构环境，也可能是用某种小众的编程语言写的，或者是由于其他技术原因导致了不兼容问题。即使某个项目一开始看起来前途无量，但如果 bug 不断或者面对一些常见问题没有好的答案，人们也会无情地抛弃它。同样，随着时间的推移，项目负责方做出了一些重大的负面改动，或者其他有害项目的决策，人们也会对这个项目失去信任。忽略 OSS 社区也会让项目受到影响：这里说的不重视可以小到问题管理，大到项目的未来方向。

（编辑：常州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!