Disclaimer: Opinions ahead

I have nothing against those who use sourcehut for their own projects, nor those who work on sourcehut. This is merely an explanation of why I personally don't consider sourcehut a good fit. My time on Sourcehut was relatively brief, so I might be wrong on some details.

Sourcehut is a software forge often touted as an alternative to Github, even going as far as to claim to be "the software development platform you've been waiting for" on its landing page. It differs from many forges in that it uses mailing lists for collaboration and patches rather than PRs/MRs, which many believe is a strictly better approach.

A while back, I briefly tried sourcehut to determine if it was worth the hype. I have since moved all my projects back off of sourcehut, and deleted my account. I have a few reasons why I believe sourcehut, as a cohesive whole, is IMO inferior to other forge options:

Strange UX Design Decisions

Sourcehut is very minimally designed from a UI standpoint, as explained in Drew Devault's article on its design philosophy. While this does help keep distractions to a minimum while using the site, this does result in some unfortunate consequences in terms of the user experience, as we'll explore below.

Sourcehut, fundamentally, is a set of services that work in concert to provide a cohesive experience. This works great for allowing those who want to self-host sourcehut to select which services they want, and which they don't. For instance, one could choose to host git.sr.ht and lists.sr.ht, but not todo.sr.ht, preferring to use mailing lists instead of the ticket tracker.

However, this separation of services results in a site that can at times be difficult to navigate. Let's walk through an example to explain what exactly I mean.

As an example, let's suppose you want to view the repository details of kak-tree-sitter, a tree sitter integration plugin for the kakoune code editor (fantastic project, by the way). You follow a link given to you to https://git.sr.ht/~hadronized/kak-tree-sitter, and see something like the following:

git.sr.ht

This page shows what you'd expect: a README document describing the project, instructions for cloning the repo yourself, and a brief exerpt from the most recent commit history. Nothing wrong here at all. You can click the tabs at the top to access the source tree, the commit log, and the git refs (branches, tags, etc) for the project. The tab bar changes to reflect which page you're looking at, and it's all quite fast. Everything overall works as it should, although accessing the source tree requires an extra click compared to github and other forges (a minor hiccup, but nothing major). The "refs" tab is also differently named from the "branches" and "tags" lists of other forges, but is more in line with how git actually works.

However, suppose we want to access the ticket trackers or mailing lists for this project. This page provides no way for us to do so, aside from links provided by the author themselves in the CONTRIBUTING.md document. While the creator of the project can obviously provide any necessary links, it now falls on them to not forget to do so, or the viewer is left stuck. This, as we'll see, is a side effect of sourcehut being multiple independent services running together.

As it turns out, the main project page for sourcehut projects is under the sr.ht domain, not the git.sr.ht domain. So, let's navigate to https://sr.ht/~hadronized/kak-tree-sitter:

sr.ht 1

OK, there we go. We have a project summary page showing much the same information as before (it's actually the kak-tree-sitter repo's README), and using similar design cues, which helps the user understand how the site works. We have a similar header and tab view at the top, allowing access to the project's source repositories, mailing lists, and ticket tracker. Very nice - no complaints so far, apart from not being able to get here directly from git.sr.ht.

Let's access the ticket trackers, by clicking the "tickets" tab. Since the tab bar on the git page updated to reflect what we were looking at, one would expect the tab bar here to do the same.

sr.ht 2

And indeed, that's exactly what happens. We have a good, consistent design, here, which is much appreciated. It's surprising how many websites get even something this basic wrong, so it's good to see that sourcehut is well designed in this regard.

Let's look at the feature requests tracker:

todo.sr.ht

Uh, oh.

We no longer have a way to get back to the main project page, so there's no way to get from here to the mailing lists or the git repos. Now obviously, in this case we can use the browser's back button to go back to the project page. However, say we arrived here via an external link, similarly to how we initially arrived at the kak-tree-sitter git repo? This would leave no way for the user to access the other parts of the project, apart from manually editing the URL in the address bar.

We run into this same issue when we try to access the project's mailing lists, and as we saw before the git service also has this problem.

So, this raises the following question:

Why is sourcehut designed this way?

As we alluded to earlier, this is a drawback of sourcehut's a la carte design. There's no guarantee that the project hub service will be there on any given installation, so linking to it isn't necessarily practical. Also, given that mailing lists, ticket trackers, and git/mercurial repositories can potentially be used for multiple projects, sourcehut has no way to determine which project you wish to "go back to". This leaves us with a problem with no apparent solution - the user needs to be able to access other parts of the project, but we can't give them that since we don't necessarily know which project to send them to, or if there's even a project to send them to at all.

Missing QOL Features

Sadly, the aforementioned navigation issues aren't the only UX related problems sourcehut has. Sourcehut is also lacking some quality of life features that come standard in other forges, which adds just that extra bit of friction when using the site.

For example, on Github and its various clones (gogs/gitea/forgejo/etc), whenever you open a subdirectory that has a README file, the contents of said file are immediately displayed the same way the repo-wide README is. This convenience feature prevents the user from having to perform that extra click to open the file, and allows the user to view it and the subdirectory's contents simultaneously. Sourcehut lacks this feature, requiring the user to manually open the file to view it, and then they have to go back to open another file in that subdirectory.

Sourcehut also lacks an easy way to edit project wikis, requiring users to go through the standard process of using the wiki's git repository to change it, and all that entails, including mailing lists for outside changes. This differs from Github clones where logged in users can edit pages with a convenient editor, and the wiki owner can optionally allow anyone at all to edit wikis this way, making it much easier to contribute.

I could list a few others here, but that's ultimately not very useful. Is any of this a massive deal? In a vacuum, no. However, it does result in a UX experience filled with little annoyances that add up over time.

