> On the other hand, the usable interface of GitHub wouldn't be available to you if you were using a regular UNIX-based git server, and that is a dealbreaker. :)
That would be one hell of an open source project: a github like UI + ticketing system but federated rather than hosted by a central authority with some kind of single sign-on mechanism.
Fossil [1] repositories include a distributed bug tracker (and also a distributed wiki and a distributed time-based notes system), and provides a browser-based UI.
I've only read about it, not played with it, so don't know how close it comes to what you are envisioning.
It's a good idea! However, the distributed nature seems to make it sufficiently involved as to preclude a good UI (e.g., issues seem to use hashes), and the simple fact of not being git, regardless of whether it's better than git, is a serious problem for adoption. Bitbucket also learned this the hard way, and even made an April Fool's joke about it before realizing they had to primarily support git.
GitHub being centralized is a feature, not a bug. You don't have issues that exist in some people's repositories and not others. You don't have a question of who has the authoritative repository; either GitHub does, or GitHub doesn't and there's a note saying it's not authoritative. You can support things like have cross-site forks, but it's actively good for UX to have a single authoritative server for the current state of the project. (And you certainly don't want to require cross-site forks, since that would make it far more burdensome to submit a single patch.)
> and the simple fact of not being git, regardless of whether it's better than git, is a serious problem for adoption
I think I was a bit too terse. I didn't mean to suggest that someone who wanted to do everything (SCM, bug tracking) distributed use Fossil instead of git. The idea was to use git for the code, and Fossil for the bug tracking and wiki.
GitLab and gogs are both fine for getting 80% of the UI, but there are network effects with GitHub: that you're already signed in and have keys and such set up (although OAuth and API cleverness with keys can get you close), that your contributions across all projects show on your profile, that third-party tools like Travis know how to talk to your GitHub in particular, etc. And all sorts of little things, like that when you mention another project's PR in a commit, a note shows up on that PR. That's a lot of what makes GitHub nice to use, more than just the UI, and I suspect that's what pushed some of the Python core devs in favor of GitHub.
There's potentially a way to build a system that federates all of this, and then toss GitLab on top for the UI. A good standard would be whether a newcomer could submit a PR with only one more click (for the OAuth screen) than they would need on GitHub.
A good federated system would allow a fork from one host to end up on another and the PR would be done automatically after the very first PR was done with that extra click (and that extra click should do a bit of magic behind the scenes to send your key over to the other server together with your first sign-on on that server).
That way future interaction would hide the fact that the systems are in fact separate.
That would be one hell of an open source project: a github like UI + ticketing system but federated rather than hosted by a central authority with some kind of single sign-on mechanism.