# The Dependency Funding Ledger: Lockfile to Weighted, Paid, Reported Grants

*Go from a lockfile or SBOM to a ranked, paid funding ledger and a pledge-ready report in about two working days, with every dollar traceable to a written rule.*

- Canonical URL: https://www.refolk.ai/guides/open-source-dependency-funding-ledger
- Pillar: Engineering and open source
- Format: Playbook
- Published: 2026-10-21
- Last reviewed: 2026-10-21
- Reading time: 22 min
- Keywords: how to choose which open source projects to sponsor, fund open source dependencies company budget, open source pledge how to allocate, which dependencies should my company sponsor, SBOM to open source funding list

## Key takeaways

- The Open Source Pledge baseline is $2,000 per full-time-equivalent developer per year in cash, and payments for services, Linux Foundation membership, and open-source developers on staff do not count toward it.
- In package registries with over a million packages, fewer than a thousand packages account for 80% of downloads or dependent repositories, so any usage-weighted split concentrates money unless you set a per-recipient cap.
- GitButler sent 89.6% of its pledge to two projects it picked by judgement, Tauri and Svelte, and only $1,050 to its dependency tree through thanks.dev, which is why the graph should fund the long tail and judgement the head.
- In Refolk's index, only 4 of 20 US profiles with maintainer titles and an open-source headline use the bare title Maintainer, so a vendor-backing check should search by repository and confirm the employer from commit email domains.
- GitHub Sponsors costs organizations 6% by card or 3% by invoice with a $5,000 minimum per invoice, while Open Source Collective and Ecosystem Funds each take 10%, so the choice of channel changes how much reaches the project.
- uv.lock marks scope only at depth 1, which left 103 dev-only components in pydantic with no scope at all, so a scope pass must give each package the strongest scope found on any inbound path.

This is the procedure for splitting a fixed yearly open-source budget, often the Open Source Pledge's $2,000 per developer, across the projects your software actually runs on. It is for the engineering manager, technical founder, developer-relations lead, or technical sourcer who owns that number. You start from a lockfile or SBOM export. You finish with a ranked funding ledger, payments sent through channels that work, and an annual report you can defend line by line.

## What counts toward an Open Source Pledge budget?

The Open Source Pledge asks a company to pay at least $2,000 per full-time-equivalent developer each year, in cash, directly to open-source maintainers or foundations. Payments already made earlier that year count toward it. The rest of this guide is about dividing that cash. This section pins down what the cash is.

What counts:

- Cash payments to any open-source maintainers you choose.
- Cash payments to open-source foundations. The Pledge says payments to all open-source foundations are in scope.
- Payments already made earlier in the same year.

What does not count, according to Pledge lead Chad Whitacre as reported by LWN:

- Payments for services rendered, such as paid feature work or support contracts.
- Linux Foundation membership.
- Having open-source developers on staff.

> **Rule:** Only donations go in the total
>
> Only cash donations count toward the pledge. Track directed work, memberships, and support contracts in the ledger so the books reconcile, but mark them as not counted and keep them out of the reported total.

The budget line is FTE developers × $2,000. Treat that as the minimum. Posit's most recent Pledge filing reports 160 developers and $750,000, which is $4,688 per developer. Its earlier filing reports 134 developers and $493,000. Whatever rate you commit to, write down the developer count and the total before you open the dependency graph, because the report needs both.

The report has to give the year, your developer count, the total paid, and a breakdown of payments. You also create a JSON file describing your commitment and submit it as a pull request to the Pledge's GitHub repository. I could not find a fixed deadline published anywhere. Posit's two filings are dated late November and late December, so plan to file at year end, but don't treat that as a rule.

## Why not hand the whole budget to an automated split?

Usage in package registries follows a power law, and build-file graphs never see tools that don't appear in a manifest. So a split driven by the graph concentrates money in projects that often already have backing, and it skips some of the tools your team relies on most. Automated splits work well for the long tail. They are the wrong tool for the top of the list.

Two mechanisms drive this:

- **Concentration.** Andrew Nesbitt of ecosyste.ms observes that fewer than a thousand packages account for 80% of all downloads or dependent repositories, even in registries with over a million packages. Any split weighted by usage inherits that curve.
- **Opaque weights.** Ecosystem Funds says only that it allocates funding to projects according to their usage among the other dependencies in their ecosystem. It does not publish how it weights direct against transitive or runtime against dev dependencies, and neither does thanks.dev. The direct-versus-transitive question is still argued in public, for example in issue #149 on the feross/thanks repository.

