AlexSelimov.com/content/posts/forge_fragmentation/index.md

---
title: "Handling the great code forge fragmentation"
date: 2026-05-15T20:29:05-04:00
tags: ["software development", "self-host", "hugo"]
---

{{< figure src="/cover.webp" alt="Picture of shower tiles that look like 10x developer git history" caption="The kind of developer I hope to be someday" >}}

It seems like there are a lot of people either leaving or talking about leaving Github, a very prominent one being [Mitchell Hashimoto](https://mitchellh.com/writing/ghostty-leaving-github).
Fragmentation seems inevitable, as people/companies start to distribute among the various options (Codeberg, self-host Forgejo, Gitlab, etc...).
I think the decision Hashimoto makes with ghostty will potentially set the tone for how the death of Github will happen.
I have some scattered thoughts about the situation:


* [Tracking activity across providers](#tracking-activity-across-providers)
* [Some kind of trust system is needed to stop AI slop](#some-kind-of-trust-system-is-needed-to-stop-ai-slop)
* [Get your username locked in NOW](#get-your-username-locked-in-now)
* [Is self-hosting the right tool to stop AI slop?](#is-self-hosting-the-right-tool-to-stop-ai-slop?)
* [Mirroring self-hosted repos to Github for engagement](#mirroring-self-hosted-repos-to-github-for-engagement)
* [Conclusion](#conclusion)

## Tracking activity across providers

I hope to someday be a 10x bathroom tile developer with a git contribution heatmap being a solid color. 
I have already had an issue with tracking my progress working on repositories split between my self-hosted Forgejo instance and Github.
I'm a simple man that wants to see my contributions measured on a public heatmap for both satisfaction and motivation.
So I solved this problem for myself with a go script and hugo module that you can use to create a git heatmap combining data from multiple hosting platforms.
Just takes one go command to generate the activity file, some hugo config changes, and a simple shortcode embedded in your hugo markdown.

[[Github repo available here]](https://github.com/aselimov/-hugo-unified-git-activity)

{{< git-heatmap >}}

I also have some random thoughts I wanted to write out about the whole situation.

## Some kind of trust system is needed to stop AI slop

I think the years of allowing contributions from anyone with an account is over for open source.
Maintainers are drowning in AI generated PRs/issues from unvetted sources.
Even though AI contribution quality is reported to be improving[^1], the core volume issue isn't.
The current system is requiring maintainers to wade through PRs/issues that potentially took 0 human effort/time to produce.
Even if some of them are useful/correct, the sheer volume makes the entire system intractable.
You guys already probably know this.

Hashimoto has a solution to this called [vouch](https://github.com/mitchellh/vouch) that is currently being developed.
It tracks approved/blocked contributors on a repo basis using a Github actions workflow by appending usernames to a `VOUCHED.td` file.
The syntax of the file is:

```
# Vouched contributors for this project.
#
# See https://github.com/mitchellh/vouch for details.
#
# Syntax:
#   - One handle per line (without @), sorted alphabetically.
#   - Optional platform prefix: platform:username (e.g., github:user).
#   - Denounce with minus prefix: -username or -platform:username.
#   - Optional details after a space following the handle.
aselimov
github:aselimov
```
This is a step in the right direction, but I still think a trust system needs to be built into the forge platform.
Ideally you would also be able enable vouch chaining somehow.
Effectively

```
aselimov VOUCHED by user1 on repo1
user1 VOUCHED by user2 on repo2
aselimov indirectly VOUCHED for repo2
```

I think we need a web with some barrier of entry to ensure contributors are high quality and motivated instead of bots that will write hit pieces[^2].

## Get your username locked in NOW

If we are transitioning to a vouching based trust model you are going to want to lock in a consistent username across the main platforms.
That way, if a cross-platform trust chain is established, you will have fewer issues from username squatters impersonating you.
Seems like the main Github alternatives are:

- Codeberg
- Gitlab
- Bitbucket

Personally I think Codeberg/self-hosted Forgejo is the best option, but you probably should make an account on each just in-case.

## Is self-hosting the right tool to stop AI slop?

Self-hosting Forgejo is the maximally guarded vouching system.
In most cases[^3], the host disables account creation to not get inundated with spam/malware.
To get account access, you have to reach out to either the host or a known admin to get registered. 
Probably this means sending an email, LinkedIn message, DM on x, etc...
I'm not completely opposed to this concept if I ever spin up a project successful enough to be targeted by the slopocalypse.

## Mirroring self-hosted repos to Github for engagement

My current workflow does involve mirroring all of my repos to Github to enable some level of community engagement.
The main motivating factor is to enable some sort of issues tracker, but receiving PRs is a nice bonus. 
Migrating the PR from Github to Forge requires manual effort on my part which acts as a hardening step.
It ensures that I need to approve the PR before it gets anywhere close to my CI.
This could be a layer of protection if my brain stops working, and I start introducing vulnerable actions[^4] by mistake.

## Conclusion

- Add a [unified git activity map](https://github.com/aselimov/-hugo-unified-git-activity) to your hugo site!
- Establish your username/identity on all of the major forges.
- I have no idea where things are going from here or if Github can recover.


[^1]: Curl maintainer talking about how the AI slop storm has actually turned high quality <https://daniel.haxx.se/blog/2026/04/22/high-quality-chaos/>.
[^2]: A maintainer of matplotlib closed a PR because it was a good first issue for a human and the PR was opened by an openclaw bot. The bot then wrote a blog post naming the maintainer as an anti-ai gatekeeper <https://crabby-rathbun.github.io/mjrathbun-website/blog/posts/2026-02-11-gatekeeping-in-open-source-the-scott-shambaugh-story.html>
[^3]: I've done this on my instance and I think it's the Forgejo default setting.
[^4]: Using `pull_request_target` can allow someone opening a PR to execute code in the runner context.