I myself don’t like Git. I’d rather pay for a Subversion + Redmine service.

Regardless of the software, if we want top availability and reliability, we must pay for it. There’s no other way. Softlayer for example has 3 sites in USA linked by dedicated optical cables. If worthy, it’s just a matter of paying for 2 servers to replicate the service, or buy a backup service hosted in another continent.

By convention, though, you *will* have a canonical repository somewhere. This is so developers know where to look for changes, and where to post changes against. While git makes this process quite a bit easier than subversion or other centralized version control systems, it still takes effort; you need to setup ACLs, potentially daemons, etc. GitHub takes the effort out of that.

That does not make GitHub a SPOF necessarily, however. As noted, because any fork/checkout of a git repository contains all changes up to the last time it was synced with the canonical repository, any given checkout can be promoted to canonical at any given time. Usually, there are any number of forks that are up-to-date — if nothing else, the last person to push to GitHub will have a full changeset.

With regards to hooks and whatnot, again, GitHub simplifies the process — but if GitHub dies, most, if not all, of those hooks can be recreated somehow. Were you using Travis-CI? you can re-create your setup as scripts for Jenkins. How about pushing to IRC? there are standard hooks you can drop into a bare repository for that. GitHub is convenience only; anything it offers can be recreated elsewhere — even the issues and wiki system (though to do that, you’ll likely need to have some systems in place ahead of time to mirror the content).

It is precisely the fact that git is distributed, and the fact that GitHub has implemented an API for everything it does, that have made GitHub successful: you can move from it at any time, but the service makes so many things convenient, and the downtime is so little for most people, that sticking with it makes as much sense as any other solution.

My suggestions:

* Don’t use the green “merge” button; always push from a local repository. This ensures somebody always has the most recent changesets.
* Write scripts to backup your wiki and issues.
* Have a list of the hooks you use, in case you ever need to recreate them later.
* Keep the scripts and your hooks list in your repository.

In this way, your project stays fully distributed, so that you never have a SPOF; you can always re-launch from elsewhere.

except that you have to get a spare pc and put linux on it and put it in a cupboard and make sure its patched.

This way we can easily add new ‘remotes’ without loosing too much sleep over it :) Works like a charm! (and indeed looses the SPOF)

Git makes this very easy. In fact, for open source, I see very little gain in owning a github appliances. That’s good for proprietary stuff _or_ when your data has to stay private to the company (ie not in the cloud).

The only parts of github you can’t fall back from are bugs, comments, etc. which should be non-deploy-critical anyways.

Note that it’s the same for any “cloud” service. They’re good, but they’ve similar limits.

Now, dependencies, those are hard. Composer, etc, a lot of times depend on github for their files (we use composer, the others like rubygems, npm i’m not so sure about) and not only the deps of your projects, but also the deps of your deps.

We are looking, but have not found a workable solution yet. The only option I see at this time is using a bash script and cron job to mirror all the repo’s we depend on to our GitLab instance, and then using Satis (private packagist repo) to override the download locations.

But then, what makes us so sure that our own infrastructure is that much more solid than GitHub’s (especially if you don’t want a full time engineer making sure this keeps working).

Any tool will fail, so you have to have redundancy if you can’t tolerate that.