"How to Use Open Source and Shut the Fuck Up At the Same Time"

去年在用 Node.js 編寫一個 side project 的過程中盖彭，因為需要集成不同第三方網(wǎng)站的 OAuth 登陸，所以接觸到了 passport.js 铺呵。雖然各類渠道都表明它似乎是 OAuth 解決方案的不二之選隧熙，但是在實際集成的過程中發(fā)現(xiàn)問題頗多，在前往 GitHub 上查看有沒有相關(guān)的 issue 時音念，驚訝的發(fā)現(xiàn) passport-github （passport 下允許使用 GitHub 進行 OAuth 登陸的子模塊 ）已經(jīng)至少有兩年沒有新的代碼提交了躏敢。正在我納悶這個項目還會不會繼續(xù)維護時件余，在主項目 passport 的 issue 里也找到了提出了相同問題的人：Library still mantained?

這則 issue 的討論非常簡短，很快就能閱讀完畢旬渠。在我看來最能體現(xiàn)項目維護者對于這個問題的答復(fù)镀首，是他直接對于這則文章的引用：

"How to Use Open Source and Shut the Fuck Up At the Same Time"

你甚至不用讀完整篇文章，光是看標題就大致明白他的態(tài)度如何了芋齿。這篇文章含標題在內(nèi)一共使用了 fuck 這個單詞8次成翩。它所表達的是作者對于開源社區(qū)目前“衣來伸手麻敌，飯來張口”和“端起碗吃肉，放下筷子罵娘”現(xiàn)象的不滿：作者認為項目維護者完全是無償在貢獻出自己的時間赢赊，且從中沒有絲毫的獲利，也就沒有義務(wù)滿足任何人提出的任何需求叭披；作者還認為使用開源項目完全是各位自己的決定玩讳，不愛用就滾——雖然“滾”這個詞在是我提煉出來的，但用來表達作者的態(tài)度一點都不夸張同诫。

這篇文章的作者可不是名不見經(jīng)傳的無名小輩误窖，他是 Eran Hammer贩猎，是 Node.js 社區(qū)中赫赫有名的 web 框架 hapijs 和數(shù)據(jù)驗證類庫 joi 的核心貢獻者之一，在 GitHub 上有超過 2k 的關(guān)注者嚷堡。

過去一年因為工作的關(guān)系蝌戒，我需要和越來越多的開源項目打交道，自然就被動地接觸到了開源社區(qū)中各種討論甚至爭吵桩匪。雖然這些內(nèi)容最終只不過淪為我和朋友們茶余飯后的談資友鼻， 但聯(lián)想到幾年前 event-stream 被植入惡意代碼 以及 antd 的圣誕節(jié)彩蛋 等一系列事件，不得不承認這些“八卦”已然讓我對開源社區(qū)的信心產(chǎn)生動搖。終于贾惦， passport.js 作者的這則令我不適的回復(fù)則徹底點燃了我的好奇心：

我們究竟應(yīng)該以怎樣的姿態(tài)與開源項目相處？

這個時候我才發(fā)現(xiàn)似乎我們每個人都置身其中碰镜，但實際上我們每個人也都置身事外：你可能下載過 lodash 這個類庫成千上萬次习瑰，但是卻對它背后的維護團隊杰刽、演進路線和發(fā)布節(jié)奏一無所知；你會在antd 的圣誕節(jié)彩蛋事件的 issue 下會看到很多大跌眼鏡的評論滓鸠，但仔細想來你也無法對其擲地有聲地反駁第喳；拋開 Eran Hammer 文章中情緒化的文字，他所想表達的觀點也并不無道理：項目消費者的權(quán)利和貢獻者的義務(wù)是否具有天然正當性的悠抹？

這篇文章不會對上述的任何一個問題予以解答楔敌，它只不過是一個旁觀者在碎碎念中表達出來的個人意見而已驻谆，充其量豐富了你的認知。你所認可的答案勺卢，要靠你自己去探索才行象对，

但它并非完全沒有意義——借用賈樟柯2013年在接受《三聯(lián)生活周刊》采訪時說過一段話：我拍《天注定》就是想從中跳出來告訴大家勒魔，我們正在經(jīng)歷的時代到底是怎樣的，只有把我們正在經(jīng)歷什么搞清楚危虱，可能接下來才能知道將來要怎么辦——同樣地唐全，開源社區(qū)也值得被審視和反思。落到我們的個人利益上弥雹，如果你正有打算發(fā)布開源項目的沖動或者回饋開源社區(qū)的想法剪勿，這篇文章在這些方面都能給你一些建議。

