Tell me if you’ve heard this one: you’re using an app, and suddenly you get the idea to fix something. You head to their project site, and scratch your heard. When searching for the issue tracker, you find out that it’s not hosted on the place you use for coding. You sigh, and debate in the back of your mind whether this is worth the effort. Code collaboration shouldn’t be this hard!

The good news is, this might soon be a thing of the past. That’s the goal with Forgefed: to let code repositories use federation to talk across the web to each other. This could have a big impact on how code collaboration happens on the Web.

A Pipe Dream

For the past few years, the project slowly gained traction. Software engineers embarked on a journey to connect code forges to each other. In the same way that Mastodon could be seen as a federated Twitter, this project would be for Github. For some, the idea was enticing, and an effort was assembled to figure out how to build it with ActivityPub.

This initiative would come to be known as ForgeFriends, and the modified spec for federating code forges was named ForgeFed. A reference implementation, Vervis, would serve as a playground for developers to figure out what worked, and what didn’t. Over time, different developers talked about what the requirements would be to make the system work.

Why is this important?

Believe it or not, GitHub and Bitbucket aren’t the only places where actual code development is happening. Granted, companies like this are very large, and feature millions of projects. But, many projects, companies, and organizations all have their own infrastructure. Pushing code, packaging libraries, and responding to issues can be a major headache. The headache gets worse when you have to wander the Internet to get basic things done.

Navigating Different Forges is Hard

Another large consideration is that of the software ecosystem itself. The GNU project, for example, hosts its own not-so-great code repository on GNU Savannah. Many of their core tools just kind of live there, and all discussions happen on a mailing list. The layout is unintuitive, if you’re trying to go there and get anything done beyond maybe downloading some source code. In fact, trying to do anything on that site is horrible.

GNU isn’t the only one, either. Mozilla’s bug tracker exists completely separate from their code repositories. KDE used to solely rely on Phabricator, but many of their projects migrated over to GitLab. Ubuntu still uses LaunchPad, a sprawling mess of links and navigation elements nested inside one another. Half of these don’t work in a standard way to one another, leading to confusion and frustration. Many organizations host mirrors elsewhere, in an effort to cast a wide net.

I’m not going to judge these projects for their choice in development software, but being able to directly federate from my own code forge of choice, rather than try to navigate whatever they’re using, would go a long way towards keeping development and distribution in one place, and making the barrier to entry much lower for newcomers.

Extending Infrastructure for Git

Git is a Distributed Version Control System. Git, as a tool, can work with a repository hosted virtually anywhere, regardless of host. However, the rise of code collaboration platforms have led us down a path: most development happens within a walled garden. If I’m doing my coding on GitHub, do I want to log in to Bitbucket to help out another project? That’s fine for some, but many folks simply drop off when they see another sign-up form to deal with.

Forgefed and its related efforts aren’t actually changing Git at all – it will work the same as it always has. What this project is doing takes inspiration from Mastodon to make federation work for programming rather than social media.

Accomplishments So Far

Trying to build out a new form of collaborative coding is a massive undertaking. It requires a deep knowledge of how federation works, and how code repos work. The good news is, the people working on it have taken steps in the right direction.

First, the ForgeFed specification is receiving ongoing revisions, as the developers come up with potential problems and solutions. The spec extends the ActivityStreams vocabulary that ActivityPub uses, with a specific focus on the needs of people pushing code. A lot of their realizations have come from tinkering with Vervis, their test implementation.

Mapping Actions to Objects

In addition to a spec for interactions and objects, there’s additional work going into the Friendly Forge Format, or F3 for short. F3 is an open format that exists to define structures and schemas of things like repositories, comments, issues, and pull requests. Adopting this would ensure that platforms not only can perform the same actions on each other, but also have a standard, shared understanding of what different objects in each others’ systems are.

Staying Compatible With Old Systems

For legacy code platforms that can’t support federation out of the box, the ForgeFlux project exists as a means to work around such limitations by instead working with a platform’s APIs directly. You could think of this as similar to cross-posting from Mastodon to Twitter, for example.

The biggest success story so far is Forgejo, a “soft fork” of the Gitea project by members of the ForgeFriends project. Much of the development on ForgeFriends has migrated over to Forgejo, put into production, and now hosts tens of thousands of projects. Codeberg eV, a German non-profit, acts as an umbrella for the trademark, as well as a steward for the project’s development. Federation work will still have a way to go before Forgejo sites are able to seamlessly connect, but the future is looking bright for the initiative.