And Now Everybody Together: Boooo GitHub

Wow. It seems like this month all the tech influencers simultaneously had the sudden realization that GitHub sucks now. Glad to see some people finally took off their rose-tinted glasses and come to terms with the reality that Microsoft, as foreseen, messed it up.

GitHub now is expensive, slow, unreliable, untrustworthy but just so happens to be a feature-rich quasi-monopoly, owned by and working for big-business, that doesn't give a flying fuck about you, your software or your company, is still carried and fueled by blinded fanboys whose public (and soon private) code in the background is getting used for training an LLM they then have to pay for, while Microsoft is riding out the wave of technical excellence initially brought in by those quirky out-of-the-box thinking top UX designers, engineers and product folks.

The only reason why it is still standing today is because it builds on top of the indestructible ingenious ingenuity of git, the result of a legendary burst of code output by a nerd who sat down and built a masterpiece in the discipline of software engineering which was born out of hatred and the necessity to sanely maintain and manage arguably the most important, oldest and still standing, complex code bases on the planet paired with the belief, experience & wisdom that there is, no, that there simply should be / has to be / must be, a better way to collaboratively develop software, only initiated by the knowledge and realization that as always, if you want something great and worthwhile, you gotta build it yourself.

As soon as M$ took over, I knew it was game over for GitHub in the long run. Only the unaware of the hip based and talented fresh university drop-out trying to bring their unique visions of how things should look like would ever go to and work for M$. I remember, especially in the OG Linux, free and open-source community there was a massive WTF going around and the overtake was met with skepticism in the mildest form up to outright protest and boycott, since those folks haven't forgotten (and never will) Steve's remarks of Linux being a "cancer" or M$ official strategy of "embrace, extend, and extinguish" to neutralize open source competitors by adopting standards, adding proprietary extensions, and locking in customers for eternity. Guess, what: I don't think their parasitic strategy changed one bit. They just ran out of the good faith and initial brilliance of the original project.

Fooling Around with GitHub Crashpilot

Recently I got more interested in reverse-engineering and sniffed around the GitHub search source code (so I can write better and more granular queries and not being hindered and blocked by their crap syntax, arbitrary caps, and can nest queries more easily) but turns out they built a custom solution named blackbird and outsourced half the problem to someone else. Anyways, I was just able to get to some internal search ranking aggregators until the constant "Do you want to use Copilot? Do you? Do you? Please start using Copilot" banners got on my nerve and I started taking apart the GitHub Copilot front-end as well which had minimal security measures in place, allowed for XSS and other fun code injections ultimately leading me to (partially) unlock internal admin access to not only see but change the system prompt, add arbitrary tool and access features reserved for M$ employees:

That's where I stopped digging further and left a message; also not gonna post a tutorial or howto. It's just to highlight that even big brands and flagship sites (if they annoy you long enough to spend the extra energy) leave plenty of doors open for you to walk through. Never trust a brand just because of their size or following.

How a Business Chooses GitHub

Funnily enough, a year after M$ took over, our company migrated to GitHub. Back then we were using BitBucket (which had its own immense set of unbearable stability issues) and the only reason why it was chosen in the first place and stayed for so long as our remote VCS system was because the founders, when setting up their first repository, searched for "free git hosting" on Google and clicked "I'm feeling lucky".

One hundred repositories and a couple dozen more technical people joining the company later, inevitably led to massive complaints about the inferior, feature-lacking, unstable BitBucket version control system, which felt like a BB-gun when directly compared to the flagship GitHub itself, bringing frustration on every failed push attempt, but mainly came to be because all those new engineers never used anything else but GitHub (which is crazy if you think about it). All they knew was that it works for their "Hello World" apps and that every other framework or package they ever used was hosted on it. Obviously, wherever the herd is flocking to must be the right way, no?

Tabs vs Spaces vs Both
by u/hongminhee in programming

Not long after, secret Slack channels were created, the usual tabs vs. spaces trash-talking began, pro-GH/anti-BB groups were formed, political momentum arose, and a push for change was reaching the technical leadership. So, to dissolve the ever growing frustration and negative mood, distracting discussions and destructive behavior, we looked into the costs of such an endeavor.

Pro-tips on: "How to Get Your Candy Bar"

You have no idea (well maybe you do) how well that strategy actually works in a business or company setting:

• Never mention any alternatives and present your option as the only true choice
  • Which is never true but with enough repetition of the statement and exerted influence becomes true enough
• Initiate a fully biased comparison and let it be presented by the biased group
  • This guarantees that outsider ideas, knowledge and perception won't make it to table in the first place! Brilliant!
• Frequently highlight the fact that you used it before, others are using it and doing the same to create FOMO
  • That is one of the best indicators that we are behind, trying to catch up, but instead of using this an opportunity to move ahead by exploring the fringes, jump down the cliff with the herd so not to be left alone. Anyone want some Kool-Aid?
• Never ever try to help the other side thus speeding up the decline by widening the cracks
  • If after years the neglected but 99% working system simply does not want to crumble and fall onto its knees (where it belongs), repeatedly hit it with a stick and poke in the holes. Eventually you will bring the number down to 95% and have a better case for the much needed change.
  • Constantly come up with new and absurd requirements that are only handled by the new thing but were never implemented, enabled or explored by the old thing to further differentiate your solution as clearly superior.
