Many users may not know use or like anything but GitHub, but there are many issues related to it, and other services are just as good, or much better.
Here is Zig moving to Codeberg. I wonder whether people would support the same for Rust. We could make a poll, but I don't want to make much fuzz, so keeping it without poll for now.
And their earlier announcement
I guess one of the blockers would be crates.io reliance on GitHub.
I believe it's good that the codeberg option is there.
I also believe that having the Rust project switch to codeberg would likely cause a lot of breakage for anyone making use of e.g. release artifacts, or the issue tracker.
And while I haven't seen GitHub take any overtly hostile action to FOSS to date, ultimately the value I see in having codeberg as a viable option is, at least for now, that it helps keep GitHub honest and fair w.r.t. FOSS projects.
I agree on the principle, but in practice I believe Codeberg isn't as stable as GitHub. I'm not even sure it's configurable and flexible enough to handle the same level of automation.
Then there's the issue of the corporate sponsors, among which is Microsoft; I doubt they'd appreciate that move.
Finally, as already mentioned, there are all the current forks and dependencies to consider, too.
That's not the sort of change you do many years later in a project of that magnitude.
PS: I understand the argument about GitHub, and particularly AI. OpenAI has done a considerable amount of damage by pushing that hype. At this point and with the amount of investment and people not wanting to lose face, I even doubt it's easily reversible. But as far as Rust is concerned, I'm not sure it'd change much to move now anyway.
In general I would always advise against having all ones eggs in one basket (crates in a basket?!) So the GitHub monopoly on crates.io is a bit disturbing. I have no idea about what could be done about it that would not cause chaos.
Initially they could just mirror the repository in my view.
GitHub and Microsoft generously donate a lot of compute resources to Rust's CI. Migrating that to a different provider would be costly, take many people's time, and be disruptive to Rust's stability. Not to say it's impossible or would never happen, but it would not be a simple thing to do.
Regarding crates.io, we want to offer other identity providers but we have some complex refactoring to do to disentangle the codebase and database from assuming GitHub-auth-only accounts before that can be started. Then there will need to be RFCs on how to clearly display identity and manage accounts tied to different services. This is something we want to do and I am slowly working on pieces of this, but it is going to take time.
So happy to see that you are replying here - I was worried the topic died down again, since the last reply on the linked issue is already from back in mid of October.
We all know things take time, and most of all if you wanna do them properly.
In my opinion, the part about crates.io relying on GitHub for auth would already be a major win, and does not require anything else to move away from GitHub at all - that way the compute resources for the project can still be used, and crates can be maintained without running into scary scenarios where it is (near) impossible to maintain the crate again.
I want to to voice my great gratitude for working on this topic, whenever it may finish, many thanks for that 