Ignoring the fulminating a bit and concentrating on the substantive issue, there is a real leap in expected level of service once you start taking money from people, and again when you start hosting Mission Critical apps. (What an overused buzzword -- but a true overused buzzword!)
Saying "He shouldn't have had anything Mission Critical on Github, he should have designed his infrastructure competently" is besides the point. Properly designing a fault-tolerant workflow involving git isn't something which is in the easy reach of everyone, and some people would prefer to pay money than to deal with the hassle of doing it themselves. (And trust me, it is a hassle. I have my own gitosis server because I had a business necessity to host my OSS on my own domain. Holy bleeping heck I lost a day of my life to getting that working. That's close to $1,000 of engineer time replicating something very close to what every git hosting company offers for $9 a month.)
People who don't have the skills and don't have the desire to set up a fault-tolerant git infrastructure pay other people to do it for them. Other people being... well... Github. That means that Github has acutely more sensitive uptime demands than somebody's blog on OSS topics or even paid services in less critical contexts. One reason my business is in a less critical context was because I knew that the constraints I was working under made it unreasonable for me to offer customers the assurance that they could build their businesses on me.
Does Github offer the assurance that customers can build their businesses on it? If you want an SLA you will probably pay more than $9 per month (beyond the implicit SLA of "I'll take my business elsewhere if somebody else has better uptime for the same price").
SLAs are largely meaningless pieces of paper invented by folks who either think that downtime can be wished away by writing the number 9 enough times, or largely meaningless pieces of paper meant to quiet the discontent of non-technical stakeholders by pointing them to a suitably impressive numbers of 9s.
I'd love seeing a copy of that if you don't mind. (Incidentally, should any of you ever want to do this to a quote on HN from me, feel free. I trust your judgement regarding whether it is substantative enough to merit attribution.)
We're all businessmen here and everybody knows I hold absolutely no ill will towards Github for what I am about to say, right?
The primary concern was what SEOs call link equity (a link to your site from a trusted domain is a signal of trust, Google uses trust as a signal of quality in determining rankings, rankings are worth money, thus inbound links are essentially illiquid capital), with brand recognition being a major secondary concern. Take a look at Rails blogs discussing the OSS packages they use: everybody cites the canonical version of the code and if that is on Github then they cite the page on Github, frequently to the exclusion of the author's post or page about it.
Related problem: Frequently authors don't have a substantive page about it. That would be a mistake if you're trying for link equity or personal branding, in my mind. Relatedly, I spent $250 on a logo.
I spent quite a bit of time on that project and wanted the various marketing benefits of it to accrue to me, not to Github. So I put it on my site, not theirs. Folks subsequently cloned the repository and put it in their Github accounts. I am totally OK with that: mine is the canonical one and the canonical one gets the links, mindshare, etc.
This is the problem I tried to solved with the Indefero hosting I offer. All the forges have their own domain name for free and you can migrate all your data to your own server with your own Indefero installation in 3 easy steps (download, import, switch DNS).
Anyway, the problems with Github is that their level of quality result in people considering all the offers as having such level of quality. We (code hosting providers) are all suffering when Github is down... this is where it annoys me.
Saying "He shouldn't have had anything Mission Critical on Github, he should have designed his infrastructure competently" is besides the point. Properly designing a fault-tolerant workflow involving git isn't something which is in the easy reach of everyone, and some people would prefer to pay money than to deal with the hassle of doing it themselves. (And trust me, it is a hassle. I have my own gitosis server because I had a business necessity to host my OSS on my own domain. Holy bleeping heck I lost a day of my life to getting that working. That's close to $1,000 of engineer time replicating something very close to what every git hosting company offers for $9 a month.)
People who don't have the skills and don't have the desire to set up a fault-tolerant git infrastructure pay other people to do it for them. Other people being... well... Github. That means that Github has acutely more sensitive uptime demands than somebody's blog on OSS topics or even paid services in less critical contexts. One reason my business is in a less critical context was because I knew that the constraints I was working under made it unreasonable for me to offer customers the assurance that they could build their businesses on me.