The published ledgers show what practitioners actually do:

| Company | Devs | Total | $/dev | Share to top 2 recipients |
|---|---|---|---|---|
| GitButler | 5 | $10,050 | $2,010 | 89.6% (Tauri, Svelte) |
| Platformatic | 6 | $13,000 | $2,167 | 76.9% (OpenJS, LF) |
| Posit (latest filing) | 160 | $750,000 | $4,688 | not published |

GitButler paid $6,000 to Tauri through GitHub Sponsors, $3,000 to Svelte at $250 a month through Open Collective, and $1,050 to its dependency tree through thanks.dev. Platformatic paid $5,000 to OpenJS and $5,000 to the Linux Foundation.

**89.6% - Share of GitButler's pledge sent to two projects picked by judgement**

Tauri and Svelte would rank low on a lockfile graph, and only $1,050 went to the dependency tree through thanks.dev.

The sources disagree on order. Algorithmic platforms split first and sort out payment channels afterwards. GitButler made its discretionary picks first and sent the remainder to an algorithm. I follow GitButler's order. Rank and fund the head by hand, because that is where exposure and manifest blindness matter most. Then send the tail to a split or to small grants at the floor amount.

## The allocation procedure, step by step

The procedure has eight steps, from the budget to a published report. My estimate is about 18 hours of work, or roughly two working days, plus however long maintainers take to reply. None of the sources give time estimates. The hours below are my own planning figures, not measurements, so check them against your first run.

#### Lockfile to published ledger

1. **Fix the budget and developer count** - Count FTE developers and multiply by $2,000 or your higher rate. Done when both numbers sit at the top of the ledger. About half an hour.
2. **Export the graph and tag every scope** - Pull lockfiles or an SBOM and tag each entry direct or transitive, runtime or dev, taking the strongest scope on any inbound path. Done when every row has a scope and uv.lock has been checked separately. About 2-3 hours.
3. **Collapse packages to projects and add unlisted tools** - Map each package to its source repository URL, one row per fundable repo or org, then add editors, frameworks, and CI tools that never appear in a manifest. About 3 hours.
4. **Weight each project by criticality and exposure** - Run criticality_score per repo, cross-check dependents against ecosyste.ms counts, assign an exposure tier, and rank. About 4 hours.
5. **Check backing and existing funding** - Confirm maintainer employers from commit email domains, read Open Collective balances, top contributors, and sponsor counts, and mark each row vendor-backed, funded, or underfunded. About 4 hours.
6. **Confirm a recipient and a working channel** - Check FUNDING.yml, GitHub Sponsors, and Open Collective, and message maintainers where none exists. About 3 hours plus waiting time.
7. **Set amounts with floor, cap, reserve, and fees** - Apply the written floor, cap, and reserve, then gross up each grant for its channel fee. About 1 hour.
8. **Pay, publish, and set a review date** - Pay, publish the report post, open the JSON pull request to the Pledge repository, and put the review date on the calendar.

Keep the ledger in one sheet from step 2 onwards. Every later step fills in more columns on the same rows. That is what makes the final report defensible, because each amount traces back to a scope, a score, a backing verdict, and a channel.

**Funding ledger columns**

```
project,source_repo,ecosystem,scope_tier,criticality_score,dependents_crosscheck,override_reason,backing_status,backing_evidence,recipient,channel,channel_fee_pct,net_target_usd,gross_paid_usd,counts_toward_pledge,review_date
"name","repo or org URL","npm|pypi|cargo|...","A|B|C|D","tool output","ecosyste.ms count","blank or one sentence","vendor-backed|funded|underfunded","employer domain, OC balance, sponsor count","person or fiscal host","GitHub Sponsors|Open Collective|foundation|reserve","6|3|10|...","what the project should receive","net / (1 - fee)","yes|no (reason)","date"
```

*Paste as the header row of a spreadsheet; the second line lists allowed values and stays as a key.*

## How do you weight projects by real exposure?

Weight a project by two things: how directly your shipped software depends on it, and how critical it is to the wider ecosystem. Measure both at the level of the source repository, not the package. Exposure tells you how much your risk depends on the project. Criticality tells you how much everyone else's does.

### Collapse packages into fundable projects

You can't pay a package. You pay a project, a maintainer, or a fiscal host, which is an organization that holds money and handles invoicing on behalf of a project that has no legal entity of its own. So map every package to its source repository URL and merge rows that share one. A monorepo that publishes twenty packages becomes one row. I could not find a published procedure for collapsing monorepos. My rule is one row per repository URL, and one row per GitHub organization where the org has a single funding page covering several repositories.

