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

企业并不是一个完全开放式的空间，通常来说员工的薪资待遇股票期权等在公司都是禁止公开讨论的。公司的发展策略等也是高层领导确定后把结论周知大家，至于决策等过程、用到的数据、利弊的考虑等都会受限于特定的人群，一般也不会在公开场合讨论。

曾经有一家公司，企业内网有一个完全匿名的 BBS 。匿名 BBS 的出发点是好的，给大家一个自由讨论的空间。我觉得这是一个非常好的「讨论实质内容」的地方。只要你把事情的原委说明白，基本上都能得到妥善解决。公司的人力、行政、食堂、财务、法务等都愿意在上面回答大家的问题。但是后来部分同学开始不断在上面质疑公司的业务目标、公司的经营策略，公司的打法运营手段等。。。。这已经超出了「实际问题」的层次，甚至已经到了「价值观」。最后发展的结果就是取消了匿名，从此 BBS一潭死水，而很多原本能在内网解决的问题，却都变成了脉脉上的各种牢骚。

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

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

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

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