Facilitate code contribution (i.e. forks) from guest users in self hosted instances of GitLab

In the report of forges in Higher Education and Research in France, it was pointed out that the numerous self hosted public forges containing open source research software are not easily accessible outside their hosting institution.

Here are some quotes from the report:

The main limitation to the forges currently available in Higher Education and Research is the limited audience for these forges (i.e. the individuals who can create an account), as the majority of platforms for the forges available do not allow individuals from outside of Higher Education and Research to create an account on these platforms themselves. This therefore poses a barrier to interacting with society.

While some of these forges allow the creation of external accounts, they are often difficult to access (for example, for gitlab.inria.fr, an external account must be “referred” by a member of an Inria project team) and limited (the GitLab external account cannot create its own projects). This often makes it impossible, or very difficult at the very least, to suggest changes with this type of account, because this would require a fork on the original project, and the external account would therefore need to create its own project on the forge. Users need to have an account beforehand in order to report a bug, which may be prohibitive.

This can also lead to problems in interacting with other parts of the open source and research software communities. For example, the Journal of Open Source Software, a widely-used journal that peer reviews and publishes about 400 short papers and accompanying software packages per year requires that submitted software "must be hosted at a location where users can open issues and propose code changes without manual approval of (or payment for) accounts." This is because JOSS is interested in publishing software that can be used by and contributed by a wide community. One of its review criterion is Community guidelines, and this includes that "there should be clear guidelines for third-parties wishing to: contribute to the software; report issues or problems with the software; and seek support," all of which are quite difficult if the forge doesn't allow these to be done without free and automatic registration that is open to all.

The OW2 approach is a pragmatic one; it allows each person to create an account on its platform, but limits the number of new projects created to two as a default setting. This allows users of OW2 software to easily interact with the issues system and be able to offer code contributions. Forge managers have found that this default open position has not led to phantom accounts being created. However, OW2 delegates account creation to its directory, and not directly to its forge.

As a general rule, forge software like GitLab does not limit project creation to simple contributions (i.e. forks on platform projects). There is also no way of preventing a user from uploading photos or videos to their project space.

However, allowing individuals outside of the institution to create projects may result in legal problems, such as compliance with the French Act of 24 June 2020 on Hate Speech on the Internet.

To summarize, on multiple existing Higher Education and Research forges the key issue that needs to be addressed revolves around setting out a coherent access policy which maximises interactions without endangering the infrastructure, both for interaction between staff members and with society.

Note that this problem will disappear once the federation of forges will be possible.