Comment by mkornaukhov

I don't agree with this at all. I think the reason Github is so prominent is the social network aspects it has built around Git, which created strong network effects that most developers are unwilling to part with. Maintainers don't want to loose their stars and the users don't want to loose the collective "audit" by the github users.

Things like number of stars on a repository, number of forks, number of issues answered, number of followers for an account. All these things are powerful indicators of quality, and like it or not are now part of modern software engineering. Developers are more likely to use a repo that has more stars than its alternatives.

I know that the code should speak for itself and one should audit their dependencies and not depend on Github stars, but in practice this is not what happens, we rely on the community.

> In addition, it is best to use code navigation simply in a web browser

How do you define "code navigation"? It might've got a bit easier with automatic highlighting of selected symbols, but in return source code viewer got way too laggy and, for a couple of years now, it has this weird bug with misplaced cursors if code is scrolled horizontally. I actually find myself using the "raw" button more and more often, or cloning repo even for some quick ad-hoc lookups.

Edit: not to mention the blame view that actively fights with browser's built in search functionality.

> a pioneering (but no longer new) PR system

having used gerrit 10 years ago there's nothing about github's PRs that I like more, today.

> code navigation simply in a web browser

this is nice indeed, true.

> You write code, and almost everything works effortlessly.

if only. GHA are a hot mess because somehow we've landed in a local minimum of pretend-YAML-but-actually-shell-js-jinja-python and they have a smaller or bigger outage every other week, for years now.

> why developers like it so much

most everything else is much worse in at least one area and the most important thing it's what everyone uses. no one got fired for using github.

> a well-formed CI system

Man :| no. I genuinely understand the convenience of using Actions, but it's a horrible product.

I'd rather solve advent of code in brainfuck than have to debug their CI workflows ever again.

The big issue with Github is that they never denied feeding ai with private repositories. (Gitlab for example did that when asked). This fact alone makes many users bitter, even for organizations not using private repos per se.

> In addition, it is best to use code navigation simply in a web browser.

IMHO the vanilla Github UI sucks for code browsing since it's incredibly slow, and the search is also useless (the integrated web-vscode works much better - e.g. press '.' inside a Github project).

> as well as a well-formed CI system with many developed actions and free runners

The only good about the Github CI system are the free runners (including free Mac runners), for everything else it's objectively worse than the alternatives (like Gitlab CI).

Github'PR and CI are some of the worst.

Would you say Github has any significant advantages over Gitlab in this regard? I always found them to be on par, with incremental advantages on either side.

> a pioneering (but no longer new) PR system

Having used Forgejo with AGit now, IMO the PR experience on GitHub is not great when trying to contribute to a new project. It's just unnecessarily convoluted.

Underrated feature is the code search. Everyone starts out thinking they’ll just slap elastic search or similar in front of the code but it’s more nuanced than that. GitHub built a bespoke code search engine and published a detailed blog post about it afterwards.

Embrace, extend, extinguish.

That's not a Victorinox you're looking at, it's a cheap poorly made enshittified clone using a decades old playbook (e-e-e).

The focus on "Sponsorship buttons" and feature instead of fixing is just a waste of my time.