譯者 | 彎月，責編 | 屠敏
頭圖 | GitHub
出品 | CSDN（ID：CSDNnews）
以下為譯文：
如今的很多開源融資模式並不適合小專案。
作業系統、框架、CMS或完全可自我託管的應用程式等大型專案佔據了主導地位，能夠從使用者（尤其是企業使用者）那裡獲得更多的資助。由於很多API和產品都建立在這些專案之上，因此他們可以透過一次性或按月支付的捐贈獲得持續性的收入。
但是大多數開源軟體專案的規模都不大。就GitHub上的大多數專案而言，考慮到在全世界基礎設施方面發揮的作用，它們只能算是實用程式。在構建複雜的應用程式的過程中，你會用到很多這樣的實用程式，這些工具可以幫助你節省大量的時間。
不幸的是，這類的實用程式很少能夠透過捐贈籌集到大筆資金，無論它們的使用範圍多麼廣泛，也無論有多少人喜歡它們。比如說：react-router，即便在GitHub上獲得了4.13萬顆星，每週透過NPM的下載次數高達300萬，而且基於React的單頁應用程式的採用非常普遍，但這個專案每年只能獲得1.7萬美元的捐款。
問題的根源在於開源捐贈是以專案為單位。如果你想透過GitHub Sponsors或OpenCollective支援專案，則必須為每個你想支援的專案單獨建立一個自動續訂的訂閱。更大問題的是，即便你決定“我要贊助X！”，也很容易說服自己放棄捐贈，因為你會擔心“但是萬一下個月我換成了另外一個熱門的新工具呢？”這極大地抑制了對開源的捐贈總數。最終，只有那些對所有人都有很大貢獻的專案才能獲得資金。這些專案通常都是大規模專案，比如框架、可自託管的軟體等。
我們需要新的融資模式，適用於中小型專案，而不僅僅是大型專案的融資模式。因此，我想提出一種能夠保證開源軟體獲得持續性融資的新方法。
贊助池
每個月，你向一個“錢包”捐款。
你的資金會被分配到“贊助池”中的各個專案。你的贊助池指的是你想要支援的一組開源專案。
只需單擊一下滑鼠就可以將新專案新增到你的贊助池中，就像在GitHub上給某個程式碼庫加星一樣簡單。
僅此而已。這個方法幾乎沒有什麼獨到之處，所以我有點驚訝為什麼主流的開源軟體開發商至今沒有為了促進開源捐贈而實現這個方法。
這種方法可以實現開源軟體持續性的終極目標：一鍵式贊助。在某人建立了贊助池以後，只需單擊一下滑鼠即可支援另一個專案。支援其他專案的邊際成本（無論是心理上的還是財務上的）都將降至零。這完全可以改變如今的局面。
為什麼這種方式更好？
為什麼我認為這種方式會大大提高捐贈給開源專案的資金？為了回答這個問題，請考慮一個假設的問題。
你願意每年為開源軟體捐贈多少資金？
我懷疑有些潛水的隱形富豪會說幾百美元吧。但你實際捐贈了多少呢？這是因為目前我們沒有途徑給“開源軟體”的抽象概念捐款。但是，如果有了贊助池，那麼實際的捐贈額度就不會與你上述給出的數目相差太遠。
GitHub
我認為，最好能夠將這種模型作為GitHub Sponsors的擴充套件。因為大多數專案的程式碼庫都在GitHub上，因此GitHub是構建這類捐贈系統的理想之選。
當然，如果GitHub實現了這樣的功能，那麼他們很可能會將捐贈機制與給星分開。也許，建立了贊助池並進行了資助的使用者能夠看到的按鈕會從“Sponsor”（贊助者）變成“Add to Pool”（新增到贊助池）。
GitHub有一定的經濟動機換成這種方法。目前他們需要負擔起GitHub Sponsors交易的所有處理費用。因此，如果你每月向某個專案贊助了1美元，那麼專案的維護人員能夠獲得1美元，同時GitHub還需要向信用卡公司支付0.3美元。捐款額度越大，GitHub承擔的費用就相對較少。
請注意，我說的是相對較少。如果處理的捐贈總數很大，即使費用較少，那麼最終他們需要支付的總費用仍然很高。如果贊助池的概念成功（比如每年累計捐款10億美元），那麼GitHub需要承擔近2000萬美元的信用卡費用。我相信這動了微軟的乳酪。
最後，我希望看到不同程度的捐贈能夠獲得一些徽章。想象一下，你在某人網站的頁尾中看到“GitHub贊助金徽章”，則表明他們每年向開源捐贈的數額超過1000美元。點選這個徽章，你就可以進入某個受信任的網站，並透過這個網站驗證徽章。下面是我快速設計的一個徽章：
這種方法可以有效地建立積極的強化迴圈：a）增強意識；b）鼓勵更多人為開源捐款。
總結
開源軟體的融資是一個難題，而且擁有大量的潛在解決方案。我並不想批評現有的一些方法，畢竟他們為開源做了很多工作，而且我也不想扼殺他們的努力。此外，實現我提出的方法還有很多我不知道的難題或法規障礙。本文只不過是一種設想罷了。
網友說
評論1：
我希望Youtube Red也有這樣的機制。每個人都有自己的贊助池。各個頻道應該以觀看時間來計算，這樣一些小頻道也能拿到捐贈。如果我觀看了一個頻道，那麼這個頻道就應該獲得我捐贈的10美元。
然而實際上，Youtube Red只有一個全域性的贊助池，並且按照全域性的流行度分配贊助，所以贊助主要流向了那些網紅，即使我並不看他們的頻道。對於那些觀看數不足百萬的頻道，這點贊助收入完全抵不過無法播放廣告而導致的損失，因此這種贊助並不能起到資助的作用。
我希望你提出的這個模型不會出現這個問題。如果有100個人願意每月支付10美元來支援兩個專案，那麼這兩個專案應該分別獲得500美元（減去交易費用）。這筆錢不應該轉移到Angular、React、Vue等等，導致這兩個專案每個月只能拿到5美元的零花錢。
評論2：
我認為有兩個問題。
首先，這樣的模型已經存在：Flattr和Liberapay。後者不得不放棄贊助池的模式，因為實際上當你採用贊助池模式時，你實際上就是一家銀行，這在法律上有一定難度。
其次，只有當用戶實際訪問你的的網站或Github時，這種模型才起發揮作用。目前我正在開發一款面向終端使用者的應用程式，我敢打賭他們中有90%的人從未使用過Github，甚至不知道Github是什麼。
評論3：
我認為這個想法非常棒，但必須要說明一個事實：只有GitHub採用這個想法，它才能成為現實。
但別忘了，就連Github的贊助功能都仍在beta測試中。但儘管如此，你還是不得不填寫各種稅務表格。
我想提一個小建議，贊助和贊助池可以並行採用。我相信，成為某個開發者的贊助者，以及成為開源世界的好公民並支援一些專案，這兩個想法並不衝突。
我可以贊助一名開發者，知道他把我列為贊助者之一，我會覺得很高興；同時我也願意每個月支出一筆錢，來贊助我的專案中用到的所有工具，原因僅僅是因為這樣做能讓這些專案活得更久。這是兩種完全不同的出發點。
大概更重要的是，GitHub可以把大部分交易處理費用放到贊助，對於贊助池則僅扣除3%作為交易處理費用。我覺得絕大部分人都不會反對這種做法。
對此，你怎麼看？
原文：https://vriad.com/essays/a-new-funding-model-for-open-source-software
本文為 CSDN 翻譯，轉載請註明來源出處。