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