GitHub seems to have become the de facto industry standard. Personally, I’ve gone from a fan, to a critic, to - now - an escapee. Here’s why.
In the beginning
I’ve been a GitHub user for a while.
I joined GitHub on May 5th, 2011. I was a student at the time, and I was looking for a place to host my projects. I was already familiar with Git, and I was using it for my projects, but I was hosting them on my own server. This sometimes made it hard to share them — getting a course professor to clone a repository or download anything from a random-looking server was not easy. It was even more fun when my server went down… right as I was supposed to turn in a finals project. I won’t soon forget those 15 frantic minutes of SSHing to my router, trying to figure out what was up with the routing table.
Then someone told me GitHub existed. Not only that — the professors already trusted it. They even knew how to clone. Not to dunk on all of my professors, but for some of them - learning they were capable of interacting with technology built after 1990 was astounding.
So I put classwork there. I started putting random personal projects there. Funnily enough, someone (hi, Andrzej!) found my personal stuff there, thought it was rough but had promise, and offered me my first Ruby job. In a very real way, where I am today - and who I am today - I owe to GitHub.
I’m saying all of this, so you can understand I’m not making this decision lightly. GitHub has been a part of my daily routing for twelve years. It’s the one tool that stayed with me for almost all of my professional career.
But now I think it’s time to move on.
Oppressive UI
I remember when GitHub looked like this (screenshot lifted from here):
Ah, the charm of websites around 2013. A cluttered, dense mess. So glad it has turned into this along the way:
Would you look at this? A cluttered, dense mess with two columns. Progress!
Static noise
I am being facetious, of course, but only up to a point. This page is incredibly noisy. My eyes are darting around: do I want to click one of the buttons near the top? The buttons below that? The buttons below that? Contributors, languages, releases, blatant advertising - ahem - packages… There’s a lot going on here. I am not put in a cool, analytical mood by this page. I am unnerved.
Gamification
I use GitHub for work. I don’t know about you, but most of the time, I work at work. I don’t need a participation trophy every time I do a thing, and even if I did - I’d like one from a human, not from a robot.
Explain to me then, what is the purpose of all this tosh?
It serves no purpose, other than to pluck at the strings in my head which make me want to play with a system like that. To min-max. To trigger the conditions in which a colorful circle will pop out. Please, for the love of - I’m enough of a completionist as-is. Do not give me yet another collection of meaningless baubles to complete.
Competition
We’ve had “complete”, how about “compete?”
This is the competitors - ahem - contributors list. There’s one on every repository, even the ones I use at work. I sort of see a reason for it to exist. I see, however, zero reason for it to be ordered in the order of most contributions.
Almost any other order wouldn’t bother me. By first contribution time, if you want to keep the “competition” going would
be better than this. Even better? Alphabetical. I’ve already all but conceded that my parents lost that competition
for me, giving me a name starting with a P to go with a surname starting with a W. Most importantly, however, it wouldn’t
make me try to top the list.
And I did. It’s pointless and foolish, and oh boy, did I get a rush when I finally unseated the original author of a certain repository at work as the top face in that box. I gamed my pull requests to have more commits than I otherwise may have created to get that top spot. My only excuse is that when I did it, I was the only contributor to the repo, so nobody suffered for my shenanigans. But I still did it for the sole purpose of getting that top spot, and I am ashamed of it.
Social pressure
Then there’s this gem:
There was a time when I pushed myself into… well, pushing to keep my “streak” up. I viewed my colleagues’ engagement — nay, their very worth — by their contributions in the current year. By extension, I also viewed my worth through that same prism. In a way, I also treated this as a competition, and I strove to win. By any means necessary.
You may put this on me — after all, I kind of did this to myself. But what I’m trying to point out is, if you’re already in a frame of mind receptive of this kind of stuff, it can get to you. It can affect your work patterns, your thought patterns. It affected my sleep patterns for a while.
This serves no purpose, and is not healthy.
Vestiges of the past?
While the contribution graph has been a mainstay for years, the contributors are relatively new - they’re nowhere to
be found on the 2013 screenshot. Oh sure, there’s the Network tab, but I could choose to not go there. I can’t choose
to not go to the main page of the repo. I can’t fully avoid my own profile, either.
These pressure-generating items were purposely surfaced. Achievements were added. If anything, this is a portent of the things to come, not some leftover from an early days GitHub. I have no faith it will get better. I fully expect this may get worse.
Git-centric world
Every organization should use source control. Every solo developer should use source control. I don’t believe this is a hot take, it shouldn’t be anyway. So why is Git so prevalent?
GitHub’s network effect
These days, almost anybody who’s not a very junior developer - and an increasing number of those, too - seems to have a GitHub account. That’s where your prospective employer will go look for your code (unless you explicitely add a link to your GitHub in your résumé).
I believe this — and by extension, that so many organizations gravitated towards Git itself - is due to GitHub’s network effect. For a good long while, running an organization with private repositories was free. And most people “in power” to make such decisions already had GitHub accounts.
Now, get ready for the hot take: as far as source control goes, Git is… honestly not that great. Okay, pitchforks down, everyone. But seriously:
Git is not that great
Git is software built for a purpose. That purpose is the development of the Linux kernel. It goes to great pains to fit in with that crowd: it’s extremely powerful, its internals are brilliant, and it is an absolute pain in the neck to use.
Ever screwed up a merge? Or a rebase? Let he who didn’t cast the first stone. While I can be a bit dense, I don’t believe I’m all that dense. And yet I managed it. I still manage it. After well over twelve years of working with Git daily. That just means that the UX is arcane enough that someone who has muscle memory for this stuff still manages to shoot themselves in the foot.
It almost reminds me of the C programming language. Power galore, but oh my word, the footguns.
The cathedral and the bazaar
Yes, I’m pulling out this tired old analogy. Git is definitely targeted towards the bazaar model of building software: many developers, distributed across timezones, and - crucially - of disparate trust levels.
In the bazaar, there’s the “cans” and the “can nots”. The maintainers, who have the final say over what goes into the “trunk”, and what does not. This works brilliantly in open source; after all, someone should keep an eye on what goes into the builds, so no bugs (intentional or otherwise) make it through.
Another hot take: most organizations are not bazaars.
Pull requests: a fit for bazaars
Everywhere I worked, my colleagues and I were building a cathedral instead. There was a small group of people, usually under single-person direction, with implicit trust being placed in every single one of them. We still used pull requests, because everyone used them - another example of GitHub’s network effect. Their proposed way of working became the way to work.
Pull requests considered harmful
Now this hot take takes the cake, I know: I don’t really like pull requests. A pull request implies a power dynamic - the requester and the approver. The powerless and the powerful. If the repo is configured this way, the requester cannot proceed without approvals. It’s a power dynamic taken straight from open source development, with the requester being more or less in the place of the “can nots”.
The lack of trust
This implies a relationship lacking trust. The powerful gatekeep merging from the powerless. Note that I’m regularly on both sides of the equation - I’m not griping about it because it sucks from “my” side. It sucks from both sides.
I would absolutely be happy to discuss code with my colleagues. I’m a nerd, I love this stuff! But we could have a discussion on equal footing, instead of introducing power dynamics.
The lazy review
Again: let he who has never just slapped an approve of something cast the first stone. Pull request reviews happen in the browser a lot. That’s not where I code; that’s where I read. Ruby has fantastic readability, but if I don’t run the code, I may well miss something. In a way, pull requests encourage me to be a lazy developer.
If, instead, someone asked me to discuss their code, I’d have to pull it. And since I already have it on my machine, I may as well run it. It would encourage me to be an active discusser instead of a lazy reviewer.
But it’s easier!
Yes, it can be argued that GitHub’s pull request review tools make commenting on code easier. That’s absolutely true. But equally, GitHub’s dominance made everyone else copy their approach instead of coming up with their own, novel ones. GitLab copied pull requests and called them merge requests, for example. That’s not because they came up with it. That’s because GitHub does it.
Some GitHub tools are terrible
We’ve discussed PRs. Now allow me to take a stab at some other grudges I have.
Actions are bad
In so many ways, too. I’ve never managed to create a GitHub Actions flow, run it, and have it work the first time. They run code from a YAML, of all formats, in a virtual machine somewhere. You better hope you added everything that you needed to that YAML, too. Even GitLab gets it more right, allowing to run specs in user-specified Docker images. Instead, on Actions, I’ve seen so many flows which just pull and set up a custom Docker container in the arcane YAML, then run the specs in that. Why couldn’t we skip a step?
Actions Marketplace is a security risk
Does this even need explaining? It’s random code, pulled from elsewhere on GitHub (usually), which runs in your CI environment with access to your CI secrets. The entire security risk is on you. It’s also on you to check what you install, is it definitely the official one, and pin the versions accordingly. That this even exists is mindboggling to me. I feel queasy using them.
Why does the CLI even exist?
Yes, GitHub has its own CLI. No, I don’t know why. It’s supposedly for pull requests and issues.
I see no reason to use it. What I see instead is the prelude to the next “browser wars”, in which GitHub decides that the standard (in this case, Git) is all cool and nice, but to use GitHub, you need GitHub’s Git. Like you needed IE to see all the IE-specific stuff in the 90s. Oh look, it’s owned by the same company now, too.
It’s not all bad
I actually quite like Copilot. I’ll probably talk about it more soon. Just in case you thought I hated on everything GitHub did on principle - no, I don’t. I can admit they have some compelling stuff. It’s just usually not the stuff I interact with the most, thought that is changing.
Where do I go from here?
I’ll still be using GitHub at work. This is non-negotiable, and I see it as a necessary evil. You know, jobs come with expectations - like wake up before noon, and use GitHub.
I’ll still be using pull requests at work. This is non-negotiable, too. But to put my money where my mouth is, I’ll try to be more of an engaged commenter, rather than a lazy reviewer. It will take undoing years of practice, but I think everyone will benefit from it in the long run.
As for my personal stuff - I’ve migrated most of it to SourceHut. At least the stuff I care about and I’d rather there be a copy somewhere outside machines I control. For less-important stuff, I’m currently evaluating several self-hosted options. There’s also the possibility of not hosting it anywhere.
With regard to git-centrism - I’ve started playing with Mercurial. After years of Git, it feels pretty foreign, but I’m slowly picking my way through it. Muscle memory is not helping.
I’ll let you know how I get on. Maybe there actually is a world outside GitHub and Git itself.