出品 | OSC開源社區（ID：oschina2013)

今年年初，我們報道“因為被多人侮辱大吼，Swift 之父正式退出 Swift 核心團隊”。

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

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

眾口難調

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

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

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

掌權者的不滿

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

• 對貢獻不滿
  

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

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

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

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

• 遭遇信任危機
  

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

因此，他不想再為 PEP（Python 改進提案）[?PEP 572?] （https://www.python.org/dev/peps/pep-0572/）爭取什么，并決定自己將逐步脫離決策層，不再領導 Python 的發展，休息一段時間后將作為普通的核心開發者參與社區。

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

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

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

• 沒有回饋?
  

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

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

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

貢獻者的不滿

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

• 對項目或社區不再看好
  

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

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

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

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

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

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

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

• 反獨裁
  

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

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

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

如何讓眾人滿意？

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

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

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

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

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

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.

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

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

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

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

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