技術團隊為什么要開源？
在開發的圈子里，開源漸已成勢，無論公司大小都在開源；個人開發者更不必說，github 已是標配。
而開源與使用 NodeJS 一樣，對待這件事，對個人而言是潮流，而對團隊，則是一種技術態度。
對團隊在開源這件事如何思考在一定程度上決定了團隊的技術氛圍。之前我的公眾文章里討論了「如何選擇開源協議」，今天我們就來討論對于一個技術團隊，代碼為什么要開源？
我們的討論重點不是討論開源哪些技術，而是開源的邏輯及帶來的收益；具體討論開源哪些技術，則是另一個話題，今天先不談。
｛BAT 開源現狀｝
開源這件事雖非洪水猛獸，但開了閘，因為開源可能會為一些人轉移公司代碼提供一種正大光明之理由，對公司造成損失，所以在公司臺面上很難說清利弊。
但現在避而不談開源就是掩耳盜鈴。做開發者人以群分，各公司使用開源軟件越來越多，使得相當一部分技術人員對開源的貢獻成為一種技術理想。希望從開源獲得成就，捕眾粉絲以獲崇拜感。
所以，有的公司允許開源，有的公司不允許，也有既沒說允許也沒說不允許的。
一般允許開源都會有相應審核機制，對開源的選擇權主要取決于每個部門自己的考慮。
就現在 BAT 情況，開源都有相應的審核機制。
｛團隊開源的原因｝
在團隊選擇開源的原因上，聽到最多的可能就是 — 開源可「增加團隊的影響力」。
我并不完全同意。
「影響力」并非是通過開源直接得到，技術影響力源自業務影響力；業務是指在你所在公司做的業務影響力，還包括所屬產品線的業務影響力。只有業務做得足夠大與好，外界才認為團隊有技術影響力。
所以在大多數人眼中，覺得國外的技術比國內好，那是因為寫代碼用英文，英語世界國家程序開發所在公司影響力比國內好；
大公司技術比小公司好，大公司之所以能這么大，同時在線人數這么多，肯定技術很厲害；
Google 搜索就一定比 Baidu 好，是因為 Google 是全世界的，搜索又是核心業務，技術理所應當很牛。
所以，如果想提升影響力為目的開源，所在團隊業務最好有一定影響力再談開源更靠譜。
｛影響力意味著什么｝
影響力看上去很高大上，但表現出來往往是很虛的事情；如不能實在的看到影響力能為我們團隊帶來收益，那這件事的動力與持續性就會大打折扣。
在我看來，影響力給團隊帶來至少以下好處：
- 技術收益
開源后技術需求的輸入會變多，從外部會給內部提供許多技術需求，從而從外部推進內部加快技術產出與技術創新。創新后再回歸到開源，構成技術閉環。
需求持續輸入可讓技術可象產品一樣迭代升級；提升功能單一的技術生命周期；需求多樣化提高創新能力，技術更有生命力。
jQuery 就是一個很好的例子，通過開源從原來單純 lib 到組件，再到新技術，都在技術前沿。類似的，團隊開源后，所在公司可最快享受到該技術在得到開源需求迭代后，得到的技術產出福利。
- 人才收益
在獲得影響力之后，簡歷的收集渠道會擴寬，會有同學主動給你發簡歷；并且會給現在團隊同學帶來平臺的成就感，也能得外界技術人員對團隊同學的認同感。這對于技術人員來說非常重要。
- 個人收益
試想想，你在原公司里使用某工具，但出公司后要么是不能使用，要么只能使用某 release 版本，那是一件很崩潰的事，如果開源后問題就可得以解決。
短期看是個人受益，長期實際上是整體受益，因為這批人里有部分工程師愿意再到開源社區里去給該工具提需求與貢獻代碼。
從這幾點來看，開源是構建 開源生態鏈/技術閉環 的必要方法。
｛總結｝
最后我們把問題收斂，簡化成一張圖，更好的表達我認為開源是構建「開源生態鏈/技術閉環」的必要手段。
- 綠色是技術收益
- 藍色是人才收益
- 黃色是個人收益
