✍️ 필사 모드: Open Source Funding in 2026: How Maintainers Actually Get Paid — GitHub Sponsors, Polar, Open Collective, Tidelift, Ko-fi Deep Dive

"Open source is a labor of love. But love alone does not pay rent."

About 90% of the world's software infrastructure runs on top of open source. And about 90% of that open source is maintained by 1% or less of contributors. This asymmetry is the structural cause of Heartbleed (2014), log4shell (2021), the xz-utils backdoor (2024), and the steady annual drumbeat of "the sole maintainer of this critical library has burned out and disappeared."

This guide takes that structure head-on from the maintainer's seat and compares the nine funding channels available in 2026. Real numbers from people who say "I make $100/month but I have no idea if that lasts." An honest assessment of which channels actually convert. And the new wave of corporate commitments — like Sentry's Open Source Pledge — that finally treats OSS work as a real cost line.

Prologue — Maintainer Burnout and the Free-Rider Problem

The 2024 xz-utils backdoor reduces to one sentence. A burned-out maintainer handed commit privileges to a "helpful" newcomer who had spent two years patiently building trust, and that newcomer planted an SSH backdoor that would have hit nearly every Linux distribution. The real cause was not the backdoor code. It was the fact that billions of dollars of infrastructure rested on one person's unpaid labor.

The structural problem

• About 96% of Fortune 500 companies depend on OSS directly or indirectly (Synopsys OSSRA report).
• Yet 75%+ of the maintainers who produce those dependencies receive zero funding (Tidelift maintainer survey).
• A maintainer of a popular OSS package spends 5–10 hours per week of unpaid labor on average.
• Even "successful" maintainer sponsorship income often clocks in below half of a self-employed minimum wage.

The free-rider problem

OSS is a classic tragedy of the commons. AWS runs trillion-dollar revenue on top of PostgreSQL but does not directly deposit money in PostgreSQL core developers' accounts. The distance between the value a consumer extracts from a dependency and the value they return to the maintainer is almost always close to infinite.

Every channel in this article is an attempt to shrink that distance. Some use individual sponsorship, some use enterprise licenses, some use automated dependency tracking, some use bounties. Different mechanisms produce wildly different conversion and durability outcomes.

The promise of this guide

This is not a marketing piece for funding platforms. We use publicly reported numbers from real maintainers, the actual constraints of each channel, and we honestly answer the question: "If I start collecting sponsorship today, can I actually pay rent?"

Chapter 1 · The Channels at a Glance — Nine Funding Options

Before going deep, sketch the whole map. The channels fall into four buckets.

Each channel differs along (1) revenue model (who pays and why), (2) fee structure, (3) tax and payout responsibility, (4) audience demographics and conversion. The rest of this guide drills each of those axes for each channel.

Chapter 2 · GitHub Sponsors — The Default with a Ceiling

GitHub Sponsors started its beta in 2019 and has since become the de facto default channel. The reason is simple — the payment button lives inside the maintainer's workplace (GitHub).

How it works

• The maintainer adds a FUNDING.yml to the repo and a "Sponsor" button appears next to PRs.
• Sponsors can support recurring (monthly) or one-time.
• Maintainers can define tiers with different benefits per tier.
• GitHub has held a 0% platform fee since 2024 (payment processing fees still apply).
• Payout runs through Stripe Connect. Korean maintainers can join, but tax handling is the maintainer's responsibility.

Real numbers

Stitching together public reports:

Strengths

• Almost no friction: both sponsor and maintainer need only a GitHub account.
• Trust: payment infrastructure is GitHub's problem.
• Exposure: the button is right where people read your code.

Limitations

• Weak B2B conversion: corporate accounting teams hate paying through "personal sponsorship" flows. Invoicing, VAT, and accounting categories are awkward.
• The ceiling is low: a typical sponsor pays $5–$25/month. Without thousands of sponsors, this does not move the needle.
• Weak benefit tooling: tiers exist, but automated benefit delivery (downloads, gated sites) is anemic.

Who should use it

If you pick only one channel, pick GitHub Sponsors. Just know the ceiling. Most maintainers cannot turn GitHub Sponsors alone into a full-time income.

