Evaluating new software forges
đ 2023-12-15 â notgull đ Origin đźď¸ Load image
Evaluating new software forges
đ 2023-12-15 â notgull đ Origin đźď¸ Load image
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!
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 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.
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 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:
theo
supports: pure software rendering, wgpu
and OpenGL. Not to mention all of the different interfaces to OpenGL, so wgl
, GLX, EGLâŚâŚ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?
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.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:
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.
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.