-
-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migration to independent platform for provision of source code #158
Comments
Hi! Thanks for contributing to BSL and providing this very detailed proposal! First, I'm very sensitive to the argument of governance - it's something very important to me - and that's why I would push a bit more the analysis: using any external provider is an issue by itself, since the service can stop or change anytime (for various reasons) because it's not in my control. Unfortunately, self-hosting means cost (monetary and time) and competence (let's say I'm not the best sysadmin in town). So that's not a road I feel confident enough to follow. Using another provider, even ethical ones like Framagit or Codeberg, do solve the cost and competence issue, but we're back in the governance issue again. Please keep in mind that associations closing previously offered service is something relatively common (see the number of Mastodon instances getting shut down, of Framasoft services gotten plugged-out those last years), and if there is good chances that Github will be still here in 5 years, I can't say I'd have the same confidence for other smaller teams and resources projects. Also, Github is indeed where everyone is. Developers and end-users, of course, but it would be an error to limit the scope to those two populations: there is also head-hunters, managers, corporation leaders, etc. I offer my code under open-source license for various reasons and don't get much in return (and I'm ok with that, not complaining), but at least I get this visibility and "portfolio" aspect with Github that I wouldn't have with any other provider out there, it's way more easy to say in a job interview "Oh, btw check my Github profile, you'll see how I work and the quality of it" than any "please note down this URL to see my work" alternative. I hope those explanations will show you a bit more where I stand, and why I don't host my code elsewhere. For now, at least. But feel free to set-up a mirror or a fork! If I had some more time on my hands, that's something I'd like to do anyway: a mirror can help mitigating some of the previously described risks. |
Thanks for your feedback! I can completely understand your points. It was clear to me that it would not be an "overnight" action. If that didn't come across that way, I'm sorry. Suggestion: I saw a post on Mastodon from a user where such issues were marked with a following label, so it's recognizable "yes, I'm aware, but I don't currently have the time to tackle this properly in full." The title was "Shelved for lack of staff manpower" and the description "It it not that I do not want it done, it is just that I do not have time to do it". -- |
That's a good idea, I created a lightly different label that should represent a bit closer my position on this one. |
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.
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 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:
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. 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/
F. 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
The text was updated successfully, but these errors were encountered: