選自知乎
機器之心報導
陳天奇、李沐、賈揚清、老師木等人如何看待國內開源現狀？這篇文章也許能為 AI 社群的開發者們提供洞見。
近年來，「開源」成為了國內科技公司對外傳播技術實力的熱門詞彙。特別是在人工智慧領域，開源成為了技術社群高頻詞彙。
近日，在阿里開源十年之際，阿里技術副總裁賈揚清發文小結了自己的開源觀念以及阿里十年開源歷程。在文章中，賈揚清表示，「當我們回想起為什麼做開源的時候，也許理由都沒有那麼的高大上：也許就是單純想分享一下程式碼，也許就是覺得社群很有意思，甚至也許不知道什麼原因，程式碼放出去了，有人用了，於是我們開始開心地找同路人。逐漸地，我們發現，開源變成了我們的一個共同的信仰：我們喜歡它，我們用心呵護它，然後我們希望更多的人加入一起培養它。」
相關知乎話題《如何看待近幾年國內開源的現狀？你是如何理解開源的？》也成為了知乎上的熱門帖子。
賈揚清在 AI 開源社群有極大的影響力。在 UC Berkeley 讀博期間，他就開始接觸深度學習，並開源了深度學習框架 Caffe。博士畢業後，賈揚清加入谷歌大腦擔任研究科學家，參與了谷歌開源框架 TensorFlow 的開發。而後在 Facebook 任職期間，他領導了很多優秀的工作，包括 2016 到 2017 年主要開發的 Caffe2、2017 年建立的神經網路通用交換格式 ONNX，以及 2018 年聯合領導的 PyTorch 1.0 專案。
除了賈揚清，在此話題下，亞馬遜 AWS 首席科學家/MXNet 作者李沐，XGBoost、TVM 等知名機器學習工具作者陳天奇、一流科技創始人袁進輝（老師木）等都回答了此問題，發表了對開源的看法。
在此文中，機器之心對他們的回答做了整理，希望能為 AI 社群的開發者們提供洞見。
李沐：開源的好與壞
我個人歷程就是從在個人主頁上掛 matlap zip（鄙視鏈底端）→ 把原始檔放到 github → 實驗程式碼一開始就是放在 github 上 → 開發工具放 github 上 → 建立 organization 來建設社群 → 先開原始碼然後再進自己公司產品。
這些年下來，感覺開源同閉源比有兩個主要好處：
- 新特性新模組能很快讓別人用上，並得到及時反饋。反饋進而激勵繼續開發。相比正常每幾個月釋出一個版本出來，這種短時激勵效果好很多。
- 開源的參與者一般比閉源專案要多。issue 上回復、相互 review 程式碼是程式猿的社交。我觀察程式猿通常在現實世界中更悶騷一點（這裡可以 at 我認識的所有給力碼農），但開源上的互動能很好的滿足社交需求（參見賈揚清回答結尾）。我認識一小哥就是持續幾年手機一響半夜起來回 issue，從而成為大神。
（對不起各位大神，腦海中實在是趕不走下面畫面）
享受便利的同時當然也得有額外付出。我覺得最大的一點是得有契約精神：我邀請你來用我新鮮出來的程式碼，那麼我會負責回答你的問題，並幫助合併你的程式碼提交請求。這個也是好幾個回答提到的「開源維護」。
但維護是個苦差事，很難被得到認可：
1. 回 issue 回慢了別人覺得會怠慢。如果回答了，但人家沒有關閉 issue 怎麼辦？放置久了就積累一大堆，造成這個專案問題多的映像。
2. 雖然絕大部分 PR 就是改改文件語法錯誤，但總會有人突然提一個很大的 PR，可能從設計上就不對，或者程式碼品味根本不行。需要不傷人自尊的情況提出改進意見，或者讓他們回爐重造。很大情況下幫別人 review 程式碼比自己重寫花費時間多多了，而且質量可能還不見得更高。但這個不能避免，只有這樣才能慢慢建設起社群。
3. 假設社群起來了，人一多背景不同想法也多，大家意見不一致，想做大改動困難重重，從而導致最初開發者榮（沮）譽（喪）退（離）休（開）。如何維持一個活躍的開發者社群就成了一個組織上問題。當前兩大組織框架是 dc 制（Linux）和民主協商制（Apache）。但絕大部分碼農得重新學習和實踐。
陳天奇：開源的三大階段
我還在讀碩士的時候嘗試的「開源」還是刀耕火種的階段。直接在個人主頁上面掛一個 zip 包，裡面有一些簡單的指令。軟體的使用者也只包含我們實驗室裡面的少數幾個同學。然後逐漸的學會了上 github，採用統一的程式碼規範，寫測試，做文件和社群的小夥伴一起推動。也認識了逐漸明白了開源並非就把程式碼掛出來那麼簡單。
很多小夥伴都說的很好。我想補充一些我從開源社群中學到的幾個東西：
開源的三個階段
1. 開放原始碼
開放原始碼也是大家所通常理解的開源。開放原始碼可以給同學們提供相互交流學習的機會，也可以使得像社群的使用交流，bug report 等可以及時得到反應。從機制上，開源其實提供了一種無形的質量評價保障。評價一個工作的好壞，是騾子是馬拉出來溜溜就知道了。對於普通的程式設計師來說，展示自己作品的一個最好讓大家發掘的方式。現在的很多領域如機器學習鼓勵開源也是這個道理，實驗的結果直接開源復現才讓大家相信。而對於整個社會來說，各種創新開放也使得技術的進步更加快速。
2. 開放開發
如果說開放原始碼是讓把自己的軟體展示出來的話。開放開發則是把一個軟體變成社群的。軟體不是一個固定的東西，需要維護、增加新特性、不斷重構來保持它的生命力。這裡面一個比較重要的問題是如何讓任何一個對這個軟體感興趣的人可以參與進來。這其中包含了開放文件是否健全，改動的技術決策是否可以讓開發者可以搜尋獲得等等，其他開發者的 pull request 是否可以被及時 review 接受等等。
不同的開源軟體的開放開發程度其實也是不同的，有的軟體主線的開發一直在一個內部機構，定期同步；有的會主要直接在主線開放開發等等。另外開放開發本身也並不是包含了程式碼實現。其實很多時候高質量的文件、code review、 社群互動等等都需要花費社群志願者的大量精力。而只有對於這些方面都進行投入之後才會讓更多的人來參與開發並且讓專案更加健康地迭代下去。
3. 開放管理
開放開發讓大家都可以參與一個軟體的開發。而開放管理則是讓積極的參與者成為社群的主人。很多成功的開源軟體都有比較成功的開放管理機制。對於開放管理的開源社群來說，開源軟體本身像是一個股份公司，而獲得股份（開發者的信任和對於專案的方向控制）的方式是參與開發。
開放的管理模式讓更多的企業和高校可以共同參與開發和管理開源專案，把一個專案做的更加持久。而因為大家都可以成為開源專案的主人，也可以鼓勵更多的合作。積極參與開發有貢獻的個人會獲得對於專案的寫許可權（committer）。許多成功的開源專案都才用開放管理的模式，比較著名的是 apache 模式，另外獨裁模式如 python（曾經是），linux 也會有 committer 來共同管理社群。
開源的「貨幣」
開源本身是志願行為，並沒有貨幣交易（當然最近 github 的打賞功能把貨幣也加入其中），但是其中卻發生了和貨幣一樣的價值交換。開源社群的一種「貨幣」是時間。參與開源貢獻，會有不同的社群同學幫忙程式碼 review 和參與討論，這些行為都需要付出大量的時間。參與開源貢獻的同學付出了自己的時間，用來交換別的開發者的時間來進行技術交流和學習。
隨著時間的積累，很多時候開發者獲得的另外一種「貨幣」是信任。一個人是否靠譜，是否願意相信一個人的技術決策，是否可以勝任一個方向的 tech lead，這些東西都決定了一個開放開發社群裡面開發者對於社群本身決策的影響能力。雖然開源可以獲得不少「貨幣」，最重要一點，開源開發者都是帶著理想和情懷投入到開發中去，而這些理想和情懷本身才是開源社群裡面最重要的東西。
程式碼並不是最關鍵的，最關鍵的是人
在一開始的時候，我們會覺得開源最重要的是程式碼。於是很多關於開源軟體的爭論會集中在程式碼在哪裡，屬於誰。實際上因為大部分開源軟體許可證允許任意複製並且授權程式碼裡面的專利給程式碼使用人，程式碼本身在哪裡並不是最關鍵的問題。
軟體並不是一個固定不變的東西，需要有不斷的升級，維護和新功能的新增。而在其中都會涉及到人—誰來做這些事情。人很多時候比程式碼重要。假設某一天一個開源軟體的主要開發方突然宣佈不再開放原始碼了了，這個時候要看其他開發者可以集合起來，有能力接著前一天的分支繼續進行開發和維護，那麼這個軟體就會依然可以被大家開發使用，甚至逐漸集合有能力的社群夥伴重構或者重寫一份都不會是問題。
程式碼在哪裡不關鍵，關鍵的是人。一個公司是否有人可以掌握開源軟體本身的架構，是否有人可以對社群的方向有所影響，是否有人可以適配開源軟體符合自己的需求，是否有人可以在必要的時候繼續維護軟體，這些才是最需要關心的問題。
活躍的開發者人群是大家使用開源軟體的真正保障，也是社會得以快速創新發展的基礎。
賈揚清：開源心態的培養
我自己做開源其實並沒有很多前輩來得久，基本上就是隨著 AI 這一波，大家有個核心的痛點就是沒有好的軟體框架可以用（那位說下載 matlab zip 包的同學請站起來），機器學習框架如雨後春筍，大家從科研界來，自然地就把程式碼開放出來，包括在知乎的李沐、陳天奇等幾位大牛，於是就入了門了。
入了門以後我們發現，哎還有那麼多講究，license 選什麼，社群怎麼互動，怎麼做推廣（對的開源也要做推廣的），等等。逐漸瞭解得多了，就越來越覺得敬畏，之前以為開源就是個很酷的事情，但是後來發現其實開源背後的精神，背後的經濟學，都有著很深的道理。
有興趣的朋友可以讀一讀一篇非常有意思的文章，stackoverflow 的創始人寫的「開源軟體經濟學」：
不過聊這個就太遠了。
我個人覺得開源是什麼
從我自己作為一個工程師的角度來說，我覺得開源是四個層面的東西：
1. 開源是作品展。畫家有畫展，作家會出書，工程師想展示自己的作品，作品是什麼？是程式碼。怎麼展示？開源。
2. 開源是技術溝通的渠道。工程師相互學習，怎麼學？怎麼討論？秀程式碼討論程式碼是最自然的途徑。當然，這個是需要真心投入的，不是開出去就算了，見光死的開源不是開源。
3. 開源是使用者模式的迭代。開源的好處是，使用者的嘗試意願高，對於 bug 的容忍度好（雖然也不是無限的），因此可以很快迭代出適合新的需求的設計。AI 框架就是一個很好的例子。
4. 開源是新商業。在商言商，我覺得開源和商業是不矛盾的。和開源非常共生的一個詞語是開放生態 - 作業系統，雲原生，各種開放標準，大大降低了軟體開發、軟體生態對接的難度。蛋糕做大了，挖掘出更多的價值，大家都開心，同時也更願意反哺開源社群發展。
國內的開源現狀怎麼樣？
從一個開源開發者開始，到逐漸考慮管理挑戰的時候，我問我自己一個問題：人有了，知識有了，意願有了，缺什麼？
缺組織保障。
這聽著是個很像宣傳部寫出來的詞語，你先別笑，我來列一下理由。開源專案要託管，要做 CI，要做 bug tracking，要定期舉行社群活動，怎麼有效運轉？這個需要做。開源專案多了，怎麼有正常的法務 CLA 流程（CLA 其實是保護開發者的），這個需要做。很多公司開源專案都是見光死，這個阿里也有，大家為了晉升而開源，導致質量堪憂，怎麼解？要建立內部孵化器機制，開源專案准入機制，開源專案關停並轉機制，這些都是很重要的事情。
舉個例子，我組裡的一位小姑娘辦今年的 Flink Forward 大會，最忙的時候在朋友圈抱怨說，氣得大半夜睡不著抹眼淚，一天被幾撥人噴，但是事情還得推。這事情讓我看到，一方面，開源是熱情驅動的，但是另一方面，我們絕對不能餓死雷鋒。所以一定要有體系化的能力沉澱，有很好的流程，把大家做開源的阻力做到最小。她和她的團隊今年主辦 Flink Forward Asia，請了頭條，快手，Intel，Bilibili，360，滴滴，等一系列社群當中的優秀公司和優秀開發者，辦成了一個兩千多人的盛會，非常成功，非常不容易。
當然，我們要說，組織保障是保障我們開發者和開源專案，不是給公司吹牛。我們開源委員會考核自己，是以我們開源專案社群的活躍度，健康度，我們做開源的技術團隊對於專案的支援程度，這些來考核的。這個初心不會變。我們要治理什麼問題？
phodal 的回答一語中的。阿里有沒有他提到的這些問題？有，而且很嚴重，內部討論的時候我還能舉出更多例子。不過我們想不想做好開源？想。解決問題的第一步就是認識問題，所以我們很感謝這些對國內開源社群愛之深責之切的朋友們。
不吐不快的部分
說了好的，我還想說一句不好的。開源不是「我的開源 vs 你的開源」。這個是我看到國內經常容易出現的一個問題。開原始碼本身是沒有國界的，什麼有國界？專家有國界。人才有國界。我們不能因為要培養我們自己的人才，就把開原始碼本身給擋在外面，自己造輪子了。
舉個 AI 框架的例子。偶爾會聽見人說「AI 框架都是美國人做的」。這句話我很費解。非常多的優秀的 AI 工程師，設計 AI 框架的工程師，都是華人。不說遠的，最近非常有潛力的 AI 編譯框架 TVM，作者是陳天奇，不能說是美國人吧。
TensorFlow 和 PyTorch 的程式碼都放在 github 上，全世界都是一套，歐洲人為什麼沒有說不是歐洲的呢？
開原始碼本身沒有國界。透過狹隘的國界區分，然後劃江而治，恰恰會對我們們的開源建設起到反效果。我們要培養的，是我們國內開源的精神，和全球的開源社群互動的能力，和開源的專案、開源的基金會，深入共建的能力，進而最終形成我們在全球開源社群當中的影響力。不是在已有的技術體系裡面搞一個我們的開源，是投入到開源社群和專案當中去，打出我們的技術深度和領導力來。
開源最後還是心態的培養
其實我覺得國內最近幾年，最讓我感到驚喜的就是，開源開放變得非常容易為人所接受了——20 年前知道 sourceforge 的工程師，和現在知道 github 的工程師，絕對數量和相對數量上都不可同日而語。相應地，我在工作當中遇到了非常多熱心開源，一起建設開源的朋友們。
我自己現在程式設計少了，有時候想起來還挺傷心的。所以偶爾週末晚上了沒事搗鼓搗鼓程式碼，放鬆一下發個 PR（是 pull request），還是個挺甜蜜的事情。
袁進輝（老師木）：開源成就程式設計師時代
近些年國內開源發展很快，表現在：1，國內的產業和工程師從開源獲益非常大，工程師的整體水平和國外水平差距越來越小；一部分國內頂尖的工程師在一些影響力大的專案中有突出貢獻，有一定的話語權甚至主導權；2，出現了一些植根於國內，在國際上有一定影響力的專案。
國內外的差距也是比較明顯的：領軍人物和明星專案與國外相比，還是太少。
其它答主對開源的總結已經非常全面，補充一些不太被提到的觀點：
0. 討論時可以區分作為愛好的開源，和帶有商業目的的開源，以下觀點是針對後面帶有商業目的的開源而言。
1. 開源是手段，不是目的（很多人都說過了），如果目的是研發更好的產品，開源更多是觸達客戶的手段，而不一定是研發更好產品的好辦法。有些工程複雜性非常高的產品，在初始階段開源不一定能從社群得到幫助，只有當工程底座比較穩固了，再開源，打磨/反饋/推廣階段或許能透過開源獲取很多幫助。（想引用一下人月神話的觀點，外科手術團隊模式，去中心化、民主不一定有助於高質量研發）。
2. 開源精神必須有「利益回報」才能持久，小到個人的成就感，名聲，職場好的職位，大到主導開源產品的企業取得商業化成功。除非一個專案單槍匹馬能搞定，大的專案在合作機制、利益分配機制上一定要合理，團隊才能長久。一個創造了價值的開源專案，最好取得好的商業回報，無論是透過諮詢，授權，訂閱還是雲服務。
3. 開源開啟了「程式設計師」時代，如果說網際網路和移動網際網路時代是「產品經理」的時代，能打造出爆款產品的產品經理更可能成就一番事業，開源時代，程式設計師有望憑藉自己的本領撬動世界，只要確實打造出了有價值的專案，在開源社群這樣一個「價值篩選器」中就能脫穎而出，獲得名聲和利益，如果運作成功，有望成就偉大的商業。
原文連結：