Every year, I donate a few percent of my income to Helen Keller International, an organisation that provides vitamin A to malnourished children. The reason I choose Helen Keller for my donation is that

• vitamin A is cheap;
• lots of children are vitamin A deficient, and fixing that meaningfully improves their health; but also
• almost all of the money Helen Keller receives gets converted into vitamin A for those who need it.

It is difficult to get a dollar to improve the state of the world more than by using it to help malnourished children get enough vitamin A.

Unfortunately, this also makes it difficult to donate to open source projects, because a donation to e.g. Mozilla is a donation that does not get vitamin A to children.

But then something has happened recently. My own children are at the age where they are starting to go to activities outside of their normal daycare/school routine to build redundant social circles. These activities are generally fun, but also cost a little money.

You know what else is fun but costs money? Open source. That’s when I realised I should not think of open source donations as charity; rather, I should make them from my fun money, the part of my budget I use to purchase cool gadgets.

With the moral contortionist trick for actually donating out of the way, the new problem becomes deciding which projects to donate to. Ideally, it should be projects that

• are important,
• can absorb donations and turn them into meaningful work, yet
• aren’t receiving lots of donations already.

I don’t know how to create a list of open source projects that are important to me. Some of those I use, e.g. Fedora, are highly visible and easy to add to the list. But then Fedora in turn consists of many parts, like Polkit. I don’t know if a donation to Fedora would also finance Polkit, or if I should consider Polkit a separate donation target. This applies any time I use a project which has dependencies in turn. A donation to the main project probably should trickle through to its dependencies, but I doubt that happens in practice.

Then there are language libraries. I use R a lot. But within R, I often use the evir library for extreme value analysis. In my head, I would want a donation to R to be split across R and the R libraries I use, but that’s not how it works, so I would have to list the libraries I use as separate donation targets. That would probably work for R and Perl, where I rely on a fairly small set of libraries. But for something like Haskell? Or transitive dependencies on C libraries? Not going to happen.

For this reason, I decided to not include any libraries in the list. The list contains only projects that produce an executable that I invoke directly. This is extremely unfair, because some of these libraries are probably in desperate need of financial support. However, my list would grow to an unmanageable size if I didn’t draw arbitrary boundaries. It sucks. If you have an idea on how to handle libraries in this framework, let me know. I’d really like to.

To reduce the size of the list further, I only retained projects that I have used for a few years. This got me a list of 36 projects I have used directly for several years. I probably failed to think of many, so I will have to revise the list with time. This list contains entries like Cabal, Darktable, Emacs, git, Immich, notmuch, OpenMW, OpenStreetMap, Python, TeXLive, WeeChat, and more.

Next comes prioritisation. I scored each project on three dimensions, all subjective scales in the range 0–1:

1. How critical is this project to me in my personal life?1¹ Note that this excludes things I depend on professionally. That may or may not be the right thing to do, but I imagine if an organisation employs people and makes money, it’s on them to donate appropriately for the open source software they rely on. How much worse off would I be if it didn’t exist?

   This score is tricky when it comes to projects where there are many alternatives. Today, I rely a lot on tmux for its nohup functionality, but if it didn’t exist, I could use one of the many alternatives that exist. This speaks in favour of reducing its criticality score to encourage donations to go to things where alternatives truly do not exist, such as ghc. On the other hand, if we stop donating to types of software just because alternatives exist, that disincentivises development on all alternatives of that type. We don’t want to disincentivise competition! I have no solution to this problem. I have tried to pick something in between “how much do I need this type of software?” and “how much do I need this specific project?”

2. What is the marginal impact of a donation? Some projects can take a sudden wad of cash and immediately spend it on something useful – that’s high marginal impact. In order of decreasing impact, we have other projects which work with long-term contracts and need time to be able to spend unexpected donations, followed by projects that don’t have anything to spend money on at all, and would put additional donations in a rainy-day fund. Then there are some zero marginal impact projects; these are those that don’t accept financial donations at all.
3. How neglected is the project by other donors? Projects like nginx, Linux, and Python have corporate sponsors and wouldn’t notice if my loose change came or went. Others like XMonad have a financing pipeline set up, but with a thin flow of donations.

After estimating these for the projects, I assign a final priority score as the geometric mean of these three. That means if a project has a zero score along any dimension (e.g. Darktable with zero impact because they don’t accept donations), it gets a zero priority score. A project that has medium scores on all dimensions (e.g. Matrix.org) gets a higher priority score than a project that has mostly low scores but one dimension scores very highly (e.g. Linux, which is very important to me, but also has plenty of corporate sponsorship already and it’s not clear how they’d use a small additional donation.)

The scores are noisy, but at least they are quantitative.

The ten top-priority projects on my list consists of two categories:

• Small-to-medium size projects that are neglected, and with a reasonably clear path for using more money: Magit, XMonad, KeyPassXC, org-mode, F-Droid, SyncThing.
• Foundations that are receive lots of donations, but are still underfunded compared to their large scope: Perl, OpenBSD, OpenStreetMap, Matrix.org.

Given the small amounts I’m donating to start out with, it would be unreasonable for me to split my donation over more than three projects. Thus, my donations, for the time being, will go to the top three candidates in my list:

• Magit: A single developer is working full-time on this high-quality application with a large user-base, and is currently underpaid to do so.
• Perl 5 Core Maintenance Fund: The Perl & Raku Foundation have suffered severe budget constraints the past few years, resulting in core maintainers being underpaid for their work. Perl is not hot, but it’s important to me and to the internet at large.
• XMonad: This is developed primarily by a small team of spare-time hobbyists, but they have expressed both a will and a rough plan for scaling up development if it becomes financially possible.

I will split a part of my fun money among these three for the next twelve months or so, and then revisit the choice to see if other projects need my money more.