Where do you keep Issues, Pull Requests, Wikis, Discussions, project boards, and everything else? (rhetorical question.)
These days, the problem with cloud-hosted Git platforms is not where to push your code. Replicating repositories across multiple providers is relatively easy, and Git has always been good at that. The harder problem is that successful teams end up accumulating a lot more than source code around their repositories, and much of that information becomes just as important as the code itself.
Bug reports, feature requests, documentation, design discussions, code reviews, project planning, CI/CD configuration, and years of historical context all tend to live inside platforms such as GitHub. While the Git repository itself is portable, all of that surrounding data is often much harder to migrate cleanly, especially if a team has built workflows and integrations around a particular provider.
That, in my view, is one of the main reasons so many companies are heavily dependent on GitHub. Moving the code elsewhere is usually straightforward; moving the entire development process, with all of its history, metadata, and institutional knowledge, is not. When GitHub goes down, the question is often less about where you can push your next commit and more about how easily you can recreate the rest of the environment that your team relies on every day.
(I upvoted you, for asking the real questions, but to answer)
> Where do you keep Issues,
Youtrack
> Pull Requests,
Gerrit, it's way better for code review
> Wikis,
Also Youtrack, but other software exists that's specific for this, I have seen Confluence used a lot and while I don't recommend: that's usually the case.
> Discussions,
As far away from code as possible, right now it's Zulip
> project boards,
Youtrack, though usually in companies they use Jira for this.
> and everything else? (rhetorical question.)
In proper tools that are designed to solve a specific need, not try to do everything: badly.
--
Now, a sane person will respond to me with the fact that I haven't removed any single points of failure, I've actually just added more of them. They'd be right! The differences is that it makes the stack a bit more flexible and composable. Migration of, say, the Wiki, doesn't make major issues because it's already somewhat decoupled.
What's the purpose of using EC2 over something much cheaper, like OVH, digitalocean, or Hetnzer?
Usually the argument is for scalability, but a single VM for personal use doesn't need that, and even if you do want that, you'll need more than a bare repo.
I also built a convenient CLI tool to switch identities on a per-repository basis. [1] [2] ...which makes working in enterprise environments much easier, as I can just have separate identities/keypairs for each customer.
Somehow I never knew that you can have multiple push URLs for a single remote. Thank you for sharing this, I've been manually pushing to two remotes with a script for years!
What happened to hacker culture? Did everyone (or enough) just sell out?
It’s fascinating to me that the people who know the most about tech keep deciding over and over to give something to some corporation and inevitably it becomes an issue. I guess ease of use and freemium really trumps everything; I expect more from smart people but money talks.
I am self hosting forgejo on my synology NAS. It is easier than it looks. Synology provides me access from the internet so I do not need static IP address. It took me at most 20 minutes to write (copy paste) docker compose file to make it run and another hour to import repositories from github and gitlab. Only maintenance I do is update to new version once a while which takes about 5 minutes. You can set it up to sync repositories back to code forges.
If you do not have a lot of users you can easily set it up too.
Codeberg and Gitlab exist though. The problem is the inertia. Tons of repositories in GitHub from way before MS acquired them, which makes most people use GitHub, which makes most software projects choose GitHub.
Heck, GH Stars are used as a vanity metric for a lot of projects.
The fact that companies request you to star them on GitHub and the stars can be bought tells you that there is a value in these stars. [2]
Now, some astute reader, who thinks the $1 trillion global advertisement market does not influence them, will also claim that they don't care about GitHub stars.
Well, that's not how the world works.
Fake stars can propel a good project to great.
A lot of people will use GitHub stars as a currency to decide the importance of certain FOSS (or even open-core) projects.
I'm thinking like "you had 200 GitHub stars before coming to us so we start you with 200 stars" as a migration process. maybe they wouldn't be as reputable but everyone knows it's gamed anyway, so why not?
> I'm thinking like "you had 200 GitHub stars before coming to us so we start you with 200 stars" as a migration process. maybe they wouldn't be as reputable but everyone knows it's gamed anyway, so why not?
> Microsoft: Our priorities are clear: availability first, then capacity, then new features.
> This is a lie. Github - and the microsoft organization more widely - clearly prioritize flashy AI features over fundamental reliability Github has a public changelog. In thirty days since they posted their update, their patch notes contain the words “copilot” 59 times, “agent” 8 times, “performance” 0 times, and “reliability” 0 times. The changelog has a feature to filter by category: copilot is it’s own category: performance and reliability do not exist at all.
I suppose when calling someone a liar, it's beneficial to have hard numbers to back it up. Ouch.
> Github does not expose a public bug list or any issues page, hiding their problems deep in email chains
Which email chains is this referring to? GitHub/community is fairly active from the community perspective. GitHub rarely looks at it anymore, prioritising their Enterprise roadmap.
> Github often breaks on firefox and safari, browsers with millions of users
[[citation needed]].
I’ve been as annoyed as everyone with the GitHub frontend performance since the React rewrite, but never really faced breakage in Firefox. This claim is repeated a few times in the article, but without any links.
People should consider decentralized git over Nostr, rather than switching to a replacement like Codeberg or Gitlab and waiting for the resulting enshittification after it attracts everyone else.
Because of so many GitHub problems, I'm adding GitLab.com and Codeberg.org.
Setup is simply 3 steps:
1. Sign up on each service, ideally with the same username.
2. For each repo you want to share, create the same repo name as a blank repo; do not automatically create a README.
3. Edit your local file .git/config to add push URLs, then push as usual.
Example:
Where do you keep Issues, Pull Requests, Wikis, Discussions, project boards, and everything else? (rhetorical question.)
These days, the problem with cloud-hosted Git platforms is not where to push your code. Replicating repositories across multiple providers is relatively easy, and Git has always been good at that. The harder problem is that successful teams end up accumulating a lot more than source code around their repositories, and much of that information becomes just as important as the code itself.
Bug reports, feature requests, documentation, design discussions, code reviews, project planning, CI/CD configuration, and years of historical context all tend to live inside platforms such as GitHub. While the Git repository itself is portable, all of that surrounding data is often much harder to migrate cleanly, especially if a team has built workflows and integrations around a particular provider.
That, in my view, is one of the main reasons so many companies are heavily dependent on GitHub. Moving the code elsewhere is usually straightforward; moving the entire development process, with all of its history, metadata, and institutional knowledge, is not. When GitHub goes down, the question is often less about where you can push your next commit and more about how easily you can recreate the rest of the environment that your team relies on every day.
(I upvoted you, for asking the real questions, but to answer)
> Where do you keep Issues,
Youtrack
> Pull Requests,
Gerrit, it's way better for code review
> Wikis,
Also Youtrack, but other software exists that's specific for this, I have seen Confluence used a lot and while I don't recommend: that's usually the case.
> Discussions,
As far away from code as possible, right now it's Zulip
> project boards,
Youtrack, though usually in companies they use Jira for this.
> and everything else? (rhetorical question.)
In proper tools that are designed to solve a specific need, not try to do everything: badly.
--
Now, a sane person will respond to me with the fact that I haven't removed any single points of failure, I've actually just added more of them. They'd be right! The differences is that it makes the stack a bit more flexible and composable. Migration of, say, the Wiki, doesn't make major issues because it's already somewhat decoupled.
I'd also add tangled.org and radicle.dev. I've been looking into these new decentralized forges recently.
And for fun, just spin up a VPS and initialize some bare repos there.
What's the purpose of using EC2 over something much cheaper, like OVH, digitalocean, or Hetnzer?
Usually the argument is for scalability, but a single VM for personal use doesn't need that, and even if you do want that, you'll need more than a bare repo.
Oh, EC2 is mostly a catchall for VPS for me. Sorry, that's unclear.
Hey, that's my workflow!
I also built a convenient CLI tool to switch identities on a per-repository basis. [1] [2] ...which makes working in enterprise environments much easier, as I can just have separate identities/keypairs for each customer.
[1] https://github.com/cookiengineer/git-identity
[2] https://cookie.engineer/projects/development/git-identity.ht...
Somehow I never knew that you can have multiple push URLs for a single remote. Thank you for sharing this, I've been manually pushing to two remotes with a script for years!
This web site is very hard to read because of the colors and font sizes.
I use firefox reader view for websites like this.
Agreed, this is kind of the perfect use case for AI. I can see the prompt now "using css, make this website readable and use a proper color scheme"
“Never, ever, think about something else when you should be thinking about the power of incentives.”
— Charlie Munger
Edit: great write up, thank you op.
Has anyone switched over to Fossil SCM, so they get issue tracking as part of the repo
What happened to hacker culture? Did everyone (or enough) just sell out?
It’s fascinating to me that the people who know the most about tech keep deciding over and over to give something to some corporation and inevitably it becomes an issue. I guess ease of use and freemium really trumps everything; I expect more from smart people but money talks.
Nobody wants to pay for git hosting. Seems like nobody wants to self-host it either.
I am self hosting forgejo on my synology NAS. It is easier than it looks. Synology provides me access from the internet so I do not need static IP address. It took me at most 20 minutes to write (copy paste) docker compose file to make it run and another hour to import repositories from github and gitlab. Only maintenance I do is update to new version once a while which takes about 5 minutes. You can set it up to sync repositories back to code forges.
If you do not have a lot of users you can easily set it up too.
Codeberg and Gitlab exist though. The problem is the inertia. Tons of repositories in GitHub from way before MS acquired them, which makes most people use GitHub, which makes most software projects choose GitHub.
Heck, GH Stars are used as a vanity metric for a lot of projects.
> Codeberg and Gitlab exist though.
Soooo...
Let me preface this by saying this is an old (so things are different) anecdote (which is not the singular of data), but...
a) I had never heard of codeberg.
b) My company used an on-prem gitlab instance, and it sucked donkey dicks.
For example, the equivalent of just putting a statically generated site into github pages required running a fucking production pipe.
You should make the easy things easy and the hard things possible. Making the easy things hard is an immediate red flag.
> The problem is the inertia.
Oh, don't worry about that. Github is working diligently to fix that problem. The question is, are the alternatives worthwhile?
Hosting forgejo on a cheap Hetzner server is the best and easiest trick that happened in my work life these last years !
I suggested we move off of github to avoid issues about a year ago. Every developer on my team looked at me like I grew a second head.
Just because you're a developer doesn't mean you're a hacker or you care for the craft on any level.
The wild west days are over.
Nginx was compelled to move to GitHub [1].
The fact that companies request you to star them on GitHub and the stars can be bought tells you that there is a value in these stars. [2]
Now, some astute reader, who thinks the $1 trillion global advertisement market does not influence them, will also claim that they don't care about GitHub stars.
Well, that's not how the world works.
Fake stars can propel a good project to great.
A lot of people will use GitHub stars as a currency to decide the importance of certain FOSS (or even open-core) projects.
The real lock-in is in GitHub stars [3].
1 - https://blog.nginx.org/blog/nginx-open-source-moves-to-githu...
2 - https://finance.biggo.com/podcast/1c9f14e134095b87
3 - https://ashishb.net/tech/github-stars/
What stops a new platform from just mirroring GitHub stars on import or something, actually?
> What stops a new platform from just mirroring GitHub stars on import or something, actually?
So, the source is still GitHub, right?
Which means I have to keep my FOSS project on GitHub to accumulate stars.
I'm thinking like "you had 200 GitHub stars before coming to us so we start you with 200 stars" as a migration process. maybe they wouldn't be as reputable but everyone knows it's gamed anyway, so why not?
> I'm thinking like "you had 200 GitHub stars before coming to us so we start you with 200 stars" as a migration process. maybe they wouldn't be as reputable but everyone knows it's gamed anyway, so why not?
And how will the project accumulate more?
> everyone knows it's gamed anyway, so why not?
Then why do they still have purchase value?
We're going to enter the era of returning to self hosting.
Self hosted gitlab is a dream, no surprises ever, exactly how your repos are supposed to work.
[delayed]
> Microsoft: Our priorities are clear: availability first, then capacity, then new features.
> This is a lie. Github - and the microsoft organization more widely - clearly prioritize flashy AI features over fundamental reliability Github has a public changelog. In thirty days since they posted their update, their patch notes contain the words “copilot” 59 times, “agent” 8 times, “performance” 0 times, and “reliability” 0 times. The changelog has a feature to filter by category: copilot is it’s own category: performance and reliability do not exist at all.
I suppose when calling someone a liar, it's beneficial to have hard numbers to back it up. Ouch.
> Github does not expose a public bug list or any issues page, hiding their problems deep in email chains
Which email chains is this referring to? GitHub/community is fairly active from the community perspective. GitHub rarely looks at it anymore, prioritising their Enterprise roadmap.
> Github often breaks on firefox and safari, browsers with millions of users
[[citation needed]].
I’ve been as annoyed as everyone with the GitHub frontend performance since the React rewrite, but never really faced breakage in Firefox. This claim is repeated a few times in the article, but without any links.
I hope vscode does not end up like this
This is my fear too. Feels inevitable tbh.
People should consider decentralized git over Nostr, rather than switching to a replacement like Codeberg or Gitlab and waiting for the resulting enshittification after it attracts everyone else.
https://nostrapps.github.io/nostrgit/
Amen.
I remain happy with GitHub!