當我們在這篇文章中將自己抽離出來重新認識開源社區(qū)時酱固，我們審視的并不是空氣头朱，而是實實在在的人和真真切切的事项钮。所以文章選取了大量開源社區(qū)中的事例，來對觀點進行說明署隘，這些事例的選取是有傾向性的——我們當然可以暢想如果沒有 Richard Stallman 或者 Linus Torvalds 開源社區(qū)會怎么樣亚隙；如果沒有 GitHub 的話 mailing list 的協(xié)作方式會比現(xiàn)在更好嗎阿弃？但很多時候與其追求宏大敘事，不如隨手截取一些開源社區(qū)的剖面展示在大家面前，這些接地氣的例子始終會比 那些高高在上的假設(shè)更具有說服力一些肴楷。

"On whose authority?"

Chris Zheng 在2017年發(fā)表了一篇名為 _On whose authority? _的文章赛蔫，在這篇文章中他敘述了他個人從加入Clojure社區(qū)到失望離開的經(jīng)歷，并且著力痛斥了導(dǎo)致他離開的主要原因 1. 迷信明星程序員鞠值；2. 忽略社區(qū)的聲音渗钉；他認為這些問題是由 Clojure 背后的商業(yè)贊助公司 cognitect 一手造成的。

這篇文章中頻繁提到的明星程序員之一 Rich Hickey 在 Reddit 上對文章里提到的問題一一進行了回應(yīng)芒炼，在回復(fù)的最后术徊，他也毫不客氣地指出對于開源社區(qū)的攻擊等同于對所有無償付出的貢獻者的否定：

……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.

咨詢行業(yè)中的金句“不管一開始看起來什么樣赠涮，它永遠是人的問題”（溫伯格《咨詢的奧秘》）在這里也同樣成立——雖然我們?nèi)湓掚x不開“社區(qū)”，離不開“項目”斜友，但我們談?wù)摰谋举|(zhì)都是人的問題株憾。

事件背后的孰是孰非暫且擱置嗤瞎，不過這個“On whose authoirty？”（誰說的算虹菲？）實在是一個再經(jīng)典不過的問題了：當一個開源項目發(fā)布到開源社區(qū)之后掉瞳，項目的擁有者是依然享有“統(tǒng)治”它的權(quán)力陕习，還是應(yīng)該交由另一類人群來管理，是一個經(jīng)久不衰的話題冻璃。

大部分真實情況沒有那么復(fù)雜：誰擁有代碼倉庫提交權(quán)限损合，誰就有最后的決策權(quán)嫁审，甚至是生殺大權(quán)：所以 Linus Torvalds 才得以排除眾議堅持 Linux 應(yīng)該使用 GPL-2.0 而非 3.0 的開源協(xié)議；而 Dave Gamache 可以選擇從2014年開始不再維護 skeleton辐烂，哪怕這個項目在 GitHub 上的收藏數(shù)量已經(jīng)達到了 18.2k 次。

但現(xiàn)實是作為項目的維護者涩堤，你很難忽略社區(qū)發(fā)出的聲音胎围〉抡伲或者準確來說上岗，阻止社區(qū)發(fā)出聲音。當我們承認這個無法避免的事實之后問題就變成了敬锐，應(yīng)該如何對待社區(qū)的這些聲音呆瞻。

讓我們看一個實際的例子。

prettier 是一個將前端代碼格式化的工具颤介，去年中旬開發(fā)者 Vadorequest 以 issue 的方式向社區(qū)提出了一則建議滚朵，他認為目前 pretttier 格式化過于追求格式美觀前域，而忽略了代碼的可讀性匿垄，他希望工具在設(shè)計格式化規(guī)則時，能夠?qū)⒏袷交蟠a的可讀性也考慮其中。

如果你是項目的維護者你會怎么看待這則建議盏浇？獨立來看它的目的只是改善愿景绢掰，甚至不存在代碼改動的成本童擎，采納也未嘗不可顾复。但如果我們把它歸納到 feature request 的標簽下整體看這一類需求的話鲁捏，恐怕盡善盡美滿足每一則提議是不現(xiàn)實的给梅，一方面因為（我在下一節(jié)會談到）維護者的精力有限，另一方面有的建議在提出時并非是經(jīng)過深思熟慮的包帚，甚至不同建議之間當中還會存在互相矛盾的情況运吓。這種體驗和你作為 leader 在團隊中進行技術(shù)決策非常相似：在項目架構(gòu)演化過程中會面臨太多的誘惑和方向以供選擇拘哨，我相信每一個給出這些建議的人都是出自真心宅静，我也相信每一則建議都有它的道理，但你才是最終為決策負責的人纤垂。

