Considering Sourcehut

> So I made the jump two weeks ago. I now self host my code. I pay for the resources I use so no more strange free lunch.

I also chose this exact approach.

Previously, I ran GitLab, GitLab Registry and GitLab CI and while I think that it's a nice ecosystem to work within (especially at work, where it still is an excellent option, as long as someone else manages the instance), it was also a bit heavy on the resources and updating across major releases... just didn't work. I wrote about that previously, "GitLab updates are broken": https://blog.kronis.dev/everything%20is%20broken/gitlab-upda...

So, eventually I switched over to Gitea, Drone CI and Nexus, all of which now comfortably live on a single VPS with 4 GB of RAM. The performance is good, the resource usage is acceptable and when things break it just takes the individual component down instead of the whole platform (which is also nice for more granular updates).

I actually did a writeup about the switch in more detail "Goodbye GitLab; Hello Gitea, Nexus and Drone": https://blog.kronis.dev/articles/goodbye-gitlab-hello-gitea-...

Of course, actually applying those updates is still somewhat of a problem and will definitely be so until the end of time or until I get enough spare income to make someone else worry about all of that for me (including moving back to cloud platforms and paying for private Docker image storage, CI etc.).

But honestly my current setup is good enough for me, at about 6 euros per month for the hosting (my time is more or less worthless so not counting that).

Well, no, that's putting the cart before the horse.

Git was not designed for remote fetching from every menial contributor. Nothing was—it didn't make sense to.* The idea with git-pull is that it's for use among a set of frequent collaborators—so for a given repo you have a handful of remotes, if any. It was not intended that everyone would need "infrastructure to let others pull directly from their repositories". That didn't arise until GitHub decided to eschew with the traditional currency of open source (i.e. patches) and use branch merges for everything. By doing so they created the demand that is responsible for the current popularity of centralized hosts—which they just so happen to be. It's one big dark pattern, not very different from the way Facebook nursed the growth of their userbase by erecting barriers around their walled garden.

* And still really doesn't. Encapsulating everything with a new branch that lives on a public fork + a proposed merge isn't terribly efficient, being the wrong tool for the job and all... People convince themselves, though, to overlook the time/effort costs of that arrangement because it's what they're used to.

wow gitlab must be truly evil for being proprietary

strong agree, though with the caveat that it's "bad" for my tastes and priorities, but is clearly ok for other folks.

it feels all too common for folks to rage against bloaty interfaces (i agree, they're terrible!) but swing wildly back towards clunky browser-default randomness. you can have a consistent, polished interface without javascript and tons of images!

one thing w/ sourcehut that i find adds confusion is their choice to make their various services (source vs tickets vs mailing lists) completely separate apps. start on this page:

https://sr.ht/~martijnbraam/photoflow/

when you click on the "source" tab what do you expect will happen? i expect i'll go to a page with a source tree, listing files and directories. i also expect that i'll now be on the "source" tab at the new page, and will have the option to click back to the "summary" tab or any of the others that i currently see.

instead, you're taken to basically the same exact summary page (displaying README content) but with some git commit info on top. the highlighted tab is now... SUMMARY, AGAIN and there's a completely different tab set available to you. there is no way to click anywhere to get back to the previous version of the summary page and explore that tab group further.

i'm sure this makes sense to some folks (and they'll explain why i'm wrong below), but to me it feels like a cohesive user experience is not being prioritized here, and that's something i value ¯\_(ツ)_/¯

We've been using for nearly 10 years in my company, hosting 100+ repositories in it. This is one of the few forges that allow hosting Git, Mercurial, and even SVN repositories within the same web interface. We had a lot of Mercurial repos in the past, but the domination of git for web development made us switch to git. Having all our repos under one software and authentication system is quite nice.

As the administrator I also really appreciate that there is an APT package available, so it is updated with the rest of the OS via unattended-upgrades. They also provide Docker and k8s installations. Except for the v1 to v2 migration 3 or 4 years ago that was a bit chaotic at first, it has been a very solid software.

This is "just" a repository hosting software though. It will not force you to use a specific git flow, there is no PR/MR interface. There are some plugins to enable some workflows, but nothing specific. While not numerous, there are several integrations available, like JIRA or Redmine, even LDAP for authentication.

There are no CI/CD part either. There is a Jenkins plugin though. Or you can also configure webhooks to be called on push events and design your own CI around it.