Should Nix transition away from GitHub to a self-hosted git forge?

[nyabinary]

Question

Do you believe Nix should move away from GitHub and instead host its independent Git forge? If so, what are the benefits and challenges of such a transition, and how would you approach this shift if it were to happen?

Candidates I'd like to get an answer from

No response

Reminder of the Q&A rules

Please adhere to the Q&A guidelines and rules

[cafkafk]

TL;DR:

• Yes, but carefully.
• We can start that transition now.
• We should become forge agnostic to ease future transitions.
• GitHub is still hugely important to growing new contributors, we can't totally abandon it yet.

We absolutely should move away from GitHub, not just because it's a proprietary platform, gating important features behind paywalls, but also because being proprietary means the platforms limitations are only fixable by Github, and they rarely listen. Also, the longevity of the project is at stake, should GitHub enshitiffication continue further. There is no world in which we consider GitHub a permanent residency, and we know from issues such as nixpkgs mass pings that we could have much to gain by having more control over the actual code. Further, control over user accounts would make increasing bus factor on projects a lot easier, since owning the forge would allow us to have a much deeper control over permissions.

What we can't forget is the benefits GitHub offers, those mainly being network effect. I don't think it would be wise to move nixpkgs off GitHub currently, as GitHub, being the default forge offers us access to a lot of new contributors. While that may not always be the case, currently, I think the tradeoff, specifically for nixpkgs, speaks for keeping it on GitHub... for the time being.

However, many projects are ready to be transferred to a self hosted forgejo instance. Whether that's Nix, the RFCs repository, the nixos-homepage, any of these wouldn't suffer from the same traffic loss as nixpkgs would. I think it would be reasonable to consider setting up forgejo infrastructure soon, and moving some of these over, perhaps keeping mirrors available on GitHub for discoverability.

Further, it's important that we do not rely too heavily on GitHub platform features, but ensure our workflows are as forge agnostic as possible, specially in the case that a sudden GitHub update or policy change would make using the platform no longer an option. This isn't likely to happen immediately, I think this platform will likely first be truly unusable in the span of decades, but we must be aware that at any moment, GitHub could make changes that make it unusable for official NixOS projects, and we must be prepared in case that ever happens.

[mschwaig]

No, I don't think we should move away from GitHub. It sounds like a quite a disruptive change which takes a lot of effort to implement, to gain some things and loose some things. Let's keep our eyes and ears open instead. I would be in favor of putting some willing enthusiasts in charge of making a 'just in case' plan to move somewhere else instead.

[tomberek]

No. While conceptually compelling, the benefits of a well-known platform and other more pressing concerns lead me to conclude this is not the right priority at the moment.

That being said, I would not oppose an effort to explore the benefits and practicality of a self-hosted forge. Trying out new ideas and preventing lock-in is expressly part of our established values.

[getchoo]

No.

However, we should have plans in place in the event of GitHub no longer being a sustainable or fitting home for our project -- or if support grows for a transition in the majority of the community

[lovesegfault]

No.

I do not think the benefits outweigh the downsides currently, mostly because of the visibility, engagement, and contributions we'd lose.

I do, however, think we should have a plan for what we'll do in the event the situation changes, and we find that moving out of GitHub is worth it. Personally, I'm partial to GitLab since it's the de-facto "other standard."

[Scrumplex]

No. Being on GitHub benefits NixOS massively, because of discoverability, tooling and ease of use.

If you consider that people nowadays learn how to use GitHub before they learn Git (if at all), I think we would lose a large pool of potential contributors by switching to a different codeforge. I personally host my own projects on Codeberg, but with the expectation that those projects will not see much foot traffic.

In a project I was involved in previously (Prism Launcher) this question also came up. Discoverability and GitHub Actions (and its public runners) were the primary pain points there. In the case of NixOS/nixpkgs, I think actions runners are not too important, but discoverability and visibility definitely are.

This would also present a chicken-and-egg problem. Many Nix tools are made with GitHub in mind and moving projects away from GitHub would mean we would lose some tooling temporarily until they get adapted to the new codeforge.

[numinit]

For now, no. To quote Pieter Hintjens:

I'm sure one day some large firm will buy GitHub and break it, and another platform will rise in its place. Until then, Github serves up a near-perfect set of minimal, fast, simple tools.

It's definitely within the purview of the Nix values to experiment, though! Lock-in is a shame, but we should go to where most of our contributors are.

[nyabinary]

Yes.

Overall, I agree with Cafkafk's approach: gradually transitioning away from GitHub makes sense for the Nix community. I have concerns about GitHub’s proprietary nature and feel that reducing our reliance on such platforms would better align with our values. While I respect GitHub's role in fostering our growth, Microsoft's control raises long-term concerns. Moving to a self-hosted Git forge, like Forgejo or GitLab, would offer us more granular control and transparency. However, maintaining forge-agnostic tooling is important to ensure flexibility for any future transitions we may face.

[phaer]

tl;dr: Short-term no, long-term probably yes; should explore

I think a migration as such would currently provide a questionable cost/benefit ratio at best.
On the other hand we should strive to minimize our dependency on GitHub in any new features and
processes and consider alternative solutions where necessary to avoid further vendor lock-in.