• Highlight the status quo as intrinsically broken especially when it's down on the ground
  • If a thing is framed as un-repairable and impossible to improve upon, well, the only choice left is to replace it. Even better if the thing you are trying to replace already was designed to break or to keep you locked in. I mean, if planned obsolescence has taught us anything then it is always cheaper to replace than to repair. Screw those right-to-repair hippies and constant nay-sayers who are just incapable, unwilling and unable to see how cool that new thing actually is.
  • Every time one of those nines isn't hit, make sure that everyone knows about it even though neither you nor them were affected. Then compare it to the fully unproven and fictional dream-world in your head by proclaiming: "This would have never happened with X" (replace X with your new thing).
• Downplay or hide all information that might indicate the current system is improving in steady paces
  • No doubt about it that going from 0-80% is a much greater feeling than to go from 95%-97% and obviously is a much greater leap of progress itself. Number is bigger, duh!
• Never mention the true costs of a migration and focus on a single easy to execute part while fully ignoring and omitting any integrations and other tangent parts of the system
  • Not adding it to the cost equation is the best way for your company to keep costs down. Simple.
• Never mention any maintenance costs either
  • You see, maintenance costs aren't real costs since that is stuff that has to be done, no matter what. And because someone already is taking care of it, it is being taken care of. I say: Work smarter not harder!
• Always leave the company before your decisions bear any consequences
  • Get hired, complain, nag, change everything, get praised, leave, repeat. Doing so will guarantee to be remembered as one of the best colleagues someone has ever worked with.

In any case, after we made the frictionless decision to migrate to GitHub (and a good extra year of finally having migrated all tangent systems) the storm was over, everybody was happy, and git push was working again (as before). Hurray!

And in case it's not clear: Don't the fuck be that person from above and instead play nice, think about the bigger picture, understand where others are coming from, make reasonable arguments, be honest with yourself and others, and you'll probably get your candy anyway since guess what: most people like sweets for dessert over a boiled potato.

A Trip Down Version Control Memory Lane

I witnessed and lived through a similar "discussion" and migration in the company prior where Concurrent Versions System (CVS) and notably Visual SourceSafe (VSS) was used to then migrate to a new more modern solution. Don't laugh at my age but listen to my experience and learn from my suffering. SourceSafe was a centralized, file-based version control system, funnily also acquired by M$, then re-branded and further developed by them. Instead of cloning and having a two-step process for publishing your changes, a check-out/check-in model with exclusive file locking was in place, preventing multiple users from editing the same file simultaneously. While simple to set up and back up (by copying the entire directory structures à la _2 and _final_last_copy_9), in multi-user environments you constantly were running into nasty database corruptions, had to walk over to your colleague, ask them to unlock their copy, fix the issue, and then continue. After many of those unbearable corruptions followed weeks of heated deliberations and eventually the company decided to start using Subversion (SVN) (followed by months of migration efforts and training sessions).

After being charged to take over some one-man project, but being faced with using yet another shitty VCS, I had a brief window of opportunity to start using git at work as I would at home. I sneakily installed, introduced and operated a GitLab server for that project, which later on, with the backing of our IT got adopted by them for proper hosting, then slowly made its way to other and new projects across the company.

Why Version Control Hits Different

I believe there is something about version control systems that make devs insanely irrational, emotional and decisions around what tool to use suddenly become personal. The reasons for that are the fact that VCSs are one of the few systems every software engineer is using on a daily basis, hence the (almost pathetic and weird) pride in keeping up your contributions streak.

Just ask them to run:

history | awk '{print $3}' | sort | uniq -c | sort -rn | head --lines 15

  1588 mise
  1382 sudo
   828 echo
   778 cd
   714 opencode
   684 ls
   528 docker
   492 uv
   466 cat
   392 ollama
   374 locate
   296 git
   290 curl
   250 which
   224 tmux

and I guarantee you git is probably in the top 10 of most used commands.

It is probably also the tool responsible for their biggest screw-up, finalized their greatest achievement, acts as one of the few constants between jobs and is used at home as for work alike. True love-hate relationships like that run deep and are deeply emotional affairs. Don't underestimate how much effort is needed to change or break apart that relationship.

There Have Been Alternatives, You Know

For over a decade now (and the last half of it reluctantly) I use GitHub but somewhere along the way I also (in parallel) started using self-hosted solutions and finally since this year fully switched to my own OneDev instance (80% of GitLab CE at 25% resource cost) as primary VCS hosting solution. It not only provides a remote git repository for my projects but comes equipped with (no credit bullshit, free) CI/CD, package and container registry, webhooks & notification systems, hierarchical projects setup with inheritance, plus stuff I haven't properly touched yet like issues with kanban boards, time-tracking and stats gathering. It really is a full-fledged DevOps platform keeping up to date by providing cutting-edge features like out-of-the-box MCP integration, Agents that read and understand your code bases, and allows for setting up Workspaces accessible from your browser to remotely run OpenCode, Codex or others similar to CodeNomad.

My point here is that I haven't seen a single influencer, while trash-talking GitHub, mentioning any of the amazing open-source alternatives like OneDev, sourcehut, or more focused and minimalistic ones like Forgejo, Kallithea, or more opinionated tools like Phorge and plenty others that are not named GitHub, GitLab, Gitea or Gogs! (I think the trick is to avoid anything starting with a G). Instead you are being directed to "the obvious" choice, but just like SVN was the obvious choice coming from CVS, or GitHub was the obvious choice coming from BitBucket, don't let your personal attachment and preferences, social/political pressure or influencers, blindside you from what's really out there and has the potential to push you forward much further and ahead of the curve if you would have just peeked outside the box or rolled up your sleeves to build the perfect-fit system yourself.

Stop whining. Do the research and peek outside the box. Make up your own mind.