As for me, this does not negate the convenient things that I originally wrote about.
The previous popular free code hoster was Sourceforge, which eventually started its what's now called "enshittifcation phase". Github was simply in the right place at the right time to replace Sourceforge and the rest is history.
And for those who don’t remember SourceForge, it had two major problems in DevEx: first you couldn’t just get your open source project published. It had to be approved. And once it did, you had an ugly URL. GitHub had pretty URLs.
I remember putting up my very first open source project back before GitHub and going through this huge checklist of what a good open source project must have. Then seeing that people just tossed code onto GitHub as is: no man pages, no or little documentation, build instructions that resulted in errors, no curated changelog, and realizing that things are changing.
But VCS has always been a standard-preferring space, because its primary point is collaboration, so using something different creates a lot of pain.
And the good ship SS Linux Kernel was a lot of mass for any non-git solution to compete with.
The big reason I recall was that GitHub provided free public repos and limited private, while BitBucket was the opposite.
So if you primarily worked with open-source, GitHub was the better choice in that regard.
1. Free hosting with decent UX
2. Social features
3. Lifecycle automation features
And probably, if the latter, fork that off into a different platform with a new name. (Microsoft loves naming things! Call it 'Codespaces 365 Live!')
I hate that this is perceived as generally true. Stars can be farmed and gamed; and the value of a star does not decay over time. Issues can be automatically closed, or answered with a non-response and closed. Numbers of followers is a networking/platform thing (flag your significance by following people with significant follower numbers).
> Developers are more likely to use a repo that has more stars than its alternatives.
If anything, star numbers reflect first mover advantage rather than code quality. People choosing which one of a number of competing packages to use in their product should consider a lot more than just the star number. Sadly, time pressures on decision makers (and their assumptions) means that detailed consideration rarely happens and star count remains the major factor in choosing whether to include a repo in a project.
The metrics you want are mostly ones they don't and can't have. Number of dependent projects for instance.
The metrics they keep are just what people have said, a way to gameify and keep people interested.
All these things are a proxy for popularity and that is a valuable metric. I have seen projects with amazing code quality but if they are not maintained eventually they stop working due to updates to dependencies, external APIs, runtime environment, etc. And I have see projects with meh code quality but so popular that every quirk and weird issue had a known workaround. Take ffmpeg for example: its code is.. arcane. But would you choose a random video transcoder written in JavaScript just due to the beautiful code that was last updated in 2012?
??? Seriously?
> All these things are powerful indicators of quality
Not in my experience....
People don't just share their stargazing plots "for fun", but because it has meaning for them.
What's the difference?
Hahahahahahahahahahahaha...
I can refer you to some github repositories with a low number of stars that are of extraordinarily high quality, and similarly, some shitty software with lots of stars. But I'm sure you get the point.
I have no idea what the parent comment is talking about a "well-formed CI system." GitHub Actions is easily the worst CI tool I've ever used. There are no core features of GitHub that haven't been replicated by GitLab at this point, and in my estimation GitLab did all of it better. But, if I put something on GitLab, nobody sees it.
Facebook has been on that path for well over a decade, and it shows. The service itself is absolute garbage. Users stay because everyone they know is already there and the groups they love are there, and they just tolerate being force-fed AI slop and being monitored. But Facebook is not GROWING as a result, it's slowly dying, much like it's aging userbase. But Facebook doesn't care because no one in charge of any company these days can see further than next quarter's earnings call.
It's been years through and the ease of doing simple things is not always indicative of difficult things. Often quite the contrary...
They're NOT! Lots of trashy AI projects have +50k stars.
In non-coding social circles, social proof is even more accepted. So, I think that for a large portion of codebases, social proof is enough.
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.