Evaluating new software forges

John Nunley · December 15, 2023

rust

What options are there other than GitHub?

Oh boy, I sure do love contributing to open source software on the largest software forge in the world! I hope they haven’t started down the slow and painful process of enshittification by following vague, ill-defined industry trends!

Wait, what’s that? Computer! Enhance!

Well, I guess I’m ready to find a new forge!

Software Host Hellscape

In all seriousness, I’ve been looking to move off of GitHub for a while now. Let me be clear, GitHub is still far and away the best website for open source discovery. Not to mention, its CI offerings are very nice, especially for something free. Yes, there are better paid CI offerings, but for something that costs zero dollars I’ve found it incredibly useful.

However, one thing has made me skeptical of GitHub is its “Copilot” offering. I’ll admit, I was in the beta program for Copilot, and found it really neat. Being able to write large amounts of code from small comments was very nice, even if it was really bad practice.

Then I found out it was training on GPL-licensed data, which left a pretty bad taste in my mouth. In addition to the fact that I’m increasingly uncomfortable with hosting my free software on a closed source forge, run by Microsoft.

Let’s take a look at everybody else.

GitLab Gauss

GitLab is the original GitHub competitor. The Linux to Microsoft’s Windows, or the MariaDB to Oracle’s MySQL. This has made it the most popular GitHub competitor by far, by virtue of people vocally quitting GitHub in favor of [GitLab].

Unfortunately, I didn’t really consider GitLab when I was finding a place to move. First of all, they aren’t actually open source. They’re “open core”, which, I admit, is better than closed source. However, like I said, I’m uncomfortable building free software on infrastructure that isn’t.

I know I can download GitLab and set it up on my own server. However, I’m a software developer, not a sysadmin. I want to spend my time developing software, not putting out fires and paying AWS bills for the rest of time.

Also, GitLab has adopted the unfortunate strategy of “following along with whatever GitHub does”. They’ve tried to jump onto the bandwagon so frequently, they’ve gotten splinters. For instance, what happens when we check their homepage?

Computer! Do the thing again!

Good golly, it’s even the same wording! Yeah, I’ll pass.

SourceHut Scramble

sr.ht takes the opposite approach as GitLab. Instead of trying to follow along with GitHub’s trends, it’s elected to do go in the other direction. Whenever GitHub does something, SourceHut does the exact opposite.

Pull requests? Too centralized, let’s construct a suitable code contribution system around email. Discussion? Why not IRC, it’s been around since the Bronze Age. Get rid of Mercurial support? Not interested.

I really like SourceHut. When you go to their homepage, they’re not showing off their fancy CSS effects or telling you about their AI offerings. They give you a simple user interface and some of the projects they host.

There was also much to impress me. Their CI offerings are better than GitHub, which alone justified me paying the humble $2/month price tag. Rather than needing a complicated YAML file to run a CI system, it’s just cloning Git repos and running commands. It’s delightfully simple yet powerful. Having native BSD and Plan9 runners doesn’t quite make up for its inability to run Windows, but I’m sure I can work around that.

Not to mention, SourceHut has the second best repository discovery system. When I go to sr.ht’s “explore” tab, I’m immediately greeted by a slew of interesting projects. Whether it’s a powerful Forth dialect that brings a lot of genuinely exciting ideas to the table, or a tiny C11 compiler written in simple ANSI C, I’m always amazed whenever I open up that tab.

I liked it so much that I announced that I was moving my personal projects to SourceHut. However, after moving my theo project to SourceHut, I found myself dissatisfied with a few things.

For one, the email-based workflow was a lot clunkier than I expected. In theory, building code contribution on top of a standard protocol that’s been around since the 60’s sounds like a good idea. In practice, it’s a lot clunkier than you’d expect, especially since most modern email clients are simply not built to read and write code.

After trying it for myself I can see that it might turn off a lot of people from contributing. I’m already losing a lot of potential contributors by moving off of GitHub. I don’t need those remaining contributors to also be turned off by a workflow completely different than what they’re probably used to.

