日前，因為被多人侮辱大吼，Swift 之父正式退出 Swift 核心團隊。

諸如此類的“語言暴力”、“網絡暴力”事件在開源社區(qū)乃至整個 IT 社區(qū)屢見不鮮。多個技術社區(qū)，都出現過創(chuàng)始人、重要維護者、貢獻者因為感覺“社區(qū)氛圍糟糕”、“受到傷害”而宣布退出的現象。更有甚者，還有科技公司領導被爆出叫囂著讓 80 后退出 IT 圈。后者可粗略視為是該領導過于偏激，且是少數案例，先不做過多討論。但是在開源圈，怎么就這樣了呢？

為了回答這個問題，本文梳理了以往的一些社區(qū)糾紛事件，發(fā)現許多矛盾發(fā)生在社區(qū)實際的管理者/層，與社區(qū)貢獻者、參與者之間，雙方的不滿大致也可以歸總成幾類原因。

眾口難調

從大教堂的開發(fā)模式轉向集市開發(fā)模式之后，技術社區(qū)存在的目的便是為了聚眾人之力，讓項目更好。在集市模式下，開源社區(qū)給了個人極大的自由度，所有貢獻者都可以暢所欲言，發(fā)表自己的想法，為項目作出貢獻。隨之而來的問題，便是如何協調所有人的意見。

社區(qū)的管理模也在一定程度上決定了社區(qū)日后的爭吵風險有多大。當下的開源社區(qū)管理主要分成四種模式。一是由社區(qū)主導，采用自由貢獻模式，“共識”是其前提，功能開發(fā)和版本發(fā)布等重要決策以社區(qū)共識為準。二是公司主導，由公司資助社區(qū)及軟件的發(fā)展，相對來說，公司會擁有更多的實權。三是 BDFL 仁慈的獨裁者模式，這是在社區(qū)模式的基礎之上，社區(qū)中有一個“獨裁者”的角色存在，他對一些重要決策有最終決定權，而非依賴社區(qū)共識。四是精英治理，在社區(qū)中表現突出、貢獻最大的人被任命為管理團隊，決策基于投票確定。

我們常見的糾紛事件，往往可以歸總為“掌權者”和“貢獻者”之爭，這種爭議更容易出現在“仁慈的獨裁者”模式的開源社區(qū)中。其他三種模式中，許多糾紛的出現也是因為實際管理團隊未扮演好自己的角色。

掌權者的不滿

聞名世界的大型開源項目往往是某個“天才程序員”的作品，早期的開源社區(qū)一般都是“仁慈的獨裁者”模式，獨裁者飽受敬仰，比如 Linux 社區(qū)的 Linus、Ubuntu 社區(qū)、Python 社區(qū)。然而，天才似乎更樂于單兵作戰(zhàn)。

• 對貢獻不滿

暴躁大佬 Linus 在評價那些沒達到他個人標準的代碼方面非常毒舌。曾有網友用了此前 Linus 在郵件列表中公開的一段回復，直指 Linus 在人際溝通中態(tài)度惡劣：“這也算是一個 BUG？你已經成為內核維護者多長時間了？還沒有學會內核維護的第一條規(guī)則？我再也不想收到這種明顯的垃圾，像白癡一樣的提交…… ”

對于一直看不爽的 Intel，Linus 對其提交的代碼也是口吐芬芳。2018 年初，為了修補 Spectre 漏洞，Intel 工程師提供了一個間接分支限制推測（indirect branch restricted speculation, IBRS）功能的補丁。Linus 當時就在郵件列表中公開指出 IBRS 會造成系統(tǒng)性能大幅降低，直言該補丁“就是徹徹底底的垃圾”。

不僅僅是 Linus，在崇尚“精英主義”的 BSD 社區(qū)，也存在明顯的“鄙視鏈”。BSD 的第一版撰寫者 Bill Joy 不愿意相信龐大的志愿貢獻者者們，他曾說：“大多數人都是糟糕的程序員，讓很多人盯著代碼不會真正發(fā)現錯誤。真正的錯誤是由幾個非常聰明的人發(fā)現的。大多數人看代碼不會看到任何東西......不能期望成千上萬的人做出貢獻并都達到高標準。”

這種看法一直存在于 BSD 之后的發(fā)展中，FreeBSD 深度參與者 Marshall Kirk McKusick 就曾表示，90% 的 committers 所貢獻的代碼都不能用，還剩下的一小部分也需要被打磨。

• 遭遇信任危機

在 Python 社區(qū)，很多年內，Python 之父 Guido van Rossum 都是最有威信的那個人，他也被社區(qū)授予“終身仁慈的獨裁者”的稱謂。但在 2018 年，當 Python 社區(qū)探討改進提案時，Guido 發(fā)現“現在有這么多人鄙視我的決定”。

因此，他不想再為 PEP（Python 改進提案）[ PEP 572 ] 爭取什么，并決定自己將逐步脫離決策層，不再領導 Python 的發(fā)展，休息一段時間后將作為普通的核心開發(fā)者參與社區(qū)。

