關於開源軟體的七大錯誤認知

開源軟體已經像水和電一樣融入到了我們日常的生活中，但我們對開源軟體還有很多錯誤的認知。我嘗試站在開源軟體作者的角度來進行總結，總共有七大錯誤認知。

首先來看第一個錯誤認知：只要軟體開源了，就會有人用。

很多剛開始從事開源軟體開發的作者，會有這樣的想法。認為我只要把軟體開源出來，就會有人來使用。但事實上一個軟體有沒有人用，首先看它有沒有價值，而不是先看它是不是開源軟體。開源軟體首先是一個軟體，開源是其定語。所以從這個角度來講，開源軟體不會超越軟體本身的屬性限制，要先有用。在這個基礎上，再進行開源，可以為使用者帶來增強的附加屬性。

這給我們的提示就是在做開源軟體之前，要認真思考軟體的定位：

這款軟體要解決的問題是什麼;

它的目標使用者是誰;

和市面上其他軟體相比有什麼優勢;

如何進行宣傳推廣。

第二個錯誤認知：我又沒收你錢，軟體有漏洞、問題跟我沒關係。

開源軟體許可協議通常會包含類似這樣的條款，表明作者不對使用者使用該軟體所造成的任何問題負責。比如 GPL V3 的第 15 條款，就是這樣的宣告：

15. Disclaimer of Warranty.

THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

中文版本：

本程式在適用法律範圍內不提供品質擔保。除非另作書面宣告，版權持有人及其他程式提供者 “概” 不提供任何顯式或隱式的品質擔保，品質擔保所指包括而不僅限於有經濟價值和適合特定用途的保證。全部風險，如程式的質量和效能問題，皆由你承擔。若程式出現缺陷，你將承擔所有必要的修復和更正服務的費用。

這份協議還特意用了全大寫的方式來宣告。但是自 2017 年《中華人民共和國網路安全法》正式實施以來，這樣的宣告就不再有效了。

《中華人民共和國網路安全法》第二十二條規定：

網路產品、服務應當符合相關國家標準的強制性要求。網路產品、服務的提供者不得設定惡意程式;發現其網路產品、服務存在安全缺陷、漏洞等風險時，應當立即採取補救措施，按照規定及時告知使用者並向有關主管部門報告。

網路產品、服務的提供者應當為其產品、服務持續提供安全維護;在規定或者當事人約定的期限內，不得終止提供安全維護。

網路產品、服務具有收集使用者資訊功能的，其提供者應當向使用者明示並取得同意;涉及使用者個人資訊的，還應當遵守本法和有關法律、行政法規關於個人資訊保護的規定。

第六十條規定：

違反本法第二十二條第一款、第二款和第四十八條第一款規定，有下列行為之一的，由有關主管部門責令改正，給予警告;拒不改正或者導致危害網路安全等後果的，處五萬元以上五十萬元以下罰款，對直接負責的主管人員處一萬元以上十萬元以下罰款：

(一)設定惡意程式的;

(二)對其產品、服務存在的安全缺陷、漏洞等風險未立即採取補救措施，或者未按照規定及時告知使用者並向有關主管部門報告的;

(三)擅自終止為其產品、服務提供安全維護的。

所以各位開源軟體的開發者們，一定要認真理解這個法律的條款。我們已經收到過五次公安部下發到青島市網警的漏洞整改通知。具體細節就不跟大家講述了。這給到開源軟體作者們兩點警示：第一個就是一定要及時處理自己產品的相關漏洞，另外一點就是認真思考開源商業化方面。

第三個錯誤認知：我應當選擇最寬鬆的開源軟體協議。

許可協議是開源軟體的法律基礎，它規定了使用者可以如何使用、修改和分發軟體。有些人錯誤地認為，選擇最寬鬆的許可協議可以吸引更多的使用者和貢獻者。然而，許可協議的選擇應該根據具體情況進行權衡，並考慮到軟體作者的目標和需求。

