Alors que le projet CPython (implémentation historique du projet Python) a annoncé son passage chez Github (avec quelques restrictions, nous reviendrons là-dessus), il est plus que jamais important de s’interroger sur les risques encourus d’utiliser un logiciel propriétaire dans notre chaîne de création du Logiciel Libre.
Des voix critiques s’élèvent régulièrement contre les risques encourus par l’utilisation de Github par les projets du Logiciel Libre. Et pourtant l’engouement autour de la forge collaborative de la startup Californienne à l’octocat continue de grandir.
L’octocat, mascotte de Github
Ressentis à tort ou à raison comme simples à utiliser, efficaces à l’utilisation quotidienne, proposant des fonctionnalités pertinentes pour le travail collaboratif en entreprise ou dans le cadre d’un projet de Logiciel Libre, s’interconnectant aujourd’hui à de très nombreux services d’intégration continue, les services offerts par Github ont pris une place considérable dans l’ingénierie logicielle ces dernières années.
Quelles sont ces critiques et sont-elles justifiées ? Nous proposons de les exposer dans un premier temps dans la suite de cet article avant de peser le pour ou contre de leur validité.
1. Points critiques
1.1 La centralisation
L’application Github appartient et est gérée par une entité unique, à savoir Github, inc, société américaine. On comprend donc rapidement qu’une seule société commerciale de droit américain gère l’accessibilité à la majorité des codes sources des applications du Logiciel Libre, ce qui représente un problème pour les groupes utilisant un code source qui devient indisponible, pour une raison politique ou technique.
De plus cette centralisation pose un problème supplémentaire : de par sa taille, ayant atteint une masse critique, elle s’auto-alimente. Les personnes n’utilisant pas Github, volontairement ou non, s’isolent de celles qui l’utilisent, repoussées peu à peu dans une minorité silencieuse. Avec l’effet de mode, on est pas “dans le coup” quand on n’utilise pas Github, phénomène que l’on rencontre également et même devenu typique des réseaux sociaux propriétaires (Facebook, Twitter, Instagram).
1.2 Un logiciel privateur
Lorsque vous interagissez avec Github, vous utilisez un logiciel privateur, dont le code source n’est pas accessible et qui ne fonctionne peut-être pas comme vous le pensez. Cela peut apparaître gênant à plusieurs points de vue. Idéologique tout d’abord, mais peut-être et avant tout pratique. Dans le cas de Github on y pousse du code que nous contrôlons hors de leur interface. On y communique également des informations personnelles (profil, interactions avec Github). Et surtout un outil crucial propriétaire fourni par Github qui s’impose aux projets qui décident de passer chez la société américaine : le gestionnaire de suivi de bugs.
Windows, qui reste le logiciel privateur par excellence, même si d’autres l’ont depuis rejoint
1.3 L’uniformisation
Travailler via l’interface Github est considéré par beaucoup comme simple et intuitif. De très nombreuses sociétés utilisent maintenant Github comme dépôt de sources et il est courant qu’un développeur quittant une société retrouve le cadre de travail des outils Github en travaillant pour une autre société. Cette fréquence de l’utilisation de Github dans l’activité de développeur du Libre aujourd’hui participe à l’uniformisation du cadre de travail dudit développeur.
L’uniforme évoque l’armée, ici l’armée des clones
2. Validité des points critiques
2.1 Les critiques de la centralisation
Comme dit précédemment, Github est aujourd’hui la plus grande concentration de code source du Logiciel Libre. Cela fait de lui une cible privilégiée. Des attaques massives par dénis de service ont eu lieu en mars et août 2015. De même, une panne le 15 décembre 2015 a entraîné l’indisponibilité de 5% des dépôts. Idem le 15 novembre. Et il s’agit des incidents récents déclarés par les équipes de Github elles-mêmes. On peut imaginer un taux d’indisponibilité moyen des services bien supérieur.
2.2 Les critiques relatives à utiliser un logiciel privateur
Cette critique, avant tout idéologique, se heurte à la conception même que chacun des membres de la communauté se fait du Logiciel Libre, et en particulier d’un critère : contaminant ou non, qu’on résume en général par GPL versus MIT/BSD.
Les défenseurs du Logiciel Libre contaminant vont être gênés d’utiliser un logiciel propriétaire car ce dernier ne devrait pas exister. Il doit être assimilé, pour citer Star Trek, car il est une boîte noire communicante, qui met en danger la vie privée, détourne nos usages à des fins commerciales, gêne ou contraint la liberté de jouir entièrement de ce qu’on a acquis, etc.
Les pendants d’une totale liberté sont moins complexés dans leur utilisation des logiciels privateurs puisqu’ils acceptent l’existence desdits logiciels privateurs au nom d’une liberté sans restriction. Ils acceptent même que le code qu’ils développent aboutissent dans ces logiciels, ce qui arrive bien plus souvent qu’on ne le croit, voir à ce sujet la liste à couper le souffle des produits commerciaux reposant sur FreeBSD. On peut donc voir dans cette aile de la communauté du Logiciel Libre une totale sérénité à utiliser Github. Et ce qui est cohérent vis-à-vis de l’idéologie soutenue. Si vous êtes déjà allé au Fosdem, un coup d’œil dans l’amphithéâtre Janson permet de se rendre compte de la présence massive de portables Apple tournant sous MacOSX.
FreeBSD, principal projet des BSD sous licence BSD
Mais au-delà de cet aspect idéologique pur et pour recentrer sur l’infrastructure de Github elle-même, l’utilisation du gestionnaire de suivi de bugs de Github pose un problème incontournable. Les rapports de bugs sont la mémoire des projets du Logiciel Libre. Il constitue le point d’entrée des nouveaux contributeurs, des demandes de fonctionnalités, des rapports de bugs et donc la mémoire, l’histoire du projet qui ne peut se limiter au code seul. Il est courant de tomber sur des rapports de bugs lorsque vous copiez/collez votre message d’erreur dans un moteur de recherche. Mémoire précieuse non seulement pour le projet lui-même, mais aussi pour ses utilisateurs actuels et à venir.
Github propose d’extraire les rapports de bugs via son API, certes, mais combien de projets anticiperont une éventuelle défaillance de Github ou un retournement de situation arrêtant brusquement le service ? Très peu à mon avis. Et comment migrer vers un nouveau système de suivi de bugs les données fournies par Github ?
L’exemple de l’utilitaire de gestion de listes de choses à faire (TODO list) Astrid, racheté par Yahoo! il y a quelques années reste un très bon exemple de service ayant grandi rapidement, largement utilisé et qui a fermé du jour au lendemain, proposant pendant quelques semaines seulement d’extraire ses données. Et il s’agissait là d’un simple gestionnaire de tâches à faire. Le même problème chez Github serait dramatiquement plus difficile à gérer pour de très nombreux projets, si on leur laisse la possibilité de le gérer. Certes le code reste disponible et pourra continuer de vivre ailleurs, mais la mémoire du projet sera perdue, alors qu’un projet comme Debian approche aujourd’hui les 800000 rapports de bugs. Une vraie mine d’or d’informations sur les problèmes rencontrés, les demandes de fonctionnalités et le suivi de ces demandes. Les développeurs du projet CPython passant chez Github ont anticipé ce problème et ne vont pas utiliser le système de suivi de bugs de Github.
Debian, l’un des principaux projets du Logiciel Libre avec autour de 1000 contributeurs officiels
2.3 L’uniformisation
La communauté du Logiciel Libre oscille sans cesse entre un besoin de normes afin de réduire le travail nécessaire pour l’interopérabilité et l’attrait de la nouveauté, caractérisée par l’intrinsèque besoin de différence vis-à-vis de l’existant.
Github a popularisé l’utilisation de Git, magnifique outil qui aujourd’hui touche des métiers bien différents des programmeurs auxquels il était initialement lié. Peu à peu, tel un rouleau compresseur, Git a pris une place si centrale que considérer l’usage d’un autre gestionnaire de sources est quasiment impossible aujourd’hui, particulièrement en entreprise, malgré l’existence de belles alternatives qui n’ont malheureusement pas le vent en poupe, comme Mercurial.
Un projet de Logiciel Libre qui naît aujourd’hui, c’est un dépôt Git sur Github avec un README.md pour sommairement le décrire. Les autres voies sont totalement ostracisées. Et quelle est la punition pour celui qui désobéit ? Peu ou pas de contributeurs potentiels. Il semble très difficile de pousser aujourd’hui le contributeur potentiel à se lancer dans l’apprentissage d’un nouveau gestionnaire de sources ET une nouvelle forge pour chaque projet auquel on veut contribuer. Un effort que fournissait pourtant tout un chacun il y a quelques années.
Et c’est bien dommage car Github, en proposant une expérience unique et originale à ses utilisateurs, taille à grands coups de machette dans les champs des possibles. Alors oui, sûrement que Git est aujourd’hui le meilleur des système de gestion de versions. Mais ça n’est pas grâce à cette domination sans partage qu’un autre pourra émerger. Et cela permet à Github d’initier à Git les nouveaux arrivants dans le développement à un ensemble de fonctionnalités très restreint, sans commune mesure avec la puissance de l’outil Git lui-même.
Centralisation, uniformisation, logiciels privateurs et bientôt… fainéantise ?
Le combat contre la centralisation est une part importante de l’idéologie du Logiciel Libre car elle accroît le pouvoir de ceux qui sont chargés de cette centralisation et qui la contrôlent sur ceux qui la subissent. L’aversion à l’uniformisation née du combat contre les grandes firmes du logiciel souhaitant imposer leur vision fermée et commerciale du monde du logiciel a longtemps nourri la recherche réelle d’innovation et le développement d’alternatives brillantes. Comme nous l’avons décrit, une partie de la communauté du Libre s’est construit en opposition aux logiciels privateurs, les considérant comme dangereux. L’autre partie, sans vouloir leur disparition, a quand même choisi un modèle de développement à l’opposé de celui des logiciels privateurs, en tout cas à l’époque car les deux mondes sont devenus de plus en plus poreux au cours des dernières années.
L’effet Github est donc délétère au point de vue des effets qu’il entraîne : la centralisation, l’uniformisation, l’utilisation de logiciels privateurs comme leur système de gestion de version, au minimum. Mais la récente affaire de la lettre “Cher Github…” met en avant un dernier effet, totalement inattendu de mon point de vue : la fainéantise. Pour les personnes passées à côté de cette affaire, il s’agit d’une lettre de réclamations d’un nombre très important de représentants de différents projets du Logiciel Libre qui réclament à l’équipe de Github d’entendre leurs doléances, apparemment ignorées depuis des années, et d’implémenter de nouvelles fonctionnalités demandées.
Mais depuis quand des projets du Logiciel Libre qui se heurtent depuis des années à un mur tentent-ils de faire pleurer le mur et n’implémentent pas la solution qui leur manquent ? Lorsque Torvald a subi l’affaire Bitkeeper et que l’équipe de développement du noyau Linux n’a plus eu l’autorisation d’utiliser leur gestionnaire de versions, Linus a mis au point Git. Doit-on rappeler que l’impossibilité d’utiliser un outil ou le manque de fonctionnalités d’un programme est le moteur principal de la recherche d’alternative et donc du Logiciel Libre ? Tous les membres de la communauté du Logiciel Libre capable de programmer devrait avoir ce réflexe. Vous n’aimez pas ce qu’offre Github ? Optez pour Gitlab. Vous n’aimez pas Gitlab ? Améliorez-le ou recodez-le.
Logo de Gitlab, une alternative possible à Github
Que l’on soit bien d’accord, je ne dis pas que tout programmeur du Libre qui fait face à un mur doit coder une alternative. En restant réaliste, nous avons tous nos priorités et certains de nous aiment dormir la nuit (moi le premier). Mais lorsqu’on voit 1340 signataires de cette lettre à Github et parmi lesquels des représentants de très grands projets du Logiciel Libre, il me paraît évident que les volontés et l’énergie pour coder une alternative existe. Peut-être d’ailleurs apparaîtra-t-elle suite à cette lettre, ce serait le meilleur dénouement possible à cette affaire.
Finalement, l’utilisation de Github suit cette tendance de massification de l’utilisation d’Internet. Comme aujourd’hui les utilisateurs d’Internet sont aspirés dans des réseaux sociaux massivement centralisés comme Facebook et Twitter, le monde des développeurs suit logiquement cette tendance avec Github. Même si une frange importante des développeurs a été sensibilisée aux dangers de ce type d’organisation privée et centralisée, la communauté entière a été absorbée dans un mouvement de centralisation et d’uniformisation. Le service offert est utile, gratuit ou à un coût correct selon les fonctionnalités désirées, confortable à utiliser et fonctionne la plupart du temps. Pourquoi chercherions-nous plus loin ? Peut-être parce que d’autres en profitent et profitent de nous pendant que nous sommes distraits et installés dans notre confort ? La communauté du Logiciel Libre semble pour le moment bien assoupie.
Le “lion” devant la cheminée
Quelques commentaires:
La centralisation n’est pour moi pas un véritable problème. Une coupure de plusieurs heures est génante, mais ce genre de coupure peut arriver n’importe où. Le point critique est que le code source disponible sur github n’est jamais disponible que sur github grâce à git. N’importe quel développeur constatant une indisponibilité peut mettre à disposition le repository complet sur une autre plateforme, et aucun développeur (à part un nouveau) n’est fondamentalement géné par cette indisponibilité puisque chacun travaille en local. De ce point de vue on est loin des centralisations couramment dénoncées (à juste titre) comme gmail par exemple.
La partie logiciel privateur est dans l’ensemble pour le cas présent une bétise à mon avis, et je suis de ceux qui refusent de toucher un windows et ne publient qu’en GPL. On est sur une utilisation de service, mais le fait que leur code soit fermé n’a pas d’importance car c’est sur leur machine qu’il tourne. On ne contrôle jamais le code source des sites web, le modèle du libre n’est juste pas adapté à ça. Si ton blog (qui me procure indéniablement un service utile) fait quelque chose qui ne me plais pas non seulement je n’ai pas vraiment mon mot à dire car c’est sur ta machine qu’il tourne, mais en plus le modèle de prendre le code et le changer n’a pas lieu d’être car je ne peut pas le changer chez toi et suis donc soumis à ton choix de toute manière (et c’est normal, c’est ta machine).
Par contre, la partie sur le tracker de bug est très très juste. Vraiment.
En ce qui concerne l’uniformisation… Tu le dis toi-même, on a toujours un besoin de normes. L’uniformisation a toujours été là dans notre communauté et je n’ai pas l’impression que ça ai empéché tant de belles histoires justement par l’attrait de la nouveauté. Même des vénérables comme emacs, vim ou bash se font aujourd’hui remplacer. J’en déduit que si aucun projet n’a pour l’instant supplanté git c’est qu’aucun n’est assez innovant. Si un nouveau arrivait je pense que github préfèrerait ouvrir une fillière supportant ce format que perdre tout ses utilisateurs donc je ne m’en fait pas trop. Je sous-estime peut-être le risque là, mais j’avoue que pour l’instant je suis près à prendre le risque d’utiliser git ^_^
Un point qu’il faut évoquer par soucis d’équité et que je n’ai pas vu dans l’article c’est tout le bien que github fait au logiciel libre en répondant au principal problème qui n’a à ce jour jamais trouvé meilleur réponse : comment trouver des logiciels libres ?
Sans mentir, s’il est vrai qu’il est dommage de voir certains ne chercher du code que sur github il faut aussi reconnaître que cette recherche ammène souvent des résultats pertinents qui ont poussé de très nombreux projets. Je pense personnellement que le logiciel libre se porte mieux depuis que github est en place.
Est-ce que je préfèrerais que github soit géré par la FSF par exemple plutôt que par une entreprise ? Sans doute, mais on part à la guerre avec l’armée qu’on a, et mercenaires ou non je trouve que cette guerre se profile bien.
Le point de la centralisation est pour moi très important. Au niveau infrastructure c’est relativement simple à mettre par terre, comme le montre les fréquentes indisponibilités du service (citées dans l’article). Ça m’a plusieurs fois gêné dans mes projets. Au niveau infrastructure, on peut également penser à des catastrophes majeurs comme the Big One qui est attendu sur la côte ouest un jour ou l’autre. Une catastrophe locale aux US aurait des répercussions globales. Exemple extrême certes mais qui vise à mettre en avant les risques de la centralisation.
Au niveau politique, autant de miel dans la même ruche, ça facilite les interactions avec l’État. N’oublions pas que de très nombreuses entreprises du monde entier utilisent des dépôts privés. Privés pour le quidam certes mais pas pour les agents du renseignement économique américain par exemple. Puis une seule entreprise finalement pas si connu que ça du grand public, c’est facile à impressionner et à lui faire faire ce qu’on veut.
Et pour répondre à ta conclusion, je ne reproche pas la qualité des services fournis par Github (sauf la disponiblité) qui est globalement reconnu comme bons mais sur les conséquences qui découlent vis-à-vis de l’idéologie du Libre de l’utilisation de Github dans sa forme actuelle.
J’en connais un qui va avoir son article remonté dans les Liens intéressants Journal du hacker semaine #3 lol.
Bravo Carl un super article !
Tcho !
merci 🙂
Pour commenter, on ne peut pas se loguer avec son compte Github ? 🙂
Sinon, pour continuer sur la lancée du commentaire de cym13, en effet, le fait que Github utilise un dVCS change pas mal les choses par rapport aux anciennes forges comme SourceForge,de sinsitre mémoire : on a forcément une copie complète de l’historique du code, et à plusieurs endroits. Une bonne protection contre la capture.
Il reste le problèlme pénible de la gestion des bogues. Il existe des tas de bons gestionnaires en logiciel libre mais tous sont centralisés (ce qui entraine des problèmes pour l’hébergement : je ne fais pas confiance à Github mais l’expérience du logiciel libre montre qu’il ne faut pas non plus faire confiance au développeur qui héberge ça sur sa machine, oublie de payer le nom de domaine, fait une mise à jour de Perl et casse tout, ne donne plus signe de vie, etc). La sécurité à long terme de la liste des bogues et de la connaissance qu’elle contient passe par un système de gestion de bogues réparti, comme le VCS est réparti.
Je suppose que la stratégie la plus raisonnable, pour bâtir un tel système, serait de partir de git. Mais pourquoi cela n’a t-il pas encore été fait ?
Si Github disparaît tu perds toutes les push requets en cours non mergées. Bien sûr elles sont chez chacun des participants, mais faudra attendre de remonter une infra pour les représenter à la personne qui peut les relire avant de les merger. C’est un travers lié à la centralisaiton encore une fois. Sur des gros projets qui cumulent les PRs, ça peut être très pénible.
Pour la partie code lui même, il y a la possibilité de récupérer les pull requests en configurant un remote sur sa machine. Par contre, je n’ai pas trouvé le moyen de le faire avec des commandes git.
En éditant le fichier “.git/config” du dépôt local, il suffit de remplacer :
fetch = +refs/heads/*:refs/remotes/origin/*
par :
fetch = +refs/pull/*:refs/remotes/origin/*
Du point de vue de la gestion de bogues décentralisée il y à Fossil (http://fossil-scm.org)
Développé par l’auteur de Sqlite, et utilisé pour gérer les sources de ce dernier
Excellent ce post ! J’en profite pour poser la question : comment se fait-il que les initiatives ayant du succès passent quasi systématiquement par la case “privateur” avant que le libre ne prenne le relais et pas l’inverse !? Que signifie “privateur” si ce n’est l’atout économique qu’il procure en premier lieu dans ce monde économique là !? Quel est alors le code de ce monde économique ? Si le code du domaine économique est lui-même par essence privateur et pas libre, n’est pas alors là la cause première qui explique la cause seconde ?
Tu as de très nombreuses innovations directement nées du Logiciel Libre sans précédent privateurs. Pour la définition de privateur http://www.gnu.org/proprietary/proprietary.fr.html
“très nombreuses” n’invalide en rien le propos. Ainsi à l’époque de Galilée “très nombreux” étaient les astronomes ayant compris l’héliocentrisme. Le nombre n’est un gage de rien. Le nombre relatif un peu plus.
A parler entre-soi, entre ceux qui partagent un même espace de libertés, on peut avoir le sentiment que “les choses” se font indépendamment de “ceux qui parlent” et “ceux qui ne parlent pas”, sans voir que “ceux qui ne parlent pas sont les 99%.
Donc sans libérer les 99%, que croit-on avoir compris de quoi que ce soit ?
« Il semble très difficile de pousser aujourd’hui le contributeur potentiel à se lancer dans l’apprentissage d’un nouveau gestionnaire de sources ET une nouvelle forge pour chaque projet auquel on veut contribuer. Un effort que fournissait pourtant tout un chacun il y a quelques années. »
Le nombre de projet a explosé avec le temps (il n’y a qu’à voir le nombre de dépendances dans un projet javascript pour s’en convaincre), quand une personne trouve un problème ou veut soumettre une amélioration il veut aller à l’essentiel (pas créer un n-ième compte, apprendre à utiliser une nouvelle interface, prendre en main un nouveau gestionnaire de version etc.).
La force de github a été de proposer le premier un moyen extrêmement pratique de résoudre ce problème basique (je veux améliorer un truc -> je fork, je modifie, je fais une pull-request).
Si demain Github se trouve remplacé par une dizaine de petit outils indépendants, la bare d’entrée à la contribution des projet sera donc augmentée d’autant et la qualité globale des outils que nous utilisons diminuera.
En outre concernant le problème de la mort de Github, il faut d’abort relativiser car GitLab propose un outil pour migrer un projet depuis Github, tickets et wiki inclus (http://doc.gitlab.com/ce/workflow/importing/import_projects_from_github.html)
Donc de mon point de vue tout va bien, on peut retourner faire des PR sur Github avec le sourire
Si quelque chose améliore la qualité du code, ce n’est sûrement pas le coût d’entrée à telle ou telle forge mais plutôt la qualité réclamée par le mainteneur du projet et l’interface avec des outils d’intégration continue, et c’est sûr que Github de ce point de vue est très pratique.
Ça fait 10 ans que je suis dans le Libre et nous n’avons pas attendu Github pour construire des projets d’ingénierie ambitieux avec de nombreux contributeurs et des échanges de code constant. Debian est sûrement l’un des plus grands projets logiciel avec 1000 contributeurs réguliers. Le noyau Linux n’utilise pas Github, etc.
Que Github ait amélioré l’accès et la contribution aux différents projets, sûrement. De là à en déduire une conséquence sur la qualité globale, il y a un sacré fossé. Et j’aurais plutôt tendance à penser l’inverse de toi.
Oui quand un projet possède des centaines de contributeurs réguliers comme Debian ou Linux la problématique n’est pas la même.
Mais 99% (source: Pifomètre inc.) des projets sont des petits trucs maintenus par moins de 10 personnes (généralement un seul mainteneur régulier en fait). Dans ces conditions faire passer le contributeur potentiel sous des fourches caudines est généralement synonyme de se passer de leurs contributions.
Je ne m’oppose pas à cet argument, c’est même à mon avis la principale réussite de Github. Maintenant cela ne fait en rien la qualité du projet ni la qualité des contributions. Au contraire parfois, on fork de son côté le projet, on modifie pour adapter à ses besoin, on envoie un pull request toute pourrie à l’upstream et on se sent tranquille. PR qui ne sera jamais relue car inutilisable. Donc abaisser et faciliter la barre d’entrée pour les contributeurs, sans aucun doute, mais améliorer la qualité des contributions, je ne vois pas le lien.
> Le nombre de projet a explosé avec le temps (il n’y a qu’à voir le nombre de dépendances dans un projet javascript pour s’en convaincre)
C’est que la plupart des langages ne savent pas monter un vrai CPAN. Un CPAN est une architecture centralisé réparti qui enregistre l’intégralité des sources des modules (ici Perl).
Le CPAN permet a des espaces de nom de s’étendre, on voit ainsi des arbres grandir, d’autres en perte de vitesse… mais tout le monde travaille sur le même arbre. Avec github, on a N truc en parallèle, la structuration est assez faible…
CPAN ne contient que des modules packagés, le développement de ceux-ci se fait toujours sur une forge (Github ou autre). Donc pourquoi opposer CPAN et Github ?
Au passage, l’adresse de courrier annoncée pour le domaine carlchenet.com (carl.chenet@ohmtux.com, titulaire et contact technique et admin) ne marche plus : ohmtux.com n’existe pas.
Le domaine est donc désormais ce que nous appelons un “domaine flamant” : n’importe qui qui enregistre ohmtux.com peut piquer carlchenet.com.
hmmm intéressant, merci de soulever ce point je vais regarder ça.
c’est corrigé, merci d’avoir levé le point.
Il manque le tag “c’était mieux avant…”
De mon point de vue, GitHub, n’est pas un danger mais une chance pour le logiciel libre.
En quelques mots:
1 – sur la centralisation : git est décentralisé => changer de remote
2 – sur le logiciel privateur : c’est du saas. Git est libre. Si cela gène, ne pas utiliser github pour la gestion des bugs ou le wiki, bien que cela soit pratique pour les futurs contributeurs d’avoir toutes les informations sous la main.
Ou utiliser GitLab, mais rien n’assure que nos informations personnelles ne soient pas communiqués aussi à des tiers également.
3 – sur l’uniformisation : l’uniformisation ne devrait pas être une critique négative, mais plutôt positive…
Sur les forges : “Un effort que fournissait pourtant tout un chacun il y a quelques années.”
Ce point est faux. Beaucoup de personnes abandonnaient.
Github a supprimé les intermédiaires et rapproché les utilisateurs des logiciels.
Il est bien plus facile de contribuer à un projet sur github en tant qu’utilisateur lambda qu’avant.
Si l’on compare à Debian, sur la page https://www.debian.org/intro/help, il n’y a pas de “comment faire pour envoyer un patch”, mais un coin des développeurs avec une liste de contrôles en 7 étapes (https://www.debian.org/devel/join/newmaint).
Décourageant… C’est dommage, c’était un patch de rien du tout à envoyer… une petite push request aurait fait l’affaire.
L’article est incomplet, il ne met pas en avant les bienfaits de github sur les logiciels libres, toutes les nouvelles contributions qui ont été apportées via GitHub. Une comparaison avant-après aurait été bienvenue.
L’article ne propose pas non plus d’alternatives concrètes concernant la manière de développer des logiciels libre en 2016, car c’est bien de ça qu’il s’agit et qu’apporte GitHub.
1. on ne parle pas de git mais de github. Si Github ferme tu perds tes bugs et tes PRs en cours.
2. oui c’est ce que je dis dans l’article avec l’exemple de Python.
3. l’innovation est liée à la diversité et à la recherche de différence par rapport à l’existant.
4. en effet, mais ça a son coût, comme dit dans l’article.
5. sur Debian : idem que 4.
L’article ne vise pas à faire les louanges de Github, le titre et l’introduction l’annoncent clairement. Des milliers de blogueurs l’ont déjà fait. Je propose une alternative : Gitlab. Et si ça ne convient pas, je rappelle que d’habitude les développeurs du Libre codent les programmes dont ils ont besoin. Et apparemment 1340 signataires de la lettre “Dear Github” expriment ce besoin…
Je me doute bien que ta notoriété et celle de ton blog peuvent te dispenser d’aller chercher une audience plus large, cependant chez Framasoft nous aimerions bien donner un écho à ce billet, soit en le republiant tel quel, soit en te proposant à ton gré un article dans le Framablog qui pourrait être plus condensé (un peu moins orienté développeurs, un peu plus grands publics-apprentis codeurs) ou au contraire allongé de réponses à quelques commentaires et observations etc. Bref, tu as carte blanche 🙂 – Me contacter.
Moi un des points qui me fatigue avec github, c’est l’uniformisation qu’il impose dans l’utilisation de git (fork, issue, PR, merge, etc.). Un des effets de bord est que, globalement, je trouve les “git log” issus des projets github plutôt dégueulasses. Or ces logs sont vraiment une source très importante pour juger de la qualité d’un code.
Et donc, pour ma part, je trouve que beaucoup gagneraient à mieux connaître les commandes git plutôt que savoir où cliquer dans github. Et découvrir que github c’est vraiment pour ceux qui n’ont pas vu la lumière.
(fin du message de vieux con grincheux)
Dans ton article tu cites la cas de BitKeeper et Linux (histoire que je ne connaissais pas). C’est très intéressant, et on voit le souci quand une organisation commerciale gère une forge.
Ne peut-on pas aussi faire un parallèle entre Github et Sourceforge? Sourceforge a été la forge principale avant Github, et ils ont profité de leur suprématie pour faire des choses par très correctes:
– Publicités malveillantes
– Ajout de logiciels publicitaires dans les logiciels hébergés (sans accord des auteurs)
– Verrouillage des dépôts
Le cas qui a du faire le plus de bruit, c’est quand ils ont touché au dépôt de GIMP.
https://linuxfr.org/users/jehan/journaux/sourceforge-de-pire-en-pire-usurpation-d-identite-du-projet-gimp
Git n’a pas encore fait de telles choses, mais le fait qu’ils soient “cool” ne suffit pas pour leur faire entièrement confiance. Quand ils seront rachetés, que se passera-t-il?
Merci, c’est un très bon point.
Personne ne semble faire de reproche à git lui-même ici… Pour jouer les troubles fête :
– je suis 100% d’accord, l’uniformisation bloque l’innovation : github de toute évidence est le premier “coupable” (mais en tant que libriste, j’ai appris à ne rien attendre d’une grosse entreprise, qui rêve d’avoir le monde entier comme client), mais quid de la communauté du libre, qui laisse paresseusement github faire de git le DVCS monopolistique, là où des alternatives innovantes existent, par exemple mercurial et l’extension evolve ? Rappelons en passant les énormes bienfaits du système d’extension de firefox qui a généré quantité d’innovations, comme firebug, ancêtre des “devtools” désormais intégrés à tous les navigateurs dignes de ce nom : mercurial a suivi ce chemin, gageons que son avenir sera plus ouvert que celui de git grâce à celà.
– l’interface de git est si complexe que 90% des développeurs ne connaissent que 10% de celle-ci… La difficulté d’apprentissage de son modèle et de ses commandes un peu avancées est énorme. Comme il est de bon ton de faire du git comme tout le monde, l’avouer est une faiblesse impardonnable pour avoir un tant soit peu de crédibilité dans une communauté du libre, que github a contribué à rendre plus compétitive (avec sa galaxie de comptes auto célébrant leur auteur comme autant de selfies ridicules, recherchant les meilleures statistiques de contribution publique sans permettre d’en juger l’intérêt), moins fraternelle et concentrée sur la lutte contre le logiciel propriétaire.
Bref, je trouve cet article très encourageant mais un peu frustrant car il semble s’arrêter au milieu du guet…
Je ne comprends pas ce commentaire, car la première remarque est indépendante de Git, et la seconde va à l’encontre du billet, en prônant la fainéantise. Que l’interface de Git soit complexe pour les commandes avancées indique juste que la maîtrise de Git est difiicile, surtout si l’on veut tout apprendre d’un coup, ce qui n’a pas de sens selon moi. Un peu comme pour Emacs. La maîtrise d’un puissant outil comme Git est certes difficile, mais l’utilisation basique est très simple.
Et il est déraisonnable de catégoriser tous les utilisateurs de Git comme y ayant été par effet de mode. Ce n’est pas le comportement que je vois autour de moi, et ça n’a surement pas été mon cas, alors que je connais Git depuis que LT l’a inventé puisque j’avais suivi l’affaire. Pourtant, je ne l’ai adopté qu’en 2010.
Peut-être peut-on dire cela des utilisateurs de GitHub, mais les projets que je suis ont plutôt migré vers celui-ci, et ont longtemps été réticents.
La disparition de GitHub n’aura aucun impact majeur sur ces projets, si ce n’est un changement d’hébergeur pour le code qui demandera une réorganisation. Cela n’aura pas le moindre impact sur le code.
De même, je voyais des comparaisons entre GitHub et Sourceforge, ce qui n’a aucun sens, Sourceforge n’hébergeait pas des dépôts Git, or Git possède intrinsèquement des mécanismes de contrôle de modification de code et de leur provenance, c’est fait pour. C’est un plus par rapport à Sourceforge.et il est très facilement possible de vérifier qu’un tarball possède exactement le même code que le dépôt Git.
Un excellent article qui pointe les risques de la centralisation, et j’ai apprécié tout autant de lire l’ensemble des commentaires qui sont de qualité et complètent bien l’article. Comment beaucoup, je me disais que cette centralisation n’est pas gênante puisque je peux déplacer mon code quand je veux ; ne collaborant pas à de gros projets le risque lié à la centralisation de l’outil de suivi de bugs m’avait échappé.
En regardant de plus près mon utilisation personnelle de GitHub, je constate que j’ai une bonne centaine de bookmarks sur des petits projets (outils ou librairies) que j’utilise. Pour certains, GitHub est devenu la “homepage officielle” avec son README et ses pages Wiki. Donc si GitHub disparaissait (ou changeait ses conditions d’utilisation, pourquoi pas), c’est une bonne partie de mes bookmarks qui serait perdu. C’est pas anodin.
En plus de partager l’avis de Hokata, je rajouterai deux choses.
La première est que la description des auteurs de Logiciel Libre est selon moi complètement fausse ici. Pour moi, le Logiciel Libre, c’est celui qui est sous GPL ou un dérivé (LGPL ou autre). Mais certainement pas un logiciel sous une licence compatible GPL comme FreeBSD, qui peut être rendu privé sans aucun souci et qui explique la liste fournie de plates-formes propriétaires l’utilisant. Du coup, tout le passage sur les auteurs du LL n’a plus de sens, puisqu’en fait il fait référence à d’autres personnes, et inclus des projets dans GitHub, qui bien que compatibles avec le Logiciel Libre, n’en sont pas vraiment.
La seconde est que selon moi, dire que la mémoire du Logiciel Libre est dans les rapports de bug est faux. C’était peut-être vrai avant Git, mais désormais avec Git c’est faux. La mémoire des logiciels libres, que j’associe à la GPL, a toujours été dans le code source, comme initié par le GNU, c’est-à-dire dans le ChangeLog.
Et Git permet d’inclure ce ChangeLog dans son historique, et rien n’empêche de mettre des liens vers des rapports de bugs ou des liens de listes de distribution ou autre.
Sinon, cela reviendrait à dire qu’il n’y a aucune mémoire pour Linux, alors qu’un des points importants qui a eu lieu lors du transfert de BitKeeper vers Git, a été le transfert de la mémoire du noyau vers Git, dans chaque commit.
Ça m’étonne que personne ne parle de FusionForge (ou redmine, mais je ne connais pas vraiment).
FF, y’a tout ce qu’on veux, on peut faire du git, du mercurial ou autre, et avec la v6 l’installation est d’une simplicité déconcertante.
bof,
même si je comprend le sens je trouve que c’est plutôt a charge et ne tient absolument pas compte des bienfaits apportes par github. Dans le cadre du projet FusionDirectory on a adopte la démarche suivante tous les services sont gérés en interne dans notre infra avec le miroir de nos repos git hébergés sur github et historiquement aussi sur gitorious (mais tellement bancal qu’on avait arrêté.)
Le nombre de patches intéressants et bug report reçus sur github avoisine les 80% donc ca montre la pertinence et la facilite d’utilisation.
Le jour ou une alternative libre et aussi facile voit le jour on y hébergera sans doute aussi des mirroir de nos dépôts git mais sans quitter github. Pour moi accessibilité et la facilite d’utilisation du code envers un majorité d’utilisateur et non pas un club ferme sera toujours supérieure.
Justement Github était down il y a 20 heures : https://news.ycombinator.com/item?id=10984775
Etrange coïncidence !
On a beau dire, c’est vrai que github est en partie propriétaire (ils utilisent malgré tout des logiciels libres), mais me concernant, je n’ai jamais autant contribué que depuis qu’il y’a github.
Dans les années 2000, mes rares projets étaient hébergés sur sourceforge & savannah, peu de personnes ont contribuées à mes projets et j’ai également peu contribué aux autres projets. Etant maintenant sur github, beaucoup plus de personnes contribuent à mes projets et je contribue plus facilement aux autres projets. Ceci grâce à la puissance du Fork et du pull request.
A un moment je pense qu’il faut arrêter de crier au loup tout en voulant systématiquement recopier les excellentes idées des projets qui ont réussis. je pense qu’il ne faut pas oublier que github a peut être permis de faire naître de nouveaux projets.
Commentaire également déposé sur http://framablog.org/2016/01/28/github-et-les-libristes-un-danger-et-un-defi/
C’est une face du sujet, mais il y en a d’autres. Par exemple, les contributions significatives de GitHub à git:
http://githubengineering.com/counting-objects/
Et histoire de continuer dans l’autre façon de voir les choses, selon Larry Wall la “fainéantise” est l’une des plus grandes qualités d’un programmeur. Et moi j’assume totalement ma flemme d’administrer mon propre serveur git: quel grand programmeur je dois être! hi hi hi^^
Personnellement ça ne m’inquiète pas plus que ça. Il y a quelques années, tout l’open source était sur SourceForge et on avait d’ailleurs droit aux même critiques. Et puis ils ont accumulés les boulettes, et en moins de temps qu’il n’en faut à peu près tout le monde s’est barré. Bye bye SF!
Merci pour ce post. On est en train de construire une alternative à la fois à git et à github là : http://pijul.org. C’est basé sur une théorie solide des patchs, qui permet d’éviter complètement la centralisation, tout en gardant l’aspect réseau social qui fait le succès de github.
Pierre-Étienne : je vois en quoi pijul est une alternative à git mais pas en quoi il remplace Github. Il a un système de gestion de bogues ? Un moyende faire des PR ? Une interface Web ? Des mécanismes pour l’éhebergement (création de comptes, par exemple) ?
Pas encore ! Notre idee, c’est que l’un des problemes que resout github vient de git : comme git (et mercurial, svn, cvs, fossil, rcs, dropbox, rsync …) est base sur des snapshots, fusionner des branches impose a l’algorithme (diff3) de “voir” les deux cotes de la fusion.
C’est pour ca que si je n’ai pas de depot chez moi, et que je n’ai pas le droit de pousser un commit chez n’importe quel projet, je ne peux pas contribuer. Techniquement, l’un des gros interets de github est de supprimer cette contrainte.
Dans Pijul, pas de snapshots, il n’y a que des patchs ! Comme dans darcs (http://darcs.net), sauf que nos algos sont bases sur une theorie des patchs qui n’a pas encore ete publiee, dont la performance defie git, surtout sur les grosses instances (histoire longue, plein de fichiers, plein de branches).
Du coup, meme si je n’ai pas de depot, je peux envoyer un patch par mail. Ou par n’importe quel autre moyen, tant que le fichier arrive, le depot distant saura quoi en faire.
(il y a une commande dans git qui permet d’envoyer un commit par mail, mais elle marche remarquablement mal si le fichier a ete edite entre temps, et est carrement dans les choux s’il y a des conflits).
Et oui, on a un systeme de rapport de bugs en preparation, completement distribue, et qui n’emprisonne personne. Il faut encore valider le passage a l’echelle de ce systeme.
Je ne vois absolument pas le rapport entre “logiciel propriétaire” et l’offre de services web comme Github.
Le même article aurait pu être écrit en remplaçant “Github” par “Gitlab”. Pour un utilisateur du service, le questionnement se situe au niveau des données, pas du logiciel derrière le service.
Github ne permet pas de tout exporter, en effet (PR, discussions, je crois). Gitlab le permet-il ? J’en doute.
Je trouve bien dommage que les points critiques abordés ne soient en fait que des compromis: la centralisation et l’uniformisation sont aussi des atouts clés de Github, et la seule alternative est l’auto-hébergement, donc la multiplication des tiers. Le coté “logiciel propriétaire” est à mon avis tout simplement hors-sujet.
Si demain Github disparaît, quelle serait la suite probable? Tout le monde se tournerait vers Gitlab.com, qui deviendrait le Github nouveau. Logiciel libre ou pas.