框架类都由公司早期来的一些大佬们负责（相当于技术委员会），更新频率非常低。给框架类提MR的人，多数本身就在技术委员会。
如果公司的人员众多，类似BAT级别，几万人使用的框架，大家一起添砖加瓦也许是合适的，尤其适合那些公司本来已经开源到开源社区的框架。但做之前肯定有大量的学习和熟悉成本。面向OKR编程的公司是否适合参与、参与程度要考虑好。
我们使用的框架完全公开的。因为每个人创建项目的时候只要选择好，前端/后端，语言等，我们就会根据用户选择直接生成项目。
举个例子，我们团队给 Jira 写过小插件，给 Gitlab 写过小插件。就一个小伙伴负责，插件不是很大，一年也不更新一次。我们还负责公司的 Jira 和 Gitlab 服务器。
其它团队有 Jira 和 Gitlab 插件的需求搞个企业内源一起搞不好么？
情形和插件类似。每个工具都有相应的负责团队，专人专职是最高效的。你开放了源代码也就是大家闲着的时候可以多扒拉扒拉几个别人的代码库。
公司内部山头林立，轮子众多自有其内在原因，根因在公司一把手，在公司管理层。很多山头的出现有时候就是为了业务的发展建立的，比如事业部制。为了能让业务快速发展，业务闭环在一起会发展得更好。「两权相害取其轻」。有的时候不是老板们看不到，而是觉得这些成本可以接受而已，而带来的闭环效果会更好。看看腾讯的PCG，TEG，再去看看 CSIG。
通过企业内源去「平山头」是最低效的方式。一个小小的工程师想通过企业内源把公司的一些大佬的「山头」平了？
我来快手入职的时候，从微软来的水叔就曾提醒我们说，不要把「内部工具」当成「内斗的武器」。时刻都谨记他的话，时刻提醒自己。
我们自问一下，这么多个轮子都内部开源了就能解决轮子多的问题了？不能的，只要公司内部造轮子的根因在那里，就会有层出不穷的轮子出现。造成多个轮子的因素多数不是轮子本身问题，而是组织管理问题。想通过一个工程实践解决组织管理问题、利益问题是不靠谱的。
企业内部的大佬之所以是大佬很多都是进来时就是大佬。他们都是带着「光环」来的。公司内部成长起来的大佬，要么是做对了业务凭战功上来的要么是抱对了大腿+做了一些事情上来的，不能说没有只能说很少是通过做「企业内源」上来的。想通过「企业内源」收获「主动性、人脉、利益、成长」太慢了。如果真有人想通过做「企业内源」上位，那么1）选择了一个边缘业务 2）自己处于一个边缘位置。
如果想快速在公司成长，那么就应该选择主营业务，去做主营业务。机会多，成长快。
公司内部的高手每天都是很忙的，每天都在参加各种会议，做各种方案，如果他的主OKR不是做企业内源，他根本没时间放这上。之所以是高手，眼力也是高的。一眼就能知道把主要精力耗在这上「没戏」。投入精力大，不易出结果，效果说不清。
公司内的新人一般更愿意多努力去获取大家的认可。所以新人利用「业(jia)余(ban)」时间去参与一下也许可以。晚上10点以后，一天的工作完成了，自己还有精力有念头去再鼓捣鼓捣的。这样的人也许会参与一下。时间上是别指望的，整体沟通成本还会增加。
企业内部开源
内部开源（Inner Source）简称内源，指把开发开源软件中学到的经验教训应用到公司或组织内部开发软件的实践。公司和组织可以在内部开源的同时开发专有软件。
DevOps
定义：DevOps是一种软件工程文化和实践，旨在统一整合软件开发和软件运维。DevOps运动的主要特点是倡导对构建软件的从集成、测试、发布、部署、基础架构管理等所有环节的全面自动化和监控。
目标：DevOps 的目标是缩短开发周期，提高部署频率和更可靠的发布，与业务目标保持一致。
企业内源与 DevOps 本质上没啥关系。企业内源只不过和其它业务一样利用了 DevOps 提供的基础设施，同时更依赖于这些基础设施。考虑到企业内源和 DevOps 都与源码、基础设施打交道，所以公司内部趋向于让 EE 团队来统一做企业内源，这事倒是也是很合理的。
总体来看，企业内源适合公司有钱、人闲、项目无时限的情况。小公司、每天都加班到深夜，今天出需求后天就上线的情况是不适合搞企业内源的。
感谢点赞、转载关注我，了解研发效能发展动向；欢迎进入「DevOps研发效能」一起探讨