比較寬鬆的許可協議限制比較少，如 MIT 和 BSD 許可證。這些許可協議幾乎沒有限制，允許使用者自由地使用、修改和分發軟體。然而，這也意味著其他人可以將開源軟體用於商業目的，甚至將其更改後的版本作為專有軟體釋出，而無需向原作者貢獻任何程式碼或修改。對於一些開源軟體作者來說，這可能不符合他們的意願和目標。

相比之下，像 GNU 通用公共許可證(GPL)這樣的許可協議對程式碼的再分發和修改設定了更嚴格的限制。它要求任何使用或修改 GPL 許可的軟體的派生作品必須以相同的許可證開放原始碼。這樣可以保護開源軟體的自由性和共享精神，防止將其私有化。

因此，在選擇許可協議時，開源軟體作者應該考慮到他們的目標、期望使用者和社群的需求，並選擇合適的許可協議來平衡開放性和保護性的要求。

第四個錯誤的認知：我應當努力地將軟體捐獻給基金會。

最近這幾年，有不少國產的開源專案陸續從 Apache 軟體基金會畢業，成為 Apache 軟體基金會旗下的專案。姜寧老師也兩度當選 Apache 軟體基金會董事。還有一些專案是加入了 CNCF 雲原生計算基金會。包括中國也成立了開放原子基金會，大廠也都有一些專案捐贈給了開放原子基金會。這對中國的開源軟體作者也是一個鼓舞，很多開源軟體作者也都在思考自己的軟體是否也可以加入這些基金會呢?我嘗試來闡述下自己的觀點：

首先這是好事情。說明瞭中國的開源軟體生態越來越成熟，也湧現了一批高質量的開源專案，在國際上也能夠產生我們的影響力，一定程度上也改變了中國只是開源軟體消費大國、對開源社群回饋較少的尷尬局面。

但是不是我們要努力地將專案捐贈給基金會，以謀求專案的健康發展呢?對此我會有完全不同的觀點。

第一，基金會並不是你想加入就能加入。無論是 Apache 軟體基金會，還是 CNCF 雲原生計算基金會，對專案的方向、成熟度、投入都有比較高的要求。所以目前能夠加入這些基金會的專案大部分都是大廠背景的開發團隊開發的。開放原子基金會目前的專案基本上都是會員單位捐贈的，網站上貌似也沒有公開加入開放原子基金會的具體章程。所以，對於我們這些個人或者小團隊的開源軟體開發者來講，這條路就不要想了，門檻太高。

第二，如果你的專案真的很不錯，都達到了加入基金會的標準，我也建議你認真思考一下加入基金會的訴求是什麼。對於大廠來講，將專案捐贈給這些基金會，可以提升自己的品牌，吸引優秀的開發者加入，建立行業標準，這些都是可以透過基金會來達成的。但如果你有明確的開源商業化方面的訴求，我建議還是要慎重，因為將專案捐贈給基金會，需要將程式碼的所有權和商標都要捐贈給基金會。換句話講，這個專案就屬於基金會了，你只是這個專案的主要貢獻者。無論從哪些方面來講，你都阻止不了其他團隊可以利用已經不屬於你的專案去做商業化的操作。

這一塊我要展開來說一下。整個自由軟體和開源軟體運動的基礎，還是 Copyright。正是有了 Copyright，才有了 Copyleft。開源軟體這種遊戲規則之所以能夠運轉起來，底層還是法律。只要是你創作的東西，你天然擁有對它的著作權(著作權不需要額外申請，都受法律保護。透過著作權登記、時間戳存證等手段可以更好地保護自己，後續再講)。之前的軟體售賣都是有原始碼的，後來比爾蓋茲說我們只能給你二進位制檔案，從而開啟了微軟帝國時代，所以才有了駭客們對商業軟體的反擊。開源軟體區別於商業軟體，就是向軟體的使用者讓渡了更多的權力：你可以對程式碼進行修改、進行二次分發。那開源軟體作者為什麼可以這麼授權呢?因為程式碼的版權是我的，所以我想怎麼樣就怎麼樣。這是底層的遊戲邏輯。當然開源軟體還有一個基本遊戲規則，就是我不對你使用軟體造成的任何問題負責，因為開源軟體和使用者之間並沒有形成商業合同上的契約關係。(但是隨著《中華人民共和國網路安全法》的實施，後面的這個遊戲規則不成立了，所以我們必須要對開源軟體的玩法做修改，參考我的前一篇文章《關於開源軟體的七大錯誤認知(上)》。)

