Open Infrastructure Alternatives to GitHub (Discussing Motivation, Choice, Migration etc.)

[RichardJActon]

An extension to #2811 with a narrower focus specifically on alternative git hosting and 'gitforges' 'platforms'/ web front ends layered on top of the git version control tool. Inspired by a Slack thread in the #ask-away channel.

Many people are uncomfortable with the use of GitHub as infrastructure for their projects of a variety of reasons. Much FLOSS (free/libre and open source) software is developed on GitHub despite github not itself being FLOSS, though the underlying version control tool git is (GPLv2) the web interface layered on top is not, nor is the continuous integration and deployment (CI/CD) system GitHub Actions. The centralization of this key infrastructure for many open source projects under the ownership of Microsoft a company with at best a chequered history with open source is disquieting to many. Most recently the controversial use of code hosted on GitHub in the training of large language models that are intended to function as coding assistants has cause many to again reflect on this question or perhaps to consider it for the first time.

The front ends placed on top of git also influence how the tools is used, Linux famously continues to use a mailing list to manage kernel development as the GitHub model does not scale out well to a project with as many contributors as the Linux kernel. How might such consideration impact the choice of tool for your project?

Practical Questions

• What are the alternatives to GitHub?
• How to their features compare?
• Which of them is the best fit for your use case?
• What are the challenges of Migration or hybrid uses or multiple tools?
• What do they cost?
• What hosting options are available?

Community, Communications, & Political Questions

• How to have conversations around compromise and practical considerations when deciding whether or not to use github?
• How to accommodate the philosophically / ideologically committed Free Software advocates who refuse to use some or all proprietary tools / platforms?
• How to weigh the burden of switching costs, how and on whom these will fall (in particular in the research context)?
• How to avoid such issue in the future, what tools should we teach/train new people on?

Scope

To keep things on topic:

• Not alternatives to git itself (though this does not exclude tools which can support multiple backends)
• Not command line or desktop git GUIs/TUIs except insofar as they depend on / integrate with the webtools and thus constitute a point of comparison between them.

List of alternatives

these may have varying degrees of openness, this list is far from exhaustive.

• gitlab the community edition is open source [MIT] but the gitlab.com version has some proprietary aspects
• gitea [MIT]
• forgejo [MIT] (codeberg includes a forgejo deployment with extra bells and whistles)
• sourcehut [mostly AGPL]
• savannah [AGPLv3]

List of discussions and comparisons of alternatives

• https://sfconservancy.org/GiveUpGitHub/
• https://libreplanet.org/wiki/FSF_forge_evaluation

Examples of Projects using these alternatives

(so that people can see and compare real workflows)

• https://peppermintos.com/2022/09/one-year-since-we-moved-to-codeberg-org/
• https://gitlab.gnome.org/GNOME
• https://gitlab.archlinux.org/archlinux
• https://invent.kde.org/explore/projects

[aleesteele]

Thanks very much for making this issue, @RichardJActon! Adding breadcrumbs to #2811 and #2337 just to have links to those.

[penyuan]

@RichardJActon Thank you so much for opening this issue!

Radicle is what I think is a very interesting, fully open source and peer-to-peer GitHub replacement relying on no central servers:

https://radicle.xyz

At first glance it's probably hard to migrate a big team to it from GitHub, but it's been sitting as a tab in my browser for 2+ years and finally here's a place to put it so I can close that tab...

[penyuan]

And forgejo is related to the ForgeFed codeforge interoperability protocol:

https://forgefed.org

For which Vervis is trying to be a reference implementation:

https://vervis.peers.community

[gedankenstuecke]

Love to see Codeberg on that list already! Maybe one interesting bit to flag is that they are a German "eingetragener Verein" (a registered non-profit), which means you can become a member and get a say in the governance: https://docs.codeberg.org/getting-started/what-is-codeberg/#what-is-codeberg-e.v.%3F

[kmcdono2]

If I may suggests a variation on one of the community question for the list above based on the original slack post I made:

• How do we make decisions about these issues for work in progress vs. completed work (e.g. decisions about archiving code are maybe easier than those that require people to have shared access to code and data while working on a paper together)?

[RichardJActon]

If I may suggests a variation on one of the community question for the list above based on the original slack post I made:

• How do we make decisions about these issues for work in progress vs. completed work (e.g. decisions about archiving code are maybe easier than those that require people to have shared access to code and data while working on a paper together)?

@kmcdono2 Archiving might be an issue worth a seperate thread but There are two main places I'm aware of for general archiving of code:

1. Zenodo
2. Software Heritage

There are also some more specific curatorial efforts build on top of some of these infrastructures like EOSSR see: https://doi.org/10.12688/openreseurope.15692.2

One of the key differences between the two is that software heritage archives the entire git repository and zenodo only archives specific snapshots. So I would say that for a software development project that software heritage might be a better choice. For capturing a point in time snapshot, say at time of publication, for an academic project containing essentially one-off analysis code then Zenodo's approach is sufficient. Both produce persistent identifiers, though I personally somewhat prefer software heritages approach as I like content based addressing. Both also have support for good project metadata.

Ease of integration with your gitforge might be a consideration for ongoing projects where you want to automate snapshots/syncronisation with the archive. Software heritage support archiving entire forges so if you have your own git forge with many projects that you want all to be archived you can request that they add it. They also have what seem like more complete integrations for more platforms and source control systems than zenodo which is a touch maual if you are on anything other than github where the integration is very easy.

[jcolomb]

change title as there is a "Github discussion" tool.

thanks for opening this, very important topic.
also want to stress the importance of using different tools with community work, so that it is easier to change one of the tool (as the community is still on the others during the migration).