DevOps｜乱谈开源社区、开源项目与企业内部开源( 二 ) _生活百科

企业是一个自上而下的组织架构，有很多的层级，上对下有考核、管理、领导的权利；这一点和开源社区区别很大。虽然开源社区也有精英式领导，但顶多接受或者拒绝你的 PR，谈不上管理，更没有考核。

文章插图
开源社区+企业
企业和开源社区也可以结合。比如 Redhat 。 Redhat 曾经是一个纳斯达克上市公司(2018年被 IBM收购)，它是一家开源解决方案供应商，为诸多重要IT技术如操作系统、存储、中间件、虚拟化和云计算提供关键任务的软件与服务。Redhat 是很多重大开源项目的主要贡献者。雇佣专职的员工为开源社区贡献代码，然后将开源社区项目产品化，达到盈利。
企业内部开源的目的是啥？
企业为啥要做内部开源(inner source)? 从内源的维基百科上，我们可以看到主要动机就是 1）想在内部建立类似开源的文化 2）在企业内部开发专有软件。

1）共同兴趣爱好：如果某些人对项目感兴趣可以自愿去学习、去加入
2）开放式交流空间：某些项目的文档、代码、制品都开放
3）开放式协作：平等、自组织、精英领导

做到以上三点不难。如果仅仅是把repo 权限打开、文档放开、开放讨论，那后面怎么让项目进展下去呢？这是我们要考虑的问题。
企业内部项目和开源社区项目异同
企业内部的项目都有团队归属的属性。开源社区的项目虽然也有核心成员，但是你完全可以 fork 一个自己的仓库，自己维护，不用在乎核心成员和原项目。
企业内部项目做不好，有追责的机制，投诉的机制：开源社区的项目没有这个机制，你觉得项目做的不好你来贡献。
企业内部的项目都有明确的时间节点，都有交付日期的规划。到什么时间点交付什么制品都是有清楚定义；虽然开源社区有的项目也有日期规划，但也只是规划，延期交付，大家也觉得没啥，毕竟大多数人是白吃人家饭，还要嫌弃人家饭晚么？
企业内部项目都有质量要求，这个团队做这个项目，那么就要对这个项目质量负责，出了问题，你要修复；虽然优秀的开源社区项目出现了问题，尤其是严重问题，负责任的团队也会及时修复，但这不是义务，更多还是一种自我追求。大多数项目都是「你行你上，不行别BB」
企业内部项目都有产品方向，策略、路径、目标计划，你可以「谏言」，提出好的建议，但是最终还是负责团队「决策」。
所以开源项目是一个成员人数不定、自组织、精英式队员领导的没有盈亏核算的松散项目。对于何时能满足用户需求具有很强的不确定性。而企业内部项目是团队组织架构清晰，有明确负责人负责的在一定时间内达到某种目的的自负盈亏的项目。对于企业内部项目，时间、范围、质量、成本都有明确的要求。

文章插图
企业内源怎么才能做起来？
那我就想在企业内部搞企业内源，我怎样才能搞起来呢？什么样的项目适合呢？

已经具备一定功能，仍需添加小需求的维护性项目
对时限没有严格要求的小项目
公司氛围是宽松的，员工有“闲”
公司的代码评审做得很好
支撑的基础设施相对完善，不需要更多其它角色介入（比如设计师、QA等）

通过上面就可以看到只有人闲，且需求没有deadline ，这样的内源项目也许才能跑起来。
国内企业内源现状
线下和一些华为腾讯百度的小伙伴细致了解了下企业内源的情况，总的来说，企业内源是可以做的一件事，但是效果和前景并不像网上说的那么光鲜亮丽。花了很大力气去搞，效果其实一般。对于一个大公司，如果大家觉得自己很闲，想竖起大旗做个专项，弄个企业内源，当成个事向上汇报还是可以的，但别太当回事。都冷静下来想一想，华为腾讯百度这种自身工作都卷到10点多回不了家的公司，怎么可能很闲，怎么可能靠「共同兴趣」去搞企业内源？除非做企业内源也是我工作的一部分，是我的「职责范围」。那和实际的项目制本质区别又在哪里？
文章总结
开源项目和企业内部项目差别很大，形相似义不同。对于「盈利」有很高要求的企业，项目的目的性非常强，对时限有明确的要求。项目的时间、范围、质量、成本都会纳入考量的因素，通过在不同因素间进行衡量，做出最佳的决策。如果企业内源不能在时限上给出明确的时间点，对范围、质量、成本也不能明确出来，大部分企业内部项目都不可能以这种形式展开。