所以從這個角度來講，你將開源軟體捐贈給國外的基金會，這個程式碼的 Copyright 和商標從法律上就歸人家基金會了。如果我們上升到國家的角度來看這個問題，我們把我們優秀的開源軟體都捐獻給國外的基金會，這會不會對國家的智慧財產權和國家安全造成威脅呢?2021 年鬧得沸沸揚揚的 Log4j2 元件的安全漏洞，可窺一斑。阿里雲的工程師在發現了這個漏洞之後，第一反應不是向中國工信部通報相關資訊，而是先向美國的 Apache 軟體基金會披露了該漏洞。工信部得知這個漏洞之後，時間已經過去了 15 天。15 天會發生什麼呢?尤其是在現在的這種國際政治背景下面。這個問題往小的方面講，是國家安全意識不夠，往大里面講，是屁股坐得正不正的問題。

有童鞋估計會問，我們不是還有國內的基金會嗎?前面也講了，現在門檻太高，不是我們想加入就加入。另外開放原子基金會有非常強的政府背景，在運作上會有比較強的監管，在各種政策措施出臺上會比較慎重(慢)。所以在國內的開源相關的基金會成熟之前，我們需要透過社群的方式來推進開源生態的發展，所以這是渠成開源社群成立的初衷(突如其來的廣告)。

第五個錯誤認知：開源之後會有很多人來幫我完善專案。

很多開源軟體作者開源，是希望有更多的人參與到專案中，這樣專案的問題能夠得到及時地發現和處理，專案也可以持續地發展。但實際的情況是什麼樣的呢?InfoQ 聯合 X-lab 開放實驗室釋出的 “GitHub 2019 數字年報”，透過對 2019 年 GitHub 上 5.46 億條日誌進行分析，得出了世界範圍內開源軟體專案的一些彙總資料。這其中有這樣的資訊值得我們思考：

2019 年總活躍專案數為 512 萬，但活躍度超過 1000 的專案只有 1399 個，不到萬分之三。

在這 512 萬個專案中，只有 333 個專案有 1000 位開發者參與，而 2019 年 Github 上活躍的開發者數量是 360 萬。

2019 年活躍度排行前 10 的專案中，有 60% 來自大廠，其中有 2 個來自微軟，分別是 vscode 和 azure-doc。3 個來自 Google，分別是 Flutter、Tensorflow、Kubernetes。還有一個是來自紅帽的 Ansible。

2019 年活躍度前列的專案中，大廠維護的專案現在仍然非常活躍，而排名第 10 的 tweakCompatible，已經停止維護了。

2019 年中國 Top20 的專案中，主要都是大廠維護的專案。

Vue 專案 2019 年大部分的貢獻是由一個賬號 Evan You，也就是尤雨溪尤大貢獻的。

2022 年 1 月份，cURL 的作者發表了一篇文章，吐槽世界 500 強企業白嫖技術支援的烏龍事件。具體新聞可以看開源中國的網址：

https://www.oschina.net/news/180252/fortune-500-log4j-curl。類似的事情太多了，就不一一列舉了。

所以，結論是，開源專案的維護主要還是要靠自己。

第六個錯誤認知：我開源不是為了錢。

這個話題估計會有很多開源軟體的作者會不贊同。就像 Linus 做 Linux 專案，just for fun。很多開源軟體作者比較純粹，把軟體開源出來就是希望能夠對使用者有用，並沒有商業化的目的。但我把這個話題換一種表達方式，估計大家都會贊同。也許大家剛開始開源的時候，確實沒有想著賺錢。但隨著事情的變化，大家就會考慮，我能不能透過開源專案賺錢呢?

