Handling the great code forge fragmentation | Alex SelimovHandling the great code forge fragmentation<br>2026-05-15<br>The kind of developer I hope to be someday<br>It seems like there are a lot of people either leaving or talking about leaving Github, a very prominent one being Mitchell Hashimoto.<br>Fragmentation seems inevitable, as people/companies start to distribute among the various options (Codeberg, self-host Forgejo, Gitlab, etc&mldr;).<br>I think the decision Hashimoto makes with ghostty will potentially set the tone for how the death of Github will happen.<br>I have some scattered thoughts about the situation:<br>Tracking activity across providers<br>Some kind of trust system is needed to stop AI slop<br>Get your username locked in NOW<br>Is self-hosting the right tool to stop AI slop?<br>Mirroring self-hosted repos to Github for engagement<br>Conclusion<br>Tracking activity across providers<br>I hope to someday be a 10x bathroom tile developer with a git contribution heatmap being a solid color.<br>I have already had an issue with tracking my progress working on repositories split between my self-hosted Forgejo instance and Github.<br>I&rsquo;m a simple man that wants to see my contributions measured on a public heatmap for both satisfaction and motivation.<br>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.<br>Just takes one go command to generate the activity file, some hugo config changes, and a simple shortcode embedded in your hugo markdown.<br>[Github repo available here]

This is my unified git heatmap from my Forgejo and Github

I also have some random thoughts I wanted to write out about the whole situation.<br>Some kind of trust system is needed to stop AI slop<br>I think the years of allowing contributions from anyone with an account is over for open source.<br>Maintainers are drowning in AI generated PRs/issues from unvetted sources.<br>Even though AI contribution quality is reported to be improving1, the core volume issue isn&rsquo;t.<br>The current system is requiring maintainers to wade through PRs/issues that potentially took 0 human effort/time to produce.<br>Even if some of them are useful/correct, the sheer volume makes the entire system intractable.<br>You guys already probably know this.<br>Hashimoto has a solution to this called vouch that is currently being developed.<br>It tracks approved/blocked contributors on a repo basis using a Github actions workflow by appending usernames to a VOUCHED.td file.<br>The syntax of the file is:<br># Vouched contributors for this project.<br># See https://github.com/mitchellh/vouch for details.<br># Syntax:<br># - One handle per line (without @), sorted alphabetically.<br># - Optional platform prefix: platform:username (e.g., github:user).<br># - Denounce with minus prefix: -username or -platform:username.<br># - Optional details after a space following the handle.<br>aselimov<br>github:aselimovThis is a step in the right direction, but I still think a trust system needs to be built into the forge platform.<br>Ideally you would also be able enable vouch chaining somehow.<br>Effectively<br>aselimov VOUCHED by user1 on repo1<br>user1 VOUCHED by user2 on repo2<br>aselimov indirectly VOUCHED for repo2I 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 pieces2.<br>Get your username locked in NOW<br>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.<br>That way, if a cross-platform trust chain is established, you will have fewer issues from username squatters impersonating you.<br>Seems like the main Github alternatives are:<br>Codeberg<br>Gitlab<br>Bitbucket<br>Personally I think Codeberg/self-hosted Forgejo is the best option, but you probably should make an account on each just in-case.<br>Is self-hosting the right tool to stop AI slop?<br>Self-hosting Forgejo is the maximally guarded vouching system.<br>In most cases3, the host disables account creation to not get inundated with spam/malware.<br>To get account access, you have to reach out to either the host or a known admin to get registered.<br>Probably this means sending an email, LinkedIn message, DM on x, etc&mldr;<br>I&rsquo;m not completely opposed to this concept if I ever spin up a project successful enough to be targeted by the slopocalypse.<br>Mirroring self-hosted repos to Github for engagement<br>My current workflow does involve mirroring all of my repos to Github to enable some level of community engagement.<br>The main motivating factor is to enable some sort of issues tracker, but receiving PRs is a nice bonus.<br>Migrating the PR from Github to Forge requires manual effort on my part which acts as a hardening step.<br>It ensures that I need to approve the PR before it gets anywhere close to my CI.<br>This could be a layer of protection if my brain stops working, and I start introducing vulnerable actions4 by mistake.<br>Conclusion<br>Add a unified git activity map to your hugo...