Go 是社區驅動嗎?哪種模式更好?
本文繼續基于對兩篇文章的前因后果的補充,基于《Is Golang truly community driven and does it really matter?》,煎魚對內容有所調整和補充。
快速背景
幾年前在 Hacker News 社區,針對 Go 的一個問題引發了激烈的辯論:“Go 是 Google 的語言,而不是社區的”。
這個討論最初是由在多倫多大學計算機科學系工作的 Chris Siebenmann(下稱:他)發起的。
圖片
他在博客文章中寫道:“Go 有社區貢獻,但它不是一個社區項目。它是 Google 的項目。”
為什么 Go 不是社區的語言
Chris 明確指出,社區的聲音對于 Go 的發展并不重要,我們必須接受這一點。他認為:Google 是 Go 社區貢獻的守門人;只有 Google 獨自決定什么是被接受的,什么不被接受。
如果開發者想要一些重要的特性被接受進 Go,與其與社區建立共識,遠不如說服 Go 核心團隊重要。
他引用了一個例子:Google 的 Go 核心團隊成員之一(指的是現在的 Go 核心團隊負責人 rsc)放棄了社區一直在努力開發的 Go 依賴管理系統(指的是 dep 等),并引入了一個新的、相對激進的不同模型,也就是現在的 Go Module。
注:這里講的是好多年前,Go 還沒有官方的模塊管理。社區自發的有 godep 等各種工具。一開始談好要基于某一個社區工具繼續開發轉成官方的。結果后面 rsc 等覺得不好用,最終自研了官方的模塊管理,直接一紙之下取代了。
期望和對比管理方式
Chris 期望的是:Go 核心團隊要關心社區,并希望他們參與建設,但要限制在一定的程度的參與度。他希望 Go 核心團隊能坦率地誠實地說明情況,而不是假裝并誤導人們。
他進一步補充說:“只有當 Go 核心團隊成員開始離開 Google,并嘗試繼續積極參與決定 Go 的方向時,我們才能確定 Go 是一個社區驅動的語言。”
他將 Go 與 C++ 進行了比較,稱后者是一個真正的社區驅動語言。
圖片
他說 C++ 有多個主要實現,這些都是真正的社區項目,C++ 的方向由一個開放標準委員會決定,成員分布相對分散。
圖片
社區驅動還是企業所有的區別
開發人員中一直流傳著這樣一種觀點:一些開源編程項目只是主要由一家公司驅動的商業項目。
我們看一下業內的頂級開源項目,它們中的大多數都有某種企業合作、支持,甚至直接的資金援助。
例如:
- 蘋果的 Swift;
- 甲骨文的 Java、MySQL;
- 微軟的 Typescript;
- 谷歌的 Kotlin、Go、Android、MongoDB、Elasticsearch;
僅舉幾例。這就引出了一個問題:企業對開源項目的所有權到底意味著什么?
仁慈的獨裁有兩種結果。
如果某個項目基于社區建議進行修改,而修改又是個壞主意,企業團隊可以進行干預,阻止修改。
但另一方面,反過來看,即使核心團隊的少數成員不同意,也可以阻止社區的好想法得到實施。
社區觀點
Chris 的帖子在 Hacker News 上引起了開發者的廣泛關注,他們既支持也反對提出的觀點。
以下是摘取的有一定觀點的評論:
- 網友 A:擁有一個社區并與它合作很重要,但尤其是對于編程語言來說,必須有一個清晰的概念,哪些特性應該實現,哪些不應該——僅僅為了使社區感覺良好而接受社區貢獻將是錯誤的方式。
- 網友 B:許多人喜歡 Go 是因為它是一種有觀點的語言。我不確定一個社區運行的語言會創造出像那樣的東西,因為意見太多。許多人聲稱代表社區,但不是那些不分享他們觀點的社區。沒有明確的領導者,我擔心技術方向和品味將變成政治,這似乎更不確定和風險。
總結
整體看來,似乎沒有完美的答案。因為幾乎所有所謂的成功的頂級項目,背后都一定有各大公司的影子,只是或多或少罷了。
Go 這一門編程語言的模式,可能也是一種比較另類的成長方式。現在被抨擊的點,有些也是直接太狠直接推翻社區導致的。
另外結合 Go 的發展歷程來看,如果 Go 不是誕生于 Google 團隊內部,可能發展和當紅的也不會那么順利,與云原生的結合可能也會沒有那么深。