Changing GNOME technical governance?

The GNOME project, which recently celebrated its 28th birthday, has never had a formal technical governance; progress has been driven by individuals and groups that advocated for—and worked toward—a particular goal in an ad hoc fashion. Longtime GNOME contributor Emmanuele Bassi would like to see that change by adding cross-project teams and a steering committee for the project; to that end, he gave a talk (YouTube video) at GUADEC 2025 in late July on his idea to establish some technical governance for the project. He also put together a blog post with his notes from the talk. The audience reaction was favorable, so he has followed up on the GNOME discussion forum with an RFC on governance to try to move the effort along.

In the RFC, Bassi described the motivation for the change. He laid out the current situation, which has changed little "from the 'rag tag band of misfits' of the halcyon days of the project's youth". Governance is highly informal, which leads to difficulties with the project's overall direction. "Decision-making is an exercise of sisyphean patience, where people must push the boulder of the community uphill only to watch it roll back down with every cycle."

He quoted from the GNOME Project Handbook; the governance section describes how decisions are made:

Most decisions in GNOME are made informally, by individuals working in collaboration with one another. This informal way of making decisions applies to who works on what, which features are supported, and which technical and user experience designs are implemented.

His goal is to switch away from the "informal" and "individual" parts of that and instead to "create formal, shared structures to increase accountability while diffusing personal responsibility". GNOME has a set of existing teams, but they are not aligned to the components and applications that make up the project. GNOME is, effectively, a collective of individual projects, each of which is maintained by a single person or, more rarely, a small group, with no mechanism for those projects to collaborate:

There is no formal venue for discussing changes across multiple projects. There is no formal process to propose changes across multiple projects. Each project is its own special, unique snowflake when it comes to interaction with other projects, both as dependencies and reverse dependency.

One potentially troubling problem is that there is no documented way to change the technical-governance situation. The GNOME Foundation board is not part of the technical governance of the project; it is focused on the foundation itself, overall strategic goals, financial oversight, and the like. Bassi is proposing to form four new teams (platform, OS, core apps, and tooling) that would join with four existing teams (design, release, translation, and infrastructure) to form a steering committee with a single representative from each team. The committee would be responsible for setting the "overall direction and vision" of the project, its priorities, and generally being the ultimate decision-making authority for GNOME, as well as for the teams and sub-projects. Though it is not specified, some kind of project-wide referendum would presumably be needed to enact this, or some other, governance structure.

The teams would be responsible for deciding on whether to accept features and other changes within the projects in their domain. They would communicate in public forums, so that others in the project can have a view into their plans. The teams would form the basis for more collaborative, cross-project planning and development, while the steering committee would oversee all of the teams and the GNOME project as a whole.

The RFC has more detail about the makeup and responsibilities of each team, the structure and duties of the steering committee, term limits, and more. But, at the core of his vision, and, seemingly, his unhappiness with the way that GNOME works currently, is the maintainer model for GNOME projects. The RFC does not go into as much detail, though it clearly looks toward replacing project maintainers with cross-project teams, but the blog post says more:

Individual maintainers should not exist in a complex project—for both the project's and the contributors' sake. They are inefficiency made manifest, a bottleneck, a point of contention in a distributed environment like GNOME. Luckily for us, we almost made them entirely redundant already! Thanks to the release service and CI pipelines, we don't need a person spinning up a release archive and uploading it into a file server. We just need somebody to tag the source code repository, and anybody with the right permissions could do that.

We need people to review contributions; we need people to write release notes; we need people to triage the issue tracker; we need people to contribute features and bug fixes. None of those tasks require the "maintainer" role.

There have only been a few replies to the RFC post, all generally favorable, but there are questions about getting rid of the maintainer role. Adrian Vovk thought that there may not really be enough people in GNOME to fill the roles that are being described. He wondered if the end result would be to continue the maintainer role, though perhaps without the name:

