Bye, Bye GitHub(log.ozgur.works) |
Bye, Bye GitHub(log.ozgur.works) |
While I can host Forgejo just fine[2], doing so means no one will be able to contribute to the projects, since federation isn’t a thing yet. Heck, getting contributions on SourceHut was hard enough, and it doesn’t even require people to register an account.
I might need to bite the bullet and go with GitHub. Regardless of what I think about the company and Microsoft, it’s where the people are.
[1]: https://sourcehut.org/blog/2026-08-27-tos-changes-and-llms/
[2]: And already do locally, as a mirror to SourceHut.
I may try out tangled.sh. It's really nice to have my code stored and backed up somewhere other than infra I control and manage.
Outcome? Everyone on their own self-hosted git servers, zero collaboration.
Everyone sticking to Github, then a year or two from now Github resolves their scaling issues and the competitors miss their window of opportunity to disrupt
Codeberg only banned projects that are majority LLM-coded. They did not ban all use of LLMs.
When people ask why people aren't switching to Gitlab, ADO, Bitbucket, etc, I believe this is the reason.
For personal or team setups, any third-party service will work well.
Open source projects existed just fine before GitHub, and they will exist just fine if they choose to move off GitHub as well. It's not a big deal if people won't do drive by contributions any more.
You don't have to; all the GitHub killers support GitHub sign on
I use https://sharemygit.com to share repos around.
I know, GitLab. Gitea. Bitbucket. They have some features, but it’s like suggesting I drive a Nissan Sentra because my BMW breaks down once in a while.
I look forward to when GitHub Actions has feature parity with Azure Pipelines.
Like even with the "will somebody please think of the operational costs" aspect, I really do wonder if the good old lock-in extortion math actually still holds in GH's favor.
Do you have a source for that claim?
Opinion: Complex build processes are great. Complex _pipelines_ are a trap. I'm in a position to see the output of a lot of teams at a very large company. The teams that have complex build processes _that they can run locally_, and then have some trivial CI yaml to run the build, are doing great.
The teams that designed their build around CI are brittle and eventually end up in a state where they can _only_ do some parts of their build on CI.
IME it's worth it to set very hard boundaries shaped like: (1) Everything needs to be able to be run locally (usually in a devcontainer), (2) CI config shall be stupid simple. If you have more than like two lines in a script section, it goes into a Tools/Build script file that must work locally and is just called in a one-line CI script.
#1 guarantees you can operate without CI, and #2 guarantees you can move CI providers trivially.
Beware the trap of making the pipeline so complicated it's like code except you can't debug or unit test like regular code, and it takes an hour between attempts to see if a change worked.
Oh, we do have Docker/Podman?
Then why not use _them_ to define your build pipelines? Bonus points: you can run them locally without tearing out your hair. And you can use normal scripting languages and task runners (taskfiles, good old makefiles, Ninja, etc.) for sequencing.
Also, I wonder what this means in practice, especially in terms of GitHub:
> MAI-Thinking-1 was trained on clean and appropriately licensed data, with AI-generated content excluded from pre-training.
Aaaand the question answers itself, because the above sentence is now gone from the page, replaced with:
> We trained it from the ground up on clean, traceable and enterprise-grade data, without distillation from third-party models.