2026 Board Candidate: Adrian Vovk

Hi everyone!

I’m writing to announce that I’m running for the GNOME Foundation’s Board of Directors!

Background

I’ve been around the GNOME community for a few years at this point, so I’ve crossed paths with many of you. Still, I’d love to give a small reintroduction and my background!

Since 2018, I was working on an independent image-based Linux distribution called carbonOS (blog post with some of the pre-history, for the curious). I can summarize the goal as “Building an OS that makes the Linux desktop usable for non-enthusiasts”. By 2023, the project had in many ways converged with GNOME’s development/QA/testing platform GNOME OS, and so I decided to move my efforts upstream. These days I am working on GNOME OS and systemd with the goal to make GNOME OS a general-purpose OS.

I was one of the contractors during the Sovereign Tech Fund’s (STF) ~1 million Euro investment into GNOME during 2023/2024. I worked on building out GNOME’s support for systemd-homed, helped out with Codethink’s systemd-sysupdate work, and started work on a new installer for GNOME OS. Later on in the project I moved into more of an administrative role, where I worked to help navigate the issues of the time and wind the project down as the budget ran out. You can read our final report for more context.

After the GNOME STF project, I got hired to Red Hat’s desktop team and have been working there since. I recently gave a talk about some of the work I’ve done. These days I’m working on save/restore support, and have also gotten involved with Flatpak and xdg-desktop-portal alongside Sebastian, including Flatpak Next. Day-to-day, I maintain gnome-session and co-maintain GDM.

Outside of my development work, I’m heavily involved in organizing STF projects. After the first STF project wound down, Tobias and I put together an STF application for systemd. We were approved, and the STF invested ~400 thousand EUR for 2025/2026. I am now managing this project in both a technical and organizational capacity. My responsibilities include: writing reports to get invoices paid, maintaining the relationship between the team and our fiscal host (Software in the Public Interest) and the STF, meeting with contractors to unblock them both in technical questions and other matters, and much more. More recently, I also helped organize another STF project for 2026/2027, which was approved but has not yet been publicly announced.

Finally, I’ve also been involved in the efforts to stand up Modal, a collective that exists to strategically fund work on the Linux desktop stack. The goal is to fund upstream work such that we build a viable competitor to the proprietary operating systems, including the mobile ones. There are a few great posts on the blog that explain the aims of Modal in more detail.

Priorities

If I am elected director, I would focus my energies within that role on the following.

Supporting the Current Trajectory

The GNOME Foundation is currently on a very positive trajectory. Its financial health has improved significantly, procedures are being refined or established, it has become more transparent, and it is now exploring ways to directly fund the community (via programs like the Fellowship). The Foundation exists to serve the project and the community, and the changes being made improve its ability to do so. There is, however, still plenty of work that needs to be done, and as a director I will vote for continuing this revamp of the way the GNOME Foundation operates.

Grant Work

During the first STF project we learned the dangers of over-loading the Foundation’s organizational capacity. However, as the Foundation re-architects itself, I believe that it may soon become ready to take on coordinated grant work again. Meanwhile, due to the current global circumstances governments are funding FOSS projects. We should not miss the opportunity. As soon as the Foundation becomes ready, we should again prepare an application for the STF, though perhaps at a smaller scale than the first one.

Another concrete step we can take is to execute on an idea I’ve previously work-shopped w/ Steven: the Foundation should start keeping track of community members’ availability for work. This knowledge would greatly help GNOME and related communities plan for such grant projects. In my experience, the number one bottleneck for planning grant work is finding the people we can hire to do it!

Flathub

The Foundation needs to bring Flathub’s payments system over the finish line. Getting our community of app developers paid is crucial for the continued growth of the Linux App ecosystem. We also need to find ways to make Flathub itself more sustainable, especially because the continued growth of the ecosystem (and ongoing wave of AI slop submissions) is putting too much pressure on our limited sysadmin resources and volunteer app review team!

Baseline AI policy

