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.
would a self-hosted all-in-one solution be a viable alternative that doesn't split these all up into separate cloud hosted apps? it's been years since i've explored anything other than github/gitlab/etc.
Right? Yeah, everything's decoupled and "flexible", but if your stack is dependent on half a dozen different third parties uninterested or uninvested in your project, you gotta watch like a hawk for when those services decide they need to be worse and charge more.
> In proper tools that are designed to solve a specific need, not try to do everything: badly.
And when you want to search for that one thing that you know got documented somewhere, but can't remember where, how many systems do you have to search?
That's one of the reasons I like the code, issues, docs (code or wiki depending), and discussions all in the same repo.
Not to be confused with Chat, which is more ephemeral, and is, for us, in Slack. But we have to be mindful of chat discussions that turn substantive and make sure we copy that info to a Discussion in the repo (which can be annoying to do and annoying when it's not done).
> And when you want to search for that one thing that you know got documented somewhere, but can't remember where, how many systems do you have to search?
Not GP, but is that actually a real problem? Take a project like OpenBSD where the code, the bug tracking , and the design discussion happens in different place?
Even in reality, you don’t put the workshop in the conference room.
This isn't a direct answer, because I agree it is difficult to move away from Github's familiarities amongst developers - so it doesn't necessarily solve the problem for a collaborative codebase involving a handful or more developers (complete with Issues, PRs, etc) but if you are working with a less technical/developer oriented team ie- regardless of org size it's just you or maybe one other teammate who are the only ones involved directly in code/PRs then you can fairly trivially roll your own issue tracker or wiki.
Particularly if your work and the employer/client/org is primarily based on a web project (extra points, you already are managing their auth) then you could simply add a new subdomain or route to your existing web project that serves said self-hosted issue tracker or wiki.
Of course these things can get into the weeds but I do think that given the dramatically reduced turnaround times for a competent dev to spin up and customize in-house/self-hosted solutions for basic things like issues and wikis the strategy is more relevant and prudent than ever.
None of those might be perfect, but at least people are trying. Even something like Gitea and other forges that you can host yourself have support for most of the basic functionality you'd expect.
However, If we ever wanted a setup where it's easy to mirror rather than import stuff, we'd probably want to look in the direction of storing everything in folders within the repo, e.g. a file/folder for every issue, for every Wiki page etc. Most of the mirroring seems to only concern the repo itself, not the stuff around it, for example: https://docs.gitlab.com/user/project/repository/mirror/
This is the real issue. We’re currently migrating from GitLab+Jira to GitHub. I did most of the migration, including our CI/CD with a self-hosted runner, and it was… fine.
The straw that broke the camel’s back was that Claude managed cloud agents are awkward to use with anything other than GitHub. In general, we realized that the whole world was on GitHub and we were swimming upstream.
But the original mistake was separating issue tracking and source control when we didn’t need all that power. Everything is so much simpler if you don’t have to maintain those integrations.
Maybe they’ll really enshittify GitHub in the future. We’ll cross that bridge when we come to it.
I switched my personal projects to Codeberg recently and couldn't be happier. After spending lord knows how many hours wading through cluttered buggy interfaces in Github it's a pleasure to use a clean intuitive platform.
Years ago I was a big fan of Gitlab and always talked them up as a better Github. At this point though they've spent years trying to become just as convoluted and "enterprisey" as Github, but with much less success.
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'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.
I've been an avid GitHub user for a very long time.
I remember way back in the "olden days" in San Francisco seeing people with Octocat signs on Market. GitHub was awesome. Fond memories.
But times are a-changin', and for lots of reasons I just don't feel like GitHub is cool or "for me" anymore.
So, with my new Mac Mini, because they were on sale and everyone was getting one for OpenClaw... I put that puppy on my tailnet, installed Gitea, and I've been using it exclusively for all my projects. It's been weeks since I've pushed anything to GitHub.
Hey, I know it’s supposed to be simple, but any chance of a write up of the macmini as a server approach? I would be interested in learning about the details of how you set it up. I would read this blog post if you ever write one!
It is. I don’t have opened up to the wide internet, but it’s still super convenient to have it on my tailnet, which all my other devices are on, so I can review and manage repos wherever I am, while operating with the privacy of a self-hosted GitHub-like experience.
I know this is just a speculative comment, but the list of GitHub issues is eerily familiar. These problems read a lot like the types of mistakes and assumptions unattended agents will make that corrode codebases.
It is targeted at tech literate people who obviously know about reader's mode, that they can load a custom css or not even load a css and set the font and size of their choice from their web client.
It’s still ugly as hell, the contrast ratios are godawful and it makes me question why I’d even do that to my eyes. Target or not, this is really hard to read.
Or... just hit the reader mode browser button that has been standard for years longer than LLMs have existed.
I had a coworker talking about how great some AI coding tool is because it can sort a bunch of strings alphabetically for him. This coworker is a programmer. Working with a language that has a builtin sort function.
I use Github extensively for my personal company, but I also use Azure DevOps (and all git-related features) extensively for a client's project. I keep seeing the Github issues being attributed to their move to Azure backend for "scale".
But we have no issues whatsoever with Azure Devops....ever. It's excellent. Seriously.
Does anyone know why the experience between Github and DevOps is so different, if they're supposed merging the two? Or at least seemingly related? Or are they not at all?
Or is it simply because Azure is "enterprise" and Microsoft cares about that more?
I find Azure DevOps UI/UX very janky. Like, the work items sometimes are loaded in the frontend only and sometimes there is a refresh, then the URL in the browser is not the same of the work tree I am seeing; sometimes there is a lot of flicker/redirects to sign in. The wysiwyg editor sometimes preserve the color themes of the person who opened, it seems. The markdown editor is view or edit only. I probably faced more issues but I won’t remember now. But to say there are no issues, and it’s excellent, I cannot relate, had to chime in. Yeah, it works, but feels like an unpolished product, especially considering the resources it has. The uptime is better than GitHub’s, though.
The flicker/signin redirects are a regression introduced post-Github acquisition. Really just evidence of the product being abandoned, or possibly of general operational decline at Microsoft which is affecting all their products. Definitely since the acquisition, both products have declined but Github has declined more to the point where I might prefer Azure DevOps.
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?
Copy the same way people can star projects to the new platform too, but maybe allow people to buy them directly from you to cut out the middleman. It could be very efficient.
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.
It’s not about ease of use and freemium, it’s the strong network economies at play, just like credit cards or social networks. It’s impossible for a competing product to get traction if it’s merely a little better than GitHub.
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.
I saw a thumbnail on Youtube that said "GitHub is killing open source" and I think the sheer wrongness of the statement surmises the entire idea very well.
There are many things that I don't like about Github, but I think the most important one is that Github doesn't allow users to have multiple free accounts.
You can create as many accounts as you want on Reddit, have as many blogs as you want on Tumblr, and even create multiple personae on Facebook on a single account, but Github doesn't allow you to do any of that.
You can't be a "hacker" platform when you give users less control over their privacy than Facebook provides.
I assume that is a bigger problem when you consider everyone decided to stop hosting their own forum and moving all their discussion to Github issues and Github's built-in forum.
> 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.
They've made a lot of progress in the recent years, and the last two major releases downright feel snappy compared to GitHub (really, browsing a repo tree is literally snappy). Oh, and their SPA implementation actually works, the back button is not broken 90% of the time like it is on GH.
And mind you, that's on a small 4 core VM on 2019 mid-range Xeons, which I would not consider to be a huge amount of compute (granted, not Raspberry Pi level, but I'd expect the SD card to be much more of an issue).
So yeah, along with the sane(r) way to do CI pipelines, and usable review tools, it's a net improvement over GitHub.
Through the magic of Claude, here is what the two hundred and eleven javascript files that GitHub loads on accessing an empty repo with just .md files (https://github.com/github-samples/.github):
┌─────────────────┬───────┬────────────┬────────────┐
│ Category │ Files │ Total Size │ Total Time │
├─────────────────┼───────┼────────────┼────────────┤
│ Copilot │ 32 │ 1,749 KB │ 1,141 ms │
├─────────────────┼───────┼────────────┼────────────┤
│ GraphQL / Relay │ 4 │ 1,629 KB │ 190 ms │
├─────────────────┼───────┼────────────┼────────────┤
│ Primer Design │ 4 │ 1,617 KB │ 329 ms │
├─────────────────┼───────┼────────────┼────────────┤
│ Highlighting │ 4 │ 1,048 KB │ 414 ms │
├─────────────────┼───────┼────────────┼────────────┤
│ Code View │ 14 │ 966 KB │ 1,226 ms │
├─────────────────┼───────┼────────────┼────────────┤
│ React Core │ 6 │ 692 KB │ 446 ms │
├─────────────────┼───────┼────────────┼────────────┤
│ UI Components │ 26 │ 674 KB │ 1,541 ms │
├─────────────────┼───────┼────────────┼────────────┤
│ SVG │ 2 │ 634 KB │ 51 ms │
├─────────────────┼───────┼────────────┼────────────┤
│ Code Editor │ 9 │ 615 KB │ 366 ms │
├─────────────────┼───────┼────────────┼────────────┤
│ Vendored │ 17 │ 608 KB │ 986 ms │
├─────────────────┼───────┼────────────┼────────────┤
│ Issues │ 13 │ 589 KB │ 504 ms │
├─────────────────┼───────┼────────────┼────────────┤
│ Markdown │ 8 │ 321 KB │ 198 ms │
├─────────────────┼───────┼────────────┼────────────┤
│ Runtime │ 12 │ 263 KB │ 807 ms │
├─────────────────┼───────┼────────────┼────────────┤
│ HTML Parsing │ 2 │ 235 KB │ 152 ms │
├─────────────────┼───────┼────────────┼────────────┤
│ Navigation │ 11 │ 230 KB │ 362 ms │
├─────────────────┼───────┼────────────┼────────────┤
│ Web Components │ 7 │ 229 KB │ 540 ms │
├─────────────────┼───────┼────────────┼────────────┤
│ Comments │ 4 │ 131 KB │ 146 ms │
├─────────────────┼───────┼────────────┼────────────┤
│ Analytics │ 5 │ 103 KB │ 348 ms │
├─────────────────┼───────┼────────────┼────────────┤
│ Other │ 32 │ 484 KB │ 2099 ms │
└─────────────────┴───────┴────────────┴────────────┘
Times given for a 150 Mbps WiFi connection.
Some personal highlights:
- Syntax Highlighting for every obscure language under the sun. Seems like the language analysis they do the repository does nothing.
- Shipping the editor on pages where there is no editor
- Shipping Copilot prompts. Incredible. { prompt:\"Analyze the test coverage of this codebase. Identify areas with missing or insufficient tests and add comprehensive test cases to improve coverage.\" }
- Just a javascript file with a massive 500K SVG.
- I don't really know anything about GraphQL & Relay. But 1.4 megabytes of generated ASTs?
> The increased ‘agentic’ load on github is the direct result of their own actions and those of their parent company, Microsoft, and that makes reliability problems their own fault.
Microsoft & Github are not a monolith. it's an institution with dozens of divisions and 100k+ employees all vying for revenue.
Anyone who's worked at a big company knows what it's like to be given an unfunded mandate to serve an important business strategy.
The author moans about the 3 copilot button's on github. meanwhile github has to manage (a) providing loads of free hosting and (b) keeping the servers up.
The entitlement to moan about a free app not providing enough free hosting, and bemoan the engineers who are barely keeping it running.
Author here. I am not a free GitHub customer. The only times I use GitHub are when my consulting clients do, who are by and large GitHub enterprise customers. It is not entitlement to complain about a company that you pay money for a service failing to provide that service by the terms of their own service lifetime agreement, something I point out repeatedly.
Github availability is driven by massive growth in the amount of work. I might add that is without a massive growth in the amount of accounts.. MS is struggling to make Github systems scale, clearly.
VS Code doesn't have a similar scaling issue that I see
I really have wanted to do this but Fossil lacks MFA, OIDC, and of course CI/CD. Maybe there's a way to get all three in it but Idk. I know for OIDC you could in theory just use a reverse proxy to do it but then you have to get Fossil to respect it and not just ask you to login again.
> 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.
The biggest shame is for Gitlab I think, if you ever try to run the service, empty, without any repository or user yet, you will need a very powerful CPU and already a dozen GB or RAM.
To do nothing...
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.
Will anyone who downvoted indicate why they've done so? I've never heard of Nostr, but this seems like a valid suggestion and point to be made, albeit at the expense of others' recommendations.
Nostr is like a decentralized message queue/database with cryptographic identities. It has been funded by Jack Dorsey. Its most common usages are a decentralized Twitter clone, a tailscale clone without any registration needed called NostrVPN, and diVine, a revival of the classic Vine service. But there's also very interesting stuff like this, a completely decentralized git that uses public relays and cryptographic identities to control ownership.
All this hate directed at github feels odd, every time I look into people complaining, or moving their projects off, other than a few related to genuine bugs, many just seem ideological. This article, calling it a crime against software? ... It's just silly. The article itself is a crime against articles, barely readable, weird ass colors. It mostly seems a regurgitation of other peoples complaints and mostly overblown.
We've been using github for a while at our company and find it really good. Copilot reviews are good, we have actions that work every single time, everything just works really well. There are, of course, plenty of things that could be improved, but it's still top dog in this space. I think maybe a couple of times there's been an outage that's affected us for a small amount of time. Overall, it's a good product.
Yeah, I didn't really like this post much. I agree the UI is bloated. But there's really two big factors here the post either ignores or doesn't empathize with, which I don't like:
1. The rise of Claude Code is what pushed this behavior, not GitHub and Microsoft's own actions. It is not because they shoved Copilot buttons everywhere, it is because a ton of people worldwide are autonomously pushing commits from Claude Code, and automated PRs/commits kicks off tons of other compute work that highly stresses a system that was never built for this scale.
2. The timeline is extremely compressed. Claude Code did not take off until late last Winter. So in one season they went from being able to mostly handle the volume of activity on their backend to an explosion of activity that shows no signs of slowing down. There is not a team on this planet earth who could foresee this circumstance and reimplement a massive distributed system like GitHub to handle the load gracefully in just a few short months. The writer of this post seems to think very highly of themselves as an engineer and my money is they would also be absolutely crushed by the nature of this challenge.
Author here. For those who don't care for the color scheme, my site has - a light theme: https://eblog.fly.dev/githubbad-light.html - a plain theme: https://eblog.fly.dev/githubbad-plain.html, added as part of the same update where I submitted this article. Both of those are available as PDFs as well (replace .html with .pdf).
And of course you can use reader mode in your favorite browser.
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.
would a self-hosted all-in-one solution be a viable alternative that doesn't split these all up into separate cloud hosted apps? it's been years since i've explored anything other than github/gitlab/etc.
Fossil does all of this, and has a better VCS for my use case than git does. https://fossil-scm.org
Right? Yeah, everything's decoupled and "flexible", but if your stack is dependent on half a dozen different third parties uninterested or uninvested in your project, you gotta watch like a hawk for when those services decide they need to be worse and charge more.
Like a hawk? If GitHub was down while you slept, would you notice?
Those third parties will be more invested in you as a customer than GitHub is.
> In proper tools that are designed to solve a specific need, not try to do everything: badly.
And when you want to search for that one thing that you know got documented somewhere, but can't remember where, how many systems do you have to search?
That's one of the reasons I like the code, issues, docs (code or wiki depending), and discussions all in the same repo.
Not to be confused with Chat, which is more ephemeral, and is, for us, in Slack. But we have to be mindful of chat discussions that turn substantive and make sure we copy that info to a Discussion in the repo (which can be annoying to do and annoying when it's not done).
> And when you want to search for that one thing that you know got documented somewhere, but can't remember where, how many systems do you have to search?
Not GP, but is that actually a real problem? Take a project like OpenBSD where the code, the bug tracking , and the design discussion happens in different place?
Even in reality, you don’t put the workshop in the conference room.
I don’t get it. That’s a lot of failure points to incur in the name of flexibility.
This isn't a direct answer, because I agree it is difficult to move away from Github's familiarities amongst developers - so it doesn't necessarily solve the problem for a collaborative codebase involving a handful or more developers (complete with Issues, PRs, etc) but if you are working with a less technical/developer oriented team ie- regardless of org size it's just you or maybe one other teammate who are the only ones involved directly in code/PRs then you can fairly trivially roll your own issue tracker or wiki.
Particularly if your work and the employer/client/org is primarily based on a web project (extra points, you already are managing their auth) then you could simply add a new subdomain or route to your existing web project that serves said self-hosted issue tracker or wiki.
Of course these things can get into the weeds but I do think that given the dramatically reduced turnaround times for a competent dev to spin up and customize in-house/self-hosted solutions for basic things like issues and wikis the strategy is more relevant and prudent than ever.
> Where do you keep Issues, Pull Requests, Wikis, Discussions, project boards, and everything else? (rhetorical question.)
I think it's worthy of a non-rhetorical answer anyways: https://docs.gitlab.com/user/project/import/github/#imported...
None of those might be perfect, but at least people are trying. Even something like Gitea and other forges that you can host yourself have support for most of the basic functionality you'd expect.
However, If we ever wanted a setup where it's easy to mirror rather than import stuff, we'd probably want to look in the direction of storing everything in folders within the repo, e.g. a file/folder for every issue, for every Wiki page etc. Most of the mirroring seems to only concern the repo itself, not the stuff around it, for example: https://docs.gitlab.com/user/project/repository/mirror/
This is the real issue. We’re currently migrating from GitLab+Jira to GitHub. I did most of the migration, including our CI/CD with a self-hosted runner, and it was… fine.
The straw that broke the camel’s back was that Claude managed cloud agents are awkward to use with anything other than GitHub. In general, we realized that the whole world was on GitHub and we were swimming upstream.
But the original mistake was separating issue tracking and source control when we didn’t need all that power. Everything is so much simpler if you don’t have to maintain those integrations.
Maybe they’ll really enshittify GitHub in the future. We’ll cross that bridge when we come to it.
I switched my personal projects to Codeberg recently and couldn't be happier. After spending lord knows how many hours wading through cluttered buggy interfaces in Github it's a pleasure to use a clean intuitive platform.
Years ago I was a big fan of Gitlab and always talked them up as a better Github. At this point though they've spent years trying to become just as convoluted and "enterprisey" as Github, but with much less success.
At this point why not just host your own gitea or something.
I'd also add tangled.org and radicle.dev. I've been looking into these new decentralized forges recently.
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!
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...
yes let's fix the lack of capacity by 3x'ing the demand to take down all of these other volunteer services , too
I've been an avid GitHub user for a very long time.
I remember way back in the "olden days" in San Francisco seeing people with Octocat signs on Market. GitHub was awesome. Fond memories.
But times are a-changin', and for lots of reasons I just don't feel like GitHub is cool or "for me" anymore.
So, with my new Mac Mini, because they were on sale and everyone was getting one for OpenClaw... I put that puppy on my tailnet, installed Gitea, and I've been using it exclusively for all my projects. It's been weeks since I've pushed anything to GitHub.
I feel free.
Hey, I know it’s supposed to be simple, but any chance of a write up of the macmini as a server approach? I would be interested in learning about the details of how you set it up. I would read this blog post if you ever write one!
If I had to guess, using tailscale is doing a lot of the heavy lifting here.
It is. I don’t have opened up to the wide internet, but it’s still super convenient to have it on my tailnet, which all my other devices are on, so I can review and manage repos wherever I am, while operating with the privacy of a self-hosted GitHub-like experience.
I was considering doing just this; I’ll spin something up soon. Thanks for the push!
Same here, I now self host Forgejo and Tangled Knot + Spindle.
Only use GitHub for employers at the moment, but don’t intend to put new code there going forward.
I know this is just a speculative comment, but the list of GitHub issues is eerily familiar. These problems read a lot like the types of mistakes and assumptions unattended agents will make that corrode codebases.
This web site is very hard to read because of the colors and font sizes.
I liked it. It has character.
I use firefox reader view for websites like this.
Had to zoom to 150% to make it bearable
It is targeted at tech literate people who obviously know about reader's mode, that they can load a custom css or not even load a css and set the font and size of their choice from their web client.
It’s still ugly as hell, the contrast ratios are godawful and it makes me question why I’d even do that to my eyes. Target or not, this is really hard to read.
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"
Or... just hit the reader mode browser button that has been standard for years longer than LLMs have existed.
I had a coworker talking about how great some AI coding tool is because it can sort a bunch of strings alphabetically for him. This coworker is a programmer. Working with a language that has a builtin sort function.
Plus the dozens of other means of changing a website's styling from the user's side.
Does anything wrap up the AI craze more succinctly than boldly calling AI the perfect use case for an already-solved problem?
“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.
I use Github extensively for my personal company, but I also use Azure DevOps (and all git-related features) extensively for a client's project. I keep seeing the Github issues being attributed to their move to Azure backend for "scale".
But we have no issues whatsoever with Azure Devops....ever. It's excellent. Seriously.
Does anyone know why the experience between Github and DevOps is so different, if they're supposed merging the two? Or at least seemingly related? Or are they not at all?
Or is it simply because Azure is "enterprise" and Microsoft cares about that more?
I find Azure DevOps UI/UX very janky. Like, the work items sometimes are loaded in the frontend only and sometimes there is a refresh, then the URL in the browser is not the same of the work tree I am seeing; sometimes there is a lot of flicker/redirects to sign in. The wysiwyg editor sometimes preserve the color themes of the person who opened, it seems. The markdown editor is view or edit only. I probably faced more issues but I won’t remember now. But to say there are no issues, and it’s excellent, I cannot relate, had to chime in. Yeah, it works, but feels like an unpolished product, especially considering the resources it has. The uptime is better than GitHub’s, though.
The flicker/signin redirects are a regression introduced post-Github acquisition. Really just evidence of the product being abandoned, or possibly of general operational decline at Microsoft which is affecting all their products. Definitely since the acquisition, both products have declined but Github has declined more to the point where I might prefer Azure DevOps.
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/
They didn't move primarily because of stars, they moved because they had been using Mercurial and most developers aren't familiar with it.
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?
Copy the same way people can star projects to the new platform too, but maybe allow people to buy them directly from you to cut out the middleman. It could be very efficient.
> everyone knows it's gamed anyway, so why not?
Arbitrage. Devs know its gamed. VCs less so.
Simpler answer: TINA (there is no better alternative)
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.
It’s not about ease of use and freemium, it’s the strong network economies at play, just like credit cards or social networks. It’s impossible for a competing product to get traction if it’s merely a little better than GitHub.
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?
You sound pleasant.
I’m actively working on a free and open source alternative Frontend for Forgejo that I self host called Joui
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.
I saw a thumbnail on Youtube that said "GitHub is killing open source" and I think the sheer wrongness of the statement surmises the entire idea very well.
There are many things that I don't like about Github, but I think the most important one is that Github doesn't allow users to have multiple free accounts.
You can create as many accounts as you want on Reddit, have as many blogs as you want on Tumblr, and even create multiple personae on Facebook on a single account, but Github doesn't allow you to do any of that.
You can't be a "hacker" platform when you give users less control over their privacy than Facebook provides.
I assume that is a bigger problem when you consider everyone decided to stop hosting their own forum and moving all their discussion to Github issues and Github's built-in forum.
Even ignoring the reliability and security issues, Github feels like an app from 2008.
Issues aren't a proper project management tool and wikis aren't fit as documentation.
I've completely abandoned Github.
That would be because Github was founded in 2008. Microsoft bought it in 2015 and hasn't done anything apart from restrict and milk.
Unlike sourceforge, how am I suppose to find new stuff when I am rate-limited after a couple of searches?
I’m in the process of developing an alternative Frontend for Forgejo that’s incredibly fast, and works perfectly well on Safari and Firefox.
Here is a screencap of the wip mobile UI on old safari: https://files.catbox.moe/bo7pxn.jpeg
> 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.
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.
Self hosted Gitlab is just as slow in my experience.
They've made a lot of progress in the recent years, and the last two major releases downright feel snappy compared to GitHub (really, browsing a repo tree is literally snappy). Oh, and their SPA implementation actually works, the back button is not broken 90% of the time like it is on GH.
And mind you, that's on a small 4 core VM on 2019 mid-range Xeons, which I would not consider to be a huge amount of compute (granted, not Raspberry Pi level, but I'd expect the SD card to be much more of an issue).
So yeah, along with the sane(r) way to do CI pipelines, and usable review tools, it's a net improvement over GitHub.
Its a 15GB docker image and is quite bloated in my experience. Probably moving to gitea soon myself.
Through the magic of Claude, here is what the two hundred and eleven javascript files that GitHub loads on accessing an empty repo with just .md files (https://github.com/github-samples/.github):
Times given for a 150 Mbps WiFi connection.Some personal highlights:
- Syntax Highlighting for every obscure language under the sun. Seems like the language analysis they do the repository does nothing.
- Shipping the editor on pages where there is no editor
- Shipping Copilot prompts. Incredible. { prompt:\"Analyze the test coverage of this codebase. Identify areas with missing or insufficient tests and add comprehensive test cases to improve coverage.\" }
- Just a javascript file with a massive 500K SVG.
- I don't really know anything about GraphQL & Relay. But 1.4 megabytes of generated ASTs?
- Shipping Protobuf, YAML, Lodash (hashing, unicode, collections), Typebox, GSAP and Framer
> The increased ‘agentic’ load on github is the direct result of their own actions and those of their parent company, Microsoft, and that makes reliability problems their own fault.
Microsoft & Github are not a monolith. it's an institution with dozens of divisions and 100k+ employees all vying for revenue.
Anyone who's worked at a big company knows what it's like to be given an unfunded mandate to serve an important business strategy.
The author moans about the 3 copilot button's on github. meanwhile github has to manage (a) providing loads of free hosting and (b) keeping the servers up.
The entitlement to moan about a free app not providing enough free hosting, and bemoan the engineers who are barely keeping it running.
Author here. I am not a free GitHub customer. The only times I use GitHub are when my consulting clients do, who are by and large GitHub enterprise customers. It is not entitlement to complain about a company that you pay money for a service failing to provide that service by the terms of their own service lifetime agreement, something I point out repeatedly.
My company recently forced us to move from Atlassian BitBucket to GitHUb. What a mess.
I hope vscode does not end up like this
This is my fear too. Feels inevitable tbh.
Github availability is driven by massive growth in the amount of work. I might add that is without a massive growth in the amount of accounts.. MS is struggling to make Github systems scale, clearly.
VS Code doesn't have a similar scaling issue that I see
Has anyone switched over to Fossil SCM, so they get issue tracking as part of the repo
I really have wanted to do this but Fossil lacks MFA, OIDC, and of course CI/CD. Maybe there's a way to get all three in it but Idk. I know for OIDC you could in theory just use a reverse proxy to do it but then you have to get Fossil to respect it and not just ask you to login again.
> 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.
those insulting graphs Microsoft put out with no labeled axes just shows how serious they are about all of this.
The biggest shame is for Gitlab I think, if you ever try to run the service, empty, without any repository or user yet, you will need a very powerful CPU and already a dozen GB or RAM. To do nothing...
Amen.
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/
Will anyone who downvoted indicate why they've done so? I've never heard of Nostr, but this seems like a valid suggestion and point to be made, albeit at the expense of others' recommendations.
Nostr is like a decentralized message queue/database with cryptographic identities. It has been funded by Jack Dorsey. Its most common usages are a decentralized Twitter clone, a tailscale clone without any registration needed called NostrVPN, and diVine, a revival of the classic Vine service. But there's also very interesting stuff like this, a completely decentralized git that uses public relays and cryptographic identities to control ownership.
All this hate directed at github feels odd, every time I look into people complaining, or moving their projects off, other than a few related to genuine bugs, many just seem ideological. This article, calling it a crime against software? ... It's just silly. The article itself is a crime against articles, barely readable, weird ass colors. It mostly seems a regurgitation of other peoples complaints and mostly overblown.
We've been using github for a while at our company and find it really good. Copilot reviews are good, we have actions that work every single time, everything just works really well. There are, of course, plenty of things that could be improved, but it's still top dog in this space. I think maybe a couple of times there's been an outage that's affected us for a small amount of time. Overall, it's a good product.
I remain happy with GitHub!
you and 99% of other people
bro needs to touch some grass
Yeah, I didn't really like this post much. I agree the UI is bloated. But there's really two big factors here the post either ignores or doesn't empathize with, which I don't like:
1. The rise of Claude Code is what pushed this behavior, not GitHub and Microsoft's own actions. It is not because they shoved Copilot buttons everywhere, it is because a ton of people worldwide are autonomously pushing commits from Claude Code, and automated PRs/commits kicks off tons of other compute work that highly stresses a system that was never built for this scale.
2. The timeline is extremely compressed. Claude Code did not take off until late last Winter. So in one season they went from being able to mostly handle the volume of activity on their backend to an explosion of activity that shows no signs of slowing down. There is not a team on this planet earth who could foresee this circumstance and reimplement a massive distributed system like GitHub to handle the load gracefully in just a few short months. The writer of this post seems to think very highly of themselves as an engineer and my money is they would also be absolutely crushed by the nature of this challenge.
GitHub enterprise is getting worse release after release. Cloud demand/usage spike is just an excuse.