開源告急！

作者 | 阿木

責編| 仲培藝

開源，還能走多遠？

現如今開源軟體幾乎可以說是軟體開發過程中必不可少的一部分，且是比較特殊的一部分，實際工作中幾乎每個項目都有開源軟體的身影。

開源社區的存在使我們每個人都可以使用到世界級的開源工具。這一點現在看起來非常常規，但其實裡面包含了很多社區開發人員的心血，比如每個 import、include 語句背後的開源軟體包都會對應一個專家團隊，都隱含了他們的貢獻，由於他們共同為一些待解的問題投入精力，這樣大家在使用這些功能時直接導入他們的成果即可，不需要再各自造一套輪子，極大提高了我們項目的進度。

開源項目的可持續性從不同角度看一般會有不同的定義：

(1) 軟體開發者

從軟體開發組織的角度來看，可持續開源項目一般是指有能力及時發布代碼並可以及時修改產品中存在的各種問題的項目。

(2) 項目本身

從項目本身的角度看，可持續性一般要求項目本身可以負擔自己的支出，這樣項目才可持續發展。

開源處境

開源社區維護者和貢獻者為我們所有人構建工具，為我們日常的開發提供了很大的幫助，但開源社區的貢獻者自身卻面臨諸多問題，這些問題一定程度上影響了開源軟體的可持續發展，開源項目的可持續性也一直存在矛盾。

這一矛盾導致很多開源軟體在最初更新迭代比較快速，文檔書寫也比較及時，後面卻可能出現一些人員離職等問題，導致該開源產品後續的更新不及時，甚至直接中斷，這時使用該開源產品的的同學在反饋問題時往往需要很長時間才會得到答覆，甚至得不到答覆。

筆者曾經在使用一個開源的資料庫遷移工具時遇到過此類問題，具體是文檔中說明該開源工具有功能 A，但並未寫明功能 A 需要如何配置才能使用，在項目討論區給作者留言長時間沒得到回復，於是自己花了接近 1 天的時間去調試該開源工具的代碼，發現文檔中寫明的功能 A 實際並未提供，一周之後作者留言功能 A 目前確實沒有提供，且由於公司內部新換的領導沒有之前領導那麼熱衷開源，所以後續用在此開源項目的人力會逐漸減少，功能 A 的上線也沒有具體的時間點。

其他類似的事例也比比皆是，如某些大公司在內部評級時需要有開源的貢獻，評級中加入對開源社區的貢獻，本身對開源的發展是很好的事情，這樣一方面可以為開源社區帶來新的成果，另一方面也可加深項目參與者對開源的認知，為推廣開源助力。但問題是很多開源項目在公司評級完成之後會很快被丟掉，沒有人再去更新、維護，只是把開源項目當做自己職業生涯上某個階段中的一個上升工具。

上面我們僅僅只是列出了開源項目經常遇到的問題之一，下面羅列了一些影響開源可持續性的常見原因：

(1) 資源不足

我們可以做個假設，如果沒有開源軟體，我們所處的社會還會不會是當今的樣子？

今天，不僅互聯網產業需要建立在軟體之上，傳統行業也是深度依賴於軟體，在這些軟體中，開源軟體所佔的比例越來越高，尤其是一些構建成本低、容易發布、可靈活定製的開源軟體。

開源軟體可以類比為我們實體世界中的公路、橋樑等基礎設施，每個人都可通行，類似開源代碼人人皆可使用，這些開源軟體已經是今天數字基礎設施的一個很重要的部分。

免費的開源軟體一定程度上使得很多創業公司的創業成本急劇下降，再加上雲服務的爆髮式發展，開源軟體在使用上越來越便捷，直接促成了 21 世紀大量創業公司的興起。

開源社區無處不在，但普遍缺乏經濟資源和人力資源。人們重視實體基礎設施的投資，但卻忽視了數字基礎設施的建設。

使用開源產品的企業或者個人開發者可以從充滿活力的開源生態鏈中獲益，但是目前缺乏比較普適的方式引導這些開源產品使用者來為開源產品貢獻自己的時間或財力上的支持。雖然開源軟體有很大的潛力，但這種情況很大程度上限制了開源軟體的價值。

