We do. It's called Git.
Github makes it easy to host git repositories, but so do a bunch of other services and it's not that hard to host your own either way or to set up trees of repository or multiple mirrors or what have you. The reason people use a central hub is all the meta-information and exchange about the code and the contributor communities.
The repository on its own has very little value.
And lest you think it's different for the kernel or whatever, a mailing list or an IRC channel are still centralised SPOF[0], when the ML provider goes down so does the project.
[0] though possibly more resilient and easier to switch out of ones
Depends for who. When I'm a user of a project, I don't care at all about anything other than the repository. The source code is the only thing that matters.
Anyway, you can't really avoid centralization in most of the projects. Barring some extreme social experiments, a project always has identity, a "canonical version". That's your SPOF right there. Of course we have tons of experience with mitigating potential issues - from caching and mirroring to not doing stupid shit like telling your CI server to download dependencies from GitHub every time it builds your project. Temporary GitHub outages seem to be a problem mostly for people doing the latter kind of stupid shit.
What would be interesting to see though is some kind of torrent network for Git repos. The kind of where I ask for a particular commit of a particular project, and I get a way to download it from some random computer that has it (with all the magic crypto code signing for confirming the code was not maliciously changed, etc.). Node.js developers have local mirrors of third of GitHub anyway, so that would pretty much solve "GitHub is down" issues.
Though it would not solve the problem of people too lazy to have a local cache of their dependencies...
The repository doesn't have any more value for that use case, tarballs would be just as good if not better.
If you don't want special git semantics around it, you'd have to be clever about how you store it so you don't have conflicts within the metadata. I.e. a naive design just adding a markdown file per issue or for all issues will require manual merging all the time. Still, it seems doable.
There were a number of tentative distributed bug trackers a few years ago, they sucked and fizzled out. IIRC Fossil is an attempt at an entire distributed project management system, I don't know how it fares.
> I.e. a naive design just adding a markdown file per issue or for all issues will require manual merging all the time. Still, it seems doable.
That only works for your own personal project where you're the only user and contributor. Bug reporting by editing a markdown file (or even something actually usable like an org-mode file or an sqlite or BDB file) isn't going to scale very high and is way more effort than most bug reporters (even technical ones) will be willing to put in.
And even if your users were willing to subject themselves to that, they still need a way to send back those contributions somehow.
Or dat http://dat-data.com/
Or Camlistore? https://camlistore.org/
Unless you're working across multiple projects, it doesn't matter to you that a GitHub outage takes out everyone else's projects at the same time.
Can you beat GitHub's uptime with a self-hosted solution? Sure. But you'll waste more time setting it up & managing it than you'd lose from GitHub downtimes.
But there still are many open problems: - incentivised file storage - fair name spaces - search and indexing and more.
Also:
sudo npm install --global gittorrent
Cool! It automatically installs a local copy of half of GitHub! ;).
Someone could serve you a maliciously-modified repo, but Git itself would then reject those objects, since they won't lead to the SHA1 that Git knows that it's looking for -- you would keep trying other peers until someone gave you bits that match the correct SHA1.
I'm not so sure about that. I've only used it once, an only to test its functionality, I didn't do any in-depth testing. Well I wouln't use it in production, but in a non-critical, small-scale project it could be worth a try...