Handling the great code forge fragmentation

Hacker News Top Tools

Summary

The article explores the fragmentation of code forges as projects leave GitHub, introduces a tool to unify git activity heatmaps across platforms, and discusses trust systems to combat AI-generated spam contributions.

No content available
Original Article
View Cached Full Text

Cached at: 05/20/26, 05:28 PM

# Handling the great code forge fragmentation Source: [https://www.alexselimov.com/posts/forge_fragmentation/](https://www.alexselimov.com/posts/forge_fragmentation/) ![Picture of shower tiles that look like 10x developer git history](https://www.alexselimov.com/posts/forge_fragmentation/cover.webp)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](https://www.alexselimov.com/posts/forge_fragmentation/#tracking-activity-across-providers) - [Some kind of trust system is needed to stop AI slop](https://www.alexselimov.com/posts/forge_fragmentation/#some-kind-of-trust-system-is-needed-to-stop-ai-slop) - [Get your username locked in NOW](https://www.alexselimov.com/posts/forge_fragmentation/#get-your-username-locked-in-now) - [Is self\-hosting the right tool to stop AI slop?](https://www.alexselimov.com/posts/forge_fragmentation/#is-self-hosting-the-right-tool-to-stop-ai-slop?) - [Mirroring self\-hosted repos to Github for engagement](https://www.alexselimov.com/posts/forge_fragmentation/#mirroring-self-hosted-repos-to-github-for-engagement) - [Conclusion](https://www.alexselimov.com/posts/forge_fragmentation/#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) This is my unified git heatmap from my[Forgejo](https://forge.alexselimov.com/aselimov)and[Github](https://github.com/aselimov) 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](https://www.alexselimov.com/posts/forge_fragmentation/#fn: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](https://www.alexselimov.com/posts/forge_fragmentation/#fn: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\. Self\-hosting Forgejo is the maximally guarded vouching system\. In most cases[3](https://www.alexselimov.com/posts/forge_fragmentation/#fn: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](https://www.alexselimov.com/posts/forge_fragmentation/#fn: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\.

Similar Articles

Why I'm leaving GitHub for Forgejo

Hacker News Top

The article discusses the decision to migrate from GitHub to self-hosted Forgejo, citing concerns over data ownership, reliability, and AI data collection practices. It highlights similar moves by the Dutch government and details the technical setup of a personal Forgejo instance.

What would you want from a forge?

Lobsters Hottest

A discussion thread on Lobsters asking developers what features they would like to see in a code forge, particularly regarding version control presentation and collaboration models, referencing tools like Jujutsu and Git.

We stopped AI bot spam in our GitHub repo using Git's –author flag

Hacker News Top

The Archestra team describes how they combated AI bot spam in their GitHub repo by building reputation tools and eventually using Git's --author flag to block contributions from unvetted accounts, aiming to preserve a safe space for legitimate contributors.

github and the crime against software

Lobsters Hottest

This article criticizes GitHub for frequent outages, poor reliability, and prioritizing AI features over fundamental infrastructure, arguing it reflects broader decay in big tech software services.