> There shouldn't be a strong dependence on a central repo.
Most groups are not setup like the Linux kernel where there is a "gatekeeper" who is a person that directly pulls from other people's repos (or from commits sent to an email list).
A central repository becomes "the truth" and once something is "the truth" it becomes the person that wants to push their code to this repo to do the merging. There is nothing about this that is inherent to Github in particular, but telling everyone to change their "origin" remote to point somewhere else can be an issue depending on how large your group is. And what if someone manages to get a push to (e.g.) master through the Github DDoS before everyone is on the new remote repo? Now Github and BackupRemote have branched, when you really want BackupRemote to be a superset of the copy on Github.
Most groups are not setup like the Linux kernel where there is a "gatekeeper" who is a person that directly pulls from other people's repos (or from commits sent to an email list).
A central repository becomes "the truth" and once something is "the truth" it becomes the person that wants to push their code to this repo to do the merging. There is nothing about this that is inherent to Github in particular, but telling everyone to change their "origin" remote to point somewhere else can be an issue depending on how large your group is. And what if someone manages to get a push to (e.g.) master through the Github DDoS before everyone is on the new remote repo? Now Github and BackupRemote have branched, when you really want BackupRemote to be a superset of the copy on Github.