GNOME currently doesn’t have any kind of AI policy in place, and that is a problem. Individual projects and maintainers may have policies that they’ve been using, but for projects that haven’t declared anything there’s nothing to establish some ground rules. The Foundation can establish such a fallback by establishing AI guidelines for the GNOME GitLab infrastructure, or alternatively by changing the definition of “Official GNOME Software” to exclude slop. Either way, we should be banning AI slop, assigning full responsibility for all code to the individual contributors, and allowing individual maintainers to opt into stronger AI policies should they wish to do so.

My Details

15 Likes

I strongly second Adrian’s candidacy.

I had the pleasure of speaking with a number of hackers back in April and May of 2025 but Adrian selflessly volunteered FIVE HOURS of his time – a record, in that period of getting to know the contributor community. Over the course of that conversation, many seeds of what would become real deliverables for the Foundation were planted. Looking back over my May 15th notes, I see:

  • how to structure the Fellowship (back when it was still under the umbrella of the old Developer Initiative label)
  • other methods of fundraising, with the intention of getting more money in the hands of hackers
  • tools for better transparency at the Foundation
  • strategies for improving governance and policies
  • how to improve elections
  • hardware partnerships with vendors
  • GNOME OS for the masses (obviously)
  • how to effectively get the Foundation more involved in the project, but do so in a way that keeps the project’s technical direction independent

Adrian was also deeply familiar with the ways non-enthusiast users actually engage with GNOME and the desktop Linux news cycle and what it means for marketing.

I’m sure most Foundation members will have similar stories to tell. Adrian is a connector, bridging the interests of multiple parties to ensure code is pushed upstream. He’s a vocal and active community member but consistently manages to focus on core issues, ensuring voices aren’t left unheard. He puts in the work. I’ve seen him raise governance concerns, negotiate the details of upstream APIs, propose real solutions to long-standing problems, and create new networks of contributors.

I believe Adrian will make a strong director.

4 Likes

I think I’m past the required date, but I strongly second Adrian’s candidacy. He has been deeply involved in important GNOME developments and importantly has always been kind and level-headed in my interactions.

2 Likes

What do you see as AI Slop? Are there any existing projects that would fail these rules you are envisioning if they were implemented today? Has AI Slop been a problem for any GNOME projects? And would individual maintainers also be able to instate weaker AI policies? What would happen to projects or contributors that would not follow this policy, would individuals be banned from contributing to the entire GNOME project or just that module?

I’d define slop as “any AI output that the submitter hasn’t sufficiently reviewed and edited that they’d be willing to take 100% responsibility for everything said in the output, like they would for a contribution they wrote entirely on their own”

There are plenty of people that slop-coded GNOME apps and published them to Flathub (like, we have a bunch of AI-generated music player apps for some reason). But within GNOME’s infrastructure, no I don’t have an example that comes immediately to mind

Yep. Slop issues and MRs are not uncommon, and burn through maintainer time/energy. This is has been especially difficult for our security folks, Flathub folks, Circle folks, etc

I think that defeats the purpose of a baseline policy.

If an individual maintainer wants to set an LLM free to run wild on some infrastructure, why does it have to be GNOME’s community infrastructure maintained for the commons? There’s nothing stopping someone from uploading their LLM’s output spew to GitHub.

Stronger rules are fine in my books, though

I don’t have this fully fleshed out in my mind. I think the primary benefit would be to just immediately close things that look like slop anywhere on GNOME’s infra. I think it’s probably fair that someone who repeatedly breaks the rules, and abuses GNOME’s infra, should get banned from either the project or all of infra (but I don’t think insta-ban on first offense is a good idea).

4 Likes

Your vision for how to handle AI seems sound to me. Thank you for answering my many questions.

2 Likes

Based on all of the times I’ve interacted with Adrian, I feel like he is a very strong candidate for the board of directors. He is visibly involved in much-needed efforts within the GNOME project, systemd, and freedesktop.org, and has always seemed rational and pragmatic.

3 Likes