GNOME Project ideas for Google Summer of Code 2025
For general information on how to get involved with our project and participate in Google Summer of Code with GNOME visit gsoc.gnome.org
This is the list of project ideas that the GNOME community is interested in mentoring. GSoC interns can also propose their very own project ideas. If you are interested in proposing a project idea, please file an issue in our Internship Project Ideas repository.
GSoC contributors proposing something original must engage with the community strongly before or during the application period to get feedback and guidance to improve the proposal.
Project list
Currently, Sysprof works by recording stack traces from the Linux Perf subsystem using perf_event_open(). It also can record various system statistics using data from /proc such as CPU, memory, networking, and disk statistics.
eBPF provides an existing new direction for tooling of this nature by uploading small programs into the kernel to extract the data you want without the parsing overhead. That data can be delivered to an application like Sysprof for recording into the capture files.
This internship would involve creating the tooling within libsysprof to setup new eBPF programs by compiling, linking, and uploading them into the kernel along with necessary components to get data from the kernel back to Sysprof.
This would then be used to port some collectors such as CPU or memory trackers to use eBPF instead of /proc files.
Requirements
- Knowledge of C, preferably using GLib/GObject but that can be learned
- Minimal experience performance profiling software
- Minimal experience with the Linux kernel
- Learning how eBPF works and how to integrate that with the kernel can be learned on the job
Communication
Chat, email, video chat. Christian Hergert @chergert or hergertme on IRC/Matrix or @chergert at gnome.org
Difficulty: Hard
Mentor availability: ~350 hours
More information
https://gitlab.gnome.org/Teams/Engagement/internship-project-ideas/-/issues/51
This project will mostly require work on Papers' libraries: ppsview and ppsdocument. The former contains an abstraction (PpsJob) to run (potentially slow) backend code in threads. The later is basically a common abstraction over different backends: PDF, DJVU, Tiff, etc. The idea is to create a component that will start a new process per-document (similar to web-browsers having one process per tab!). That side-car process will take care of all the calls to the backends (so embedded in ppsdocument), and be managed by PpsJobs. Further details are available in https://gitlab.gnome.org/GNOME/Incubator/papers/-/issues/104
The idea for the GSoC will be for the Intern to prototype a solution to this problem, and investigate potential solutions and foot-guns. The intern will need quite a good knowledge on C, and have motivation to do some investigate work (e.g: look into solutions implemented by other projects like WebKit). I don't expect a full implementation or solution, even if that would be welcomed. A failed attempt at this might already gives us extremely valuable input.
This will benefit Papers as the future Document Viewer in GNOME in two ways:
- By isolating documents from each other, we improve the overall security situation. Even CVEs that might allow somebody to gain access to execution code from rendering a PDF would not have access to the other documents.
- By isolating documents from the UI we improve the resilience of Papers. A document crashing during rendering (for which CVEs happen regularly (last one CVE-2024-6239) will not bring down with itself the complete application. This has been so far the main blocker to implement the Document Viewer tabbed view, which has been a feature request for Evince since 2005
Requirements
- Good skill and experience in the C programming language. Both be able to write and read it
- The ability to investigate previous approaches to solve the same issue. We will guide the Intern on where to look
- Motivation to try different approaches. We know a big part of this project will be checking the feasibility of different solutions
Communication
Our preferred communication channel is Matrix (https://matrix.to/#/#papers:gnome.org), but we will also do video-calls to get onboarded and if deemed useful and necessary for the mentoring process
Difficulty: Hard
Mentor availability: ~350 hours
More information
https://gitlab.gnome.org/Teams/Engagement/internship-project-ideas/-/issues/58
GNOME Disks is a graphical interface for the UDisks system service that allows to view, modify, and configure disks.
The project also provides a binary for disk image mounting and a session service for disk health notifications.
It's latest stable release still uses GTK 3 but on the development branch the port to GTK 4 is almost done.
The development branch also includes a Rust rewrite of the disk image mounting helper that introduces a proper UI for disk image actions from the file browser, including support for encrypted container files. This uses a newly developed UDisks Rust client library.
The GNOME Disks code base is mainly interacting with UDisks via D-Bus, and is suffering from callback spaghetti. Combined with the domain-specific knowledge required, the code base is not very accessible for new developers, and thus areas like the disk health alert service are not often touched. With a Rust rewrite we can leverage language support for asynchronous functions to replace the use of callbacks. The good tooling, strong compile time guarantees and support for tests in Rust is also great for new contributors.
Thus, the goal of this proposed project is to rewrite the disk health alert service and the disk image create/restore dialogs of GNOME Disks in Rust. The disk health notification service is a small separate binary that can be worked on without touching the rest of GNOME Disks. The disk image create/restore dialogs of GNOME Disks share functionality with the disk image mounting helper which currently spawns GNOME Disks to write images to disks. When using C-Rust FFI we can have one new implementation in Rust and stop spawning a new GNOME Disks window for this operation. Porting the dialogs one by one is also a great way to chunk up the work so that the app stays in a working state and one can benefit from the start even if the whole app won't be ported soon.
It's important to get the basics right for FFI and establishing a pattern that can be followed afterwards when other dialogs are ported.
Last year's ground work with the image mounting binary already showed that there are significant investments needed to lay the foundations and that new issues are popping up on the way. A draft MR for porting the dialog demonstrates that the FFI approach can work but requires more work on the dialogs itself and related areas to become ready. The results are very promising, though, and we want to continue this direction. However, this effort requires special attention. An internship can provide this focused environment for both contributors and maintainers.
Porting the disk health notification binary and the disk image create/restore dialogs and calling them from the image mounting binary involves many subtasks. The udisks-rs library needs to be worked on to support all needed features, the FFI and interaction with UDisks job objects needs to be figured out, the build system needs to be worked on, the disk image compression handling should become more generic on the way, unit tests should be introduced when useful to check properties of the ported code and to help others when touching the code in the future.
The scoping as a 'large' internship project already includes the fact that a draft MR is available for one dialog (If we get very lucky and have remaining time, we can look into stretch goals, such as, porting other dialogs, supporting more disk image compression formats, compressing created disk images, or letting the window of the disk image mounting binary to stay open and update its state).
Requirements
- Good knowledge of C and Rust on Linux, Git, Meson, the GNOME Disks functionality, the UDisks functionality (in particular the UDisks Rust client library), and Gtk/GLib FFI. Certain specifics of course can be figured out along the way.
- Being comfortable to work independently with async communication. Taking ownership of that part of the project by identifying related work items and possible solutions.
- This is not an entry-level project for GNOME, Linux, Rust, and FOSS collaboration.
Communication
Our preferred communication channel is Matrix but we will also do video-calls and emails. kailueke@riseup.net, @pothos:matrix.org
Difficulty: Hard
Mentor availability: ~350 hours
More information
https://gitlab.gnome.org/Teams/Engagement/internship-project-ideas/-/issues/59