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

21–30 of 82 posts

Re: Bye, Bye GitHub

#21

Post by honr »

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.

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.

Re: Bye, Bye GitHub

#22

Post by cyberax »

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.

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.

Re: Bye, Bye GitHub

#23

Post by ralph84 »

What frontier model did GitHub train? All of the frontier labs scraped GitHub like they scraped everything else. While GitHub has certainly tried to profit from AI, directing ire at GitHub for frontier labs training on public code seems misplaced.

Re: Bye, Bye GitHub

#24

Post by iterance »

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.

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.

Re: Bye, Bye GitHub

#26

Post by p4bl0 »

luciandan wrote: post #5

So why no self-hosted GitLab then?

GitLab is also getting worse and worse. They're going full-in on AI and each new release is more cluttered with useless features and requires more and more resources to run smoothly. After six years self-hosting a GitLab instance for a few hundred users (among which a few dozens are quite active), I abandoned this summer and I'm currently migrating the instance to Forgejo.

Re: Bye, Bye GitHub

#27

Post by pico303 »

The problem is nothing competes with GitHub.

I know, GitLab. Gitea. Bitbucket. They have some features, but it’s like suggesting I drive a Nissan Sentra because my BMW breaks down once in a while.

Re: Bye, Bye GitHub

#28

Post by gravypod »

p4bl0 wrote: post #26
luciandan wrote: post #5

So why no self-hosted GitLab then?

GitLab is also getting worse and worse. They're going full-in on AI and each new release is more cluttered with useless features and requires more and more resources to run smoothly. After six years self-hosting a GitLab instance for a few hundred users (among which a few dozens are quite active), I abandoned this summer and I'm currently migrating the instance to Forgejo.

It's a shame because I like GitLabs UX and runners much more than other forges. I've been considering forking gitlab and removing complexity. GitLab uses multiple GB of memory idle with no users. It's sad.

Re: Bye, Bye GitHub

#29

Post by p4bl0 »

gravypod wrote: post #28
p4bl0 wrote: post #26

Earlier quoted context omitted.

GitLab is also getting worse and worse. They're going full-in on AI and each new release is more cluttered with useless features and requires more and more resources to run smoothly. After six years self-hosting a GitLab instance for a few hundred users (among which a few dozens are quite active), I abandoned this summer and I'm currently migrating the instance to Forgejo.

It's a shame because I like GitLabs UX and runners much more than other forges. I've been considering forking gitlab and removing complexity. GitLab uses multiple GB of memory idle with no users. It's sad.

I agree. GitLab UI was great and the simplicity of its CI/CD is unequaled on other forges. It's sad that Forgejo went with the actions model from GitHub which introduce a lot of useless complexity. But it seems that Woodpecker CI [1] could be a good candidate to replace GitLab CI, as it uses very similar concepts and workflow description files.

[1] https://woodpecker-ci.org/

Re: Bye, Bye GitHub

#30

Post by broken-kebab »

honr wrote: post #21
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.

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…

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.
Post reply on HN