開源社群的暗面
“How to Use Open Source and Shut the Fuck Up At the Same Time”
去年在用 Node。js 編寫一個 side project 的過程中，因為需要整合不同第三方網站的 OAuth 登陸，所以接觸到了 passport。js 。雖然各類渠道都表明它似乎是 OAuth 解決方案的不二之選，但是在實際整合的過程中發現問題頗多，在前往 GitHub 上檢視有沒有相關的 issue 時，驚訝的發現 passport-github （passport 下允許使用 GitHub 進行 OAuth 登陸的子模組 ）已經至少有兩年沒有新的程式碼提交了。正在我納悶這個專案還會不會繼續維護時，在主專案 passport 的 issue 裡也找到了提出了相同問題的人：Library still mantained？
這則 issue 的討論非常簡短，很快就能閱讀完畢。在我看來最能體現專案維護者對於這個問題的答覆，是他直接對於這則文章的引用：
“How to Use Open Source and Shut the Fuck Up At the Same Time”
你甚至不用讀完整篇文章，光是看標題就大致明白他的態度如何了。這篇文章含標題在內一共使用了 fuck 這個單詞8次。它所表達的是作者對於開源社群目前“衣來伸手，飯來張口”和“端起碗吃肉，放下筷子罵娘”現象的不滿：作者認為專案維護者完全是無償在貢獻出自己的時間，且從中沒有絲毫的獲利，也就沒有義務滿足任何人提出的任何需求；作者還認為使用開源專案完全是各位自己的決定，不愛用就滾——雖然“滾”這個詞在是我提煉出來的，但用來表達作者的態度一點都不誇張。
這篇文章的作者可不是名不見經傳的無名小輩，他是 Eran Hammer，是 Node。js 社群中赫赫有名的 web 框架 hapijs 和資料驗證類庫 joi 的核心貢獻者之一，在 GitHub 上有超過 2k 的關注者。
過去一年因為工作的關係，我需要和越來越多的開源專案打交道，自然就被動地接觸到了開源社群中各種討論甚至爭吵。雖然這些內容最終只不過淪為我和朋友們茶餘飯後的談資， 但聯想到幾年前 event-stream 被植入惡意程式碼 以及 antd 的聖誕節彩蛋 等一系列事件，不得不承認這些“八卦”已然讓我對開源社群的信心產生動搖。終於， passport。js 作者的這則令我不適的回覆則徹底點燃了我的好奇心：
我們究竟應該以怎樣的姿態與開源專案相處？
這個時候我才發現似乎我們每個人都置身其中，但實際上我們每個人也都置身事外：你可能下載過 lodash 這個類庫成千上萬次，但是卻對它背後的維護團隊、演進路線和釋出節奏一無所知；你會在antd 的聖誕節彩蛋事件的 issue 下會看到很多大跌眼鏡的評論，但仔細想來你也無法對其擲地有聲地反駁；拋開 Eran Hammer 文章中情緒化的文字，他所想表達的觀點也並不無道理：專案消費者的權利和貢獻者的義務是否具有天然正當性的？
這篇文章不會對上述的任何一個問題予以解答，它只不過是一個旁觀者在碎碎念中表達出來的個人意見而已，充其量豐富了你的認知。你所認可的答案，要靠你自己去探索才行，
但它並非完全沒有意義——借用賈樟柯2013年在接受《三聯生活週刊》採訪時說過一段話：
我拍《天註定》就是想從中跳出來告訴大家，我們正在經歷的時代到底是怎樣的，只有把我們正在經歷什麼搞清楚，可能接下來才能知道將來要怎麼辦
——同樣地，開源社群也值得被審視和反思。落到我們的個人利益上，如果你正有打算髮布開源專案的衝動或者回饋開源社群的想法，這篇文章在這些方面都能給你一些建議。
當我們在這篇文章中將自己抽離出來重新認識開源社群時，我們審視的並不是空氣，而是實實在在的人和真真切切的事。所以文章選取了大量開源社群中的事例，來對觀點進行說明，這些事例的選取是有傾向性的——我們當然可以暢想如果沒有 Richard Stallman 或者 Linus Torvalds 開源社群會怎麼樣；如果沒有 GitHub 的話 mailing list 的協作方式會比現在更好嗎？但很多時候與其追求宏大敘事，不如隨手擷取一些開源社群的剖面展示在大家面前，這些接地氣的例子始終會比 那些高高在上的假設更具有說服力一些。
“On whose authority？”
Chris Zheng 在2017年發表了一篇名為 _On whose authority？ _的文章，在這篇文章中他敘述了他個人從加入Clojure社群到失望離開的經歷，並且著力痛斥了導致他離開的主要原因 1。 迷信明星程式設計師；2。 忽略社群的聲音；他認為這些問題是由 Clojure 背後的商業贊助公司 cognitect 一手造成的。
這篇文章中頻繁提到的明星程式設計師之一 Rich Hickey 在 Reddit 上對文章裡提到的問題一一進行了迴應，在回覆的最後，他也毫不客氣地指出對於開源社群的攻擊等同於對所有無償付出的貢獻者的否定：
……In the end it‘s about people。 You can’t say f**k XYZ and deny that it is an attack on the people who work on XYZ…… it‘s a bunch of people with families trying to make a living， pay their mortgages and send their kids to college。 And， if you are talking about Clojure， you are talking to me。 The indirection doesn’t mask the attack on people， their work and their choices。
諮詢行業中的金句“不管一開始看起來什麼樣，它永遠是人的問題”（溫伯格《諮詢的奧秘》）在這裡也同樣成立——
雖然我們三句話離不開“社群”，離不開“專案”，但我們談論的本質都是人的問題。
事件背後的孰是孰非暫且擱置，不過這個“On whose authoirty？”（誰說的算？）實在是一個再經典不過的問題了：當一個開源專案釋出到開源社群之後，專案的擁有者是依然享有“統治”它的權力，還是應該交由另一類人群來管理，是一個經久不衰的話題。
大部分真實情況沒有那麼複雜：誰擁有程式碼倉庫提交許可權，誰就有最後的決策權，甚至是生殺大權：所以 Linus Torvalds 才得以排除眾議堅持 Linux 應該使用 GPL-2。0 而非 3。0 的開源協議；而 Dave Gamache 可以選擇從2014年開始不再維護 skeleton，哪怕這個專案在 GitHub 上的收藏數量已經達到了 18。2k 次。
但現實是作為專案的維護者，你很難忽略社群發出的聲音。或者準確來說，阻止社群發出聲音。當我們承認這個無法避免的事實之後問題就變成了，應該如何對待社群的這些聲音。
讓我們看一個實際的例子。
prettier 是一個將前端程式碼格式化的工具，去年中旬開發者 Vadorequest 以 issue 的方式向社群提出了一則建議，他認為目前 pretttier 格式化過於追求格式美觀，而忽略了程式碼的可讀性，他希望工具在設計格式化規則時，能夠將格式化之後程式碼的可讀性也考慮其中。
如果你是專案的維護者你會怎麼看待這則建議？獨立來看它的目的只是改善願景，甚至不存在程式碼改動的成本，採納也未嘗不可。但如果我們把它歸納到 feature request 的標籤下整體看這一類需求的話，恐怕盡善盡美滿足每一則提議是不現實的，一方面因為（我在下一節會談到）維護者的精力有限，另一方面有的建議在提出時並非是經過深思熟慮的，甚至不同建議之間當中還會存在互相矛盾的情況。這種體驗和你作為 leader 在團隊中進行技術決策非常相似：在專案架構演化過程中會面臨太多的誘惑和方向以供選擇，我相信每一個給出這些建議的人都是出自真心，我也相信每一則建議都有它的道理，但你才是最終為決策負責的人。
即便這樣的技術決策並非出自於個人之手，但也只可能出自於人數有限的小團體之中。因為集體的決策成本太高，它絕非是最佳實踐。《團隊協作的五大障礙》一書中指出的協作障礙之一就是欠缺投入，而欠缺投入的其中一個最重要原因就是追求絕對一致。回想你目前所在公司內網上的熱門討論，任何被提出的觀點，大到制度改革小到文化衫投票，反對聲音總是存在。在處理這些問題時我的意見正如我上一段所說，辨別聲音的分量比感知聲音的大小更重要，向結果邁進比盡如人意更有意義。請放心，無論是這樣的團體還是個人都不應該是隨機挑選出來的，他們應該符合某種資質，這種資質的合法性來源於多個方面，有來自於對於業務知識的長年積累，也有來自於對技術的深刻見解，這些沉澱有助於他們來把握架構的發展方向，並從容應對業務上的變化。
類似的觀點早在《人月神話》一書中就提出過，在書中“外科手術”一章中作者指出
“需要協作溝通的人員的數量影響著開發成本，因為成本 的主要組成部分是相互的溝通和交流，以及更正溝通不當所引起的不良結果（系統除錯）”
。在軟體應該由儘可能少量人員開發的前提下，作者認為軟體開發的團隊模式類似於外科手術的方式進行組建，由一人拆解問題，其餘人負責實施。當觀點發生衝突時，由外科醫生單方面進行統一。並且為了追求系統中的概念的完整性，專制統治也是可取的。
歸根結底，我的結論是技術決策不應該是直接民主的。
蘇格拉底之所以否定雅典城邦實現的直接民主制度，是因為在他認為既然我們生病的時候會去找醫生看病，那為什麼當城邦的健康出現問題的時候，卻會認為應當求助於普通人的意見呢？技術決策也是同理，對於開源社群而言，核心維護團隊或者個人擁有對於整個專案最完整的上下文。長時間傾聽社群的聲音，使得他們對於專案的現狀，消費者的訴求有全面的瞭解。在掌握更完整的資訊的前提下，我相信他們理應比個體做出更理性的決策。
開源社群中剛好有一個概念描述了這類角色的存在：仁慈的獨裁者（Benevolent Dictators）或者是終身仁慈獨裁者（ Benevolent Dictator For Life），簡稱為BDFL。
顧名思義，獨裁者一言九鼎，他擁有對專案社群中爭議問題的最終決定權。你大可不必擔心他成為一名濫用權力的“暴君”，因為一方面這個稱謂只是一個榮譽頭銜，是對退居二線曾經常年為開源社群付出努力的貢獻者的認可（比如 Guido van Rossum 之於 Python）；另一方面他並非是開源社群中唯一的決策者，而是當作解決爭議問題的終審裁判。在問題觸達他之前，社群的公共事務通常由少數人組成的委員會負責解決，也就是我們熟知的 TSC （Technical Steering Committee）。
比如在 Node。js 的社群治理章程中，就詳細說明了 nodejs/node 是由核心協作者（Core Collaborators）來維護 。任何一則 pull request 都需要兩位協作者的批准才能合入到程式碼中。協作者負責社群的日常運營，例如貢獻程式碼、完善文件以及解決疑問等等；其中一小部分人組成的 TSC 則負責決定技術的演化方向，制定社群章程等更高層次的議題。
而開源專案 SciPy 的治理方式則是委員會（Steering Council）與獨裁者並存。委員會的候選成員在過於的一年中對專案的貢獻必須有質量和數量上的保證，由現有委員會提名產生。委員會負責專案的日常運營工作，包括但不限於專案方向的制定，社群問題的解決，文件的更新等等。而當前的 BDFL Pauli Virtanen 則只在委員會處理問題發生“死鎖”時做出決策。為了防止權力被濫用，專案還鼓勵任何與 BDFL 意見相左的人 fork 一份屬於自己 SciPy 程式碼庫。
如果以 GitHub 誕生之日為一個起點開始算起，開源社群至少已經經過了數十年的發展，其中很多實踐已經相當成熟了。
https：//opensource。guide/
是 GitHub 官方釋出的一個站點，來指導大家如何參與和維護開源專案，上面描述幾種社群治理形態幾乎就是在 Leadership and Governance 一章中的全部了。抽象看，運營一個開源社群和運營其他形態的實體社群（比如大學社團）需要解決的問題沒有太大不同，你同樣要面臨拉新，提高留存率，發展第二梯隊等問題；甚至你還需要想方設法拉取贊助（對應於給專案建立贊助頁面），為社團制定活動規範（對應於社群的 Code of Conduct）等等。
最後，我認為無需擔心開源社群中“掌權”的個人和小團體會演變成僭主（一個人統治且為了私人利益）或者寡頭（少數人統治且為了私人利益）。因為在下一節中我會談到，維護開源專案無利益可言：與社交網路恰恰相反，你無法將日益增長的“粉絲”流量兌現，它越受歡迎，你心力交瘁的感受越是強烈。
現在我們已經回答了一個問題，那就是在開源社群中應該由誰說的算。如果說這場歸宿是有關開源專案終點的話，別忘了我們還沒有回答另一個更關鍵的問題，那就是開源專案的起點在哪：為什麼要有開源專案。
“Pay Me or Fork This”
如果一則頗受歡迎的開源專案的維護者突然宣佈停止維護專案，你會作何感想？我猜你第一反應情緒大多是負面的：疑惑、不解、失望、擔心——至少你肯定不會為他感到高興。
但為什麼不呢？為什麼他要長達數年的無償的為成千上萬人貢獻出他的業餘時間？
首先我們要承認一個這樣的事實：絕大部分開源專案成立的初衷大都出自於程式設計師的個人需求，比如愛好、學習、市面上還沒有這樣的輪子等等，絕非為了什麼遠大的目標。Linus Torvalds 創造 Linux 當初的目的“只是想作為一個愛好而已”（just a hobby， won‘t be big and professional ），他釋出 Git 系統也只是“想用一些指令碼來更高效的追蹤程式碼”（some scripts to try to track things a whole lot faster）。甚至這兩者的命名都是極個人化的。
甚至有的人只是為了好玩——event-stream 在被曝出安全問題之後，專案的原維護者 Dominic Tarr 對於他為什麼創造和離開這個專案給出了這樣的解釋：
I didn’t create this code for altruistic motivations， I created it for fun。 I was learning， and learning is fun。 I gave it away because it was easy to do so， and because sharing helps learning too。
If it‘s not fun anymore， you get literally nothing from maintaining a popular package。
在我個人程式碼倉庫中，收藏數量排名前三的開源專案也都統統源自於我的個人需求：Node-Simple-Cache 是為了解決一個工作上的快取模組功能；search-trie-tree 只是突發奇想希望更高效的解決問題；而 scrapy_douban 只是為了解決當時個人想在豆瓣小組裡找房源而豆瓣又不支援合併查詢和排序的問題。
還有另一個我們可能都沒有意識到乃至不願意承認的原因是：GitHub 還具有社交屬性，程式設計師都想透過這個平臺擴大自己的影響力。2019 年有一篇名為 《社會地位即服務》（Status as a Service）頗有意思的文章事無鉅細的解釋了現代社交網路背後運作的原理。文中圍繞的中心以及反覆提及的出發點就是
“對於地位的渴望是源自於人類內心的本能”
：
people are status-seeking monkeys， always trying to seek more of it in the most efficient way possible。
並非所有渠道和平臺提供的社交地位都值得被一視同仁，社交地位價值還和稀缺性有關，如果使用者不需要付出努力就能輕而易舉得到的話，那麼以這種方式收穫的虛擬地位一文不值。GitHub 自然很具有想達成這層目標的潛質，它對所有人開放但並非所有人都能從平臺中脫穎而出。但它畢竟不是為“社交”而生，所以從來沒有想過解決社交網路裡最常見的通病：如何避免贏者通吃，如何解決蒸發冷卻效應。
這樣的趨勢是不可逆的，web 1。0 到 2。0 的進化就是最好的證明。2。0 時代的網路將曾經的資訊孤島緊密的連繫在了一起，將資訊的流通的方式從單向變更為了四通八達。這正是《未來簡史》中描述的數字主義興起的里程碑：
如果你體驗沒有被分享，沒有人看到那就是沒有價值的。資料由此產生了異化，曾經資料只是內容的點綴，而現在內容是數字的附庸。
以上狀態無論是對於傳統上內容媒體還是開源專案都同樣成立。不知道你有沒有想過這樣的一個問題：如何衡量開源專案的價值？我相信你第一時間想到的依然是各種各樣的數值：收藏數量、fork 數量、維護者解決 issue 的效率等等——所有這一切在專案 Github 主頁的 Insights 標籤下全部都有體現，甚至還包括你想不到的依賴圖譜——然而有意思的地方在於以上指標其實是圍繞專案生長於平臺的間接資訊，而專案本身比如程式碼質量和它能提供的業務價值卻因為無法被量化而被忽略。
事情比我們想象的還要複雜。
2016年 Azer Koulu 因為他釋出在 npm （JavaScript 的包管理平臺）上名為 kik 的模組與某個公司的註冊商標相同，而被律師要求從 npm 平臺上撤下（unpublish）。一怒之下他撤下了所有的釋出在 npm 上的模組。其中包括一個名為 left-pad 的模組。雖然這個模組只有17行程式碼，但卻導致整個網際網路的JavaScript 開發工作陷入癱瘓，因為有一些極其重要的模組比如 Babel。js（一款 JavaScript 程式碼的編譯工具）對 left-pad 存在依賴。以至於 npm 的 CTO 和創始人之一 Laurie Voss 不得不採取史無前例的手段來解決這個問題——恢復被撤下的 left-pad 0。0。3 版本
我們應該怎麼衡量這個專案的價值？這17行程式碼顯然不是不可替代的；收藏數量？截止專案被歸檔（ archived）累計收藏數量才 1。2k 次。但就它能帶來的破壞力而言卻是其他更大體量專案望其項背的。
我同意指標的價值，但是如果不參考維護團隊的規模，維護者能夠投入的資源，用絕對的數值來評判是有失公允的。可這恰恰是這個網路時代需要的：鑑於我們早已經被海量的資料淹沒，鑑於我們的注意力早已被碾壓的七零八落，降低消化知識的門檻，以及把權力交接給演算法和他者看上去是一個不錯的選擇。
泛社交化是一把雙刃劍，一方面它降低了開源社群的准入門檻，給了更多好的開源專案嶄露頭角的機會；另一方面它也讓更多的噪音有了可乘之機。在 GitHub 出現之前，mailing list 是社群主要的溝通方式，但如果你在決定加入某個 mailing list 之前有閱讀過官方社群的提供的 FAQ 的話，那麼你的念頭很有可能會被打消： linux-kernal 的 FAQ 長度堪比一篇論文；Apache 的 tips 甚至會告訴你應該避免使用“你”這個單詞，因為這會引起人的戒備心。更不要提社群中的 Code of Conduct 了。這些規則或者說是儀式感天然的會遮蔽掉部分人群。而到了 GitHub 時代當準入的成本幾乎為零了之後，人們甚至要被反覆告知不要在社群中新增無意義“我也是”的留言，這樣對解決問題沒有任何幫助。
從根本上與社交網路不同的是，維護一個受人矚目的開源專案的成本比發一次 twitter 的成本高多了。一旦你的具有一定的影響力和知名度之後，對專案的精力的投入便會產生邊際遞減效應。
pouchdb 的維護者之一 Nolan Lawson 專門寫過一篇名為
What it feels like to be an open-source maintainer
的文章來吐槽維護開源專案的體驗：
Outside your door stands a line of a few hundred people。 They are patiently waiting for you to answer their questions， complaints， pull requests， and feature requests。
對他而言 GitHub 的訊息通知只會給他帶來源源不斷的負面情緒，光是每天閱讀這些訊息就已經讓他心力交瘁了。
在Dominic Tarr 的在此之前的解釋中，用他的親身經歷給出了一個似乎能為所有開源專案維護者辯解為什麼要離開的理由——因為責任與收益不對等：
One time， I was working as a dishwasher in a resturant， and I made the mistake of being too competent， and I got promoted to cook。 This was only a 50 cents an hour pay rise， but massively more responsibility。 It didn’t really feel worth it。 Writing a popular module like this is like that times a million， and the pay rise is zero。
我猜你現在才開始意識到 GitHub 的功能迭代是有方向性的，它在盡最大努力減輕專案維護者的負擔，所以我們看到 GitHub 上有了issue 模板，pull request 模板，機器人，持續整合工具等等。
那我們作為專案的消費者又能為專案維護者做些什麼呢？或者在提每一個 issue 之前先前往 StackOverflow 或者是現有的 issue 看有沒有相似的問題；或者在提交 issue 的時候可以精心準備好能夠復現問題的 demo 來縮減維護者的時間；也許在提交每一個 pull request 之前現在本地執行單元測試看能否透過。但說實話無論你如何小心翼翼的用愛發電，不如考慮另一個更有效的方式——錢。
不知出於什麼樣的原因，faker。js 的維護者 Marak 決定“不再免費為世界500強公司工作了，要麼給他一份年薪六位數的合同，要麼 fork 這個專案然後自己維護去”。這個帖子的標題就叫作 No more free work from Marak - Pay Me or Fork This
令人欣慰的是，大家回帖一律對他的決定表示支援，並出謀劃策為提供他籌款方面的建議。由此可見大眾的思維也在逐漸發生轉變，越來越多的人意識到雖然開原始碼是免費的，但是貢獻者的時間並不是，他們理應得到回報。在這個共識之下市面上出現越來越多的平臺為開源專案提供第三方服務，比如 open collective、 xs code 和 gitcoin 負責籌措資金， Maintainer。io 和 tidelift 為專案提供諮詢和診斷。
這其中最著名的要數 patreon，Vue 作者尤雨溪的贊助頁面就託管在這個平臺上面，他發起贊助的目的非常明確：幫助他全職全身心的投入開源專案 Vue 的開發中。贊助選項中最“昂貴”的選項名為 Platinum Sponsor， 贊助金額為 2000 美元且每個月只提供三個名額。這個級別的贊助機構或者個人的名字能夠出現在 Vue 官網頁面的每一個文件頁面上。以我的觀察這一欄的名額供不應求。
相當長的一段時間內我都對在開源專案網站上進行商業露出的行為感到厭惡，認為這不過是將流量兌現的把戲罷了，但時至今日我才意識到這可能只不過是開源專案在做默默的掙扎而已。
關於為什麼以及如何給開源專案籌集資金在 opensource。guide 的 Getting Paid for Open Source Work 一章有很詳細的說明，我不再贅述。從這個主題自成一章的規格來看它的重要性不言而喻。金融手段雖然不是支援開源社群唯一的手段，但絕對是有力的手段之一。
“Transphobic maintainer should be removed from project ”
以上內容只不過是整個開源社群現狀的冰山一角。正如本文開頭所說，這篇文章目的並非是給大家一個結論，而是呈現給大家更多平時被忽略的事實。如果說對於前兩小節的內容我還能做到夾敘夾議的話，那麼有些話題根本就是超出我討論能力範圍之外，比如說有關道德與社會公共議題。
2015 年年中開源專案 opal 的核心團隊成員之一 Elia Schito 在 twitter 上發表言論認為跨性別者不過是“不願面對現實（not accepting reality）”。這則言論被開源社群的一位意見領袖 Coraline Ada Ehmke （她也是開源專案“參與者公約（Contributor Covenant）”的發起人）發現並在 opal 社群中發起討論，認為這種對跨性別者仇視者應該從核心團隊中被移除（Transphobic maintainer should be removed from project）。而維護團隊中的另一位成員 meh 堅決不這麼認為，他認為技術是與道德無關的，如果你想把他替換掉，你應該比他貢獻的更多才有資格說這話。至今 Elia 依然是 opal 核心團隊的成員。
如果說上面這個例子離你太遠的話，我們不如看一個更實際的：2017 年 3月餓了麼前端團隊在知乎上發表了一篇名為《寫在 Element 一週年之際》的文章，其中除了對 Element 前端類庫誕生一週年表示慶賀以外，還對他們眼中 iView 抄襲的行為表示了譴責。當然正如 iView 團隊在評論區迴應的，他們並不認可餓了麼前端團隊對於抄襲的指責。
我不敢對這些事件做任何的評價，
這類議題已經超越了開源社群，它們更加宏大，同時也更加危險。網際網路並非是討論這些問題的最佳場所，我們也並非是討論這些問題的最佳人選。
我在此談論這些話題的目的並非是想讓一種聲音壓倒一切，而是想讓不同的聲音都能傳播的更遠。
平克弗洛伊德樂隊（Pink Floyd）的概念音樂專輯《月之暗面》（Dark Side of the Moon）絕對可以算作歷史上最偉大的音樂專輯之一，它至今依然保持著 Billborad 累計停留958周的最高記錄。
樂隊的貝斯手兼主唱 Roger Waters 對於專輯標題中月之暗面的解釋是：一方面它象徵著我們都不曾親眼見過的地方，但是卻不能否認它的存在；另一方面它也代指我們每個人不為人知想對大眾隱藏的負面，我們應該學會駕馭這些負面而不是讓它們佔據我們。
開源社群的暗面就在那裡，我們無法不視而不見。
