For a long time I’ve been stuck waiting for my perfect alternative to GitHub to appear. Whilst I've been historically a fan of GitHub, and used it for almost two decades, of late the site seems to have its owners interests over those of the community it previously fostered, and just it's reliability seems to be on a decline. I'm not alone in this, e.g., my colleagues have been doing their own exploration of alternatives: Anil Madhavapeddy has been getting excited about Tangled for over a year now, and Patrick Ferris has recently done a similar exercise, but I've been dragging my feet holding out for my own perfect solution.

My requirements have been:

1. Something where I can have my code on my server: if the provider goes away I still have everything
2. Something where other people can see and access that code via the web: most code I write is open source, which means people need to be able to access it
3. Something that lets people raise issues and open pull requests: open source is more than code, it is about community so code being public isn't enough, people need to be able to interact with it
4. Something that lets me run CI: I make significant use of GitHub's "actions" to both run automated quality control checks on pull requests and to push packages into production.
5. Something that is federated, so we don't need to rely on a single centralised point to mitigate access to supposedly open resources.

There's many partial solutions out there to these problem, but I've not seen something that solves all of them.

For instance, I could use an alternative service like Codeberg, or GitLab, etc. if I just want away from GitHub. But then GitHub was a fun and community orientated site when I first joined, like Codeberg and GitLab are today, and I’m afraid it seems an inescapable truth of the internet that services eventually trend closed and exploitative. So whilst I’m sure Codeberg in particular has good intentions, history says statistically they’ll fail, and I'm tired of playing catchup with startup exits, particularly in the space of archival.

The list of excuses for staying on GitHub too long goes on. For instance, I could self host that same centralised software GitLab or Codeberg are based on myself, and indeed I have my own personal Gitea server that I run on my NAS at home, but whilst that's useful for archival purposes, I don't use it much because it fails at point 3.

To cut a long story short, whilst there are many options for self hosting open source software out there, nothing hits all the points I've been holding out for, and so as GitHub's decline seems to accelerate, I need to make some compromises and accept many options are better now than just holding out.

Federation or bust

Of the requirements I have, the last one is less a technical requirement but rather more of a societal requirement. I have tried self hosting my own code, but without federation, that magic network effect that made GitHub so appealing is not there: it's hard for me to fork a repository, make a fix, and submit a patch back to the original owner. It's hard for me to open an issue on a project without needing an account on the service that is hosting it. I really do believe the point of open source software is to share, and so any solution requires that same lack of friction we got by everyone being on GitHub. Even if Codeberg and GitLab and others were successful, I'd hope we'd not see everyone using just one solution, but then we'd all need accounts on every single provider, which is tedious.

In the last few years we've had quite a lot of excitement in federated services thanks to ActivityPub, the protocol that underpins services like Mastodon, PeerTube, and ATProto which is used by BlueSky and the aforementioned Tangled. In general, whilst ATProto seems to have a cleaner architecture, I've avoided it because whilst in theory I can own my own identity, in practice it's super tricky to do that, and I've failed on multiple occasions, and so pretty much everyone just registers with Bluesky and uses that identity on ATProto services: this is a clear centralisation point that is owned by a corporation and so in my mind isn't federated! Whilst ActivityPub seems to be quite a noisy protocol and has a bunch of other issues raised around it, it is actually federated: I set up my own server for social media posts and I'm an actual peer on the Mastodon network.

So I've been holding out for an ActivityPub based solution, and whilst there's been a bunch of noise around attempts to add support to say Forgejo, nothing has yet emerged that I can see, and even if it did I suspect it'd take a while to be stable enough I'd want to trust it for archival purposes.

And so finally, I overcame my dislike of ATProto, and moved to Tangled.

Tangled: above and beyond