像實體基礎設施一樣，數字基礎設施也需要不斷的定期維護。很多比較有價值的開源軟體無法得到商業模式的支持，也缺乏任何形式的機構支持。所以開源貢獻者投入很大的精力換來的更多的是認可，並且後續還要保持項目的版本迭代，基本不求任何形式的回報。因為搭上了開源這個便車，眾多的互聯網巨頭成開源軟體的最大受益者，但巨頭們並未將因此獲得財富有效回饋給開源貢獻者，甚至很多公司壓根就沒有意識到這一點。

(2) 隱性成本

在此我們所說的隱性成本是指因為忽視數字基礎設施建設而帶來的隱性成本,由於是隱性成本，所以這方面的關注度一直不高。

a. 開源軟體漏洞

過去幾年開源軟體因為數字基礎設施建設被忽視而導致的問題可謂實繁，如眾多的嚴重代碼錯誤、開源軟體安全漏洞、服務中斷等。

比如在 2014 年，一些用戶在使用開源的 OpenSSL 庫時發現其存在Heartbleed安全漏洞（也稱心臟出血漏洞）但是在當時開源 OpenSSL 庫已經被廣泛使用，整個互聯網行業中有接近 2/3 的 Web 伺服器在使用存在Heartbleed漏洞的OpenSSL進行密碼、信用卡等敏感信息的傳輸。我們可以看下 ZoomEye 當時專門針對 OpenSSL 漏洞製作的漏洞影響統計：

幾乎影響了分布在世界各地的互聯網公司：

可見開源OpenSSL在整個互聯網行業的重要性，大家可能以為互聯網行業如此重要的一個開源軟體應該有自己的專業技術團隊，應該人數眾多、資源充足，但是事實上 OpenSSL 只有一位全職的工程師，所以在事件發生後不足以及時地修復漏洞。好在事情後續有了比較好的進展，隨著各大媒體的報導，Heartbleed 得到了廣泛關注，一些報導也關注到了 OpenSSL 本身面臨的困境，OpenSSL 因此暫時獲得了一些資助，這部分資助當時可以支持 4 位全職的工程師為 OpenSSL 服務 3 年。

b. 軟體維護困境

據統計，很大一部分開源軟體在開發出來之後得不到必要的維護。

2013 年，著名 Ruby 代碼開發託管平台 RubyGems.org 被爆出一個非常嚴重的安全漏洞，但問題爆出後長時間未被修復，後發現開源平台 RubyGems.org 沒有自己專職的技術人員，完全是由志願者開發並維護的，因此出現問題後沒人去及時處理。結果導致一些黑客發現了這個安全漏洞，並利用這個漏洞攻擊了 RubyGem.org 的伺服器。

RubyGem.org 伺服器被攻擊一段時間之後，之前開發此網站的一部分志願者抽出自己的休假時間開始對網站漏洞進行修復。接觸過 Ruby 生態的同學應該知道，RubyGem.rg 是 Ruby 生態中非常重要的一個組成部分，是 Ruby 基礎架構中的一個關鍵部分，因此這個安全問題波及了許多開發者和公司。

這個事情也從側面暴露出一個問題，對於沒有全職技術人員且完全由志願者開發維護的開源軟體應該如何保證其安全性和可靠性。

c. 優秀人才流失

開源軟體在開發過程中或開發完後的日常迭代中經常會遇到技術人員退出的問題。技術人員尤其是核心技術人員在中途退出，會嚴重影響開源項目的進度和項目的質量。

開源社區的志願者和我們日常的一些社區志願者一樣，也會存在懈怠的情況，且此種情況也算是比較常見的，畢竟大家一般都是一面做著自己的專職工作，一面來參與社區的工作事務。

