Awesome
オープンソースのための金銭的支援についてのガイドブック
"オープンソースの仕事はしているけれど、どうやって資金を捻出したらいいんだろう？"
オープンソースに対する仕事で報酬を得るための方法すべてを、私が知る限り列挙します。だいたい金額の小さい方から大きい方に並んでいます。それぞれのファンディングカテゴリーはいくつかの実例にリンクしています。（もし可能なら、ホームページではなく有用な記事やページにリンクしています）
カテゴリーは排他的ではありません。たとえば、あるプロジェクトは基金モデルを採用しながら、お金をもっと集めるためにクラウドファンディングも利用しているかもしれません。他の人はコンサルティングをしながら寄付ボタンを使っているかもしれません。このガイドの目的は報酬を得る方法の完全なリストを提供することであり、そうすればあなたにとって一番いいものを見つけることができるでしょう。
目次
- 寄付ボタン
- 助成金
- クラウドファンディング (売り切り)
- クラウドファンディング (定期課金)
- 書籍とグッズ
- 広告とスポンサー
- プロジェクトの仕事をするために企業に雇われる
- 現在雇われている企業でプロジェクトを開始する
- 助成金
- コンサルティングとサービス
- SaaS
- フリーミアムライセンス
- デュアルライセンス
- オープンコア
- 基金とコンソーシアム
- ベンチャーキャピタル
補遺: このガイドへの貢献 // ライセンスと帰属
翻訳: 原文（英語） // 繁體中文 // 簡體中文 // イタリア語
"個人的な努力" という但し書きは資金獲得の努力がプロジェクトではなく個人によってなされていることを意味します
寄付ボタン
サイトに寄付ボタンをつける。StripeとPayPalは寄付を受け付けるためのサービスとしての代表例。
良い点
- 制約があまりない
- やるべきことの少なさ： "設定したら忘れろ"
悪い点
- よほど熱心にやらないかぎりは十分な金額を得られない。
- 寄付を受け付けるための実体が必要で、それは手数料を取る。たとえばStripeやPayPal。
- 寄付をした人や組織が免税されるには、法的に寄付を受け付けている実体（合衆国では502(c)(3)非営利団体）でなければならない。SFC, OpenCollectiveとNumFOCUSがその例。個人や国際的な寄付だともっと難しい。
- 往々にしてプロジェクトの誰がその金額に「値する」のかがわかりづらく、分配も不明瞭。OpenCollectiveのような法人が役立つかもしれない。
ケーススタディ
賞金
ときどきプロジェクトや企業がオープンソースワークに報奨金を投じる（例： "このバグを直して$100を受け取ろう"）。以下にあげるリストに報奨金の授受を簡単にするWebサイトを紹介している。
良い点
- コミュニティの参加者に開かれている
- お金が特定の仕事に紐づけられている（サービスへの支払いや寄付よりも）
- セキュリティ関連で特に人気
悪い点
- プロジェクトに捻じ曲がったインセンティブをもたらす（質の低いPR、優先順位の混乱）
- 報奨金はそれほど高い金額にならない（$500以下）
- 継続的な報酬をもたらさない
ケーススタディ
クラウドファンディング（売り切り）
目下進行中のプロジェクトにではなく、実装したい特定のアイデアがあるなら、売り切りのクラウドファンディングは必要な資金を集めるのに適している。個人および企業があなたのキャンペーンに寄付したいと思うかもしれない。
良い点
- 制約があまりない
- たとえばKickstarterなどを使えば、個人が法的にお金を集めるのが簡単。
悪い点
- マーケットでキャンペーンを打つのにやるべきことがたくさんある。
- 通常、支出や経費に紐づけられる。
- 通常はそこまで高い金額ではない（一回あたり$50,000以下）。
- 企業がキャンペーンに寄付することを常に好むわけではない。
ケーススタディ
- Dave Gandy + Font Awesome
- Michal Papis + Rvm (personal effort)
- Andrew Godwin + Django (personal effort)
- ribasushi + CPAN (personal effort)
- RESTful WP-CLI
クラウドファンティング（定期課金）
もし目下進行中のプロジェクトに資金が必要なら、定期課金のクラウドファンディングキャンペーンを設定することができる。毎月または毎年の資金が確約され、ユーザーが解除しない限りはずっと続く。あなたのプロジェクトを何度も使っている人（個人および法人）が資金提供に応じるかもしれない。
良い点
- 制約があまりない
- たとえばPatreon, Salt, Gratipay, OpenCollectiveなどを使えば、個人が法的にお金を集めるのが簡単。
悪い点
- 継続的な寄付に対してのコミットを提供するのが困難（以前から有名なブランドや評判が高い必要がある）
- 定期的な寄付に対して、具体的な支出や経費の具体的な使途を説明するのが困難。
- 通常、それほど高い金額ではない（毎月$1,000-$4,000）
- 企業がキャンペーンに寄付することを常に好むわけではない。
ケーススタディ
- MochaJS
- React-boilerplate
- jsbin
- Tom Christie + Django REST framework (personal effort)
- Ruby Together
書籍とグッズ
もしあなたが他の人が学びたいと思うような特定領域の専門家であれば、書籍を執筆して売ることができる。O'Reillyのような出版社を見つけるか、自己出版するか。本を売るのに加え、いくつかのプロジェクトは仕事の足しにグッズ（シャツやパーカ）を売っている。
良い点
- 支出はプロジェクトには紐づかないため、創作の自由は保たれる。
- プロジェクト自体のマーケティングに使える。
- 初期の開発ののちも繰り返し使える収益源となる。
悪い点
- 多くの場合、それほど大きな収益をもたらさない。
- プロジェクトのコアとなる開発の妨げになる。
- グッズに経費がかかる
ケーススタディ
- Lua
- Daniel and Audrey Roy Greenfeld + Two Scoops of Django (personal effort)
- Sandi Metz + Practical Object-Oriented Design in Ruby (personal effort)
- Kyle Simpson + You Don't Know JS (personal effort)
- CocoaPods (fundraising for charity)
広告とスポンサー
あなたのプロジェクトに注目する人が多くいるなら、その人たちにリーチしたい広告主にスポンサーシップを売ることができる。おそらくは限られたターゲットの人たち（例： あなたがPyhonのプロジェクトを持っているなら、その人たちはPythonに技術的に詳しい人だと仮定できる）なので、それをアドバンテージとすることができる。
良い点
- 人々がお金を払ってもいいと思えるビジネスモデルに沿っている。
悪い点
- スポンサーシップを正当化するために、注目する人がたくさんいなければならない。
- ユーザーベースに関する信頼と透明性を必要とする（たとえば、トラッキングしない）。
- 広告主を見つけて管理するために多大な労力を必要とする。
ケーススタディ
プロジェクトの仕事をするために企業に雇われる
企業はときどきオープンソースの仕事をさせるために人を雇う。あなたがやりたいプロジェクトを利用している企業を見つけよう。分配されることもよくある（例： 50%が会社の仕事、50%がオープンソースの仕事）。もしくは、新しいプロジェクトのアイデアがある場合、あなたが作るものに興味を持ちそうな企業を見つけよう。この場合、実演できるものがあると役に立つだろう。
良い点
- リソースを持つ人（たとえば企業）をあてにできる。
- 企業のニーズに沿っている。
- 安定した収入。
悪い点
- 普通は“ラッキーであること”が求められる: はっきりした再現性のある手はずは存在しない。
- プロジェクトはすでに有名でよく使われている必要がある。
- 企業の求める最低ラインを超えないと首になる。
- ガバナンスの問題。企業はプロジェクトに必要以上の影響力を発揮することがある。
- プロジェクトの活発さやバランスに影響を与える。
ケーススタディ
- Donald Stufft + Hewlett-Packard and Python packaging (personal effort)
- Rich Hickey + Cognitect and Clojure
- Aaron Patterson + ManageIQ and Ruby, Rails (personal effort)
- Ryan Dahl + Joyent and Node.js (opens a YouTube video) (personal effort)
現在雇われている企業でプロジェクトを開始する
多くのオープンソースプロジェクトは被用者のサイドプロジェクトとして始まる。プロジェクトはその企業規模を超えた突然の成長をするかもしれないが、サイドプロジェクトとして始めるのはそのアイデアを試す意味でよい試みだ。
*この道を選ぶ場合、あなたは自分の会社のオープンソースポリシーについて理解しておく必要がある。いくつかの企業は従業員が業務時間にオープンソースに貢献することを奨励している。またある企業はあなたの成果を会社のプロジェクトとして扱うだろう。なにごとも思い込むのではなく、始める前に会社の人に尋ねてみよう。
良い点
- 給料のことを気にせず新しいアイデアを試す自由がある。
- 企業のニーズに沿っている場合がある。
- 新しく実験的なアイデアに向いている。
悪い点
- サイドプロジェクトとして始めるか、業務時間中にやってよいという承諾を得る必要がある。
- 意図しない企業の影響がでるリスク。
- 後になってから複雑な管理上の問題に発展することがある
ケーススタディ
助成金
助成金は事実上、返済の義務のない巨額の寄付である。しばしば慈善団体はあなたに助成金を与えることで他のメリットを得る。あなたに近づくことや、インパクトを見せつけたり、あなたの成果について調査したり、節税をしたり。
助成金は様々な場所から来る。企業はもちろんのこと、ソフトウェア財団、慈善団体、そして政府など。助成金の専門的または法的な意味は、それがどこからきたのかによって大きく異なる。たとえば、ある企業があなたに「助成金」を与えても、それをコンサルティング料金と考えているかもしれない。慈善団体は非営利団体にしか寄付できないので、あなたは自らが非営利になるか、（よくある例としては）あなたをサポートしてくれる非営利団体を探さなくてはならない。もしあなたが助成金に詳しくなければ、それがどんな仕組みか理解するのに最良の方法として、それを受け取ったことがある人に話を聞くことだ。助成金を受け取ったことのある例として、下にそのリストを挙げる。
良い点
- 制約がほとんどない。
- 助成金はかなりの間プロジェクトに集中するのを助けてくれる。
- 一息ついて実験をできるプロジェクトルームを与えてくれる。
悪い点
- ソフトウェア関連の支援団体は多くない（慈善団体、政府、企業ともに）
- 助成金は有限である。助成金を超えてなお続くサステナビリティが必要なのは変わらない。
ケーススタディ
コンサルティングとサービス
コンサルティングはオープンソースの資金を捻出するための柔軟な方法だ。自分の思う通りに時間を捻出する自由がある（たとえば、週に30時間コンサルティングをして、10時間をオープンソースに費やす）。コンサルタントの時間給は給料をもらう会社員よりも高い。身分が安定しない、福利厚生がない、などの理由による。もしこの種の労働を定期的にするのであれば、合同会社を設立したくなるかもしれない（米国以外の場合は同等のもの）。
もしあなたのプロジェクトが人気のあるものなら、プロジェクト自体に関わるコンサルティングやサービスを提供できる。たとえば、クライアントはそのプロジェクトを実装することに対してお金を払うかもしれないし、カスタムの何かを構築したり、利用方法を教えることなども同様。
良い点
- 人々がお金を払ってもいいと思えるビジネスモデルに沿っている。
悪い点
- コンサルティングはヒューマンパワーを必要とするのでスケールしない（例外的に突出した人を除く）
- ビジネスニーズはプロジェクトのコードを書くことやそれに類するその他の仕事とはかけ離れたものになることがある。
- ソフトウェアをシンプルに使えるものにすることとは相性が悪い
- 人々が関連サービスにお金を払いたいと思う程度にはプロジェクトが有名でなくてはならない。
ケーススタディ
SaaS
SaaSとはSoftware as a Serviceを意味する。このモデルではコードベースそれ自体はオープンソースだが、プロジェクトを利用するために追加の有料サービスを提供できる。よくある有料の例はホスティングへの課金である。
良い点
- プロジェクトの周囲にコミュニティを形成し、ホスティングサービスから資金を捻出できる。
- オープンソースプロジェクトがユーザーにフォーカスすること、そして企業がプロジェクトを受け入れるだけのニーズを育てることを可能にする。
- ユーザーの数に応じてスケールできる。
悪い点
- ときにホスティングがプロジェクトに必要な人を雇うだけの額に見合わないことがある。
- 製品の“二段階”サポートは無料のユーザーを不幸にしうる。
ケーススタディ
フリーミアムライセンス
"フリーミアム"ライセンスはオープンソースではない。というのも、オープンソースライセンスに要求される自由を同時に満たすことができないからだ（例：ソースコードは自由に見ることができ、再配布および修正の自由がある）。それでもオープンソースの仕事には間接的に関わっている。
フリーミアムライセンスはオープンソースにおけるいくつかの自由を商業的な用語に制限する。たとえば、ソースコードを参照することは可能だが、そのコードを利用するにはコマーシャルライセンスを必要とする。
良い点
- 人々がお金を払ってもいいと思えるビジネスモデルに沿っている。
- 成功すればスケールする可能性がある。
- エンドユーザーの製品に向いている。
悪い点
- 実際にはオープンソースではない。
- いまだ調査の必要な新領域であり(しかしながらshareware運動と関わりがある)、まだよくわかっていない。
ケーススタディ
- Fair Source, used by Sourcegraph
- BSL (Business Source License), used by MariaDB
デュアルライセンス
ときおり、プロジェクトはまったく同じコードベースに二つの異なるライセンスを提供することがある。一つは商売に向いたもので、もう一つはそれほどでもない（例・GPL）。後者は利用者が自由に使えるためものもので、企業は法的な平安を得るために商業ライセンスを購入する。
良い点
- 人々がお金を払ってもいいと思えるビジネスモデルに沿っている。
- 成功すればスケールする。
悪い点
- ソフトウェアに自由にアクセスできるようにすることと相性が悪い。
- 顧客ニーズが存在しうるだけプロジェクトが大きい必要がある。
ケーススタディ
オープンコア
オープンコアモデルでは幾つかの面でプロジェクトは自由だが、その他の機能はプロプライエタリであり、購入者だけが利用できる。通常、このモデルはプロジェクトに大企業の需要があるときだけ機能する。
良い点
- 人々がお金を払ってもいいと思えるビジネスモデルに沿っている。
- 成功すればスケールする可能性がある。
悪い点
- 課金できるものがなくてはならない（これはつまりある機能を排他的にすることを意味する）。
- ソフトウェアに自由にアクセスできるようにすることと相性が悪い。
- 製品の“二段階”サポートは無料のユーザーを不幸にしうる。
ケーススタディ
基金とコンソーシアム
基金とは寄付の受け入れおよび支払いが可能な法人である。なぜなら、その目的は利益を生むことではなく、素晴らしく中立にプロジェクトを管理することにある。合衆国においては501(c)(3) (nonprofit) または 501(c)(6) (trade consortium)である。多くのソフトウェア基金は501(c)(6)である。というのも、501(c)(3)はチャリティ目的を掲げる必要があり、それはソフトウェアにとってしばしば困難なことだからだ。
良い点
- 中立である。基金はコードを守り、コミュニティを管理できる。
- 複数の寄進者に影響力が分散する。
- プロジェクトを合法的なものにすることで、個人よりも基金に資金を提供したいと思う企業を安心させられる。
悪い点
- 大きなプロジェクトにだけ意味がある。
- 歳入庁の要請により(501(c)(3)の代わりに多くが501(c)(6)を選ぶ)、できることには制限がある
- コミュニティの真摯な努力と様々なスキルを要求する（法人立ち上げのあとも資金集めが必要になる！）
ケーススタディ
ベンチャーキャピタル
ベンチャーキヤピタルは大きな成長が見込めるビジネスにおける資金集めの一形態である。銀行ローンやその他の融資とは異なり、ベンチャーキャピタルは資金提供の見返りとして企業資産（あなたのビジネスにおける所有権）を要求する。トレードオフとなるのは、ローンを組む場合と異なり、ビジネスが失敗した場合でも債権者にお金を返す必要はない。しかしながら、もし成功したら、出資者に数倍の資産を返すことになる。
ベンチャーキャピタルは「ハイリスク・ハイリターン」である。ベンチャーキャピタルは、そう、たとえば銀行よりもはるかにリスクに寛容だが、成功したときの見返りに多大な期待を寄せている。ベンチャーキャピタルをあてにするのならば、株式会社を設立しなければならないし、できればデラウェア州でなければならない。ベンチャーキャピタルのプロセスに詳しくないなら、ベンチャー立ち上げに成功した起業家に接触することからはじめるのがよいだろう。
良い点
- 組織的なサポートはビジネスの成長を助けるだろう。
- 非常に多くの資本を使うことができる。
悪い点
- ベンチャーキャピタルはイグジット（たとえば投資が何倍にも返ってくること）を期待している。歴史が示すところによると、オープンソースビジネスにおいてこれは構造的に困難である。
- ベンチャーキャピタルは動機を変更することがあり、優先度に影響する。
ケーススタディ
このガイドへの貢献
私は自分の知識を頭の中から出して整理するためにこのガイドを書きましたが、大きな変更や執筆を行う予定はありません。良い点・悪い点がいくらか主観的であることはわかっていますが、私の考えを反映したものであはります。
なにかが事実と異なっている（とくにケーススタディの例）場合は、編集してください。もちろん、私が見通していたカテゴリーがあるなら、喜んで追加します。
ライセンスと帰属
このガイドはクリエイティブコモンズ CC0 において利用できます。つまり、あなたはいかなる理由においてもこの文書を利用でき、商用・非商用を問いませんし、クレジットも必要ありません（パブリックドメイン）。もし使ったら、教えてくれると嬉しいです！（私のアカウント： @nayafia）でも、そうしなければいけないというわけでもありません。