GNOME Foundation Names Its First Two Fellows to Tackle Governance, Rust Libraries, and the Files App

The GNOME Foundation announced today the first two participants in the fellowship program it first revealed back in March. Peter Eisenmann and Sophie Herold, both longtime contributors rather than newcomers, will formally start their funded work in July and spend the following twelve months on the unglamorous infrastructure that keeps a desktop project alive over the long haul.

The fellowship exists to solve a specific problem that affects almost every large open-source project: the work that matters most for sustainability is often the work nobody gets paid to do. Feature commits get attention and corporate sponsorship. Governance processes, library maintenance, and the slow modernization of aging application code tend to languish because they are diffuse, unsexy, and hard to attribute to a single sponsor's roadmap. Funding two experienced contributors to focus on exactly that category of work for a full year is a direct attempt to close that gap.

{{IMAGE:2}}

What Sophie Herold Will Work On

Herold's mandate has two distinct halves. The first is establishing a new RFC (Request for Comments) process for GNOME, which the Foundation frames as a project-level governance improvement. If you have followed how other large ecosystems operate, this pattern will look familiar. Rust has its RFC repository, Python has PEPs, and Kubernetes has KEPs. The common thread is a written, reviewable, archived record of why a significant decision was made, who weighed in, and what alternatives were rejected.

GNOME has historically made architectural decisions through a mix of mailing list threads, GitLab discussions, hackfests, and maintainer consensus. That works when a project is small enough that the relevant people all know each other. It scales poorly. An RFC process gives contributors a predictable path for proposing changes that cross module boundaries, and it gives the wider community a durable explanation they can point back to years later. For a desktop that ships to millions of Linux users across dozens of distributions, that institutional memory has real value.

The second half of Herold's work is library maintainability and security through Rust adoption. This continues a direction GNOME has been moving for several years. Memory-safety bugs in C libraries that sit at the heart of the desktop are a recurring source of security advisories, and rewriting or wrapping those components in Rust eliminates entire classes of vulnerabilities by construction. Herold is well positioned for this, having worked extensively on image-handling code, which is historically one of the most dangerous attack surfaces on any system because it parses untrusted data from arbitrary files.

What Peter Eisenmann Will Work On

Eisenmann's focus is the Files app, known to most users as Nautilus. The brief covers three areas: thumbnailing, user directory localization, and adopting modern GNOME platform conventions.

Thumbnailing sounds trivial until you run a file manager against a directory holding tens of thousands of photos, RAW files, or video clips on spinning rust or a slow network mount. The thumbnail pipeline has to decode media, generate preview images at the right resolution, cache them so the work is not repeated, and do all of this without freezing the UI or hammering the disk. Done badly, it produces stutter, runaway memory use, and stale caches. Done well, it is invisible. Modernizing this pipeline is exactly the kind of deep, infrastructural work that benefits everyone but rarely fits neatly into a feature release.

User directory localization addresses how Files handles the standard XDG directories like Documents, Downloads, and Pictures across different system languages, a perennial source of subtle bugs when a user switches locales or runs a mixed-language environment. The third item, aligning Nautilus with modern GNOME platform conventions, points toward consistency with the GTK4 and libadwaita design and API patterns the rest of the desktop has been adopting.

Why a Twelve-Month Horizon Matters

The length of the commitment is the most interesting design choice here. A one-year funded position is long enough to take on work that cannot be finished in a weekend hackathon or a single release cycle. Governance processes need iteration and buy-in. Rust migrations of core libraries need careful API design and review. A file manager overhaul touches caching, threading, and platform conventions that ripple outward into other applications.

This is a different model from bounties or short contracts, which tend to incentivize quick, self-contained fixes. By funding sustained effort from people who already understand the codebase and the community, the Foundation is betting on continuity over throughput. Both Fellows are existing maintainers, so there is no ramp-up cost and no risk of a drive-by contribution that the regular maintainers then have to support indefinitely.

The practical payoff for end users will not arrive in July. It will show up gradually over the next year and beyond: fewer memory-safety advisories in the libraries underpinning the desktop, a file manager that behaves better under heavy directory loads, and a governance structure that makes the project easier to reason about as it grows. For anyone running GNOME on a daily-driver workstation or a homelab management box, those are the kinds of improvements you only notice when they are missing.

Full details on the scope of each fellowship are available through the GNOME Foundation blog, and the broader project work can be followed on the GNOME GitLab instance.