Chapter 3 · Polar.sh — The Rise of Developer-First MoR

Polar.sh, which emerged in 2023 and grew rapidly through 2024–2026, has become the strongest developer-first alternative. Its two killer differentiators:

1. Merchant of Record (MoR): Polar becomes the legal seller. VAT/sales tax filing, invoice generation, refunds — all on Polar. The maintainer just collects the deposit.
2. GitHub Sponsors integration: in late 2024 Polar began offering to handle GitHub Sponsors payments behind the scenes — you keep the GitHub-side exposure and let Polar handle the back office.

How it works

• Compose subscription tiers, one-time payments, digital products (files, license keys), benefits (priority on GitHub issues, etc.) freely.
• Fees are similar to Stripe, but MoR costs are bundled in (roughly 4% plus payment processing).
• Embed sponsorship widgets directly in your README.
• Automate benefit delivery (e.g., if a sponsor opens a PR, it gets priority review).

Strengths

• B2B friendly: invoices are issued automatically. Accounting teams are happy.
• Flexible pricing: tiers, caps, time-limited campaigns, SaaS-class pricing tools.
• Diversified monetization: not just sponsorship but digital product sales.
• Developer experience: APIs and webhooks are well designed. Easy to integrate into your own site.

Limitations

• MoR fees look expensive: compared to GitHub Sponsors' "0% fee" marketing they look pricier on paper. In reality, since Polar handles all tax and VAT, the effective cost story is different.
• Awareness gap: less recognized to casual individual sponsors compared to GitHub Sponsors or Ko-fi.
• Benefit automation depends on a SaaS mindset: it does not magically convert; you have to design and run the benefits.

Real-world usage

Individual maintainers backed by Astro, Nuxt, Vercel, as well as core people on Yjs and Hono use Polar as their primary channel. The "GitHub Sponsors for visibility + Polar for the actual infrastructure" combo is becoming the de facto pattern.

Who should use it

Maintainers serious about corporate sponsors, maintainers who want to sell digital products or paid benefits alongside sponsorship, and maintainers who want to outsource tax handling.

Chapter 4 · Open Collective — Transparent Ledgers and Group Funds

Open Collective shines for multi-maintainer or team-led OSS projects, less so for individuals. The core idea is the fully public ledger: every income and expense is visible on a page anyone can read.

How it works

• The project creates a "Collective." This is not a legal entity; it is a virtual fund pool under a hosting umbrella.
• Sponsors contribute recurring or one-time.
• When someone files an expense ("AWS bill $50," "designer contract $200"), it is paid from that pool.
• All transactions are recorded automatically on a public page.
• The fiscal host (e.g., Open Source Collective 501(c)(6)) carries legal and tax responsibility.

Strengths

• Transparency: sponsors see exactly where their money went. Strong for community projects.
• Group collaboration: easy to share one pool across multiple maintainers.
• Fiscal hosting: receive funds and pay expenses without forming a legal entity yourself.

The big variable — OCF wound down in 2024

In 2024, Open Collective Foundation (OCF), the 501(c)(3) fiscal host arm aimed at charitable groups, announced it would wind down its operations. The roughly 600 collectives under that host had to migrate or wind down their own funds.

Note: this was the closure of one host under the Open Collective umbrella, not the Open Collective platform itself. But it was the first time community OSS projects took "fiscal-host concentration risk" seriously.

As of 2026, developer OSS projects mostly sit under Open Source Collective (a 501(c)(6) trade association), which continues to operate steadily. Still, the structural risk of host concentration remains.

Limitations

• Overkill for solo maintainers: a single-person library does not need a public ledger or a group fund.
• Fees: host fees of 5–10% plus payment processing are typical. More expensive than GitHub Sponsors.
• Host dependency: the host's policy and survival affect the project's funds.

Who should use it

Multi-maintainer OSS projects — webpack, Babel, communities running meetups or conferences — fit it well. Solo-maintainer one-package libraries are better off with GitHub Sponsors due to lower friction.

Chapter 5 · Tidelift — The Enterprise Subscription Model