即便這樣的技術(shù)決策并非出自于個人之手磷账，但也只可能出自于人數(shù)有限的小團體之中逃糟。因為集體的決策成本太高，它絕非是最佳實踐菇肃∪∧迹《團隊協(xié)作的五大障礙》一書中指出的協(xié)作障礙之一就是欠缺投入玩敏，而欠缺投入的其中一個最重要原因就是追求絕對一致质礼】艚叮回想你目前所在公司內(nèi)網(wǎng)上的熱門討論唧躲，任何被提出的觀點惊窖，大到制度改革小到文化衫投票，反對聲音總是存在界酒。在處理這些問題時我的意見正如我上一段所說毁欣，辨別聲音的分量比感知聲音的大小更重要，向結(jié)果邁進比盡如人意更有意義饭耳。請放心执解，無論是這樣的團體還是個人都不應(yīng)該是隨機挑選出來的，他們應(yīng)該符合某種資質(zhì)新蟆，這種資質(zhì)的合法性來源于多個方面琼稻，有來自于對于業(yè)務(wù)知識的長年積累饶囚，也有來自于對技術(shù)的深刻見解萝风，這些沉淀有助于他們來把握架構(gòu)的發(fā)展方向，并從容應(yīng)對業(yè)務(wù)上的變化睬塌。

類似的觀點早在《人月神話》一書中就提出過衫仑，在書中“外科手術(shù)”一章中作者指出“需要協(xié)作溝通的人員的數(shù)量影響著開發(fā)成本堕花，因為成本 的主要組成部分是相互的溝通和交流缘挽，以及更正溝通不當所引起的不良結(jié)果（系統(tǒng)調(diào)試）”。在軟件應(yīng)該由盡可能少量人員開發(fā)的前提下苏研，作者認為軟件開發(fā)的團隊模式類似于外科手術(shù)的方式進行組建摹蘑，由一人拆解問題轧飞，其余人負責實施过咬。當觀點發(fā)生沖突時，由外科醫(yī)生單方面進行統(tǒng)一泵三。并且為了追求系統(tǒng)中的概念的完整性烫幕，專制統(tǒng)治也是可取的具篇。

歸根結(jié)底驱显，我的結(jié)論是技術(shù)決策不應(yīng)該是直接民主的。蘇格拉底之所以否定雅典城邦實現(xiàn)的直接民主制度伏恐，是因為在他認為既然我們生病的時候會去找醫(yī)生看病翠桦，那為什么當城邦的健康出現(xiàn)問題的時候销凑，卻會認為應(yīng)當求助于普通人的意見呢？技術(shù)決策也是同理澎蛛，對于開源社區(qū)而言谋逻，核心維護團隊或者個人擁有對于整個項目最完整的上下文桐经。長時間傾聽社區(qū)的聲音阴挣，使得他們對于項目的現(xiàn)狀，消費者的訴求有全面的了解送巡。在掌握更完整的信息的前提下骗爆，我相信他們理應(yīng)比個體做出更理性的決策蔽介。

開源社區(qū)中剛好有一個概念描述了這類角色的存在：仁慈的獨裁者（Benevolent Dictators）或者是終身仁慈獨裁者（ Benevolent Dictator For Life）虹蓄，簡稱為BDFL。

顧名思義外臂，獨裁者一言九鼎宋光，他擁有對項目社區(qū)中爭議問題的最終決定權(quán)炭菌。你大可不必擔心他成為一名濫用權(quán)力的“暴君”黑低，因為一方面這個稱謂只是一個榮譽頭銜，是對退居二線曾經(jīng)常年為開源社區(qū)付出努力的貢獻者的認可（比如 Guido van Rossum 之于 Python）枷踏；另一方面他并非是開源社區(qū)中唯一的決策者掰曾，而是當作解決爭議問題的終審裁判婴梧。在問題觸達他之前，社區(qū)的公共事務(wù)通常由少數(shù)人組成的委員會負責解決客蹋，也就是我們熟知的 TSC (Technical Steering Committee)塞蹭。

