框架類都由公司早期來的一些大佬們負責（相當於技術委員會），更新頻率非常低。給框架類提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研發效能」一起探討