作者 | Sophie Alpert
翻译者 | 王磊
策划 | 小光
对民营企业而言，正式发布和保护开放源码工程项目都是须要花费大量心思的。在为 React（一款由 Facebook 合作开发的知名开放源码 JS 库）组织工作六年后我对此感慨万千。我最开始而已一名内部COBOL，加入 React 项目组后，又从工程师抓起，最终升为项目组管理。和绝大多数的 Facebook 开放源码工程项目那样，React 起初而已为内部采用而合作开发的，体悟到它在简化 UI 标识符的合作开发和保护上的作用后，他们下定决心将它与全世界分享。
在我看来，React 是 Facebook 的一次令人不可思议的获得成功，而这获得成功背后也隐藏了巨大的挑战。比方说，尽管 React 非常受欢迎，但它仍处于两个竞争激烈的领域，这使得他们在合作开发新版本时须要留神再留神。
他们尽量不去做重大更动，原因很明显，人们没有天数或者不愿去适应两个变更博蒙阿的商品，即使可能将会一怒之下转用其它同价位。但反过来想，如果他们墨守成规，那么 React 将会落后于其它更Plogastel，更有开拓性的商品。React 会像它的后辈们那样，被后浪拍死在海滩上。
庞大的采用者群体也让他们在做出任何人下定决心时单厢收到反对的声音。在你体量还很小的时候，你可以讨好其它人，一旦你体量科小剑，满足所有人就变成了不可能将 的任务。这一现象并不仅限于 OSS（开放源码应用软件）。这就意味着，在准备更新版本时，他们同样须要细细考虑他们的沟通策略。在 2018 年 10 月的 React 大会上公布 React Hooks 之前，他们特意避免公合作开发表任何人 React Hooks 的消息。这原因在于他们担心在只有部分结构设计的情况下，可能将会让采用者错误知觉他们的结构设计。于是他们在直到工程项目完善后才将它Dhuys。两个工程项目越是畅销，就越难在不刺激到采用者的情况下实验新想法。
当 React 还是个初生的小婴儿时，绝大多数的采用者都是出于个人偏好优先选择了它。而在它基本上算是标准规范的现在，许多他用 React 原因在于没得选，可能将原因在于项目组中有人在用，也可能将是讲课教授优先选择了它，而这类采用者往往都并不了解 React 的独特优势。因此，更多的新采用者单厢带着偏爱的眼光看待 React，期待着捷伊插件出现。React 的采用者群之大，相关文章之多，让新采用者（有时即使会有老采用者）在找帮助时都摸不清楚哪些天然资源才是可靠的。当然，所有资料的COBOL都是素不相识的，但这并不能保证这些天然资源都是高效率的。
很多公司都指望通过正式发布两个其它人都可重大贡献标识符的开放源码应用软件来吃红利，但就，这种做法实际基本上从未获得成功过。回应难题，回答采用难题，细细规划新版本正式发布的天数线，这些都要花天数来做。哪怕是标识符重大贡献，这个被誉为能让民营企业开放源码的决策收获丰厚回报的奖，也总是盛名难副。捷伊COBOL既不像核心项目组那样对现有标识符一无所知，也不像他们那样对工程项目的远景蓝图有着清晰的知觉。内部COBOL的标识符总要经过修改才能采用，即使是一些较为优秀的拉取请求也是要过几轮审查的，对审查者而言，你永远无法确定COBOL会不会更新，以及何时才会更新。这种情况下，通常还是自己写程序比较快。
此外，绝绝大多数的拉取请求都而已顺手做的重大贡献。某人在做某工程项目时，发现了他们正在采用的某开放源码工具的两个 bug 或者限制，于是他们提交两个小插件，覆盖了他们所遇到的独特情况。通常这类的COBOL是不会做回头客的，而肯回来帮忙的都是好人。在帮忙的过程中，他们会逐渐了解你，了解你工程项目版本间的微妙差异，他们对工程项目的可靠性和长期的获得成功有了个人的投入。在 React 中，他们对捷伊COBOL总是很友善，希望他们或许会回来继续帮忙。但无论他们对他们有多么欢迎，鲜少有人会有精力或意愿继续重大贡献标识符，这可以知觉，每个人都有他们各自的生活，而有意义的重大贡献是须要花费天数的。
以上提及的困难点都是获得成功工程项目才会遇到的，但开放源码工程项目难免会失败。原因有许多，可能将是这个工程项目解决的难题太过小众、不常见，或者是它针对的难题已经有了个更好的解决方案。开放源码工程项目的创建者也许无法证明自己工程项目的实用价值，或者是没有提供足够的文档，尤其是没有对新采用者的指引。工程项目可能将须要复杂的设置或者前置基础架构环境，也可能将是用某种小众的编程语言写的，或者是由于其它技术原因导致了不兼容难题。即使某个工程项目一开始看起来前途无量，但如果 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/
