開源社區給黑客帶來了什麼？

| 作者：tisonkun

| 轉載自：夜天之書

| 編輯：黃欣宜

| 設計：劉穎潔

| 責編：陳梅梅

近年來，以阿里巴巴、小米和華為為首的一批公司在開源社區中的活躍，以及在招聘條件上明確加入優先錄用具有開源經驗的候選人，使得開源軟體、開源社區以及具體到個人參與社區的方法和收益成為了業內熱議的話題。

我有幸在實習及工作中深度參與到 Apache Flink 社區中，並在社區成長一年之後加入到 Committer 團隊裡；又在轉換到業務為主的工作以後，根據自己的經驗和熱情成為了 Apache Curator 項目的 Committer 和 PMC 成員。時常有同學問我開源社區該怎麼參與，社區和工作之間的平衡應該要怎麼做的問題。我雖然算不得經驗豐富，有些理解也尚淺薄，但是也確實覺得開源社區對軟體開發有實際的好處，值得分享。

這篇文章先簡要的回答怎麼參與社區的問題，再談談開源社區給黑客，也就是熱愛代碼的開發者們帶來了什麼。

---

誠如《社區運營的藝術》一書中所說，開源社區本質上是開發開源軟體的人所形成的群體，其主要標誌是社區成員在社區中建立的歸屬感。參與開源社區，本質上是在社區中找到自己的位置，建立自己的歸屬感，並將自己融入到別人對社區的歸屬感的定義中去。

因此，參與開源社區的方法，說一千道一萬，首要的是建立自己對社區的認同。如果自己都反感某個社區，或者以社區為工具而不是歸屬，怎麼能努力參與其中呢？基於對社區的認同，才能說服自己付出時間和精力獲取社區的認同，而社區的認同實際上是一種社交經濟。

是的，參與開源社區的要點和參與任何社區的要點一樣，最重要的是社區中的社交貨幣，也就是那些對人們日常生活有重大影響的可感受到的東西。例如信譽、夥伴關係、同情心和成員之間的社會交往。開源社區的參與並不因為它圍繞著開源軟體展開而有所不同，只是在社交貨幣的具體表現上體現為以對開源軟體的貢獻為核心而已。

我在一篇早期的文章《如何參與 Apache 社區》中以交流技巧為開頭，以興趣使然為結尾，就是強調主動和社會交往的重要性。具體的實踐技巧非常簡單，想想看你要如何參與一次團體遊戲或者讀書研討？只要表現出你的興趣和基礎的能力，參與其中並展現自己，為團體做出貢獻就可以了。在社區中，這個貢獻可以從文檔和注釋開始，因為這能夠幫助你快速的了解社區。儘量不要在一個地方呆著，但是要花主要的時間在一個地方鑽研。因為在單點上更容易集中精力做出貢獻，積累社交貨幣，而廣泛地交遊才能讓你把握住社區的走向。主動承擔社區 RoadMap 上關鍵的職責，如果不知道是什麼或者怎麼做，就去問。這樣才能和開源社區一起成長。沒有人會拒絕一個能力合格而積極主動的貢獻者。

對於工作和社區的所謂平衡問題，我曾說過要寫一篇短文來討論，但是細想之後發現其實一句話就能說清楚。因為根本不存在需要刻意平衡的點。如果你的工作就是運營或者發展開源社區，例如著名社區的主要貢獻公司，那麼你的工作就是社區工作，並不衝突；如果你的工作建立在開源社區的成果之上的，那將你的工作成果在組織同意的情況下貢獻給開源社區，或者解答社區中的問題，都是與工作有益無害的；如果你的工作和開源社區不太搭邊，那參與開源社區就是純粹的個人行為，這跟工作時間完成工作又有什麼衝突的呢？

對於最後這一點稍作解釋。軟體開發不是割裂的，不是說你精力投入在公司工作中，就對開源社區的貢獻一無所用，也不是說精力投入在社區工作中，就必然影響公司工作。關於後者，下面我會討論開源之風給黑客帶來的影響，關於前者，這很顯然。開源社區大多圍繞開源軟體而展開，軟體開發是共通的，開源軟體也只有能夠很好的解決業界的問題才有擴大其影響面的機會。工作中遇到的問題可以成為開源軟體功能擴展的方向，工作中歸納的方法可以成為開源軟體優化的方案，工作中積累的經驗當然可以在開源軟體的開發中遷移和演繹。

---

聊完這些，我們再看看本文的標題，即開源社區給黑客帶來了什麼？標題我想了很久，稱呼碼農或者程式設計師，總有種把自己約束在職位上的不爽快感；稱呼開發者，又跟開源社區疊字。還是用黑客最爽快，雖然黑客在時代的流變下有 cracker 的別指，但是秉承《黑客與畫家》以及《大教堂與集市》的用法，黑客（ hacker ）還是指熱愛並精通程序設計的人。

