開源專案掙錢實用手冊
https://github.com/nayafia/lemonade-stand
作者 | Nayafia
轉載自 | https://github.com/wizicer/FinancialSupportForOpenSource
譯者 | wizicer
我在參與開源專案，但是我該如何掙錢呢？
我列出了我從各種渠道所知道的開源專案帶來收入的人們的故事，每種出資型別都有一系列的真實案例，粗略的按照出資量從小到大排列。（我已儘可能的將連結指向具體故事而非主頁面）
本文中的出資型別並非互斥的，例如一個專案既可以由基金會也可以通過眾籌來籌集資金，而一個人既可以靠諮詢掙錢也可以獲得捐贈。本文的主要目的是提供一個詳盡的掙錢方式列表，而你只需要從中選出適合你的。
本中文版是原版[1]的翻譯版本。
原專案名稱 Lemonade Stand 是指銷售檸檬汁的小攤，而在美國，這種小攤通常是由小朋友運作的。
“個人努力” 用來標記其資金是由個人而非專案主導籌集獲得的
捐贈按鈕
在你的網站頁面裡放上捐贈按鈕。Stripe 和 PayPal 都可以很方便的提供這項服務。
優點
◈ 限制條件少◈ 工作量小：放好後就可以不管了缺點
案例學習
◈ Twisted [4]◈ Git [5]◈ Transmission [6]懸賞
專案或公司可能時不時的張貼開源專案的懸賞工作（例如“修漏洞賺 $100”），下面列出了一些網站，他們收集和釋出了這類懸賞工作。
優點
◈ 參與到開源社群◈ 確定的工作有確定的回報◈ 在修復安全漏洞方面特別流行缺點
案例學習
◈ Bountysource [7]◈ GitHub Bug Bounty Program [8]眾籌（一次性）
如果你想實現一個特別的想法（區別於長期專案），一次性的眾籌活動可以幫助你籌集到你需要的資金，許多個人和公司都可能會為你的想法捐款。
優點
◈ 限制條件少◈ 對個人來說也可以很容易合法的進行，例如通過 Kickstarter [9]缺點
◈ 一大堆的市場工作需要做◈ 通常都需要為捐贈者提供回報甚至是特權◈ 通常錢也不是那麼多（一次大約$50K）◈ 公司並不常願意向眾籌捐款案例學習
◈ Michal Papis + Rvm (個人努力) [10]◈ Andrew Godwin + Django (個人努力) [11]◈ ribasushi + CPAN (個人努力) [12]◈ RESTful WP-CLI [13]眾籌（持續性）
如果你想要為持續性的專案籌集資金，可以設立一個持續性的眾籌，捐贈者承諾按月或按年提供資金直到捐贈者退出。對於那些經常使用你的專案的個人或公司可能會願意為你的專案提供資金。
優點
◈ 限制條件少◈ 對個人來說也可以很容易合法的進行，例如通過 Patreon [14]、 Salt [15]、 Gratipay [16]、 OpenCollective [17]缺點
◈ 很難獲得承諾的持續性捐贈（這通常需要你或專案已經有一定的名聲）◈ 很難解釋持續性的捐贈能獲得什麼樣明確的回報或特權◈ 通常錢也不是那麼多（一個月 $1-4K）案例學習
◈ MochaJS [18]◈ React-boilerplate [19]◈ jsbin [20]◈ Tom Christie + Django REST framework (個人努力) [21]◈ Ruby Together [22]賣書及周邊
如果你是某個領域的專家，你可以寫書賣書，可以找個出版社（像 O'Reilly）或自己出版（譯者注：在中國不行）。除了賣書之外，有些專案也賣短袖外套等。
優點
◈ 籌集到的資金並不和專案本身管理關聯，所以專案本身可以保持創作的自由◈ 銷售的商品本身也可以當做為專案做的宣傳◈ 在初次銷售後可以成為持續性的資金來源缺點
◈ 通常錢也不是那麼多◈ 會影響用在專案上的精力◈ 賣周邊需要準備預付資金案例學習
◈ Lua [23]◈ Daniel and Audrey Roy Greenfeld + Two Scoops of Django (個人努力) [24]◈ Sandi Metz + Practical Object-Oriented Design in Ruby (個人努力) [25]廣告
如果你的專案已經有了一定的受眾，你可以幫助廣告商向你的受眾推銷。通常你的專案都會有明確的受眾，這是你的優勢也是廣告商所喜歡的。（比如你有一個 Python 專案，那麼基本上可以假定你的受眾一定是技術上熟悉 Python 的）
優勢
◈ 這是成熟明確而且大眾也能接受的商業模式缺點
◈ 需要足夠多的受眾才能請來廣告商◈ 需要通過透明化來讓受眾相信你（比如讓其信任你不會追蹤他們）◈ 需要許多精力來尋找和管理廣告商案例學習
◈ Read the Docs [26]◈ Hoodie [27]受僱於公司並繼續你的專案
公司有時候會僱傭一些個人來做開源專案，你可以尋找一個正在使用你的開源專案的公司。當然具體在公司裡可能公司工作和開源專案工作時間會是五五分。除此之外，也可以找一個願意嘗試使用你的新專案的公司。如果你有展示專案經驗，這將會非常有用。
優點
◈ 可以利用公司的資源◈ 可以很好的和公司的需求保持一致◈ 穩定的收入缺點
◈ 獲得這樣的機會需要極好的運氣，現目前沒有明確可重複的方式獲得這樣的機會◈ 專案通常需要非常出名並且被使用◈ 對於沒有為公司的利潤工作，這使得個人很容易被公司優先捨棄◈ 公司可能會過分影響專案的發展◈ 可能會因平衡不好兩邊而影響專案案例學習
◈ Donald Stufft + Hewlett-Packard and Python packaging (個人努力) [28]◈ Rich Hickey + Cognitect and Clojure [29]◈ Aaron Patterson + ManageIQ and Ruby, Rails (個人努力) [30]◈ Ryan Dahl + Joyent and Node.js (opens a YouTube video) (個人努力) [31]在職時啟動專案
許多開源專案最初都是員工的編外專案Side Project，即便其最終可能會成長為一家公司，但以編外專案的形式在公司裡進行孵化應該是不錯的選擇。
如果你想走這條路，請確定你理解了公司在開源專案上的政策。有些公司鼓勵員工在工作時間從事開源專案開發，而有些則將你的任何工作視作公司專案。不要假定任何前提，最好在開始前問問你公司裡的相關人員。
優點
◈ 可以不用擔心收入的情況下嘗試新想法◈ 可以和公司的需求很好的保持一致◈ 適合嘗試新想法缺點
◈ 需要用業餘時間開發，或者獲准在工作時間開發◈ 有被公司過分影響的風險◈ 持續下去可能會出現極度複雜的管理情況案例學習
◈ Mozilla and Rust [32]◈ Google and Go [33]◈ Facebook and React [34]◈ Futurice’s open source program [35]補貼
補貼是不需要償還的極其有效的大筆捐贈，提供補貼的組織通常能夠通過給予補貼而從其他方面獲得利益，例如接近你，展示其影響力，獲得你的工作彙報或稅率優惠。
補貼可能來自很多地方，包括公司、軟體基金會、慈善基金會以及政府，其技術及法律方面會因其來源的不同有很大的差異。比如一家公司可以通過開諮詢費發票給你補貼，而慈善基金會則只能給非盈利組織或個人，通常你得找到一個非盈利組織來幫助你。如果你對補貼不熟悉，瞭解它的最好方式就是和曾經獲得過的人去了解。下面列出了一些成功的案例
優點
◈ 限制條件少◈ 有保證的資金可以確保你能在一段時間裡專注在你的專案上◈ 讓你的專案有時間喘口氣和做些試驗缺點
◈ 軟體方面沒太多提供補貼的組織◈ 補貼是有限的，始終需要在用完補貼前找到一個持續方法案例學習
◈ Dat [36]◈ Andrey Petrov + Stripe Open-Source Retreat and urllib3 [37]◈ Django + Mozilla Open Source Support [38]諮詢服務
諮詢是一種為開源專案提供資金的靈活方式。你可以更加自由的規劃你的時間，比如一週 30 小時做諮詢業務，10 小時做開源專案。諮詢師通常收費相對較貴，因為工作不穩定且沒有公司福利。如果你打算做這類公司，你應該想要建立一家有限責任公司。
優點
◈ 這是成熟明確而且大眾也能接受的商業模式缺點
◈ 諮詢工作需要人力，而且不宜規模化（除了極少數）◈ 商業本身的需求會分散開源專案上的注意力◈ 可能會和軟體的簡易要求有差異◈ 專案需要足夠流行，才會讓人願意為相關服務付錢案例學習
◈ Neighbourhoodie [39]◈ Baroque Software [40]◈ OpenSSL [41]SaaS
SaaS 即軟體即服務Software as a Service[42]。在這個模型下，程式碼本身是開源的，但是你可以提供增值服務使得使用者更容易使用。一個典型的增值服務就是託管付費。
優點
◈ 可以圍繞這個開源專案建立一個社群，然後通過託管服務賺錢◈ 讓開源專案可以專注在使用者層面，當需求增加後再幫助企業採用這個專案◈ 可以根據使用者數進行規模化改造缺點
◈ 對增值服務使用者來說，通常意味著託管服務必須比招聘一個人來維護專案更便宜◈ 增值服務有可能會使得免費使用者不太高興案例學習
◈ WordPress.com [43]◈ Moodle [44]◈ Forge Laravel [45]◈ Gitlab [46]◈ Sentry [47]◈ Travis CI [48]◈ Ghost [49]雙重協議
有時候專案可以在完全相同的程式碼裡提供兩種不同的授權協議：一個是商業友好的，而另外一個則不（例如 GPL）。後者對於個人來說可以免費使用，而公司需要通過購買商業協議來獲得合法的商業授權。
優點
◈ 這是成熟明確而且大眾也能接受的商業模式◈ 如果成功的話，也可以做到規模化缺點
◈ 會和讓軟體自由獲得的理想有衝突◈ 專案需要足夠大以滿足客戶的需求案例學習
◈ MySQL [50]◈ SQLite [51]開放核心
在開放核心[52]模型中，專案的一些方面是免費的，但一些功能則是私有的，且只對付費使用者開放，通常要求這個專案有企業的需求。
優點
◈ 這是成熟明確而且大眾也能接受的商業模式◈ 如果成功的話，也可以做到規模化缺點
◈ 需要設計付費專案，且該專案應該是獨有的◈ 會和讓軟體自由獲得的理想有衝突◈ 獨有功能有可能會使得免費使用者不太高興案例學習
◈ Docker [53]◈ Elastic [54]◈ Mesosphere [55]◈ Sidekiq [56]基金會
基金會[57]是可以接收和支出的合法法人實體。鑑於其目的並非獲得利潤，因此可以更好保持中立地管理專案。在美國，基金會可以是 501c3（非盈利）或 501c6（貿易聯盟），許多軟體基金會都是貿易聯盟，因為非盈利基金會要求展示出慈善的目的，這在軟體開發中比較困難。
優點
◈ 中立，基金會可以幫助保護程式碼和管理社群◈ 可以在許多捐贈者中散佈影響力◈ 使得專案合法，公司會更願意向基金會付款/捐贈而非個人缺點
◈ 只適合大專案◈ 由於 IRS 的限制，專案能做什麼會有所限制◈ 需要大量社群的努力和各種技能，而且之後仍舊需要努力獲得籌款案例學習
◈ Ruby Together [58]◈ Python Software Foundation [59]◈ Node.js Foundation [60]風險投資
風險投資是高增長業務的一種籌資形式，不像銀行貸款或者任意一種債務財務形式，風險投資者通過提供資金來佔有你業務的一定股份。這種交易不像貸款，如果你的業務掛了你並不需要償還出資方。當然，如果你成功了，你也需要成倍的返還給你的投資者。
風險投資是高風險高回報的：風投者相比銀行對風險更加寬容，當然他們也期待你成功後的鉅額回報。如果你打算獲得風險投資，你應該建立股份有限公司。如果你對風險投資過程不熟悉，開始的最好方式就是詢問成功獲得風險投資的人。
優點
◈ 制度上的支援對成長中的業務有益◈ 大量的風投資金蓄勢待發缺點
◈ 風險投資在投資之初便做好了獲得成倍回報後退出的打算，歷史證明，由於開源專案的結構特點，風險投資的成功很難。◈ 風險投資者可能會因為優先順序改變其動機（譯者注：在中國有一類風險投資者故意誘導涉世不深的創業者簽訂不平等協議，尤其是在創業者熱情最濃而又最困難的時候，使其在業務失敗時也能全身而退，相應的，創業者會輸得很慘，值得小心對待）
案例學習
◈ Npm [61]◈ Confluent [62]◈ NodeSource [63]◈ Meteor [64]貢獻
我寫這個手冊主要是為了將我頭腦中的知識都整理出來，不過我並沒有打算做主要的貢獻或改變。優點和缺點大多是從我的觀點出發的主觀想法。
如果有什麼錯誤（尤其是案例學習），非常歡迎大家的修改。同時，如果發現有什麼分類漏掉了，我也非常歡迎大家的修改。
關於中文版的貢獻，如果有資訊上的錯誤或遺失，請到原文中提出，如果有中文翻譯上的錯誤，請在這裡直接提出。如果你覺得有資訊上的錯誤或遺失，但又各種原因無法用英文表述，擔心中文表述不會被採納，這種情況請還是在原文中提出，我或者其他同時會英文和中文的小夥伴會幫助解決問題的。
本翻譯專案使用翻譯輔助工具[65]輔助同步原文修訂部分。
協議
原文協議為 Creative Commons CC0 1.0 License，即你可以自由的使用，商業或非商業，不過如果你用了，很開心能從你那裡聽到點什麼，在這裡找到我 @nayafia[66]，當然這並不是要求必須做的。
中文版協議為 Creative Commons Attribution 4.0 International License，和原文協議差不多了，基本上可以說怎麼用都可以，唯一不要修改原作者名字或以原作者名字宣告演繹作品就可以了。
題圖來自 wxy，CC0 授權。