Mercurial had a single command for this, "hg serve", that would just pop up a webserver for sharing. It was extremely useful for me during university, and I've often considered it a key failing that git does not provide a similar command out of the box. As a result, the distributed nature of git is hidden from a lot of people.
For the record, the command to make git do what mercurial does with hg serve is "git daemon --reuseaddr --base-path=. --export-all --verbose --enable=receive-pack".
Obviously this is insecure and anyone who can establish a connection can push and pull from your repo, but if you're just jamming with some friends you don't need github.
The vast majority of Linux developers don't have their own publicly-accessible repository that you can pull from - they push patches to the mailing list.
Various archives can host copies of the mailing lists (you can ask https://www.mail-archive.com to do so for you), and the git repository can obviously be mirrored anywhere anyone who can clone it likes. Congratulations, you now have a globally mirrored, decentralised development process where the canonical repo and any patches submitted never disappear.
You don't even have to "host a server". Simply allowing ssh access to your machine is enough.
But instead having many small hand-maintained servers, the admin of each is responsible for what's hosted on it, and of which there is no registry, doesn't sound much better. Very likely there would be a handful of effective central nodes in that network, but if you take down a couple of them, you end up with a situation where already-involved devs might still be able to navigate the landscape, but for a newcomer it might be really hard to find one of those nodes, or be sure it's one with the "right" revisions.