It’s not really lack of repo access that makes GitHub outages bad. It’s all the “value-add” stuff on top of the repo that makes outages suck.

You’ve got workflows bolted on top that block forward progress when it goes down. Hooks for when push requests happen, when commits happen, etc. You’ve got code reviews in your workflow that cannot happen when the service is down.

Basically there is much more to a service like GitHub / gitlab than just “write code, commit”. These services enable powerful workflows. When those go down all you can do is write code locally. The rest of the pipeline is dead in the water, which in many cases makes your overall ability to work virtually impossible.

And it's going to be the same with cryptocurrencies.

All the interesting stuff for normal people is built on top.

well the case is that if github keeps going down and becomes completely unreliable you can take your decentralized code and more it to a different provider. Those other providers will also have value added stuff and you will not lose the core of your business/work (your source code).

If it was a pure central authority + protocol you would be doomed to live and die with them. Imagine if instead of git + github you had some source code protocol that only allowed you to checkout the latest commit of some branch. All code history needed to be viewed by connecting to the central servers. Why not make it even worse, you could only view+edit a specific file of the latest commit on your machine. All other files must live on the central server, you are not allowed to build/compile code locally either... Centralization is the process of you giving up control to a "trusted" entity. If they fail you lose everything

Ok... how does that help cryptocurrencies, though?

I think that's mainly cultural, actually. "Github is down" is seen as "take the day off". But it actually is pretty easy to work around a remote being temporarily down. Developers can use their local copies of code and merge them when the remote is back up. Or whoever has the latest commits can start a temporary git server in an EC2 instance and tell the developers on slack to update their remote URLs.

Of course, if your build process is tied into github actions or something, that will still be broken. But that problem also exists for any other 3rd party build/deploy service you might use, independent of git-the-VCS-tool.

> I think that's mainly cultural, actually.

Yes, that's my point. It doesn't matter if your protocol is decentralized as long as your business processes rely on having a blessed authoritative repo, which most do. Yes, you can point your remotes somewhere else, but in practice nobody bothers.

Small organizations use github. Really large organizations have their own git servers.

I have worked on both sides of that.

I used to work for a company that used on-prem BitBucket. And even there, "Stash is down" caused development to grind to a halt. Yeah, sure, our outages weren't synchronized with the rest of the world's outages, but the end result is the same: productivity depends on the uptime of our authoritative repo. That all the developers have clones of that repo on our own boxes is irrelevant... nobody's going to bother pointing our remotes at each other's workstations or reconfiguring Jenkins.

I’ve worked for a number of very large, enterprise companies. They use Github Enterprise.

Even banks are moving to SaaS first for their core applications.