GitHub and GitLab logos side by side
The Run Time (fair-use)

I quite like GitLab for a number of reasons, but before I ever knew it existed, I was already deeply embedded in GitHub’s ecosystem. The TL;DR of this blog post is that GitHub’s network effects and ubiquity outweigh GitLab’s technical advantages for my own open source projects.

I was not particularly bothered by Microsoft’s acquisition of GitHub, despite a general bias against Microsoft for political and technical reasons. At that time, it did not seem like MS was particularly interested in changing GitHub’s culture or direction, and MS being more invested in open source was a welcome development.

But the recent immersion of GitHub into MS’s AI division, with GH no longer having a CEO or even the pretense of independence, I find myself wishing I was rooted on another platform.

For this reason, I had a stop-and-think about this subject before I released a new bunch of codebases on the platform. I gave it enough serious thought and did enough research to feel like it makes a nice, short blog post that maybe nobody should be particularly influenced by.

The Comparison

There are a lot of “content marketing” articles out there that claim to help you decide for your own case. This article is not one of those. I never know how much of those articles is sponsored content or SEO gaming or just AI slop that may or may not be true.

Really I am just documenting my own decision for accountability.

My decision took into account a peculiar use case: different (non-developer) audience, strong technological opinions, and a need to grow a community around the work.

My own research involved a marathon ChatGPT 5 session evaluating numerous aspects of the two platforms.

Here is a table ChatGPT made to represent the assessment that I led it to through interrogation and testing of its assessments.

Criterion GitHub GitLab Win

Account friction

Ubiquitous accounts

New signup needed

Discoverability

Strong social graph

Limited visibility

PR/MR workflow

Simple & familiar

Powerful but heavier

AsciiDoc Support

Modest

Strong

Issues/Discussions

Familiar, lightweight

Powerful but heavy

Browser editing

Seamless

Full IDE, slower

Incentives

Global profile value

Siloed

I weighed a couple of these criteria a lot, including AsciiDoc support and PR/MR workflow. (I even dislike the term “pull request” and would much prefer GitLab’s “merge request”.)

GitLab has better aesthetic (“front end”) support for AsciiDoc rendering, and it supports the powerful include:: directive.

Then again, since I want all of my frameworks and strategies to be GitHub friendly, I really should not actually take advantage of major (“back end”) features that GitHub does not support.

When it comes to actually generating user-facing documentation, neither platform matters. This criteria is just about how it renders READMEs and displays browseable source files. (Truthfully, README files should not employ transclusion, anyway.)

The same is basically true for workflow features like pull request/merge request process or UI tools. Either people can use the excellent tools and interfaces GitHub provides, or there really is no reason to believe a push for code-like practices by non-developers is viable.

I rightly will not be able to control or really even influence where people choose to host their own projects that employ the techniques DocOps Lab exists to promote. Most will choose GitHub, so everything we are trying to prove and demonstrate should probably happen on GitHub.

The Conclusion

In the end, I have decided that since I have no gravity of my own to draw people to a platform, I should not add variables (“friction”) to this endeavor that might disadvantage it any further than its starting point.

If my work somehow engenders a draw of its own, perhaps the community could make a project of migrating to a platform that is not owned by a publicly traded corporation in the first place. For now, it seems like GitHub is the best path to popularizing tools and techniques that most people will invariably practice on GitHub.