開源,還能走多遠?
【編者按】在各大廠紛紛擁抱開源的當口,“開原始碼面臨可持續發展危機”的言論也甚囂塵上。早期,技術愛好者們“用愛發電”,“他們知道在出問題前,沒人會注意到他們,沒人會重視他們”。但遺憾的是,很長一段時間裡,很多從開源中謀取暴利的人,卻“沒有為開源社群做出過貢獻,他們將開源當成禮物直接拿走”,留給開源貢獻者無限的陣痛——從開發者到經濟學家們不禁發問,開源,還能走多遠?
本文剖析了以開源軟體為基礎開發的複雜業務,討論了建立在免費開源開發者之上的網際網路能否可持續發展的問題。
作者 | Daniel Oberhaus
譯者 | 彎月
責編 | 仲培藝
來源 | CSDN(ID:CSDNnews)
以下為譯文:
Stephen Henson 稽核通過了一個網際網路漏洞的時候,正值 2011 年跨年夜的午夜。
這位 43 歲的英國軟體開發人員接受了有關 OpenSSL 程式碼的一處很小的改動,OpenSSL 是一種開源加密協議,其可以保護網路上的很多內容。OpenSSL 是開源的,任何人都可以線上檢視其程式碼,並自願貢獻專案程式碼,但這並不意味著真的有很多人做出了貢獻。
Henson 在 OpenSSL 上花了十多年的心血,OpenSSL 有一個很小的團隊,加上其他核心成員也從未超過 3-4 個開發人員。到 2011 年底,他與其他核心開發人員需要負責維護一個包含大約 50 萬行程式碼的程式碼庫,其中絕大部分是由 Henson 自己編寫或批准的,這個責擔子可不輕。 OpenSSL 保護了大量的 Web 伺服器(網際網路中三分之二的網站都用到了這些伺服器),以及電子郵件伺服器、聊天伺服器、VPN 以及軍事、政府和金融機構的網路基礎設施。
12 月的那個晚上,Henson 批准的程式碼變更是由一位名叫 Robin Seggelmann 的德國開發人員提交的,他幫忙編寫了 OpenSSL 的“心跳(heartbeat)”標準。在這項程式碼變更被批准之前,Henson 和 Seggelmann 已經在這段程式碼上工作了數週時間,但仍未能發現這個 bug:允許攻擊者攔截傳遞給由 OpenSSL 保護的任何站點的資訊。
後來, Seggelmann 承認了程式碼中的 bug——這就是著名的“心臟出血”(Heartbleed)漏洞,雖然這是一個“非常微不足道”的小改動,卻成為了歷史上最危險的軟體漏洞之一。對於像 Henson 這樣經驗豐富的人來說,應該很容易發現並修復這個 bug——但是每個人都會犯錯誤。實際上,在 Google 的一位程式設計師後來於 2014 年發現並修復了這個 bug 之前,它已經在 OpenSSL 程式碼中存活了將近兩年半的時間。儘管如此,如今這個漏洞依然存活於數十萬臺裝置上,其中許多裝置不太可能得到修復。
OpenSSL 只是成千上萬開源軟體程式中的一個,數百萬人每天都依賴這些程式來瀏覽網頁或觀看視訊,實時翻譯或在智慧手機上使用語音識別功能等。這些專案都是開源的,這意味著任何人都可以免費檢視或使用這些程式碼。
自從開源建立以來,開源開發的最大賣點之一就是軟體開發人員 Eric Raymond 提出的“林納斯法則(Linus’s Law)”,還有人認為那麼多的人檢視這些程式碼,所以“所有的錯誤都會浮出水面”。因此,在心臟出血 bug 被修復後,每個人心中最大的疑問是:這麼關鍵的一個漏洞為何會被忽視如此之久,而其他開源專案的程式碼中是否也存在類似的漏洞。
注:林納斯法則即“足夠多的眼睛,就可讓所有問題浮現”。
正如 OpenSSL 基金會的前任執行長 Steve Marquess 在部落格文章中指出的那樣,心臟出血可以歸因為開發人員的筋疲力竭以及資金的匱乏。據 Marquess 所言,該基金會的捐款預算不到 2 千美元,每年簽署的合同收入不足 100 萬美元,且無法承擔更多合同,因為其開發人員(其中許多人有全職工作和家庭)根本沒有時間。
Marquess 還表示,實際上 Henson 是唯一一個全職工作的 OpenSSL 開發人員,而且以他的技術實力如果換作其他地方他所得到的報酬遠不止如此微薄。 “這些人並不是為了錢而在 OpenSSL 工作,他們也不是為了出名。他們這麼做只是出於對技術的自豪感以及對他們所信仰事物的責任……他們知道在出問題前,沒人會注意到他們,沒人會重視他們。”
開源惡疾:把開源當成天賜禮物“搶”走的人
很顯然,全球網際網路的安全性僅靠一位拿著微薄薪資的程式設計師嘔心瀝血的無私奉獻來支撐著,這本身就是很大的問題,那麼誰應該擔負起責任呢?Marquess 認為應該由“廣泛使用 OpenSSL,並將其視為理所當然的商業公司和政府”站出來。
Marquess 在文中寫道:“我說的就是你,世界 1000 強公司,那些靠銷售包含了 OpenSSL 產品賺取利潤的人;那些弄不清楚如何使用 OpenSSL 就來纏著我們要免費諮詢服務的人;那些從來沒有為開源社群做出過貢獻,卻把 OpenSSL 當成禮物拿走的人。”
Marquess 和 Henson 都於 2017 年離開了 OpenSSL,但在臨走前他們還為這個專案做好了近期的籌劃。在他們離開後,OpenSSL 的核心開發團隊已經發展到了 7 人,該專案的資金可以至少撐到 2021 年。這主要得益於 Linux 核心基礎設施計劃的大量資助——該計劃致力於向對網際網路安全至關重要的開源專案分配資源。該核心基礎設施計劃本身的資金來自亞馬遜、Google、IBM、微軟、Facebook 和英特爾等主要科技公司的捐款。這筆資助意味著 OpenSSL 是安全的——只要這些公司繼續捐贈。
從表面上看,如今的開源軟體社群非常繁榮。各家公司和政府正在以 20 年前難以想象的速度採用開源軟體,而新一代程式設計師正在開發軟體,並且可以隨意使用。然而,深入觀察你會發現問題已經開始顯現。
開源的優勢地位給流行軟體的維護者帶來了沉重的負擔,如今他們需要處理比以往更多的 bug 報告、功能請求、程式碼審查和程式碼提交。與此同時,開源開發人員還必須處理不斷湧入的不熟悉社群規範的企業使用者生產和使用開源軟體。這導致開發人員疲於應付,並對依賴免費勞力來生產軟體的公司產生了不滿情緒,這些公司利用開源軟體打包成產品後賣給消費者以獲取鉅額利潤。
從這個角度來看,心臟出血並不是唯一一個開發人員精疲力竭和資金匱乏的例子,而是多年以來在開源軟體社群內逐漸惡化的系統性疾病的產物。確定這種疾病的症狀和原因很容易,但想找到治療方法卻很難。
許多開發人員與 Marquess 一樣認為開源發展的主要問題在於財務,如果大型科技公司能夠為他們所依賴的開源軟體專案貢獻更多資源,那麼這些問題就可以得到解決。從理論上講,這可以讓開發人員在開源專案上投入更多時間,並激勵其他程式設計師為開源專案做貢獻。
然而,僅靠在開源社群投入資金還遠遠不夠。關於如何分配增加的資金以及如何回報提供資金的組織,這本身就是問題。事實上,資本的湧入有可能破壞社群驅動的基礎,而近半個世紀這個基礎一直支撐著開源的發展。
免費提供啤酒:開源軟體的經濟基礎
為了理解當前關於開源軟體經濟學的爭論,我們有必要回顧一下其歷史發展的背景。這可以追溯到 80 年代早期麻省理工學院的人工智慧實驗室。
那是一個 Marvin Minsky 等電腦科學先驅與 Richard Stallman 和 Guy Steele 等新一代黑客交鋒的時代,後者憑藉自己的實力從根本上改變了計算機程式設計世界。Steele 在編寫和建立 Lisp 和 Scheme 等程式語言方面起到了重要的作用,而 Stallman 為自由軟體運動奠定了基礎——這是自 Luddism 以來對技術仲裁者的最大挑戰。
在最近一次接受 New Left Review 的採訪時,Stallman 描述了麻省理工學院的人工智慧實驗室培養了一種合作與激進開放的文化,以至於實驗室的巨型計算機沒有密碼保護,實驗室的大門始終處於無鎖狀態。可以肯定的是,Stallman 承認這些開放的文化是環境的產物:例如 Minsky 總是丟鑰匙,而實驗室裡的研究人員不得不共享龐大的計算機,因為這是唯一的一臺。儘管如此,該實驗室的精神還是給 Stallman 留下了深刻的印象。
1983 年,他向 Usenet 小組(這基本上是一個論壇的原型)釋出了一條訊息,他宣佈打算建立一個作業系統並“免費送給所有想要使用的人”。Stallman 稱這個作業系統為 GNU(Gnus Not Unix),這是對當時主流專有作業系統(即 Unix,貝爾實驗室內部使用的作業系統)的挑戰,而它的名字也蘊含了這一點。
GNU 開啟了自由軟體運動。1985 年,Stallman 在 GNU 宣言中總結了這一原則:“我認為黃金法則的要求是:如果我喜歡一個程式,那麼我必須與喜歡它的其他人分享。軟體銷售商希望分裂使用者並征服他們,讓每個使用者都答應不與他人分享。我拒絕這種破壞使用者團結的方式。”
Stallman 在討論自由軟體時使用“自由”這個詞的方式並不是很明顯。正如他喜歡的表達方式,自由軟體的“自由”意味著“自由言論,而並不是免費的啤酒”。換句話說,自由軟體的定義是道德要求,即將程式碼從對使用方式的限制中解放出來,但這並不一定意味著必然不收分文免費贈送軟體。自由軟體運動的基本原則於 1989 年正式編纂完成,而當時 Stallman 釋出了 GNU 通用公共許可證(General Public License,簡稱 GPL)——即現在更廣為人知的公共版權,它為自由軟體開發的爆炸式增長奠定了基礎。
Richard Stallman(右)正在展示“自由言論”與“免費的啤酒”之間的區別。圖片來源:Wikimedia Commons
兩年後,脾氣暴躁的芬蘭學生 Linus Torvalds 使用 GPL 釋出了他的免費作業系統核心 Linux。其核心經常與 GNU 軟體一起使用,自發布以來的三十年,GNU/Linux 已經成為世界上 Web 伺服器和個人計算使用最廣泛的作業系統之一。繼 Linux 之後,許多其他有名的免費軟體程式都在 GPL 或符合 GPL 標準的許可下發布,其中包括 Apache Web 伺服器軟體和 MySQL 資料庫引擎,兩者目前仍在廣泛使用。
在狂熱的網際網路泡沫中,當名不經傳的科技公司都獲得了令人憎惡的估值時,Stallman 由道德驅動的自由軟體運動提供了一種截然不同的視角來看待未來。與矽谷的風險資本家在辦公室裡大量炮製的空中數字城堡不同,自由軟體發揮了作用。Stallman 和他的助手證明了,通過結合道德信念和技術,可以構建出優秀的軟體,這些軟體能夠通過修改來滿足使用者的個性化需求。90 年代間曾有一個短暫的時期,軟體的未來似乎就在於自由——真正的自由。
後來,在 1997 年,一位名叫 Eric Raymond 的程式設計師發表了《大教堂和市集》(The Cathedral and the Bazaar),這篇文章分析了開發自由軟體的過程。Raymond 富有創意的文字和核心是他所謂的“林納斯法則”(Linus’s Law),主要思想是說如果足夠多的人共同開發一個軟體程式,那麼任何隱藏在程式碼中的 bug 就會被迅速捕獲和修復。從本質上講,Raymond 為自由軟體開發的效率打好了基礎。由於軟體是公開開發的,所以任何人都可以看到自由軟體程式的底層,這意味著任何程式碼中潛在的 bug 都會被迅速發現。林納斯法則的必然結果是:自由軟體可以更快地發展,因為任何人都可以針對軟體提出自己的改進,併傳送給專案的核心開發人員。
Raymond 的分析對自由軟體運動的影響非常大。在他的文章釋出之後,網路瀏覽器 Netscape(它曾是世界上最有價值的一個軟體)公開了它的原始碼,並引用 Raymond 的文章作為該決定的“基本靈感”。很明顯,Raymond 的宣言引起了一些矽谷人的注意,他們意識到了自由軟體的商業潛力。
但還有一個問題:自由軟體運動揹負著重要的道德問題,而道德對企業很不利。因此,1998 年在 Raymond 和嶄露頭角的媒體巨頭以及“大騙子” Tim O’Reilly 的領導下,一群高調的自由軟體傳播者聚集在一起,探討如何讓自由軟體對行業更具吸引力。正如 Raymond 後來描述的那樣,會上的開發者們針對“重新塑造產品品牌,將其樹立成企業界渴望購買的產品”為目標,開展了一場“營銷活動”。
Raymond 在一篇名為《開源:開源革命的聲音》的文章(https://www.oreilly.com/openbook/opensources/book/raymond2.html)中寫道:“回想起來,很明顯多年以來‘自由軟體’一詞對我們的運動造成了巨大的破壞”,“這與對智慧財產權的敵意和共產主義有著很強的聯絡。”他還指出,“Netscape 之後,[開源]的成功來自我們用積極的形象——更高的可靠性和更低的成本,以及更好的功能——取代了自由軟體基金會的負面刻板印象——根據實踐做事,取悅管理者和投資者。”
該小組的這個刻板印象被封裝到了“開源”一詞中,他們集中精力通過讓軟體原始碼“開放”,來回避自由軟體的道德維度。
回顧過去,這場營銷活動取得了巨大的成功。現在開源軟體成為了我們大多數人每天使用的技術平臺和服務的核心,包括微軟,其前執行長史蒂夫·鮑爾默曾將 Linux 和其他開源專案稱為“毒瘤”。而如今,微軟也將自己定位成開源開發的擁護者,Google、Facebook、亞馬遜、IBM 甚至美國政府皆是如此。另外說一句,通常自由軟體是指自由開源軟體(Free and Open Source Software,簡稱 FOSS)。
開源經濟學
儘管很快很多矽谷的大科技公司都接受了開源軟體,但經濟學家們仍在努力解釋這些專案適應了市場的慣例並取得了成功的原因。當時,自由軟體人群兜售的標準解釋是:自由軟體的開發可以在自由和利他主義的道德要求的基礎上持續發展。這似乎不足以解釋 Linux 等專案的迅速出現和廣泛採用。到目前為止,歷史上沒有任何一個其他行業能夠僅靠貢獻者的“善良”就催生出這種技術要求十分嚴格的專案。
這種顯著的異常現象引發了 21 世紀初的一系列研究,人們設法解釋開發人員如何通過他們對自由開源軟體生態系統所做的貢獻而“獲利”。簡而言之,這些經濟學家試圖解釋開源開發,讓這些程式設計師的行為符合經濟學家的理性生產者/消費者的概念:即所謂的“理性經濟人”。
2000 年,哈佛大學經濟學家 Josh Lerner 和麻省理工學院的 Jean Tirole 發表了開源開發的經濟學解釋。Lerner 和 Tirole 的這篇論文標題為《開源的簡單經濟學》(https://www.nber.org/papers/w7600),找出了開源開發人員所獲得的多項短期和長期的利益,開源開發中利他主義的作用被大大降低成了意外的副產品。簡而言之,Lerner 和 Tirole 聲稱開源開發的主要推動因素是開發人員獲得的經濟利益,而不是給予世界自由軟體的一些根深蒂固的願景。
Tirole 和 Lerner 認為,就短期利益而言,開源程式設計師可以通過在開發該軟體的公司工作而直接獲得工作的報酬,他們也可以通過修復 bug 或新增功能讓軟體進一步體現自己的價值。至於長期利益,開源程式設計師可以通過開源開發來向未來的僱主或風險資本家展現他們的才能,從而推動他們的職業生涯發展,同時還提供了一種訊號機制,即開發人員可以從開源的同行那裡獲得技術支援的認可。
在該論文發表後,其二者對開源開發經濟激勵的解釋成為了新的“福音”。至今,開源經濟學還在大量引用該論文。
大約在 2000年,Lerner 和 Tirole 所認定的開源社群是一個人人都是贏家的系統,但在這之前的 20 年中,自由開源軟體生態系統在採用的規模和生產方式方面都發生了巨大的變化。這些變化很大程度上應該歸功於 Git 的創立,Git 是 2005 年問世的一個開源工具,為軟體開發提供了分散式協作。圍繞 Git 構建的服務,尤其是 GitHub,大大加快了開源開發的步伐,並大大降低了新的開發人員進入市場的障礙。這是 Lerner 和 Tirole 所預見的一個問題,他們在 GitHub 出現大約 10 年之前就曾質疑“開源專案的管理是否能夠容納越來越多的貢獻者”。
通常開源貢獻者數量的迅速增加被認為是對其開發正規化的驗證。然而,在過去十年中,越來越多自由開源軟體的開發人員開始談論維護開源庫時的不堪重負。許多開發人員指出,使用者權利是這種不堪重負的主要來源。正如開發人員 William Gross 所描述的那樣,依賴開源軟體的公司不斷增加,這意味著開源開發人員需要處理越來越多大量的功能請求和程式碼的問題,而且許多公司都認為他們的改進和問題應該得到優先考慮。換句話說,似乎開源社群中的許多熱門專案都必將成為成功的受害者。
Lerner 和 Tirole 認為,許多自由開源軟體的開發人員開始懷疑僅靠個人志願者的善意而展開的軟體開發模式是否可以大規模地持續發展。只不過我們很難確定這個問題。有些開發人員將其視為一種文化問題,他們認為可以通過一些措施來加以解決:向新手傳授成為優秀使用者的守則,並且要讓維護人員知道拒絕貢獻也無可厚非;還有人則認為,從根本上說,這是一個可以通過更多資金解決的經濟問題;還有人則否認存在任何系統性的問題。
開源的悲劇
2015 年,Nadia Eghbal 辭掉了她作為風險投資家的工作,並著手開始研究為什麼許多開源專案很難通過他們的成果賺錢。Eghbal 告訴我們,在她反覆聽到自由開源專案的廣泛使用後,開始對開源軟體的經濟學產生了興趣,但卻無法弄清楚如何為其開發提供資金。對於 Eghbal 來說,這裡面似乎存在著矛盾。許多流行的開源專案都具有創業成功的所有特點:快速採用、龐大的使用者群以及低成本的開發。然而,大多數這些專案都會成為風險資本的詛咒,投資者只關心軟體是否會帶來巨大的回報。那麼,問題就在於我們需要確立一些可以持續為開源提供資金的機制。
為了找到解決方案,Eghbal 去採訪了問題的源頭:開源專案的維護者。在對數百名開源開發人員進行了長達一年的採訪之後,Eghbal 釋出了文章《道路與橋樑》(https://www.fordfoundation.org/about/library/reports-and-studies/roads-and-bridges-the-unseen-labor-behind-our-digital-infrastructure),這可以說是有史以來開源軟體開發經濟學方面最廣泛的研究。
Eghbal 的報告將開源軟體視為一種非排他性的公共產品。這是社會科學中的一個技術術語,意思是任何人都可以使用的資源,例如無論他們是否支付過道路和橋樑費。非排他性的公共產品是健康社群的基石,但它們也受到經濟學家所謂的“搭便車問題”和“公地悲劇”的影響。
搭便車問題比喻的是一種情況:因為沒有辦法阻止那些沒有付款卻使用商品的人,從而導致商品過度消費或生產不足。根據定義,開源是一種非排他性的商品。例如,像 Google 這樣的公司可能會花費大量資源來開發開源工具(例如機器學習平臺 TensorFlow 等),但由於這些工具是開源的,所以 Google 也無法阻止其他公司的使用。如果出現太多使用 TensorFlow 卻不對其維護做出同等貢獻的公司,那麼就可能會導致該軟體生產力不足,因為維護人員無力承擔過量的使用者提交的功能請求或 bug 報告。
搭便車的問題與公地悲劇息息相關,公地悲劇描述的情況是:社群所有的成員都受益於對公共物品的無管制訪問,但是沒有人有動力承擔維持該商品的成本。如果社群的每個成員都根據自己的利益使用公共物品,那麼最終該物品會被耗盡,社群中的人都將無法再使用。對於自由開源軟體來說,公共物品就是數十億行的開原始碼。雖然程式碼本身不能像食物或土地等其他經濟商品一樣被耗盡,但其耗盡的資源是負責開發和維護程式碼的程式設計師的注意力和精力。
公地的悲劇是經濟學中一個經過充分研究的問題,但 Eghbal 意識到這個問題常見的解決方案(即將公地變成私有或受監管的商品)在開源軟體開發方面並不適用。將軟體變成私有產品會破壞開源開發的整個過程:高效開發的高質量軟體,任何人都可以根據需要使用。
另一方面,規範化開源軟體的生產(例如,建立類似於國家科學基金會的組織,將公共資助的資產分配給開源軟體專案)會破壞開源軟體開發的主要優勢。監管所帶來的穩定性是以效率為代價的,而在快節奏的軟體開發領域,這根本就行不通。此外,監管也會破壞開源開發的精神,因為這可能導致設立門檻以決定哪些人可以貢獻程式碼,而哪些人可以消費資源。
有些開源維護者試圖按照過去使用他們的軟體的方法來規範化開源軟體,例如禁止與移民和海關執法部門合作的公司使用該軟體。但這遭到了開源社群的強烈反對,最終被撤銷,這證明了人們深信開源軟體應該向所有人免費提供。另一方面,有關開源社群的訪問規則已經浮出水面,這可能會成為開發人員不堪重負問題的解決方案。正如開發人員 William Gross 在文章中指出的那樣,在這種“開源,封閉社群”的模式中,如果有人想訪問開發人員工作的社群,則實質上需要支付費用。
“我們向使用者傳達的資訊應該是:‘你可以隨心所欲地利用程式碼做任何事情,但是如果你想影響專案的未來,那麼請為我們的工作支付報酬’”,“這會導致出現一個更小規模的社群以及更多的分支嗎?肯定會。但是,如果你堅持不懈地建立自己的願景,併為其他人創造價值,那麼如果他們想有所貢獻就會付錢。”
對於那些不願意守護開發社群的維護者而言,另一個最合乎邏輯的解決方案似乎是要求開源軟體使用者通過聘請該專案的開發人員來支援開發。這種方法通過計算來確立開源的資金,即找出誰是開源專案的受益者,並確保他們儘可能多地回饋生態系統。雖然我們沒有中央資料庫能夠跟蹤世界上所有的開源貢獻者,但有一樣東西已經非常接近了——那就是 GitHub。
GitHub 於 2008 年問世,雖然它不是唯一一個程式設計師用來儲存、審查和討論開源軟體的地方,但它相當於自由開源軟體社群的市政廳。如今,這個線上軟體倉庫擁有來自世界各地大約 2500 萬名貢獻者所建立的超過 1 億個程式碼倉庫。促使這 2500 萬人為開源開發做出貢獻的動機有多個方面,但根據開源 Web 開發框架 Ruby on Rails 的建立者 David Hansson 的說法,在過去的二十年裡,開源貢獻者的情況發生了根本性的轉變。
“絕大多數開源軟體(尤其是與網路相關的軟體)的資助都是由公司出面贊助開發人員處理那些對他們很重要的問題”,“這是一種與 Richard Stallman 的自由軟體不同的方式,Richard Stallman 的自由軟體只談論到了人們自行編寫軟體,而這個非常出色的模型可以為我們提供一系列開源軟體。”
圖片來源:Cathryn Virginia/Motherboard
這並不是說在閒暇時間推送程式碼的開源程式設計師在自由開源軟體社群不是特別受歡迎。Hansson 特別讚揚了這些“熱情的愛好者”,他們是自由開源軟體生態系統的基石。仔細閱讀 2017 年 GitHub 上的主要貢獻者名單就會發現,Hansson 說得沒錯——Google、微軟、亞馬遜、IBM、Facebook、騰訊、百度、紅帽和英特爾的員工都是最活躍的開源貢獻者。所有這些公司都是營利性的,每年從基於開原始碼的產品中可以獲得數百億美元的收入。我聯絡了其中幾家公司,請求他們回應開發人員說他們沒有回饋開源社群的指控。那些回應了我的請求的公司快速地捍衛了他們對開源開發做出的實質性貢獻。
IBM 開放技術副總裁 Todd Moore 指出,自 90 年代中期以來,該公司一直在為開源專案做貢獻,包括他們在 Linux 和 Apache 尋求立足之地時給予的資助。據 Moore 所說,1200 多名 IBM 的員工在工作和閒暇時間為 1000 個開源專案做出了貢獻。Moore 表示“很多”IBM 員工在全職為Linux、Kubernetes、Java 和 Node.js 等開源專案工作,而且該公司每年都會向各個開源社群的頂級 IBM 開發人員提供獎勵。(Moore 拒絕提供有關獎勵性質或他們對開發者社群影響的更多資訊。)
他強調,“在過去的 10 年裡,我們通過資助每一個主要的開源基礎幫助建立了如今的開源革命”,“IBM 鼓勵員工為開源效力。”
IBM 還舉行了一個年度認證計劃,“幫助 IBM 員工瞭解與開源有關的價值和風險,並提醒他們內部治理的流程。”該教育研討會還包括“成為某個專案或社群積極成員的最佳實踐指南”。據 Moore 所述,有 72000 多名 IBM 員工已獲得了該計劃的認證。
Google 開源主管 Chris DiBona 也提供了類似的資訊:
“自公司成立以來,自由和開源軟體一直是 Google 技術和組織基礎的一部分。”,“拉里·佩奇和謝爾蓋·布林為 Linux 和商用硬體做了很多貢獻,而且多年以來 Google 員工也在開源許可下發布了數百萬行的程式碼。”
雖然 DiBona 拒絕提供在開源專案上全職工作的 Google 員工的確切數目,但他表示該公司在 GitHub 上擁有 2000 多個活躍的開源專案。特別是由 Google 建立並得到廣泛使用的開源專案,而且每天都有員工為其效力的例子,DiBona 重點強調了程式語言 Go 和容器軟體 Kubernetes。
“你幾乎找不到一位沒有為開源專案做出過貢獻的 Google 技術員工。”
“Google 鼓勵員工開展與他們的工作、興趣或愛好相關的開源專案。”DiBona 還指出,據 2018 年的資料顯示,Google 員工佔 GitHub 所有活動的 1% 以上,這就是該公司及其員工緻力於開源開發的證據。
Google 和 IBM 等公司通過要求或鼓勵員工開發開原始碼,直接為開源社群做出了貢獻。許多公司還向 Linux 基金會、Apache 基金會或 Mozilla 基金會等非營利組織提供了捐款,現如今這些組織擁有數百萬美元的捐贈基金。
然而,個別開發人員提出的問題不在於這些科技巨頭是否為開源做出過貢獻;而是這些公司做得貢獻是否足夠,以及這些貢獻是否用到了正確的專案上?
開源 Web 開發框架 Django 的聯合創始人 Jacob Kaplan-Moss 認為,這些價值數十億美元的公司需要為開源社群做出更多貢獻。 Kaplan-Moss 特別指出了 GitHub(最近微軟以 75 億美元的價格收購了 GitHub),並建議如果 GitHub 真關心開源,就應該把這筆交易的一半收益交給該軟體的維護者和貢獻者。
“開源軟體不堪重負的根本原因是資金,”Kaplan-Moss 在推文中說,“解決這個問題的唯一方法就是金錢。那些依靠開源軟體賺取數十億美元的科技公司幾乎沒有給予任何回報。他們現在就可以解決這個問題,而且幾乎不會影響他們的利益。如果這些公司真的關心開源軟體,而不是為了彰顯他們的美德,那麼他們就應該把這些鉅款變成對開源維護者和基金會的支援。”
Hansson 雖然不反對為開源專案提供更多的資金,但當涉及“開源與資金掛鉤的風險”時,他採取了更為謹慎的立場:
“如果你有一個擁有幾百個貢獻者的專案,而且你開始為一些工作設定特定的金錢獎勵,那麼我覺得很快你就會進入非常危險的境地”,“對於那些只是為了社群、個人愛好、或創造力而為開源工作的人來說,他們並沒有從經濟學的角度來審視自己的工作,一旦出現金錢獎勵,那麼他們也要突然被迫從市場的角度考慮他們的時間投入了。我認為在很多情況下,這種做法都會造成很大的損害。”
有關這方面的損害,Hansson 以自己在 Ruby on Rails 做貢獻時的故事為例子進行了說明——當他剛開始為 Rails 工作時,他被功能請求和 bug 報告等壓得喘不過氣來,而且大量的電子郵件都希望他能夠解決所有的問題,就好像他是軟體供應商一樣。然而,由於完全不涉及市場價值,所以 Hansson 當時的心態是“去你媽的”,他說經證實這種心態是抵抗自由開源軟體社群猖獗地壓榨開發人員的“頭號防禦機制”。如果他因為拿了錢而工作,那麼他就有義務滿足客戶的要求。然而,也正因為他自願為社群專案做出的貢獻,所以也沒有人會對他表示感激。
Hansson 表示,“我免費提供了軟體,所以如果你想幫忙把這個軟體做得更好,那肯定非常好啊,我們可以一起加油”,“但如果你想站在一旁,叉著腰對我大吼大叫說這個軟體很差勁,那麼我會跟你說去你媽的,我又不是為你工作。”
開源社群中肯定不會有人覺得為自由開源軟體提供更多資金是一個徹頭徹尾的壞主意。即使是 Hansson 這樣常常批評將金錢與開源混為一談的人也提倡在某些情況下應該注入更多資金。總體來說,開源社群面臨的難題不在於擁有更多的資金是不是一個好主意,而是這些資金應該如何分配。
自由軟體並非免費
Hansson 認為企業贊助是支援開源專案最有希望的方式。這其中有很多種形式。有些公司向為支援特定開源專案而建立的非營利基金會捐款。例如,IBM、英特爾、Google、微軟都是 Linux 基金會的“白金捐助者”,他們聘請了全職開發人員為 Linux 核心工作。各個公司支援開源專案的另一種方式是聘請開發人員在公司全心全意為開源工作,或允許員工將部分工作時間用於編寫開源專案。
然而,將支援開源專案的重任交給各大科技公司並非沒有風險。從本質上講,開源開發是分散的。然而,如果由一家公司負責支援某個專案大部分的核心開發工作,那麼這種集中化將成為極大的風險,因為這家公司可以隨時決定停止為該專案提供資金。
此外,向開源專案投入人力的公司顯然會優先考慮按照對公司本身最有利的方式開發該專案。雖然這本身並不一定是壞事(例如對 Google 有利的事情可能對許多其他使用該軟體的公司也有好處 ),但也可能會犧牲軟體使用方式的多樣性。
有關這方面的一個例子就是 Android 作業系統的開發,該系統在全球智慧手機中佔 86% 的份額。Android 是開源的,但幾乎所有關於作業系統的開發工作都是在 Google 內部完成的。與此同時,Google 還出資讓工程師開發一些專有的應用程式,通常這些應用(例如 Google 地圖和 Gmail)被視為 Android 作業系統最大的賣點。
因此,雖然任何人都可以利用開原始碼自由建立自己的 Android 作業系統,但 Google 有一項政策,禁止在任何非官方的 Android 作業系統上使用其應用程式。這項政策是合理的,因為這項政策有益於應用開發人員——他們的應用程式無需適應幾十個略微不同的 Android 版本,但最顯著的後果是開源 Android 作業系統已經與專有的 Google 產品融為了一體。別的公司也可以在手機上免費使用自定義版本的 Android 產品,但這會讓他們承擔很大的風險。2014 年亞馬遜的 Fire 手機非常不明智地嘗試使用自定義的 Android 產品,結果以 1.7 億美元的損失慘淡收場。雖然缺乏 Google 的應用並不是這款手機失敗的唯一原因,但也是導致其失勢的主要原因。
然而,對於很多開源專案來說,即使想要接受企業的資助,也缺乏這方面的組織結構,軟體自由保護協會(Software Freedom Conservancy,簡稱SFC)的通訊主管 Deb Nicholson 表示,他們是一個為開源專案提供基礎設施支援的非盈利組織。事實上,Nicholson 表示,自該組織成立十年以來,他們的主要工作就是作為一種聯盟的組織,代表其成員的 50 個開源專案接受資金。這些專案包括只有寥寥幾個貢獻者的小型運營,也包括 PHP 和 Git 等從根本上改變了我們使用網際網路方式的大型專案。
在眾多為開源專案提供機構支援的非盈利機構中,軟體自由保護協會只是其中之一。其他組織(例如公共利益軟體和自由軟體基金會)提供了各種其他服務,例如法律建議,或為開源專案成功執行提供所需的物理基礎設施(伺服器、辦公空間等)。這些專案中的程式設計師都知道如何編寫好的程式碼,但他們往往沒有時間或資源來處理建立法人以及為專案建立管制組織的瑣事。這些非營利組織的作用就在於幫助這些專案解決這方面的難題,保證自由開源軟體專案能夠獲得所需的支援,而程式設計師則可以專注於他們最擅長的事情:編寫軟體。
從歷史上看,支援自由開源軟體的重任已經落到了這些非營利組織的肩上,然而一家名為 Tidelift 的新公司致力於通過市場的解決方案為開源社群解決資金的問題。這家由四名紅帽公司前員工創立的公司通過銷售 Linux 支援服務,最近成了科技史上排名第三的大筆收購的主角——IBM 以 340 億美元收購了該公司,而 Tidelift 則希望通過開源軟體的安全支援增加流向開源專案的資金。
Tidelift 的執行長 Donald Fischer 指出,採用開源專案的最大障礙(特別是在銀行等受到嚴格監管的行業中)在於缺乏軟體能夠按照預期執行的保證。與專有軟體不同,開源專案通常沒有客戶支援熱線。如果有一家公司使用了開原始碼,然後維護人員卻停止了工作,或者沒能及時解決 bug,那麼這家公司也無可奈何。
正如 Hansson 指出的那樣,從維護者的角度來看,這種選擇性地與使用者互動的能力在沒有獲利的開源專案中只是痴心妄想。Fischer 同意這一觀點,他認為如果程式設計師不想因為獲取了報酬,就將他們的開發時間花在為使用者提供客戶支援上,那也無可厚非;但是對於那些想為自己的勞動而獲得報酬的人來說,我們也應該為他們提供機會——加入 Tidelift。
Tidelift 有點像 Red Hat 為 Linux 所做的努力,但對於所有其他自由開源軟體專案來說:如果企業想獲得與他們使用的開源專案相關的支援服務,那麼他們就需要支付費用。正如 Fischer 向我描述的那樣,類似於 AirBnb 帶來了酒店業,Uber 帶來了運輸業,Tidelift 也想將相同的邏輯用在自由開源軟體社群。
Tidelift 通過自己開發的程式跟蹤了數百個開源庫中的變動,並以此跟蹤了程式碼的變更會對那些使用了這些服務的公司造成怎樣的影響。如果其中一個庫中的程式碼出現了安全性、許可或維護的問題,那麼 Tidelift 登記在冊的開發人員就會處理與該變更相關的任何問題。在這種模式下,各個公司需要向 Tidelift 支付固定的費用,Tidelift 抽取分成後會將剩下的分配給開發人員,而開發人員根據使用他們維護的程式碼的公司數量來獲取相應的報酬。
Tidelift 的模型類似於開源中最古老的一個集資機制:Bug 賞金。這基本上相當於一種協議,即向發現和/或修復某些開原始碼中已知 bug 的開發人員支付報酬。市場上湧現的很多服務都是為了滿足這一需求,其中包括在區塊鏈中支付賞金的 Gitcoin,歐盟於 12 月推出了面向 14 個開源專案的 Bug 賞金計劃(https://www.zdnet.com/article/eu-to-fund-bug-bounty-programs-for-14-open-source-projects-starting-january-2019/)。2017 年,一家名為 Code Sponsor 的公司致力於通過將開源專案與想在開源專案的幫助檔案中新增廣告的公司聯絡起來,從而實現開源專案的獲利。Code Source 後來改變了其業務模式,並重組為 CodeFund,它利用合乎道德的數字廣告為開源專案提供資金。
流行的開源專案中,一些比較活躍的開發人員已經通過 Patreon 等眾籌服務尋求支援,並自行籌集了資金。對於那些為知名開源專案工作的知名開發人員來說,這可能相當“有利可圖”。例如 Vue.js(一個用於建立使用者介面的開源 JavaScript 框架)的創立者 Evan You 每月可以通過 Patreon 獲得 1 萬 7 千多美元。
當然,Evan You 是開發人員中的一個例外。其他從事開源專案的程式設計師可以通過眾多資源獲得更多的報酬。Henry Zhu 最近辭職了,他開始全職為開源 JavaScript 編譯器 Babel.js 工作,完全依賴眾籌來支援他的收入,目前每個月他可以從 Patreon 上獲得大約 1500 美元的收入。
今年 1 月,GitHub 的開源專案經理 Devon Zuegel 在網站上寫了一篇名為《我們來談一談開源的可持續性發展》(https://github.blog/2019-01-17-lets-talk-about-open-source-sustainability/)的文章。該文章強調了開源社群中的一些問題,其中包括資源與治理不足、缺乏溝通、工作超負荷。Zuegel 懇請社群向服務於改善開源維護者和貢獻者等領域的公司提供資訊。
GitHub 產品管理高階主管 Kathy Simpson 告訴我,“我們所要做的事就是,傾聽那些正在構建軟體的開發人員的意見,給予他們大量支援,幫助他們建立對其將來有助益的工具。我們有義務保護這些專案和社群之間的結締組織,並幫助他們成長。”
“維護可能是一項非常具有挑戰性且吃力不討好的工作,”Simpson 補充道,“我們非常清楚這一點,而且我們希望盡我們所能全面推進。”
儘管表面上 GitHub 非常認真地設法幫助開源維護者,但對於 GitHub 的建議請求卻得到了不同的回應。有些開發人員歡迎 GitHub 嘗試改善執行開源專案的經驗,而有些人則對該公司所暗示的開源存在可持續性發展的問題表示不滿。
“對於那些已經在開源努力了 20 年的人來說,可持續發展性的觀點會非常令人感動。”Hansson 告訴我,“但如果你提出一個觀點說開源存在可持續性發展的危機,那麼你必須指出貢獻或專案數減少了,而不僅僅是幾個無關的事例。我認為有些專案確實陷入了一種奇怪的境況,這些專案中沒有從事自由職業的核心維護者,而且也沒有一家公司最終認為有必要直接資助這些專案,但我不覺得這可以代表普遍現象。”
開原始碼中是否普遍存在可持續性發展的危機,這是一個有爭議的問題,但這並不能否定我們需要找到一種解決方案,來解決難以找到資金和志願者來支援開發開源專案的必要性。無論這些是個別現象還是不斷上升的趨勢,無論是否有存在這樣的缺陷,開源開發人員繼續致力於開源專案這一事實證明了他們更加願意致力於專案和開源開發。然而,大多數開發人員都認為,如果有可持續性的方式為開源社群提供資金,那麼肯定可以開發出更好的軟體。
正如 Zhu 在去年參加 Eghbal 主持的一個播客系列“Hope in Source”(https://hopeinsource.com/)中所說的那樣,開源社群很像一個宗教團體,特別是在金錢方面。人們可以自由地組織這樣的宗教機構,以確保在那裡工作的人可以繼續進行組織的工作,而無需在外部尋找工作。這些有組織的宗教團體需要資金才能保證基層的運作,但他們最重要的資產不是金錢,而是人們聚集在一起讓這個社群成為現實。即使擁有世界上所有的錢,也無人可以創立這樣的宗教,或維持一個廣泛使用的開源專案。
“我們希望鼓勵人們參與進來,”,“在開源社群中,時間重於金錢。”
儘管如此,科技公司和其他使用者依靠資金不足和過度勞累的開發人員所維護的開源軟體來為現代社會提供動力,這種現象仍然是不公平的。雖然從一定程度上來看這是一個值得研究的問題,但實際情況還沒到這一步。正如 Eric Raymond 於二十多年前指出的那樣,開源的最佳特性之一就是其開放性以及社群驅動的開發模型能夠以更低的安全風險更高效地建立更好的軟體。
對於消費者產品以及關鍵性的網際網路安全基礎設施而言,世界變得越來越依賴於開源軟體,而且公司和使用者不能因為“心臟出血”這樣的災難性漏洞就相信維持這種開放式基礎設施需要付出代價。
原文:https://motherboard.vice.com/en_us/article/43zak3/the-internet-was-built-on-the-free-labor-of-open-source-developers-is-that-sustainable
(本文為AI科技大本營轉載文章,轉載請聯絡原作者)
精彩推薦推薦閱讀:
點選“閱讀原文”,檢視歷史精彩文章。
相關文章
- “魂Like”遊戲,到底還能走多遠?遊戲
- 預訓練語言模型:還能走多遠?模型
- 你在信奧上能走多遠?
- 亞馬遜無貨源店群模式,能走多遠? YMX973亞馬遜模式
- 停服第28天,內憂外患的Win7系統還能走多遠?Win7
- 我的小家:三消女性向小遊戲能走多遠?遊戲
- 名人效應+病毒式營銷:“傳奇類”頁遊能走多遠?
- 公司研報|Keep上市,使用者的自律能帶它走多遠
- 傳統的“養兒防老”觀念依然存在,“以房養老”的房地產運營模式還能走多遠?模式
- 驚呆了!Spring Boot 還能開啟遠端除錯?Spring Boot除錯
- 執著於追求純粹“打寶體驗”的《火炬之光:無限》能走多遠?
- 你離 30 歲還有多遠?
- 距離 Java 開發者玩轉 Serverless,到底還有多遠?JavaServer
- 被遊戲耽誤的動畫公司紛紛湧現!遊戲衍生動畫能走多遠?遊戲動畫
- 走進開源專案 - urlcat
- 我們離夢想還有多遠
- 特斯拉Optimus人形機器人進廠打工,嫻熟分裝電池、自我矯正,還能走更遠了機器人
- 量子技術離市場還有多遠?
- 中秋節營銷方案除了走心設計還能如何製作?
- 遠端桌面多開,遠端桌面多開的工具介紹,操作方法
- 腦機介面技術離“治療”還有多遠?腦機介面
- 強人工智慧離我們還有多遠?人工智慧
- 獨立開發者眼中的Epic商城,還遠不是能改變業界的英雄
- 卷生卷死的SLG,下一步還能怎麼走?
- 高開低走主力洗盤還是出貨?
- Stability AI開源3B程式碼生成模型:可補全,還能DebugAI模型
- 通用人工智慧離我們還有多遠?人工智慧
- 遊戲畫面距離電影還有多遠?遊戲
- 走進開源專案 - urlcat 原始碼分析原始碼
- 從普通程式設計師到身價過百億:追求長期價值的耐心,決定了你能走多遠 原程式設計師
- 開源!mathAI 手寫拍照自動能解高數題,AI 還能這麼玩?AI
- 我們離通用人工智慧到底還有多遠?人工智慧
- 95後遊戲人離挑大樑還有多遠?遊戲
- AI有鼻子了,還能遠端傳輸氣味,影像生成香水AI
- 中國遊戲分級制度離我們還有多遠?遊戲
- 我們的手機離3A遊戲還有多遠?遊戲
- 華為openGauss正式開源,國產資料庫開源生態逐漸走強資料庫
- 還在為找開源專案發愁麼?或許這個專案能幫助你