Tidelift runs on a fundamentally different mechanism from every other channel. It is not "sponsorship." It is an enterprise subscription.

How it works

• A company pays Tidelift an annual subscription fee. They typically want security and license SLAs over the OSS packages they actually use.
• Tidelift distributes that subscription fee to the lifter (maintainer) behind each used package.
• The maintainer signs a "lifter contract," accepting obligations like security-patch SLAs, accurate license information, and dependency hygiene, and in return receives recurring income.

What is different

• A business transaction, not a goodwill gesture: the company buys an SLA, the maintainer provides one.
• Enterprise accounting friendly: "OSS security subscription" maps cleanly to a corporate budget line.
• Stable income: once you are a lifter, payments come in on a quarterly/annual cadence.

Real income

Public reporting suggests well-placed package maintainers can produce $500–$3k/month from Tidelift alone. Maintainers of multiple popular packages can exceed $10k/month. There is an application and acceptance step, and not every package makes the cut.

Strengths

• Recurring stable income: quarterly or annual contracts are the default.
• B2B clarity: easy for corporate finance teams to process.
• Aligned with supply-chain security: SBOM and dependency-security trends increase the value of the SLA story.

Limitations

• Acceptance gate: Tidelift decides whether to include a package in its catalog. Small or unknown packages may not be accepted.
• SLA obligations: you must ship security patches within a defined window. Heavy if you have a day job.
• No effect on individual sponsorship: Tidelift is not a channel where individual sponsors discover you.

Who should use it

Maintainers of libraries deeply embedded in enterprise systems — security libraries, core infrastructure libraries, popular utilities. Weaker fit for purely consumer-facing libraries.

Chapter 6 · Patreon / Ko-fi / Buy Me a Coffee — The Consumer Trio

These three often get lumped together, but they actually have distinct personalities.

Patreon

• Originally grew with YouTubers, podcasters, and artists.
• Strong on tiered membership subscriptions.
• Fees of 8–12% plus payment processing.
• OSS maintainers who use it tend to be content creators (blog, video, courses) on top of code.

Ko-fi

• "Buy me a coffee" metaphor — one-time tips feel natural.
• Recurring memberships also supported.
• Base fee 0% with a paid Ko-fi Gold plan for premium features.
• Digital product sales and commissions are supported.
• Popular among indie devs, indie game devs, and designers.

Buy Me a Coffee

• Similar tone to Ko-fi, one-time-tip-centric.
• 5% fee, but with crisp UX and a strong mobile experience.
• Memberships and digital products are supported as well.

Comparison matrix

Reality for OSS maintainers

All three convert weakly for maintainers who only ship code. Sponsors sponsor a face and a story, not a package changelog. Maintainers with strong content (blog, video, Twitter/X) do well; maintainers visible only through GitHub activity tend to do better on GitHub Sponsors.

Who should use it

Maintainers with strong side content (blog, video, Twitter/X) who care about a personal brand. Otherwise, GitHub Sponsors has less friction.

Chapter 7 · Liberapay — Pure Nonprofit Donations

Liberapay runs the most distinct operational philosophy of any channel.

Characteristics

• Nonprofit (Belgian ASBL) operates it.
• 0% platform fee (payment processing fees only).
• Recurring donations only — no one-time payments.
• Anonymous donations are supported.
• It is itself funded via Liberapay donations ("dogfooding its own food").

Strengths

• The channel closest to the original "open source spirit" — nonprofit, transparent, anonymity-preserving.
• Effectively the lowest fees of any channel.
• Minimum sponsor PII exposure.

Limitations

• Smaller pool and visibility: user base is far smaller than GitHub Sponsors.
• No one-time donations: "this library saved me a day's work, let me drop a tip" is not supported.
• Payment partner dependency: there have been multiple-month windows where withdrawals paused because of payment-processor issues.

Who should use it

Maintainers who ideologically want a nonprofit, transparent channel, and maintainers of privacy or security tools where an anonymous donor pool actually exists.

Chapter 8 · Thanks.dev — Automated Dependency Distribution