比如在 Node.js 的社區(qū)治理章程中，就詳細說明了 nodejs/node 是由核心協(xié)作者（Core Collaborators）來維護 讶坯。任何一則 pull request 都需要兩位協(xié)作者的批準才能合入到代碼中番电。協(xié)作者負責社區(qū)的日常運營，例如貢獻代碼辆琅、完善文檔以及解決疑問等等漱办；其中一小部分人組成的 TSC 則負責決定技術(shù)的演化方向婉烟，制定社區(qū)章程等更高層次的議題娩井。

而開源項目 SciPy 的治理方式則是委員會（Steering Council）與獨裁者并存。委員會的候選成員在過于的一年中對項目的貢獻必須有質(zhì)量和數(shù)量上的保證似袁，由現(xiàn)有委員會提名產(chǎn)生洞辣。委員會負責項目的日常運營工作，包括但不限于項目方向的制定昙衅，社區(qū)問題的解決扬霜，文檔的更新等等。而當前的 BDFL Pauli Virtanen 則只在委員會處理問題發(fā)生“死鎖”時做出決策而涉。為了防止權(quán)力被濫用著瓶，項目還鼓勵任何與 BDFL 意見相左的人 fork 一份屬于自己 SciPy 代碼庫。

如果以 GitHub 誕生之日為一個起點開始算起啼县，開源社區(qū)至少已經(jīng)經(jīng)過了數(shù)十年的發(fā)展材原，其中很多實踐已經(jīng)相當成熟了。 https://opensource.guide/ 是 GitHub 官方發(fā)布的一個站點季眷，來指導(dǎo)大家如何參與和維護開源項目华糖，上面描述幾種社區(qū)治理形態(tài)幾乎就是在 Leadership and Governance 一章中的全部了。抽象看瘟裸，運營一個開源社區(qū)和運營其他形態(tài)的實體社區(qū)（比如大學社團）需要解決的問題沒有太大不同客叉，你同樣要面臨拉新，提高留存率，發(fā)展第二梯隊等問題兼搏；甚至你還需要想方設(shè)法拉取贊助（對應(yīng)于給項目建立贊助頁面）卵慰，為社團制定活動規(guī)范（對應(yīng)于社區(qū)的 Code of Conduct）等等。

最后佛呻，我認為無需擔心開源社區(qū)中“掌權(quán)”的個人和小團體會演變成僭主（一個人統(tǒng)治且為了私人利益）或者寡頭（少數(shù)人統(tǒng)治且為了私人利益）裳朋。因為在下一節(jié)中我會談到，維護開源項目無利益可言：與社交網(wǎng)絡(luò)恰恰相反吓著，你無法將日益增長的“粉絲”流量兌現(xiàn)鲤嫡，它越受歡迎，你心力交瘁的感受越是強烈绑莺。

現(xiàn)在我們已經(jīng)回答了一個問題暖眼，那就是在開源社區(qū)中應(yīng)該由誰說的算。如果說這場歸宿是有關(guān)開源項目終點的話纺裁，別忘了我們還沒有回答另一個更關(guān)鍵的問題诫肠，那就是開源項目的起點在哪：為什么要有開源項目。

"Pay Me or Fork This"

如果一則頗受歡迎的開源項目的維護者突然宣布停止維護項目欺缘，你會作何感想栋豫？我猜你第一反應(yīng)情緒大多是負面的：疑惑、不解谚殊、失望丧鸯、擔心——至少你肯定不會為他感到高興。

但為什么不呢嫩絮？為什么他要長達數(shù)年的無償?shù)臑槌汕先f人貢獻出他的業(yè)余時間骡送？

首先我們要承認一個這樣的事實：絕大部分開源項目成立的初衷大都出自于程序員的個人需求，比如愛好絮记、學習摔踱、市面上還沒有這樣的輪子等等，絕非為了什么遠大的目標怨愤。Linus Torvalds 創(chuàng)造 Linux 當初的目的“只是想作為一個愛好而已”（just a hobby, won't be big and professional ）派敷，他發(fā)布 Git 系統(tǒng)也只是“想用一些腳本來更高效的追蹤代碼”（some scripts to try to track things a whole lot faster）。甚至這兩者的命名都是極個人化的撰洗。

