Le danger Github (revu et augmenté)

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.

codercat

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.

github-logo

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

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

L’uniforme évoque l’armée, ici l’armée des clones

2. Validité des points critiques

2.1 Les critiques de la centralisation

2.1.1 Taux de disponibilité du service

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.

githubdown

2.1.2 Blocage de la construction du Logiciel Libre par réaction en chaîne

Aujourd’hui plusieurs outils de gestion des dépendances comme npm dans le monde javascript, Bundler dans le monde Ruby ou même pip pour le monde Python sont capables d’aller chercher le code source d’une application directement depuis Github. Les projets du Logiciel Libre étant de plus en plus intriqués, dépendants les uns des autres, si l’un des composants de la chaîne de construction vient à manquer, c’est toute la chaîne qui s’arrête.

Un excellent exemple de cet état de fait est la récente affaire du npmgate (voir l’article Du danger d’un acteur non-communautaire dans votre chaîne de production du Logiciel Libre). Github peut très bien demain être mis en demeure par une entreprise de retirer du code source de son dépôt, ce qui pourrait entraîner une réaction en chaîne menant à l’impossibilité de construire de nombreux projets du Logiciel Libre, comme cela vient d’arriver à la communauté Node.js à cause de la société Npm, inc. gérant l’infrastructure de l’installeur automatisé npm.

2.2 Un peu de recul historique : SourceForge

Même si l’ampleur du phénomène n’a pas été la même, il est bon de rappeler que Github n’est pas apparu ex-nihilo et avait un prédécesseur ayant joui en son temps d’un engouement important : SourceForge.

Fortement centralisé, reposant également sur de fortes interactions avec la communauté, SourceForge est un SAAS fortement vieillissant  ces dernières années et subit une véritable hémorragie de ses utilisateurs au profit de Github. Ce qui signifie beaucoup d’ennuis pour ceux qui y sont restés. Pour le projet Gimp, il s’agit tout d’abord d’abus publicitaires trompeurs indignes, qui entraînent également le départ du projet VLC , puis l’apparition d’installeurs comprenant des adwares se faisant passer pour l’installeur officiel Windows de Gimp. Et enfin purement et simplement le piratage du compte SourceForge du projet Gimp par… les équipes de SourceForge elle-même.

Nous voyons ici des exemples récents et très concrets des pratiques dont sont capables les sociétés commerciales lorsqu’elles sont sous la pression de leurs actionnaires. D’où la nécessité de bien comprendre l’enjeu représenté par le fait de leur confier une centralisation des données et des échanges ayant de fortes conséquences sur le fonctionnement et les usages de la communauté du Logiciel Libre et opensource.

 

2.3 Les critiques relatives à utiliser un logiciel privateur

2.3.1 Une communauté, différents rapports au logiciel propriétaire

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 opensource, et en particulier d’un critère : contaminant ou non, qu’on résume en général par GPL versus MIT/BSD.

 

bsdvsgpl

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.

gplv3

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 MIT

FreeBSD, principal projet des BSD sous licence BSD

2.3.2 Les pertes de données et obstructions liées à l’usage d’un logiciel privateur

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.

mastering-issues

Issues, le suivi de bug propriétaire de Github

Autre perte si Github disparaît ou devient inaccessible : le travail de revue des “push requests” (abrégées par PRs) en cours. Pour les lecteurs qui ne connaîtraient pas cette fonctionnalité de Github, il s’agit d’adresser de cloner le dépôt Github d’un projet, de modifier ce clone pour l’adapter à vos besoins, puis ensuite de proposer vos modifications au dépôt d’origine. Le propriétaire du dépôt d’origine va alors étudier les modifications qui lui ont été proposées et si elles lui conviennent les fusionner à son propre dépôt. Il s’agit donc d’une fonctionnalité très importante offerte de Github, qui propose de réaliser les différentes opérations graphiquement via son interface.

Toutefois le travail de revue des modifications proposées peut être long et il est courant d’avoir, pour un projet qui marche bien, plusieurs PRs en cours. Et il est également courant d’échanger des commentaires via ces PRs et/ou via le système de suivi de bugs propriétaires de Github dont nous avons parlé plus haut.

Le code en lui-même n’est donc pas perdu si Github devient inaccessible (quoique, voire plus bas un cas spécifique), mais le travail de revue matérialisée par les éventuels demandes et commentaires présents dans les PRs et les suivis de bugs associés l’est bien, lui. Rappelons également que Github permet de cloner des projets via son interface web propriétaire, puis d’y apporter toujours via la même interface des modifications et ensuite de générer des PRs sans télécharger aucunement le code sur son poste. Dans ce cas de figure, si Github devient indisponible, la perte du code et du travail en cours est totale.

