GitHub et les libristes : un danger et un défi !

Temps de lecture 13 min

image_pdfimage_print

Lorsqu’une personnalité notoire du Libre comme Carl Chenet s’attaque avec pertinence à la tendance massive du « tous sur GitHub » et égratigne la communauté du Libre pour son immobilisme (et même sa paresse !), Framasoft trouve que c’est une bonne occasion de lui donner un peu plus de voix encore.

S’adressant principalement aux développeurs, il pointe les dangers d’un service centralisateur, privateur, qui uniformise les pratiques en étouffant les alternatives. Ça ne vous rappelle rien ? Oui, les mêmes écueils contre lesquels nous vous mettons en garde dans notre campagne degooglisons ! Ajoutons que nous avons déjà basculé sur GitLab, comme le recommande Carl, dès 2014 et mis à la disposition de tous depuis le mois de mars 2015 notre GitLab qui héberge à ce jour 3017 projets, 2071 utilisateurs inscrits, 242 groupes.

Nous reprenons ici avec son autorisation le récent billet de Carl qui a déjà suscité d’intéressants commentaires et en provoquera probablement d’autres ici même.

 

Le danger GitHub

Un article de Carl Chenet d’abord publié sur son blog

Carl ChenetAlors 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.

codercatL’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 n’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.

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.

clone_army

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éni 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.

 

githubdown

L’excuse n°1 des programmeurs pour se lâcher sans scrupules : « GitHub est en panne »

— Hé, au boulot les gars ! — Github est en panne !

— Ah bon, continuez alors.

2.2 Les critiques relatives à l’usage d’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.

 

bsdvsgpl

Framanote : MIT/BSD sont des licences permissives, laissant toutes les libertés, même celle de reprendre le code dans un logiciel privateur/propriétaire. Cela correspond à la CC-BY ou à la CC-0 dans les licences Creative Commons.

GPL est une licence copyleft (ou contaminante). Le principe est que tout développement utilisant un code sous licence contaminante doit rester Libre, donc être diffusé sous la même licence. Cela correspond à la mention SA dans les licences Creative Commons.


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 tenants 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
FreeBSD, principal projet des BSD sous licence MIT

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 800 000 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.

 

proposed-debian-logoDebian, 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.

git-logo

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’alternatives et donc du Logiciel Libre ? Tous les membres de la communauté du Logiciel Libre capables de programmer devraient 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.

gitlab

Logo de Gitlab, une alternative possible à GitHub

en choisissant la version Communauté

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.

GitPourTous

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.

cat-sleeping-fireplace
Le « lion » du Libre assoupi devant la cheminée (allégorie)

Liens :

Suivre Framasoft:

Réseau d'éducation populaire au Libre. Nous souhaitons faire le trait d'union entre le monde du Libre (logiciel, culturel, matériel, etc.) et le grand public par le biais d'une galaxie de projets à découvrir sur framasoft.org

