Just to be clear: I’m not asking for github alternatives.
If you had an open source project that is somewhat deeply rooted in GitHub’s ecosystem and wanted to move to another service, how would you proceed?
I’d really want to self host a service, but then i’d be subjecting my internet to regular clones or downloads of releases (I’m not sure how much that’d effect me generally, but it seems worth considering).
No one’s internet is as reliable as a cloud hosted service either, so there’s also that to consider.
So I guess a cloud option? (Codeberg probably btw)
But then (either way) you’re potentially splitting a community I’d imagine?
You can mirror repos to github, but if you have a project small enough and it forces issues/prs on another service, is anyone gonna bother?
Maybe you just have to swap and be okay with less people around, just so you can get out of Microsoft’s grip in open source.
Do you have any thoughts?
Maybe you just have to swap and be okay with less people around, just so you can get out of Microsoft’s grip in open source.
I think you hit the nail on the head here. It is almost always the case that you will trade adoption/utilization/community for a less-used solution. Using loops, pixelfed, mastodon or piefed/lemmy, element, linux, FOSS web apps instead of their more popular system, they all come with an unspoken agreement that you embrace a niche-existence.
Only you can really decide what’s more important to you.
That’s a good point, I guess I already practice this with everything else, I just waited too long for this specifically and now there’s a lot of (+new) people I’d potentially be parting with.
Still going to think about this and maybe test the waters, see if it’s viable.
Thank you for the response, I feel more confident in the idea!
I didn’t have “deeply rooted” projects, but i started by just creating new projects on codeberg. It gave me time to test it out before i moved the rest of my projects which i did ~6 months later.
For your use case i would consider the same. Figure out where you might like to migrate to and give it a test run with new projects. Then decide if you want to migrate the deeply rooted project(s) or not.
I didn’t have to worry about the community much, both because i didn’t have large projects and also because i was on gitlab to begin with. If anything going from gitlab to codeberg i had the same if not more engagement with my small projects. But my motivation for my migration was just wanting to use services that support what i support. For me that’s what was most important in the long run.
Also re: github container registry. Forgejo (what codeberg uses) supports this: https://forgejo.org/docs/latest/user/packages/container/ . These images would then also show up on your project page under “packages” tab if it has been enabled
It’s nice to hear you didn’t see a drop in engagement, that gives me hope.
I think I might do as you say and make something small to try out codeberg, see if everything works for me (dev to release).
motivation for my migration was just wanting to use services that support what i support
Very true, if it works I should just do it. It’s not like I’m losing paying customers hehe.
p.s. thanks for the link, I hadn’t looked it up yet :)
In practice these won’t be concerns. “Usually” if it’s an important project, the distribution is not based around github. It’s pypi for python or npm for js, or a package distributor on linux, or a store or whatever.
A weird mixed setup would be providing some kind of signed object through torrents, don’t know how that works in practice, but that would avoid stressing your own internet too much.
Yes, you will lose some “driveby” error reports from people who don’t want to make a codeberg account to report the bug on. But then they don’t actually “need” need it solved either.
Make it a single source of truth, point to the new repo in the old one and update the descriptions in the distributing websites/services and that’s it.
I guess I have a slightly different problem in that I use GitHub Container Registry to host release images.
I haven’t looked, but I would think Codeberg might have something similar.
I would use Docker’s registry, but that feels like stepping sideways instead of forwards for some reason.
Yes, you will lose some “driveby” error reports from people who don’t want to make a codeberg account to report the bug on. But then they don’t actually “need” need it solved either.
That’s a very good point. I had thought of keeping the github repo mirrored so that it could be used for issues (and maybe prs?) still, but your point has me rethinking the need.
Make it a single source of truth, point to the new repo in the old one and update the descriptions in the distributing websites/services and that’s it.
I will certainly consider this. It would definitely be easier than setting up a mirror in addition to moving.
I guess I’m worried that without an “active” side on github, the project will lose any traction it has gained since I didn’t advertise it, I think github naturally brought people in.
Thank you for your reply, it is very helpful!
