open-funding: a map of who might pay for your open source work

A document shaped as a checklist, one funder per entry

open-funding is a guide for researching ways of funding open source projects, and it is a document rather than a program. The repository description says so in one line, and the primary language field is empty because there is no source code in the ordinary sense.

What there is, is a very long README organised as a table of contents that reads like a spreadsheet of funding opportunities. The structure repeats with almost mechanical consistency. Each funder gets an About section, an Eligibility Criteria section, an Application section and a Deadline section, and the entries are grouped under a Grants heading.

That consistency is the main contribution. Funding research is usually a matter of visiting twenty programme pages and remembering the eligibility rules for each, which is a workflow that fails silently. Here the same four questions are answered in the same order for every programme, so you can scan a hundred funders and notice which ones you might qualify for.

The final section in the visible table of contents is titled Currently Not Applicable, which is a good sign about the author's intent. The guide is not pretending that every programme is open to everyone, and it appears to keep a separate record of the ones that are closed or that do not fit, rather than silently dropping them.

The recurring shapes in the funder list

Roughly thirty programmes appear in the table of contents, and grouping them by the kind of money they hand out is more useful than reading them one by one.

Several are general purpose foundations that fund open source as part of a wider mission. The Awesome Foundation, the Matthew Good Foundation, the Chan Zuckerberg Initiative, the Open Society Foundation and the Roddenberry Catalyst all appear, alongside the Metamask Grants, the Web3 Foundation Grants and the Kusama and Polkadot Treasury Fund entries, which are treasury models where funds are allocated by a community rather than applied for through a form.

Others are tied to a network or a region. The NGI-NLNet Foundation, the Internet Freedom Support Fund on Open Collective, the Open Humans project, the Swedish Internet Foundation, Vinnova for Sweden, SIDN Fonds for the Netherlands, the RIPE NCC Community Projects Fund, Netidee for Austria and InnovationsFonden for Denmark all sit in that category, and the country flags in the headings make the regional bias visible at a glance.

A third group is tied to a sponsor's interests. Cisco Research Grants carries two named tracks, Sustainability and Web 3. The Comcast Innovation Fund, the Top10vpn Research Grant and the Unreal Engine Megagrants are company programmes. The Sloan Foundation has three programme areas, Better Software for Science, Exploratory grant making in technology, and Data and computational research, with sub-topics listed under the first two.

And two entries are about people rather than projects. The Sovereign Tech Fund appears twice, once generally and once as Maintainer Fellowships, which is a useful reminder that maintainer time is a fundable line item.

Why the guide is right about reading the funder's own page

Every entry in the guide ends with a Deadline section, and that is the part that dates fastest.

Grant programmes have fixed application windows, usually quarterly or yearly, and an entry written a year ago has a deadline in the past. The guide cannot avoid this, because a static document listing deadlines is always going to be partly out of date, and that is precisely why the guide is a research aid rather than an application service.

There is also the question of what the guide can know. Eligibility criteria are set by each programme, and they change, sometimes for political reasons inside the foundation and sometimes because a programme has run out of money. The most useful thing a guide like this can do is point at the right programmes and give you the questions to ask, which is what the four part structure does.

For a maintainer looking for funding, the practical sequence is therefore short. Read the About line of each entry to see whether the programme is even in the same universe as your project, read the eligibility criteria against your own situation, and then treat the application and deadline sections as pointers rather than as instructions. The deadlines are the part to re-check on the funder's site before you plan around them.

One specific warning is worth making about the treasury entries, Kusama and Polkadot. Those allocate funds through on-chain governance rather than through an application form, so the Application and Deadline sections mean something different there, and the route to funding is participation rather than a form.

Topic specific lists, and the crypto file

The repository contains a topic_specific_lists directory alongside the README, and the one file visible in the tooling configuration is CRYPTO.md.

The topic_specific_lists directory is the guide's way of handling the fact that some funding routes are only relevant to certain kinds of project. A cryptocurrency project, for instance, has access to treasury funds and web3 programmes that a general purpose library does not, and the people most likely to need those entries are the people least likely to read a long alphabetical list of foundations.

The naming convention is visible in the npm script, which is the only piece of automation in the repository.

npm run toc

hallmark --fix README.md topic_specific_lists/CRYPTO.md

The hallmark tool reads the markdown files, regenerates the table of contents in place and fixes the formatting, which is what keeps a document with this many nested headings maintainable. Running it over both the README and the crypto list means the two documents share one generation step.

The package manifest is minimal. The package is called open-funding, it is private, the only script is toc, and the only development dependency is hallmark at version 4 or newer. There is no runtime code, no build pipeline for an application and no test suite, which is exactly what you would expect from a repository whose deliverable is a set of markdown files.

What the repository is, and the licence question

It is worth being explicit about what this repository is not, because a repository with a package.json looks more like a tool than it is.

There is no software to run. The package manifest exists so that the table of contents generator can be run with a single npm command, and that is the whole role of the Node setup. The content is the README and the topic specific lists, and the value is entirely in what the author has collected and how they have arranged it.

The licence situation is the one thing that deserves attention from a reader who wants to reuse the content. The licence field on the repository carries no value, and there is no LICENSE file among the top level entries, which are the .gitignore, the .npmrc, CONTRIBUTING.MD, the README, the package.json and the topic_specific_lists directory.

A document with no stated licence is not public domain. If you want to reuse the guide, translate it, fold its entries into your own fundraising notes or mirror it, you should ask the author or the contributors rather than assuming permission, and the contributing file in the repository root is where that request belongs.

That is a small point in the context of a guide that exists to help people, but it is the sort of thing that matters for a document whose main asset is a curated list that other people would want to build on.

Maintenance, and how to read the entry dates

The last push was on 2026-05-28, the default branch is main, and the repository has no GitHub releases, which is consistent with a document rather than a package. There is no versioning scheme to track, and the changelog lives in the commit history.

The absence of releases is the right shape for this kind of repository, but it does mean there is no way to tell from the outside which version of the guide you are looking at. A fork, a mirror or a copy of the README will drift from the original without any marker, and for a document whose content is deadlines and eligibility criteria, that drift is the main failure mode.

The practical advice is to read the guide as a map, not as a source of truth. Use it to find the programmes in your area of the world and your category of work, then go to the programme. If you find an entry that is out of date or a funder that is missing, the repository has a contributing file and an issue tracker, and adding a funder is a contribution of exactly the kind the guide is built from.

The topics attached to the repository are crowdfund, foss, funding, funds, grants and oss, which is a fair summary of the scope, and the fact that crowdfund is listed alongside grants is a useful signal that the guide is aimed at a maintainer with a specific project in mind rather than at an organisation looking for a fundraising platform.

Editorial conclusion

Adopt open-funding as a starting map when you are looking for money to keep an open source project going, especially if you are outside Europe and North America where the listed funders are thin, or if your work touches the themes the guide covers, such as internet freedom, sustainability, research software or maintainer time. Do not treat it as a decision tool on its own, because every entry is a pointer to a programme you must read and confirm yourself. Before you act on any line, check the funder's own page for the current deadline and criteria, since the guide records deadlines at the time of editing, and the repository carries no licence file, so check the terms before you republish or adapt its content.

Frequently asked questions

Official sources

1. Issues
2. ralphtheninja/open-funding on GitHub
3. README