社群糾紛不斷:程式設計師何苦為難程式設計師

語言: CN / TW / HK

日前,因為被多人侮辱大吼,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 ] 爭取什麼,並決定自己將逐步脫離決策層,不再領導 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 社群尋找一位合適的社群總監。

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


你最喜歡哪個開源社群的氛圍?歡迎在評論區暢所欲言。

延伸閱讀:

Linus Torvalds 2020 年度騷話集錦

Python 之父宣佈退出決策層,Python 該何去何從?

LLVM 開發者退出事件持續發酵,Swift 語言之父迴應

Debian 包維護者不滿 Debian 開發流程,宣佈退出

Log4j2 維護者吐槽沒工資還要捱罵,GO 安全負責人建議開源作者向公司收費

Debian 包維護者不滿 Debian 開發流程,宣佈退出

Qt 5.15 轉入商業化 LTS 階段,導致外部貢獻者棄坑

因不滿社群變化,LLVM 資深開發者髮長郵件宣佈退出

使用者發帖稱官方技術版塊不該參與政治,Rust 社群鎖帖

Rust 稽核團隊集體辭職

被多人侮辱大吼,Swift 之父正式退出 Swift 核心團隊

Log4j2 維護者吐槽沒工資還要捱罵,GO 安全負責人建議開源作者向公司收費

PhantomJS 核心開發者宣佈退出,專案或面臨困境

某科技公司領導稱 80 後該退出 IT 行業