Migrating (some things) to Codeberg

Back when Microsoft bought GitHub, before Cory Doctorow had even invented the term “enshittification”, my immediate thought was, “oh, that’s not good.” Companies beyond a certain size don’t buy services in order to improve them for users.

It’s great that git is a distributed version control system. There isn’t, in principle, “a server” where your code lives. You can move it anywhere you like. In fact, all of the places where it lives are peers in some (important, technical) sense.

But, in practice, it’s not that simple. If you have an open source project with users, then you need to be able to communicate with them. Your project needs a web browsable repository, issues lists, release management, etc. (The exact needs are going to vary between projects, but unless you have a small, essentially closed, team of users, “a git repository” isn’t enough.)

And that’s a can of worms. Is GitHub’s user interface better than the user interface of GitLab, SourceHut, BitBucket, Codeberg, SourceForge, or any of six other services I’ve never heard of? Maybe. Maybe not. But it’s familiar. It’s what users know. And users like familiar things. (Heck, so do developers!)

Overcoming inertia is hard. It requires effort.

But I’ve been around the block a few times. I know what’s even worse. What’s even worse is discovering that you need to do this right now. That making this kind of transition is suddenly some sort of emergency. That’s worse.

So I decided I needed to start learning about the alternatives.

The hard core alternative, of course, is to self host the whole thing. There are open source alternatives that you can run on your own hardware. And administer on your own time. And keep secure on your own anxiety.

No. No. There was a time, but that time is not now.

I looked at some of the alternatives, in some detail; YMMV, but I decided to give Codeberg a try. They’re based in Europe, non-profit, and have a reasonable sounding approach to community and policy.

So I’m going to move XML Calabash there before the official release. (I did an experiment with a much smaller project a while back, it went fine.)

Is the Codeberg user interface good? Well, to quote Adam of North of the Border, it’s not just good, it’s good enough.

Moving the git repository is a couple of commands.

And then there’s everything else. It’s the switching costs that get you.

Not being able to rely on GitHub Pages to publish web sites meant setting up my own web servers with nginx and LetsEncrypt. Not hard, just a bit of a faff.

Losing CI/CD (GitHub actions) was hard.

There has to be some form of testing and release management that’s separate from my laptop. There needs to be a repeatable, controlled environment that won’t be affected if I install something new.

I’ve cobbled together something in Docker containers that I think will clear the minimum bar. And it syncs the constructed output (for documentation and such) with the aforementioned web sites.

Those same containers can publish to Maven Central, so I think that’s covered.

I don’t do releases so frequently that I need to automate doing releases. But I hope it turns out to be possible. (I haven’t really investigated yet.)

The missing piece is automatic CI for pull requests. That’s not absolutely necessary as long as I’m disciplined. But I know me, so I’d like to get that working again.

I think the answer is Woodpecker CI running on some cloud service of my own. Not on my own network because I’m not opening up a port on that to the public internet. But also probably not on Codeberg directly. They offer CI/CD, but it’s obviously a bit of a struggle. Me supporting it for my projects: probably not hard or expensive. Them supporting it for all the projects of all their users, quite probably hard and expensive.

I think I can make this work. We shall see.