为React项目工作四年后，我理解了企业开源的真谛

Posted 2021-04-25 InfoQ

作者 | Sophie Alpert

译者 | 王强

策划 | 小智

对企业而言，发布和维护开源项目都是需要耗费大量心力的。在为 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 社区也会让项目受到影响：这里说的不重视可以小到问题管理，大到项目的未来方向。

诚然，项目的成功会带来高昂的维护成本，失败的可能性也不容小觑，但处理得当的开源项目也会带来巨大的价值。

开始之前

文档以及代码质量

有些开源带来的好处甚至在项目宣发之前就已经体现出来了。准备将某项目开源会迫使人们清理代码、划出清晰的 API 边界、让项目在现有环境和公司之外实际可用，这样维护起来会更方便，日后如果需要重构也会容易很多。开源同样是个让人认真写软件运行文档的好时机，哪怕这个项目只是在公司内部使用，好的文档对新入职的员工而言也是个很好的资源。随着使用项目的人增加，外部的人 也会开始帮忙写入门指南。到后来，只要是软件使用相关，只有你想不到，没有你找不到的问题和其解决方式，就像 React 的社区做到的一样。

扩展之后

大多数开源软件的好处会随着项目的受欢迎程度扩大而增长。成功的开源项目往往拥有多功能的基础架构，和可以重复利用的核心构件。项目越是不针对具体业务，他人越会觉得这个项目有用，项目作者也就越不用担心会泄露公司机密。

工程品牌

无论是名不见经传的小公司还是五百强科技公司，开源项目都可以提升工程部门的品牌声誉。2013 年 Facebook 发布 React 时，很多人对此都不屑一顾，“Facebook 的工程建议？他们连自己在干什么都不知道！”。现在，随着 React 和其他开源项目的出现，Facebook 作为前端工程领域的领军者已经得到了广泛的认可。这在招聘方面是一大助力：在我任职期间，面试过的许多工程师应试者都说过，他们想要加入 Facebook，是因为这里是 React 的发源地。无论公司规模大小，发布高质量项目不仅可以炫技，还能吸引到新人加入。

提升可靠性

他人在使用你的软件时会遇到 bug，遇到你没见过的边缘情况。多数情况下，这些 bug 被发现都是迟早的事，而随着使用人数的增多，你也就有更多的机会发现并修复这些 bug（免费的质量保证！）。即便 Facebook 拥有上千名使用 React Alpha 版的开发人员，并在每个新版本公开前发现了大多数的 bug，外部 bug 报告里仍然不断有新的问题汇报进来。

投资于员工

发布开源软件的最大内部拥趸之一，通常都是希望能回馈广大编程社区的员工个人。他们借此得到了在日常工作中做公益的机会，也得以围绕工作打出个人的招牌。开源项目也可以让他们的工作更为充实，如果一个项目的受益人不仅是公司，那么人们就更容易发自内心地关注它。

另外，项目得到推广后，关于它的知识也会变得更有价值。公司内使用开源项目的员工会收获可转移的技能，而不是针对专有系统的小众技巧。拥有开源项目使用经历的员工在转职后上岗会更快。和行业大众割裂的专有基础架构只会变成负担，而开源则可以帮你避免这种情况。其他项目的同行们会在软件兼容性上向你看齐，日后使用这些软件时，集成工作也会大大减少。

技术上的自知之明

最后，开源中最重要的好处之一：将你的基础架构作为独立项目发布，有助于你了解自己技术栈的真实水平。如果你的公司是以专有技术为基础，那么对自己程序的盲目自信更像是一种冒险，直接用另一款现有的替代品可能效果会更好。让项目在公司之外凭借其自身优点进行竞争，会帮助你看到更现实的情况（亚马逊 大概是这种策略在大规模背景下应用的最著名的例子）。如果基础架构的某部分能够凭借自身获得成功，那这就说明你前进的道路是正确的。

值得吗？

如果你所在公司搭建的某款软件对业务有较强的针对性，那么将其开源的可能性就不会太高。事实上，如果潜在用户看不到它的价值，那么这款软件基本就是无用的。但如果开发的工具泛用性较高，即便它并不完美，开源也可以被列为认真考量的事项。明确的维护承诺也很重要，如果你能够保证长期维护，用户会感激不尽的。反之，如果只是一次性的代码发布，虽然也会有帮助，但要记得提前告诉大家！

有了开放源码，你就能得到你所投入的东西。它可以帮助推动行业发展，使你的公司受益，并激励当前和未来的员工——虽然这需要时间和努力。如果条件合适，它是值得的。

开放源码会让你的付出有所回报，会帮助推动行业发展，使你的公司受益，激励当前和未来的员工——尽管这些都需要付出时间和精力，但如果条件合适，你会发现这些付出都是值得的。

参考阅读：

https://increment.com/open-source/the-benefits-and-costs-of-corporate-open-source/

---

点个在看少个 bug