The strongest abstract argument against Github being Independence/Sovereignity: GitHub being a proprietary service means we have no influence over
its features and policies while both of them decisively shape how we collaborate on this project.
The strongest argument pro is that we gain lots of infrastructure. To maintain that kind of infrastructure would require resources that could be used better in our existing infrastructure (i.e. cache, ofborg, etc) or work on nix and nixpkgs itself.

Being on Github means that Microsofts has the final say in:

• Who is able to contribute to nixpkgs (as you de facto need an account).

  On the other hand we rarely have to deal with things such as spam control (at least compared to matrix and so), and we gain an OpenID provider with 2fa for several thousand people for free. This is no small feat to maintain properly in itself.

• How we collaborate - it's a platform decision whether everyone can mistakenly ping 3k people by changing a target branch.

  On the other hand it's the tool-set that everyone knows. Like it or not, GitHub is the WordPress of code forges:
  Most experienced users will strongly dislike some of its design decisions, but almost everyone either knows how
  to use it or can quickly learn it with the help of endless good resources online.

• and it's a single point of failure; hard-coded somewhere almost anywhere in the ecosystem. If GitHub goes down, much of our project comes to a halt, you have neither issues nor pull requests available nor can you update your sources and we have no real influence on when it's back up.

  On the other hand it has a pretty okay record on uptime and it's not clear how much better we could do with a self-hosted git forge in the long run. We also don't need to care much about ddos protection or so with GitHub. And we have another single point of failure in our systems which needs somewhat urgent care and long-term solution: The binary cache should be the first priority here IMO.

So to conclude we should explore alternatives to GitHub eventually, but I don't regard this as urgent as other issues (cache, flake stabilsation, governance structures in general).
More specific steps would need to be planned in a team and scoped as tightly as possible. I personally believe that our code review tools could be a good place to start exploring alternatives ;)

[roberth]

If a group of people with spare time want to create an alternate non-GitHub workflow, and it works well, we could do it.
I would not invest my time or actively support such a project though, because of the significant time cost.
If Microsoft becomes hostile, the switch will be more valuable and easier for everyone to accept. They aren't much of a risk to the project today or in the near future.
The GitHub-based workflow should stay supported for the following reasons:

• Network effects
  • Virtually everyone has a GitHub account, so contributing is easy
  • Many thousands of automatic backlinks from upstream issues to ours
  • Visibility in GitHub's stats
• Free moderation. The moderation team is already short-staffed; let's not make them also responsible for handling low-level spam, etc, that's done by GitHub now.
• Redundancy. This actually lets the alternate forge setup iterate more freely.

[winterqt]

I think it makes sense for some reasons (e.g. things like the platform sporadically failing/being opaque in ways we can't debug, like notifications not working), but I'm not entirely sure that self-hosted alternatives will scale too well at Nixpkgs' repo size.

Losing the network effect is both a bad thing and a good thing IMO; on one hand, we lose contributors, but on the other hand, raising the barrier to entry for contributions might lead to better patch quality overall. However, there are other ways to solve this problem, like automating patch vetting + having consistent contribution guidelines.

[proofconstruction]

In time, yes. Dependence on commercial entities for critical infrastructure is concerning, and over-reliance on a single entity (in this case GitHub) is simply too risky in the long-term. Migrating to self-hosted git infrastructure would allow more flexibility and better control over maintenance tasks and likely tighter integration with the rest of the infrastructure (e.g. build caching), but comes with substantial challenges: rewriting GitHub Actions workflows and bots like ofborg and r-ryantm, porting all of the historical activity for future reference, and rethinking human interaction patterns all carry significant costs in time and energy, which are already severely limited to begin with.

I expect we can collectively determine some reasonable path to standing up parallel infrastructure and integrations to automate some of the migration heavy-lifting, as well as producing a suite of checks to tell us when we're actually done, and then slowly move activity over to the new environment until we're ready to make the GitHub org read-only.

[Infinidoge]

There are ultimately 2 competing goals: Independence, and accessibility.

Having our own git forge would be very freeing. It would let us use whatever workflows we wish, and let us have a deeply integrated development ecosystem that works for us, as opposed to requiring us to bend over backwards to accommodate it. Lix is already working under this model, with their own Gerrit-centered review scheme, plus infrastructure centered around a central Lix SSO. Adding new infrastructure and giving people access to it can be relatively straight forward and completely community owned.

On the other hand, GitHub is the biggest git forge extant. Within a rounding error, pretty much every developer has a GitHub account. If you want to make an issue, you don't need to create a whole new account. You just open GitHub and make an issue. You're already logged in. And if you aren't, you soon will be for one project or another. It is inevitable. This is a problem to which I see ForgeFed as the eventual solution. It may not be quite as simple as being already logged in, but being able to log into any federated forge using an existing account would help greatly.

So long as we make it easily accessible via OAuth login and the like, a self-hosted forge would be accessible enough to me. The only remaining question would then be the amount of time and effort it would take to make that transition. The sheer volume of open issues and pull requests would make any transition difficult.

[jtojnar]

Yes, but I see this more of a long term goal.

I would support establishment of a team that would look into alternatives. IIRC some people looked into using GitLab and other forges and found them unsuitable so the team could look into what the specific bottlenecks are and if it would be feasible to solve them. It might be suitable to apply for some grants so SC or the board to facilitate that.