Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bye, Bye GitHub

log.ozgur.works

Post reply on HN
Print view View original

11–20 of 82 posts

Re: Bye, Bye GitHub

#11

Post by perching_aix »

multisport wrote: post #7

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.

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.

Re: Bye, Bye GitHub

#12

Post by monkaiju »

multisport wrote: post #7

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.

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

Re: Bye, Bye GitHub

#14

Post by guywithahat »

monkaiju wrote: post #12
multisport wrote: post #7

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.

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

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.

Re: Bye, Bye GitHub

#15

Post by ranger_danger »

multisport wrote: post #7

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.

Most companies?

Do you have a source for that claim?

Re: Bye, Bye GitHub

#16

Post by beanjuiceII »

ranger_danger wrote: post #15
multisport wrote: post #7

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.

Most companies? Do you have a source for that claim?

i can be the source for that claim

Re: Bye, Bye GitHub

#19

Post by dabedee »

I agree with the sentiment of the post, and Github deserves every bit of it. Tried codeberg (which uses forgejo) and I am very happy with it personally.

Re: Bye, Bye GitHub

#20

Post by rogerrogerr »

guywithahat wrote: post #14
monkaiju wrote: post #12

Earlier quoted context omitted.

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

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.

> 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.

Post reply on HN