Ben Busby | Projects, writeups, ideas, announcements, other random junk

GitHub vs GitLab vs SourceHut

19 Oct 2022

I’ve written a few different iterations of this post, and each time I end up feeling dissatisfied because it either A) comes across preachy and biased, or B) sounds too unbiased and robotic. This is my attempt at explaining some pros and cons of the services mentioned in the title and explaining why I use each one, without rambling too much. Like my last post about SourceHut, this won’t be a super technical overview of any of the three, but rather just my opinions after having used all three for a decent amount of time.

For background, I use at least one of the three services — GitHub, GitLab, and SourceHut — on a daily basis. Most of my projects are currently on GitHub, with new ones being created on (and existing ones migrating to) SourceHut, and private contracting projects being hosted on GitLab. I feel that I’ve spent enough time with these three services to talk about the pros/cons of each and why you might want to use them. If you want a TL;DR, feel free to skip to the bottom.

GitHub

GitHub offers a lot of the same basic features that GitLab does, but with a more generous free tier. You have individual repos with issue tracking, milestones, pull requests, wikis, CI (via GitHub Actions) etc. All of these work pretty much as expected without any surprises, although using GitHub Actions can feel like you’re spending time learning something that won’t translate to other services very well, which may or may not bother you. If not, you might actually like GitHub Actions. There’s a huge marketplace for Actions that make throwing together a decently complex CI build a lot faster than it would be otherwise. GitHub also offers “discussions” per repo for users to talk or ask questions without having to open an issue. I’m sure this feature is useful to some projects, but I’ve found that I prefer issues since I can usually just answer the user’s question and close the issue, removing it from the view altogether. Fragmenting user interactions between two different tabs just means that I only check one of them, and 99% of the time it’s going to be the issues tab that takes priority.

Nothing so far has likely sounded like a standout feature that explains their success, but GitHub is the most popular service out there for a reason. In my opinion, that reason is its introduction and continued development of social media features. I don’t exactly know the timeline of who introduced things like followers, star counts, etc but GitHub is indisputably the platform that sees the most interaction with these features. This is both a good and bad thing. The good side is that you have the highest likelihood of having your project noticed and gathering potential contributors to help you out. Your followers might star your repo, which their followers would see, and the more interaction with your project, the more likely it is to end up on a list of daily featured GitHub projects somewhere. The bad side is that this can encourage a pretty unhealthy relationship with writing code. If you put out a project that doesn’t get as much attention (according to stars/forks) as other projects, it can feel like you’ve wasted your time on something that nobody cares about, even if the goal was to just make something for fun.

Beyond just the standard social features, there are things like achievements, which I find so weird and am curious who actually asked for something like that. I know it’s just another attempt at gamifying software development, but it really rubs me the wrong way. There are achievements for things like closing an issue within 5 minutes of opening it and merging a PR without reviewing it. Why? I get that some people really like this sort of positive reinforcement in the form of little awards and whatnot, but I just view it as cheapening the entire experience.

And then there’s Copilot. I can’t go into all of my reasons for not liking Copilot here, but Drew DeVault did a great job in his post here if you’re interested: https://drewdevault.com/2022/06/23/Copilot-GPL-washing.html

I guess my relationship with GitHub is fairly complicated. I do actually think it’s one of the easiest to use “git forges” out there to get started with. You can create a repo and automatically have things like an issue tracker, interface for PRs, etc set up for you so that you can just focus on writing code. There are tons of integrations with GitHub out there for extending functionality (such as with code quality tools, external CI services, etc) and repos are typically automatically set up to receive alerts when dependencies become outdated or have vulnerabilities revealed, which can be nice. And if you’re anything like me and don’t spend a lot of time socializing with other devs, it can feel validating to have positive interactions come from GitHub’s social features for projects that you release (although as I said earlier I think this is unhealthy in the long term).

But perhaps the most important component to me is the GitHub Sponsors feature, which allows users to give either a one-time or recurring donation to you to say thanks. I can’t express enough gratitude for the people who have signed up to sponsor me on GitHub. But between the unhealthy insistence on social features and the fact that GitHub itself isn’t open source, I find myself noticing that GitHub as a product doesn’t really align too well with my personal values and interests. I don’t like social media and don’t like associating my value as a developer to my follower count or which of my repos has the most stars, and I don’t like hosting open source code on a closed source platform.

SourceHut

I already covered most of my impressions of SourceHut in my last post, and not much has changed since then, so I’ll keep this fairly short. Overall I’m still a happy paying user of SourceHut, but with the same gripes as before.

SourceHut’s main flaw in my eyes continues to be its weird insistence on one-way navigation between the different components of a project. I sometimes feel like I’m going crazy when I point this out, because aside from this short thread there doesn’t seem to be anyone else pointing out how confusing it is to not know if a git repo is part of a larger project or not. It’s quite odd.

