Moving gotop to Sourcehut

I recently relocated a project I maintain, gotop to Sourcehut. I was asked “why”, and this blog is the answer.

Microsoft acquired Github in 2018, and started enshittifying it immediately. Click here for a larger version Github’s uptimes were consistently high until the acquisition and started dropping just after the acquisition. Rumors are currently circulating on social media that the outages are related to an Azure migration, but the uptime history tells a different story: Microsoft ruined Github’s uptime record. More recent has been the invasive force-feeding and subsequent decline of Copilot on developers, including surprise pricing changes and degrading performance; this is above and beyond the fact that Microsoft is using Github as a giant data farm for LLM training, including scraping privte repositories hosted on the platform.

Now, I don’t so much object to Microsoft using OSS projects hosted on Github to train their LLMs: github is a free service, and if you’re going to use free services under capitalism, you have to accept that you’re going to be productized. In the US it’s becoming increasingly expected that even if you pay for services, you’re going to be productized too, but I feel justified about getting indignant about that.

In any case, I do not want to be a product. I had almost entirely migrated to Sourcehut even before the acquisition, because Sourcehut supports Mercurial but also because it’s a better service. Gotop remained on Github, though, because gotop was popular enough to have widespread packaging for multiple distributions; packagers have hard enough lives doing thankless jobs without project authors yanking their chains by moving source code around. Eventually, though, the combined pain of having to use both Github and git for gotop overwhelmed my altruism: after a few years of avoiding working on gotop just to avoid having to deal with git and Github, I’m finally relocating gotop. Sourcehut’s CI is better, its collaboration is better, it has mailing lists and web hosting and an absolutely lovely, Javascript-free, user experience – and it supports Mercurial repositories.

Which brings me to Mercurial. Thanks to Linus and Linux, git won the VCS popularity contest. Popularity has never been a reliable metric for quality, and it certainly wasn’t reliable in the VCS wars: Mercurial is more sane, more easy, and more secure git supports destructive history rewriting, allowing developers to change history including fabricating authorship, and catching these sorts of changes requires a level of git expertise which can not be assumed for most projects. than git. I’ve spent more aggregate hours fighting with git and being uncertain about whether what I was doing was going to break git history, and I just don’t enjoy fighting with my tools. Jujutsu goes a long way to making git less hostile, but it can’t entirely hide the fundamentally… well, I won’t say “stupid”, but how about “unnecessarily complicated” git mental model. It’s not as if git does anything useful with all that complexity; it’s not even as sophisticated as Darcs or Pijul. It covers essentially the same problem space as Mercurial, but in a far more byzantine way.

This is all highly subjective, and most of you will be shaking your heads in violent disagreement, at least about the git part. But this is my fork of this project, and I’m not going to make myself suffer for something I’m not getting paid to do anyway.