The norms
The Give Back Standard
What a good declaration looks like, and how to think about what goes in it. None of this is binding. That is what makes it useful.
Everything on this page could have gone in the licence, and putting it there would have ruined it. A suggested amount in binding text is a fee schedule. A norm in binding text becomes an unbounded liability that no corporate lawyer can approve. Out here it can say useful, specific, arguable things, be wrong, and be revised next year without anybody relicensing anything.
Departing from this document is not a breach of anything. Ignoring it entirely and publishing a compliant declaration that says you gave nothing is a legitimate position, and one this project expects a great many organisations to take, at least at first.
1. Look properly
The declaration asks what you rely on. Almost everyone’s first instinct is to list their direct dependencies, which is between twenty and eighty things and is not the answer. The answer is the transitive tree, which for a normal web application is somewhere between four hundred and two thousand components, and which almost nobody has ever seen laid out.
Look at all of it. Then look specifically for these, because they are what the exercise is for:
- Single-maintainer projects. One person, no organisation, no funding. These are your actual risk and they are almost never the ones you have heard of.
- Projects with no commits in eighteen months that are nonetheless deep in your tree.
- Projects whose maintainer publishes no profile at all, which usually means nobody has ever asked them anything.
- Things you assumed were corporate and are not. This is the category that surprises people.
Depth beats breadth here. A declaration that names four hundred packages and says nothing about any of them is worth less than one that names the eleven things that would actually hurt.
2. Give by need, not by visibility
The default failure mode of every giving-back scheme is that money flows to the projects that are already famous, already sponsored, and already fine. React does not need your thousand dollars. The dependency four levels down that resizes your images, written by one person in Utrecht who has never been paid for it, might be changed by it entirely.
This is the whole reason maintainer profiles exist. Until profiles are published, “give where it is needed” is not a principle, it is a wish, because there is no way to compute need. With profiles, the ranking falls out of the data.
| Signal | What it suggests |
|---|---|
| Unincorporated, 1 maintainer, unpaid | Highest priority. Small amounts change outcomes here. |
| Not-for-profit, 2–5 maintainers, partly funded | High. Usually running on grants that expire. |
| For-profit, funded, employs its maintainers | Low. Give attention, not money. |
| No profile published | Unknown, and worth ten minutes to find out. Often the same as the first row. |
3. Money is not the only currency, and often not the best one
A tired maintainer with a hundred open issues frequently needs triage more than they need four hundred dollars. Ask before assuming. All of the following count, and all of them belong in the “what I did” field:
Money
Direct sponsorship, recurring donations, a purchase of commercial support you did not strictly need, paying for a feature you want anyway.
Work
Patches, reviews, issue triage, reproductions, documentation, translations, release testing, dependency upgrades, a security review.
Infrastructure
Hosting, CI minutes, a build farm, package mirrors, signing certificates, a domain renewal somebody has been paying for personally.
Time
Paid staff hours, explicitly allocated. An afternoon a fortnight, rostered, is worth more than an enthusiastic hackathon.
Employment
The strongest form. Hiring a maintainer, or funding a role at a foundation, with no strings on what they work on.
Standing
Public reference, a case study, a conference talk, letting them say your name. Free to you, and sometimes the thing that unlocks their next grant.
4. The numbers
These figures are a starting point for a conversation, not a target, not a floor, and emphatically not an obligation. They are here because “give something” is useless advice to a finance team who need a number to put in a cell, and because if this document does not supply one, someone will invent a worse one.
The most workable framing found so far is a proportion of what you already spend on the people who use the software, because it scales automatically, survives inflation, and is a number every organisation already has to hand.
| Level | Suggestion | What it means in practice |
|---|---|---|
| Publish Tier 0 |
Nothing | You look, you publish, you give nothing. Fully compliant. A reasonable first year for almost anybody, and better than most organisations manage today. |
| Notice Tier 1 |
0.1% of engineering payroll | For a team of ten, roughly NZ$1,500 a year. Enough to sponsor the four or five single-maintainer projects you found. This is the level at which the exercise stops being theoretical. |
| Support Tier 2 |
0.5% of engineering payroll | A real budget line with an owner. Sponsorships, plus rostered staff time on upstream work. About the level at which maintainers notice you exist. |
| Sustain Tier 3 |
2%+, or a person | Funding a role, or employing a maintainer to keep doing what they were doing. Very few organisations are here. The ones that are tend to depend on open source for their entire revenue. |
Engineering payroll, not IT spend, and not revenue. Revenue-based figures punish low-margin businesses and are trivially gamed. Payroll tracks the thing that actually correlates with how much open source you are consuming.
Charities, schools, individuals and volunteer projects: tier 0 is the expected answer, and nobody should feel awkward about publishing it. The point of the exercise is the looking. It was never a means test.
5. Write the “why” honestly
Field (e) is the one that will embarrass people, and it is the one worth spending twenty minutes on. It is not a marketing paragraph. Nobody is scoring it. The audience is a developer at a competitor, an auditor, and possibly one of the maintainers you named.
Weak
“Acme is deeply committed to the open-source community and believes strongly in the collaborative ethos that underpins modern software development. We are proud to be part of this ecosystem.”
Says nothing, commits to nothing, and reads as though it was written to avoid saying the number. Everyone can tell.
Better
“We gave nothing this year. We had not looked at this before and there was no budget line for it. Of the 412 components we depend on, 47 have a single maintainer and nine of those have had no commit in over a year. We have proposed NZ$4,000 for next year, directed at those nine first. If that is not approved we will say so here.”
Gives nothing, and is a far better declaration. It is specific, it is checkable next year, and it is obviously true.
A useful test: would you be comfortable if the maintainer of your most fragile dependency read this paragraph? Not proud. Comfortable.
6. Make it somebody’s job
An annual obligation with no owner is an annual obligation that gets done at 4pm on the last day by whoever is unlucky. Three things make the difference between a real declaration and compliance theatre:
- Name an owner. A person, not a team. Ideally an engineer, not counsel.
- Align it to your financial year. The licence lets you choose your twelve-month period for exactly this reason. Do the looking while the budget conversation is open, not four months after it closed.
- Show it to someone senior. The single most valuable thing about this entire scheme is a director seeing, once, the list of unpaid strangers their business runs on. Do not let that document go straight to a web server without anyone reading it.
7. Things that defeat the purpose
- Automating it end to end. The tool should draft; a person should read. A declaration generated and published by a cron job with nobody in the loop has skipped the only step that mattered.
- Giving to whoever has the easiest donate button. Convenience is not need.
- Counting your own open source as giving back. Publishing your work is good and it is not the same thing. Note it separately if you like, but it does not discharge anything.
- Treating tier 1 as a ceiling. It is a starting point chosen to be approvable, not a fair valuation of what you have received.
- Waiting until the declaration is impressive. Publish the unimpressive one. The series is the point; a first year of zeroes followed by a second year of something is a far better public record than a four-year silence.
8. Versioning and governance
This document is versioned separately from the licence and can change at any time, including the numbers in section 4, which are the part most likely to be wrong. Changes are recorded on the changes page.
It is currently written by one person, which is a weakness rather than a feature, and is published under CC BY 4.0 so that anyone who thinks it is wrong can fork it and say so. The intended end state is that a body that is not this project maintains it. More on that.