不管是個人開發者還是企業的開發者，大部分情況下大家都是在無償處理來自用戶的需求，有時也會心力交瘁。在此種情況下部分的開源開發者會選擇停止自己手裡維護的開源項目，或者希望別人可以接手自己的項目，因為自己沒有時間專職去做開源的項目。與此同時，企業和個人繼續依賴和使用這些開源產品，他們並不了解這些產品目前所包含的風險。

小結

開源軟體大部分時候都是以代碼的形式對外展現，由於代碼並不像熱門視頻或熱門音樂那樣能夠吸引人，這樣就造成公眾對開源工作的認知度很低。

在多數人的認知里，使用開源是理所應當的，我們在使用開源的產品時並不會去考慮維持我們正在使用的開源產品所需要的人力、物力、財力等資源。

OpenSSL 的事情並非特例，類似的開源產品的遭遇幾乎每天都在上演，但並不是每個產品都得到了後續的資金支持，因此一定程度上來看 OpenSSL 又是幸運的。

無數的開源項目繼續默默無聞，且得不到完善的支持，這些問題開源貢獻者幾乎每天都會面對，但是開源產品的使用者一般並不清楚這個情況，數字基礎設施缺乏足夠的制度支持。

(3) 溝通工具缺乏

這裡提到的溝通工具不是開源項目開發成員之間的溝通，指的是開源社區和開源產品使用者之間的溝通互動。

現階段來看，隨著開源項目的發展，和用戶之間溝通會變得越來越有挑戰性，導致這種現象出現的原因主要還是社區管理工具的缺乏。為改變這種情況，很多開源項目會自己去構建項目和社區管理工具，但是這個過程往往會消耗比較多的時間和精力，這些時間和精力本來應該是需要用在開源產品本身的開發上的。

(4) 人身攻擊

大家經常逛開源社區的話，應該不難發現評論區經常會出現一些不和諧的聲音，比如「就這代碼水平還來做開源…..balabala」等。

開源社區的維護人員一般是自願為社區做事情的，沒有人應該被騷擾，甚至辱罵。

(5) 缺乏分析工具

除了下載統計這些基本的統計信息，開源軟體維護人員一般對自己軟體的實際使用情況了解有限。

最常見的就是通過社區的留言信息來了解用戶的實際需要，相比企業內做產品的溝通方式，這種溝通方式相對低效，需要提供更好的需求收集、反饋工具。

(6) 新人培養問題

企業內日常開發中一般都會有新人培養機制，典型的就是老司機帶新人，培養模式一般相對較成熟。但放到開源軟體開發中此種方式就有些水土不服，很難在開源的項目中找到老師傅帶路，對於新加入的開發者存在一定的挑戰，很容易產生挫折感。

(7) 項目管理待優化

隨著項目的發展，開源項目的團隊創建、任務分配和溝通決策的方式也要隨之發展，這在企業內部正常的開發中也許問題不大，但環境挪到開源軟體開發中時開源社區往往並不能夠總是很好地應對這種變化。

(8) 反對商業利益

參與過開源項目的同學可能會很有體會，開源文化中一般並不鼓勵談論金錢，大家往往會認為涉及到金錢的話就會腐蝕和削弱開源工作的資源精神，違背很多人參與開源工作的初衷。

儘管這種態度使得開源領域擁有了今天的規模，但是隨著時代的改變、社會形勢的改變、周圍環境的改變，開源參與者也會面對一些資源需求。開發者可能會出於內疚或者可能被質疑缺乏團隊精神而羞於談論此類話題，但當與現實需求產生碰撞時很多人可能會處於利益的考慮而選擇退出手裡的項目。

參與過開源項目的同學應該知道，整個過程除了需要做公司內自己的任務，還需要擠出時間去做社區的項目。這種狀況往往導致開源開發者疲憊不堪，且整個參與過程中幾乎無報酬或者報酬微薄。

開源軟體並不一定是免費軟體，開源軟體和免費軟體不是一個事情，更不能等同，在此我們有必要回顧下開源軟體的定義，以維基百科對開源軟體的定義為例：