甚至有的人只是為了好玩——event-stream 在被曝出安全問題之后篮愉，項目的原維護者 Dominic Tarr 對于他為什么創(chuàng)造和離開這個項目給出了這樣的解釋：

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.

在我個人代碼倉庫中，收藏數(shù)量排名前三的開源項目也都統(tǒng)統(tǒng)源自于我的個人需求：Node-Simple-Cache 是為了解決一個工作上的緩存模塊功能差导；search-trie-tree 只是突發(fā)奇想希望更高效的解決問題试躏；而 scrapy_douban 只是為了解決當時個人想在豆瓣小組里找房源而豆瓣又不支持合并查找和排序的問題。

還有另一個我們可能都沒有意識到乃至不愿意承認的原因是：GitHub 還具有社交屬性设褐，程序員都想通過這個平臺擴大自己的影響力颠蕴。2019 年有一篇名為 《社會地位即服務(wù)》（Status as a Service）頗有意思的文章事無巨細的解釋了現(xiàn)代社交網(wǎng)絡(luò)背后運作的原理泣刹。文中圍繞的中心以及反復(fù)提及的出發(fā)點就是“對于地位的渴望是源自于人類內(nèi)心的本能”：

people are status-seeking monkeys, always trying to seek more of it in the most efficient way possible.

并非所有渠道和平臺提供的社交地位都值得被一視同仁，社交地位價值還和稀缺性有關(guān)犀被，如果用戶不需要付出努力就能輕而易舉得到的話椅您，那么以這種方式收獲的虛擬地位一文不值。GitHub 自然很具有想達成這層目標的潛質(zhì)寡键，它對所有人開放但并非所有人都能從平臺中脫穎而出掀泳。但它畢竟不是為“社交”而生，所以從來沒有想過解決社交網(wǎng)絡(luò)里最常見的通参餍：如何避免贏者通吃员舵，如何解決蒸發(fā)冷卻效應(yīng)。

這樣的趨勢是不可逆的藕畔，web 1.0 到 2.0 的進化就是最好的證明马僻。2.0 時代的網(wǎng)絡(luò)將曾經(jīng)的信息孤島緊密的連系在了一起，將信息的流通的方式從單向變更為了四通八達劫流。這正是《未來簡史》中描述的數(shù)字主義興起的里程碑：如果你體驗沒有被分享，沒有人看到那就是沒有價值的丛忆。數(shù)據(jù)由此產(chǎn)生了異化祠汇，曾經(jīng)數(shù)據(jù)只是內(nèi)容的點綴，而現(xiàn)在內(nèi)容是數(shù)字的附庸熄诡。

以上狀態(tài)無論是對于傳統(tǒng)上內(nèi)容媒體還是開源項目都同樣成立可很。不知道你有沒有想過這樣的一個問題：如何衡量開源項目的價值？我相信你第一時間想到的依然是各種各樣的數(shù)值：收藏數(shù)量凰浮、fork 數(shù)量我抠、維護者解決 issue 的效率等等——所有這一切在項目 Github 主頁的 Insights 標簽下全部都有體現(xiàn)，甚至還包括你想不到的依賴圖譜——然而有意思的地方在于以上指標其實是圍繞項目生長于平臺的間接信息袜茧，而項目本身比如代碼質(zhì)量和它能提供的業(yè)務(wù)價值卻因為無法被量化而被忽略菜拓。

事情比我們想象的還要復(fù)雜。

2016年 Azer Ko?ulu 因為他發(fā)布在 npm （JavaScript 的包管理平臺）上名為 kik 的模塊與某個公司的注冊商標相同笛厦，而被律師要求從 npm 平臺上撤下（unpublish）纳鼎。一怒之下他撤下了所有的發(fā)布在 npm 上的模塊。其中包括一個名為 left-pad 的模塊裳凸。雖然這個模塊只有17行代碼贱鄙，但卻導(dǎo)致整個互聯(lián)網(wǎng)的JavaScript 開發(fā)工作陷入癱瘓，因為有一些極其重要的模塊比如 Babel.js（一款 JavaScript 代碼的編譯工具）對 left-pad 存在依賴姨谷。以至于 npm 的 CTO 和創(chuàng)始人之一 Laurie Voss 不得不采取史無前例的手段來解決這個問題——恢復(fù)被撤下的 left-pad 0.0.3 版本