Still, I can imagine this workflow working for many people, especially ones who already have a decent setup for email-based projects like Linux.

Codeberg

Codeberg is a public instance of Forgejo, which is in turn a fork of Gitea. It’s got a pretty nice interface similar enough to GitHub’s. It’s got the familiar pull-request-based contribution interface. The CI is good enough, I suppose. Docker containers aren’t the best CI environment, but I can certainly think of worse.

So what’s not to like?

My main problem is that Codeberg has a very limited CI capacity, and I have a lot of projects that require significant testing. theo, for instance, requires these things to be tested:

• Make sure it compiles on Windows, Mac, Linux, WASM, Redox, and whatever oblique platform people run Rust on nowadays.
• Check the various different backends that theo supports: pure software rendering, wgpu and OpenGL. Not to mention all of the different interfaces to OpenGL, so wgl, GLX, EGL…
• Check formatting and linting.

…which doesn’t even cover testing. For rendering frameworks like theo, you want to have some pre-defined rendering programs that render your code to images. That way, you can regenerate these images and compare against an existing set of images in order to check for regressions.

This isn’t a practical concern, although it really should be. It’s a moral concern. You have an organization like Codeberg, donating a significant amount of time and resources to try to make a positive difference in the world of software. Now, here I am, sucking up all of those compute resources for my insignificant little projects.

Of course, while pondering this moral concern, I realized that I’ve locked myself into a Catch-22. I can’t use any independent project’s CI because of my concerns that I would drain too many of their resources. On the other hand, I can’t use any large company’s CI because I don’t want to host my project with a large company. I can’t self host, because that would be a pain.

Would it?

Self-Hosting Gitea

I said I didn’t want to self-host. I worked in IT for two years, so I’ve already gotten my fill of fighting with both servers and people.

However, in a Discord I’m in, an acquaintance of mine talked about how they set up Gitea and Drone CI on a school Kubernetes cluster they had access to. I mentioned my predicaments in finding a forge service, and they said that it was only two configuration files.

That tempted me. Not enough to deal with the absolute nightmare that is Kubernetes, but enough for me to rent out a couple of Lightsail servers to experiment.

I’d like to say that I set up the entire thing in a weekend, but it wasn’t that simple. Sure, it was easy enough to install Gitea and Drone in Docker containers. Sure, it wasn’t too hard after that to set up my DNS records to forward src.2023.notgull.net to that new serer. Yeah, it’s probably hacky to set up my CI system on a public cloud, but as long as I keep people from abusing it that aren’t me it shouldn’t be too bad, right?

Of course, I forget my crucial weakness: my perfectionism. Sure, my site looks pretty good… but it looks a bit ugly. Let’s play around with themes for three days until I find one I like. Oh, the logo doesn’t look good with my new theme. Let’s convert the MS paint drawing I call my avatar into SVG and then set it up to be this site’s logo. Oh, Gitea has a weird templating system; let’s compile it from scratch!

At the end of this week(!)long process, I had a somewhat functional Git forge, with the following features:

• A decent Linux Drone CI setup.
• A Dependabot clone for automatic updates.
• A system that allows everyone to create an account and open issues, but doesn’t allow people to create repos or mess with the CI.
  • If you want to create a repo for PR’s sake, email me at dev at notgull dot net and I can set you up.
• A mirror to GitHub, so I can still take advantage of their code discovery.
  • Yeah yeah, I know, but keeping an arm’s length from GitHub is a win in my book.

I’ve uploaded a lot of my code to there, and it seems to be working well so far. I have to admit, it is somewhat liberating to have full control of how your code is forged.

Parting Shots

I still consider this to be in the “experimental” stage. If it ends up being too inconvenient or too expensive, I’ll probably move it somewhere else. Still, having my own space for code that I can do whatever I want with is very nice. Let’s hope it keeps working well and this blog post doesn’t age like milk.

All photos are from public websites and fall under free use, as this is a review.

Share: Twitter, Facebook