Some are asking: why does privacy-focused Organic Maps use GitHub? The largest open-source contributor network, familiar PR & issue workflow, Actions CI, broad integrations, zero infra to maintain, and easy onboarding/discoverability. This lets us focus on improving the app instead of running and maintaining servers. Development time is the most precious resource nowadays, and most of our users don't care where the code is hosted, but care about the app functionality and usability…
Do you care?
I’m a software developer with over 40 years experience. Much of it with FOSS.
Your argument in relation to GitHub does not take in the reality of the effort involved with migrating to a different platform, effort that is likely unpaid, has no logistical upside and stalls the development efforts of a project, not to mention breaking every single source code repository link across the wider internet, links that represent publicity and community engagement.
It’s one thing migrating after a service vanishes, it’s an entirely different thing to migrate due to the philosophical differences perceived by the ownership change to Microsoft. In my opinion, chanting FOSS is insufficient as an argument.
I have several projects and clients that use GitHub and while I detest copilot and the enshitification that the new ownership represents, I’m also aware that it’s likely that the sale provides financial security to the continued existence of GitHub.
I think it’s admirable that a project is asking its community if it should stay or move and I wish the developer(s) wrestling with this all the strength and patience in the world to work through it.
I know I’ve struggled with the same considerations and I’m still using GitHub … for now.
Your argument in relation to GitHub does not take in the reality of the effort involved with migrating to a different platform, effort that is likely unpaid, has no logistical upside and stalls the development efforts of a project,
forgejo can automatically import issues, PRs, Wiki articles, and automatic pull/push mirrors can be set up to keep the repo up to date at other places.
the CI/CD system is almost the same.
all the usual features are the same or very similar, including the whole user interface.
not to mention breaking every single source code repository link across the wider internet, links that represent publicity and community engagement.
who said they need to delete the repo from github?
I think it’s admirable that a project is asking its community if it should stay or move
it indeed would be admirable if the communication did not contain offensive tones at multiple places.
and also don’t forget that they already migrated once. but in the meantime it seems they have gone back to github for reasons unknown to me.
You’re right. I don’t mean to minimize the effort required. The effort required is a big part of the argument in favor of moving, or at least aspiring to move to a platform with more open and interoperable values. I can’t imagine MS will make that transition any easier as time goes on despite forgejo and others best efforts. I’ve no problem with an OSS projects using GH but I’d hope they’d take the risk more seriously in a discussion about it.
Edit: I also don’t think the effort is wasted or insurmountable. Regarding broken links, I’ve stumbled across many projects that have changed their GH repo to a mirror and link to their new platform. And RE logistical v philosophical reasons, I consider avoiding vender lock-in to be risk management and part of a project’s long-term logistics.
I’m a software developer with over 40 years experience. Much of it with FOSS.
Your argument in relation to GitHub does not take in the reality of the effort involved with migrating to a different platform, effort that is likely unpaid, has no logistical upside and stalls the development efforts of a project, not to mention breaking every single source code repository link across the wider internet, links that represent publicity and community engagement.
It’s one thing migrating after a service vanishes, it’s an entirely different thing to migrate due to the philosophical differences perceived by the ownership change to Microsoft. In my opinion, chanting FOSS is insufficient as an argument.
I have several projects and clients that use GitHub and while I detest copilot and the enshitification that the new ownership represents, I’m also aware that it’s likely that the sale provides financial security to the continued existence of GitHub.
I think it’s admirable that a project is asking its community if it should stay or move and I wish the developer(s) wrestling with this all the strength and patience in the world to work through it.
I know I’ve struggled with the same considerations and I’m still using GitHub … for now.
forgejo can automatically import issues, PRs, Wiki articles, and automatic pull/push mirrors can be set up to keep the repo up to date at other places.
the CI/CD system is almost the same.
all the usual features are the same or very similar, including the whole user interface.
who said they need to delete the repo from github?
it indeed would be admirable if the communication did not contain offensive tones at multiple places.
and also don’t forget that they already migrated once. but in the meantime it seems they have gone back to github for reasons unknown to me.
Certainly it was a mistake to use Github in the first place.
You’re right. I don’t mean to minimize the effort required. The effort required is a big part of the argument in favor of moving, or at least aspiring to move to a platform with more open and interoperable values. I can’t imagine MS will make that transition any easier as time goes on despite forgejo and others best efforts. I’ve no problem with an OSS projects using GH but I’d hope they’d take the risk more seriously in a discussion about it.
Edit: I also don’t think the effort is wasted or insurmountable. Regarding broken links, I’ve stumbled across many projects that have changed their GH repo to a mirror and link to their new platform. And RE logistical v philosophical reasons, I consider avoiding vender lock-in to be risk management and part of a project’s long-term logistics.