剛開始開源的時候，開源軟體的作者更多的是興奮，以及軟體得到使用者認可所帶來的成就感。但隨著使用者的增多，來自使用者的問題就會越來越多。有的是希望你幫我解決一些使用安裝的問題，有的是希望你幫他做一些功能。隨著這些問題的增多，你做開源這件事情的性質就會逐漸發生變化。從最開始的分享為主，逐漸變成維護為主。開源專案給到你的樂趣會逐漸減少，責任和義務就會逐漸增多。自己的投入會越來越多，心裡的不平衡感就會越來越強。這時候大家就會考慮，我是不是可以透過開源專案來賺點錢呢?

所以這是水到渠成的想法，也是非常合情合理的想法。能夠透過開源專案獲得一定的收益，然後支援自己在開源專案做更多的投入，這是一件非常好的事情。

再來看最後一個錯誤認知：開源軟體靠服務和捐助可以賺錢。

網上有很多的資料，在講到開源軟體的商業模式時候，都會談到軟體免費，服務收費。這個模式按道理是能夠講得通的。畢竟軟體我都給你了，你要是有問題，我透過服務來收點費用，不是很合理嗎?但這裡面有一個悖論，我來給大家分析一下。

先來界定下這個服務的範圍。我所理解的軟體免費，服務收費的服務，是指保證軟體正常執行使用過程中所產生的支援類的服務。二次開發類的服務和諮詢培訓類的服務，超脫了這個服務的範圍。

如果我們嘗試透過支援服務來收費，那麼什麼情況下使用者需要支援服務呢?肯定是軟體有問題使用者才會需要服務，對吧。如果我們希望透過服務來賺比較多的錢，肯定是希望使用者提出越多的問題越好。那如果一個軟體問題比較多，那就說明軟體複雜度或者質量有問題。那這樣使用者就比較少。使用者少，那怎麼透過服務來收費呢?所以這裡面就存在了這樣一個悖論。

什麼樣的軟體可以透過支援服務收費呢?這個軟體對企業非常關鍵，他們需要一個商業主體來為這個軟體的正常執行負責，這樣的軟體透過服務收費才能行得通。什麼樣的軟體符合這樣的標準呢，基礎軟體。所以紅帽賣自己的訂閱制服務是行得通的。

我們禪道團隊在開發專案管理軟體之初，就放棄了透過支援服務收費的想法。我們給禪道開源免費版的使用者都會提供近乎於實時的技術支援。我們的目的很簡單，吸引更多的使用者使用禪道。一個社群的陌生小夥伴，只有成為你軟體的使用者，才有可能成為你的客戶。為了吸引更多的社群小夥伴成為禪道的使用者，我們不遺餘力的完善產品、提供各種技術支援。然後透過我們的收費的版本來實現商業化。

很多開源軟體作者也都放出了自己的捐助賬號，但實際的情況如何呢?我們在網上也看到過很多的新聞，很多知名的開源專案，一年收到的捐助少得可憐，可能連主要維護人員的正常生活都保證不了，這還是在歐美。比如 Core-js 專案每週下載量達數千萬次，累積下載量已經超過 90 億次，但作者 Denis 並沒有從這個專案中獲得更多的回報，甚至因為全職維護 Core-js 而窮困潦倒。他想了各種辦法來籌集資金以便維護開源專案，結果每個月也只能獲得幾十美元的贊助。估計會有小夥伴會提 Vue 尤大的例子，但這個只能是個例，而且很多對 Vue 的捐贈是有品牌推廣的性質在裡面，和我們通常說的打賞類的捐贈還是不太一樣。

我們最開始幾年也有開放捐贈的通道，也陸續收到一些捐助，不過相比較於我們的研發投入來講，只能說是杯水車薪。因為我們跑通了商業化這條路，我們把我們所收到的捐助又全部捐了出去。後來我們就關閉了捐贈的通道，是因為有的人因為捐贈之後，希望我們能夠給他做一些額外的事情，這已經超出了捐贈這件事情本身的含義。

所以大家就不要幻想透過技術支援和捐助來實現健康的收入了。需要認真考慮開源軟體的商業化之路。這是關於開源軟體的七大錯誤認知系列的最後一篇文章。歡迎大家來討論。