作者：我把玲玲打一頓
本篇主要通過對中國開發者在開源社群中的活動的觀察，總結了一些有待提升或者存在弊病的現象。這些現象的背後原因可能是開發者的利益訴求，也可能是公司之間的惡性競爭，不管如何，這些行為或多或少給開源社群技術圈子已經帶來了一些影響或衝擊，甚至可能影響到了外國開發者對中國開源社群的公共印象。希望隨著成熟，這樣的現象在未來可以有所改善。
前幾天開源前端框架AntDesign的事件鬧得沸沸揚揚，儘管負責團隊已經給出了誠懇的道歉並承認了過失，但是這次事件對中國開源社群敲響了警鐘。在開源社群合作互贏的前提是相互信任相互負責，隨著開源的概念深入中國開發者圈子，我們應該反省並從中吸取教訓。大如阿里尚且會犯下錯誤，如果把同樣的責任和權力轉移給其他中國技術公司的頭上，處理的未可能未必會更合理。與此同時，這次事件也讓我們看到開源專案在中國的火爆程度，通過Github全球開發者的賬號統計又讓我們看到了中國開發者對全球開源社群的力量。甚至在世界已經有了一定的地位，其中尤其以前端專案領先，那麼非前端專案呢？
眾所周知，非前端專案（比如Web框架，容器編排框架等）在中國一直是處於一個不溫不火的狀態，參與的開發者數量遠不及前端開發者，也尚處於一個萌芽成長的階段。筆者深度參與過一些國外大型非前端的開源專案，親眼見證了一些中國的開源開發者在這些社群存在的一些問題，這些問題如果沒有得到大家的正確認識可能漸漸癌變成疾，導致更糟糕的事件爆發。
本篇指出這些專案是希望得到大家的一些反思，熱愛開源技術的朋友們有則改之無則加勉，也希望得到在社群活躍的貢獻者/維護者的共鳴。以下我們分別從貢獻者和維護者的角度拿出一些現象作為例子探討背後的原因。
貢獻者篇
開源“瘋狂英語”
在Github上面絕大部分是英語維護的，在程式碼倉庫難免有一些錯別字在裡面。日落日升，在中國有這樣一群耐苦耐勞的神祕程式設計師們，他們喜歡鑽研開源技術閱讀開原始碼，但大多數人沒想到的是，他們真的是在“閱讀”開原始碼，並且日以繼日地提交一個又一個錯別字的PR。這些錯別字在大型的專案中幾乎“取之不盡，用之不完”，自然這樣的PR也是層出不窮甚至氾濫成災。這些來自中國的開源朋友們每天修改錯別字的動力到底是什麼呢？這些灌水PR為什麼大部分來自中國呢而不是印度人日本人呢？究其根本當然這裡面有利可圖，畢竟沒有開發者願意一直跟在程式碼庫後面一直撿錯別字修改難道不是麼？小編從個人和公司層面總結了幾種最有可能的原因拋磚引玉：
個人層面：主要是簡歷造假，當然很少有人會明晃晃直接拿著一摞錯別字去偽造自己的開源社群貢獻，中國人都懂所謂造假都是“真假混賣”，畢竟很少人會仔細勘誤裡面摻雜的一半垃圾PR。再不濟碰到愣頭青面試官把我揪出來，那他走夜路應該小心後面砸來磚頭。簡歷造假本身其實見怪不怪，但是在Github開源貢獻造假有明顯越來越多的跡象。從為程式碼倉庫花錢購買star，到購買follower早不是什麼稀奇的事情。另一部分開發者會比較保守，一般是提交幾個錯別字之後抱著僥倖的心理在簡歷聲稱自己是“XXX貢獻者”。
公司層面：競標專案以及KPI，背景是一些專案招標過程中會白紙黑字寫上“需要對XXX開源專案貢獻前XX位”，尤其是最近在雲端計算領域大熱的Kubernetes，有些公司尤其是小公司面臨生存的壓力只能被迫參與這樣的惡性競爭中，可是,開發/維護開源專案本身的成本是巨大的（有深度維護過開源專案的朋友應該會感同身受），幾乎可以斷言國內沒有小公司能專門分配人力參與開源社群中，這些公司甚至緊咬在社群後面已經有些應付不來了，何況事實上投入開源社群的人力可能幾乎沒有回報？自然而然，修改錯別字或者其他的灌水形式就成了偽造貢獻的捷徑，只需要一兩個程式設計師或者全公司舉力（DDOS式“貢獻”？）公司的開源貢獻就領先全球前幾十位了。如果公司已經有一些“內鬼”維護者在社群中的話，可以源源不斷把自己公司的PR合併進來甚至打壓競爭對手。騙人騙己，真正參與過社群的朋友自然會體感到哪些公司是有貢獻的，這樣不能可持續發展，所以漸漸地這些小公司找到了灌水和貢獻之間的平衡點：維護殭屍程式碼。社群迭代過程中會嘗試性地建立一系列倉庫試驗新功能，這樣的程式碼庫往往無人問津但是“貢獻”源源不斷，美其名曰合理利用官方統計貢獻的機制裡的漏洞。
總的來說，大數量的錯別字修改PR提交只是現象，背後的原因待人深思。其實外國人也在提交錯別字修改，但是大都是零星的提交遠不及中國開發者這樣有組織有規模，甚至“軍事化”地提交錯別字。可能是公司管理層面沒有預估到開源技術的投入成本，可能是迫於生存壓力。但是如果這樣的行為影響到了開源社群的正常維護，還請手下留情。
開源“苦肉計”
所謂的“苦肉計”，是指一些“天降”貢獻者在忽然開始每天在某個開源專案提交許多PR，一堅持就是幾個月，而這些PR很多是可有可無的，（比如修改程式碼風格，調整字串風格等等“程式碼”等價的重構），甚至會反過來浪費維護者的時間。但是他們每天按時按點做這樣一件事情，目的是什麼呢？可能的原因是開源專案尤其是大型專案裡會有“席位”的說法，比如變成了專案的Committer就有了一個社群席位，貢獻者每天奮勇提交的十幾個PR一段時間就變成了上百個，這個時候就可以拿著自己的貢獻列表向開源專案提出申請“席位”，您看我這麼辛苦這麼肯幹給你貢獻了這麼多（雖然講真可能沒幾個是社群需要的），總得回饋給我點什麼吧？於是拿到席位之後，這些朋友自然就銷聲匿跡再也不開啟這個開源專案了，因為進一步投入拿到更高的席位是一件投入產出划不來的事情沒有動力去做下去。這樣的貢獻往往來自於某些公司的“開源中心”，既消耗維護者的時間又浪費貢獻者的時間，但是KPI所迫沒有辦法是個死局。扣回上面“瘋狂英語”的現象，社群貢獻本身不應該緊緊限於PR數量，commit數量，對社群的支援和維護都應該是其中主要的一部分。
既然貢獻開源社群的途徑有這麼多，為什麼中國貢獻者往往更願意通過一步到位提交程式碼的方法終結貢獻呢？一部分是大部分管理者衡量貢獻的標準如此，像盯著股票大盤一樣盯著PR數量，你多一個我少一個，另一部分是原因受限於語言表達，中國貢獻者相比於國外往往和社群之間的英語溝通比較吃力所以索性以程式碼代替交流。一些確實很有能力的開源貢獻者參與開源社群的方式卻是“悶頭苦幹”。當然文化來講中國自古以勤勞樸實為美德，但是社群（Community，更像國外鄰里/教會這樣的社群）本身不是誰種的南瓜大誰就更厲害，更不是血汗工廠。開發者參與開源社群的方式可以更“溫和”一些，比如從在slack上禮貌地提出問題交流想法開始，比如從郵件列表/Google Group中尋求幫助開始。沒有了解清楚背景提交的程式碼PR往往是“離譜”的，看來比較淺的現象後面藏著的可能是一個早前懸而未定的issue。參與開源社群，更好的姿勢應該是從蒐集資料發問開始以提交程式碼終結。
"另外"
所謂的開源社群席位只是一個名頭。在對開源專案的貢獻程度上，相比於追逐席位，更高效的參與方式可能是在瞭解並溝通社群基礎上再提交貢獻。哪怕是剛剛開始沒有任何席位身份的貢獻者，只要捕捉到社群未來的發展動向，並提交給社群“計劃內”的PR。那社群就是需要你的貢獻，這樣貢獻遠比灌水有價值更會被社群認可，以此一步一步深入開源專案，席位就是水到渠成的事情。
維護者篇
開源“吹牛怪”
首先說個結論，中國有很多所謂“維護者”是言過其實譁眾取寵的。顯而易見，所謂”吹牛“就是放大過言自己的開源社群地位。尤其是在一些國外公司主導的開源專案裡，中國個人的開發者想要得到這種社群的信任和託付是一件非常困難的事情，除非你曾經和擁有專案的公司有過合作或者任職才能進入重要的模組參與開發。結合上面提及的貢獻者存在的“瘋狂英語”和“苦肉計”的問題，很多中國開發者參與社群的心路歷程就會變得有些“病態”：先”忍辱負重“提交灌水PR充數，熬出頭拿到席位洗白變成開源“明星”。然而開源專案的每個貢獻都是在Github上面開放可以查詢的，如果身邊有所謂“明星”維護者，我們無意冒犯但是可以自己動手確認一下他在開源社群是否是真的有title上面寫的那麼重要，筆者也接手處理過這樣的面試簡歷，目前來看一大部分所謂維護者在開源社群的貢獻上是不誠實的。這種現象的根本原因之一是造假成本太低或者信用成本太低，破這個局的解法只有我們每個在關注開源的中國開發者對信譽保持敬畏，對造假持有戒心。
另外諷刺的是往往越資深越有實際社群地位的維護者，越會低調拋開身份純粹交流技術，而不會彰揚身份扎人耳目。剛剛加入社群的成員搖身一變就成了正了八經維護者，維護社群的子專案頭髮一甩交流起來就成了開源專案的Partner。當然這種身份變遷往往是一步一步來的，今天成了社群成員（事實如此），明天簡歷上就是核心成員（發現沒人有異議？），後天就是維護者（感覺自我狀態不錯），大後天就是專案合作者了（“這專案沒我轉不起來”），這種現象會使得開源技術圈子的風氣越來越浮躁，真實貢獻的成本很高於是越來越多的人走捷徑造假，何況這條路事實上已經是可以“走得通“的了。當然吹牛圖心裡一爽不會是目的，問題還是怎麼進一步變現。一方面是可能是O2O培訓開課，線上線下一齊發力，將線上維護線下變現又反過來擴張自己的名氣，另一方面可以虛張自己的業界影響力，尤其如果是國外公司維護的專案參與的中國本身就少，瞭解社群結構的人少之又少，把自己的社群聲望稍稍說高一點是抱著僥倖心理，再往高了說就是譁眾取寵反正沒幾個人懂。保持謙虛的態度才可以進一步發掘自己，社群地位是不應該過分追逐，事情做到了地位自然就來了。魯迅說過“走的人多了，就有了路”（”真的說過“），而牛皮吹出去，儘管聽的人多了但事實還是事實。少一些浮躁，維護者自然不會追逐這樣的名頭，也不會醞釀出開源專案名頭靠喊靠編的惡性競爭。
開源“隱形人”
維護者可能因為工作內容的變化就離開了一些開源專案，但是出於某些原因可能社群還會需要持續的支援和維護，但是由於個人精力有限應付不來，於是就有了這樣的“隱形“維護者。當有使用者尋求幫助開啟issue甚至直接在slack上登門拜訪也杳無音訊。確實開源社群的維護本身是非常辛苦的事情，但是如果維護者可以儘自己所能再把承擔一部分社群的責任會是更好的事情。在Github上每一個倉庫都是一個由開發者組成的社群，傳承下去也是維護的一部分內容，如果發現自己很難騰出時間管理多人在使用的公共倉庫，把這樣一份成果傳承下去而非讓程式碼”死“在那裡會是更好的處理方式。
最後簡言
上述現象可能不限於中國開源開發者，但是我們面對這些事實應該警惕成為“令人討厭的開發者”，這篇文章對此給出了很好的建議：daimajia.com/2017/03/10/…。道阻且長，希望開源的意識和規範在中國開發者圈子中深入人心，合作共贏。