有時，“仁慈的獨裁者”也會因為“不作為”被指責。Ubuntu 創(chuàng)始人 Mark Shuttleworth 在社區(qū)中被戲稱為“自封的仁慈獨裁者”。事實上，Ubuntu 社區(qū)早期也確實是“仁慈的獨裁者”管理模式。 

然而，在 Ubuntu 社區(qū)蓬勃發(fā)展，各項業(yè)務步入正軌之際，Mark Shuttleworth 本人的工作逐漸與開發(fā)者拉開距離，Jono Bacon 等一些早期在 Ubuntu 社區(qū)中頗具名望的核心成員相繼離開，Mark Shuttleworth 也很少在社區(qū)活躍。逐漸，有一些資深的 Ubuntu 開發(fā)者認為社區(qū)正面臨“群龍無首”的尷尬局面，指責沙特爾沃思沒有盡到“BDFL”的責任。一位前 Ubuntu 開發(fā)人員在 Ubuntu 社區(qū)中留言指責 Mark Shuttleworth 作為 BDFL “放棄了社區(qū)，對社區(qū)治理的崩潰保持沉默”，令人失望。

Mark Shuttleworth 面對職責也欣然接受，承認自己在這些方面確實做得不夠好，并表達了“挫敗感”。

• 沒有回饋 

開源項目最容易讓人不滿的點還當屬“白嫖”，許多開源項目都是靠作者用愛發(fā)電，社區(qū)的汲取大于回饋，從而導致軟件作者身心俱疲。

前段時間轟轟烈烈的 Apache Log4j2 高危漏洞事件，攻擊者可以利用其 JNDI 注入漏洞遠程執(zhí)行代碼，影響了眾多項目和公司。此事也讓 Log4j2 的作者受到關注與批評，Log4j2 的維護者之一 @Volkan Yaz?c? 在推特上吐槽：Log4j2 維護者只有幾個人，他們無償、自愿地工作，沒有人發(fā)工資，也沒人提交代碼修復問題，出了問題還要被一堆人在倉庫里留言痛罵。

此前，PhantomJS 的核心開發(fā)者之一 Vitaly Slobodin 宣布辭任 maintainer ，不再維護項目，原因也是一個人發(fā)電太累：“我看不到  PhantomJS 的未來，作為一個單獨的開發(fā)者去開發(fā) PhantomJS 2 和 2.5 ，簡直就像是一個血腥的地獄。即便是最近發(fā)布的 2.5 Beta 版本擁有全新、亮眼的 QtWebKit ，但我依然無法做到真正的支持 3 個平臺。我們沒有得到其他力量的支持！”

貢獻者的不滿

當社區(qū)隨著項目生命周期的發(fā)展逐漸發(fā)生變化時，流程和規(guī)定上的改變不可避免，貢獻者間交流的氛圍也在不斷變化中。貢獻者對社區(qū)的不滿往往是從社區(qū)發(fā)生變化開始……

• 對項目或社區(qū)不再看好

一位 Debian 的包維護者 Stapelberg 在 2019 年寫了篇長文宣布自己要退出 Debian 的開發(fā)流程，逐漸減少參與 Debian 的維護和相關活動。主要原因便在于，他發(fā)現 Debian 整個開發(fā)評估流程非常遲鈍。

舉例來說，補丁的評估沒有截止日期，有時候他會收到通知說幾年前遞交的補丁現在合并了。Debian 的一些維護者出于個人喜好拒絕合作，維護者給予的個人自由度太高對 Debian 構成了嚴重影響。

在他對 Debian 的開發(fā)流程沮喪程度超過閾值之后，他便宣布退出，寫了文章，希望能激勵 Debian 作出改變。

在 LLVM 社區(qū)，2018 年一位名叫 Rafael Avila de Espindola 的資深開發(fā)者（LLVM 編譯器貢獻排名第五）發(fā)郵件宣布決定與該項目分道揚鑣。 原因在于近幾年的感受發(fā)生了變化，LLVM 日益龐大且變化緩慢，他也不贊成 LLVM 最近引入的社區(qū)行為規(guī)范。真正促使他做決定的是 LLVM 與一個公開根據性別和血統(tǒng)進行歧視的組織 Outreachy 進行合作，這讓他感到非常不滿。

除此之外，一些由公司主導的開源項目也會因為改變發(fā)展戰(zhàn)略招致不滿。

Qt 公司從 2021 年 1 月開始，將 Qt 5.15 作為僅供商業(yè)化的 LTS，現有的 Qt 5.15 分支將公開可見，但不會看到任何新補丁，只有付費賬戶才可以使用長期支持版本的 Qt 5.15 。

