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).

[danshearer]

This issue is about technology alternatives, which is great and I will engage with this, but also could we start by mentioning forges more equitably even without the proposed more technical chapter?

I just did some wordcounts in the book/website tree, looking at mentions of software forges. It looks like github is about 642, gitlab is 38 and bitbucket is 6. Codeberg and Sourcehut in particular can reasonably be mentioned along with these large American forges because they have large numbers of projects, and for certain user requirements such as visual accessibility (Sourcehut) and privacy (both) the American forges don't really have answers.

I got these numbers by running the following approximate counter:

find . -name \*\.md -exec bash -c 'pandoc --strip-comments -t plain {} | grep -i bitbucket | wc -l >> /tmp/bitbucket.count' \;
perl -nle '$i += $_;  END { print $i }' < /tmp/bitbucket.count

[danshearer]

I'm going through this very decision process for one of my projects. I'll put some thoughts down here.

The first question on @RichardJActon 's list was:

• what are the alternatives to GitHub?

I find it helpful to think of two levels at which software collaboration happens.

1. At the Distributed Version Control System (DVCS) level. A DVCS is a kind of filesystem where a new version is created every time you make a change. It helps to understand a little version control theory. The Distributed part of the DVCS enables collaboration. It means there are many copies of files owned by many people who can share their changes as peers of each other, accepting or refusing changes from other people into their copies. Many software communities successfully form around a DVCS, adding extra collaboration with a mailing list and maybe a bug tracker, and a download page for releases. A DVCS+basic tooling like this is sufficient to run a busy collaborative project, as we know because large parts of the internet are constructed using this sort of arrangement. It is certainly an alternative to GitHub.
2. At the software forge level. A software forge is a single user interface to both a DVCS (on which the forge relies to manage software and DVCS-level collaboration) and an additional layer of collaboration on top. The additional collaboration is an integrated bundle of facilities such as: bug tracking, user management across projects, automatically rendering web pages from documentation and many other nice features. The forge tries to make these two levels of collaboration look like one, but it always remains true that you can have your own DVCS copies sprawling around the web without the forge knowing or caring.

So what are the choices?

In terms of practical user communities, if you wish to install a DVCS plus applications, there are only two DVCSs that are maintained: Git (which has one implementation, and is overwhelmingly the most-used), and Fossil (two implementations.) Both are commandline tools. Both come with a GUI, with Fossil's much more complete. Setting up your own Git server to share DVCS changes with other Git users is more complicated than setting up your own Fossil server. Fossil also has some advanced forge features built into one of its implementations.

If you use a software forge, the forge usually takes care of setting up and integrating the DVCS for you, and after that it is like any other sophisticated collaboration web app. You have two kinds of forge to choose from:

1. Self-hosted. These are open source ones you can install yourself, such as Forgejo and Sourcehut. While there are others (and Fossil does a lot of this out of the box for medium-sized projects) there really is not a lot of choice of well-used, well-supported open source forges. GitLab Community Edition is open source but has reduced features and a commercial disincentive to ship all features for self-hosters. Pagure is open source but mostly used by Fedora and OpenSuSE, without a large development community as far as I know.
2. Saas, hosted in the cloud on your behalf, which may be open source or fully commercial. Codeberg is one of many forges running Forgejo, integrating Woodpecker CI and other handy open source tools. Sourcehut is a hosted instance of its own forge. And then there are the closed source services, such as GitHub, GitLab, BitBucket and so on.

There is another dimension of forge to choose from:

1. Privacy-respecting (ie according to privacy law) and code-respecting (ie not training AIs or offering tools which may modify your code by AI.) These include Codeberg and Sourcehut. It is significant that Sourcehut moved its operations from the US to Europe for this reason among others.
2. American views on privacy and commercial views on AI. This seems to cover all the other forges, noting that while Bitbucket is Australian as well as American, and GitLab is Ukranian as well as American, the American rules apply to privacy for these services even when offered to Europeans (see the unresolved issues around the US Cloud Act, etc, which is out of scope for this discussion.)

[danshearer]

Another @RichardJActon question was:

What are the challenges of Migration or hybrid uses or multiple tools?

One of the problems is migration of issues. Here is what I can contribute from work done elsewhere:

• Migrating issues from GitLab to GitHub is essentially impossible unless your write the code yourself, because the data models just don't match at all. You can find our effort in the issue-porter repo, which has some solutions to matching up issue ID references, and dealing with only one of them doing threading etc.
• When doing an import from GitHub to Codeberg, issues come across perfectly.
• The GitHub -> Codeberg import cannot be set to happen automatically, but a manual system can be set up.
• Sourcehut has some GitHub import discussions and perhaps features; I dropped out of that discussion.

As to Git:

• Migrating Git repos is assumed and built in, because all the Forges are build on Git and expose the Git protocol.
• Fossil does full-fidelity Git exchanges, in both directions. Many projects use this without problems.

... just a few things we have noticed.

[danshearer]

Scope and APIs

@RichardJActon said:

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.

I think it is only fair to GitHub, and inclusive to Turing Way users, to observe that GitHub has put a lot of effort into maintaining their commandline tool. There are very few web operations on GitHub that cannot be done via the cli, and for people with vision impairments that really matters, particularly because GitHub are very poor at accommodating visual impairments. There are several sticking points that mean the cli is not a full solution, especially authentication and token management, which not only require the web interface but an inaccessible web interface.

The cli is also a great help for dealing with things the web interface doesn't care about, like giving you an overview of multiple repos. Let's say you wanted to see the issues that involve you in three repos in TTW, a couple GitHub cli commands and you can know straight away (or even be informed in your web browser if that's how you like it.)

All GitHub alternatives have equivalents to the GitHub cli that I know of, which means it is in fact a point of comparison.

[danshearer]

All GitHub alternatives have equivalents to the GitHub cli that I know of, which means it is in fact a point of comparison.

Specifically:

• Codeberg/Forgejo cli
• gitlab CLI
• sourcehut cli

[JimMadge]

Removing the infrastructure label. Although we will have opinions there isn't a specific responsibility or ask for the WG here.