Handling the great code forge fragmentation

The kind of developer I hope to be somedayIt seems like there are a lot of people either leaving or talking about leaving Github, a very prominent one being Mitchell Hashimoto. 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 providersSome kind of trust system is needed to stop AI slopGet your username locked in NOWIs self-hosting the right tool to stop AI slop?Mirroring self-hosted repos to Github for engagementConclusionTracking activity across providersI 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]This is my unified git heatmap from my Forgejo and GithubI also have some random thoughts I wanted to write out about the whole situation.Some kind of trust system is needed to stop AI slopI 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 improving1, 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 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:aselimovThis 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. Effectivelyaselimov VOUCHED by user1 on repo1 user1 VOUCHED by user2 on repo2 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.Get your username locked in NOWIf 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:CodebergGitlabBitbucketPersonally 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 cases3, 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 engagementMy 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 actions4 by mistake.ConclusionAdd a unified git activity map 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.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/. ↩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 ↩I’ve done this on my instance and I think it’s the Forgejo default setting. ↩Using pull_request_target can allow someone opening a PR to execute code in the runner context. ↩