開源軟體的解釋與布道近來在國內也是甚囂塵上（ exactly ）。我無意於代表某種嚴謹的定義，也沒想著坐而論道。只是作為一個實際的一線開發人員，分享我所看到、體會到的東西。

開源社區的衝擊或者說工程師的開源文化，在開發者的圈子裡至少帶來了良好的流程規範、優秀的代碼參考以及廣泛的自由信念。

良好的流程規範說的是開源社區的代碼開發規範、代碼評審規範、提議發起和投票規範以及軟體發布規範。這在某些方面是因為社區更有可能由優秀的技術人員主導，而不是公司利益所驅動。不少社區的束縛更少，更願意嘗試新的流程和規範。這使得一線開發人員觀察和總結出來的經驗有了實驗的場所，並最終在得到驗證後在公司業務的研發上落實。好的流程和規範能夠改善開發者的工作體驗，這一點應當毋庸置疑。

其實，軟體行業不過是一個出現還不超過百年的新興行業，如今卻要和機械、土木這種數百年的傳統行業一起成為工業時代的支柱。這個行業本身尚待總結和驗證的經驗有太多太多，而開源社區作為一塊創新的試驗田，傾向於更信任的、更簡潔的流程規範，無疑是軟體行業向更人性化、更公平化發展的好趨勢。

這些年來，刪除無用代碼、採用版本管理，強制代碼評審、完善單元測試，重視技術方案、推廣敏捷開發，實踐小步快跑、落地持續集成，這些現在已經成為業內共識的規範，很有許多是從 Linux、Apache、Perl 以及其他開源社區所嘗試和流傳開來的。誰又能說現在的開發者沒有享受到開源社區的發展帶來的好處呢？

優秀的代碼參考無需多言。這是一個很明顯的現象，如果你的代碼會被別人看到、會被別人評審，更直接的說，垃圾代碼的合併請求會被否決、垃圾代碼的作者會被議論，那麼開發者對自己的代碼質量就會有更高的自我要求。同時，垃圾代碼也能夠被社區中的貢獻者所修正。

雖然我經常調侃 Flink 的代碼，但是過度的面向對象和異步化代碼確實在我需要這方面的幫助的時候提供了典型且有效的指導。另外諸如 Spark 和 Etcd 也是各自領域以及語言的代表作，以至於有段時間人們提起 Scala 會跟 Spark 混淆起來，而 Etcd 則是了解 Go 語言程序設計的比複雜的 Kubernetes/Docker 更親民的實例。

從開源軟體的代碼中學習設計模式，歸納普遍問題的一般解法，對自己代碼水平的精進顯然是大有裨益。在業務開發中我們總是很容易重複發明解決方案。重複造輪子的壞處從公司利益角度來看主要並不在於浪費時間，反正都是在預定時間內完成工作，而是解決方案通常是需要長期完善的。不使用已有的成熟方案，反而靠自己拍腦袋瞎想，很多時候是在給自己埋坑。開源社區有的是成熟的解決方案，即使解決方案存在缺陷，那也更有可能被社區成員反饋。已知的問題總不比未知深坑可怕。

最後也是我最鍾情於這個行業的一點，就是開源社區的運作方式所表達出來的廣泛的自由信念。

曾幾何時，我們自然地以為華貴的服飾和稀有的食材只有特權階級才能享受的起，工匠和學者只把自己的經驗學識由血緣或師徒紐帶傳承，甚至還要留一手。但是隨著時代的發展，如詩中所言【舊時王謝堂前燕，飛入尋常百姓家】，我們已經進入到了一個文明高度發展，自由和平等被高度重視的時代。軟體的未來，必定不是某家公司所壟斷的命運。

開源軟體在中國的發展很快遇到了抄襲、濫用的問題，但是正如書影音作品在版權保護之下自由流通一樣，開源軟體在中國或者任何地方，都將在軟體協議的保護下自由的分發。軟體作為後工業時代的核心生產力，絕對不會也不應該成為私有物品，所有的人都應該平等的享受軟體行業高速發展帶來的紅利。開源社區的蓬勃發展，證明了自由將賦予軟體更旺盛的生命力。

軟體自由流通的實現，不應該像普羅米修斯盜火一樣伴隨著巨大的犧牲，而應該在工程師的開源文化潛移默化當中成為共識。我們開發軟體，是為了改善人的生活，為了社會的發展。軟體開發的經驗和結果，自然應該自由地流通在社會上。