> A central repository is precisely the wrong way to use a distributed change-management system
You still need a single point of truth for the actual release version, which everyone agrees to sync to, most especially the Release Build process.
Distributed VC means you can do your dev without always connecting to The Repo, you have full history, can make all the branches you want (and reap the ones that don't work), collaborate with others etc etc, but once you have The Fix or The New Feature you have to merge it into The Repo before it can be released.
Otherwise your company/project can not have any guarantees about what is actually in a release if you just made it from whatever is sitting in a random repo on someone's laptop.
BUT The Repo just needs to be a simple Git (or whichever) repo on a machine that has been blessed. If you are all in-house it can just be a.n.other box on the LAN, otherwise hosting it somewhere accessible to anyone on the Internet is rather useful.
The whole GitHub thing is less about Git than it is all the stuff they put on top - and I'm not going to particularly praise that.[1]
[1] Personally, I think they got obsessed with Ruby and will never forgive them for recoding their Markup entirely in Ruby, instead of adding the features they wanted to the C library they'd been using! Obviously, if they'd (had the ability to) update the C lib, then everyone - Ruby, Python, C/C++ etc - could have used it directly. Not only did this make a total mockery of "GitHub, we are all about people collaborating together to make their projects better" but it guaranteed that we had yet ANOTHER *incompatible* dialect of Markup: even before being bought out by Microsoft, they had "Embrace, Extend" bit down pat!