Every open-source roundup is reading from the same small pool. The names barely change from one list to the next, the recommendations are correct, and the writeups stop being useful the moment you already know the players. So I went looking further down the discovery ladder. Smaller GitHub projects, niche forum threads, repos that barely trend, and the recommendations of maintainers whose taste I already trust.
This is the short list of what stuck. Six tools I personally keep installed across at least one machine, no brand deal and no affiliate link, written so the next person who has worn out the usual roundup has somewhere to go.
Why the canonical roundup formula stays in rotation
There is a real reason every listicle starts with a recognizable name. The first time a new reader encounters open source, a confident recommendation of VLC, LibreOffice, GIMP, KeePass, Bitwarden, or Thunderbird is doing useful work. Those tools earned their keep. The recommendations are accurate.
The problem starts on the second and third read of the same kind of list. Once those six are already installed, the article is no longer introducing them. It is restating them. The list writers know this, and the path of least resistance in a deadline-driven publication cycle is to recycle the same names with a fresh headline. The list stays accurate and stops being useful at the same moment.
When a recommendation article feels like that, the move is to stop reading roundups and start reading maintainers. Find the open-source author whose work you already trust, read what they are using, and filter the suggestions through the lived experience of someone who has actually carried the dependency. That is where this list came from.
A second signal that a listicle is recycling rather than discovering is a thin opening paragraph. Lists that pile up brand names in the first three sentences are usually thin everywhere else too. The lists that take a position, name an actual annoyance, and explain why the new tool beats the commercial alternative are the ones worth reading. Discovered apps tend to surface first in long-form blogs, Mastodon threads, and Discord channels, and only land in the roundups after a season of word-of-mouth.
The six apps worth installing this season
Kando
A radial launcher that lives on top of any Linux desktop and turns the mouse wheel and a hotkey into a circular menu of apps, files, scripts, and custom commands. The replacement is in the category of tools I forget I am using until I switch desktops and lose the gesture for a single afternoon. The repo, install instructions, and plugin catalog are all on GitHub under the BSD license.
A short list of why Kando belongs on a desktop where the canonical six are already installed.
- It does not depend on a window manager (the part of the desktop that draws and arranges the windows on screen), so it works on GNOME, KDE, XFCE, and Hyprland without a config file.
- The radial menu can be triggered by mouse, by keyboard, or by the corner of the screen, whichever the user actually reaches for during the day.
- Theme files are plain JSON, so a community member can publish a custom layout on a personal page without setting up a marketplace.
- Nested menus turn long command lists into a hierarchy the muscle memory can hold, instead of a flat list the eye has to scan every time.
LocalSend
The cross-platform file share that does not need an Apple account, a Google account, or a network you do not own. It works on phone, laptop, and Linux desktop over the same Wi-Fi as the router. It does not phone home and the install is a flat binary I can audit. It is the replacement for every “send me the file” email and every “let me airdrop you this” that breaks the moment the recipient is on a Pixel.
Stirling PDF
A self-hosted document tool that runs in Docker and replaces the browser-based services that ask for an account, upload to a server I cannot audit, and charge for the second step. Merge, split, redact, convert, sign. Stirling is the answer to the question of what to do with the PDF the bank sent.
The version that earned a permanent install for me was the OCR add-on (optical character recognition, the part that converts a scanned image back into editable text). Together they replaced four bookmarks on my browser bar and one desktop app I had been paying for.
Mealie
A meal-planning and recipe app that lives on a server in the house. It imports recipes from any URL, parses the ingredients into a shopping list, and keeps the list across phones and laptops. The self-hosted version is one docker-compose file and a directory I already back up. It is the rare app that earns its keep the first weekend I stop writing grocery lists on the back of an envelope.
Every recipe is stored as plain JSON with a stable schema. When the new release lands, the upgrade is a single container rebuild. When I move to a new server, the data folder zips up and ships. There is no “export to vendor format” step and no paid-tier import gotcha.
Vikunja
A task manager that does not force a method on the user. Tasks, lists, kanban, calendar. The data lives in a single SQLite or Postgres file, and the web frontend is fast on a phone or a desktop browser. It is the kind of boring infrastructure app that is hard to demo and easy to live with for a decade.
Actual Budget
A local-first budgeting app that uses envelope-style budgeting, a method that predates apps by decades. The interface is plain, the math is correct, and the data lives in a single file I can back up to a thumb drive or a private Git repo. Actual is the one I send friends who keep asking what I use to keep the books straight.
A common thread across these six: none of them depend on a server the user does not control. Every one of them has a single-binary install, a Docker image, or a self-hosted web frontend that runs on hardware the user already has. None of them bundle analytics, telemetry, or a “we use your data to improve the product” footnote. The small print on the homepage reads like the small print on a piece of free software, not on a SaaS contract.
How to actually pick a starting point
The first install to try is the one that solves a small annoyance. Stirling replaces three browser bookmarks the first week. LocalSend replaces one email a day. Kando replaces a muscle memory I did not know I had. The wins stack up, and after a season the roundups become optional reading.
If a roundup starts with the usual six names, scroll past it. If a maintainer I already trust recommends a smaller project, try the smaller project. If the install instructions fit on a single page and the binary is signed, that is a stronger signal than stars. If the repo has been quiet for more than a year, look at the last commit and the open issues before committing any data to it.
Trade-offs
Self-hosted open source is not free. Stirling needed an evening to set up the right reverse proxy (a small service that sits in front of a container to handle HTTPS, domain names, and rate limits) and a backup script. Mealie wanted a Postgres container, and the recipe importer ate an afternoon the first time I pointed it at a popular recipe site. None of this is hard. All of it is real, and a household that runs ten containers without a checklist is going to have a bad week when something breaks.
A second trade-off is the maintenance tax. Each of these apps has its own release cadence, its own security advisories, and its own breaking-change log. Six small services is fine. Twenty is a part-time job. Pick the few that solve an annoyance I actually have, not the ones that look good on a homelab dashboard.
The third trade-off is the community size. The canonical roundup picks have forums and Stack Overflow answers for every error. A smaller project has the maintainer, the issue tracker, and maybe a Discord channel. When something breaks at 2 a.m. I am either working the bug out solo or waiting on a volunteer who has a day job. That is the cost of staying close to the tools. It is also the reason those tools stayed small and stayed good.
What I would tell past me
Stop reading roundups. Read maintainers instead. Find the open-source author whose work I already trust and read what they are using, what they recommend, and what they have quietly removed from their own setup. The signal is much higher and the noise is much lower. A maintainer’s curated short list is worth more than a publication’s weekly roundup, and the maintainer is usually more honest about the trade-offs.
If only one of these six gets installed this weekend, install LocalSend. The path of least friction and the highest daily return. The rest can wait for a slow afternoon.
FAQ
What about the apps I already have installed and like?
Keep them. The canonical names really are good at the things they were built to do. The list above is not a replacement for the roundup picks. It is the next layer, after the obvious picks are already on the disk and the reader has worn out the first wave of recommendations.
How do I know if a smaller open-source project is still maintained?
Look at the last commit date, the last release date, and the count of open issues. A project with commits in the last month and a release in the last year is healthy. A project with commits in the last week and a release in the last week is either small or over-caffeinated. A project with no commits in a year is a museum exhibit rather than a tool, and the install command should be a respectful nod.