Then add what the manifest cannot see: your editor, your application framework, your CI runner, and the desktop or UI toolkit you build on. GitButler's two largest grants went to exactly this kind of tool.

### Assign an exposure tier

The tiers below are my default. They are not a published standard, and no platform publishes its own weights to compare them with.

- **Tier A:** a direct runtime dependency, or a tool you added by hand that the team uses every day.
- **Tier B:** a transitive runtime dependency.
- **Tier C:** a direct dev or build dependency.
- **Tier D:** reachable only through dev dependencies.

If a package is reachable through both a runtime path and a dev path, it stays runtime. Your scope pass has to take the strongest scope across all inbound paths.

> **Watch out:** uv.lock hides dev scope below depth 1
>
> npm lockfiles mark dev: true on transitive entries, but uv.lock marks scope only at depth 1. In pydantic, 103 components reachable only through dev-group dependencies carry no scope at all and will read as runtime unless you trace the paths yourself.

### Run criticality_score per repository

The OpenSSF criticality_score CLI is free. It needs a GitHub token, and its deps.dev lookup is optional (switch it off with `-depsdev-disable`). It scores a repository URL, not a package, which is why you collapse first. By default, contributor_count and dependents_count carry the highest weight, 2× each. dependents_count has a threshold of 500,000, and updated_since has a weight of -1. For scale, the tool's example output for Kubernetes shows a dependents_count of 454393 and a default_score of 0.99107.

What the score proves: the project is widely relied on and actively maintained. When it misleads you: the dependents signal comes from mentions in commit messages, not install counts, so old or noisy repositories can score high. Cross-check every Tier A and Tier B row against ecosyste.ms dependent counts. Write a reason in the override column whenever you move a row against its score.

Rank by tier first, then by score within each tier. Then go through the top of the list by hand. Most of your judgement goes into the top twenty rows, not the long tail.

## How do you tell if a project is already vendor-backed or well funded?

Read who employs the maintainers and who already pays the project. Do not rely on job titles or on how popular the project is. Mark each ranked row with one of three verdicts and note the evidence: **vendor-backed** (a company pays maintainers to work on this project), **funded** (healthy existing donations), or **underfunded**.

The baseline is grim, which is why this check matters. The Tidelift State of the Open Source Maintainer report found that 60% of maintainers are unpaid, and that only 24% are paid for their maintenance work as part of their salary. It also found that 61% of unpaid hobbyists maintain alone, compared with 26% of paid maintainers. The projects that most need money are therefore the least likely to have anyone set up to receive it.

### Employer backing hides behind titles

In Refolk's index of professional profiles, maintainer titles are a poor guide to who backs a project:

| Query | Profiles | Bare "Maintainer" / main title | Large-vendor employers in top 10 |
|---|---|---|---|
| Maintainer, US | 20 | 4 (20%) | 5 (Okta, Red Hat, Ericsson, Microsoft, Netflix) |
| Maintainer, Germany | 4 | 0 | 0 (Dash0, Adfinis, L3montree, OpenMS) |
| OSPO titles, US | 15 | 6 "OSP Manager" (40%) | 3 (Goldman Sachs, State Farm, NVIDIA) |

In the US sample, maintainer-titled profiles sit at large vendors. In Germany, 3 of the 4 hold C-level titles (Chief Architect, CTO, CPO), which suggests founder-maintainers whose own small company may be the vendor. The US sample has 5 times as many maintainer-titled profiles as the German one, and about 1.33 maintainer profiles per OSPO profile. An OSPO, or open source program office, is the team inside a company that manages its open-source use and contributions. These samples are small, and I classified the vendors myself. Treat the table as a pointer to where backing hides, not as a measurement of it.

**4 of 20 - US open-source maintainer profiles in Refolk's index that use the bare title Maintainer**

The rest carry other titles at employers such as Okta, Red Hat, Microsoft, and Netflix, so a title search misses most of the backing.

### The backing check, per row

