Posté par raphj (site web personnel) .
Évalué à 10 (+8/-0).
Dernière modification le 21 février 2026 à 12:14.
L'écosystème GitHub est un bug, pas une feature, et de plus en plus. Ils se sont fait ça à eux-même d'ailleurs, en voulant faire d'un outil de développement un réseau social.
Je me demande quand les gens commenceront à s'en rendre compte.
Les mèmes dans les tickets, les rapports de bugs de mauvaise qualité, les contributions de merde pour grossir le CV ou liées à l'Hacktoberfest, les connards avec leurs expérimentations IA…, tout ça, ça se passe sur GitHub. L'absence de frontière à l'entrée attire probablement les interactions lazy qui ne valent pas grand chose.
Entre temps, je ne suis toujours pas sûr qu'être hors de GitHub soit vraiment un frein à recevoir des contributions de qualité. La FOMO est bien réelle par contre.
Par contre, en étant sur GitHub, on continue à dépendre d'une infra et d'un logiciel non libre et d'un hébergement GAFAM pour son projet libre.
Même l'argument « oui mais au moins l'uptime est meilleur que n'importe quel truc auto-hébergé » ne tient pas, il y a sans cesse des pannes. Et puis maintenant, il y a Codeberg de toute façon, si on ne veut pas gérer ça soit-même.
Sans cette centralisation, peut-être qu'on arrêterait enfin de prendre des décisions à coups de nombre d'étoiles, aussi.
En fait, c'est un peu comme les infras cloud : tu peux très bien gérer tes VMs et les services qui tournent dessus, en minimisant le vendor lock-in, et afin de maximiser la réversibilité/facilité de migration vers une autre infra si besoin, mais c'est pas ça qui fait manger les vendeurs d'infonuagique… Ce qui est rentable, c'est les services intégrés comme les k8s managés, les bases de données managées, les intégrations autoscale/DNS/Load balancing, etc…
Et donc pour GitHub c'est pareil, le repo gratuit, c'est un produit d'appel, ça ne rapporte rien. Très vite, tu te retrouves avec des intégrations propriétaires et ça devient difficile de migrer… Alors tu payes. Cf le cas de Curl, Daniel S. a bien expliqué que ce serait hyper coûteux de migrer et devoir payer les pipelines de build.
Y'a plein de personnes ou d'équipes qui savent faire du beau code mais n'ont aucune envie ou connaissances, ou plus simplement de temps pour gérer une infra de build.
Posté par raphj (site web personnel) .
Évalué à 8 (+6/-0).
Dernière modification le 21 février 2026 à 14:44.
Cf le cas de Curl, Daniel S. a bien expliqué que ce serait hyper coûteux de migrer et devoir payer les pipelines de build.
Merci pour la mention de Curl, je ne connaissais pas la situation. Le cas de Curl ne me parait pas représentatif, il se trouve que GitHub est un sponsor de Curl. En général, tu paies ta CI, et tu peux décider de payer quelqu'un d'autre.
n'ont aucune envie ou connaissances
Plusieurs réponses à ça :
l'auto-hébergement est une alternative à GitHub, mais pas la seule. Tu peux décider de payer quelqu'un d'autre qui le fait pour toi (bon, pour tout ce qui est CI, j'ai l'impression que c'est vite très cher quand c'est pas toi qui fait toi-même, et en vrai ça vaut certainement le coup de se faire chier à mettre en place le truc dans beaucoup de cas - oui, pour Curl c'est potentiellement complexe parce qu'ils supportent une liste d'environnements longue comme le bras)
j'ai du mal à défendre la position "pas envie de m'y intéresser". C'est ce qui maintient le statut quo, dans tous les aspects de la vie, et finit par toutes et tous nous foutre dans la merde. On devrait toutes et tous nous questionner un minimum sur nos choix et ses conséquences. La vie, ça demande de s'intéresser aux choses. Après, que le choix se tourne vers GitHub après avoir peser le pour et le contre, c'est une chose, mais la position « bof, je m'en fiche », en fait ça me soûle un peu. C'est difficile de progresser sur les sujets avec des positions comme ça.
pour GitHub c'est pareil, le repo gratuit, c'est un produit d'appel, ça ne rapporte rien
On est d'accord. En plus des services autour, c'est aussi pour habituer aux gens à la plateforme pour que dans le monde professionnel, ils finissent par choisir aussi GitHub pour les besoins de l'entreprise et là, c'est payant (c'est un peu la même stratégie que Microsoft Office qui est donné (pour gratuit ou pas cher) aux étudiant·e·s).
Oui c'est un cas un peu extrême, mais il a l'avantage d'être visible. D'une manière générale, concernant les forges logicielles, j'ai l'impression que peu importe celle que tu choisis, il n'y a pas tellement d'interopérabilité. En changer revient à réécrire plein de trucs non liés au but du projet lui-même.
Toutefois, dans le cas du choix de la forge, choisir Gitlab, Codeberg ou Gitea, c'est au moins avoir la possibilité de se monter une instance chez soi et de conserver au moins une partie des intégrations.
j'ai du mal à défendre la position "pas envie de m'y intéresser". C'est ce qui maintient le statut quo, dans tous les aspects de la vie, et finit par toutes et tous nous foutre dans la merde. On devrait toutes et tous nous questionner un minimum sur nos choix et ses conséquences. La vie, ça demande de s'intéresser aux choses
Je suis d'accord avec toi, et c'est vrai que c'est peu défendable. Mais c'est explicable : en pratique, on a un temps disponible fini , et on délègue sans cesse plein d'aspects de nos vies (et pas forcément les bons comme tu dis). La curiosité, et faire un truc en dehors de ses compétences/appétences permet souvent d'en apprendre plus sur soi. Mais on ne peut pas tout avoir en priorité 1.
Et quand c'est dans le monde professionnel, c'est exacerbé, on a rarement l'occasion d'aller jouer et apprendre des trucs avec les copines de l'équipe d'à côté.
Bon après le monde professionnel du libre / de l'Open source est déjà en général engagé dans une démarche où on est censé faire un peu plus attention aux choix, et où on ne fait pas nécessairement les choix les plus simples (à commencer par le business model lui-même !). Je pense que souvent, github n'est pas un choix de la facilité, c'est un choix lié à la peur de ne pas être visible. En tout cas historiquement, et en effet après il y a un peu de lock-in.
C'est probablement une bonne idée de limiter au maximum les trucs spécifiques, et par exemple il devrait être un maximum possible de faire tourner ce qui tourne dans la ci en local, ça limite un peu le lock-in.
Toutefois, dans le cas du choix de la forge, choisir Gitlab, Codeberg ou Gitea, c'est au moins avoir la possibilité de se monter une instance chez soi et de conserver au moins une partie des intégrations.
L'éléphant dans la pièce, comme disent les américains, c'est que Github n'est pas libre, alors que les trois alternatives que tu cites (et plein d'autres), si.
Ça me semble important au moins quand il s'agit d'héberger des projets de logiciels libres. La situation peut être différente quand il s'agit d'un hébergement de projets fermés "en interne" pour une entreprise.
Et surtout ce qui est un peu rageant, c'est que avant Github, il y avait Sourceforge, et plein d'autres outils, basés entièrement sur des technologies libres. Et la partie "sociale"/découverte des projets se faisait ailleurs: via freshmeat.net et d'autres annuaires de projets, indépendants des solutions d'hébergement.
Donc on est même pas dans un cas où il n'y avait pas d'alternative libre et les gens se seraient dirigés vers Github faute d'avoir aucune autre option. Faire de l'hébergement de logiciel avec uniquement du logiciel libre, ce n'est pas le futur, ce n'est pas le présent, c'est possible depuis 30 ans.
J'espère que les efforts de Forgejo/Codeberg pour mettre en place une interface lisible et plus légère, ainsi qu'un système de fédération, pourront aider à faire que certains projets quittent Github.
Pour ma part je retourne petit à petit à de l'auto hébergement avec Trac et Gerrit. Ça marche bien malgré les attaques de robots scrappers qui s'acharnent à cliquer sur tous les liens de mon serveur…
L'éléphant dans la pièce, comme disent les américains, c'est que Github n'est pas libre, alors que les trois alternatives que tu cites (et plein d'autres), si. Ça me semble important au moins quand il s'agit d'héberger des projets de logiciels libres.
Oui, c'est pour ça que je les ai cité, c'était implicite. Merci de la précision !
Sur l'auto-hébergement, on peut préciser qu'il est aussi possible d'avoir une instance hébergée chez soi de GitHub. C'est proprio quand même, mais c'est possible. La différence réside donc dans libre/open-source/pas libre.
Sinon pour ton Trac et Gerrit, as-tu vraiment besoin de les exposer sur Internet ? (j'imagine que oui mais bon)
J'ai quelques projets avec des utilisateurs, donc oui, c'est pas mal d'avoir un bugtracker exposé. J'ai par contre mis certaines parties (comme l'exploration en ligne du code source et de son historique) réservées aux utilisateurs identifiés.
Et je met en place des blocages de plage d'IP et de user agent de plus en plus vastes en espérant que ça se calme (même s'il n'y a pas spécialement de problème de surcharge du serveur ou de ma connexion réseau pour l'instant)
Un coup d'œuil rapide sur leur github permet de voir qu'il y a 214 jobs lancés sur la branche main, pour vérifier la compilation sur toutes les plateformes (OS et arcitectures CPU) supportées, différentes dépendances (par exemple libssh ou libssh2 pour le SFTP, différents résolveurs DNS, …), plusieurs compilateurs différents (gcc, Microsoft, …), des tests de fuzzing, certains builds avec des fonctions expérimentales activées comme le support de HTTP/3, des builds "out-of-tree" et d'autres configurations plus ou moins exotiques.
Donc oui, ça a l'air un petit peu compliqué de vérifier toutes les combinaisons possibles.
Il y a aussi des éléments de réponse dans le blog de Daniel Stenberg, on en trouve d'autres sur Mastodon, mais autant dire que chercher github et curl ça ratisse large :).
Peut-être qu'avec une tour blindée de RAM et de CPUs posée dans un grenier ou une cave, ça suffirait.
Posté par raphj (site web personnel) .
Évalué à 3 (+1/-0).
Dernière modification le 23 février 2026 à 21:19.
Une tour qui serait probablement une machine Apple, parce que je suppose qu'ils ont de la CI pour macOS, et c'est à ma connaissance la seule manière légale de faire tourner macOS. Cela dit, peut-être qu'Apple devrait sponsoriser voire fournir la CI macOS, après tout ils fournissent curl par défaut avec leur OS si je ne m'abuse.
Whoa, la personne qui pense pouvoir réécrire curl en un weekend de trois jours… J'avais oublié cet article, c'est toujours un peu "marrant".
Rien que documenter chacune des options et leurs interactions prendrait probablement plus que ça xD
Si je comprend bien, pour fonder sa start-up le gus a besoin d'une boutique. Il déploie :
Load balancers, VMs, and S3-compatible object storage
Transactional Email (TEM) service, Container Registry, a second S3 bucket for specific workloads, their observability stack, and even their domain registrar
CDN with distributed storage, DNS, image optimization, WAF, and DDoS protection
AI inference
authentication and identity
Grace à tout ça il peut héberger Kubernetes.
Grace à ça il peut héberger :
- Gitea for source control
- Plausible for privacy-friendly analytics
- Twenty CRM for customer management
- Infisical for secrets management
- Bugsink for error tracking
Malheureusement il n'a ni boutique ni email (hors spamotron). Il prend donc tutanota pour les emails.
# TL;DR
Posté par geegeek . Évalué à 6 (+5/-0).
# "Leaving GitHub [...] you'll miss the ecosystem"
Posté par raphj (site web personnel) . Évalué à 10 (+8/-0). Dernière modification le 21 février 2026 à 12:14.
L'écosystème GitHub est un bug, pas une feature, et de plus en plus. Ils se sont fait ça à eux-même d'ailleurs, en voulant faire d'un outil de développement un réseau social.
Je me demande quand les gens commenceront à s'en rendre compte.
Les mèmes dans les tickets, les rapports de bugs de mauvaise qualité, les contributions de merde pour grossir le CV ou liées à l'Hacktoberfest, les connards avec leurs expérimentations IA…, tout ça, ça se passe sur GitHub. L'absence de frontière à l'entrée attire probablement les interactions lazy qui ne valent pas grand chose.
Entre temps, je ne suis toujours pas sûr qu'être hors de GitHub soit vraiment un frein à recevoir des contributions de qualité. La FOMO est bien réelle par contre.
Par contre, en étant sur GitHub, on continue à dépendre d'une infra et d'un logiciel non libre et d'un hébergement GAFAM pour son projet libre.
Même l'argument « oui mais au moins l'uptime est meilleur que n'importe quel truc auto-hébergé » ne tient pas, il y a sans cesse des pannes. Et puis maintenant, il y a Codeberg de toute façon, si on ne veut pas gérer ça soit-même.
Sans cette centralisation, peut-être qu'on arrêterait enfin de prendre des décisions à coups de nombre d'étoiles, aussi.
[^] # Re: "Leaving GitHub [...] you'll miss the ecosystem"
Posté par cg . Évalué à 5 (+3/-0).
Je suis un peu partagé là-dessus.
En fait, c'est un peu comme les infras cloud : tu peux très bien gérer tes VMs et les services qui tournent dessus, en minimisant le vendor lock-in, et afin de maximiser la réversibilité/facilité de migration vers une autre infra si besoin, mais c'est pas ça qui fait manger les vendeurs d'infonuagique… Ce qui est rentable, c'est les services intégrés comme les k8s managés, les bases de données managées, les intégrations autoscale/DNS/Load balancing, etc…
Et donc pour GitHub c'est pareil, le repo gratuit, c'est un produit d'appel, ça ne rapporte rien. Très vite, tu te retrouves avec des intégrations propriétaires et ça devient difficile de migrer… Alors tu payes. Cf le cas de Curl, Daniel S. a bien expliqué que ce serait hyper coûteux de migrer et devoir payer les pipelines de build.
Y'a plein de personnes ou d'équipes qui savent faire du beau code mais n'ont aucune envie ou connaissances, ou plus simplement de temps pour gérer une infra de build.
[^] # Re: "Leaving GitHub [...] you'll miss the ecosystem"
Posté par raphj (site web personnel) . Évalué à 8 (+6/-0). Dernière modification le 21 février 2026 à 14:44.
Merci pour la mention de Curl, je ne connaissais pas la situation. Le cas de Curl ne me parait pas représentatif, il se trouve que GitHub est un sponsor de Curl. En général, tu paies ta CI, et tu peux décider de payer quelqu'un d'autre.
Plusieurs réponses à ça :
On est d'accord. En plus des services autour, c'est aussi pour habituer aux gens à la plateforme pour que dans le monde professionnel, ils finissent par choisir aussi GitHub pour les besoins de l'entreprise et là, c'est payant (c'est un peu la même stratégie que Microsoft Office qui est donné (pour gratuit ou pas cher) aux étudiant·e·s).
[^] # Re: "Leaving GitHub [...] you'll miss the ecosystem"
Posté par raphj (site web personnel) . Évalué à 6 (+4/-0). Dernière modification le 21 février 2026 à 14:50.
(zut, passé le délai d'édition, je me renfd bien compte qu'une partie de ma réponse tape à côté)
Le manque de compétences ou de temps pour gérer sa propre infra, j'entends 100% par contre.
[^] # Re: "Leaving GitHub [...] you'll miss the ecosystem"
Posté par cg . Évalué à 3 (+1/-0).
Oui c'est un cas un peu extrême, mais il a l'avantage d'être visible. D'une manière générale, concernant les forges logicielles, j'ai l'impression que peu importe celle que tu choisis, il n'y a pas tellement d'interopérabilité. En changer revient à réécrire plein de trucs non liés au but du projet lui-même.
Toutefois, dans le cas du choix de la forge, choisir Gitlab, Codeberg ou Gitea, c'est au moins avoir la possibilité de se monter une instance chez soi et de conserver au moins une partie des intégrations.
Je suis d'accord avec toi, et c'est vrai que c'est peu défendable. Mais c'est explicable : en pratique, on a un temps disponible fini , et on délègue sans cesse plein d'aspects de nos vies (et pas forcément les bons comme tu dis). La curiosité, et faire un truc en dehors de ses compétences/appétences permet souvent d'en apprendre plus sur soi. Mais on ne peut pas tout avoir en priorité 1.
Et quand c'est dans le monde professionnel, c'est exacerbé, on a rarement l'occasion d'aller jouer et apprendre des trucs avec les copines de l'équipe d'à côté.
[^] # Re: "Leaving GitHub [...] you'll miss the ecosystem"
Posté par raphj (site web personnel) . Évalué à 4 (+2/-0).
Absolument.
Bon après le monde professionnel du libre / de l'Open source est déjà en général engagé dans une démarche où on est censé faire un peu plus attention aux choix, et où on ne fait pas nécessairement les choix les plus simples (à commencer par le business model lui-même !). Je pense que souvent, github n'est pas un choix de la facilité, c'est un choix lié à la peur de ne pas être visible. En tout cas historiquement, et en effet après il y a un peu de lock-in.
C'est probablement une bonne idée de limiter au maximum les trucs spécifiques, et par exemple il devrait être un maximum possible de faire tourner ce qui tourne dans la ci en local, ça limite un peu le lock-in.
[^] # Re: "Leaving GitHub [...] you'll miss the ecosystem"
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 8 (+5/-0).
L'éléphant dans la pièce, comme disent les américains, c'est que Github n'est pas libre, alors que les trois alternatives que tu cites (et plein d'autres), si.
Ça me semble important au moins quand il s'agit d'héberger des projets de logiciels libres. La situation peut être différente quand il s'agit d'un hébergement de projets fermés "en interne" pour une entreprise.
Et surtout ce qui est un peu rageant, c'est que avant Github, il y avait Sourceforge, et plein d'autres outils, basés entièrement sur des technologies libres. Et la partie "sociale"/découverte des projets se faisait ailleurs: via freshmeat.net et d'autres annuaires de projets, indépendants des solutions d'hébergement.
Donc on est même pas dans un cas où il n'y avait pas d'alternative libre et les gens se seraient dirigés vers Github faute d'avoir aucune autre option. Faire de l'hébergement de logiciel avec uniquement du logiciel libre, ce n'est pas le futur, ce n'est pas le présent, c'est possible depuis 30 ans.
J'espère que les efforts de Forgejo/Codeberg pour mettre en place une interface lisible et plus légère, ainsi qu'un système de fédération, pourront aider à faire que certains projets quittent Github.
Pour ma part je retourne petit à petit à de l'auto hébergement avec Trac et Gerrit. Ça marche bien malgré les attaques de robots scrappers qui s'acharnent à cliquer sur tous les liens de mon serveur…
[^] # Re: "Leaving GitHub [...] you'll miss the ecosystem"
Posté par cg . Évalué à 4 (+2/-0).
Oui, c'est pour ça que je les ai cité, c'était implicite. Merci de la précision !
Sur l'auto-hébergement, on peut préciser qu'il est aussi possible d'avoir une instance hébergée chez soi de GitHub. C'est proprio quand même, mais c'est possible. La différence réside donc dans libre/open-source/pas libre.
Sinon pour ton Trac et Gerrit, as-tu vraiment besoin de les exposer sur Internet ? (j'imagine que oui mais bon)
[^] # Re: "Leaving GitHub [...] you'll miss the ecosystem"
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6 (+3/-0).
J'ai quelques projets avec des utilisateurs, donc oui, c'est pas mal d'avoir un bugtracker exposé. J'ai par contre mis certaines parties (comme l'exploration en ligne du code source et de son historique) réservées aux utilisateurs identifiés.
Et je met en place des blocages de plage d'IP et de user agent de plus en plus vastes en espérant que ça se calme (même s'il n'y a pas spécialement de problème de surcharge du serveur ou de ma connexion réseau pour l'instant)
[^] # Re: "Leaving GitHub [...] you'll miss the ecosystem"
Posté par bbo . Évalué à 3 (+1/-0).
C'est pas courant courant comme choix !
Comment t'es-tu retrouvé à l'utiliser ? Des éléments à partager sur ce que tu apprécies dans cet outil vs le plus classique Gitlab et ses MR ?
[^] # Re: "Leaving GitHub [...] you'll miss the ecosystem"
Posté par devnewton 🍺 (site web personnel) . Évalué à 3 (+0/-0).
Pourquoi ? C'est si compliqué que ça de compiler curl ?
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: "Leaving GitHub [...] you'll miss the ecosystem"
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6 (+3/-0).
Un coup d'œuil rapide sur leur github permet de voir qu'il y a 214 jobs lancés sur la branche main, pour vérifier la compilation sur toutes les plateformes (OS et arcitectures CPU) supportées, différentes dépendances (par exemple libssh ou libssh2 pour le SFTP, différents résolveurs DNS, …), plusieurs compilateurs différents (gcc, Microsoft, …), des tests de fuzzing, certains builds avec des fonctions expérimentales activées comme le support de HTTP/3, des builds "out-of-tree" et d'autres configurations plus ou moins exotiques.
Donc oui, ça a l'air un petit peu compliqué de vérifier toutes les combinaisons possibles.
[^] # Re: "Leaving GitHub [...] you'll miss the ecosystem"
Posté par cg . Évalué à 3 (+1/-0).
Il y a aussi des éléments de réponse dans le blog de Daniel Stenberg, on en trouve d'autres sur Mastodon, mais autant dire que chercher
githubetcurlça ratisse large :).Peut-être qu'avec une tour blindée de RAM et de CPUs posée dans un grenier ou une cave, ça suffirait.
Comme de loin les choses ont toujours l'air plus facile, je ne voudrais pas être le nouveau I could rewrite curl on a long week-end.
[^] # Re: "Leaving GitHub [...] you'll miss the ecosystem"
Posté par raphj (site web personnel) . Évalué à 3 (+1/-0). Dernière modification le 23 février 2026 à 21:19.
Une tour qui serait probablement une machine Apple, parce que je suppose qu'ils ont de la CI pour macOS, et c'est à ma connaissance la seule manière légale de faire tourner macOS. Cela dit, peut-être qu'Apple devrait sponsoriser voire fournir la CI macOS, après tout ils fournissent curl par défaut avec leur OS si je ne m'abuse.
Whoa, la personne qui pense pouvoir réécrire curl en un weekend de trois jours… J'avais oublié cet article, c'est toujours un peu "marrant".
Rien que documenter chacune des options et leurs interactions prendrait probablement plus que ça xD
# résumé
Posté par Pol' uX (site web personnel) . Évalué à 5 (+3/-0).
Si je comprend bien, pour fonder sa start-up le gus a besoin d'une boutique. Il déploie :
Grace à tout ça il peut héberger Kubernetes.
Grace à ça il peut héberger :
- Gitea for source control
- Plausible for privacy-friendly analytics
- Twenty CRM for customer management
- Infisical for secrets management
- Bugsink for error tracking
Malheureusement il n'a ni boutique ni email (hors spamotron). Il prend donc tutanota pour les emails.
Et il lui reste la boutique à coder.
Adhérer à l'April, ça vous tente ?
[^] # Re: résumé
Posté par BAud (site web personnel) . Évalué à 2 (+0/-0).
facile ! il met des liens vers Amazon /o\ (parce que bon cdiscount ça va pas le faire)
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.