✍️ 필사 모드: オープンソース資金調達 2026: GitHub Sponsors / Polar / Open Collective / Tidelift / Ko-fi — メンテナはどう報酬を受け取るか (Deep Dive)

「オープンソースは愛の労働である。しかし愛だけでは家賃は払えない。」

世界のソフトウェアインフラの約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つに分類される。

各チャネルは(1)収益モデル(誰が、なぜ支払うか)(2)手数料構造(3)税金/支払いの責任範囲(4)人口統計とコンバージョンで異なる。この記事の残りはこの4軸をチャネル別に掘り下げる。

第2章 · GitHub Sponsors — デフォルトだが天井が低い

GitHub Sponsorsは2019年にベータで始まり、いまや事実上の「デフォルト」チャネルになった。理由は単純だ — メンテナの仕事場(GitHub)の中に決済ボタンがある。

どう動くか

• メンテナがレポにFUNDING.ymlを追加すると、「Sponsor」ボタンがPRの隣に自動で出る。
• 寄付者は定期決済(月次)または単発で寄付できる。
• メンテナはティアを作れ、ティアごとに異なるベネフィットを提供できる。
• GitHubは2024年から**プラットフォーム手数料0%**を維持(決済処理手数料は別)。
• 支払いはStripe Connectベース。日本のメンテナも参加可能だが税金処理は本人責任。

実際の数字

公開データを総合すると:

強み

• ほぼ摩擦がない: 寄付者もメンテナもGitHubアカウントだけで完結。
• 信頼: 決済インフラはGitHubが責任を持つ。
• 露出: GitHubプロフィールとレポに自然に露出する。

限界

• B2Bコンバージョンが弱い: 企業の経理は「個人的な寄付」フローでの支払いを嫌う。請求書、消費税、会計科目として処理しづらい。
• 天井が低い: 寄付者一人あたり通常$5〜$25/月。数千人単位で集めない限り大きな金額にならない。
• ベネフィット運用が弱い: ティアを作れても、ティアごとの自動化ベネフィット(ダウンロード、サイトアクセス等)の提供は貧弱。

誰に向くか

GitHub Sponsorsは「寄付チャネルを1つだけ持つならこれ」の正解だ。ただし天井を理解して始めること。多くのメンテナはGitHub Sponsorsだけではフルタイム化できない。

第3章 · Polar.sh — 開発者ファーストMoRの台頭

Polar.shは2023年に登場、2024〜2026年にかけて開発者向け決済プラットフォームの強力な代替として急成長した。中核的な差別化点は2つ。

1. Merchant of Record (MoR): Polarが決済の法的販売者になる。つまり消費税/販売税の申告、請求書発行、返金処理をPolarが行う。メンテナは入金を受け取るだけ。
2. 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と強いモバイル体験。
• メンバーシップ、デジタル商品もサポート。

比較マトリックス

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つのチャネルを、メンテナが実際に気にする軸で比較しよう。

正直な推薦 — メンテナのペルソナ別

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つの道

1. VC系OSS企業に加入する: 従業員になる道。最も安定だが、もはや「独立メンテナ」ではない。
2. 多様なチャネルの寄付でフルタイム収入を作る: 難しいが可能。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 — 基本セットアップ

1. GitHub Sponsors登録。Stripe接続。
2. レポにFUNDING.yml追加、Sponsorボタン有効化。
3. 寄付ティアを3つ程度から始める: $5、$25、$100。
4. ティアごとのベネフィットは最初は「感謝メッセージ + READMEに名前」だけで十分。

Day 8〜30 — メッセージ作成

1. 寄付ページに「なぜ寄付するとよいのか」を明確に書く。
2. 進行中の作業、ロードマップ、時間投入を正直に公開する。
3. 最初の寄付者に心からの感謝メッセージを送る。これが次の寄付者を作る。

Day 31〜60 — チャネル拡張

1. Polar.shを追加。GitHub Sponsors統合または独立運用を決める。
2. 依存グラフが深いならThanks.devに登録する。
3. インフラ/セキュリティライブラリならTideliftに申請する。

Day 61〜90 — 測定と調整

1. どのチャネルがコンバージョンするかを測定する。
2. 寄付者に「何が決め手だったか」短いアンケート。
3. 最初の90日の学びで次の四半期計画を立てる。

チェックリスト (最初の90日):
[ ] GitHub Sponsors有効化 + Stripe接続
[ ] FUNDING.yml追加
[ ] 寄付ティア3つ設定
[ ] 寄付ページにメッセージ作成
[ ] 最初の寄付者に感謝メッセージ
[ ] Polar.sh検討 (B2B寄付者がいるなら)
[ ] Thanks.dev登録 (依存深いなら)
[ ] Tidelift申請 (インフラライブラリなら)
[ ] 測定データ整理 (最初の90日)

エピローグ — チェックリストとアンチパターン

オープンソース資金調達は結局2つの能力の結合だ。(1) 良いコードを作る能力。(2) そのコードで働く人の価値を正直に伝える能力。どちらか一方だけではフルタイム化は難しい。

メンテナ資金チェックリスト

1. 自分のライブラリが実際に誰に、どう使われているか理解している。
2. GitHub Sponsorsが有効化されている。
3. FUNDING.ymlがレポにある。
4. 寄付ページに「なぜ」が明確だ(単なる「寄付」ボタンではない)。
5. B2B寄付の可能性があるなら、PolarまたはTideliftを検討した。
6. 寄付者プールが1人/1社に依存していない。
7. 寄付とコード決定権は分離されている。
8. 寄付内訳は(少なくとも合計は)公開している。
9. フルタイムが目標なら、チャネル3つ以上、寄付者50人以上が見えている。
10. バーンアウト予防: コード外時間(トリアージ、寄付者管理)を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