開源軟體（英語：open source software，縮寫：OSS）又稱開放源代碼軟體，是一種源代碼可以任意獲取的計算機軟體，這種軟體的著作權持有人在軟體協議的規定之下保留一部分權利並允許用戶學習、修改以及以任何目的向任何人分發該軟體。開源協議通常匹配開放源代碼的定義的要求。一些開源軟體被發布到公有領域。開源軟體常被公開和合作地開發。開源軟體是開放源代碼開發最常見的例子，也經常與用戶生成內容做比較。開源軟體的英文「open-source software」一詞出自自由軟體的營銷活動中。

開源軟體同時也是一種軟體散布模式。一般的軟體僅可獲取已經過編譯的二進位可執行檔，通常只有軟體的作者或著作權所有者等擁有程序的源代碼。

有些軟體的作者只將源代碼公開，卻不匹配「開放源代碼」的定義及條件，因為作者可能設置公開源代碼的條件限制，諸如限制可閱讀源代碼的對象、限制派生產品等，此稱之為公開源代碼的免費軟體（Freeware，例如知名的網路論壇軟體 Discuz!），因此公開源代碼的軟體並不一定可稱之為開放源代碼軟體。

除此之外，開源開發者的高度分散和高度民主的特性，即使是有償服務開源也是極具挑戰的。

(9) 缺少可持續性的商業模式

當前開源領域常見的商業模式：

a. 專業服務

專業服務即專門做付費服務。這中模式中最著名就是紅帽，紅帽主要通過向使用他們產品的用戶提供有償服務進行收費，比如對於企業用戶的 Linux 支持、技術培訓等。

紅帽成立於 1993 年，是一家上市公司，藉助專業服務這種商業模式，全世界領先的開源服務提供商，紅帽公司每年的營收可以超過 30 億美金，2018 年 10 月被 IBM 以 340 億美元收購。

b. 區分版本

採用此種商業模式的開源軟體，一般就將產品的版本分為開源社區版和付費商業版。

社區版開源且可免費使用，一般也可使用到最新的功能（有的開源版本只會提供單機版，集群版包含在商業版中，如 InfluxDB），但不提供任何商業版本具有的服務保障。

商業版一般閉源且需要付費才可使用，並且還會提供質量測試、Bug 修復、性能優化、定製化服務以及眾多售後技術支持。

此種模式下比較出名的如 Docker、MySQL 等。以 Docker 為例，Docker 分為三個版本：Moby、Docker CE 、Docker EE。Moby 是 2017 年初由 Docker 公司原先的 Docker 項目改名而來，Moby 繼承了原先的 Docker 項目，由開源社區進行維護，每個人都可以在 Moby 的基礎上再次開發屬於自己的容器產品；Docker CE 也是免費開源的 Docker 產品，與 Moby 不同的是 Docker CE 是由 Docker 公司自己維護的開源項目，是一個基於 Moby 項目的免費開源容器產品；Docker EE 是 Docker 公司的 Docker 商業化產品，該版本閉源且需要付費才可使用。

c. 基金會

基金會這種商業模式大家可能會更加熟悉，這種模式中最為出名的莫過於 Apache 軟體基金會，其他的比較出名的如 Linux 軟體基金會、OpenStack 軟體基金會。Apache 軟體基金會成立於 1999 年，到目前為止 Apache 軟體基金會已經孵化了超過 350 個項目，如 Dubbo、Apollo、CloudStack、Flink、Groovy、Hive、Mesos、Nutch、Pig、Spark、Storm、Python、Node.js、Django 等等。

基金會的資金來源一般是企業捐贈，業界的幾大巨頭捐贈較多，基金會本身為項目提供組織和法務等方面的支持，基金會本身不直接為項目提供資金支持。

如果項目本身足夠大的話，可以創建獨立的基金會進行管理和募資，此種情況比如：Python、Node.js、Django 等。

d. 企業贊助

如果項目本身價值較高，擁有大量的使用人群，此種情況企業可以專門招聘專職的技術人員為項目工作。此種商業模式的典型例子也有一些，如 jQuery——一個被廣泛使用使用的 JS 庫，接觸前端開發的同學應該都不會陌生。

e. 賞金