Overall, my concern is that we don't have enough people for this bureaucratic process to shift us away from the status quo. It seems to me like we'll still have de-facto "maintainers" who have the institutional knowledge over their corner of the stack. Not even necessarily because folks want to hoard institutional knowledge, but simply because we don't have enough people interested in involving themselves. Someone needs to keep triaging issues/reviewing MRs/fixing bugs/etc, and it's going to be the people who know most about a specific codebase. I fear the end result will be teams that have members working on unrelated projects, or grouped into subteams that consist essentially of individuals.

[...] I suppose a valid course of action is just to accept that this is what it is, and that the people with de-facto power today (by being a maintainer of a project) will have formal power when we put these structures into place (by being the sole interested party for a project on the relevant team). But I'm not certain that this is all you intend to achieve.

Bassi pointed out that the "Drawbacks" section of the RFC mentioned the lack-of-people problem, but that the aim is to "bring in new contributors that have so far resisted the role of 'maintainer'". But Michael Catanzaro suggested that removing maintainers was "unrealistic":

GNOME is a big collection of small projects, and teams with a large scope and perspective are just not a better way of working on small projects. I see only two possible ways that ends: (a) we'll continue to have de facto maintainers and everything operates same as before, except without any way to formally indicate who the maintainer is, which is not an improvement; or (b) we take "no maintainers" seriously until chaos ensues and eventually we change our minds and bring back maintainers.

He noted that the RFC did not directly call for removing maintainers and he saw no problem with forming teams as an experiment. Creating a steering committee to relieve the current release and design teams from serving in that role is "a clear improvement", he said. Bassi seemed to bristle a bit about the concerns expressed by Vovk and Catanzaro with regard to the need for maintainers. Bassi wondered if it was because they were too strongly focused on the recognition aspects of being the maintainer of a project. The attention on the maintainers question seemed to irritate him some, as seen in his reply to another generally favorable response from Allan Day:

Ideally, instead of people hyperfocusing on whether or not I'm trying to remove the role of maintainers like I'm proposing the installation of guillotines in the middle of Place de la Revolution, we'd see people proposing additional teams and sub-teams.

Bassi, Catanzaro, and Vovk appeared to be talking past each other to a certain extent. Both Catanzaro and Vovk were largely in favor of the ideas, but expressed concern that there were simply not enough people to fill the teams, which would inevitably mean that some interested developers would be acting as maintainers anyway. Catanzaro explicitly rejected the notion that he was focused on recognition and agreed with Bassi that the maintainer model is flawed: "The fact that maintainers have final say on everything is a defect in our current development model, and I appreciate that you're trying to fix that." But there is a need for some person or entity to have responsibility for ensuring that the critical work of maintaining a project is actually done:

So my question is: how will high level teams decide who will read the issue tracker, respond to merge requests, flag security issues for GNOME Security, etc? Components cannot be overlooked. If you join the Platform team, then will you dutifully help with triaging libxslt issue reports? I rather doubt it, but the team will need to ensure that somebody does so. Maintainership seems like the best way to define this responsibility, but as long as each high level team truly has a plan to take responsibility for each of the dozens of components within its extremely broad purview, I suppose that's sufficient.

That is as far as the conversation has gotten at the time of this writing; we will have to wait and see where it goes. The goals of the proposal seem popular, while some of the details will still need to be worked out—all par for the course in a free-software-governance discussion. What is unclear, however, is how to actually enact the change, since there is no steering committee or other overarching technical-governance decision-making body. One suspects that if the proposal (or some, yet-to-be-revealed alternative) gains steam, GNOME will figure that out in due course.

We have seen other projects undertake this kind of change before, notably Python; Bassi has clearly looked into governance, and changes to it, in other free-software communities as part of coming up with his proposal. Someday, other projects may also look to GNOME for guidance, when they reach a point where change is needed. It is yet another benefit of building our communities in the open.