19 Responses

  1. Nathael Pajani

    Yop,

    Merci de supprimer les erreurs de cette phrase :

    « S’adressant principalement aux développeurs, il pointe les dangers d’un logiciel (et d’un service) centralisateur, privateur, qui uniformise les pratiques en étouffant les alternatives. »

    Github n’est pas un logiciel, mais uniquement un service.
    Git est libre (GPLv2)
    Git est décentralisé.

    Github est centralisé, mais pas git. Github est (en partie) privateur, mais pas git.

    Merci de ne pas confondre l’outil (git), et le site/service (github)

    +++

  2. HelloWorld

    Je ne saisit pas bien le problème de l’uniformisation, Mercurial et GIT sont quasi-identiques ( commits, releases, tags, etc ) et il est toujours possible d’avoir son propre issue-tracker ( par exemple Redmine ).
    Et un README c’est toujours sympa pour indiquer les infos pertinentes.

  3. Roberto Potato

    @Nathael je pense que tu n’as pas compris la phrase : Github.com est bien un service, qui fonctionne grâce à des logiciels (le backend et le frontend de Github.com). L’article ne parlait pas de Git comme d’un logiciel privateur mais bien du logiciel qui tourne derrière Github.com.

    • Nathael Pajani

      Roberto : oui, c’est un service, et si tu lis la phrase originale (dans mon commentaire) il était question du logiciel :
      … il pointe les dangers d’un logiciel (et d’un service) centralisateur, privateur …

      Nous sommes d’accord, GitHub est un service, qui utilise plein de logiciels.

      Proposer pour le remplacer un logiciel (mercurial par exemple, mais y’en a d’autres) qui fait la même chose que git, et de la même façon (de loin du moins, je n’ai jamais testé mercurial) n’a pas de sens.

      J’utilise git .. mais en auto-hébergé : http://git.techno-innov.fr/

      On dirait franchement que l’auteur (de l’article original) confond git et Github. C’est dommage.

      PS : Pour Framasoft : il reste un double « d’un d’un » suite à la correction 🙁

      +++

    • Mathieu Bridon

      J’ai oublié le plus important : pagure est entièrement libre, et le restera, pas d’open core ou de faux-pen source. 🙂

    • Nathael Pajani

      Mathieu : Hé, voila une _vraie_ alternative 🙂

      Il manque juste le lien pour faire un don …

      (Et un petit bug sur leur Overview du projet : libgit2-0.23.4-1)

  4. Luc Sorel

    ! Désintox !

    L’article laisse croire que « L’excuse n°1 des programmeurs pour se lâcher sans scrupules : GitHub est en panne » est un strip original de Xkcd, donnant ainsi plus de crédibilité à cet article de critiques sur GitHub.

    Pas du tout, c’est un détournement (par un internaute qui s’est ensuite anonymisé : http://karmadecay.com/r/pics/comments/zpqvz/as_github_is_down_i_updated_xkcds_compiling_comic/) du strip original qui parodiait en fait la perte de productivité due au temps de compilation des programmes (cf. https://xkcd.com/303/). C’est donc une blague individuelle, pas du temps un problème général remonté par XKCD.

    @Framablog : attention à la pertinence de vos sources et à ne pas décrédibiliser un débat réel sur l’hégémonie d’un acteur privé dans la chaîne de production du libre par des références maladroites ou qui pourrait mettre votre lectorat en confusion.

    Merci toutefois pour l’article et bonne journée !
    Luc

    • Goofy

      Merci Luc Sorel pour cette intéressante précision. En effet ça change tout.

    • HelloWorld

      Lancer les binaire et hop tout fonctionne du premier coup, pas des tonnes de dépendance, docker, etc..
      Simplement magnifique , même pour des projets en petit groupe 🙂

  5. Ginko

    Y’a un élément en faveur de github que je n’ai pas vu (sauf erreur de ma part) ni dans l’article, ni dans les commentaires (y compris ceux de l’article d’origine) : l’aspect « social » de github.

    Le fait qu’un seul profil rassemble un grosse part de la contribution open source d’un dév. Ne nous le cachons pas : on est fier d’afficher que l’on a participé à X projets, poussé ou mergé Y pull request, contribué à Z issues. Ça caresse l’égo, et pour ceux d’entre nous qui sont développeurs le jour et la nuit, ça nous fait un « book » accessible à n’importe quel recruteur en un clin d’œil. Recruteur qui a plus de chance de saisir l’activité d’un dév sur github qu’en fouillant dans les entrailles des commits de 10 forges différentes (effort qu’il ne ferait sans doute pas).

    Je ne sais pas s’il est possible de constituer un profil « inter-instances » sur gitlab, mais j’imagine que récupérer également cette caractéristique de github aiderait à attirer de nouveaux dévs ou projets.

  6. Xarkam

    Je préfère aussi gogs.io qui permet de juste utiliser un binaire si on a la flemme d’installer via les sources.
    En plus comme c’est en Go, ca permet de se donner une idée des perf de ce langage.

  7. Bruno Adelé

    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.

  8. Bredt

    Comme d’hab je vais joué mes relou :
    Github est une forge, vous voulez une forge 100% libre et auto-hebergable, qui est un tant soit peut crédible,
    et bien elle existe (y’en a plein d’autre d’ailleurs), elle est basée sur les sources de sourceforge (oui le github des années 2000) et ça s’appelle :
    FusionForge
    Et si les mecs de Debian l’utilisent, c’est que c’est pas une daube …
    Aux petits malins qui me disent qu’ils n’arrivent pas a créer un projet sur http://www.fusionforge.org : le site http://www.fusionforge.org n’est pas un service, c’est la forge qui héberge le code de FusionForge.
    Pour info, la V6 s’installe en une ligne de commande !

    • Goofy

      Je te réponds sur la pointe des pieds, compte tenu de mon incompétence. Je suis ravi pour les mecs de Debian qui utilisent fusionforge. Je fais partie des nombreux neuneus qui contribuent (à des bricoles de basse intensité) sur github et sur gitlab. Alors je te dis ma réaction :
      s’il faut installer une forge sur ma machine avec une ligne de commande, tu n’as aucune chance de me voir contribuer à un projet quelconque. Pour moi, Git a abaissé la barrière d’entrée de telle façon que même les neuneus peuvent apporter un petit quelque chose : signaler une issue, ajouter à la doc ou la corriger, la traduire, proposer un petit bugfix… et je ne parle même pas des apprentis codeurs qui profitent de cet outil pour expérimenter sans complexes.

      Maintenant je peux comprendre que les gars de ton calibre aient envie de rester entre eux avec leurs compétences de haut niveau. Je peux le comprendre mais je pense que c’est une impasse, et qu’on risque de voir les projets de Fusionforge subir dans quelque temps le même déclin fatal que de nombreux projets open source sur sourceforge, faute de combattants, c’est-à-dire de contributeurs actifs, occasionnels ou réguliers.

    • xataz

      @Bruno Adelé : Totalement d’accord, je n’ai jamais autant contribué depuis ma découverte de github et git en général. Tout est fait pour en même temps. Il est tellement simple de créer une issue, de la suivre. Ou alors de proposer une feature. A cotés j’utilise également gogs (que je préfère à gitlab personnellement), qui me permet de faire une sauvegarde des mes repos.

      La centralisation est justement un plus pour ce type d’outils, il devient facile de contribuer rapidement à un projet. Si tous les projets avais leurs propres outils de versionning (git ou autre), je pense qu’il y aurais beaucoup moins de contributeur. C’est cette centralisation qui a permis ceci, qui a permis à beaucoup de gens (comme moi), qui ne contribuait pas auparavant.

  9. RyDroid

    L’article est sous quel(s) licence(s) ? J’aimerais pouvoir en publier une version modifiée sur mon site web.