GitLab, une des alternatives à GitHub, a fait un superbe cadeau de Noël à sa communauté : l’intégration des GitLab Pages à la version communautaire de GitLab !
Le ticket où a eu lieu la discussion amenant à cette décision a été ouvert il y a neuf mois et, alors que la discussion s’était éteinte il y a près de deux mois sur un refus (argumenté et compréhensible) de la part de GitLab, celle‐ci a repris il y a deux semaines pour aboutir à un dénouement inattendu : l’intégration des GitLab Pages à la version communautaire.
Qu’est‐ce que GitLab Pages ?
À l’instar des pages Github, les pages GitLab permettent à toute personne possédant un dépôt sur un GitLab de créer un site Web via un générateur de site statique (Jekyll, Middleman, Hexo, Hugo, Pelican…) et de l’héberger sur l’infrastructure dudit GitLab.
La compilation du site est effectuée lors du push vers le dépôt GitLab, via le système d’intégration continue de GitLab, puis le résultat est publié à l’endroit idoine pour être accessible via le Web.
Il est possible d’utiliser un nom de domaine personnel (il n’est pas obligatoire d’utiliser une adresse du style https://username.gitlab.io), ainsi qu’un certificat personnel.
Et ça sert ?
Les pages GitHub sont très souvent utilisées par les développeurs pour fournir une page de présentation de leurs projets, même les plus gros : Ruby on Rails, Django, React…
Les pages GitLab sont donc susceptibles d’être tout autant utilisées que les pages GitHub. La demande est là.
Et avec le danger que représente GitHub, il est plaisant de voir qu’une de ses alternatives libres s’étoffe et propose une de ses fonctionnalités des plus appréciées. Tellement appréciées que certains utilisent les pages GitHub comme hébergement pour leur blog !
La discussion
Le ticket où a eu lieu la discussion a été ouvert suite à l’interpellation sur Twitter de GitLab par… votre serviteur.
En effet, Framasoft proposant une instance de GitLab libre d’utilisation, nous recevions beaucoup de demandes pour fournir un service équivalent à GitLab Pages. D’où ma demande via Twitter.
L'argumentaire de GitLab était le suivant : une fonctionnalité de GitLab qui ne serait pas utile à des installations de moins de 100 utilisateurs n’a pas vocation à être intégrée à la version communautaire de GitLab [lien].
À noter : GitLab a proposé à Framasoft de lui fournir une licence pour l’édition Entreprise de GitLab avec un rabais… Proposition refusée, puisque Framasoft ne veut utiliser que du logiciel libre. :-)
La communauté a réagi en indiquant bien que les GitLab Pages seraient utiles, même aux installations de moins de 100 développeurs.
Au bout de trois mois, votre serviteur a codé un pis‐aller de GitLab Pages : Fs Pages, afin de fournir https://frama.io/. La compilation est laissée à la charge du développeur et il n’est pas possible de choisir un nom de domaine personnalisé.
Après quelques appuis supplémentaires de la part de la communauté en faveur de l’intégration, le ticket fut fermé avec l’argument du business : GitLab avait peur, ce qui est compréhensible, de diminuer l’attrait de l’édition Entreprise puisqu’une des killer features serait déjà dans l’édition communautaire.
Il fut rappelé que l’instance officielle, disponible sur http://gitlab.com, libre d’utilisation de façon illimitée, permettant (au contraire de GitHub) d’avoir des dépôts privés, utilise l’édition Entreprise et propose de ce fait les GitLab Pages. À quoi il fut répondu que cela n’avait guère plus de sens que d’utiliser GitHub, puisqu’il s’agissait alors d’utiliser une solution propriétaire.
La discussion semblait finie… jusqu’à une nouvelle note, il y a deux semaines.
L’argument utilisé me semblait des plus fragiles : avec les GitLab Pages dans l’édition communautaire, plus de développeurs utiliseraient GitLab pour héberger leur blog, ce qui aurait pour effet de faire grandir la notoriété de GitLab par le bouche à oreille, donc d’avoir plus de personnes familières avec la plate‐forme et donc d’avoir potentiellement plus de prescripteurs qui pourraient faire pencher la balance en faveur de GitLab lors du choix d’une forge en entreprise.
L’argument de la notoriété. Le genre d’argument que l’on sort, par exemple, pour ne pas payer un graphiste : « Ça vous fera de la pub ».
Les gens de GitLab, devant la reprise des discussions, annonçèrent qu’ils allaient y repenser…
Il fut proposé un financement participatif pour offrir une compensation à GitLab en échange de la libération des GitLab Pages.
Une autre organisation sans but lucratif comme Framasoft, bien que plus petite (ce sont leur termes), vint appuyer la demande de libération, ainsi que l’idée d’un financement participatif.
Et enfin… la demande de fusion de la libération apparut.
Au final
Au‐delà de l’excellente nouvelle de l’arrivée des GitLab Pages dans la version 8.16 qui arrivera le 22 janvier 2017, nous avons là un bel exemple de dialogue avec la communauté.
Les échanges furent cordiaux, argumentés, et le « non » initial fut accueilli sans animosité par la communauté.
La communauté, de son côté, fut opiniâtre et cela a payé. Notons que la communauté n’attendait pas que cela lui tombe tout cuit dans la bouche, entre solutions alternatives codées à la main ou bidouillées à coup de rsync et proposition de financement participatif.
Bref, un bel exemple de gestion de communauté à suivre, d’un côté comme de l’autre.
Aller plus loin
- GitLab (248 clics)
- L’annonce de la libération (201 clics)
- Le ticket à l’origine de la libération (143 clics)
- GitLab Pages (326 clics)
# C'est Noël :)
Posté par lapineige (site web personnel) . Évalué à 10.
Excellente nouvelle, qui mérite en effet que l'on l’ébruite pour faire honneur à cette décision :-)
Framasoft va avoir encore plus de succès, avec des pages web statiques facilement mises en ligne, ça va permettre à beaucoup de monde de très facilement ouvrir un site sans passer par une plateforme propriétaire, en contrôlant leur données.
Merci à ceux qui ont fait la demande et qui ont été convaincants, et à l'éditeur pour son ouverture.
# GitLabs en force
Posté par dstauret . Évalué à 1.
Personnellement en cherchant une forge pour mes logiciels, j'ai tenté d'utiliser GitHub.
J'avoue que non seulement je ne trouve pas l'interface très "fameuse", mais en plus je n'ai pas trop bien compris la philosophie.J'ai vite compris que tout était à vendre.
Je me suis donc tourner vers GitLab pour tester et ça m'a tout de suite plu.
Plus simple, plus libre. CQFD.
[^] # Re: GitLabs en force
Posté par CrEv (site web personnel) . Évalué à 7.
C'est réellement une histoire de libre ou plutôt de gratuit/payant ?
[^] # Re: GitLabs en force
Posté par dstauret . Évalué à 1.
Il y a des deux.
Payer ne pose pas forcément problème.
Mais quand on paye un service il faut qu'il réponde à un besoin.
GitHub me disait par exemple que les sources de mon projet devaient être publiques…
Ce n'est donc plus moi qui décide ?
A moins de payer. Mais comme je disait, j'ai bloqué sur l'interface.
Pour le moment sur GitLab, je travaille mon projet avec qui je veux et comme je veux. C'est aussi ça la liberté.
Après s'il fallait payer une somme raisonnable, pourquoi pas.
[^] # Re: GitLabs en force
Posté par Jehan (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 03 janvier 2017 à 04:08.
Moi ça me choque pas. Le business model de Github est assez clair: soit tu payes et tu es le client; soit tu payes pas, et tu es le produit (pour eux, tu es juste alors un "chiffre" marketing qui montre à leurs clients à quel point Github est devenu central et "indispensable"; ils doivent donc le prouver et pour ça, seuls les "produits" publiques sont acceptés).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: GitLabs en force
Posté par CrEv (site web personnel) . Évalué à 2.
Je vois toujours pas le truc. Github fourni des accès gratuits et payant avec des fonctionnalités différentes. Ok. Mais je vois pas bien en quoi c'est surprenant, à moins d'être dans un monde tout gratuit mais je sais pas comment on paye ne serait-ce que l'infra derrière.
Ok, ça me surprend parce que personnellement je trouve l'interface de gitlab tellement brouillonne que je n'arrive jamais à l'utiliser.
Parce que c'est fourni gratuitement et que d'autres payent pour toi, non ? (ben oui ceux qui payent sur ces plateformes payent en réalité pour les comptes gratuits)
Tu parles de gitlab ou github ? Parce que les tarifs de github me semblent tout de même raisonnable.
[^] # Re: GitLabs en force
Posté par dstauret . Évalué à 1.
7$ par mois pour un compte personnel/étudiant, je ne trouve pas cela raisonnable. C'est quand même 84$ l'année.
Pour du personnel c'est trop AMHA.
Je te rassure, je ne suis pas fauché ; je paye des choses bien plus chères. Et comme je t'ai dit, il faut que ça réponde à un besoin.
Pour la petite histoire, je me suis d'abord dirigé vers GitHub avant de chercher une alternative (je ne connaissais pas encore GitLab).
Pour en finir, je n'utilise pas GitLab tant que ça pour le moment. Mon projet est travaillé en local et synchronisé ensuite.
Je suis encore en mode découverte et à ce jour ce fonctionnement me convient mieux que GitHub.
Le jour où j'aurai besoin de plus de fonctionnalités (payantes), je regarderai ce que propose d'abord GitLab (puis GitHub pourquoi pas).
[^] # Re: GitLabs en force
Posté par lapineige (site web personnel) . Évalué à 1.
Oui très clairement l'interface est brouillonne, incompréhensible.
[^] # Re: GitLabs en force
Posté par DerekSagan . Évalué à 1.
L'interface de github n'est pas terrible à mon goût non plus, mais il faut reconnaître à leur crédit que contrairement à gitlab, tout n'a pas changé de place au moins 3 fois en nous obligeant à nous réhabituer. Et l'instabilité historique de l'interface de gitlab a été déroutante (j'espère pouvoir parler au passé).
# Râler en public
Posté par gasche . Évalué à 5.
Étant frustré par l'immobilité de Gitlab sur cette discussion, j'avais adopté une technique dont je trouve l'efficacité assez frustrante voire agaçante : faire des reproches en public pour faire de la question non seulement une question de fond, mais aussi une question de réputation. Les gens qui sont sur Twitter font ça très bien, on entend beaucoup d'histoires de gens qui contactent un service client, aucun résultat probant, et qui se mettent à râler sur Twitter et là tout de suite on leur donne satisfaction. C'est triste, mais souvent le fait qu'on expose un problème à un endroit où il touche la réputation de l'autre permet de le résoudre beaucoup plus rapidement.
Concrètement, c'était un message Google Plus, dans la communauté Gitlab (donc visible par les gens auprès de qui Gitlab veut faire de la publicité : cette communauté fait partie de la stratégie de communication) pour râler sur l'absence totale de réponse de Gitlab sur l'issue. Quatre jour à près, une personne de Gitlab répondait qu'ils allaient y re-réfléchir. Je ne connais pas assez leur processus décisionnel pour dire que "c'est ça" qui a débloqué la situation, mais c'est clair que ça a joué—la personne le dit lui-même.
Il faut faire attention à ne pas trop utiliser cette technique, je pense. Quand on force des gens à réagir à quelque chose, ça peut être aux dépends d'un autre sujet sur lesquels ils travaillaient qui était aussi ou plus important. En plus ça nécessite forcément de rentrer un peu dans le lard (si on écrit une demande gentille et implicite, ça ne fait pas pression), et donc ce n'est pas une bonne manière d'entretenir des relations productives sur le long terme.
Je ressors de cette expérience (et d'autres un peu du même genre) avec un sentiment mitigé sur ce modèle d'"Open Core" où tout le monde danse d'un pied sur l'autre pour savoir ce qui va être libre et ce qui ne va pas l'être, et où on sent que parfois il y a une barrière à l'amélioration de la solution libre à cause de l'offre propriétaire qui l'accompagne. J'aime mieux les modèles par souscriptions, comme LWN.net.
[^] # Re: Râler en public
Posté par Framasky (site web personnel) . Évalué à 10.
Quelle immobilité ? Ils avaient répondu. D'accord, la réponse fournie ne te convenait pas, mais on ne peut pas dire qu'ils sont restés silencieux. Et la réponse avait du sens (on pense que ça n'est utile que quand plus de 100 utilisateurs et — plus loin — on craint que ça ne déprécie la valeur de l'EE), ça n'était pas une réponse capricieuse, il y avait de la réflexion derrière.
Au bout d'un moment, que veux-tu, on n'a pas forcément envie de revenir sur une discussion close (le ticket était d'ailleurs bel et bien clos).
Je ne fais pas de support pour Apache pour mes logiciels. Si quelqu'un m'en demande, je réponds non (de manière argumentée), fin de la discussion. Ce n'est pas de l'immobilisme, c'est juste que j'ai mes raisons, et une opinion sur le sujet que je ne compte pas changer (si tu veux savoir, c'est parce qu'Apache, en tant que reverse proxy est bien plus embêtant à configurer que Nginx, et que comme c'est sur mon temps privé que je fais le support de mes logiciels, je considère avoir le droit de ne pas m'embêter avec un truc que je n'aime pas. Mais libre à la communauté de proposer des exemples qui seront intégrés à la doc).
NB : Quand je les ai interpellés sur Twitter, je ne cherchais pas à leur mettre la pression, je n'attendais qu'une réponse succincte (oui/non/on va y réfléchir), et ils ont créé un ticket d'eux-même. Donc ils ont carrément été actifs.
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: Râler en public
Posté par gasche . Évalué à 2.
Mon analyse de la situation est un peu différente. Je trouve assez difficile d'argumenter que Gitlab Pages n'a d'intérêt que pour les organisations de plus de 100 utilisateurs—puisque Github pages est utilisé par de nombreuses personnes de façon purement individuelle, et qu'au contraire les grosses organisations ont plus souvent des sites webs dédiés et non-statiques. N'importe quelle instance Gitlab, quelle que soit sa taille, bénéficie du fait d'avoir des pages statiques pour chaque utilisateur et pour chaque projet.
Je veux bien croire qu'au moment où cette décision a été prise, elle n'avait pas été beaucoup réfléchie (c'était juste un petit ticket). Mais je pense que la longue liste de personnes qui sont venues dire qu'elles en auraient l'usage à titre individuel aurait du rendre clair assez vite que la justification de départ était à revoir. Ça n'a pas été fait pendant quatre mois; juste après la fermeture du ticket, Drew a commenté
C'était très vrai, et ça l'est resté pendant quatre mois. Aucun signe que les développeurs Gitlab, indépendamment de leur envie de changer ou pas de décision, reconnaissaient que la justification devait être approfondie. C'est ça, pour moi, l'immobilisme.
[^] # Re: Râler en public
Posté par barmic . Évalué à 4.
En auto hébergé ça n'a pas vraiment d'intérêt. Tu publie un dossier à partir de ton reverse proxy et tu pousse ton contenu avec rsync ou tout ce que tu veux d'autre. Au contraire Git(hub|lab) Pages vont à l'encontre du principe fondateur de ce types de sites statiques : avoir un serveur simplifié au maximum.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Râler en public
Posté par gasche . Évalué à 4. Dernière modification le 27 décembre 2016 à 19:50.
Je crois que c'est un peu plus subtil que ça.
D'une part, un des cas d'usages est une personne qui est sur Github.com ou sur Gitlab.com, qui utilise leur option Pages pour son blog perso, et qui décide de passer en auto-hébergé. Elle peut s'attendre à pouvoir conserver la même méthode—la disponibilité de cette méthode peut même influencer son choix de logiciel à auto-héberger.
Ensuite, il y a une ambiguité quand on dit "fait sens pour une organisation de 100 personnes", est-ce qu'on parle d'une instance de Gitlab avec 100 utilisateurs, ou alors d'organisations de gens travaillant ensemble de façon ciblée ? (Chez Github c'est clair, "organisation" c'est la personne morale 'foo' github.com/foo; chez Gitlab c'est moins clair, ils utilisent plutôt "Groupes" pour ce concept). Si les développeurs de Framasoft utilise un Gitlab perso pour gérer le code leurs projets, c'est très clairement une organisation (de moins de 100 personnes). Si on parle de Framagit, est-ce que c'est "une organisation" ? Je suis prêt à faire le choix le plus restrictif: j'imagine qu'ils pensent aux instances de plus de 100 utilisateurs¹.
Enfin, il y a plein de groupes de gens de par le monde qui font de l'auto-hébergement mutualisé : un groupe de gens qui se connaissent et qui se partagent les coûts et l'effort d'entretien d'un serveur web, éventuellement d'un serveur mail, etc. On est tous d'accord je pense sur le fait que c'est un excellent modèle. Ces groupes peuvent tout à fait avoir l'usage de Pages (cf. premier point: héberger les pages web d'un projet dans le Pages de la forge correspondante c'est naturel, serveur dynamique à côté ou pas), et font dans leur grande majorité moins de 100 personnes—j'appartiens moi-même à deux groupes différents d'une dizaine de personnes chacuns (mais aucun n'héberge d'instance gitlab). Et ce cas d'usage montre bien que l'intérêt de la feature ne dépend pas du tout du nombre d'utilisateurs de l'instance.
¹: Il y a un truc très pervers avec les modèles commerciaux des forges fondés sur le nombre d'utilisateurs, et que j'ai mis du temps à réaliser. Ça marche bien pour des structures qui ont des dépôts à l'équipe de développement fermée, ou carrément des dépôts privés. Mais ça ne marche pas du tout pour du développement coopératif libre, à moins d'implémenter la fédération d'instances. Je m'explique : si tu mets un projet disponible sur Gitlab (auto-hébergé ou gitlab.com ou gitlab.inria.fr), tu veux que les gens puissent t'envoyer des propositions de changements (pull/merge requests). Mais aujourd'hui pour envoyer une proposition de changement, il faut un compte sur l'instance de la personne. Du coup si tu as un projet qui a du succès sur une instance gitlab, tu n'as aucun contrôle sur le nombre d'utilisateurs qui vont s'inscrire dessus pour t'envoyer une petite contribution—et tu as envie que ce nombre soit grand. Si tu paies ton hébergement au nombre d'utilisateurs, ou de manière générale si les gens qui développent le logiciel catégorisent les instances en "nombre d'utilisateurs inscrits", ça ne colle pas du tout. Ça aurait du sens si tu avais de la fédération, si pouvais envoyer une proposition de changement d'une instance de Gitlab à une autre. Je pense maintenant qu'il est important d'implémenter ce genre de fonctionnalités. (Le mieux serait d'avoir un format qui marche avec toute forge git, par exemple en utilisant le format de
git format-patch, que github par exemple sait très bien produire en sortie (github.com/foo/bar/pull/123.patch).)[^] # Re: Râler en public
Posté par Framasky (site web personnel) . Évalué à 4.
Ton argument du nombre de personnes indéfinies qui vont s'inscrire pour patcher une fois couplé au coup par utilisateur est très pertinent ! Marrant qu'il ne soit pas apparu tel quel dans le ticket.
Pour la fédération, il y a un ticket en cours (je vous laisse chercher, je suis sur mon téléphone), donc on peut espérer — un jour — au moins un embryon de fédération, ne serait-ce que pour les merge-requests.
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: Râler en public
Posté par gasche . Évalué à 3.
Merci. Il est en fait apparu indirectement dans la discussion, où Éloi Rivard a dit:
Cependant c'est plutôt un commentaire général sur le soucis de la mesure du nombre d'utilisateur (et le modèle de choix des prix des hébergeurs payants) qu'un argument spécifique à Pages, donc je n'ai pas jugé bon de développer spécifiquement sur ce ticket.
[^] # Re: Râler en public
Posté par Zenitram (site web personnel) . Évalué à 9.
He ho ca suffit la. On (les développeurs) n'est pas la a attendre les questions et réfléchir dans la journée a ta question, on a aussi d'autres choses sur le feu.
Je réagis car ca m'arrive aussi souvent cd "tu dois répondre la maintenant (et de préférence dans mon sens)", et c''est franchement pas agréable et donne envie d'envoyer chier par principe de ne pas faire plaisir aux chieurs (déjà que ca oblige parfois à répétr la même réponse une n-ieme fois car la question a été reposée n fois car "réponse des dev ne me plait pas").
alors désolé mais je trouve la réaction FramaSky, surtout face au refus, bien plus agréable que ces accusations qui font plus penser à "tu as pas répondu ce que j'attendais". Et si on débattait sans ces attaques "immobilisme" etc?
[^] # Re: Râler en public
Posté par gasche . Évalué à 2.
Je suis développeur aussi et je sais faire la différence entre "la question la plus importante du monde pour trois râleurs ou râleuses qui ne se remettent jamais en question" et "la communauté montre un intérêt fort pour un sujet mais la hiérarchie préfère mettre la tête dans le sable".
Le ticket avait 25 commentaires quand il a été fermé, il en accumulé plus de 100 supplémentaires pendant les quatre mois de silence de la part de Gitlab. Je t'invite à aller chercher sur le traqueur de tickets de Gitlab CE pour d'autres tickets qui auraient plus de 100 commentaires, il n'y en a quasiment jamais (un "très gros" ticket c'est 30, 50, 80 commentaires max), je n'en connais qu'un seul ("Issue Boards") qui soit plus gros, à 208 commentaires. On ne peut pas tout déduire d'un nombre de commentaire, mais c'est clair que cette question avait un intérêt fort pour une base d'utilisateurs importante, et que Gitlab en était conscient—et qu'ils avaient pourtant choisis de ne pas réagir ou répondre aux arguments qui étaient avancés.
Je suis d'accord sur le fait que critiquer les gens en public, quand ils font par ailleurs souvent du bon boulot, ce n'est pas agréable. C'était justement tout le but de mon commentaire initial que de montrer que c'est une technique désagréable, à utiliser avec une grande modération, mais qui peut parfois (malheureusement ?) être efficace aussi.
[^] # Re: Râler en public
Posté par BAud (site web personnel) . Évalué à 2.
quand le patch est initialement fourni, cela donne tout de même le levier permettant d'éviter facilement le fork rajoutant la fonctionnalité et permet au développeur principal de montrer qu'il est à l'écoute de la communauté plutôt que focalisé sur son business model initial et sait rajouter une autre fonctionnalité, tout le monde est gagnant : pas de dispersion. fonctionnalité ajoutée au libre, fonctionnalité ajoutée à l'EE qui passera aussi en libre tôt ou tard (un logiciel peut être libre, une fois qu'il a été payé).
Bon entre github/gitlab (bien parti) et cyanogenmod/lineageos (mal'barre(*)) j'ai un peu de mal à trouver des arguments pour et contre :/ on va dire qu'il y en a un qui abuse du java, ah non plus… bah.
(*) https://linuxfr.org/users/ms-mac/journaux/cyanogenmod-est-mort-vive-lineageos
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.