GNOME’s Quiet Infrastructure Move: Why the Desktop Project Is Redirecting GitHub Traffic to Its Own GitLab Instance

In a move that underscores the open-source community’s ongoing tension between convenience and sovereignty, the GNOME project has implemented automatic redirects from GitHub to its self-hosted GitLab instance. The change, which has been rolling out in recent weeks, sends a clear signal about where the venerable desktop environment project wants its development activity to live — and where it doesn’t.

The shift may seem minor on its surface: visitors who land on GNOME’s GitHub repositories are now greeted with a redirect pointing them to the corresponding project page on gitlab.gnome.org. But for a project of GNOME’s stature — one of the two dominant Linux desktop environments, used by millions worldwide and backed by a formal foundation — the decision carries significant weight for how open-source governance and infrastructure independence are evolving in 2025.

The Mechanics of the Redirect and Why It Matters

As reported by Phoronix, GNOME’s GitHub organization pages now redirect users to the project’s self-hosted GitLab instance. The implementation affects the various GNOME repositories that had maintained a presence on GitHub, even after the project formally migrated its primary development infrastructure to GitLab years ago. The GitHub mirrors had persisted as a convenience — a way for developers already embedded in GitHub’s vast user base to discover, browse, and occasionally contribute to GNOME code without creating a separate account on GNOME’s infrastructure.

That convenience is now being deliberately wound down. The redirect mechanism ensures that anyone arriving at a GNOME GitHub URL is automatically sent to the authoritative source on GNOME’s own GitLab. This eliminates the ambiguity that had existed for years about which platform represented the canonical home for GNOME development. Pull requests, issues, and other collaboration features on GitHub were already non-functional for most GNOME projects, but the mere existence of the repositories there created confusion among newer contributors about where to direct their efforts.

A History of Migration: GNOME’s Long Road Away from GitHub

GNOME’s relationship with GitLab dates back to 2018, when the project completed a significant migration from its legacy Bugzilla-based infrastructure and older Git hosting to a self-managed GitLab Community Edition instance. At the time, the decision was driven by practical concerns: GitLab offered modern code review workflows, integrated CI/CD pipelines, and issue tracking that could be customized to GNOME’s specific needs. Importantly, because GNOME chose to self-host GitLab CE rather than use GitLab.com’s hosted service, the project retained full control over its data, uptime, and policies.

The decision to self-host was not accidental. GNOME, as a project governed by the GNOME Foundation, has long emphasized software freedom and user autonomy. Relying on a proprietary platform like GitHub — owned by Microsoft since its 2018 acquisition — sat uncomfortably with many in the community. While GitHub’s dominance in open-source hosting is undeniable, with over 100 million developers on the platform, GNOME’s leadership viewed infrastructure independence as a matter of principle aligned with the project’s free software values.

Microsoft’s Shadow and the Broader Open-Source Sovereignty Debate

Microsoft’s acquisition of GitHub in 2018 for $7.5 billion sent shockwaves through the open-source world. While many projects remained on the platform — and GitHub’s user base has only grown since — a notable subset of free software projects began exploring alternatives. The GNOME migration to self-hosted GitLab was one of the most prominent examples, but it was far from alone. The KDE project, GNOME’s counterpart in the Linux desktop space, also uses a self-hosted GitLab instance at invent.kde.org.

The concern is not merely philosophical. When a project’s development infrastructure resides on a third-party commercial platform, that platform’s terms of service, content policies, and business decisions can directly affect the project. GitHub has faced criticism over the years for actions including restricting access for developers in sanctioned countries, implementing AI-powered code suggestion tools trained on open-source repositories without explicit consent (GitHub Copilot), and making policy changes that affect how repositories are managed. For a foundation-governed project like GNOME, maintaining independence from such external pressures is a governance priority.

What This Means for Contributors and the Wider Community

For existing GNOME contributors, the redirect changes little in practical terms. Development has been centered on gitlab.gnome.org for years, and the community’s workflows — merge requests, CI pipelines, issue tracking — all operate within that infrastructure. The redirect primarily affects newcomers and casual browsers who might have discovered GNOME code through GitHub search results or direct links shared on forums, social media, or documentation that hadn’t been updated.

There is a trade-off here that GNOME’s leadership has clearly weighed and accepted. GitHub’s massive user base provides a built-in discovery mechanism. When a project maintains active repositories on GitHub, it benefits from the platform’s social features: stars, forks, contributor graphs, and the simple fact that millions of developers check GitHub daily. By redirecting away from GitHub, GNOME is accepting a potential reduction in casual discovery in exchange for consolidating its community on infrastructure it controls. The bet is that serious contributors will follow the redirect, while the loss of drive-by GitHub engagement is an acceptable cost.

The Technical Implementation and Its Implications

The redirect mechanism itself is straightforward — HTTP redirects from GitHub repository URLs to their gitlab.gnome.org equivalents. GitHub allows organization owners to configure repository descriptions and websites, and the GNOME team has used these features in conjunction with other mechanisms to guide users to the correct location. The approach is clean and non-disruptive: no content is lost, and users are simply pointed to where the real work happens.

This approach also has implications for how search engines index GNOME’s code. Over time, as GitHub pages return redirects rather than content, search engine rankings should shift toward the GitLab-hosted pages. This is a subtle but meaningful change — it means that when a developer searches for a GNOME module or library, the top result will increasingly point to GNOME’s own infrastructure rather than to a Microsoft-owned platform. For a project that champions software freedom, having its own infrastructure rank prominently in search results is a form of digital self-determination.

A Signal to Other Open-Source Projects

GNOME’s move may embolden other large open-source projects to reconsider their own GitHub dependencies. While self-hosting a GitLab instance requires resources — server infrastructure, maintenance personnel, and ongoing administration — the costs have decreased as cloud hosting has become more affordable and GitLab CE has matured. For projects with established foundations or corporate backing, the barrier to self-hosting is lower than ever.

The Linux kernel itself has never used GitHub as its primary development platform, relying instead on mailing lists and the kernel.org Git infrastructure. Other major projects like Debian, FreeBSD, and the Apache Software Foundation maintain their own infrastructure as well. GNOME’s redirect move places it more firmly in this tradition of infrastructure independence, drawing a sharper line between projects that treat GitHub as a convenience mirror and those that treat it as their primary home.

The Tension Between Pragmatism and Principle

Not everyone in the open-source community agrees with moves like GNOME’s. Critics argue that fragmenting development across multiple platforms increases friction for contributors, particularly those who are new to open source and may only have a GitHub account. Creating an account on yet another platform, learning its specific workflows, and managing multiple identities across services can be a deterrent. In an era when open-source projects are competing for contributor attention, making participation even slightly harder can have real consequences for project health.

Proponents counter that the friction is minimal — creating a GitLab account takes minutes — and that the principle of infrastructure sovereignty outweighs the inconvenience. They point to the risks of centralization: if GitHub were to change its policies, suffer a prolonged outage, or make business decisions that conflicted with a project’s values, projects that had consolidated entirely on the platform would have limited recourse. By maintaining independent infrastructure, GNOME ensures that its development can continue regardless of what happens to any single commercial platform.

GNOME’s redirect from GitHub to its self-hosted GitLab is, in many ways, the completion of a process that began seven years ago. It is a statement that the project’s home is its own — not a page on someone else’s platform. Whether other major open-source projects follow suit will depend on their own calculations of cost, convenience, and conviction. But GNOME has made its position clear, and the redirect is now live for all to see.