Count the software named on this site. Around thirty distinct projects — the hypervisor, the filesystem, the web server, the tunnel, the VPN, the identity provider, the password vault, the photo library, the media server, the mail server, the phone system, the monitoring stack, the log aggregator, the security platform, and the operating system underneath all of it.
Every single one is free software. Total licensing cost: nothing.
That is not a happy accident of the market. It is the accumulated unpaid labour of thousands of people, most of whom will never know this lab exists. A homelab is only possible at all because of it — the commercial equivalents of that stack would cost more per year than the hardware did once, and several have no commercial equivalent at any price.
So this page exists to say the obvious thing: if you are getting all of this for free, consider paying some of it back. Not out of guilt. Because the supply is not guaranteed, and the failure modes are already visible.
Why it actually matters
Two things are worth understanding, because they change what kind of help is useful.
Maintainer burnout is the normal ending. The typical open-source project is one or two people doing unpaid support work in their evenings, indefinitely, for strangers who are often rude. They do not usually quit dramatically. They drift away, and the project goes quiet, and a year later you notice it has not had a security release. Most abandoned software was not abandoned by careless people; it was abandoned by tired ones.
An unmaintained dependency is a security problem, not just an inconvenience. This site has already written about a security platform pinned to a version carrying a critical remote-code-execution flaw. Fixes exist because someone maintained the thing. When nobody does, the vulnerabilities do not stop being discovered — only the patches stop arriving. Supply-chain attacks specifically target exhausted, under-resourced projects, because a maintainer desperate for help is a maintainer likely to accept a helpful-looking pull request from a stranger.
Both problems are directly, unglamorously fixable.
Money
The least romantic option and often the most useful. It converts into maintainer time, which is the actual scarce resource.
- GitHub Sponsors — most projects with a GitHub presence have a Sponsor button. Recurring beats one-off, because predictable income is what lets someone reduce their day-job hours.
- Open Collective — used by projects that want transparent, publicly auditable finances.
- Directly. Many projects sell support, a hosted version, or a “pro” tier that you do not need. Buying it anyway is a donation with a receipt.
- NLnet funds European open-source and privacy work through grants; supporting the funders scales further than supporting one project.
- Software Freedom Conservancy provides legal and administrative infrastructure to projects too small to have any.
How much? A useful heuristic: total up what the commercial equivalents of your stack would cost, take a small percentage, and split it across the three or four projects you would genuinely miss. For most self-hosters that is a few pounds or dollars a month per project and it is transformative in aggregate.
If you use open source at work, this is the highest-leverage thing on this page. A company expensing a few hundred a year to the projects its product is built on will not notice the cost, and it is worth more than any individual donation. Someone has to ask, and it is usually nobody’s job. Be the person who asks.
Time
Not everything needs money, and some of the most valuable contributions need no code at all.
Write a good bug report. Genuinely valuable and genuinely rare. Steps to reproduce, the version, the actual versus expected behaviour, relevant logs with the secrets removed. Maintainers spend enormous time extracting this from reports that say “doesn’t work.”
Confirm someone else’s bug. An issue with one report is ambiguous. An issue with three independent confirmations and a clear pattern is actionable. This takes five minutes and needs no expertise.
Test release candidates. Projects ship betas that almost nobody runs until they are stable, which is exactly backwards. If you have a lab, you have somewhere safe to run them. That is a real advantage — use it.
Answer questions. Forums, chat, the issue tracker. Every question you answer is one the maintainer does not have to. If you have solved something once, you are qualified.
Improve the documentation. The single most common gap, and the one you are best placed to fix while you are still confused — once you understand something you forget what was unclear. That correction you made in your own notes because the docs were wrong? That is a pull request.
Translate. Chronically under-supplied and immediately useful.
Code
The obvious one, and worth doing well.
- Start with the issue tracker, not with a redesign. Labels like
good first issueexist for exactly this. - Ask before building something large. A big unsolicited pull request is a large review burden that a maintainer may have to reject on direction grounds — bad for everyone.
- Fix your own itch. The bug that annoyed you is one you understand, can reproduce, and will care enough to see through review.
- Small, focused, tested, documented. A patch that is easy to review gets merged. A patch that is a weekend of reading does not.
- Follow through. An abandoned pull request after review comments is worse than none — the maintainer spent the review time for nothing.
Things that cost nothing at all
- Say thank you. Maintainers hear from users almost exclusively when something is broken. An unprompted message saying a project is useful is rare enough to be memorable.
- Report security issues privately, through the project’s disclosure process, and give them time to fix it.
- Write about what you built, so the next person finds it. That is part of why this site exists.
- Recommend it. Adoption attracts contributors, which attracts funding.
- Do not be the entitled user. Nobody is obliged to fix your problem on your timeline. “Any update on this?” on a two-week-old issue costs a volunteer more than it seems.
Where to start, concretely
If this is a wall of good intentions, do exactly this:
- Pick the one project you would be most annoyed to lose. Not the biggest — the one you would actually miss.
- Check whether it takes money. Set up a small recurring donation.
- Next time it confuses you, write down what confused you and send it as a documentation fix.
That is it. One project, one small monthly amount, one documentation fix. If everyone reading this did that, the maintenance problem would substantially go away.
This site is built on free software, published with free software, and documents infrastructure made entirely of free software. Pointing that out without pointing anywhere useful would be a bit hollow — hence this page.