框架類是否適合企業內源？

框架類都由公司早期來的一些大佬們負責（相當于技術委員會），更新頻率非常低。給框架類提MR的人，多數本身就在技術委員會。

如果公司的人員眾多，類似BAT級別，幾萬人使用的框架，大家一起添磚加瓦也許是合適的，尤其適合那些公司本來已經開源到開源社區的框架。但做之前肯定有大量的學習和熟悉成本。面向OKR編程的公司是否適合參與、參與程度要考慮好。

我們使用的框架完全公開的。因為每個人創建項目的時候只要選擇好，前端/后端，語言等，我們就會根據用戶選擇直接生成項目。

插件類是否適合企業內源？

舉個例子，我們團隊給 Jira 寫過小插件，給 Gitlab 寫過小插件。就一個小伙伴負責，插件不是很大，一年也不更新一次。我們還負責公司的 Jira 和 Gitlab 服務器。

其它團隊有 Jira 和 Gitlab 插件的需求搞個企業內源一起搞不好么？

• 如果需求工作量不大，通常直接提給我們團隊，我們團隊的小伙伴一兩天就能解決，在測試環境測試完，然后我們協調個時間就部署到線上服務器了。如果不這么做，業務方自己做插件，自測沒問題提交到我們這，我們也要看下代碼，然后驗證，最后部署上線。這里有多個前提：1）業務方有相關的插件專家 2）他寧愿自己寫，也不愿意把需求提給我們，讓我們幫他 3）他寫完了，我們還是要了解他真實的訴求，然后審查代碼，驗證功能，部署上線。即便再簡單的功能1-3天的排期是相對合理的，也就是放著自己的主業不做，一定花個1-3天幫我們寫插件，如果再算上我們配合他的時間，估計得一周上線。對于企業整體效能來說，非常低。
• 如果需求工作量很大，連我們工具維護方都要分迭代排期上線，我覺得正常一點的業務方根本不會考慮自己寫。

工具類是否適合企業內源？

情形和插件類似。每個工具都有相應的負責團隊，專人專職是最高效的。你開放了源代碼也就是大家閑著的時候可以多扒拉扒拉幾個別人的代碼庫。

企業內源能解決公司內部山頭林立的問題？

公司內部山頭林立，輪子眾多自有其內在原因，根因在公司一把手，在公司管理層。很多山頭的出現有時候就是為了業務的發展建立的，比如事業部制。為了能讓業務快速發展，業務閉環在一起會發展得更好?！竷蓹嘞嗪θ∑漭p」。有的時候不是老板們看不到，而是覺得這些成本可以接受而已，而帶來的閉環效果會更好?？纯打v訊的PCG，TEG，再去看看 CSIG。

通過企業內源去「平山頭」是最低效的方式。一個小小的工程師想通過企業內源把公司的一些大佬的「山頭」平了？

我來快手入職的時候，從微軟來的水叔就曾提醒我們說，不要把「內部工具」當成「內斗的武器」。時刻都謹記他的話，時刻提醒自己。

企業內源能解決重復造輪子、內部輪子眾多的問題？

我們自問一下，這么多個輪子都內部開源了就能解決輪子多的問題了？不能的，只要公司內部造輪子的根因在那里，就會有層出不窮的輪子出現。造成多個輪子的因素多數不是輪子本身問題，而是組織管理問題。想通過一個工程實踐解決組織管理問題、利益問題是不靠譜的。

企業內源能讓參與者收獲主動性、人脈、利益、成長？

企業內部的大佬之所以是大佬很多都是進來時就是大佬。他們都是帶著「光環」來的。公司內部成長起來的大佬，要么是做對了業務憑戰功上來的要么是抱對了大腿+做了一些事情上來的，不能說沒有只能說很少是通過做「企業內源」上來的。想通過「企業內源」收獲「主動性、人脈、利益、成長」太慢了。如果真有人想通過做「企業內源」上位，那么1）選擇了一個邊緣業務 2）自己處于一個邊緣位置。

如果想快速在公司成長，那么就應該選擇主營業務，去做主營業務。機會多，成長快。

企業內源期望高手或者想提升個人技能的人參與？

公司內部的高手每天都是很忙的，每天都在參加各種會議，做各種方案，如果他的主OKR不是做企業內源，他根本沒時間放這上。之所以是高手，眼力也是高的。一眼就能知道把主要精力耗在這上「沒戲」。投入精力大，不易出結果，效果說不清。

公司內的新人一般更愿意多努力去獲取大家的認可。所以新人利用「業(jia)余(ban)」時間去參與一下也許可以。晚上10點以后，一天的工作完成了，自己還有精力有念頭去再鼓搗鼓搗的。這樣的人也許會參與一下。時間上是別指望的，整體溝通成本還會增加。

企業內源與 devops

企業內部開源

內部開源（Inner Source）簡稱內源，指把開發開源軟件中學到的經驗教訓應用到公司或組織內部開發軟件的實踐。公司和組織可以在內部開源的同時開發專有軟件。

DevOps

定義：DevOps是一種軟件工程文化和實踐，旨在統一整合軟件開發和軟件運維。DevOps運動的主要特點是倡導對構建軟件的從集成、測試、發布、部署、基礎架構管理等所有環節的全面自動化和監控。

目標：DevOps 的目標是縮短開發周期，提高部署頻率和更可靠的發布，與業務目標保持一致。

企業內源與 DevOps 本質上沒啥關系。企業內源只不過和其它業務一樣利用了 DevOps 提供的基礎設施，同時更依賴于這些基礎設施?？紤]到企業內源和 DevOps 都與源碼、基礎設施打交道，所以公司內部趨向于讓 EE 團隊來統一做企業內源，這事倒是也是很合理的。

文章總結

總體來看，企業內源適合公司有錢、人閑、項目無時限的情況。小公司、每天都加班到深夜，今天出需求后天就上線的情況是不適合搞企業內源的。

更多相關

從特拉斯辭職風波到研發效能中的荒唐事

亂談開源社區、開源項目與企業內部開源（中）

為啥不適合，依然有很多人大張旗鼓搞企業內部開源？（下）

什么是研發效能？研發效能定義及核心價值

研發效能｜DevOps 已死平臺工程永存帶來的焦慮

感謝點贊、轉載關注我，了解研發效能發展動向；歡迎進入「DevOps研發效能」一起探討