SourceHut Impressions

03 Aug 2022

For >1 year now, I’ve been strongly considering migrating some or all of my repos from GitHub to SourceHut. I had been putting it off for some time, mostly due to the push-back I’ve received in emails and comments whenever I’ve mentioned leaving GitHub. As a middle ground, I decided to set up a two-way mirror of a few of my repos, which are all synced after an update to a repo on either SourceHut or GitHub, while I decide what the best next steps are.

I won’t go too deep into the reasons why I’d like to leave GitHub – at this point I think most people either get it or they don’t/won’t. I’ll save my reasoning for another post, but for now I’ll just say that I disagree with a lot of GH’s business decisions and that I think the platform encourages an unhealthy relationship between a developer and their work. I’m also not going to go into detail on why not GitLab (or Gitea/Gogs/Codeberg/etc) in this post.

Now that I have a few repos on SourceHut, I’ve had a chance to get a rough idea of the feel of things, as well as the tools available to be a maintainer of a project. Fair warning: this is going to be more of a reflection on how I “felt” using SourceHut, nothing overly technical. I’d like to save that for a future post once I’ve spent more time with it. This is more for GitHub devs who are curious about SourceHut but haven’t tried it.

Appearance/UI/UX/etc

I love the minimalism of everything on sr.ht. There’s no star counter, no following/follower count, no “achievements” (gross), no profile pictures, etc. In general, I’ve gathered that Drew Devault (the founder) has a disdain for “faffery”, so this didn’t really surprise me. SourceHut does, however, walk a very thin line between minimalist and clinical, which I’m usually grateful for, but sometimes it feels a bit too cold. I find conversations with users to typically be very enjoyable when all parties involved act as if we’re all human beings talking to each other as we would in person. Without profile photos, and with most users using pseudonyms when reporting issues, the interactions feel even more detached.

At this point the easy counterarguments are either A) “if you want to talk with actual people, just go on social media” or B) “a Git forge shouldn’t have social components, it should just be about code”. Or both. And I actually agree with B to an extent, but everyone has their own opinion of the right balance to strike between purpose and enjoyment of a product. In my opinion, SourceHut nails the purpose of their UI and usability, but falls short in creating enjoyable experiences with other users (for someone like me, who enjoys those interactions).

Despite my complaints, the simplicity of SourceHut’s presentation was my main reason for becoming a paid member over a year ago. Most of the time, when I want to work on one of my open source projects, I don’t want to feel my brain chemistry change when I see an increased star counter, or number of forks, or new followers, or anything aside from just the code and the todo list for the code.

Functionality

A big part of SouceHut’s functionality is strongly tied to its proposed structure of projects. You can have a standalone git repo, but the (seemingly) preferred way to host a repo on SourceHut is to organize it as a top-level project with other services implemented as needed. For example, the structure of Farside looks like this:

Farside (the project, on sr.ht)
- Farside (the git repo, on git.sr.ht)
- Tickets (on todo.sr.ht)
- Mailing lists (on sr.ht/~benbusby/farside/lists)

Tickets and mailing lists are both optional, which makes it possible to host a git repo on SourceHut without actually having a way to file tickets as a user of that repo. I don’t think this would ever be a recommended use case, though, unless you plan to have a separate ticket/bug reporter outside of SourceHut.

Overall I really like the structure that SourceHut provides, but at the moment, I find it very hard to navigate. For example, how do you get from the git repo for a project to the issue tracker? Right now, you basically just don’t. If you click the maintainer’s name, you’re taken to their home page on git.sr.ht. But the issue tracker is only on todo.sr.ht, and most easily accessible from the project page on sr.ht, so my approach at the moment is to go to the user’s git.sr.ht home page, remove “git.” from the URL, and then navigate to the project page. I recall seeing somewhere a while back that this was being addressed, but I don’t know what sort of priority it’s being given. In its current state, it ruins the otherwise excellent approach to structuring a project.

I unforunately can’t say much about builds.sr.ht, the CI service that sourcehut provides, but I do enjoy what I’ve seen so far. It seems to be a much more straightforward approach to writing multi stage builds, rather than the bespoke experience that GitHub Actions provides. I will say that anyone who creates software for macOS or Windows will need to look elsewhere, and at the moment there doesn’t seem to be support for nightly/scheduled builds. Both of these things are dealbreakers for a game that I’m currently working on, but likely not dealbreakers for the majority of developers.

There’s likely other functionality that I’ve missed in my initial experience with SourceHut, but that can be saved for a future post once I’ve spent more time with it.

Contributing and Mantaining

Both contributing to and maintaining a repo depends on a primarily email-based workflow. I don’t have a strong opinion on this, mostly because I primarily only work on projects that I created/maintain, but also because I don’t have very many outside contributors to my projects (if you’re one of the them, please know that you’re greatly appreciated), so the number of people who would potentially complain to me about the increased friction of learning how to send patches over email is likely very small.

While I do understand the reservations that some have regarding sending patches over email, I’d highly recommend trying out the guide here: https://git-send-email.io/ to see just how simple it really is. It doesn’t include a portion on how to review patches that you’ve received, but from what I understand, it works about the same way.

There’s also been work to create web-based workflows for submitting patches and reviewing code, so I think that this (seemingly common) complaint about SourceHut is no longer valid.

Other

SourceHut also provides chat.sr.ht, which is a chat service for IRC users, and is available to paid members of SourceHut. I’ve personally never used IRC, but can see the utility of having a specific IRC channel for individual projects where real time communication could help solve a problem quicker than asynchronous comment-based conversations.

Closing Thoughts

Overall I’ve quite enjoyed using SourceHut. It’s a nice break from the gamified components of GitHub, and although it does sort of feel like other users are just nametags and not actual people, I think the overall simplicity it brings to hosting a project is bar none.

If you’re looking for technical reasons to use SourceHut, check out their website (https://sourcehut.org) covers that very well.