部分公司或個人有時會對外發布懸賞，以此來獲取諸如新需求、軟體安全漏洞等信息。此種商業模式事例也是不勝枚舉，以 IBM 為例，IBM 從 2013 年開始便藉助網站 Bountysource 來為自己的多個項目收集新的需求。也有部分公司會為了發現開源軟體的安全漏洞而對外發布懸賞。

f. 眾籌

部分開源項目會通過眾籌的方式對外尋求需求資金的支持，比如 Kickstart、Indiegogo、Django 等。我們以 Django 為例，Django 資料庫模塊的核心開發者曾從其 507 名的支持者中眾籌了一部分資金，以此來資助 Django 框架中資料庫模塊的開發。

g. Open Core

此種模式通常會涉及一種功能強大的開源核心產品，然後圍繞著這個核心產品來提供一些商業上的擴展，一般還會捆綁一些支持和服務。

目前也有一些採用這種商業模式的開源產品公司，如 Cloudera、Elastic、Confluent 等。

問題小結

上文列出了開源軟體開發過程中面臨的一些問題，從中我們可以看出開源軟體的發展所面臨的一些痛點：

(1) 開源軟體的可持續性

開源軟體的眾多商業模式中，總結起來，目前僅僅只有專業服務、付費商業版和 Open Core 這少數幾種模式可以獲得持續且比較穩定的收入，其他幾種方式存在不確定性，甚至可能並不能算作嚴格意義上的商業模式。

(2) 對開源的支持對象

現在看來，外界對開源的支持絕大部分是對項目的支持，而且是對特定的項目，對個人貢獻者直接支持的情況相對比較少些。

(3) 時間消耗

如果一個開源項目有比較多的用戶群體，且很多用戶願意付費，那麼對於個人開發者或小團隊來說專業服務這種模式不失為一種很好的選擇，但是這種方式也會帶來其他的一些問題，即可能會消耗開發者改進項目本身的時間和精力。

(4) 資源差距

從今天開源社區資源獲取的情況來看，大部分資源被投入到少數幾個熱門的項目上，其他的一些項目受關注程度和獲取的資源支持相對較少，這種現象也會導致一些問題的出現，例如一些基礎軟體和小眾軟體的生存空間可能逐漸被壓縮掉。

(5) 開源社區中立性

企業如果為開源項目聘請專職的技術人員，可能會導致技術人員在參與開源項目發展的過程中傾向於自己所在的公司，進而可能影響到所在項目的中立性，甚至可能影響到項目原本的發展方向，此種情況的出現將不利於開源社區的發展。

可持續性建議

對於開源可持續發展，筆者結合社區給出的一些建議總結了以下幾點：

(1) 鼓勵個人開發者

可以通過改進眾籌的方式增加項目收入，以此來回饋開源貢獻者。

具體實施，可以從項目的用戶或關注者中獲取收入，並向開源項目的開發人員提供部分經常性的收入，以示對開源項目的支持。此種方式可以藉助如下兩個平台：

a. Patreon

Patreon 不僅關注開源貢獻者而且也關注其他的內容創作者，該網站不僅可以提供開源項目的捐贈服務，還可提供商業貸款。

b. Liberapay

Liberapay 的前身是 Gratipay，是資助開源項目和開源開發人員的最大平台，遺憾的是 Gratipay 已經於 2017 年年底關閉，後續由其分支 Liberapay 繼續提供功能。

(2) 支持雙許可證

雙許可證是指一種在商業付費和開源代碼之間的一種平衡的方法，如：

a. License Zero

License Zero 是一種基於雙條款的 BSD 許可，該條款允許用戶在購買之前進行試用，商業用戶可以有 90 天的產品試用期，使用期限達到 90 天后需要購買商業許可才可繼續進行產品的使用。

b. Fair Source

Fair Source 是 Sourcegraph 推出的 Source Visible 許可，一般情況下對於個人和小型企業是免費的，但是對比較大的商業用例需要付費後才可使用。

(3) 支持小項目的商業化

此種模式類似紅帽的商業模式，區別是該模式支持較小的項目。