1. Find the people. Search by repository and project name, not by title. [Refolk](/) handles this as a plain-English request: name the projects and ask who maintains them and where they work now. You get back people and current employers, not a list of titles to sort through.
2. Confirm the employer from commit email domains on recent commits. This proves where the commits come from. It misleads in two ways: people commit from personal addresses on work time, and they use a corporate address for side projects. Where the two signals disagree, mark the row unconfirmed rather than vendor-backed.
3. Read the Open Collective page. It shows the balance and the top contributors. A large balance, or a big-company OSPO among the top contributors, points to funded.
4. Count GitHub sponsors where the project uses them.
5. Remove directed work. If your company pays for features in a project, leave it out of the pledge total, as GitButler did with GitOxide.

I ran this search: `Core maintainers of Tauri, Svelte and Fastify, and which company currently employs each` - [see the full result list](https://www.refolk.ai/s/x2btpetc93).

*Returns the named people behind each project with their current employer, so you can mark a row vendor-backed or underfunded before checking commit domains.*

No published threshold says how much existing funding is enough to deprioritize a project. Set your own threshold, write it in the ledger header, and apply it to every row the same way. The matrix below is how I make the final call.

#### Where each ranked project lands

Horizontal axis runs from Low exposure and criticality to High exposure and criticality. Vertical axis runs from Underfunded, no backer to Vendor-backed or well funded.

| Quadrant | What it means |
| --- | --- |
| Covered and peripheral | Leave out and note the evidence in the ledger |
| Covered and critical | Small or zero grant unless backing is thin for this specific project |
| Exposed long tail | Route through the reserve or an algorithmic split |
| Critical and underfunded | Head grant, sized up to the cap |

*Head grants go to projects that are both critical to you and underfunded, and everything vendor-backed needs a written reason to receive money.*

## Which payment channel, and how much to each project?

Pay through the cheapest channel that reaches a named recipient. Then size each grant using three rules you write down before any money moves: a floor, a per-recipient cap, and a reserve. Gross every amount up for fees so the project receives the net you intended.

### Channel cost

| Channel | Fee | Net on $10,000 | Minimum |
|---|---|---|---|
| GitHub Sponsors, org card | 6% | $9,400 | none stated |
| GitHub Sponsors, invoice | 3% | $9,700 | $5,000/invoice |
| OSC fiscal host | 10% + processor | ≤$9,000 | none |
| Ecosystem Funds | 10% | $9,000 | payouts once fund ≥$1,000 |

Notes your finance team will ask about:

- **GitHub Sponsors by card** costs organizations 6%: 3% card processing plus a 3% GitHub service fee.
- **GitHub Sponsors by invoice** costs 3%. Each invoice must be at least $5,000 and paid within 30 days, and the balance can be used over time without expiring.
- **Open Source Collective**, the most common fiscal host, takes a 10% host fee with no setup fees, minimum balances, or recurring charges. It invoices on 30-day terms. It is a 501(c)(6) nonprofit, so contributions are not tax-deductible. In return for the fee you get an invoice and a public ledger.
- **Ecosystem Funds** takes a 10% management fee. It launched with 291 ecosystems and allocates 100% of every fund with a balance of $1,000 or more each month. Before launch it had paid out over 80% of its funds in 375 payments to 136 projects.
- **thanks.dev, foundation directed funds, and direct contracts** have fees I could not confirm from public sources. Ask each one for its fee schedule in writing before you commit.

> **Tip:** Invoice once, sponsor many
>
> If your GitHub Sponsors spend for the year is $5,000 or more, pay by invoice: the fee halves from 6% to 3%, and because the balance does not expire, a single invoice can fund every sponsorship on the ledger.

### Resolving the recipient

Work through the options in a fixed order for every underfunded row. Stop at the first one that names a person or a fiscal host who can accept the money.

#### Finding a channel for one project

1. **FUNDING.yml** - Read the funding links the repository declares
2. **GitHub Sponsors** - Use the org invoice route if yearly spend reaches $5,000
3. **Open Collective** - Pay the fiscal host and note its balance
4. **Ask the maintainer** - Request a funding link or fiscal host by message
5. **Hold in reserve** - Pay when the reply lands, or reallocate at review

*Check declared channels first, ask the maintainer only when none exists, and park the money in reserve rather than guessing a recipient.*

No public figure says what fraction of critical projects has no funding channel at all. The Tidelift numbers on solo maintainers suggest the gap is largest exactly where need is highest. The documented fix comes from Ecosystem Funds. It asked hundreds of maintainers to update funding.yml, and for those who didn't, it paid maintainers directly through Open Collective. Finding a working contact for a solo maintainer who lists no employer is the slow part. Refolk can turn up the person behind a package and their public professional profile, which spares you a lot of digging through commit history.

**Message to a maintainer with no funding channel**

```
Subject: Funding for <project> from <company>

Hi <name>,

I run open-source funding at <company>. <project> is one of the dependencies we rely on most, and I would like to send it <amount> this year as a no-strings donation. It is not payment for any work.

I could not find a funding link in the repository. Any of these would work on my side:
- a GitHub Sponsors profile
- a fiscal host such as Open Source Collective
- a foundation that holds funds for the project

If you add one, or tell me which you prefer, I can pay before <date>. If you would rather not take funding, a one-line reply is enough and I will move it elsewhere.

Thanks for maintaining it,
<name, role>
```

*Send from a named person, state the amount and deadline, and list only channels your finance team can actually pay.*

### Floor, cap, and reserve

#### Layers of the yearly budget

1. **Cash total** - FTE developers times $2,000 or your higher rate
2. **Head grants** - Critical, underfunded projects picked by judgement, each within the cap
3. **Long tail** - Algorithmic split or floor-sized grants across the rest
4. **Reserve** - Held for projects still setting up a channel and for mid-year additions

*Directed work and memberships sit outside the stack entirely, and every counted dollar lands in exactly one of these layers.*

- **Floor:** the smallest grant you will make. Fees bite hardest on small amounts. At 10%, a $500 floor nets $450. Set the floor where the net amount is worth the maintainer's time to accept. Send anything below it to the long-tail split.
- **Cap:** the most any one recipient can get, written as a share of the budget. Because usage follows a power law, the cap is the only lever that spreads money. GitButler's largest grant was $6,000 of $10,050, about 60%. A lower cap is a deliberate choice to fund more projects.
- **Reserve:** money held back for rows waiting on a channel. GitButler's long-tail slice was $1,050 of $10,050, roughly 10%, which gives you one reference point for sizing it.
- **Gross-up:** gross = net ÷ (1 − fee). A $500 net through a 10% host is $555.56. Open Source Collective lets donors cover the fee, so you can send the grossed-up amount directly. I have not found Pledge guidance on whether fees count toward the total, so record gross and net separately and report whichever the guidelines require.

> A cap is the only lever that spreads money in a power-law graph; every other rule concentrates it.

## How this goes wrong: failure modes and false positives

Most bad ledgers fail in one of seven ways. Each produces a confident ranking that is wrong. Check for every one of them before you pay.

1. **Dev scope dropped in uv.**
   - What you see: dev-only Python packages ranked as runtime, with inflated weight.
   - Why: uv.lock marks scope only at depth 1. In pydantic, 103 dev-only components carry no scope.
   - Check: trace every inbound path and assign the strongest scope. A package reachable from both a runtime path and a dev path stays runtime, and one reachable only through dev paths drops to Tier D.

2. **The dependents signal counts mentions, not installs.**
   - What you see: an old or noisy repository near the top with little real install base.
   - Why: criticality_score's dependents_count comes from commit-message mentions, and it carries 2× weight.
   - Check: compare every Tier A and Tier B row against ecosyste.ms dependent counts. Where they diverge sharply, override and write a reason.

3. **Manifest blindness.**
   - What you see: the framework and toolkit your team uses every day rank low or are missing.
   - Why: lockfiles list packages, not tools. Tauri and Svelte would rank low on a lockfile graph, yet they received 89.6% of GitButler's pledge.
   - Check: before weighting, add editors, frameworks, and CI tools by hand, and ask the team what they would miss most.

4. **Counting a foundation membership as a donation.**
   - What you see: a foundation payment in the reported total.
   - Why: foundation donations are in scope, but LWN reports Whitacre saying Linux Foundation membership does not count. Platformatic's report includes $5,000 to the Linux Foundation, and it is not clear from outside whether that was a donation or a membership.
   - Check: read the invoice. If it says membership, mark the row as not counted.

5. **Counting directed work as a donation.**
   - What you see: a contract for features inflating the pledge.
   - Why: payments for services do not count.
   - Check: exclude it and note it, as GitButler did with GitOxide.

6. **False positives on employer backing.**
   - What you see: a project marked vendor-backed because one maintainer's profile shows a large employer, or marked underfunded because nobody's title says Maintainer.
   - Why: in Refolk's index only 4 of 20 US maintainer-titled profiles use the bare title. A large employer also doesn't prove the job includes this project, since only 24% of maintainers are paid for maintenance as part of their salary.
   - Check: search by repository, confirm from commit email domains, and mark the row unconfirmed when the signals disagree.

7. **Fees eating small grants.**
   - What you see: a long list of $500 grants that each net $450 or less.
   - Why: a 10% host fee, or 6% for card-paid GitHub Sponsors.
   - Check: gross up, consolidate GitHub Sponsors payments onto one invoice of $5,000 or more where you can, and push sub-floor amounts into the split.

One more trap sits above all seven: no public source tells you how much existing funding counts as enough. If you skip writing down your own threshold, two people will judge the same Open Collective balance differently, and the report stops being defensible.

## Publishing the report and keeping the ledger current

Publish a short post that a stranger could check against your ledger. Open the Pledge pull request. Put a review date on the calendar so next year starts from this ledger instead of from scratch.

The report needs:

- The year.
- Your developer count.
- The total paid.
- A breakdown of payments by recipient and channel.
- A line for each excluded item (directed work, memberships) saying why it was not counted.
- Your floor, cap, reserve, and backing threshold, stated as rules.

Then create the JSON file describing your commitment and submit it as a pull request to the Pledge's GitHub repository. Follow the schema the repository shows for existing members rather than copying another company's file field by field.

At the review date, rerun steps 2 to 6 on the current lockfile. Scopes change, maintainers change employers, and reserved rows either get a channel or get reallocated. Hiring changes the developer count, so the budget changes too: Posit's grew from 134 to 160 developers between its two filings.

#### Before you call the ledger done

- [ ] The developer count and budget total are written in the ledger header and match the report.
- [ ] Every row has a scope taken from the strongest inbound path, and uv.lock was traced separately.
- [ ] Every row is one source repository or organization, and unlisted tools were added by hand.
- [ ] Every Tier A and Tier B score was cross-checked against ecosyste.ms dependent counts.
- [ ] Every funded row has a backing verdict with evidence, and none rests on job title alone.
- [ ] Every funded row names a recipient and a channel, or sits in reserve with a follow-up date.
- [ ] Gross amounts include channel fees and add up to the budget.
- [ ] Memberships, services, and directed work are marked not counted and are not in the total.
- [ ] The report states year, developer count, total paid, breakdown, and the allocation rules.
- [ ] The JSON pull request is open and the review date is on the calendar.

## Frequently asked questions

### How do I choose which open source projects to sponsor?

Choose by exposure and need, not popularity. Collapse your lockfile or SBOM into one row per source repository, add tools that never appear in a manifest, rank by how directly you depend on each one and by its criticality score, then remove projects that are already vendor-backed or well funded. The projects left at the top that have a working payment channel get the head grants. The long tail gets a reserve or an algorithmic split.

### Do Linux Foundation memberships count toward the Open Source Pledge?

No. LWN reports Pledge lead Chad Whitacre saying Linux Foundation membership does not count, and neither do payments for services or having open-source developers on staff. Cash donations to open-source foundations are in scope. Before a foundation payment goes in your report, check the invoice or receipt to see whether it was a donation or a membership fee, because the two can look alike in your accounts.

### Should I hand the whole budget to thanks.dev or ecosyste.ms Funds?

I would not. These platforms split money by usage in the build-file graph, and their exact weights are not published. Usage follows a power law, so the money concentrates, and tools that never appear in a manifest get nothing. Published small-company pledges sent 77-90% to two recipients picked by judgement. Use an algorithmic platform for the long tail and fund the head yourself.

### What is the cheapest way for a company to pay through GitHub Sponsors?

Pay by invoice if you can meet the minimum. Organizations paying by card are charged 6%, made up of 3% card processing and a 3% GitHub service fee. Invoiced organizations pay 3%. Each invoice must be at least $5,000 and paid within 30 days, and the balance can be spent over time without expiring, so one invoice can cover several sponsorships.

### What do I do when a critical maintainer has no funding channel?

Ask them to set one up, and hold their grant in reserve while you wait. Ecosystem Funds asked hundreds of maintainers to add funding.yml, and paid the ones who did not reply directly through Open Collective. Send a short message that says how much, why, and which channels you can pay through. If there is still no answer by your review date, move the money to the next row on the ledger.

### Are donations through Open Source Collective tax-deductible?

No. Open Source Collective is a 501(c)(6) nonprofit, and contributions through it are not tax-deductible. It charges a 10% host fee, with no setup fees, minimum balances, or recurring charges, and it invoices on 30-day terms. Finance teams often accept it anyway because it produces an invoice and a public ledger, which makes your report easier to defend.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/open-source-dependency-funding-ledger*