Tangled is interesting, as it breaks my idea of what a federated service should look like. I still think that the goal is total self hosting (and self doesn't need to be for an individual, but for some social unit like a makerspace or a work group), the way Tangled does it is more nueanced, and actually does some bits better than I'd imagined.

Identity

Firstly, let's deal with identity. Firstly, in git this is messy anyway, as your identity on GitHub is actually devolved from the identity of the code you commit, it's just UI in GitHub makes this seem like your GitHub user made the code. But you commit the code using an email address you choose, that is actually how you're code is identified, and then in GitHub you just tell it which email addresses you have, and then it shows all your commits as belonging to your GitHub user ID. I flag this mostly as it makes the identity of whatever you use to access the code slighly less important that it is in other systems. With git the identity of the code authorship is decoupled from the identity of whatever portal I use for sharing that code. I "own" (technically rent) my own domain and sign my code with that, so I have already achieved my implied goal of identity ownership without realising it.

But, I still refuse to engage with BlueSky on principle: a network isn't federated if I have to use one entity to generate an account. As I say, that's technically not true, as you can in theory set up all the necessary software and certificates to do it, it's just really complicated and poorly documented. Thankfully the tangled team have done this, and so I can in fact sign up with Tangled and generate an ATProto ID without using BlueSky at all. Now, I don't own this identity, tangled.org does, and so if they go away, so does that identity. But given the earlier point about my code actually being committed based on my email address rather than the access portal identity, I've chosen to compromise on my principles here and use the ID provided by tangled.

Code hosting

Now this is where tangled is really quite interesting, and more so than I originally realised. When you put your code "on" Tangled, the code storage is decoupled from the tangled.org user hosted interface. Indeed, this becomes apparent when you commit code, as the remote you set up isn't for tangled.org (as you might expect having used GitHub, Codeberg, etc.). Instead you nominate a "knot", which is a server that just deals with code hosting. And that's quite cool about Tangled is that:

1. You can host your own knot
2. You can have have different knots for different projects.

So, if you're just getting started and experimenting, you can use the default tangled.org knot. But I currently am using two knots: one that is set up for my group in the university, which is where I push code made for work, and I now self host my own knot on one of my VPS nodes which is where I put my own personal projects. And if I log into my VPS, I can see the raw git repositories on the file system, so I have absolute access and control.

Again, I don't own my VPS, it is rented, but I can copy the directory from there to my NAS say and I get to there. One thing you realise quite quickly on this sort of exercise of self ownership is how little you own even under "self hosting": rent extraction is built into a lot of the Internet.

But back to the point: Tangled not only doesn't commit me to hosting code with them, it doesn't commit me to hosting code in an single place either, I get to make that on a per project basis, which I think is pretty empowering in terms of people rarely working within a single context.

Metadata hosting

If you've looked into ATProto at all you might be surprised to see I've not yet talked about the role of the Personal Data Server (PDS). In ATProto data you own (e.g., social media posts on BlueSky) are not stored with the service provider, they are stored in your own PDS. Now, most people get a PDS from the place they get their identity from (e.g., BlueSky), but that's not a requirement of the protocol, just a convenience function. In general setting up your own PDS is easier than setting up your own identity on ATProto, so my understanding self hosting a PDS is quite common. As I'm new to ATProto my PDS is also currently provided by my identity provider, tangled.org.

I bring this up as initially I was so focussed on the knot being the unit of storage I forgot about the role of the PDS. Tangled will use the PDS to store non-code related things, such as your profile, people/project follows, project issues and so forth. This means that if you bring your own PDS, then you will have ownership of the data behind issues you post on a project.

Now, I can't blame the tangled authors for the fact that git itself doesn't not have a way to store issues or pull request state, etc. as ideally I'd have liked project issues to live with the code. For larger projects a lot of community knowledge is stored in issue history, and I've been involved in a large project that wanted to migrate but couldn't because GitHub Enterprise would not export issue history, and that acted as a form of lock in.

With this system in Tangled we're not locked in to tangled.org, but we are somewhat locked into ATProto. It also feels like if someone stops maintaining their PDS then issues might also be lost, a real problem I suspect given how long open source projects can last for.

CI

The main functional gap between what I've been relying on with GitHub and Tangled is a lack of built in CI. Now, to be clear, GitHub's Actions always felt unsustainable: a clear loss-leader by GitHub to get people to stick around, and so I don't think it's reasonable for any free to access service to also offer free CI. Tangled does have an architecture for CI, called Spindles, and so I now need to look into how and where to host this. I say, I rely heavily on CI to keep me straight, and so fixing this will be somewhat of a priority.

A pragmatic move

To be clear, I'm happy with my move to Tangled. Tangled does currently miss the mark a little on my personal federated dream, but that's my own personal ideal, and so I don't mean this as any disrespect to the authors. I've been fortunate enough to chat with Akshay Oppiliappan who is one of the authors of tangled and has been very happy to try explain things to me, and I know has a great vision for tangled going forward.

I think for me, despite my dislike of ATProto, Tangled represents the best option right now, and so I've started to slowly migrate myself to over. You can find my profile here. I won't be able to stop using GitHub for things where there's already an established community there - as I say community is such a key part of any open source project that community wins out over any personal preferences for hosting, but I hope over time we can decouple community choice from any single vendor, and little steps like this can help.