Mailing Lists Or Nothing

One common criticism of Github-like forges is that they lock you into the PR/MR contributing model. However, somewhat conterintuitively, they do not. While the forges themselves do not provide a mailing list service, there's nothing stopping you from using an external one, and linking to it in your repo. I myself have chosen to self-host a GNU mailman-based solution at lists.jdugan6240.dev, but you can also use services such as Google groups and sourcehut's own service for the job. This allows you to support both the PR/MR based contribution workflow, as well as a mailing-list based workflow for those that prefer that.

Sourcehut, by contrast, doesn't support the PR/MR workflow at all, and thus ironically locks you into its preferred way of doing things. You can, of course, support PRs/MRs on a mirror of the sourcehut repository, but at that point, why is upstream still on sourcehut?

Another criticism often levvied at Github clones is that you are locked into the web interface for PRs/MRs/issues, while sourcehut can be used entirely from the terminal and an email client. This is, once again, simply not true - while sourcehut can indeed be used without the web interface, so can Github and its ilk. While you do indeed need to use the web interface to sign up for the service and obtain an access token, from then onward, you do not. This is due to the fact that Github, and other forges like it, provide an API through which external interfaces can be created. Emacs users for example have the magit-forge package, a magit extension that provides an interface to Github and other forges they can use within the comfort of emacs. Additionally, Github users who prefer living in the terminal can use gh-dash, a TUI application that provides an interface to Github repositories. This is not to mention the CLI interfaces for these forges, like gh for github, fj for forgejo, etc.

This leads into the final issue I have with sourcehut, which is...

Email Isn't Reliable

As anyone who's had their emails bounced can attest, email isn't guaranteed to arrive at the desired destination. The SMTP protocol behind email is indeed resilient, but it is not reliable. It will guarantee that it will keep trying to send an email if it gets a temporary failure, but that's the only guarantee you get. Emails can fail to reach their destination for all sorts of reasons, from spam filters, greylisting, DKIM issues, and more. Additionally, even if they do manage to get through, emails are not guaranteed to arrive in the same order as they were sent if they were sent in rapid enough succession.

This is a problem due to sourcehut's preferred method of handing patches - namely, one patch per email. Sourcehut encourages this usage due to git's default tooling implementing this workflow, with git send-mail sending one patch per email, and git am applying a patch from an email. While there usually isn't a problem, it's possible to end up in situations where patches can arrive in a mailing list inbox in the wrong order, or worse, not at all. This is problematic, as the maintainer can end up confused for reasons that aren't the contributor's fault.

This can be rectified by sending patches as attachments to a single email, similarly to what the PostgreSQL project requires contributors to do. This means that if the one email doesn't make it through, none of the patches make it, ensuring there's no possibility of incomplete patchsets, and no way for the patch order to get jumbled. This method solves most of the issues with an email-based workflow. However, git's default tooling cannot easily deal with this, as git am is designed to work with one patch per email, and cannot handle patches as attachments. Additionally, patches alone don't easily allow to see the surrounding context without applying the patch, something many maintainers are hesitant to do without having given the patch a good look first.

The above issues make sourcehut's implementation of a mailing list based workflow somewhat inconsistent as a means of contributing to projects and receiving contributions, and not strictly superior to MRs/PRs as some suggest.

It's not all bad

This article has been fairly negative so far, so I'd like to somewhat balance it out with some positivity. There are some things sourcehut does exceptionally well:

builds.sr.ht is phenomenal

builds.sr.ht is sourcehut's ci service.

Put simply, it's absolutely fantastic.

There's a variety of different linux and UNIX distros for you to pick from for your VM. You can have it run ad-hoc build manifests, allowing you to test them out before committing them to your repository. Additionally, if a build fails, you can ssh into the VM to debug the issue.

This is massive, and a big reason why many projects use builds.sr.ht despite their projects not being hosted on sourcehut. builds.sr.ht may very well be the best OSS ci service out there. It's a shame it's only supported on Alpine linux.

lists.sr.ht is a great mailing list provider

While mailing lists may not necessarily be the best choice for everyone regarding contributing to a git repo, lists.sr.ht provides an excellent interface for it.

The mail view provides a feature to export the patchset contained in the email thread and apply it, which is a great quality of life enhancement. The patches view keeps track of which patches have been applied, and which are still in review, making it easy to keep track of what needs to be looked at. If you're signed in, the new post view allows for posting in the mailing list via the web interface, which is convenient for those that prefer working in the browser.

It's great - if you're going to commit to the mailing list workflow, lists.sr.ht is a fantastic mailing list provider to use for that purpose. The only reason I don't currently use it to host my mailing lists is that, again, it's only supported on Alpine, and I couldn't get any of the unofficial docker builds to work.

It's fast

Sourcehut consistently measures near the top of nearly every relevant performance statistic. This is likely due to its relative simplicity as a site, not requiring javascript for any of its features (which is also a big deal for NoScript users and the like). This makes sourcehut great if you need to push up or pull often, as you won't be wasting a ton of time waiting for the git server to accept your commits.

It supports mercurial

Most popular software forges almost universally support exclusively git, which leaves mercurial users high and dry. Even BitBucket, which used to be a haven for mercurial repositories, dropped mercurial support in July of 2020, due to the fact that git users dramatically outnumber mercurial users. This makes sourcehut an enticing option for mercurial users, as it has experimental support for hosting mercurial as well as git repositories.

The above benefits are certainly enticing, but ultimately not enough to keep me personally on the platform. Right now, I have settled on having my personal projects hosted on codeberg, a github account for contributing to Github projects, and a self-hosted forgejo server for anything not meant for collaboration (dotfiles, etc).