Thanks.dev tries to automate the "selection" side of sponsorship. Instead of clicking a sponsor button per maintainer, it scans your repo's dependencies and distributes sponsorship automatically.

How it works

• A company subscribes to Thanks.dev with a monthly or annual budget (say, $1,000/month).
• Thanks.dev scans package.json, Cargo.toml, go.mod, and friends across the company's repos.
• It weights dependencies (direct vs transitive, number of dependents) and splits the budget across maintainers automatically.
• Maintainers connect GitHub and Stripe and just receive deposits.

Strengths

• For the company: no need to debate which OSS to sponsor. The packages we actually use get paid.
• For the maintainer: small packages deep in the dependency graph get rewarded automatically.
• Aligned with supply-chain security: who we actually depend on becomes visible automatically.

Limitations

• Per-maintainer amount is small: distribution is so broad that many maintainers see only $1–$10/month.
• Hard to land on the company side: convincing leadership to spend $1,000/month on OSS is the real barrier.
• No reward for activity: even if a maintainer stops working, the distribution can continue.

Sentry joining via the Open Source Pledge

Sentry's Open Source Pledge (launched 2024) commits each company member to spend $2,000/year per full-time engineer on OSS maintainer sponsorship. As more companies join, automated channels like Thanks.dev see proportionally larger flows.

Who should use it

Company side: organizations with deep OSS dependency graphs that want hands-off reward distribution. Maintainer side: small "leftpad-like" utilities deep in the graph that suddenly get visible income they would never have seen otherwise.

Chapter 9 · Algora — Bounties Plus Sponsorships

Algora does two things at once. (1) A per-issue bounty marketplace. (2) Recurring corporate sponsorships of maintainers/projects.

How it works

• A company or individual attaches a bounty to a GitHub issue ("solve this and earn $500").
• Anyone can submit a PR. When it merges, the contributor gets paid.
• Separately, companies can recurring-sponsor maintainers or projects.
• Maintainers can use corporate sponsor money to fund bounties on their own repo's issues.

Strengths

• Outcome-based: not a vague gesture but payment for a specific piece of work.
• Pull new contributors: bountied issues attract new contributors strongly.
• Direct corporate influence: companies put money where their actual needs are.

Limitations

• Risk for maintainer time: a flood of bounty-chasing contributions raises the review burden.
• AI slop risk amplified: high-bounty issues attract masses of AI-generated, low-quality PRs (the most acute problem of 2025–2026).
• Not stable income: bounty payments are sporadic, not recurring.

Who should use it

Companies: when you want to fund a specific feature or fix. Maintainers: as a side income stream or as a contributor-acquisition tool, not as a foundation for stable monthly income.

Chapter 10 · Channel vs Income Matrix — Honest Assessment

Compare the nine channels on the axes a maintainer actually cares about.

Honest recommendations by maintainer persona

Solo small-utility library maintainer (utility-belt style)

• Primary: GitHub Sponsors (zero friction).
• Secondary: Thanks.dev (if you sit deep in the dependency graph).
• Tertiary: Algora bounties (if companies show willingness).

Mid-size framework or library core contributor

• Primary: GitHub Sponsors + Polar integration (visibility plus B2B).
• Secondary: Tidelift (if you can carry the security-SLA obligation).
• Tertiary: Open Collective (if you run it as a team).

Maintainer of infrastructure libraries deeply used in enterprise

• Primary: Tidelift (best alignment).
• Secondary: GitHub Sponsors (individual sponsor topping up).
• Tertiary: direct consulting/support contracts (out of scope for this guide).

Content-strong maintainer (blogger, video creator)

• Primary: GitHub Sponsors + Patreon (content memberships).
• Secondary: Ko-fi or Buy Me a Coffee (one-time tips).
• Tertiary: Polar (digital product sales).

Chapter 11 · The Corporate Side — Open Source Pledge and Funding Models

Channels are the maintainer-side tools. The corporate side is moving too. The big 2024–2026 trend is companies making quantitative commitments to spend on OSS.

Sentry's Open Source Pledge

The Sentry-led Open Source Pledge, launched in 2024, proposes a simple formula:

Spend $2,000/year per full-time engineer on OSS maintainer sponsorship.

A 100-person company is $200,000/year. A 1,000-person company is $2M/year. Aggregated, this puts real money into the maintainer pool.

As of 2026, Sentry, Astral (uv/ruff), parts of Vercel, parts of Stripe, and dozens of SaaS companies have joined. The movement's impact depends on whether membership crosses the 1,000-company mark. Today it sits between 100 and several hundred.

OpenJS, CNCF, Linux Foundation Europe

Nonprofit funding is also evolving.

• OpenJS Foundation: sponsors JS ecosystem projects including Node.js, Express, ESLint. Funded by corporate member fees.
• CNCF: hosts cloud-native projects like Kubernetes, Prometheus, etcd. Grows projects through incubation and graduation tiers.
• Linux Foundation Europe: launched in 2022. Offers OSS governance hosting tailored to European regulatory environments.

These foundations focus on project-level rather than individual-maintainer funding — CI infrastructure, security audits, conference funding all come from there.

VC-backed OSS companies — a different game

Supabase, Tailscale, Vercel, Linear, Posthog and similar VC-backed OSS companies have structurally different funding profiles.

• Seed and Series funding covers full-time maintainer salaries from day one.
• Core maintainers are company employees; external contributors are managed by the company.
• Revenue comes from cloud hosting, SaaS, or enterprise licensing.
• Sponsorship is rare or limited to supporting external contributors via GitHub Sponsors.

This model is an OSS company, not a maintainer-funding channel. Sponsorship income for a Supabase maintainer on GitHub Sponsors is small and separate from their salary. Confusing the two distorts the picture.

Chapter 12 · "Should I Take Corporate Money?" — The Honest Debate

The hottest political debate in OSS funding is whether corporate money is acceptable. Three positions, fairly presented.

Position 1 — "Take it unconditionally"

• Companies extract value from maintainer labor. Receiving compensation is just.
• If maintainers starve, OSS itself is at risk (see xz-utils).
• As long as the maintainer keeps decision power, the source of the money does not matter.

Position 2 — "Conditionally"

• Accept as long as you do not cede license or roadmap decisions to a sponsor.
• One company should not exceed a certain share of total income. Diversification matters.
• Benefits like "sponsor priority" must be designed carefully.

Position 3 — "Taking corporate money compromises you"

• Corporate sponsors influence, even if implicitly.
• Nonprofit channels (Liberapay) are cleaner.
• The "OSS as a hobby" purity has to be preserved.

A pragmatic middle

Most maintainers converge on Position 2 in practice. Practical guidelines:

• No single sponsor should exceed 30% of total income.
• State explicitly that license and governance decisions are independent of sponsorship.
• Sponsor benefits should focus on "time-efficient" perks (priority issue handling), not "feature prioritization."
• Disclose sponsorship publicly. Transparency creates trust.

Chapter 13 · From the Maintainer's Seat — Is Full-Time OSS Possible?

Now the hardest question. "Can I become a full-time OSS maintainer?"

Two paths to full-time OSS

1. Join a VC-backed OSS company: become an employee. Most stable, but you are no longer "independent."
2. Build a full-time income from diverse sponsorship channels: hard but possible. As of 2026 the count of independent full-time OSS maintainers globally is estimated in the hundreds.

The practical full-time formula

A rough composition looks like:

Full-time sponsorship income =
  GitHub Sponsors (sum of individual sponsorships)
  + Polar / digital products / benefits
  + Tidelift (if applicable)
  + Direct corporate sponsorship (Sentry Pledge, etc.)
  + Consulting / speaking (separate income line)

The pattern in success stories is not one channel paying everything but multiple channels summing up. Five channels at $1k/month each gets you to $5k/month.

The time-allocation trap

A full-time OSS maintainer's actual time often looks like this:

• Writing and merging code: 30%
• Issue triage: 25%
• Sponsor relationships / content / newsletter: 20%
• Consulting / speaking / taxes / accounting: 15%
• Rest: 10%

"Coding time" being one-third or less is normal. Switching to full-time without internalizing this leads to fast burnout.

