Borg is a living open-source project — and you can be part of it. This episode maps the development direction (the awaited stable Borg 2.0 release, the security & performance focus) and the community: the GitHub repository, documentation, IRC/Matrix channels, forums, and the Bountysource funding system.

Twenty episodes in, you have gone from installing borg to monitoring production. There is one dimension we have not touched: Borg as an open-source project built by a community. Understanding the project's direction helps you plan migrations (when to move to 2.0), while participating in the community is the fastest way to grow and to make sure the bugs you encounter get fixed.
The signal everyone is waiting for is the stable Borg 2.0 release. As we discussed in episode 17, 2.0 brings an overhauled repository format, a more scalable hash index, --match-archives, and new segment management. The project's roadmap places 2.0 stability as a priority — until then, 1.4.x continues to be maintained as the production path.
Two themes are consistent across the roadmap:
As a practitioner, the best way to follow the roadmap is reading the changelog and release notes — not guessing from forums.
The main repository lives at github.com/borgbackup/borg. This is where everything happens:
The official documentation at borgbackup.readthedocs.io is the source of truth — far beyond third-party tutorials. There you will find guides, the FAQ, the changelog, and a security section. For questions still unanswered, the documentation points to community channels.
The community is active on the #borgbackup channel (Libera.Chat / IRC) with a bridge to Matrix. This is the fastest place to ask practical questions — and also the right place to report odd behavior you suspect is a bug, before it escalates to GitHub Issues.
Because Borg is community-funded, the project uses Bountysource — a platform where individuals/organizations can offer a bounty for a specific feature or bug. It is not an obligation, but a concrete way to give back without writing code.
Tip
The best contribution for non-programmers: reproduce bugs cleanly. When a backup behaves oddly, collect the borg version, the borg check output, and the reproduction steps — a quality report is a highly valued contribution and speeds up the fix you need.
Start small and sustainable:
In episode 22 — the series finale — we widen the view: ecosystem, alternatives & closing reflections — comparing Borg with Restic, Borgmatic, rsync/tar, Proxmox Backup Server, and Bacula/Veeam, when to choose which, a recap of the 22-episode journey, a production checklist, and next steps.