&gt; either for Git or just Github, there&#x27;s some gap between the ideal they described and how things work in practice<p>The hub-spoke topology is the easiest way of distributing source code to a lot of people. If the hub goes down, this is what happens. If that leads to a halt in productivity, then that is a failure in contingency planning. Git gives you many tools to distribute your workflow, but that won&#x27;t save you if your workflow is centralized around Github.<p>Granted, sometimes you don&#x27;t really have a choice whether to depend on Github, such as when working with language package managers. Perhaps that goes to show that mirroring and resiliency should be a design consideration in those tools, but it&#x27;s not a shortcoming of Git itself.<p>&gt; even CVS or Subversion repos on high availability systems didn&#x27;t have 2 hours of downtime<p>It&#x27;s easier than ever to have HA with a DVCS: clone the repository somewhere else and keep it in sync with commit hooks.<p>Large FOSS projects (should) do this by keeping a self hosted repository, and mirroring somewhere else like Github, Bitbucket, etc. Internally, an org should be able to quickly stand up a SSH or HTTP server for the purpose, or have collaborators push-pull directly from each other. Worst case? Send patches. Git apply works really well, and you might be surprised at how clever git-merge is when everyone finally syncs up.<p>That&#x27;s what it means to be distributed: there is no real concept of a &quot;central&quot; node, unlike Subversion. Every local checkout has a full copy of the repository history. Any centralization is a (somewhat understandable) incidental artifact of how Git is being used.