我們應(yīng)該怎么衡量這個項目的價值逗宁？這17行代碼顯然不是不可替代的；收藏數(shù)量梦湘？截止項目被歸檔（ archived）累計收藏數(shù)量才 1.2k 次瞎颗。但就它能帶來的破壞力而言卻是其他更大體量項目望其項背的件甥。

我同意指標的價值，但是如果不參考維護團隊的規(guī)模言缤，維護者能夠投入的資源嚼蚀，用絕對的數(shù)值來評判是有失公允的」苄可這恰恰是這個網(wǎng)絡(luò)時代需要的：鑒于我們早已經(jīng)被海量的數(shù)據(jù)淹沒轿曙，鑒于我們的注意力早已被碾壓的七零八落，降低消化知識的門檻僻孝，以及把權(quán)力交接給算法和他者看上去是一個不錯的選擇导帝。

泛社交化是一把雙刃劍，一方面它降低了開源社區(qū)的準入門檻穿铆，給了更多好的開源項目嶄露頭角的機會您单；另一方面它也讓更多的噪音有了可乘之機幻工。在 GitHub 出現(xiàn)之前存淫，mailing list 是社區(qū)主要的溝通方式窘拯，但如果你在決定加入某個 mailing list 之前有閱讀過官方社區(qū)的提供的 FAQ 的話氧吐，那么你的念頭很有可能會被打消： linux-kernal 的 FAQ 長度堪比一篇論文饼疙；Apache 的 tips 甚至會告訴你應(yīng)該避免使用“你”這個單詞尔许，因為這會引起人的戒備心巫俺。更不要提社區(qū)中的 Code of Conduct 了偎谁。這些規(guī)則或者說是儀式感天然的會屏蔽掉部分人群筑辨。而到了 GitHub 時代當準入的成本幾乎為零了之后俺驶，人們甚至要被反復(fù)告知不要在社區(qū)中添加無意義“我也是”的留言，這樣對解決問題沒有任何幫助棍辕。

從根本上與社交網(wǎng)絡(luò)不同的是暮现，維護一個受人矚目的開源項目的成本比發(fā)一次 twitter 的成本高多了。一旦你的具有一定的影響力和知名度之后楚昭，對項目的精力的投入便會產(chǎn)生邊際遞減效應(yīng)栖袋。

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 的消息通知只會給他帶來源源不斷的負面情緒，光是每天閱讀這些消息就已經(jīng)讓他心力交瘁了抚太。

在Dominic Tarr 的在此之前的解釋中栋荸，用他的親身經(jīng)歷給出了一個似乎能為所有開源項目維護者辯解為什么要離開的理由——因為責任與收益不對等：

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.

我猜你現(xiàn)在才開始意識到 GitHub 的功能迭代是有方向性的，它在盡最大努力減輕項目維護者的負擔凭舶，所以我們看到 GitHub 上有了issue 模板晌块，pull request 模板，機器人帅霜，持續(xù)集成工具等等匆背。

那我們作為項目的消費者又能為項目維護者做些什么呢？或者在提每一個 issue 之前先前往 StackOverflow 或者是現(xiàn)有的 issue 看有沒有相似的問題身冀；或者在提交 issue 的時候可以精心準備好能夠復(fù)現(xiàn)問題的 demo 來縮減維護者的時間钝尸；也許在提交每一個 pull request 之前現(xiàn)在本地運行單元測試看能否通過括享。但說實話無論你如何小心翼翼的用愛發(fā)電，不如考慮另一個更有效的方式——錢珍促。

不知出于什么樣的原因铃辖，faker.js 的維護者 Marak 決定“不再免費為世界500強公司工作了，要么給他一份年薪六位數(shù)的合同猪叙，要么 fork 這個項目然后自己維護去”娇斩。這個帖子的標題就叫作 No more free work from Marak - Pay Me or Fork This

令人欣慰的是，大家回帖一律對他的決定表示支持穴翩，并出謀劃策為提供他籌款方面的建議犬第。由此可見大眾的思維也在逐漸發(fā)生轉(zhuǎn)變，越來越多的人意識到雖然開源代碼是免費的芒帕，但是貢獻者的時間并不是歉嗓，他們理應(yīng)得到回報。在這個共識之下市面上出現(xiàn)越來越多的平臺為開源項目提供第三方服務(wù)背蟆，比如 open collective鉴分、 xs code 和 gitcoin 負責籌措資金， Maintainer.io 和 tidelift 為項目提供咨詢和診斷带膀。

