Ye, some of these i started thinking of after i made my comment, which is my bad. Its true a project that uses the full github stack is harder to move, its its still relatively easy. The only problem you’d have is redirecting traffic to a new host, but this problem exists in all platforms and not only in project management sites like github.
As for your bulletpoints, i have a few remarks. Mainly that github pages are silly and they should not be used as a website. And even if you are, there are tools out there to convert the markdown from github pages into html/css/js so moving that is easy. Same with wiki pages, they are just markdown. 90% of markdown is compatible with other sites, and the parts that arent probably have a site specific syntax that youll need to look up, nothing bad. Review comments i will disregard, as those are part of the PR process. Once a project is moved you could hide the PR tab on github or close all new ones redirecting them to the new host. All older ones can be handled and phased out. Once a pr is merged, get the commit from github and push it to the new host. Thanks git!
Random contributers have nothing to say imo. If a project’s team feels the need to move away from github a true contributer/side team member/helper will move with them, and if they dont then so be it. Once a project team feels the need to move, something bad must be going on and moving will always be the better move for their mental health than to keep working with bad stuff.
As mentioned before ci/release pipelines are all yaml. Their odeas stay the same, only action names & their patameters change. Nothing complex there to move there…
So im short : only moving your traffic is a real problem, but is a problem on all websites and all communities, not just github or a project on github
As I said, it is not impossible to move away from gh compared to many other cases in other industries, just that it is more difficult than necessary because vendor-lockin is allowed.
If vendor-lockin was illegal, companies had more incentives to use established or create new standards to facilitate simpler migration between software stacks, without changing the external interface.
For instance allowing your own DNS name to be used as the repo/project basepath instead of enforcing github.com, Allowing comments, reviews, issues and pull requests via email or other federated services, instead of enforcing github accounts to do so, providing documented, stable and full-featured APIs for every component of their software, so that it is easy to migrate and pick and choose different components of their while stack from possible different vendors, …
There are so many ways that would improve the migration situation, while also providing more ways for other ideas to compete on a level playing field. If a bright engineer has an idea for improving one component from github, they should not be required to write a whole separate platform first.
Small aside: Microsoft GitHub’s proprietary Markdown fork is certainly not 90% compatible—most egregious IMO was overloading blockquote semantics with callouts which breaks semantics all over the web. Some providers & forks have had to support their fork due to the monopoly control MS GitHub asserts.
Ye fair, it all depends on what markup you have and what features you use. Personally i dont think my markup of priiloader has any weird stuff that is specific to github, but i will have to check to be honest. If there was any special stuff id try to steer away from github specifics as much as i can, because i believe and work in a way it should always be possible to take away any part of a project and replace it with something else. It makes projects very flexible to change
Do you mean admonitions? E.g. info, warning, etc? There’s precedent for that in commonly-used open source implementations, e.g. obsidian.md (which uses the same syntax, and started before). What semantics does it break? It’s designed to read well in plaintext and render nicely even if used in a renderer that doesn’t support admonitions, e.g.
[!NOTE]
Information the user should notice even if skimming.
As opposed to other common markdownish implementations that use nonsensical plaintext which renders poorly in alternative renderers. Here’s a discussion on the topic in the CommonMark forums.
Ye, some of these i started thinking of after i made my comment, which is my bad. Its true a project that uses the full github stack is harder to move, its its still relatively easy. The only problem you’d have is redirecting traffic to a new host, but this problem exists in all platforms and not only in project management sites like github.
As for your bulletpoints, i have a few remarks. Mainly that github pages are silly and they should not be used as a website. And even if you are, there are tools out there to convert the markdown from github pages into html/css/js so moving that is easy. Same with wiki pages, they are just markdown. 90% of markdown is compatible with other sites, and the parts that arent probably have a site specific syntax that youll need to look up, nothing bad. Review comments i will disregard, as those are part of the PR process. Once a project is moved you could hide the PR tab on github or close all new ones redirecting them to the new host. All older ones can be handled and phased out. Once a pr is merged, get the commit from github and push it to the new host. Thanks git!
Random contributers have nothing to say imo. If a project’s team feels the need to move away from github a true contributer/side team member/helper will move with them, and if they dont then so be it. Once a project team feels the need to move, something bad must be going on and moving will always be the better move for their mental health than to keep working with bad stuff.
As mentioned before ci/release pipelines are all yaml. Their odeas stay the same, only action names & their patameters change. Nothing complex there to move there…
So im short : only moving your traffic is a real problem, but is a problem on all websites and all communities, not just github or a project on github
As I said, it is not impossible to move away from gh compared to many other cases in other industries, just that it is more difficult than necessary because vendor-lockin is allowed.
If vendor-lockin was illegal, companies had more incentives to use established or create new standards to facilitate simpler migration between software stacks, without changing the external interface.
For instance allowing your own DNS name to be used as the repo/project basepath instead of enforcing github.com, Allowing comments, reviews, issues and pull requests via email or other federated services, instead of enforcing github accounts to do so, providing documented, stable and full-featured APIs for every component of their software, so that it is easy to migrate and pick and choose different components of their while stack from possible different vendors, …
There are so many ways that would improve the migration situation, while also providing more ways for other ideas to compete on a level playing field. If a bright engineer has an idea for improving one component from github, they should not be required to write a whole separate platform first.
Small aside: Microsoft GitHub’s proprietary Markdown fork is certainly not 90% compatible—most egregious IMO was overloading blockquote semantics with callouts which breaks semantics all over the web. Some providers & forks have had to support their fork due to the monopoly control MS GitHub asserts.
Ye fair, it all depends on what markup you have and what features you use. Personally i dont think my markup of priiloader has any weird stuff that is specific to github, but i will have to check to be honest. If there was any special stuff id try to steer away from github specifics as much as i can, because i believe and work in a way it should always be possible to take away any part of a project and replace it with something else. It makes projects very flexible to change
Do you mean admonitions? E.g. info, warning, etc? There’s precedent for that in commonly-used open source implementations, e.g. obsidian.md (which uses the same syntax, and started before). What semantics does it break? It’s designed to read well in plaintext and render nicely even if used in a renderer that doesn’t support admonitions, e.g.
As opposed to other common markdownish implementations that use nonsensical plaintext which renders poorly in alternative renderers. Here’s a discussion on the topic in the CommonMark forums.