在开发的圈子里，开源渐已成势，无论公司大小都在开源；个人开发者更不必说，github 已是标配。
而开源与使用 NodeJS 一样，对待这件事，对个人而言是潮流，而对团队，则是一种技术态度。
对团队在开源这件事如何思考在一定程度上决定了团队的技术氛围。之前我的公众文章里讨论了「如何选择开源协议」，今天我们就来讨论对于一个技术团队，代码为什么要开源？
我们的讨论重点不是讨论开源哪些技术，而是开源的逻辑及带来的收益；具体讨论开源哪些技术，则是另一个话题，今天先不谈。
｛BAT 开源现状｝
开源这件事虽非洪水猛兽，但开了闸，因为开源可能会为一些人转移公司代码提供一种正大光明之理由，对公司造成损失，所以在公司台面上很难说清利弊。
但现在避而不谈开源就是掩耳盗铃。做开发者人以群分，各公司使用开源软件越来越多，使得相当一部分技术人员对开源的贡献成为一种技术理想。希望从开源获得成就，捕众粉丝以获崇拜感。
所以，有的公司允许开源，有的公司不允许，也有既没说允许也没说不允许的。
一般允许开源都会有相应审核机制，对开源的选择权主要取决于每个部门自己的考虑。
就现在 BAT 情况，开源都有相应的审核机制。
｛团队开源的原因｝
在团队选择开源的原因上，听到最多的可能就是 — 开源可「增加团队的影响力」。
我并不完全同意。
「影响力」并非是通过开源直接得到，技术影响力源自业务影响力；业务是指在你所在公司做的业务影响力，还包括所属产品线的业务影响力。只有业务做得足够大与好，外界才认为团队有技术影响力。
所以在大多数人眼中，觉得国外的技术比国内好，那是因为写代码用英文，英语世界国家程序开发所在公司影响力比国内好；
大公司技术比小公司好，大公司之所以能这么大，同时在线人数这么多，肯定技术很厉害；
Google 搜索就一定比 Baidu 好，是因为 Google 是全世界的，搜索又是核心业务，技术理所应当很牛。
所以，如果想提升影响力为目的开源，所在团队业务最好有一定影响力再谈开源更靠谱。
｛影响力意味着什么｝
影响力看上去很高大上，但表现出来往往是很虚的事情；如不能实在的看到影响力能为我们团队带来收益，那这件事的动力与持续性就会大打折扣。
在我看来，影响力给团队带来至少以下好处：
- 技术收益
开源后技术需求的输入会变多，从外部会给内部提供许多技术需求，从而从外部推进内部加快技术产出与技术创新。创新后再回归到开源，构成技术闭环。
需求持续输入可让技术可象产品一样迭代升级；提升功能单一的技术生命周期；需求多样化提高创新能力，技术更有生命力。
jQuery 就是一个很好的例子，通过开源从原来单纯 lib 到组件，再到新技术，都在技术前沿。类似的，团队开源后，所在公司可最快享受到该技术在得到开源需求迭代后，得到的技术产出福利。
- 人才收益
在获得影响力之后，简历的收集渠道会扩宽，会有同学主动给你发简历；并且会给现在团队同学带来平台的成就感，也能得外界技术人员对团队同学的认同感。这对于技术人员来说非常重要。
- 个人收益
试想想，你在原公司里使用某工具，但出公司后要么是不能使用，要么只能使用某 release 版本，那是一件很崩溃的事，如果开源后问题就可得以解决。
短期看是个人受益，长期实际上是整体受益，因为这批人里有部分工程师愿意再到开源社区里去给该工具提需求与贡献代码。
从这几点来看，开源是构建 开源生态链/技术闭环 的必要方法。
｛总结｝
最后我们把问题收敛，简化成一张图，更好的表达我认为开源是构建「开源生态链/技术闭环」的必要手段。
- 绿色是技术收益
- 蓝色是人才收益
- 黄色是个人收益