這其中最著名的要數(shù) patreon志珍，Vue 作者尤雨溪的贊助頁面就托管在這個平臺上面，他發(fā)起贊助的目的非常明確：幫助他全職全身心的投入開源項目 Vue 的開發(fā)中本砰。贊助選項中最“昂貴”的選項名為 Platinum Sponsor碴裙， 贊助金額為 2000 美元且每個月只提供三個名額钢悲。這個級別的贊助機構(gòu)或者個人的名字能夠出現(xiàn)在 Vue 官網(wǎng)頁面的每一個文檔頁面上点额。以我的觀察這一欄的名額供不應(yīng)求。

相當長的一段時間內(nèi)我都對在開源項目網(wǎng)站上進行商業(yè)露出的行為感到厭惡莺琳，認為這不過是將流量兌現(xiàn)的把戲罷了还棱，但時至今日我才意識到這可能只不過是開源項目在做默默的掙扎而已。

關(guān)于為什么以及如何給開源項目籌集資金在 opensource.guide 的 Getting Paid for Open Source Work 一章有很詳細的說明惭等，我不再贅述珍手。從這個主題自成一章的規(guī)格來看它的重要性不言而喻。金融手段雖然不是支持開源社區(qū)唯一的手段辞做，但絕對是有力的手段之一琳要。

"Transphobic maintainer should be removed from project "

以上內(nèi)容只不過是整個開源社區(qū)現(xiàn)狀的冰山一角。正如本文開頭所說秤茅，這篇文章目的并非是給大家一個結(jié)論稚补，而是呈現(xiàn)給大家更多平時被忽略的事實。如果說對于前兩小節(jié)的內(nèi)容我還能做到夾敘夾議的話框喳，那么有些話題根本就是超出我討論能力范圍之外课幕，比如說有關(guān)道德與社會公共議題厦坛。

2015 年年中開源項目 opal 的核心團隊成員之一 Elia Schito 在 twitter 上發(fā)表言論認為跨性別者不過是“不愿面對現(xiàn)實（not accepting reality）”。這則言論被開源社區(qū)的一位意見領(lǐng)袖 Coraline Ada Ehmke （她也是開源項目“參與者公約（Contributor Covenant）”的發(fā)起人）發(fā)現(xiàn)并在 opal 社區(qū)中發(fā)起討論乍惊，認為這種對跨性別者仇視者應(yīng)該從核心團隊中被移除（Transphobic maintainer should be removed from project）杜秸。而維護團隊中的另一位成員 meh 堅決不這么認為，他認為技術(shù)是與道德無關(guān)的润绎，如果你想把他替換掉撬碟，你應(yīng)該比他貢獻的更多才有資格說這話。至今 Elia 依然是 opal 核心團隊的成員凡橱。

如果說上面這個例子離你太遠的話小作，我們不如看一個更實際的：2017 年 3月餓了么前端團隊在知乎上發(fā)表了一篇名為《寫在 Element 一周年之際》的文章，其中除了對 Element 前端類庫誕生一周年表示慶賀以外稼钩，還對他們眼中 iView 抄襲的行為表示了譴責顾稀。當然正如 iView 團隊在評論區(qū)回應(yīng)的，他們并不認可餓了么前端團隊對于抄襲的指責坝撑。

我不敢對這些事件做任何的評價静秆，這類議題已經(jīng)超越了開源社區(qū)，它們更加宏大巡李，同時也更加危險抚笔。互聯(lián)網(wǎng)并非是討論這些問題的最佳場所侨拦，我們也并非是討論這些問題的最佳人選殊橙。我在此談?wù)撨@些話題的目的并非是想讓一種聲音壓倒一切，而是想讓不同的聲音都能傳播的更遠狱从。

平克弗洛伊德樂隊（Pink Floyd）的概念音樂專輯《月之暗面》（Dark Side of the Moon）絕對可以算作歷史上最偉大的音樂專輯之一膨蛮，它至今依然保持著 Billborad 累計停留958周的最高記錄。

樂隊的貝斯手兼主唱 Roger Waters 對于專輯標題中月之暗面的解釋是：一方面它象征著我們都不曾親眼見過的地方季研，但是卻不能否認它的存在敞葛；另一方面它也代指我們每個人不為人知想對大眾隱藏的負面，我們應(yīng)該學會駕馭這些負面而不是讓它們占據(jù)我們与涡。

開源社區(qū)的暗面就在那里惹谐，我們無法不視而不見。