Which GitHub features are needed in a code forge before you can migrate?

18 points by pksunkara

Which GitHub features would you consider a blocker for migrating to a different code forge, and in what order do you prioritize them?

Context:

I am heads down building a code forge (https://juju.bi) based on three ideas:

Code collaboration part should work offline
Should be compatible with GitHub API (like how some services are considered S3 compatible)
Support change-id based features (ex: Jujutsu's evolog)

I shipped a super-early version that I am currently dogfooding. https://juju.bi/changelog/2026-07-01-alpha-release

I am currently focused on improving the experience for small teams working on private repos. I would like to polish the overall product before thinking about public repos. (A lot of great forges exist for public repos right now).

sjamaan

It sounds like OP is posing a trick question. IMO the features a forge should have are not GitHub features. In somewhat arbitrary order:

It should be FOSS
Ideally it should be self-hostable
The main instance ought to be run by a non-profit
It should have some form of federation

You may notice that all of these together solve the problem of centralization and vendor-lock in and hopefully prevent enshittification and ensloppification. And if it doesn't prevent those, at least these features make it easier to leave. The lock-in and enshittification are GitHub's biggest problem, and the reason people are looking to leave it. From a user perspective, any "successor" should solve these issues.

technomancy

A lot of people talk about "federation" as a really big deal, and ... it's cool, but 90% of the benefits come not from federating issues or discussion but instead from federating login. This is one place where Forgejo fails badly; for every site that you want to support logins for, the site admin has to register an oauth client manually for every single one. Obviously this doesn't work in a world where most projects have their own Forgejo. It badly needs the ability to use your home Forgejo account to log into some other Forgejo despite the fact that "some other Forgejo" admin has never heard of your instance.

I've implemented the Fediverse version of this here and it works great; you just type in your instance name instead of selecting it from a pre-seeded list of choices: https://git.sr.ht/~technomancy/min-web-fennel#fediverse-specific-oauth-flow
- sjamaan
  
  federating login
  
  I should probably have qualified that. This is what I meant. The benefit of GitHub for many people is (was?) "you already have an account anyway", so you can start contributing immediately without going through a signup process.
- colonelpanic
  
  A perceptive point, although I think you may be eliding just how difficult identity federation can be. To my knowledge, nobody has actually solved the identity portability problem in a user-friendly way.
splitbrain

A huge network of potential collaborators.
pksunkara
Let me start off with my personal checklist: (assuming all code forges will have PRs)
- Branch protection rules
- Terraform provider to setup everything (so, API)
- CI
mariusor

Personally I would need the features present in SourceHut, not Github. If you are interested in offering a jujutsu code forge, you could add support for it in SourceHut which might be a faster path to success than reimplementing Github..
blainsmith

Codeberg (Forgejo) and SourceHut is all anyone should need.
- Al3xFor
  
  I'm happy with Forgejo, any reasons to look into SourceHut?
  - PuercoPop
    
    Their CI, builds.sr.ht, is better imho.
    
    It has a better debugging story. You can SSH into the machine if the CI fails.
    
    Although it is still YAML based it doesn't lean to heavily into it. So its easy to keep CI a shell script in thinly-veiled YAML.
    
    You don't need to push a commit to trigger a CI build, you can submit the YAML directly. It has better iteration ergonomics.
    
    One of the downsides is that it doesn't have any job fan out functionality built it. If desired one has to roll it out yourself by having one build trigger another as part of its run. Although I just run the linter, tests and publishing/deploying steps sequentially. Which is fine for the average project.
    
    Note you can use builds.sr.ht from codeberg using yojo.
    
    technomancy
    
    The ability to SSH into a build is an absolute must-have. I don't understand why anyone would use CI that lacks that ability; it feels crippling and causes you to waste hours for something that should take five minutes.
    
    colonelpanic
    
    I dislike Forgejo's movement towards act although even with my reservations it's better than woodpecker. The positive side of this is that instead of SSHing into your remote build, you can run the build locally. I think for most problems this is a reasonable compromise.
    
    Al3xFor
    
    Hey thanks for the drill down, appreciated.
    
    I'm hosting my Forgejo + action runner (with podman/systemd) and so far it's been pretty smooth sailing, I'm actually impressed by the overall polish of the project and I don't feel any real pain with the ci/cd yet to search for alternatives, but good to know there are good alternatives.
    
    By the way Forgejo also suggests https://woodpecker-ci.org/ as job runner alternative which looks interesting by overlill for my self host needs.
  - abeyer
    
    The ability to host private non-oss code if needed, without having to run your own instance, seems valuable.
- JulianSildenLanglo
  For a collaborative project, i.e. anything more complex than me just hosting my own hobby projects that few will look at and nobody will use, I'd consider these features to be required:
  
  Static file hosting for html++.
  
  Pull/merge requests. Ideally without requiring that people fork the repo.
  
  Issue tracker with labels.
  
  Branch/tag protection rules.
  
  SSH-key auth for git pull/push.
  
  Signature verification for commits.
  
  Integrated markdown to html renderer.
  
  Now aside from the requirements, there's a few features that I'd really want to have.
  
  Simple way to export a repository's metadata in an easy to parse schema. Including all issues and PR-history with comments.
  
  Ditto, but as static html documents.
  
  Ability to integrate with a CI-system using webhooks.
  
  Ability to sort repositories in a folder structure /juliansl/weather/yr for example.
  
  Finally there's some things that I absolutely do not want to have because I believe they will make the tool worse:
  
  Custom CI system.
  
  AI.
  - mdaniel
    
    Custom CI system.
    
    I am pretty sure every CI system is a custom CI system. I am guessing since this thread is about "GitHub features" then you likely meant "the GH replacement should do CI the way GH does it"
    
    JulianSildenLanglo
    
    No, other way around: the code forge shouldn't make it's own CI. Instead focusing on being easy to use by dedicated CI systems.
    
    technomancy
    
    It's a very weird take to say that CI should not be integrated but static file hosting (which has existed for literally as long as the web has existed) should be the job of the forge software.
    
    JulianSildenLanglo
    
    A forge is at its very core a static file host: it hosts the source code and patches. So making some of them easily accessible over http is in my opinion natural. On the other hand running user defined software on demand is a very complicated task that is so different to hosting files that it's best to just use pre-existing options instead of reinventing the wheel.
    
    david_chisnall
    
    The thing I would really like is bidirectional sync of PRs and issues with GitHub. The most painful thing about migrating is that it’s a flag day. Before the migration, you’re telling everyone to use GitHub. After migration you’re telling everyone to use the new thing. It’s like moving house: you always want a mail redirection for a few months so people who don’t know you’ve moved can still reach you. I would love to phase it as:
    
    Read-only migration. Code, issues, and PRs are mirrored to the new thing, but can’t be edited there.
    
    New things is the default but GitHub still works. PRs can be opened in both places and are reflected in both, comments are copied across.
    
    GitHub issues are made read-only PRs are automatically closed with a ‘please open in the new place’ message. Code is mirrored back to GitHub.
    
    GitHub project is archived with a not about its new home.
    
    Without that gentle flow, there’s an abrupt transition that makes it painful.
    
    Once you have migrated, the main thing I want is something that can import GitHub Projects for project management.
    
    hongminhee
    
    One of the things I really want from an alternative forge is OIDC trusted publishing with npm, JSR, crates.io, and so on. I don't think that's something you can just implement through technical effort alone, though. And honestly, being able to use a decent amount of CI/CD for free is a huge differentiator for GitHub.
    
    Edit: Org accounts are also must have!
    
    pksunkara
    
    I don't think that's something you can just implement through technical effort alone, though.
    
    I assume that's because we need the package registries to add support for the new code forge?
    
    toast
    
    What matters more to me than featureset is the lack of them. There are plenty of alternative GitHub-like forges that are very high quality, but the converse side hasn’t progressed very much since then. What I’d really like is something like gitweb/cgit/etc that would be more appropriate given recent threat vectors (better caching, scraping detection, no accounts needed) and integrate with the system (so users just have their ~/git/ and choose what to publish or not). I want a minimum number of accounts everywhere and don’t want to make a fork to send a patch, so something like the forgejo agit flow is good, especially if you can submit a patch without an account (maybe authenticate against the pushing ssh key?).
    
    wink
    
    +1 for Forgejo and Codeberg so far covering everything I need for personal projects
    
    Have not used Github at work in a long time, so only by gut feeling: Probably also good enough but I have not used external self-hosted runners, if that is possible.
    
    shazow
    
    Minimal lock-in: if I disagree with the host, I should be able to fork and migrate easily without breaking everything
    
    Minimal but customizeable contributor friction: I am very tired making new accounts every day, I am very tired of solving captchas and still getting rejected because I'm on a VPN, I am very tired of setting up my pubkeys and bio and all that. The baseline participation experience should be extremely minimal, even a bot over Tor should be able to make an account quickly and easily. The baseline contributing experience for a specific project should be customizeable, whether I want the contributor to answer a skill testing question or run some code or have an account elsewhere or sign an affidavit that I am made out of meat, that should be within the power of the respective project.
    
    The usability, visibility, and amenities should be amenable to the populace. Everyone is used to how Github presents things, a lot of inexperienced consumers are learning to use Github, so dramatically changing how things work/look is painful for projects optimizing for wide reach/impact.
    
    airdrop
    
    Cool project! If my team were to switch we'd need:
    
    Issue tracker with labels and API (but it seems you are targeting this)
    
    Branch rules, and protections & integration with CI/CD
    
    Actions i.e. CI/CD (It would be great if you could bring your own cloud provider for this)
    
    A nice PR review UX (should be doable to beat GitHub at this since their UI is actually noticably regressing...)
    
    EDIT: One thing that would really help is an "Import from GitHub" button to smooth over the transition. Though it seems technically pretty hard to do it for code, PRs, issues, actions, etc.
    
    pksunkara
    
    GitHub's issue tracker is useful for public repos. But for private repos, most of the people use separate issue trackers like Jira, Linear etc..
    
    Do you guys use github issues for private repos?
    
    david_chisnall
    
    We use GitHub issues and Projects for private repos. We’re starting to use Linear because GitHub doesn’t make it easy to track issues that span multiple repositories that are public and private and get the planning views, but if a F/OSS GitHub alternative eliminated the need for Linear then that would make me very happy, especially if they offered a hosted option that I could just throw money at. Oh, but not if it’s one of these bullshit ‘open source, but the features that are essential to corporate use are proprietary’ things: I want a F/OSS thing so that there’s an easy second source if you go evil, if the features I need are proprietary then your going evil is a migration anyway and you’re just another SaaS provider that looks like it’s planning a rug pull.
    
    JIRA should be used only between consenting adults, in private.
    
    mdaniel
    
    Though it seems technically pretty hard to do it for code, PRs, issues, actions, etc.
    
    https://docs.gitlab.com/user/project/import/github/#imported-data and because GitLab is MIT licensed I bet with enough time I could give you a link to the source code
    
    That "actions" one has some nuance since of course the .yml come over for free, and would need analysis to convert to your new CI setup's mental model, but I actually don't see the CI secrets mentioned in that imported-data list. However, that's a gap in the automation and not "technically pretty hard"
    
    alper
    
    I'd like one that can be private either hosted or what makes more sense for a private forge: self-hosted.
    
    I consider the confluence of FLOSS work and private software development to be a mistake, so it would be interesting to see what a forge looks like that does not offer any public facilities at all and has hard vetted boundaries with the outside world.
    
    jfloren
    
    I'll never migrate to something I can't host myself. Any SaaS is just setting up for another round of Github behavior.
    
    Yogurt
    
    I'd love to see private vulnerability reporting and advisory publication
    
    jedahan
    
    CI that uses jj/git server hooks and can be run / hosted locally easily.
    
    ysun
    
    Hosted and free CI with unlimited build time
    
    kjensenxz
    
    Pages.
    
    fanf
    
    git-pages can serve a website cloned from basically any git forge. It is used by Codeberg Pages, but you can also use Grebedoc if you don’t want to host git-pages yourself. Web hosting doesn’t need to be tightly integrated with a git forge.
    
    pksunkara
    
    I am curious, why not use one of the so many free static website hosts (Cloudflare pages)? What advantages does github pages have?
    
    alloyed
    
    my experience has mostly either been in larger teams that would never consider moving from what they already have, or very small/volunteer teams that are probably an easier target :), so I'm going to describe the needs of that second one.
    
    Some sort of managed public presence. you can think github pages, or more likely, "here's a direct link to the github releases tab" with some minor CMS-like stuff on top
    
    using (abusing?) CI pipelines as a release management. Again, think of all the software you use where the install instructions are "go to the github releases tab".
    
    Every group of this size did public issue and bug reporting using google forms, and then a developer would manually write up a bug # after manual inspection of the queue.
    
    lots and lots of code review/pair programming. This would happen through the PR interface, but also realtime screensharing. always-sharable urls, including urls for local code, as well as urls for web views of the code, are very handy for this
    
    A non-technical contribution flow. this is for things like "hi here's a new logo png I just made" or "here's a translation of all the UI strings". In github, you can kinda do this by using the "fork and edit" button on the web-hosted version of the repos.
    
    Every group had all of these, although usually they are external non-code-forge services: real time chat + issue tracking + kanban + some kind of cms or wiki + a voting/internal feedback process