I do like the separation of lists vs todos (issues). This is similar to the distinction seen on GitHub for discussions vs issues, but lists on sr.ht feel less like customer support and more like an honest discussion. The two are actually meant to be used together, from what I can tell. There’s an expectation in some projects that you don’t create a new issue/todo for a project on SourceHut until you’ve submitted your report through the proper list first. This just seems like a headache for maintainers, since a lot of users likely don’t want to have a discussion about the issue before reporting it. I get that it’s better in theory, but in my experience most users just want to leave hit-and-run bug reports, which I think are valuable. If the user didn’t provide enough info, or if it’s a duplicate, just close it and move on.

Speaking of user interactions, I’m still quite curious how well/poorly my experiences will be with accepting contributions from users. SourceHut has an emphasis on email driven contributions using git send-email to submit patches and whatnot, but now there’s web based tools for submitting and reviewing patches, so I don’t think there’s an excuse to point out the email workflow as a negative anymore.

SourceHut also offers things like paste.sr.ht for hosting snippets of code/text, chat.sr.ht for a hosted IRC bouncer, a really powerful CI service, and is completely open source. It’s all great and works phenomenally well, aside from the weird navigation quirks. Like I’ve seen others do, I’ll probably just insert a table at the top of each README for navigating between the project’s home page, mailing lists, issue tracker, git repos, etc.

GitLab

In my time as a freelance developer or “consultant”, I most commonly work with clients that either already have a repo hosting service that works for them (which in the overwhelming majority of cases is GitLab, in my experience) or clients that are not particularly technical but want to easily be able to see a rough overview of things like issues, milestones, and the code itself. In the latter case, I find GitLab to be the best solution. It has a design that seems to click for non-technical people, probably due to its straightforward “Group” structure for single projects with multiple git repos.

Say I accept a contract to develop Project X for a client. I can quickly create a Project X group on GitLab, with its own issue tracker, milestones, and individual git repos (separate frontend and backend repos, for example). The group issues can be used for high level features that the client wants to see in the end product, with higher fidelity issues kept in the appropriate git repo’s issue tracker within the group. For example, if a client wants “User Profiles”, I can create a “User Profiles” issue in the Project X group issue tracker, but then break that out into more meaningful tickets for the project’s individual repos to actually capture the work required for that feature. Likewise I can tie group-level issues to a milestone that a client can visit to view progress on items without having to send me an email asking about progress on something.

From a technical standpoint, I think GitLab is fine, but not great. Their CI support is clearly something that they view as their “killer feature” (since they’re rebranding as THE DevOps Platform now), and I’ve always found it to be fairly intuitive. They have a lot of easy-to-set-up integrations with services like Jenkins as well, if you prefer a different build service. Each repo can also have it’s own wiki, but that’s a pretty standard feature nowadays.

GitLab also has a lot of drawbacks that shouldn’t be ignored. The one that bothers me the most is just how slow it typically is to use. Navigating between pages, especially on an average or slower than average connection, can be pretty frustrating. Page load times are the slowest of all three services, taking ~6.4s for a page to become interactive. If you’re rather impatient like me, this can be a pretty huge deal breaker. GitLab also has a ton of features that likely only appeal to enterprise (or “power” users), such as time tracking, feature flags, Kubernetes (even when it makes no sense for a particular repo), value stream analytics, incident monitoring, etc. This is basically all just clutter on top of an already cluttered view for non-enterprise users.

GitLab is also prohibitively expensive to use if you want their premium features (25x CI minutes, merge request approval rules, advanced CI/CD). They charge $19/month per user, and limit their free tier to 5 users per namespace. So unless you can afford it, or are working on smaller projects, or don’t care about their premium features, then GitLab isn’t the right choice.

Perhaps above all else, I don’t think they’re a trustworthy company as of recently. I find it shady to make major changes to free tier features in an effort to shove people into paid tiers or off of the site altogether. I also didn’t like how they announced they were going to delete all repos that they deemed inactive, and then suddenly U-turned when people were rightfully upset about that. It just isn’t a good look.

Ultimately, GitLab is my least favorite. Despite the ease of navigation that some non-technical clients have mentioned, I don’t think that alone is enough to get me to stay. It’ll likely be replaced by SourceHut for me.

TL;DR

GitHub

Pros:

  • Ubiquitous
  • Easy to use
  • GitHub Sponsors
  • CI is pretty good

Cons:

  • Way too many social features
  • Closed source
  • Increasingly frequent outages
  • Copilot (will expand on this in a future post, maybe)

SourceHut

Pros:

  • Simple and fast UI
  • Powerful CI
  • Logical structuring of projects and components (lists, todos, sources, etc)
  • Actually open source
  • IRC services
  • Can configure whatever tools you need for a particular project
  • Doesn’t require an account for users to open issues or participate in discussions
  • Paid, but affordable ($2/mo)

Cons:

  • Weird unidirectional navigation from project page
  • A bit more setup up front per repo for adding issue trackers, lists, etc
  • Perhaps a bit sterile for some
  • Small learning curve if coming from GitHub/GitLab/etc

GitLab

Pros:

  • Group-level issue and milestone tracking
  • Possibly more intuitive for non-technical individuals (in my experience)

Cons:

  • Slow
  • Too many features for non-enterprise usage
  • Not trustworthy for long term use
  • Not priced appropriately for non-enterprise usage

Questions? Comments? Reach out!
Back to Home