Stability — diversification is insurance

Build so that no single sponsor leaving, no single channel dying, no single company sinking takes you down.

• 3–4 channels in parallel (GitHub Sponsors + Polar + Tidelift + Open Collective).
• Dozens to hundreds of sponsors (no dependency on any one).
• Separate income streams (courses, books, consulting).

Chapter 14 · A Maintainer's First 90 Days — Practical Setup

The most frequently asked question is "I just got a library that's blowing up, how do I start sponsorship?" Here is a 90-day plan.

Day 0–7 — basic setup

1. Sign up for GitHub Sponsors. Connect Stripe.
2. Add FUNDING.yml to the repo. The Sponsor button activates.
3. Start with three tiers: $5, $25, $100.
4. For benefits, start with "thank-you note + name in README." That is enough.

Day 8–30 — message it

1. Write a clear "why sponsor" on the sponsor page.
2. Disclose ongoing work, roadmap, and time invested honestly.
3. Send the first sponsor a heartfelt thank-you. This drives the next sponsor.

Day 31–60 — expand channels

1. Add Polar.sh. Decide whether to integrate with GitHub Sponsors or run independently.
2. If you sit deep in dependency graphs, register on Thanks.dev.
3. If you maintain infrastructure or security libraries, apply to Tidelift.

Day 61–90 — measure and adjust

1. Measure which channel actually converts.
2. Ask sponsors briefly what made them sponsor.
3. Plan the next quarter based on what you learned.

Checklist (first 90 days):
[ ] GitHub Sponsors active + Stripe connected
[ ] FUNDING.yml added
[ ] Three tiers configured
[ ] Sponsor-page message written
[ ] Thank-you sent to first sponsor
[ ] Polar.sh reviewed (if B2B sponsors are likely)
[ ] Thanks.dev registered (if deep in dependency graph)
[ ] Tidelift applied (if you maintain an infra library)
[ ] First-90-days data collected

Epilogue — Checklists and Anti-Patterns

OSS funding is ultimately the combination of two abilities. (1) The ability to ship good code. (2) The ability to honestly communicate the value of the person doing the work. With only one of those, full-time is hard.

Maintainer funding checklist

1. I know who actually uses my library and how.
2. GitHub Sponsors is active.
3. FUNDING.yml is in the repo.
4. The sponsor page makes the "why" clear (not just a donate button).
5. If B2B sponsorship is possible, I have considered Polar or Tidelift.
6. The sponsor pool does not depend on any single sponsor or company.
7. Sponsorship and code decisions are separated.
8. Sponsorship (at least the totals) is disclosed publicly.
9. If full-time is the goal, three-plus channels and 50-plus sponsors are visible.
10. Burnout prevention: 30–50% of time budgeted for non-coding work (triage, sponsor management).

Anti-patterns

• The illusion that "good code attracts sponsorship by itself": it does not. Invisible to sponsors means no sponsorship.
• 70% dependency on one company: one policy change and your income vanishes.
• Tying benefits to code decisions: "sponsor-requested features get priority" eventually compromises you.
• Ignoring taxes: using maintainer-responsibility channels (GitHub Sponsors, Patreon, Ko-fi) without tax handling produces a large bill later.
• Replacing maintainer work with monetized content: if coding time drops as sponsorship grows, you have flipped the trade.
• Starting all channels at once: do not launch all nine at once. You will run none well. Start with GitHub Sponsors.
• Hiding burnout: sponsors trust an honest status update most. "Burned out, taking a month off" is far better than "vanished and apologizing later."

What is next

The next post is "OSS Licenses 2026 — From MIT to AGPL, BSL, FSL, and Elastic License: a Maintainer's Choice." Funding channels are payment mechanisms, but licenses determine the environment the maintainer works in. AWS's free-rider response, the license evolution that enabled Open Core, and an honest look at "is MIT really forever the best?"

Open source is a labor of love. But love alone is not enough. Building a structure that compensates maintainer time fairly is the biggest assignment OSS has in 2026. The first step toward that assignment is the five minutes it takes to add FUNDING.yml to your repo.

참고 / 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