While I don't use GitHub for personal projects, I don't see how moving off GitHub solves anything. If you are open source contributor, then repositories you interact with are public, and there is nothing preventing anybody (including GitHub) from using your code for any purpose. If you contribute to a public repository on any public platform, be it Codeberg, sourcehut or GitLab, your activity is public, issue you create are public[1], everybody knows who changed what in the code.
The social media effects are twofold, on one hand I think stars and contributors count, contributor profiles are great to see what is popular, but it went a little too far when they added scrollable home page. Virtually everyone has an account on GitHub, the best way to make your project visible and ease the contribution threshold is to put your project on GitHub.
What I would like to see is federated git, so that some protocol allowed different git servers could communicate with each other, which will make moving off GitHub much easier.
[1]: except for sourcehut I guess, which does not have issues or pull requests?
> Features like GitHub Actions, Copilot, and Codespaces also creates vendor lock-in.
It is possible to use GitHub Actions in ways that do not create vendor lock-in. (Unfortunately this is not always the case.)
> GitHub tracks user behavior through telemetry data, including all interactions on the platform
You might be able to work with using only the API, like I do (I can't log in anyways (due to forced 2FA that doesn't work), so I have to use the API). (There might still be server-side logging, but this should prevent client-side telemetry.)
> and GitHub Copilot uses the publicly available source code to train its AI
Publicly available source code is public and can already be used by anyone anyways.
> Rather than promoting quality software, it has become a matter of "stars" and "likes".
I think that you do not have to use these features; you can still host a mirror of your repository. I find the "stars" and "likes" to not be very helpful anyways. It is a problem that many people try to overemphasize these features, though.
> GitHub's decision-making processes regarding policy changes and feature implementations has no regard for users and it can change at any time
I do believe that there are significant problems with their policies, so they are right about that part.
> Consider open source self-hosting solutions
I think having multiple mirrors is more helpful, whether or not GitHub, Codeberg, etc are some of them. (You might want to mention the multiple mirrors in the README file. Some projects on GitHub already do this.)
The hashes can be used to identify git objects regardless of which mirrors are being used, and you can also have signed commits.
• Pages often take tens of seconds to load, even on a stable internet connection.
• Using the back/forward buttons takes a few seconds and if I click them several times, it results in the page shown not matching the URL bar.
• If I click an anchor link and then press the back button, it does not send me back. (Very annoying when reading READMEs and using table-of-contents links.)
I've been mirroring all my public projects on GH and Codeberg using CI to keep things in sync, and add a note to my README's [1] explaining that both can be used. In practice the vast majority of OSS contributors are on Github so it's just not reasonable for smaller projects trying to grow to be anywhere else. Larger projects have enough pull that they can do what they want.
For me, I begrudgingly use GitHub for my personal projects because GitHub Actions is free. If I move elsewhere, I'll have to stop providing precompiled binaries for OS's that I can't cross-compile for from Linux (eg. macOS).
I would not provide precompiled binaries for other systems if I could not even test it properly (nor know all of the details for programming for those other systems), whether or not it uses GitHub Actions.
If you do use GitHub Actions for compiling, then it might be better for the actual implementation of compiling to be in a separate file (which can also be used outside of GitHub) and the GitHub Actions file will only specify the conditions to trigger that separate file.
(I do use GitHub Actions, but only to automatically assign issues to myself (which is not something that is necessary in order to work the software that is being made by your repository). If it is moved to (or copied or mirrored to) something else that cannot use GitHub Actions files, it might have another way to auto-assign issues or make it unnecessary to do s.)
Yeah, my GitHub Actions workflows don't do much more than `cargo build --release && cargo test --release`. I don't use any of the fancy features that would lock me in.
It's really just running the tests on Mac that I rely on it for. For Windows and Android, I can (and regularly do) use wine and qemu-user-static to run the tests on Linux. My project (a computationally heavy CLI tool) is simple though. It doesn't need much from the OS besides memory allocation, thread spawning, and opening a user-specified file.
Because GitHub is incredibly reliable, it'd take more than zero effort to move it, and I'd lose whatever small community I've already built up around it.
This is like asking "Why are you still using Facebook" and you'll get very similar answers.
Exactly. Github is the Facebook of code hosting. It's the place where you can make money and that's why people use it: some form of eventual profit motive. Weather actual money or just as a resume.
But why not using Github, if I develop my open-source projects mostly alone and if I don't care about Microsoft supporting US and Israel governments?
And in case if it will be no longer possible (if Github will be fully enshittificated) it's relatively easy to switch to another platform, much more easier compared to switching from Facebook or Twitter.
> For software developers, giving up GitHub will be even harder than giving up Facebook and Twitter/X!
This is not so sure; the git format is supported by many services so mirrors can easily be made. It can be difficult if you are using some of their proprietary features for important purposes, but hopefully you might be able to avoid those things (I do avoid them for this purpose).
> Copilot's AI model was trained (according to GitHub's own statements) exclusively with projects that were hosted on GitHub, including many licensed under copyleft licenses.
Whether or not that is true, projects may be mirrored, forked, back up copies, etc on GitHub even if the original one isn't, or if it has been deleted or moved since then it might still be used. Even if they are not on GitHub, someone else might try to use them for training the AI models whether or not Microsoft does.
Nevertheless, the real problem is if someone else other than who originall wrote the software, will add additional restrictions on their modified versions by use of copyright, even though it was originally intended to prevent such a thing. (I think abolishing copyright entirely would be a better solution.)
> Microsoft's Copilot is now generating issues and pull requests and GitHub users cannot opt out
I have not experienced this. (If you have experienced this, then you might try to make a GitHub Actions file to automatically delete any issues generated by Copilot, and see if that will work. If GitHub Actions files are not executed for issues and pull requests from Copilot, then possibly something similar to what I did with auto-assignment using GitHub Actions, might help to allow the ones with Copilot to be ignored.)
> The reason that it's difficult to leave GitHub is a side-effect of one of the reasons to leave them: proprietary vendor lock-in. We are aware that GitHub, as the “Facebook of software development”, has succeeded in creating the most enticing walled garden ever made for FOSS developers. Just like leaving Facebook is painful because you're unsure how you'll find and talk with your friends and family otherwise — leaving GitHub is difficult because it's how you find and collaborate with co-developers.
Not all features require vendor lock-in, e.g. if you only host mirrors of the repositories on GitHub then it does not require the proprietary vendor lock-in.
Problems can occur, if anyone who wishes to discuss it is required to use GitHub, or if you require complicated GitHub Actions files that cannot easily be ported to use on something else, etc.
> We also know that some Computer Science programs even require students to use GitHub.
This seems to be more of an issue with Computer Science programs that require the external services and registration than GitHub itself, although that is still a part of it too.
> Below we include a list of various options for both third-party hosting and self-hosting
I think it would be helpful to make an improved service in many ways. For example, ensure that JavaScripts and CSS are not required, allow X.509 client authentication (this also makes it possible for such things as API keys to be portable to other services if you move your project or make up your own, since the public keys are public and can be trusted by anyone who wishes to do so; and can do so without needing vendor-locking 2FA and stuff like that; and if the other service is malicious, they cannot use this to impersonate you on your first service, so it is also more secure), and better work with non-Unicode text, multiple version control systems possible, the ability to mirror issues and comments, etc.
Because that's how and where people find them.
Related questions with same answer: Why do you still use Facebook? Why do you still use LinkedIn? Why do you still use YouTube?
While I don't use GitHub for personal projects, I don't see how moving off GitHub solves anything. If you are open source contributor, then repositories you interact with are public, and there is nothing preventing anybody (including GitHub) from using your code for any purpose. If you contribute to a public repository on any public platform, be it Codeberg, sourcehut or GitLab, your activity is public, issue you create are public[1], everybody knows who changed what in the code.
The social media effects are twofold, on one hand I think stars and contributors count, contributor profiles are great to see what is popular, but it went a little too far when they added scrollable home page. Virtually everyone has an account on GitHub, the best way to make your project visible and ease the contribution threshold is to put your project on GitHub.
What I would like to see is federated git, so that some protocol allowed different git servers could communicate with each other, which will make moving off GitHub much easier.
[1]: except for sourcehut I guess, which does not have issues or pull requests?
https://forgefed.org/
> Features like GitHub Actions, Copilot, and Codespaces also creates vendor lock-in.
It is possible to use GitHub Actions in ways that do not create vendor lock-in. (Unfortunately this is not always the case.)
> GitHub tracks user behavior through telemetry data, including all interactions on the platform
You might be able to work with using only the API, like I do (I can't log in anyways (due to forced 2FA that doesn't work), so I have to use the API). (There might still be server-side logging, but this should prevent client-side telemetry.)
> and GitHub Copilot uses the publicly available source code to train its AI
Publicly available source code is public and can already be used by anyone anyways.
> Rather than promoting quality software, it has become a matter of "stars" and "likes".
I think that you do not have to use these features; you can still host a mirror of your repository. I find the "stars" and "likes" to not be very helpful anyways. It is a problem that many people try to overemphasize these features, though.
> GitHub's decision-making processes regarding policy changes and feature implementations has no regard for users and it can change at any time
I do believe that there are significant problems with their policies, so they are right about that part.
> Consider open source self-hosting solutions
I think having multiple mirrors is more helpful, whether or not GitHub, Codeberg, etc are some of them. (You might want to mention the multiple mirrors in the README file. Some projects on GitHub already do this.)
The hashes can be used to identify git objects regardless of which mirrors are being used, and you can also have signed commits.
It's the standard. Opposition to GitHub tends to be on moral grounds, rather than the product itself.
On technical grounds, the UI is broken and slow as fuck.
Is gitlab better in some ways?
GitLab is just as bad. I personally use SourceHut, but Forgejo also seems fine.
weird, I've never had a single problem with it and I don't know anyone else who has
Problems I’ve encountered recently:
• Pages often take tens of seconds to load, even on a stable internet connection.
• Using the back/forward buttons takes a few seconds and if I click them several times, it results in the page shown not matching the URL bar.
• If I click an anchor link and then press the back button, it does not send me back. (Very annoying when reading READMEs and using table-of-contents links.)
If you disable the JavaScripts provided by GitHub and implement your own instead, then it works better, in my experience.
I've been mirroring all my public projects on GH and Codeberg using CI to keep things in sync, and add a note to my README's [1] explaining that both can be used. In practice the vast majority of OSS contributors are on Github so it's just not reasonable for smaller projects trying to grow to be anywhere else. Larger projects have enough pull that they can do what they want.
[1] https://github.com/arcuru/eidetica#repository
Because taking it out of Github does very little, when the project keeps using technologies that Microsoft pays for.
Are those moving away from Github, also dropping Typescript, .NET, Electron, npm, VSCode,....?
> Are those moving away from Github, also dropping Typescript, .NET, Electron, npm, VSCode,....?
I don’t use any of these technologies for my projects.
Do you also use anything with Linux kernel, Java on ARM, clang?
Those examples belong to the ... I left on the comment.
Because GitHub took a pretty complicated thing called git and built a featureful, fast, and friendly site. Credit where it's due.
For me, I begrudgingly use GitHub for my personal projects because GitHub Actions is free. If I move elsewhere, I'll have to stop providing precompiled binaries for OS's that I can't cross-compile for from Linux (eg. macOS).
I would not provide precompiled binaries for other systems if I could not even test it properly (nor know all of the details for programming for those other systems), whether or not it uses GitHub Actions.
If you do use GitHub Actions for compiling, then it might be better for the actual implementation of compiling to be in a separate file (which can also be used outside of GitHub) and the GitHub Actions file will only specify the conditions to trigger that separate file.
(I do use GitHub Actions, but only to automatically assign issues to myself (which is not something that is necessary in order to work the software that is being made by your repository). If it is moved to (or copied or mirrored to) something else that cannot use GitHub Actions files, it might have another way to auto-assign issues or make it unnecessary to do s.)
Yeah, my GitHub Actions workflows don't do much more than `cargo build --release && cargo test --release`. I don't use any of the fancy features that would lock me in.
It's really just running the tests on Mac that I rely on it for. For Windows and Android, I can (and regularly do) use wine and qemu-user-static to run the tests on Linux. My project (a computationally heavy CLI tool) is simple though. It doesn't need much from the OS besides memory allocation, thread spawning, and opening a user-specified file.
SourceHut builds are not free, but cheap if you’re an “amateur hacker” ($2/month).
See also:
- Important open source projects should not use GitHub (2020) - https://news.ycombinator.com/item?id=43688417 - 73 comments
- Ditching GitHub (2024) - https://news.ycombinator.com/item?id=44826484 - 65 comments
- Why Microsoft is Evil https://programmerbear.com/why-microsoft-is-evil/
Because GitHub is incredibly reliable, it'd take more than zero effort to move it, and I'd lose whatever small community I've already built up around it.
This is like asking "Why are you still using Facebook" and you'll get very similar answers.
The company i work for is adopting github in lieu of a solution hosted in our datacenters.
We've had more downtime with github than without. So I'd take the "reliable" with a grain of salt.
Exactly. Github is the Facebook of code hosting. It's the place where you can make money and that's why people use it: some form of eventual profit motive. Weather actual money or just as a resume.
But why not using Github, if I develop my open-source projects mostly alone and if I don't care about Microsoft supporting US and Israel governments?
And in case if it will be no longer possible (if Github will be fully enshittificated) it's relatively easy to switch to another platform, much more easier compared to switching from Facebook or Twitter.
https://sfconservancy.org/GiveUpGitHub/
> For software developers, giving up GitHub will be even harder than giving up Facebook and Twitter/X!
This is not so sure; the git format is supported by many services so mirrors can easily be made. It can be difficult if you are using some of their proprietary features for important purposes, but hopefully you might be able to avoid those things (I do avoid them for this purpose).
> Copilot's AI model was trained (according to GitHub's own statements) exclusively with projects that were hosted on GitHub, including many licensed under copyleft licenses.
Whether or not that is true, projects may be mirrored, forked, back up copies, etc on GitHub even if the original one isn't, or if it has been deleted or moved since then it might still be used. Even if they are not on GitHub, someone else might try to use them for training the AI models whether or not Microsoft does.
Nevertheless, the real problem is if someone else other than who originall wrote the software, will add additional restrictions on their modified versions by use of copyright, even though it was originally intended to prevent such a thing. (I think abolishing copyright entirely would be a better solution.)
> Microsoft's Copilot is now generating issues and pull requests and GitHub users cannot opt out
I have not experienced this. (If you have experienced this, then you might try to make a GitHub Actions file to automatically delete any issues generated by Copilot, and see if that will work. If GitHub Actions files are not executed for issues and pull requests from Copilot, then possibly something similar to what I did with auto-assignment using GitHub Actions, might help to allow the ones with Copilot to be ignored.)
> The reason that it's difficult to leave GitHub is a side-effect of one of the reasons to leave them: proprietary vendor lock-in. We are aware that GitHub, as the “Facebook of software development”, has succeeded in creating the most enticing walled garden ever made for FOSS developers. Just like leaving Facebook is painful because you're unsure how you'll find and talk with your friends and family otherwise — leaving GitHub is difficult because it's how you find and collaborate with co-developers.
Not all features require vendor lock-in, e.g. if you only host mirrors of the repositories on GitHub then it does not require the proprietary vendor lock-in.
Problems can occur, if anyone who wishes to discuss it is required to use GitHub, or if you require complicated GitHub Actions files that cannot easily be ported to use on something else, etc.
> We also know that some Computer Science programs even require students to use GitHub.
This seems to be more of an issue with Computer Science programs that require the external services and registration than GitHub itself, although that is still a part of it too.
> Below we include a list of various options for both third-party hosting and self-hosting
I think it would be helpful to make an improved service in many ways. For example, ensure that JavaScripts and CSS are not required, allow X.509 client authentication (this also makes it possible for such things as API keys to be portable to other services if you move your project or make up your own, since the public keys are public and can be trusted by anyone who wishes to do so; and can do so without needing vendor-locking 2FA and stuff like that; and if the other service is malicious, they cannot use this to impersonate you on your first service, so it is also more secure), and better work with non-Unicode text, multiple version control systems possible, the ability to mirror issues and comments, etc.
Are you suggesting people should continue to use github?
[dead]
[flagged]
[flagged]
What propaganda? All what he linked is by independent and free journalists and investigators.
if you want to discuss this I am happy to do so. But it won't be on HN. This is supposed to be a sacred space free from psychological warfare.
My email listed on the about section.
great I'll be in touch. salam