公司里做事无非「利益」二字。公司利益，团队利益和个人利益。如果三者能高度统一，那当然是好的。很多时候未必能完全统一，尤其是中间团队的利益，这个时候特别需要中间团队负责人的大局观。有的团队人浮于事，先把团队「吹起来」，然后再把事情「铺开来」，再把效果「美颜起来」，至于真实作用闭口不谈。根本没有一个长远目标和实现路径的规划。

从大局观去考量

集体利益和个体利益之间的差别。好的组织可以让大多数时候的集体利益覆盖个体利益，如果大多数时候个体利益凌驾集体利益之上，这个组织是存在问题的，直到问题积累越来越多，最后组织崩溃。

比如在公司基础设施还是刀耕火种的年代进行企业内部开源，尤其是很多基建都不行的时候还大张旗鼓的搞企业内部开源，不是傻就是坏。如果没意识，没法判断、错误跟风，我们没实力也就认了；如果明知不可为依然力挺，对大局的认知就有待商榷了。其实很多时候团队负责人是可以判断出来的。只不过公司不是自己开的，不想认真去思考这个问题。简单说如果你是产研100人的CEO，你会去做企业内部开源么？

为啥很多大公司在搞企业内部开源？

大公司的特点 1）团队多人多 2）分工细 3）内部卷。该占的坑都占了，升职加薪需要业绩；能体现业绩的坑都在那里，早来的都分完了。那咋办？如果已有的坑不满足，那我们就挖新坑。1）影响大 2）没人占 3）效果未知。企业内部开源就满足这些特点。扯虎皮拉大旗，先占上坑干起来再说。让全公司的人都知道我在干这事，成功与否管他呢？企业内部开源整体效能如何，管他呢？毕竟现在也没有一个统一的衡量标准在那里。如果企业内部开源还要有一个衡量标准，情怀呢？文化呢？很多人就开始毛了。衡量一下投入产出比，指定负责人、看下实际的效能还是需要的。

埃隆对于精简流程有很好的直觉。如果没有人强力驱动简化，一切都会变成委员会，公司内部的民主，流程，与利益相关者交谈，决策... 一切都会崩塌。设定非常雄心勃勃的目标，10倍问题并不代表着10倍难度。通常，10倍难度的问题，执行难度大概是2或3倍。

你看腾讯百度华为都在搞，怎么讲？这三家公司每年搞的东西很多，每年黄掉的项目更多。这三家做的很多项目有预研和探索的性质，毕竟是一线互联网公司，通常更激进一些。还有一点就是适合他们那个体量的未必适合我们。同样的一种药给大象可能是麻醉剂，给人用可能直接 gg。

企业内源衡量标准

如果真想做好一个企业内部开源项目/模块/产品，那我们先可以定一些衡量标准。先拿去跑一跑现在企业内部开源的项目，如果都达标了，我们可以继续往下跑，如果不成，立刻划分团队归属专人负责。

1. 代码更新频率
2. 代码和文档贡献的人员个数和趋势，人员所在部门分布及趋势，持续贡献的人数
3. star、fork数量和趋势
4. MR 数量、周期、comment 数量
5. 打开的issue，关闭的issue，打开到关闭的时长
6. 文档完善度：文档内容是否完善、文档内容和实际功能是否一致
7. 发布频率和趋势

通过体检做决定

如果通过数据看到上面的人员过于集中，那么就应该划分到一个团队来负责；如果人员过于分散，那么就要思考下这是一个什么神仙级的项目，每个部门都在用且都在贡献代码，是功能严重缺失大家想集中完善，还是质量太差已经失控。

问：已有的内部项目团队可以只保留几个核心成员。其他的功能都开放给所有的人，需求任务领取，bug任务领取，文档任务领取等，全员都可以参与，PR或者文档编写之类；以开源的方式来运作。如果有好的需求也可以提，审核，开放，等着领取，如果大家都不参与就看如何运营？

答：关键是其他人为啥要参与进去？这是最需要想清楚的原因。

问：主动性、人脉、利益、成长，都是参加 github 的项目的理由。下次找工作，github一看就有背书了，交际认识了一群人，可以互相介绍了？个人能力提升了？
答：在开源世界中积攒的这些，会一直存续在开源社区，还有可能渗入到你的雇主；但是你在企业内部的人脉、利益、成长，无法「全部同步平移」到下家公司。

问：把局限在一个项目A项目B项目C的人，放在了公共的平台上展示自己的能力；算是证明自己的一个机会吧

答：在公司里完成你的现有工作是第一位的。比如去做好项目ABC这是你的本职工作，你就要首先做好；如果你还有空余时间那你再去做公共平台展示你的能力。不能为了展示你的工作能力去做公共平台了，项目ABC给耽误了，这就本末倒置了。

乱谈开源社区、开源项目与企业内部开源（中）

从特拉斯辞职风波到研发效能中的荒唐事

孙荣辛 ｜ 大数据穿针引线进阶必看——带你盘点那些必知必会的Google经典大数据论文

研发效能｜DevOps 已死平台工程永存带来的焦虑

如何快速提升团队软件开发成熟度，提升研发效能？