此舉引起了社區(qū)的強烈不滿，基于 Qt 開發(fā)的 KDE 社區(qū)的擔憂。有用戶在 Qt 官方公告下留言諷刺道：“所以，基本上您是在告訴所有忠實的開源用戶，現在他們將僅被視為商業(yè)客戶的 beta 測試者，并且作為獎勵，他們將只能下載非 LTS 版本。你們真是太親切了！”一位長期的 Qt 貢獻者，來自英特爾公司的開發(fā)者 Thiago Macieira 表示，至少對于他在 Qt 中處理過的代碼，他不會再參與修復、評論和審查后端錯誤報告。

• 反獨裁

與每個社區(qū)都有一個人或者幾個人的實際管理團隊向對應的是，在管理不當時，貢獻者會起身反抗“管理”。

幾個月前，Rust 審核團隊 (Moderation Team) 昨日公告稱，他們已集體辭職且即刻生效。團隊成員 Andrew Gallant 表示此舉是為了抗議 Rust 核心團隊 (Core Team) 不對除自己以外的任何人負責。

Rust 的管理者分為很多個團隊，比如核心團隊、審核團隊、發(fā)行團隊、庫管理團隊等等...其中，Rust 核心團隊的權限最大，而且其他團隊無法影響他們。Andrew Gallant 在公告中寫道，由于核心團隊在組織結構層面的不負責任，他們一直無法按照社區(qū)對審核團隊的期望和他們自己堅持的標準來執(zhí)行 Rust 行為準則。對于在這種情況下選擇離開，他們表達了對大家的歉意。但從治理 Rust 的角度來看，他們別無選擇。因此 Rust 審核團隊認為除了辭職和發(fā)表這份聲明之外，已經沒有其他辦法了。

如何讓眾人滿意？

矛盾激化的后果只有一個：成員慢慢離開。如果社區(qū)和項目不做出改變，則很有可能導致項目走向衰落。既然長時間充斥著爭吵與不滿的社區(qū)難以持久，那么，該如何構建一個讓更多人愉快參與的社區(qū)？

首先，無論何種治理模式下的社區(qū)，個人文明表達觀點，遵守社區(qū)行為準則都是減少沖突的必要條件。但是，個人行為是非常不穩(wěn)定的因素，就像 Linus 曾說要改改自己的暴脾氣，卻每每被各種言論刺激，重回暴躁大佬。

其次，便是通過治理框架有效地管理社區(qū)，多權分立、避免獨裁，并且成員間相互約束，基于“共識”發(fā)展。具體來說便是有一份好的“手冊（原則、準則等）”，以及一個讓人信服、能公證管理的團隊。

比如在 Apache 軟件基金會中，便采用精英治理的模式。Apache Way 中對于決策、監(jiān)督、執(zhí)行等各方面都有明確規(guī)定：包括結構扁平，無論職位如何，各個角色間是平等的，投票權重相同，不允許有仁慈的獨裁者出現；單個項目由自選的活躍志愿者團隊監(jiān)督，傾向在達成共識的前提下決定項目發(fā)展，不能完全建立共識則用投票等方式做出決策；整個基金會的治理模型基于信任和委托監(jiān)督……

在開放原子開源軟件基金會中，項目的畢業(yè)標準考核中也有類似的關于社區(qū)需符合“賢能治理”的規(guī)定：

OA-CO-40

【英】The community strives to be meritocratic and over time aims to give more rights and responsibilities to contributors who add value to the project.

【中】社區(qū)要符合賢能治理的精神，隨著時間的推移，為項目增值的貢獻者會被賦予更多的權利和責任 

TOC 成員徐亮曾介紹，賢能治理這四個字是經過很多輪討論確定下來的。在英文語境中，這個詞是 meritocracy，并不完全是一個褒義詞，“我們并不覺得用 meritocracy 形容社區(qū)是完全正確的事情，但是我們又覺得在開源社區(qū)中，所謂的能者上氛圍是比較積極向上的，是社區(qū)能夠健康運轉的主要因素?！?/p>

在許多項目中，一方面大家是貢獻者，另一方面，每個人提交的功能越重要，或者對項目本身做出了更有意義的貢獻，就更有可能被現任維護人員選中去承擔更重要的角色。通過這種方式達成的精英治理或是賢能治理，往往是希望能夠讓項目可以自己成長，更好地走下去。

Ubuntu 的創(chuàng)始人 Mark Shuttleworth 在遭到信任危機之后，便著手參與將 Ubuntu 轉向經營治理的模式。目前，Ubuntu 社區(qū)也重新組建了由 3 名核心成員組成的管理團隊，分別是 Ubuntu 社區(qū)代表 Monica Ayhens-Madon，Ubuntu 開發(fā)者關系負責人 Rhys Davies，以及臨時社區(qū)經理 Ken VanDine。Ken 還將負責繼續(xù)為 Ubuntu 社區(qū)尋找一位合適的社區(qū)總監(jiān)。

最后，借用一個當下共識：開源比以往任何時候都更加重要。也因此，維護一個好的社區(qū)氛圍，正尤為重要。