Pourquoi des développeurs quittent GitHub pour Codeberg et des alternatives auto-hébergées
(howtogeek.com)- GitHub reste une immense plateforme, avec plus de 600 millions de dépôts et près d’un milliard de commits enregistrés en 2025, mais certains projets open source choisissent d’autres solutions d’hébergement en raison de pannes et d’une perte de confiance dans son orientation opérationnelle
- Ghostty, Zig et Tenacity ont quitté GitHub ou n’y conservent plus que des miroirs en lecture seule ; Dillo et Hare ont également migré, tandis que des projets comme GNOME et Apache ont opté dès le départ pour l’auto-hébergement
- Le grief le plus direct concerne les interruptions de service : IncidentHub a suivi 48 « major outages » de GitHub et un total de 112 heures d’indisponibilité sur un an à partir de mai 2025
- Parmi les controverses politiques, le contrat de 200 000 dollars de GitHub lié à l’ICE est mentionné ; l’extension de l’intégration de l’IA et la déclaration du CEO Thomas Dohmke en 2025, « Either you embrace AI, or get out of this career. », ont aussi renforcé les critiques
- Codeberg, GitLab, Bitbucket, Sourcehut, Gitea et Forgejo offrent des alternatives réalistes hors de GitHub, avec suivi des issues, hébergement de pages statiques, CI/CD, workflows par e-mail et exploitation de forges propres
La taille de GitHub et les signes de départ
- GitHub reste, selon de nombreux indicateurs, une plateforme de développement largement dominante
- Un nouvel utilisateur s’inscrit chaque seconde
- La plateforme héberge plus de 600 millions de dépôts
- Près de 1 milliard de commits ont été créés en 2025
- Cependant, certains utilisateurs s’inquiètent de sa stabilité technique et de la direction prise par GitHub
- Les critiques techniques se concentrent sur les indisponibilités fréquentes
- Depuis le rachat par Microsoft, l’orientation politique est aussi devenue un sujet plus sensible
- Alors que certains projets connus s’orientent vers un départ complet de GitHub, certains y voient le possible début d’un mouvement de départ plus large
Les projets qui ont quitté GitHub
- Quand on cherche des logiciels open source, on peut avoir l’impression que presque tous les projets sont sur GitHub, mais de nombreux cas ont aussi leur domicile principal ailleurs
- Le code source du noyau Linux dispose d’un miroir en lecture seule sur GitHub
- Son domicile principal réel se trouve sur un domaine distinct
- Ghostty est l’un des exemples de départ les plus visibles
- Ghostty est un émulateur de terminal multiplateforme
- Son mainteneur, Mitchell Hashimoto, a annoncé qu’en avril 2026 Ghostty quitterait GitHub
- La migration ne sera pas immédiate : le projet prévoit de supprimer progressivement ses dépendances à GitHub et de conserver un miroir en lecture seule à l’URL actuelle
- Zig a également annoncé son départ de GitHub en novembre 2025
- Zig est un langage de programmation système présenté comme un héritier spirituel de C
- Son premier commit date de 2015, et le projet a été exploité sans interruption sur GitHub jusqu’à récemment
- Tenacity est un autre projet majeur à avoir migré hors de GitHub
- Tenacity est un éditeur audio multiplateforme
- Le projet a annoncé sa migration sur un forum Reddit en 2023 et ne conserve désormais qu’un miroir sur GitHub
- Le navigateur web Dillo et le langage de programmation Hare ont également migré, tandis que GNOME et de nombreux logiciels d’Apache ont choisi dès le départ un hébergement propre plutôt que GitHub
Les raisons du départ : pannes, politique et IA
- Les raisons pour lesquelles les mainteneurs quittent GitHub ne se résument pas à un seul facteur
- La critique technique la plus récurrente concerne les pannes fréquentes
- IncidentHub a suivi 48 « major outages » sur GitHub pendant un an à partir de mai 2025
- Le temps d’indisponibilité total a été estimé à 112 heures
- Ces pannes sont citées parmi les facteurs ayant conduit aux migrations de Ghostty et Zig
- Les raisons politiques font aussi partie du contexte de ces départs
- Andrew Kelley, créateur de Zig, a mentionné les relations entre GitHub et l’ICE
- Le contrat de 200 000 dollars de GitHub lié à l’agence de contrôle de l’immigration avait déjà été critiqué par des employés en 2019
- L’intégration de l’IA alimente également les débats autour de GitHub
- GitHub intègre de plus en plus Copilot
- En 2025, le CEO Thomas Dohmke a déclaré : « Either you embrace AI, or get out of this career. »
- Mitchell Hashimoto a déclaré que GitHub n’était plus un endroit agréable pour travailler et qu’il donnait l’impression d’entraver le travail et la distribution de logiciels
Les projets qui ont évité GitHub dès le départ
- Indépendamment des projets qui ont quitté GitHub, certains ne l’ont jamais choisi
- Le GNU Project rejette GitHub pour des raisons idéologiques
- Il critique le fait que GitHub nécessite du JavaScript non libre pour fonctionner
- Il estime que GitHub encourage de « mauvaises pratiques de licence »
Les options hors de GitHub
- Codeberg est l’un des principaux services concurrents choisis par des projets comme Zig à la place de GitHub
- Il propose des fonctionnalités similaires à GitHub, comme le suivi des issues, l’hébergement de pages statiques et la CI/CD
- GitLab et Bitbucket sont également cités comme alternatives
- GitLab offre une option d’auto-hébergement
- Bitbucket est présenté comme une alternative contemporaine de GitHub
- Sourcehut est un service entièrement open source
- Il propose des fonctionnalités correspondant aux fonctions clés de GitHub
- Il met l’accent sur les workflows fondés sur l’e-mail
- Il est aussi possible d’exploiter sa propre forge
- Gitea et Forgejo sont mentionnés comme options populaires
- Forgejo est le logiciel qui fonctionne derrière Codeberg
- Des initiatives comme la campagne Give Up GitHub de la Software Freedom Conservancy aident aussi à quitter GitHub
Des critères de décision différents selon les projets
- GitHub est reconnu comme une application web qui a joué un rôle important dans la promotion du développement open source et de la collaboration
- Dans le même temps, il présente à la fois des problèmes techniques et des problèmes idéologiques
- Selon leur position, les développeurs et les projets peuvent continuer à utiliser GitHub ou choisir des alternatives comme Codeberg, GitLab, Bitbucket, Sourcehut, Gitea, Forgejo ou l’auto-hébergement
1 commentaires
Avis sur Hacker News
En laissant de côté les sentiments pour ou contre GitHub, les articles du type « pourquoi X fait Y » font comme si la prémisse X fait Y était vraie, puis passent directement au « pourquoi » avant même de démontrer que cette prémisse est exacte de façon significative
C’est pour ça que je ne fais pas confiance aux titres qui commencent par « Why »
On nous dit que « les développeurs partent », mais en réalité on ne cite que quelques dépôts vaguement significatifs parmi des centaines de milliers
Maintenant, le service est devenu tellement mauvais que, dès qu’un outil de l’entreprise ralentit ou tombe, quelqu’un fait une blague sur GitHub
La réputation est un actif extrêmement précieux, et GitHub a détruit en quelques mois une excellente réputation ; ça, c’est digne d’intérêt
Le point essentiel, comme d’autres l’ont dit, c’est la tendance
D’après ce que j’ai entendu de plusieurs responsables de grands projets open source, la raison pour laquelle ils restent encore sur GitHub aujourd’hui, ce sont les crédits GitHub Actions gratuits. Autrement dit, ils ne pourraient pas assumer le coût du CI/CD s’ils partaient, donc les chiffres seraient plus élevés si GitHub ne les « payait » pas pour rester
https://www.paulgraham.com/submarine.html
J’ai utilisé Codeberg pendant un an, et au début de cette année, Codeberg a décidé de montrer de son propre chef du texte aléatoire hostile à la place du dépôt. Apparemment, le but était de perturber l’entraînement des LLM pour les user agents dont ils n’étaient pas certains qu’ils soient humains
Codeberg n’avait qu’un seul travail : servir les dépôts. Ils ont échoué à le faire, et quand j’ai signalé le problème, on m’a répondu que ce n’était pas un bug mais une fonctionnalité. Ils ont bien proposé de me mettre sur liste blanche, mais le problème n’était pas moi : c’était le fait que des gens choisis arbitrairement se retrouvaient complètement bloqués pour accéder au dépôt. J’ai fini par revenir sur GitHub
Ce message de quelques secondes est à ce point gênant qu’il rend Codeberg inutilisable pour toi ? Ou bien, chez toi, ça dure bien plus de 2 secondes ?
Chacun a sa propre tolérance, mais de mon point de vue, Codeberg mène un bon combat pour empêcher les LLM de scraper le site
J’imagine qu’exploiter une forge logicielle est plus difficile que je ne le pensais
Ça fait 9 mois que j’ai quitté GitHub
Maintenant, j’héberge moi-même Gitea, que j’utilise comme registre pour Docker et NPM, avec act runner comme alternative à GitHub Actions, le tout protégé à l’intérieur d’un tailnet
Je suis très satisfait de cette configuration. Elle contient tout ce qu’il me faut et, une fois mise en place, elle demande très peu d’attention
À présent, je n’utilise GitHub que comme sauvegarde pour mettre en miroir mes dépôts auto-hébergés
[0] https://gitea.com
[1] https://docs.gitea.com/usage/actions/act-runner
J’ai d’abord mis en miroir tous mes dépôts GitHub, puis j’ai migré en priorité les plus utilisés
Le plus gros avantage, c’est que je peux maintenant faire tourner un runner Apple sur mon Mac, ce qui me permet de réserver les GitHub Actions gratuits à autre chose
Pour les projets publics, j’ai des workflows qui publient et poussent des conteneurs à la fois sur Gitea et sur GitHub
En revanche, pour mes projets open source personnels, je les garde tous sur GitHub, là où tout le monde est, afin de faciliter le partage et la collaboration
Le CI de toute l’organisation https://github.com/lightningdevkit est resté hors service pendant 3 semaines. La raison : un contributeur externe, bloqué de manière injustifiée, avait ouvert une PR
Il a fallu contester plusieurs fois, sans jamais obtenir d’explication, seulement une réponse disant que le blocage était permanent, et le problème n’a été résolu qu’après un esclandre sur Twitter. Malheureusement, ce n’est plus un endroit agréable pour travailler
En tant que développeur ayant quitté GitHub pour l’auto-hébergement, je n’ai qu’une seule raison. Ni la difficulté technique, ni la politique, ni l’IA : Microsoft
Comme Apple ou Facebook, je déteste profondément Microsoft et je veux l’éliminer de ma vie autant que possible
Aujourd’hui, je fais tourner Git avec Gitea et Forgejo sur un Raspberry Pi. Je peux y envoyer des fichiers d’une taille difficile à imaginer sur GitHub, et si Claude ouvre seul une PR, je peux relire les différences, les corriger puis fusionner. Même avec la seule puissance d’un Pi 3B+, l’ensemble me semble plus réactif
Les développeurs, moi y compris, n’aiment pas entendre qu’ils vont être licenciés à cause d’IA entraînées sur des projets open source gratuits faits comme hobby
Si le monde finit par accepter les LLM comme une méthode valide de blanchiment de licence, je ne vois pas bien comment m’y opposer
Le code privé semble plus sûr en auto-hébergement. Idéalement, le placer derrière WireGuard ajoute une couche de sécurité supplémentaire
Pour l’hébergement de code public, GitHub bloque trop de personnes et de projets, et ça me met mal à l’aise. Des chercheurs en sécurité jusqu’aux développeurs de jeux pour adultes, il y a trop de cas de blocages injustifiés
Je me demande si la multiplication des services d’hébergement de code s’accompagnera aussi d’une hausse des systèmes alternatifs de gestion de versions, ou si Git est vraiment trop profondément ancré comme outil
C’est un peu une plainte de ma part, mais j’aimerais voir davantage de développement autour de systèmes de gestion de versions alternatifs. Pijul a l’air sympa, même si je ne sais pas ce qu’il vaut en matière de montée en charge. Git LFS peut être assez pénible à gérer par moments, donc on pourrait aussi voir apparaître davantage de systèmes à la Perforce
Il est clair que disposer d’une grande variété de systèmes de gestion de versions très différents les uns des autres n’est pas forcément pratique, et apprendre plusieurs outils est vraiment pénible, mais quand on entend des anecdotes de gens qui se contentent de re-cloner le dépôt, Git ne semble pas totalement optimal. J’ai essayé jj récemment et, à part l’absence de support de LFS, ça avait l’air de bien fonctionner, donc j’ai bon espoir
L’auto-hébergement pourrait aussi gagner en popularité. Jusqu’à récemment, je n’en entendais pas beaucoup parler
Si LFS est une souffrance, je dois mentionner Oxen, parce que je n’arrive vraiment pas à utiliser Git LFS. C’est open source, auto-hébergeable, et il existe aussi une offre hébergée. Gérer les gros fichiers dès le départ, et le faire plus vite que quiconque, est l’un de ses objectifs principaux. Pour la distribution, ils utilisent encore GitHub, ce qui est assez drôle : https://github.com/Oxen-AI/Oxen
Je me demande aussi où va aller jj. Sa philosophie est vraiment intéressante et prometteuse
En tant que quelqu’un qui a déjà auto-hébergé Git et trouvé la maintenance pénible, je suis sincèrement curieux. J’aimerais savoir pourquoi les développeurs se ruent vers d’autres plateformes, et comment ils peuvent être sûrs que ces plateformes ne montreront pas les mêmes signaux d’alerte que GitHub
Une ou deux fois par an, une mise à jour demande une intervention ; sinon, rien de particulier. Jusqu’ici, nous en sommes très satisfaits
Le principal problème actuellement, ce sont les scrapers IA, qui ralentissent parfois l’ensemble. Cela dit, ce n’est pas quelque chose que quelques règles de pare-feu et anoubis ne puissent pas régler
Si vous voulez un service hébergé, vous pouvez utiliser Codeberg. Il est géré par une association à but non lucratif allemande, donc il lui est plus difficile de mordre soudainement à l’hameçon et de pivoter à la manière d’OpenAI. En revanche, ils n’acceptent que les projets libres et open source
Cela fait environ un an que nous faisons de l’auto-hébergement GitLab, et je ne me souviens pas d’une seule fois où il a été hors service ou inutilisable
À part les réunions en ligne, nous auto-hébergeons aussi presque tout le reste, et dans l’ensemble c’est assez stable. Certains outils tombent parfois en panne, mais en général il suffit de redémarrer la VM ou d’ajouter un peu d’espace de stockage
Ce n’est pas la seule option dans ce domaine, mais parmi celles que j’ai vues jusqu’ici, c’est l’une des plus faciles à déployer
J’envisage moi aussi l’auto-hébergement, mais mon objectif est l’open source, donc les scrapers et les autres trafics de type DOS m’inquiètent