公司裡做事無非「利益」二字。公司利益，團隊利益和個人利益。如果三者能高度統一，那當然是好的。很多時候未必能完全統一，尤其是中間團隊的利益，這個時候特別需要中間團隊負責人的大局觀。有的團隊人浮於事，先把團隊「吹起來」，然後再把事情「鋪開來」，再把效果「美顏起來」，至於真實作用閉口不談。根本沒有一個長遠目標和實現路徑的規劃。
集體利益和個體利益之間的差別。好的組織可以讓大多數時候的集體利益覆蓋個體利益，如果大多數時候個體利益凌駕集體利益之上，這個組織是存在問題的，直到問題積累越來越多，最後組織崩潰。
比如在公司基礎設施還是刀耕火種的年代進行企業內部開源，尤其是很多基建都不行的時候還大張旗鼓的搞企業內部開源，不是傻就是壞。如果沒意識，沒法判斷、錯誤跟風，我們沒實力也就認了；如果明知不可為依然力挺，對大局的認知就有待商榷了。其實很多時候團隊負責人是可以判斷出來的。只不過公司不是自己開的，不想認真去思考這個問題。簡單說如果你是產研100人的CEO，你會去做企業內部開源麼？
大公司的特點 1）團隊多人多 2）分工細 3）內部卷。該佔的坑都佔了，升職加薪需要業績；能體現業績的坑都在那裡，早來的都分完了。那咋辦？如果已有的坑不滿足，那我們就挖新坑。1）影響大 2）沒人佔 3）效果未知。企業內部開源就滿足這些特點。扯虎皮拉大旗，先佔上坑幹起來再說。讓全公司的人都知道我在幹這事，成功與否管他呢？企業內部開源整體效能如何，管他呢？畢竟現在也沒有一個統一的衡量標準在那裡。如果企業內部開源還要有一個衡量標準，情懷呢？文化呢？很多人就開始毛了。衡量一下投入產出比，指定負責人、看下實際的效能還是需要的。
埃隆對於精簡流程有很好的直覺。如果沒有人強力驅動簡化，一切都會變成委員會，公司內部的民主，流程，與利益相關者交談，決策... 一切都會崩塌。設定非常雄心勃勃的目標，10倍問題並不代表著10倍難度。通常，10倍難度的問題，執行難度大概是2或3倍。
你看騰訊百度華為都在搞，怎麼講？這三家公司每年搞的東西很多，每年黃掉的專案更多。這三家做的很多專案有預研和探索的性質，畢竟是一線網際網路公司，通常更激進一些。還有一點就是適合他們那個體量的未必適合我們。同樣的一種藥給大象可能是麻醉劑，給人用可能直接 gg。
如果真想做好一個企業內部開源專案/模組/產品，那我們先可以定一些衡量標準。先拿去跑一跑現在企業內部開源的專案，如果都達標了，我們可以繼續往下跑，如果不成，立刻劃分團隊歸屬專人負責。
如果通過資料看到上面的人員過於集中，那麼就應該劃分到一個團隊來負責；如果人員過於分散，那麼就要思考下這是一個什麼神仙級的專案，每個部門都在用且都在貢獻程式碼，是功能嚴重缺失大家想集中完善，還是質量太差已經失控。
問：已有的內部專案團隊可以只保留幾個核心成員。其他的功能都開放給所有的人，需求任務領取，bug任務領取，檔案任務領取等，全員都可以參與，PR或者檔案編寫之類；以開源的方式來運作。如果有好的需求也可以提，稽核，開放，等著領取，如果大家都不參與就看如何運營？
答：關鍵是其他人為啥要參與進去？這是最需要想清楚的原因。
問：主動性、人脈、利益、成長，都是參加 github 的專案的理由。下次找工作，github一看就有背書了，交際認識了一群人，可以互相介紹了？個人能力提升了？
答：在開源世界中積攢的這些，會一直存續在開源社群，還有可能滲入到你的僱主；但是你在企業內部的人脈、利益、成長，無法「全部同步平移」到下家公司。
問：把侷限在一個專案A專案B專案C的人，放在了公共的平臺上展示自己的能力；算是證明自己的一個機會吧
答：在公司裡完成你的現有工作是第一位的。比如去做好專案ABC這是你的本職工作，你就要首先做好；如果你還有空餘時間那你再去做公共平臺展示你的能力。不能為了展示你的工作能力去做公共平臺了，專案ABC給耽誤了，這就本末倒置了。
相關文章
孫榮辛 ｜ 巨量資料穿針引線進階必看——帶你盤點那些必知必會的Google經典巨量資料論文