Migration to independent platform for provision of source code

[linux-lukas]

A. Problem / Goal

Since the purchase of GitHub by Microsoft in 2018, a dependence on the BigTech corporation can no longer be denied.

On the one hand, I can understand why GitHub was chosen as the platform for making source code available: "Everyone is here".

On the other hand, I see the danger of a vendor-lockin effect and that open source projects become centrally dependent on Microsoft. In my eyes, this is very dangerous for free and open source software and hardware projects (I would like to highlight one point very clearly: I am aware that it will not be an "overnight" process to migrate the entire GitHub organisation to, for example, Codeberg or a separate Gitea instance. A complete migration involves an enormous amount of work, both in terms of personnel and possibly also financially. Basically, I wanted to draw attention to the problems with GitHub, which are somehow not small.).

In the medium and long term, the goal would be to become independent of GitHub and thus of Microsoft. The Gitea-based Codeberg project of Codeberg e. V. in Berlin, Germany, would be a good choice here.

There are also (legal) problems with compliance with the licence of GitHub functions, such as the co-pilot.

B. Solution

My considered solution to the problem described in A. would be the following:

1. A user of this open source project creates a user account on https://codeberg.org/
2. If necessary: This user creates an organisation for the project.
3. A "personal access token" is created on the GitHub account, which has appropriate rights to the organisation repositories, using the developer options in the settings.
4. all repositories would be migrated with this access token into the ownership of the organisation created in step two.

Note: This procedure should also work for your own Gitea instance.

Regarding step four, there is an entry in the documentation of Codeberg: https://docs.codeberg.org/advanced/migrating-repos/

C. Alternatives

A possible alternative would be to perform the first three steps as described in B. A possible alternative would be to perform the first three steps as described in B., and modify the fourth step to include a mirror of GitHub. So that all issues and such that would be created in the GitHub repository would be transferred to the Codeberg repository.

D. Responsibilities

I would see the responsibility in the owners of the repository and, if necessary, additional project participants.

E. Risk

Last but not least, it must be assumed that people could potentially create fewer issues because it is a new platform and it is less known. It remains to be seen how and when the principle of decentralisation or federation will be implemented in Gitea, on which Codeberg, the GitHub alternative, is based, see the following article: https://social.exozy.me/@ta180m/108631221939677386

F. Other

• Basically, a look at the documentation of Codeberg is not unwise: https://docs.codeberg.org
• Should it be necessary to manage repositories in organisations, this is also possible under Codeberg, see: https://docs.codeberg.org/collaborating/create-organization/
• Regarding licensing there is a page in the documentation of Codeberg: https://docs.codeberg.org/getting-started/licensing/
• The Terms of Use (ToS) of Codeberg.org can be viewed at the following link: https://codeberg.org/Codeberg/org/src/branch/main/TermsOfUse.md

[welcome[bot]]

Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review. In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within two business days. If this does not happen, feel free to leave a comment. Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:

• "Priority" labels will show how urgent this is for the team.
• "Status" labels will show if this is ready to be worked on, blocked, or in progress.
• "Need" labels will indicate if additional input or analysis is required.

Finally, remember to use https://discuss.ipfs.io if you just need general support.