Enfin certains utilisateurs se servent de Github entre autre comme d’une application de favoris, afin de suivre l’activité de leurs projets préférés en s’abonnant à ces projets par la fonctionnalité “Watch”.  Ce travail de réunion de données pour la veille technologique est perdu  en cas d’indisponibilité du service Github.

Proposed Debian Logo

Debian, l’un des principaux projets du Logiciel Libre avec autour de 1000 contributeurs officiels

 

2.4 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.

3. 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.

gitlab

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.

cat-sleeping-fireplace

Le “lion” devant la cheminée

Texte sous licence Creative Commons CC BY-ND 3.0 FR

20 thoughts on “Le danger Github (revu et augmenté)

  1. La solution que je pense la plus simple, et que j’ai adopté, consiste à n’utiliser Github que comme une simple remote et à auto-héberger son serv git (comme remote master).

    Ça ne gomme pas toutes les critiques citées, notamment pour le bug tracker, mais si le plus de gens possibles le faisaient, le problème de centralisation serait quasiment réglé.
    Resterait juste à faire en sorte que les dépendances utilisent les deux remotes (ou plus!), au cas où l’une tombe.

    Par contre, pour le coté réseau social du dev et kiki-meter du commit, là je vois aucune alternative décentralisée fiable.

  2. Merci pour l’article, je rajoute des idées:

    Un autre problème de la centralisation : même si l’entreprise est digne de confiance, elle doit respecter les lois en vigueur dans son pays. L’accès aux logiciels peut alors être impossibles dans certaines régions :
    http://framablog.org/2010/01/26/sourceforge-censure/

    Dans ton résonnement, il y a un point qui me parait un peu bancal. Tu parles de fainéantise à propos de développeurs qui ne fabriquent pas leur propre alternative à Github. Je pense que cela n’est pas très juste, car Github est un service, une communauté, ce sont des serveurs, de l’espace de stockage, de la bande passante… Ce n’est pas juste une solution logicielle: les alternatives logicielles existent déjà. C’est un peu comme demander de faire une alternative à Google, ce n’est pas que du code.
    Et en faisant un autre Github en mieux, il restera toujours le problème de la centralisation.

    • Ted : je suis tout à fait d’accord que je pousse un peu en parlant de fainéantise, mais je ne suis pas d’accord pour dire que les alternatives existent. Bien sûr je mets Gitlab en avant dans l’article car c’est une excellente forge logicielle, mais il est certain que nous n’atteindrons pas une vraie alternative à Github sans rendre sociales et interopérables les forges, un peu l’approche adoptée par Diaspora* au niveau des réseaux sociaux grand public. Cela doit-il se concrétiser par un plugin social supporté par les différentes forges ou par une réelle interopérabilité des forges via la normalisation des profils d’utilisateurs de forge ? je n’ai pas la réponse mais je pense que c’est des pistes à creuser.

      • J’arrive un peu après la bataille mais je trouve cet article très juste. Comme tu le souligne, le problème c’est que si tu veux que le code ait un tant soit peu de visibilité et de contributions, c’est github ou rien.
        La solution de rendre les forges interopérables me semble bonne, cependant les gros acteurs (Github quoi) n’ont pas intérêt à jouer le jeu puisque cela faciliterait la migration de projets.
        Enfin, Gitlab offre dans l’ensemble les mêmes fonctionnalités que Github mais présente l’avantage d’avoir une version open source. Deux avantages à cela :
        – si une fonctionnalité manque, nul besoin de pleurer, il suffit de l’ajouter,
        – il serait facilement possible de profiter des avantages collaboratif de la version hébergée tout en ayant une copie intégrale sur une CI sur ses propres serveurs (je ne sais pas dans quelle mesure c’est possible).

        Si de nombreux gros projets open source migraient les uns après les autres sur Gitlab, une partie de la communauté suivrait certainement.

        Pour ma part, j’utilise Gogs sur mon serveur pour les besoins de les projets. Mais il est certain que des que je veux partager quelque chose et/ou créer un module pour NPM je ne peux pas échapper à Github…

  3. Il y a un isolement certain quand on refuse d’utiliser ces outils, c’est notre cas (ni FB, ni Twitter, ni Github, ni Google), et malgré un gros projet qui intéresse du monde (à en juger par les retours sur les salons ou les commentaires sur le net), nous n’avons aucune contribution (enfin pour être honnête on en a eu une dizaine depuis le début du projet… en 2008, et on a eu du soutien financier pour notre campagne de financement participatif l’année dernière — là encore avec un choix d’outil qui nous a paru correct — et surtout on a eu de l’aide à se faire connaître grâce à des acteurs de libre).

    C’est difficile, et on a plusieurs fois réflechi à remettre en question cette politique, mais pour le moment on garde cette ligne.

    Au niveau des alternatives décentralisées, il est très probable qu’on en développe une nous même, car nous avons tout ce qu’il faut ou presque avec XMPP, et que ça nous serait très utile pour le projet lui même, ça fait longtemps que j’y pense (mais par manque de bras, on est obligés de se contentrer sur d’autres choses avant).

  4. Article intéressant, dommage que certains arguments ne soient pas assez poussés.
    Par exemple votre point 1.3 est une critique vide de fond.
    C’est frappant si j’enleve les quelques mots négatifs que vous écrivez: la phrase peut être comprise comme positive.

    Travailler via l’interface Github est 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.

    En espérant que vous prendrez ce commentaire comme une critique constructive,
    Merci de votre article,
    Renaud

    • Toujours intéressé par les retours, merci 🙂

      Le point 1.3 ne fait que présenter une éventuelle critique qui est en suite confirmée et développée au point 2.4.

  5. À propos de l’uniformisation (qui d’ailleurs n’est pas forcément liée à github), je ne trouve pas que ça soit un inconvénient que la majorité des projets utilisent le même gestionnaire de sources (en l’occurrence, git), ça permet de contribuer plus facilement à différents projets.

    Surtout si les alternatives utilisent les mêmes principes mais ne fournissent qu’une interface différente, l’intérêt est minime.

  6. Merci pour l’article.
    je déterre un peu le sujet mais ne serait il possible de faire un gît décentralisé comme mastodonte ou peertube ?
    J’espère que ça viendra.
    J’espère aussi qu’on étendra le principe du versionning à plus de logiciels. Pour travailler collaborativement en entreprise notamment. (et sans passer par un cloud, merci)

  7. Merci pour l’article, qui pointe du doigt un problème que j’avais plus ou moins entrevu, mais de façon bien moins argumentée qu’ici.

    Bon en fait, je ne suis pas sûr d’avoir compris pour les licences, mais ce que je dis plus loin va peut-être dans le même sens, et je voulais ajouter plusieurs remarques :
    – j’utilise github par vice : je ne mets dessus que ce que les gens doivent voir, et je fais très attention à ce qui ne doit pas être vu
    – je mets systématiquement une licence GPL, surtout sur ce qui a de la valeur : trop de boîtes se gavent du code (souvent de très bonne qualité) mis sous licence qui ne protège pas suffisamment les codeurs (et beaucoup les boîtes qui pillent)

    Remarque importante : le choix de la licence est fondamental quand on écrit un logiciel, et la GPL n’est pas terrible, mais protège bien le développeur. Par contre, c’est une vraie plaie quand on veut intégrer du code dans un logiciel sous licence LGPL ou plus permissive, car elle est contaminante, et il y a plein de code qu’on ne peut pas réutiliser à cause de ça (mais le débat est déjà vieux 😉

    Et je tenais à ajouter cette petite expérience : je fais souvent une recherche sur un seul mot clé (imgui le plus souvent) et dans les critères je mets toujours “recently updated”. Et depuis peu, j’ai régulièrement une page qui me dit “Woaw .. mais tu es un vrai spammeur … ! ” Ce que je comprends : les utilisateurs sont tracés (essayez d’ouvrir plusieurs pages, de vous connecter / déconnecter sur votre compte github sur une de ces pages et vous comprendrez), MAIS ils ne peuvent rien savoir sur
    – la vie de leurs sites
    – les derniers ajouts
    – combien de personnes ont consulté un code / téléchargé un binaire etc
    De plus, même après avoir réclamé plusieurs vois aux admins qui doivent finir par me connaître, on ne peut toujours pas télécharger le diff (unifié) d’un commit ou d’une PR !! (c’est vraiment la base, parce qu’un dev, c’est avant tout quelqu’un qui parle le “patch language”)

    (… plein d’autres anomalies aussi)

    … et pour ne pas abuser, je terminerais sur gitlab : l’interface utilisateur est vraiment trop peu conviviale, et je pense que je vais essayer de retourner chez Framasoft (je ne connais pas leur interface)


    ericb

    Pour ceux qui veulent tester : https://github.com/ebachard/miniDart
    => on parle de mon logiciel, mais je mettrai d’abord le code sous licence GPL (quand il sera propre) et ensuite, je verrai.

    P.S. : on ne peut pas prévisualiser ce qu’on a écrit ?

  8. gitlab est mieux que github. Les merge request (equivalent des “pull request”) sont mieux gerer. La CI est integre a gitlab maintenant. J’ai pas encore fait le pas mais je vais passer a gitlab en saas malgres que le projet GNU ne le recommende pas :/

  9. Je sais que l’article date de 2016, mais il existait déjà Gogs ( https://gogs.io/ ), projet qui semble avoir débuté en 2014.

    Ou encore, le projet Gitea ( https://gitea.io/ ) basé sur Gogs, semble avoir débuté en 2016.

    Ce sont d’excellentes alternatives à Github. Peut-être serait-il judicieux de mettre à jour l’article pour mentionner ces projets?

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *