IME switching git providers is very hard, especially getting off of github. Most companies have insane numbers of integrations, automations, etc on top of GH. So yeah, its on us, but its also pretty simple algebra: does GH's downtime affect us more than the cost of switching? Most companies the answer is no.

When people ask why people aren't switching to Gitlab, ADO, Bitbucket, etc, I believe this is the reason.

▲

honr 5 hours ago | parent | next [-]

This year, the migration projects I have worked on were some of the most fun. Migrations have changed from the death-by-1000-cuts that they were, to the which-AI-method-to-best-ensure-100%-fidelity. So, I don't believe the "very hard" part. Obviously it would involved recreating or reshaping many features that very involved in an integration to have a disruption-free move, but I think the complexity is manageable for most companies if they put in some effort.

	▲	broken-kebab 4 hours ago \| parent [-]
		This fun was not revenue-generating, I suspect, so it's already a loss. Also it's a long-tail change, which will likely create unexpected situations here and there, and de-value experience and knowledge already available. Cumulatively it can be much more expensive than staying, unless GH will continue to falter, of course.

▲

bariumbitmap 4 hours ago | parent | prev | next [-]

It really is a testament to the power of mindshare and vendor lock-in. Git is GPL-licensed, the format is a de-facto standard, the commits and tags live in an on-disk format, merging and collaboration doesn't require a server, and yet somehow we still managed to end up with a centralized system with GitHub at the center.

▲

iterance 5 hours ago | parent | prev | next [-]

90% uptime is abysmal. That degree of poor performance can easily cost astounding amounts of money and/or cause secondary incidents. It's just harder to quantify than the cost of switching.

▲

Uvix 4 hours ago | parent | prev | next [-]

I can't imagine anybody switching to ADO from GitHub. Microsoft has made clear that ADO is on life support, and are slowly stripping features out like public repos.

I look forward to when GitHub Actions has feature parity with Azure Pipelines.

▲

monkaiju 6 hours ago | parent | prev | next [-]

Maybe for big companies that irresponsibly vendor-locked themselves, but I work at a SMB (~60 employees) and we switched to Forgejo in a couple days

▲

guywithahat 5 hours ago | parent [-]

I would not call it irresponsible. If you have a big, long running project you're going to want to develop complex pipelines and build processes to help with development and testing. This will save a lot of time and create a more consistent workflow, but switching vendors can require redoing work that was built over years.

	▲	rogerrogerr 5 hours ago \| parent \| next [-]
		> you're going to want to develop complex pipelines and build processes to help with development and testing Opinion: Complex build processes are great. Complex _pipelines_ are a trap. I'm in a position to see the output of a lot of teams at a very large company. The teams that have complex build processes _that they can run locally_, and then have some trivial CI yaml to run the build, are doing great. The teams that designed their build around CI are brittle and eventually end up in a state where they can _only_ do some parts of their build on CI. IME it's worth it to set very hard boundaries shaped like: (1) Everything needs to be able to be run locally (usually in a devcontainer), (2) CI config shall be stupid simple. If you have more than like two lines in a script section, it goes into a Tools/Build script file that must work locally and is just called in a one-line CI script. #1 guarantees you can operate without CI, and #2 guarantees you can move CI providers trivially.
	▲	cube00 4 hours ago \| parent \| prev \| next [-]
		>develop complex pipelines and build processes to help with development and testing. This will save a lot of time and create a more consistent workflow, Beware the trap of making the pipeline so complicated it's like code except you can't debug or unit test like regular code, and it takes an hour between attempts to see if a change worked.
	▲	cyberax 5 hours ago \| parent \| prev [-]
		If only we had a way to run code in a pre-defined isolated environment that can hide most of the differences of the actual hardware... Oh, we do have Docker/Podman? Then why not use _them_ to define your build pipelines? Bonus points: you can run them locally without tearing out your hair. And you can use normal scripting languages and task runners (taskfiles, good old makefiles, Ninja, etc.) for sequencing.

▲

bigstrat2003 4 hours ago | parent | prev | next [-]

Most companies aren't on GH at all, but are doing some internally hosted forge. Companies who build on GH are very much in the minority in my experience.

▲

ranger_danger 5 hours ago | parent | prev | next [-]

Most companies?

Do you have a source for that claim?

	▲	beanjuiceII 5 hours ago \| parent [-]
		i can be the source for that claim

▲

perching_aix 6 hours ago | parent | prev [-]

I really do wonder if the disruptions caused by the outages are starting to match the disruptions caused by a migration (which at least has a foreseeable end to it, theoretically).

Like even with the "will somebody please think of the operational costs" aspect, I really do wonder if the good old lock-in extortion math actually still holds in GH's favor.