- Published on
オープンソース資金調達 2026: GitHub Sponsors / Polar / Open Collective / Tidelift / Ko-fi — メンテナはどう報酬を受け取るか (Deep Dive)
- Authors
- Name
- Youngju Kim
- @fjvbn20031
「オープンソースは愛の労働である。しかし愛だけでは家賃は払えない。」
世界のソフトウェアインフラの約90%はオープンソースの上で動いている。そしてそのオープンソースの約90%は、1%以下のメンテナの手で支えられている。この非対称性こそが、2014年のHeartbleed、2021年のlog4shell、2024年のxz-utilsバックドア、そして毎年繰り返される「この重要ライブラリの唯一のメンテナがバーンアウトで消えた」というニュースの構造的原因だ。
この記事はその構造に正面からぶつかるメンテナの視点で、2026年現在使える9つの資金調達チャネルを比較する。「月100ドルは入るが、それがいつまで続くのかわからない」という人々の実データ、どのチャネルが実際にコンバージョンするのかという正直な評価、そして企業がついにコストを認め始めたSentryのOpen Source Pledgeのような流れまで整理する。
プロローグ — メンテナのバーンアウトとフリーライダー問題
2024年のxz-utilsバックドア事件は一文に要約できる。バーンアウト状態のメンテナが、「手伝います」と現れた正体不明の新規貢献者にcommit権限を譲り、その人物がほぼ全てのLinuxディストリビューションに侵入できるSSHバックドアを仕込んだ。この事件の真の原因はバックドアコードそのものではなく、数十億ドル規模のインフラが一人の無償労働の上に乗っていた、という事実だ。
構造的問題
- Fortune 500企業の約96%が直接または間接的にOSSに依存している(Synopsys OSSRAレポート)。
- しかしその依存関係を支えるメンテナの75%以上が1セントの資金援助も受けていない(Tideliftメンテナ調査)。
- 人気OSSパッケージを維持するメンテナは平均して週5〜10時間を無償労働に費やしている。
- 「うまくいっている」メンテナの寄付平均月収は、自営業の最低時給の半分にも満たないことが多い。
フリーライダー問題
OSSは古典的な共有地の悲劇だ。AWSはPostgreSQLの上で数兆円規模の売上を作るが、PostgreSQLのコア開発者に直接振り込まない。一人の消費者が依存関係から得る価値と、その人がメンテナに返す価値の距離は、ほぼ常に無限大に近い。
この記事のすべてのチャネルは、その距離を縮めようとする試みだ。あるチャネルは個人寄付、あるチャネルは企業ライセンス、あるチャネルは自動依存関係トラッキング、あるチャネルはバウンティをメカニズムとして使う。メカニズムが違えばコンバージョンと持続性も違う。
この記事の約束
これは資金プラットフォーム企業のマーケティング資料ではない。実際のメンテナが公開している数字、各チャネルの限界、そして「自分が今日寄付を集め始めたら、本当に家賃が払えるのか」という問いに正直に答える。
第1章 · チャネル一覧 — 9つの資金調達オプション
深く掘る前に全体地図を描こう。チャネルは大きく4つに分類される。
| 分類 | チャネル | 一行要約 |
|---|---|---|
| 開発者デフォルト | GitHub Sponsors | GitHubプロフィールに刻まれたSponsorボタン。摩擦最小。 |
| 開発者デフォルト | Polar.sh | StripeベースのMoR(merchant of record)。ベネフィット/サブスク/デジタル商品。 |
| 団体/透明会計 | Open Collective | 非営利の財政ホスティング。全取引が公開帳簿。 |
| エンタープライズ | Tidelift | 企業サブスク料金をメンテナに分配。セキュリティ/ライセンスSLA。 |
| 消費者向け | Patreon | クリエイター向け。メンバーシップとティア。 |
| 消費者向け | Ko-fi / Buy Me a Coffee | 単発チップ中心。気軽な寄付がしやすい。 |
| 消費者向け | Liberapay | 非営利、匿名寄付、定期決済のみ。 |
| 自動分配 | Thanks.dev | 依存関係グラフベースの自動寄付。企業加入型。 |
| 自動分配 | Algora | Issueバウンティ + 寄付。GitHubの上に直接乗るマーケットプレイス。 |
各チャネルは(1)収益モデル(誰が、なぜ支払うか)(2)手数料構造(3)税金/支払いの責任範囲(4)人口統計とコンバージョンで異なる。この記事の残りはこの4軸をチャネル別に掘り下げる。
第2章 · GitHub Sponsors — デフォルトだが天井が低い
GitHub Sponsorsは2019年にベータで始まり、いまや事実上の「デフォルト」チャネルになった。理由は単純だ — メンテナの仕事場(GitHub)の中に決済ボタンがある。
どう動くか
- メンテナがレポに
FUNDING.ymlを追加すると、「Sponsor」ボタンがPRの隣に自動で出る。 - 寄付者は定期決済(月次)または単発で寄付できる。
- メンテナはティアを作れ、ティアごとに異なるベネフィットを提供できる。
- GitHubは2024年から**プラットフォーム手数料0%**を維持(決済処理手数料は別)。
- 支払いはStripe Connectベース。日本のメンテナも参加可能だが税金処理は本人責任。
実際の数字
公開データを総合すると:
| プロファイル | 月収 | コメント |
|---|---|---|
| 単一アクションメンテナ(人気のGitHub Actionなど) | $0〜$50/月 | 企業ユーザー多数、寄付者ほぼなし |
| 中規模Node/Rustライブラリ単独メンテナ | $100〜$500/月 | 定期寄付者5〜20人レベル |
| 大型フレームワークコア貢献者(個人) | $1k〜$5k/月 | Caleb Porzio、Sindre Sorhusなど公開事例 |
| フルタイムOSSに転向したトップティアメンテナ | $10k〜$30k/月 | Evan You(Vue)、Anthony Fuなど |
強み
- ほぼ摩擦がない: 寄付者もメンテナもGitHubアカウントだけで完結。
- 信頼: 決済インフラはGitHubが責任を持つ。
- 露出: GitHubプロフィールとレポに自然に露出する。
限界
- B2Bコンバージョンが弱い: 企業の経理は「個人的な寄付」フローでの支払いを嫌う。請求書、消費税、会計科目として処理しづらい。
- 天井が低い: 寄付者一人あたり通常
$5〜$25/月。数千人単位で集めない限り大きな金額にならない。 - ベネフィット運用が弱い: ティアを作れても、ティアごとの自動化ベネフィット(ダウンロード、サイトアクセス等)の提供は貧弱。
誰に向くか
GitHub Sponsorsは「寄付チャネルを1つだけ持つならこれ」の正解だ。ただし天井を理解して始めること。多くのメンテナはGitHub Sponsorsだけではフルタイム化できない。
第3章 · Polar.sh — 開発者ファーストMoRの台頭
Polar.shは2023年に登場、2024〜2026年にかけて開発者向け決済プラットフォームの強力な代替として急成長した。中核的な差別化点は2つ。
- Merchant of Record (MoR): Polarが決済の法的販売者になる。つまり消費税/販売税の申告、請求書発行、返金処理をPolarが行う。メンテナは入金を受け取るだけ。
- GitHub Sponsors統合: 2024年後半、PolarはGitHub Sponsorsのバックエンド決済を処理するオプションを提供開始した — 一箇所で管理しながらGitHub側の露出はそのまま得られる。
どう動くか
- サブスクティア、単発決済、デジタル商品(ファイル、ライセンスキー)、ベネフィット(GitHub Issueの優先順位など)を自由に構成できる。
- 手数料はStripeと同水準だが、MoRコストが含まれる(約4% + Stripe決済手数料)。
- READMEに寄付ウィジェットを直接埋め込める。
- 寄付者がPRを開くとメンテナが優先レビューする、というベネフィットを自動化できる。
強み
- B2Bフレンドリー: 請求書発行が自動。経理チームが喜ぶ。
- 柔軟な価格設定: ティア、上限、期間限定キャンペーン等、SaaS級の価格設定ツール。
- 収益化の多様化: 寄付だけでなくデジタル商品販売が可能。
- 開発者体験: API、Webhookがよく作られている。自前サイトに統合しやすい。
限界
- MoR手数料が高く見える: GitHub Sponsorsの「0%手数料」マーケティングに比べると名目上高く見える。ただし税金/消費税処理を全て代行するので実質コストは異なる。
- 認知度: 一般個人寄付者にはまだGitHub SponsorsやKo-fiほど馴染みがない。
- ベネフィット自動化はSaaS的マインドが必要: 魔法的に変換するわけではなく、ベネフィットを設計して運用する必要がある。
実際の利用事例
Astro、Nuxt、Vercelが後援する個別メンテナたち、Yjs、Honoの一部メンテナがPolarを一次チャネルに使っている。「GitHub Sponsorsの露出 + Polarの決済インフラ」の組み合わせが事実上の標準になりつつある。
誰に向くか
企業スポンサーを本格的に受けたいメンテナ、寄付以外にデジタル商品/有料ベネフィットを売りたいメンテナ、税金処理を外部委託したいメンテナに強力。
第4章 · Open Collective — 透明会計とグループ資金
Open Collectiveは単独メンテナよりも団体/チームOSSプロジェクトに強いチャネルだ。中核は透明な公開帳簿。すべての収入と支出が誰でも閲覧できるページに記録される。
どう動くか
- プロジェクトが「Collective」を作る。これは法人実体ではなく、ホスティング団体の下にある仮想資金プールだ。
- 寄付者が月次または単発で寄付する。
- 誰かが経費請求(例:「AWS請求書
$50」「デザイナー外注費$200」)を出すと、その資金プールから支払われる。 - すべての取引が公開ページに自動記録される。
- 財政ホスト(例: Open Source Collective 501(c)(6))が法的/税務責任を持つ。
強み
- 透明性: 寄付者が「自分の資金がどこに使われたか」を正確に見れる。コミュニティや慈善的プロジェクトに強い。
- グループ協業: 複数メンテナが1つの資金プールを共有しやすい。
- 財政ホスティング: 法人実体なしで寄付を受け、支出できる。
大きな変数 — 2024年OCFのwind down
2024年、Open Collective Foundation (OCF、501(c)(3)慈善団体向けの財政ホスト)が運営終了を発表した。これによりそのホスト下にあった約600の団体が他のホストに移るか資金を整理する必要が生じた。
これはOpen Collective プラットフォーム自体が破綻したのではなく、その下の1つのホスト団体の終了だ。しかし団体型OSSプロジェクトが「財政ホスト集中リスク」を初めて真剣に認識した事件だった。
2026年現在、開発者OSSプロジェクトは主にOpen Source Collective (501(c)(6)業界団体) 下にあり、このホストは安定的に運営中だ。ただし移行先が少ないという構造的リスクは残る。
限界
- 単独メンテナにはオーバーキル: 1人プロジェクトに透明会計とグループ資金プールは不要。
- 手数料: ホスト手数料5〜10% + 決済処理手数料が通常。GitHub Sponsorsより高い。
- ホスト依存: ホスト団体の方針/存続がプロジェクト資金に影響する。
誰に向くか
複数人で運営するOSSプロジェクト — 例: webpack(多数のメンテナ)、Babel、ミートアップ/カンファレンスを共同運営するコミュニティに合う。単独メンテナ1人ライブラリには摩擦の少ないGitHub Sponsorsが良い。
第5章 · Tidelift — エンタープライズサブスクモデル
Tideliftは他のすべてのチャネルと根本的に異なるメカニズムだ。「寄付」ではなくエンタープライズサブスクリプションだ。
どう動くか
- 企業顧客がTideliftに年間サブスクリプション料金を支払う。通常、自社が使っているOSSパッケージのセキュリティ/ライセンスSLAを得るため。
- TideliftはそのサブスクリプションをOSSパッケージの**lifter(メンテナ)**に分配する。
- メンテナは「lifter契約」を結び、セキュリティパッチSLA、ライセンス情報の正確性、依存関係整理などの義務を負う代わりに、定期収入を得る。
何が違うか
- 善意の寄付ではなくビジネス取引: 顧客がSLAを買い、メンテナがSLAを提供する。
- 企業会計フレンドリー: 「OSSセキュリティサブスク料金」は会社の会計科目として明確だ。
- メンテナ収入が安定: 一度lifterになれば四半期/年単位で収入が入る。
実際の収入
公開データによると、よく組み込まれているパッケージのメンテナはTideliftだけで$500〜$3k/月水準の収入を作る。複数の人気パッケージのメンテナなら1万ドル以上も可能。ただし申請-承認プロセスがあり、すべてのパッケージが受け入れられるわけではない。
強み
- 反復的な安定収入: 四半期/年単位の契約が基本。
- B2B明確性: 企業の経理チームが処理しやすい形態。
- サプライチェーンセキュリティトレンドと整合: SBOM、依存関係セキュリティが強調される時代に適合。
限界
- 承認ゲート: Tideliftが「このパッケージをカタログに入れるか」を決める。小さい/無名のパッケージは登録されない可能性がある。
- SLA義務: 決められた期間内にセキュリティパッチを出さなければならない。本業がある人には負担。
- 個人寄付効果が0: Tideliftは個人寄付者に露出するチャネルではない。
誰に向くか
エンタープライズで深く使われているライブラリ(セキュリティライブラリ、コアインフラライブラリ、頻繁に引用されるユーティリティ)のメンテナに最も強力。コンシューマーアプリ寄りのライブラリには弱い。
第6章 · Patreon / Ko-fi / Buy Me a Coffee — 消費者向けの微妙な違い
この3つのチャネルはよく一緒に語られるが、実際にはかなり色が違う。
Patreon
- 元々YouTuber/ポッドキャスター/アーティスト中心に育ったプラットフォーム。
- ティアベースのメンバーシップサブスクに強い。
- 手数料8〜12% + 決済処理。
- OSSメンテナのうちでは、コンテンツを合わせる人(ブログ、動画、講座)が主に使う。
Ko-fi
- 「コーヒー1杯」メタファーの単発チップが自然なトーン。
- 定期寄付(メンバーシップ)もサポート。
- 基本手数料0% + Ko-fi Gold有料プラン。
- デジタル商品販売、コミッション受付もサポート。
- 開発者インディーメーカー、インディーゲーム開発者、デザイナーに人気。
Buy Me a Coffee
- Ko-fiとほぼ同じトーン、単発チップ中心。
- 5%手数料、ただしすっきりしたUXと強いモバイル体験。
- メンバーシップ、デジタル商品もサポート。
比較マトリックス
| 項目 | Patreon | Ko-fi | Buy Me a Coffee |
|---|---|---|---|
| トーン | メンバーシップサブスク | 親しみやすいチップ | 親しみやすいチップ |
| 手数料 | 8〜12% | 0% (Gold別) | 5% |
| 単発決済 | 可能 | 強み | 強み |
| メンバーシップ | 強み | 可能 | 可能 |
| デジタル商品 | 可能 | 可能 | 可能 |
| 開発者トーン適合 | コンテンツがあれば強い | インディーメーカーに強い | インディーメーカーに強い |
OSSメンテナにとっての現実
この3つのチャネルすべて、「コードだけ書く」メンテナにはコンバージョンが低い。寄付者は人の顔と物語に寄付するもので、パッケージのchangelogには寄付しない。コンテンツ(ブログ、動画、Twitter/X)が強いメンテナには強力だが、単にGitHub活動だけのメンテナにはGitHub Sponsorsより良くない。
誰に向くか
ブログ/動画/Twitter (X) のような副次的コンテンツがあり、メンテナ本人が「パーソナルブランド」を意識する場合。そうでなければGitHub Sponsorsの方が摩擦が少ない。
第7章 · Liberapay — 非営利寄付の純粋形
Liberapayは他のすべてのチャネルと最も異なる運営哲学を持つ。
特徴
- 非営利(ベルギーASBL)団体が運営。
- プラットフォーム手数料0%(決済処理手数料のみ)。
- 定期寄付のみ対応(単発決済はなし)。
- 匿名寄付が可能。
- 自体もLiberapayで寄付を受けて運営される(「自分のドッグフードを食べる」)。
強み
- 最も「オープンソース精神」に近いチャネル — 非営利、透明、匿名性保証。
- 手数料が事実上最も低い。
- 寄付者の個人情報露出が最小化される。
限界
- 規模と露出が小さい: ユーザープールがGitHub Sponsorsより大幅に小さい。
- 単発寄付不可: 「今日このライブラリすごい仕事した、1回だけ寄付」ができない。
- 決済インフラ依存: 決済パートナー問題が起きると一時的に出金が止まったことがある。
誰に向くか
理念的に非営利/透明なチャネルを優先したいメンテナ、そして匿名寄付者プールが存在しそうなプライバシー/セキュリティツールのメンテナに合う。
第8章 · Thanks.dev — 依存関係グラフによる自動分配
Thanks.devは寄付の「選択」側面を自動化しようとする試みだ。一人ずつメンテナを選んで寄付ボタンを押す代わりに、レポの依存関係をスキャンして自動でメンテナに分配する。
どう動くか
- 企業がThanks.devに加入し、月次/年次予算を設定する(例: 月
$1,000)。 - Thanks.devがその会社のレポの
package.json、Cargo.toml、go.modなどをスキャンする。 - 依存関係の重み(直接/間接、依存パッケージ数)に応じて予算を自動でメンテナに分配する。
- メンテナはGitHub/Stripe連携後、入金を受けるだけ。
強み
- 会社側: 「どのOSSを寄付するか」悩む必要なし。実際に使っているパッケージのメンテナが自動で報酬を得る。
- メンテナ側: 依存グラフ深部にいる小さなパッケージのメンテナも自動で報酬を得る。
- サプライチェーンセキュリティ整合: 自社が依存している人が誰かが自動で可視化される。
限界
- メンテナ一人あたりの金額が小さい: 分配が広範囲なので、一人あたり
$1〜$10/月水準にとどまるケースが多い。 - 会社側の認知度/予算確保が難しい: 「なぜOSSに月1,000ドル使うのか」を経営層に説得するのが最大の壁。
- メンテナの積極性への報酬がない: メンテナが活動を止めても分配は続き得る。
SentryのOpen Source Pledge参加
Sentryは2024年に開始したOpen Source Pledgeの一環として、フルタイム開発者1人あたり年$2,000をOSSメンテナ寄付に使うと公約した。この流れに加わる会社が増えれば、Thanks.devのような自動分配チャネルのインパクトも増す。
誰に向くか
会社側: 大規模なOSS依存グラフを持ち、「報酬の自動化」を望む会社。メンテナ側: 深い依存関係を持つ小さなライブラリ(leftpadのような下位ユーティリティ)のメンテナにこれまで見えなかった収入を作ってくれる。
第9章 · Algora — バウンティ + 寄付の結合
Algoraは2つを同時に行う。(1) Issue単位の**バウンティ(賞金)**マーケットプレイス。(2) 会社単位の寄付チャネル。
どう動くか
- 会社または個人がGitHub Issueにバウンティを掛ける(例:「このIssueを解決したら
$500」)。 - 誰でもPRを送り、マージされればバウンティを受け取れる。
- 別途、会社はメンテナ/プロジェクトに定期寄付もできる。
- メンテナは自分のレポのIssueに、会社寄付金からバウンティを直接掛けることもできる。
強み
- 成果ベース: 漠然とした寄付ではなく、具体的な作業への決済。
- 新規貢献者を引き寄せる: バウンティのあるIssueは新規貢献者を強く引き寄せる。
- 会社の直接影響力: 「自社が本当に必要な機能」に直接資金を投じる。
限界
- メンテナ時間視点ではリスク: バウンティだけ追う貢献が増えるとメンテナのレビュー負担が増す。
- AIスロップリスク増大: バウンティが大きいIssueにAIで大量生成された低品質PRが押し寄せる(2025〜2026年に最も深刻になった現象)。
- メンテナの安定収入ではない: バウンティは1回ずつ入る収入で、定期収入ではない。
誰に向くか
会社: 具体的な機能/バグ修正に資金を投じたいとき。メンテナ: 安定収入ではなく副収入または新規貢献者誘致のツールとして。
第10章 · チャネル vs 収入 マトリックス — 正直な評価
ここまでの9つのチャネルを、メンテナが実際に気にする軸で比較しよう。
| チャネル | 参入摩擦 | B2Bコンバージョン | 定期収入安定性 | メンテナ平均天井 | 税金処理 |
|---|---|---|---|---|---|
| GitHub Sponsors | 非常に低い | 弱い | 中 | $1k〜$5k/月 | メンテナ責任 |
| Polar.sh | 低い | 強い | 中〜高 | $5k〜$20k/月 | MoR (Polar処理) |
| Open Collective | 中 | 中 | 中 | 団体単位$5k〜$30k/月 | ホスト処理 |
| Tidelift | 高(承認) | 非常に強い | 非常に高い | $1k〜$10k/月 | Tidelift処理 |
| Patreon | 低い | 弱い | 中 | $500〜$3k/月 | メンテナ責任 |
| Ko-fi / BMC | 低い | 弱い | 低(チップ中心) | $200〜$1k/月 | メンテナ責任 |
| Liberapay | 低い | 弱い | 中 | $200〜$1k/月 | メンテナ責任 |
| Thanks.dev | 非常に低い | 非常に強い(会社側) | 中(自動) | $10〜$200/月/メンテナ | Stripe処理 |
| Algora | 中 | 強い | 低(バウンティ) | 変動 | プラットフォーム処理 |
正直な推薦 — メンテナのペルソナ別
1人ライブラリメンテナ(utility-beltのような小規模パッケージ)
- 1次: GitHub Sponsors(摩擦ゼロ)。
- 2次: Thanks.dev(依存グラフ深部にいるなら自動収入)。
- 3次: Algoraバウンティ(意欲のある会社があるなら)。
中規模フレームワーク/ライブラリのコア貢献者
- 1次: GitHub Sponsors + Polar統合(露出 + B2B)。
- 2次: Tidelift(セキュリティSLAの義務を負えるなら)。
- 3次: Open Collective(チーム単位で運営するなら)。
エンタープライズで深く使われるインフラライブラリのメンテナ
- 1次: Tidelift(最も整合)。
- 2次: GitHub Sponsors(個人寄付者の補完)。
- 3次: 直接コンサル/サポート契約(別記事)。
コンテンツが強いメンテナ(ブロガー、動画クリエイター)
- 1次: GitHub Sponsors + Patreon(コンテンツメンバーシップ)。
- 2次: Ko-fi / Buy Me a Coffee(単発チップ)。
- 3次: Polar(デジタル商品販売)。
第11章 · 企業側 — Open Source Pledgeと資金モデル
チャネルはメンテナ側のツールだ。企業側にも変化がある。2024〜2026年の核心的流れは、会社がOSSに定量的に資金を投じると公約することだ。
SentryのOpen Source Pledge
2024年にSentryが開始したOpen Source Pledgeはシンプルな公式を提案する。
フルタイム開発者1人あたり年
$2,000をOSSメンテナ寄付に使う。
100人の会社なら年$200,000、1,000人の会社なら年$2Mだ。これが集まればメンテナプールに意味のある資金が流れ込む。
2026年現在、Sentry、Astral (uv/ruff)、Vercelの一部チーム、Stripeの一部、そのほかSaaS企業数十社が加入。運動のインパクトは加入会社数が1,000を超えるかにかかっている。2026年時点では100〜数百のレベル。
OpenJS、CNCF、Linux Foundation Europe
非営利の資金モデルも進化している。
- OpenJS Foundation: Node.js、Express、ESLintなどJS生態系のOSSプロジェクトを後援。会社会員費で運営。
- CNCF: Kubernetes、Prometheus、etcdなどクラウドネイティブプロジェクトのホスト。インキュベーションと卒業段階でプロジェクトを育てる。
- Linux Foundation Europe: 2022年発足。欧州規制環境に合わせたOSSガバナンスホスティングを提供。
これらの財団が後援するモデルの核心は「個人メンテナに直接資金を渡すよりも、プロジェクト単位でコストをまかなう」ことだ。CIインフラ、セキュリティ監査、カンファレンス運営費などがそこから出る。
VC系OSS企業 — 別のゲーム
Supabase、Tailscale、Vercel、Linear、PosthogのようなVC系OSS企業は、資金構造自体が異なる。
- シード/シリーズ資金が最初からメンテナのフルタイム給与を支える。
- コアメンテナは会社の従業員で、外部貢献者は会社が管理する。
- 売上はクラウドホスティング / SaaS / エンタープライズライセンスで作る。
- 寄付はほぼ受けない、または外部貢献者をGitHub Sponsors等で支援する程度。
このモデルはOSS企業でありメンテナ資金調達チャネルではない。Supabaseのメンテナが GitHub Sponsorsで受ける寄付金は会社給与とは別の少額だ。この2つを混同してはいけない。
第12章 · 「企業から資金を受け取ってよいか」 — 正直な議論
オープンソース資金調達における最大の政治的論争は「企業からの資金を受け取ってよいか」だ。中核となる3つの立場を整理しよう。
立場1 — 「企業の資金は無条件で受け取るべき」
- 会社はメンテナの労働から価値を得ている。その価値を返してもらうのは正当だ。
- メンテナが飢えればOSS自体が危険になる(xz-utilsのような事件)。
- どんな会社からの資金を受けようと、メンテナが決定権を持てばよい。
立場2 — 「条件付きで受け取る」
- ライセンス決定権、ロードマップ決定権を会社に譲らない限り、受け取ってもよい。
- ただし1社の比重が大きすぎると危険だ。寄付者プールは多様であるべき。
- 会社の「スポンサー優先」のようなベネフィットは慎重に設計しなければならない。
立場3 — 「企業の資金を受けると魂が売られる」
- 会社の寄付者は結局影響力を行使する。明示的でなくとも黙示的に。
- 非営利チャネル(Liberapay)だけ使う方が清潔だ。
- 「趣味としてのOSS」の純粋性を守るべきだ。
現実的な折衷案
ほとんどのメンテナは立場2(条件付き)に収束する。実践的なガイドラインは以下のとおり。
- 1人の寄付者が全収入の30%を超えないようにプールを多様化する。
- ライセンス/ガバナンス決定は寄付と無関係であると明示する。
- 寄付者ベネフィットは「Issue優先のような時間効率」中心とし、コード決定に影響を与える形(例: 「スポンサー要求機能優先」)は避ける。
- 寄付内訳を公開する。透明性が信頼を作る。
第13章 · メンテナ視点の実践 — フルタイムOSSは可能か
ここで最も難しい問いに答える番だ。「自分がフルタイムOSSメンテナになれるか?」
フルタイムOSSへの2つの道
- VC系OSS企業に加入する: 従業員になる道。最も安定だが、もはや「独立メンテナ」ではない。
- 多様なチャネルの寄付でフルタイム収入を作る: 難しいが可能。2026年基準で世界中の独立フルタイムOSSメンテナは数百名程度と推定。
フルタイム寄付収入の現実的な公式
ざっくりした公式は以下のとおり。
フルタイム寄付収入 =
GitHub Sponsors (個人寄付合計)
+ Polar / デジタル商品 / ベネフィット
+ Tidelift (該当するなら)
+ 会社直接寄付 (Sentry Pledge等)
+ コンサル/講演 (別収入)
成功事例を見ると1つのチャネルから大きく入るのではなく、複数チャネルの合算だ。各チャネルが月$1kずつ5つあれば$5kになる。
時間配分の罠
フルタイムOSSメンテナの実際の時間配分はしばしばこうなる。
- コード作成/マージ: 30%
- Issueトリアージ: 25%
- 寄付者管理/コンテンツ/ニュースレター: 20%
- コンサル/講演/税金/会計: 15%
- 休息: 10%
「コードを書く時間」が全体の1/3以下なのが普通だ。これを理解せずにフルタイムに転向するとバーンアウトが早く来る。
安定性 — 多角化が保険
1人の寄付者が去っても、1つのチャネルが死んでも、1社が傾いても収入が維持されるよう分散する。
- チャネル3〜4個並行(GitHub Sponsors + Polar + Tidelift + Open Collective)。
- 寄付者数十〜数百名(特定の1人に依存しない)。
- 別収入源(講座、書籍、コンサル)。
第14章 · メンテナの最初の90日 — 実践セットアップ
最も頻繁に受ける質問は「いま人気が出たライブラリがあるのだが、寄付チャネルをどう始めればよいか」だ。90日プランで整理する。
Day 0〜7 — 基本セットアップ
- GitHub Sponsors登録。Stripe接続。
- レポに
FUNDING.yml追加、Sponsorボタン有効化。 - 寄付ティアを3つ程度から始める:
$5、$25、$100。 - ティアごとのベネフィットは最初は「感謝メッセージ + READMEに名前」だけで十分。
Day 8〜30 — メッセージ作成
- 寄付ページに「なぜ寄付するとよいのか」を明確に書く。
- 進行中の作業、ロードマップ、時間投入を正直に公開する。
- 最初の寄付者に心からの感謝メッセージを送る。これが次の寄付者を作る。
Day 31〜60 — チャネル拡張
- Polar.shを追加。GitHub Sponsors統合または独立運用を決める。
- 依存グラフが深いならThanks.devに登録する。
- インフラ/セキュリティライブラリならTideliftに申請する。
Day 61〜90 — 測定と調整
- どのチャネルがコンバージョンするかを測定する。
- 寄付者に「何が決め手だったか」短いアンケート。
- 最初の90日の学びで次の四半期計画を立てる。
チェックリスト (最初の90日):
[ ] GitHub Sponsors有効化 + Stripe接続
[ ] FUNDING.yml追加
[ ] 寄付ティア3つ設定
[ ] 寄付ページにメッセージ作成
[ ] 最初の寄付者に感謝メッセージ
[ ] Polar.sh検討 (B2B寄付者がいるなら)
[ ] Thanks.dev登録 (依存深いなら)
[ ] Tidelift申請 (インフラライブラリなら)
[ ] 測定データ整理 (最初の90日)
エピローグ — チェックリストとアンチパターン
オープンソース資金調達は結局2つの能力の結合だ。(1) 良いコードを作る能力。(2) そのコードで働く人の価値を正直に伝える能力。どちらか一方だけではフルタイム化は難しい。
メンテナ資金チェックリスト
- 自分のライブラリが実際に誰に、どう使われているか理解している。
- GitHub Sponsorsが有効化されている。
FUNDING.ymlがレポにある。- 寄付ページに「なぜ」が明確だ(単なる「寄付」ボタンではない)。
- B2B寄付の可能性があるなら、PolarまたはTideliftを検討した。
- 寄付者プールが1人/1社に依存していない。
- 寄付とコード決定権は分離されている。
- 寄付内訳は(少なくとも合計は)公開している。
- フルタイムが目標なら、チャネル3つ以上、寄付者50人以上が見えている。
- バーンアウト予防: コード外時間(トリアージ、寄付者管理)を30〜50%予算に組む。
アンチパターン集
- 「良いコードを作れば自然に寄付が入る」という幻想: 入らない。寄付者に見えなければ寄付もない。
- 1社に70%依存: その会社が方針を変えれば収入が一気に消える。
- ベネフィットをコード決定と結び付ける: 「スポンサー要求機能優先」は結局魂を売ることになる。
- 税金無視: メンテナ責任チャネル(GitHub Sponsors、Patreon、Ko-fi)を使いながら税金処理をしないと後で大きな請求が来る。
- 収益化コンテンツでメンテナ活動を代替する: 寄付者が増えるにつれコード作成時間が減れば本末転倒。
- 複数チャネル同時開始: 9つのチャネルを同時に始めるな。どれもまともに運営できない。GitHub Sponsorsから。
- バーンアウトを隠す: 寄付者はメンテナの正直な状態更新を最も信頼する。「バーンアウトで1ヶ月休みます」が「失踪後の謝罪」よりはるかに良い。
次回予告
次回は 「OSSライセンス 2026 — MITからAGPL、BSL、FSL、Elastic Licenseまでメンテナの選択」 を扱う。資金調達チャネルは決済メカニズムだが、ライセンスはメンテナが働く環境自体を決める。AWSのフリーライダー対応、Open Coreを可能にしたライセンス進化、そして「MITは本当に永遠の最適解か」という問いまで正直に覗く。
オープンソースは愛の労働だ。しかし愛だけではない。メンテナの時間が正当に補償される構造を共に作っていくこと — それが2026年OSSの最大の宿題だ。そしてその宿題を解く最初のステップは、レポにFUNDING.ymlを追加する5分の仕事だ。
参考 / References
- GitHub Sponsors
- GitHub Sponsors Docs
- Polar.sh
- Polar GitHub Integration
- Open Collective
- Open Source Collective (Host)
- OCF Sunset Announcement (2024)
- Tidelift
- Tidelift Lifter Program
- Patreon
- Ko-fi
- Buy Me a Coffee
- Liberapay
- Thanks.dev
- Algora
- Sentry Open Source Pledge
- Open Source Pledge — Member List
- OpenJS Foundation
- Cloud Native Computing Foundation
- Linux Foundation Europe
- Synopsys OSSRA Report
- Tidelift Maintainer Survey
- xz-utils backdoor analysis (Filippo Valsorda)
- Nadia Eghbal — Roads and Bridges
- Nadia Eghbal — Working in Public
- GitHub Octoverse 2024
- Stripe Atlas — OSS taxes guide
- Caleb Porzio — How I make OSS sustainable
- Sindre Sorhus — Sponsorship FAQ
- Evan You — Vue funding history
- Anthony Fu — OSS journey
- Open Source Pledge — Why $2,000