-
Notifications
You must be signed in to change notification settings - Fork 177
Google Summer of Code 2026 Ideas
This idea page is for multiple Borg-related projects listed below. In short what each project does:
- Borg is a Python-based file backup tool. It can also compress, encrypt/authenticate and deduplicate the data. Repository for Borg
- Borgmatic is a CLI wrapper for it that keeps settings and runs pre- and post-backup tasks. It basically helps manage your Borg repos, settings and tasks that go with it. It also deals with monitoring. Repository for Borgmatic
- Vorta is a desktop GUI for Borg. It sits in your task bar and runs backups in the background. You can also use it to view and restore different versions of your files. Vorta officially supports Linux and MacOS while the community is currently testing running vorta on Windows. Our latest release was downloaded over 9000 times via flathub or the MacOS installer. However many users install Vorta from the package repository of their Linux distribution. Repository for Vorta
In addition we have an Ansible role and a Docker image to make installing Borg and Borgmatic easier on servers.
Technologies used: All projects use Python as main language. Vorta also relies on Qt for the GUI parts. The devops tasks use Ansible and Docker.
AI use: Task durations assume the use of AI coding assistants. Accepted contributors can request a sponsored subscription if needed. While AI tools can accelerate implementation, contributors remain fully responsible for all code they submit. We expect contributors to invest additional time in understanding the codebase, making sound architectural decisions, and ensuring code quality—AI assistance doesn't replace critical thinking and careful review.
GSoC is a program that allows students and open source beginners to learn contributing to an open-source project while receiving a stipend from Google, and mentorship from open-source software developers. For details about this year's GSoC, please refer to this page.
The Borg Collective is part of the Python Software Foundation. Please read about our expectations.
- Get in touch on Github and tell us that you are interested in one of our projects. This doesn't represent any commitment to apply as a contributor. You can choose to apply for a different project at any time.
- Select an easy issue which are tagged/labelled with
good first issueand try solving it. (view such issues in each project: Vorta, Borg, borgmatic) This allows you to get to know the project and its source code. This helps you determining whether it suits you and whether you want to apply as a contributor. Solving an issue and opening a pull request (PR) for it will also be required for applying. - Before working on an issue, please comment and make sure it's assigned to you, so no duplicate work is done. Also outline how you plan on solving the issue, so you are on the right track from the start. We can give you some hints on how to go about, but we also want to see how you manage on your own.
- Open a PR fixing the issue. We will then review it as usual. Don't feel discouraged if the reviewer requests changes to your PR. This doesn't question your skills. We just want the code to meet our (formal) standards.
- When you are sure that you want to apply as a contributor to one of our projects, it is time to discuss the project ideas that you are interested in with your prospected mentors. We will set up a private room with the relevant members. Make sure to communicate your current knowledge and expertise so that your prospected mentors can guide you adequately. After this step you should have a clear understanding of task you will apply for including expected results, tasks and steps towards that goal, time effort.
- Your prospective mentors will then help you with writing your application. It is very important to check in with them on your application before submitting. Else your likelihood of being accepted shrinks drastically. To get quick feedback it's best to share your application using something like Google Docs with comments enabled.
During all steps communication is key. Talk to the mentors as well as other community members, take their feedback and advise into account. You can find more information about the process alongside tips on the website of the PSF.
To start coding, see the existing contributor guides for each project and setup your development environment:
Feel free to ask questions. On your journey you might encounter unclear, insufficient or missing documentation. Don't hesitate to point out the problems, so we can help you out as well as improve the documentation of our projects.
You will be working with the below maintainers to implement your projects and learn more about the daily tasks of maintaining an open source project. Please don't tag any mentors. We will see your comment or PR and someone will respond if you have a question.
- @witten: Primary mentor for Borgmatic
- @m3nu: Primary mentor for Vorta
- @ThomasWaldmann: Mentor for Borg (backup mentor)
These are tasks you can work on. You can combine any number of tasks, so they add up to a full- or part time project. You can also suggest your own tasks to supplement the ones below. Especially if they are related. Keep in mind that this is not about picking the easiest tasks, but learning something that will be useful later. It's best to pick tasks from a single project, so you can work with the same mentor the whole time. Stated lengths are preliminary approximations.
Difficulty: Medium to Hard
Length: 90 hours
Skills required: Python, Qt, SQLite/Peewee ORM
Description:
Refactor Vorta's scheduler to improve reliability, maintainability, and user visibility into scheduled and past jobs. This involves adding a persistent jobs store to track pending/scheduled jobs that survive restarts, separating scheduling, execution, and state management into focused components, and adding a new Jobs View UI.
Task outline:
- Add a database model to track pending/scheduled jobs, skipped jobs with reasons, and link between scheduled intent and execution results
- Split the current
VortaScheduler(532 lines) into focused components for scheduling, execution, and state management - Create new Jobs page showing pending and completed jobs with filtering by profile, repository, job type, and status
- Improve reliability by addressing QTimer limitations and race conditions
Additional details: See #2360
Possible mentors: @m3nu
Difficulty: Medium
Length: 90 hours
Skills required: Python, Qt, Software Architecture
Description:
Comprehensive refactoring of the views layer to reduce code duplication (~200-250 lines of duplicated boilerplate), improve maintainability, and establish clearer architectural patterns. This includes creating a BaseTab class, adding a ViewModel layer, and reorganizing dialogs.
Task outline:
- Create
BaseTabclass that manages signal connections with automatic cleanup and provides template methods - Replace
BackupProfileMixinwith proper dependency injection for better testability - Add ViewModel layer (e.g.,
RepoTabViewModel) to handle data transformation, validation, and persistence - Split large tabs like
ArchiveTab(900+ lines) into smaller focused components - Reorganize dialogs into logical subfolders
Additional details: See #2361
Possible mentors: @m3nu
Difficulty: Medium
Length: 45 hours
Skills required: Python, mypy, Type Systems
Description:
Add comprehensive type annotations throughout the Vorta codebase and enforce type checking via CI. Currently only ~22% of files import typing and ~32% have actual type hints. This will improve code quality, catch bugs earlier, enable better IDE support, and make the codebase more maintainable.
Task outline:
- Configure mypy with appropriate settings for gradual adoption
- Add type stubs for dependencies (PyQt6-stubs, types-peewee)
- Add type checking to CI and pre-commit hooks
- Systematically add type annotations starting with core modules (
store/,network_status/), then Borg layer, then views layer - Add
py.typedmarker for package type information
Additional details: See #2362
Possible mentors: @m3nu
Difficulty: Medium
Length: 45 hours
Skills required: Python, Qt Linguist format, AI/LLM integration
Description:
Move translation management from Transifex to an AI-based workflow that keeps translations fully within our repository. This will reduce external dependencies, enable faster iteration on translations, and provide better context-aware translations. The project involves removing the existing Transifex integration, creating an AI translation skill that can parse Qt .ts files, generate context-aware translations, and maintain consistency across 13 supported languages.
Task outline:
- Remove Transifex configuration and Makefile targets
- Create skill to parse Qt
.tsfiles and identify untranslated/fuzzy strings - Implement translation generation with full application context (UI location, backup terminology, style guide)
- Add review/update capabilities and integrate with existing
translations-to-qmworkflow - Test translations in running application including RTL support (Arabic)
Additional details: See #2359
Possible mentors: @m3nu
Difficulty: Easy to Medium
Length: 22.5 hours
Skills required: Linux, Flatpak, D-Bus, Documentation
Description:
Systematically review, test, and document known Flatpak sandboxing issues that affect Vorta users, and identify workarounds where possible. Issues include FUSE/mounting problems, D-Bus and keyring access, filesystem access, network/DNS issues, and theme/UI problems.
Task outline:
- Review and reproduce ~15 known Flatpak-related issues on recent distros
- Document which issues are still reproducible and identify root causes (sandbox permissions vs. code issues)
- Document workarounds and test Flatseal permission overrides
- Propose manifest changes to flathub/com.borgbase.Vorta if needed
- Create user-facing documentation for Flatpak-specific troubleshooting
Additional details: See #2363
Possible mentors: @m3nu
You can also come up with own ideas to implement or choose to solve any other existing issue tagged with type:enhancement.
Discuss your ideas with your prospective mentors.
Issues tagged help wanted and good first issue
Difficulty: Hard
Length: 175 hours
Skills required: Software architecture, Python, pytest, CI/CD
Description: BorgBackup (master branch == borg2) is currently storing each chunk separately, which is simple, but bad for performance and efficiency. This needs to be changed so that packs of chunks are stored and efficiently dealt with.
Task outline:
- Pack format design
- Indexing
- Compaction
- Checking
Additional Details: https://github.com/borgbackup/borg/issues/8572
Possible mentors: @ThomasWaldmann (primary), Secondary mentor TBD
Difficulty: Medium-Hard
Length: 175 hours
Skills required: Windows, Python, Filesystem APIs, pytest, CI/CD
Description: BorgBackup is primarily POSIX-oriented backup software. While basic Windows functionality exists, significant work is needed to make it truly usable on Windows. This project focuses on improving Windows-specific features including drive letter handling, metadata support, SSH remote repositories, FUSE mounting, and CI infrastructure.
Task outline:
- Drive letter support - Properly handle Windows drive letters in paths and repository URLs (#9279, #4731)
- Windows metadata support - Implement birthtime/ctime handling (#8730), fix mode/permissions (#7191), implement real users/groups (#7192), handle inherited ACEs in ACLs (#1341)
-
SSH remote repository support - Implement and test
ssh://repository access on Windows (#7261) -
FUSE support - Investigate and implement
borg mountfunctionality on Windows using WinFsp or similar (#2316) - Test suite and CI improvements - Re-enable Windows CI (#8474), fix spurious test failures (#7616, #6195), resolve path normalization issues (#7120)
- Additional Windows fixes - Handle Ctrl-C/SIGINT properly (#7196), fix files-cache with ctime/inode (#7193), character mapping for invalid filenames (#7294)
Additional details: There are currently 24 open issues labeled "os: windows" in the Borg repository. Key tracking issues include #983 (Windows roadmap) and #4466 (Windows maintainers wanted). See all Windows issues.
Possible mentors: Primary mentor TBD, @ThomasWaldmann (backup)
Difficulty: Medium-Hard
Length: 175 hours
Skills required: Python, Cython, Algorithms, Security fundamentals, Research evaluation
Description: Evaluate and implement modern content-defined chunking algorithms (FastCDC, UltraCDC, etc.) for BorgBackup, with a focus on deduplication efficiency, throughput performance, and security against fingerprinting attacks. The final deliverable includes extracting the chunker code into a standalone borgchunk library with comprehensive tests and documentation.
Task outline:
- Research and evaluate modern CDC algorithms (FastCDC, UltraCDC, Gear, etc.) based on academic papers and existing implementations
- Benchmark candidate algorithms for deduplication ratio and throughput on representative datasets
- Implement selected chunking algorithm(s) in Cython, following the existing buzhash/buzhash64 patterns
- Integrate new chunker(s) with BorgBackup's existing interfaces and test infrastructure
- Analyze and mitigate security concerns (fingerprinting attacks, predictable chunk boundaries)
- Extract
borg.chunkersinto a standaloneborgchunkpackage with its own test suite and documentation - Document performance characteristics and provide guidance for algorithm selection
Additional details: This project builds on the recent Cython conversion of buzhash32/64 chunkers. It does not require deep knowledge of the Borg codebase but benefits from background in algorithms, cryptography, and security. Practical experimentation and paper evaluation are key components.
Possible mentors: @ThomasWaldmann (backup), primary mentor TBD
Difficulty: Easy
Length: 90 hours
Skills required: Python, Linux
Description: borgmatic is effectively a wrapper around Borg backup, providing additional features like a configuration file, database integration, etc. But borgmatic only wraps a fraction of the sub-commands that Borg provides. And for those that it does wrap, it doesn't necessarily support all command-line flags as borgmatic options. Users can always drop back down to running Borg directly for those missing sub-commands (or use the borgmatic borg action), but that doesn't provide all the conveniences of borgmatic and its configuration file.
Task outline: Implement borgmatic actions for all Borg sub-commands that are not yet implemented. For each Borg flag within those sub-commands, decide whether it makes sense to add a new borgmatic configuration option for it—or whether it would be more appropriate as a borgmatic action command-line flag. Also as part of this work, consider implementing missing flags/options on existing borgmatic actions.
Additional details: Not all Borg sub-commands make sense to wrap. For instance, Borg invokes borg serve internally, and there's likely not a good use case for running it via borgmatic. Similarly, some Borg flags like --info and --debug shouldn't be exposed directly via borgmatic configuration options or command-line flags, because borgmatic uses them implicitly (e.g. via --verbosity) without exposing them to the end-user. But at the risk of creeping scope, it would be a good idea to look through the ticket backlog when implementing this project, as there may be tickets for adding individual actions that could be implemented as part of this effort. Potential examples: #825, #610, and #345.
Difficulty: Medium
Length: 80 hours
Skills required: Python, Linux, MySQL/MariaDB
Description: Today borgmatic supports dumping MySQL/MariaDB databases directly to Borg for backup purposes and also restoring them directly from Borg. However, borgmatic does not support the MySQL/MariaDB directory format for database dumps currently.
Task outline: Implement a new directory value (or maybe tab?) for the existing MySQL/MariaDB format configuration options. When that's set, pass the relevant option (--tab=...?) to mysqldump so that database dumps are dumped into a directory instead of as a single file. Note that this will have to bypass the existing streaming to named pipe logic since a directory can't be streamed that way. Also note that there are separate MySQL and MariaDB hooks, which would both need similar updates to support this feature.
Additional details: Look at the existing PostgreSQL and SQLite hooks for examples of database hooks that support both streaming database dumps and non-streaming directory format database dumps. You can probably take a similar approach with this MySQL/MariaDB work. Also see the ticket.
Difficulty: Medium
Length: 120 hours
Skills required: Python, Linux, Docker/Podman
Description: borgmatic has a variety of hooks for dumping non-filesystem data sources like databases, but now there's also a need to dump containers or container volumes for backup.
Task outline: Implement a new borgmatic hook or multiple hooks for dumping and restoring containers or container volumes. Test against both Docker and Podman.
Additional details: See the ticket for design and implementation ideas, and check out the related linked tickets there for prior discussion on the general topic of borgmatic and container backups.
Difficulty: Medium
Length: 100 hours
Skills required: Python, Linux, KVM/libvirt
Description: borgmatic has a variety of hooks for dumping data sources like databases and filesystem snapshots. Now there's also a need to snapshot VMs for backup.
Task outline: Implement a new borgmatic hook for snapshotting KVM VM and including those snapshots in backups.
Additional details: See the ticket for design and implementation ideas. borgmatic already has three filesystem hooks (ZFS, Btrfs, and LVM) that work by snapshotting and injecting that snapshot directory into the backed up patterns, so a KVM hook could likely take a similar approach. One difference though is that the existing filesystem hooks don't implement anything for the borgmatic restore action, and it may make sense to implement restore for a KVM hook.
Also see the good first issues.
For the Borg+Borgmatic Docker image and Ansible role
Difficulty: Medium
Length: 45 hours
Skills required: Ansible, Molecule, Docker, Linux
Description: We already use Molecule to test this role, but only do a few basic validations. This task would add more validations and maybe run a local backup to make sure the role works well.
Task outline: Research how verification is done at similar projects. Then make a list of things we like to test. Then see which ones we can test in the context of a Docker test.
Additional details: See this issue for more.
Possible mentors: @m3nu, @grantbevis (backup mentor)