Gitlab Gaining Fediverse Capabilities

Open Source enthusiasts at the Fediverse currently get excited about an epic on the Gitlab issue board: Adding fediverse capabilities to Gitlab.

Fediverse

We are nowadays used to platforms. If want something, we need to register at a platform: Twitter, Facebook, Github, Reddit, LinkedIn, Youtube etc. The Fediverse has counter parts of these platforms, but they rely on common protocols. In your federated Twitter alternative, let’s say you use Mastodon, you can collaborate with users from Lemmy (kind of Reddit), Pixelfed (kind of Instagram), Firefish (kind of Twitter) and PeerTube (kind of Youtube) and Funkwhale (kind of Spotify). All in one feed and without noticiting they are actually on another platform.

Each of these platforms is decentralized in to many instances already. And they rely on protocols like ActivityPub. If another platform supports implements the same protocol, instances from both platforms are able to federate.

Islands of Gitlab

Gitlab is a platform that can be consumed as a service, but also be self-hosted. Self-hosting can become necessary for companies that have to comply to certain data privacy regulations or regulations where source code must be under their own protection.

That leads to even many public Gitlab instances out there which are all just islands. In order to collaborate on project on such island, you need to create an account first. If you collaborate on several islands, you need an account for each. And when you do collaborate on island you can only work on that island.

Federation of Islands

Gitlab is now working on federating instances. If you are from one Gitlab instance and want to collaborate with a project on another instance, you are supposed to be able to fork from and send merge requests to other instance. Without necessity for creating a new account.

Although it then would be technically possible to participate in discussions on merge requests on platforms like Lemmy or Mastodon this is not planned. The amount of posts coming from Gitlab would be too much, thus it is only planned to integrate sharing of status changes.

Dreams

Enthusiasts already dream of the possibilities offered by Gitlab implementing ActivityPub. Take for example Gitea which is popular open source devops platform and basis for further platforms like Codeberg and Forgejo. When Gitea finishs their ActivityPub integration, Gitea based instances and Gitlab instances may be able to federate.

Another example is also stated in the ticket: government entities or departments in big companies might already run their own Gitlab instances for reasons. Those instances may have different requirements to authentication, data privacy or just different workflows matching the need of local teams. Collaborating within the same legal entity but on different instances is difficult, since the instances are like isolated islands that do belong to the same country. With Fediverse capabilities users from different internal instances would be able to collaborate. That feature may cause heavy migraine for CISOs whose credibility was shred when their fellow C-levels decided moving entire devops infrastructure to Github for cross-divisional collaboration.

Opinion

I am a fan of the Fediverse in general. Due to how markets work providers tend to see their users as resources of money bags at some point. From that on offering a good service is less profitable strategy than exploiting users just enough that leaving to another provider would be just little bit more painful. Federated protocols and platforms offer souvereignity. If I do not like Meta’s Threads platform, I just don’t federate with them. And if I do like their content, I can still remain on Mastodon and subscribe to some of the Threads users. I am absolutely flexible. If Meta violates my standards, I de-federate. If Mastodon or my mastodon instance provider violates my values, I move to another instance or entire platform without loosing my entire network.

It is no secret I do not exactly like Github. It is ok-ish, but as other former shiny oldies like JIRA or Jenkins it’s overdue. I still have empathy for Github, despite it basically falls short on its core-features. The CI is even worse than good old Jenkins. Since years, project management and structuring projects are in a state of a proof of concept. If you run more than handful repositories in your organization Github is not your home. Legally and security wise it is a mess. Companies successfully avoid looking in to the mess of private and corporate github account accessing internal and public repositories alike. Companies just hope that when there is a violation, the developer is found responsible. Developers must go through a lot of overhead on Github if they are working on anything more serious than a little experiment. The only benefit Github has: you find every repository there. Now with Gitlab federating their public instances, they may offer a similar experience, but without the technical and legal implications companies ignore on Github.

I believe federated platforms have better liability. Federated platforms compete with features and service. And not with enforcing just enough pain for not driving customers away. Federating providers don’t need a lock-in, they are convinced by their quality. Thus, I’d rather buy a federated product.