“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 fk 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ù)有限的小團體之中。因為集體的決策成本太高，它絕非是最佳實踐?！秷F隊協(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ū)（比如大學(xué)社團）需要解決的問題沒有太大不同，你同樣要面臨拉新，提高留存率，發(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è)余時間？

　　首先我們要承認一個這樣的事實：絕大部分開源項目成立的初衷大都出自于程序員的個人需求，比如愛好、學(xué)習(xí)、市面上還沒有這樣的輪子等等，絕非為了什么遠大的目標。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ò)里最常見的通?。喝绾伪苊廒A者通吃，如何解決蒸發(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 甚至?xí)嬖V你應(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)該學(xué)會駕馭這些負面而不是讓它們占據(jù)我們。

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