之前《从特拉斯辞职风波到研发效能中的荒唐事》中关于企业内源的内容在研发效能群内引起了大家的热烈讨论。有的小伙伴不同意，有的小伙伴非常不同意，我觉得这都是非常正常的反馈，话不说不透，理不辩不明。这篇文章就是那篇文章的后续，本文主要讨论开源社区、开源项目以及企业内源。
企业内部开源
内部开源（Inner Source）简称内源，指把开发开源软件中学到的经验教训应用到公司或组织内部开发软件的实践。公司和组织可以在内部开源的同时开发专有软件。
开源社区概念
开源社区又称开放源代码社区， 一般由拥有共同兴趣爱好的人所组成 ，根据相应的开源软件许可证协议公布软件源代码的网络平台，同时也为网络成员提供一个自由学习交流的空间。由于开放源码软件主要被散布在全世界的编程者所开发，开源社区就成了他们沟通交流的必要途径，因此开源社区在推动开源软件发展的过程中起着巨大的作用。
开源社区的特点
- 1）共同兴趣爱好
你对这个东西感兴趣就可以参与进去，小到更新文档，回答用户问题，大到贡献代码、优化架构、加入方向讨论。只要你有能力且得到了别人的认可，那么社区就是欢迎的。愿意加入就加入，觉得不合适了就退出。你不对任何一个人有义务，任何一个人也没有理由约束你。
- 2）开放式交流空间
基于PR的代码协作，基于 wiki 的文档协作，基于slack/telegram 或者邮件组的讨论沟通。大家「大部分」的工作都是透明的。
开源项目所有的物料、制品每个人都可以访问。正式发布的版本还是会受到核心团队的审查、验证、把关等。
当然某些开源项目也有核心成员，他们的一些讨论会限制在一定范围。大体来看，这还是一个非常开放式的交流空间。
- 3）开放式协作：平等、自组织、精英领导
因为大家是基于兴趣爱好而来，那么来去自由。想关注 Watch/Star 项目即可；想贡献内容 Fork/PR 过来，会有人查阅你的 PR；自己已经很熟悉项目了，在 Issue 讨论区帮助回答用户问题也可。总之想对一个项目进行贡献，是没人限制你的。
虽然加入的门槛很低，但是开源协作是有「运行规则」的。每个项目都有一些核心成员，这些成员主要是把控项目前进的方向，推动项目前进，接受其他人的 PR，同时对项目投入更多的精力产出更多的内容。
开源社区是一个以共同兴趣爱好为基础的、松散的组织。
企业的概念
现代的企业是依法设立的,以营利为目的,运用各种生产要素(土地、劳动力、资本和技术等),向市场提供商品或服务,实行自主经营、自负盈亏、独立核算的法人或其他社会经济组织。从本质上，企业是一个以盈利为目的的经济组织。
如果一定非要说企业都由什么兴趣爱好的人组成，那就是都拥有「共同赚钱的爱好」。
企业的特点
企业是一个由组织机构、规章制度组成的的社会组织，需与员工签订劳动合同，而形成的一种开放式的社会组织。企业给员工各种福利待遇，员工按照公司要求尽职尽责，不存在自组织的因素。
企业不需要依靠血缘、亲缘等其他关系，更不依赖于兴趣爱好；公司里也会有各种公司组织的社团，提供一些经费场地等，但根本目的还是服务好员工，让员工有更好的产出。
企业作为一种社会组织，他的目的就是盈利，不断提高经济效益。如果说做开源社区可以给公司带来经济效益，那么公司也可以选择做；但做开源社区只是一种手段，而不是目的。
企业并不是一个完全开放式的空间，通常来说员工的薪资待遇股票期权等在公司都是禁止公开讨论的。公司的发展策略等也是高层领导确定后把结论周知大家，至于决策等过程、用到的数据、利弊的考虑等都会受限于特定的人群，一般也不会在公开场合讨论。
曾经有一家公司，企业内网有一个完全匿名的 BBS。匿名 BBS 的出发点是好的，给大家一个自由讨论的空间。我觉得这是一个非常好的「讨论实质内容」的地方。只要你把事情的原委说明白，基本上都能得到妥善解决。公司的人力、行政、食堂、财务、法务等都愿意在上面回答大家的问题。但是后来部分同学开始不断在上面质疑公司的业务目标、公司的经营策略，公司的打法运营手段等。。。。这已经超出了「实际问题」的层次，甚至已经到了「价值观」。最后发展的结果就是取消了匿名，从此 BBS一潭死水，而很多原本能在内网解决的问题，却都变成了脉脉上的各种牢骚。
企业是一个自上而下的组织架构，有很多的层级，上对下有考核、管理、领导的权利；这一点和开源社区区别很大。虽然开源社区也有精英式领导，但顶多接受或者拒绝你的 PR，谈不上管理，更没有考核。
开源社区+企业
企业和开源社区也可以结合。比如 Redhat。 Redhat 曾经是一个纳斯达克上市公司(2018年被 IBM收购)，它是一家开源解决方案供应商，为诸多重要IT技术如操作系统、存储、中间件、虚拟化和云计算提供关键任务的软件与服务。Redhat 是很多重大开源项目的主要贡献者。雇佣专职的员工为开源社区贡献代码，然后将开源社区项目产品化，达到盈利。
企业内部开源的目的是啥？
企业为啥要做内部开源(inner source)? 从内源的维基百科上，我们可以看到主要动机就是 1）想在内部建立类似开源的文化 2）在企业内部开发专有软件。
- 1）共同兴趣爱好：如果某些人对项目感兴趣可以自愿去学习、去加入
- 2）开放式交流空间：某些项目的文档、代码、制品都开放
- 3）开放式协作：平等、自组织、精英领导
做到以上三点不难。如果仅仅是把repo 权限打开、文档放开、开放讨论，那后面怎么让项目进展下去呢？这是我们要考虑的问题。
企业内部项目和开源社区项目异同
企业内部的项目都有团队归属的属性。开源社区的项目虽然也有核心成员，但是你完全可以 fork 一个自己的仓库，自己维护，不用在乎核心成员和原项目。
企业内部项目做不好，有追责的机制，投诉的机制：开源社区的项目没有这个机制，你觉得项目做得不好你来贡献。
企业内部的项目都有明确的时间节点，都有交付日期的规划。到什么时间点交付什么制品都是有清楚定义；虽然开源社区有的项目也有日期规划，但也只是规划，延期交付，大家也觉得没啥，毕竟大多数人是白吃人家饭，还要嫌弃人家饭晚么？
企业内部项目都有质量要求，这个团队做这个项目，那么就要对这个项目质量负责，出了问题，你要修复；虽然优秀的开源社区项目出现了问题，尤其是严重问题，负责任的团队也会及时修复，但这不是义务，更多还是一种自我追求。大多数项目都是「你行你上，不行别BB」
企业内部项目都有产品方向，策略、路径、目标计划，你可以「谏言」，提出好的建议，但是最终还是负责团队「决策」。
所以开源项目是一个成员人数不定、自组织、精英式队员领导的没有盈亏核算的松散项目。对于何时能满足用户需求具有很强的不确定性。而企业内部项目是团队组织架构清晰，有明确负责人负责的在一定时间内达到某种目的的自负盈亏的项目。对于企业内部项目，时间、范围、质量、成本都有明确的要求。
企业内源怎么才能做起来？
那我就想在企业内部搞企业内源，我怎样才能搞起来呢？什么样的项目适合呢？
- 已经具备一定功能，仍需添加小需求的维护性项目
- 对时限没有严格要求的小项目
- 公司氛围是宽松的，员工有“闲”
- 公司的代码评审做得很好
- 支撑的基础设施相对完善，不需要更多其它角色介入（比如设计师、QA等）
通过上面就可以看到只有人闲，且需求没有deadline，这样的内源项目也许才能跑起来。
国内企业内源现状
线下和一些华为腾讯百度的小伙伴细致了解了下企业内源的情况，总的来说，企业内源是可以做的一件事，但是效果和前景并不像网上说的那么光鲜亮丽。花了很大力气去搞，效果其实一般。对于一个大公司， 如果大家觉得自己很闲 ，想竖起大旗做个专项，弄个企业内源，当成个事向上汇报还是可以的，但别太当回事。都冷静下来想一想，华为腾讯百度这种自身工作都卷到10点多回不了家的公司，怎么可能很闲，怎么可能靠「共同兴趣」去搞企业内源？除非做企业内源也是我工作的一部分，是我的「职责范围」。那和实际的项目制本质区别又在哪里？
文章总结
开源项目和企业内部项目差别很大，形相似义不同。对于「盈利」有很高要求的企业，项目的目的性非常强，对时限有明确的要求。项目的时间、范围、质量、成本都会纳入考量的因素，通过在不同因素间进行衡量，做出最佳的决策。如果企业内源不能在时限上给出明确的时间点，对范围、质量、成本也不能明确出来，大部分企业内部项目都不可能以这种形式展开。
以上讨论的范围限制在中小企业（研发小于3000人），有专职团队负责基础工具，中台工程类建设的情况。
更多内容
从特拉斯辞职风波到研发效能中的荒唐事
内源的维基百科
Tim O'Reilly
企业内部开源
感谢点赞、转载；关注我，了解研发效能发展动向