比如開源軟體 Tidelift，企業用戶如果需要後續的技術支持服務，則需要向其支付一筆服務費用，此種模式的目的是為了讓企業用戶為開源軟體貢獻人員提供一種穩定的收入，這種模式如果可以推廣將會吸引大量技術人員進入開源社區，為開源社區貢獻力量。

(4) 降低成本

開源項目實現可持續性一般還需要開源項目自身能夠負擔自身的各項成本。成本包括多種，比較常見的如基礎設施成本、開發成本、軟體後續的更新和維護成本，另外還包括項目管理產生的治理成本、營銷成本和溝通成本等。

很多項目的初始成本是由上級機構、或者初始的開發者自己投資支付的，問題是這筆錢用完了後續該怎麼辦？

開源項目的初期資金一般比較有限，到了項目的一定的階段，就需要採取一些措施縮減開支，通常無非是開源或者節流。一個開源項目如果需要持續發展，則其收入必須超過其消耗成本，如開發和維護成本。

鑒於此，絕大部分的開源項目很難實現可持續性，這一點不僅僅適用於開源項目的開發，也同樣適用於閉源項目的開發，實際上任何需要資金支持的項目都是如此，不論開源還是閉源。

開源項目無法實現可持續性的原因很多。某些情況下，可能是因為項目未能達到項目最初設置的目標，所以項目的很多參與者便期望可以取消項目。這是一種情況，另一方面，很多項目即使達到了最初的目標，卻仍然無法實現持續性。使用公共資金的項目尤其如此，這類失敗通常是由於開源項目開始的規劃不當引起的。換句話說，項目開始的最初階段項目管理者並未就項目初期資金的使用制定合理的規劃，如到達什麼階段消耗多少資金，項目未完成資金消耗完時該如何應對等，因此也就沒有為項目實現可持續性分配資源。

所以，結論很明顯，要想實現可持續性，我們必須在項目的初始目標中包括可持續性計劃。這意味著，我們需要在項目周期的最開始階段就制定出可持續性計劃，而要想制定出合理的計劃需要真正清楚當前項目已經具備的資源和可以調動的資源，對於開源項目的負責人來說這些都需要整理清楚。

實現可持續性有很多的選擇，在此我們無法一一列舉，因為項目的模型和項目的創意幾乎一樣多，鑒於很少有項目可以嚴格歸為某種模型，在此我們不再贅述，感興趣的同學可以自己查閱下。

開源未來

藉助 GitHub 這一平台，今天的開源社區仍在加速發展。Github 平台一定程度上充當了開源軟體爆炸式增長的中心，據統計，目前使用Github平台託管的 repo 數量已經超過 1 億個。

開源軟體在蓬勃發展的同時，也吸引了眾多 VC 的目光，越來越多的 VC 開始踴躍投資開源項目，但其投資會受到資產類別的限制，目前 VC 不能投資一個沒有商業模式的開源項目。

紅帽的模式很難複製，紅帽商業模式的成功，一方面得益於其技術的先發優勢，另一方面，服務的模式很難持續高速發展，尤其是雲計算的興起，開源項目的市場空間會逐步受到擠壓，後續將會出現越來越多的併購案。

目前對開源項目可持續性的探索，可以說還處於一種低水平的階段，一種早期階段。上文中我們講到的幾種新的商業模式基本都需要開源項目有自己的全職技術人員，但實際情況是目前只有少量的項目達到這一標準。

此外 Pateron、License Zero 和 Tidelift 雖然可以提供可持續性的不同方法，但需要花費很多力量使這些基礎設施真正地被使用起來，另一方面，Pateron、License Zero、Tidelift 和 Collective 等還相對較新，後續的發展還需要進一步的觀察。

作者：王洪鵬，運營有個人公眾號新新生活志。目前任職網易雲計算技術部高級工程師，近3年雲計算從業經驗，愛讀書、愛寫作、愛技術。

聲明：本文為CSDN原創投稿，未經允許請勿轉載。

【完】

熱 文推 薦

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！