Alors que 2022 a commencé, il est temps de revenir sur l’année 2021. Comme il s’agissait de ma première année en tant que co-mainteneur, j’ai décidé d’écrire ce compte-rendu en mon nom propre sur le site officiel, me permettant ainsi un propos plus personnel sur ce que le projet GIMP représente pour moi.
J’en profite pour annoncer la sortie (fin 2021) de la version corrective GIMP 2.10.30.
"Hello 2022" par Aryeom, Creative Commons by-sa 4.0 - GIMP 2021 annual report
Sommaire
- Statistiques
- Constituer une équipe agréable
- GIMP 2.10.30 sorti juste avant noël
- GIMP 3.0 en approche
- GEGL, babl et ctx
- Infrastructures, documentation
- Plans pour 2022
Statistiques
En 2021, nous avons eu :
4 versions stables (GIMP 2.10.24, 2.10.26, 2.10.28 et 2.10.30) ;
2 versions de développement (GIMP 2.99.6 et 2.99.8) ;
1179 commits sur la branche de développement instable (2.99.x, la future 3.0) et 407 commits sur la branche de développement stable (2.10.x) du dépôt principal ;
-
91 contributeurs sur le dépôt principal, dont (certains appartiennent à plusieurs catégories) :
- 41 développeurs ;
- 42 traducteurs ;
- 24 contributeurs de ressources (icônes, thèmes, documentation dans le dépôt de code) ou d’améliorations du système de compilation.
22 personnes ont contribué plus de 10 commits dans le dépôt principal, parmi lesquels 2 contributeurs ont réalisé plus de 100 commits (Jacob Boerema et moi-même), parmi lesquels un seul (moi-même) en a réalisé plus de 500 ;
247 commits sur le dépôt du site web de GIMP par 14 contributeurs ;
31 commits sur le dépôt de babl par 6 contributeurs ;
229 commits sur le dépôt de GEGL par 33 contributeurs ;
1179 commits sur le dépôt de ctx par 3 contributeurs (principalement Øyvind Kolås) ;
255 commits dans le dépôt
gimp-help(notre manuel), dont le principal contributeur est Jacob Boerema qui fait un superbe travail de reprise ;53 commits dans le dépôt
gimp-macos-build(notre dépôt pour le système de build de macOS) par 4 contributeurs (principalement Lukas Oberhuber qui a repris la maintenance du paquet macOS) ;185 rapports de bogues corrigés dans nos versions de 2021 et des centaines de plus gérés, triés, discutés et étudiés… ;
de nombreux correctifs réalisés par les contributeurs de GIMP dans divers autres projets que nous utilisons (GLib, GTK, Cairo, GExiv2 et d’autres… trop nombreux à citer) et d’innombrables rapports de bogues remontés par nos contributeurs à d’autres projets ;
De l’aide offerte à (ou obtenue par) d’autres Logiciels Libres quand nous le pouvons, par exemple au très sympathique projet Siril pour le traitement d’images d’astronomie, et d’autres logiciels, parce que contrairement à ce que certains pensent, nous ne nous positionnons pas dans un marché ou une compétition ! Nous travaillons ensemble à construire un meilleur environnement de travail graphique ;
Et bien plus !
Au final, c’est un sacré travail qui vous est fièrement présenté par GIMP.
Comme vous pouvez le remarquer, nous avons de belles contributions, et pourtant le cœur du développement est en fait toujours réalisé par une poignée de personnes puisque la plupart des contributions sont ponctuelles (sur 91 contributeurs, 69 ont réalisé moins de 10 commits, et parmi ceux-ci, 51 n’en ont réalisé qu’un seul).
Je veux saluer Jacob Boerema en particulier, qui est le plus gros contributeur sur la branche stable cette année, alors que, je dois admettre me concentrer davantage sur la branche instable, quitte parfois à négliger un petit peu la branche stable 😒 ! Merci Jacob ! 🤗
Et nous ne devrions jamais oublier babl, GEGL et le nouveau projet ctx par Øyvind Kolås, puisque ceux-ci constituent le cœur du moteur d’imagerie de GIMP, et sont considérés comme faisant partie intégrante du projet GIMP au même titre que l’interface elle-même.
Constituer une équipe agréable
Vous avez peut-être remarqué une section récurrente dans les quelques dernières nouvelles, appelée "Nouvelles de l’équipe" dans laquelle nous listons les changements dans l’équipe, en particulier les nouveaux contributeurs à qui ont été donné plus d’accès sur le gestionnaire de bogues ou le dépôt de sources. J’essaie d’être de plus en plus proactif dans l’intégration de nouvelles personnes au sein de l’équipe principale.
En effet, comme vous l’avez vu dans les statistiques, Jacob Boerema est le seul autre contributeur qui a réalisé plus de 100 commits en 2021, tandis que j’en ai réalisés un peu plus de 500. Je souhaite améliorer ce ratio pour augmenter le bus factor (nombre de personnes sur lesquelles repose la pérennité d’un logiciel, lequel est de 2 ou 3 en moyenne pour GIMP ces dernières années).
L’équipe de GIMP a toujours été très accueillante, du moins depuis que j’ai commencé à contribuer en 2012 et c’est même la raison qui m’a fait rester. Je veux perpétuer cette tradition. Mon but est d’identifier plus rapidement les personnes à qui donner plus de responsabilités (notez que les compétences techniques sont importantes mais la sociabilité, autrement dit être une bonne personne et agréable avec les autres, est mon critère prioritaire). Bon, en vrai, c’est bel et bien une astuce diabolique 🦹 pour diminuer ma propre charge (notamment comme je constate que je n'arrive plus à développer autant que je le voudrais car je m'occupe de trop de sujets transverses et que j'ai trop de tâches de maintenance), mais je m’attends également à ce que cela rende les contributions au projet plus attrayantes 🎡 (d’expérience personnelle)!
Remercions tout spécialement Jacob Boerema pour son travail sans répit sur l’amélioration de prise en charge des formats de fichier (et plus encore), Niels de Graef pour son aide inestimable et sa grande expertise de GTK, Luca Bacci pour son très joli travail sur la prise en charge des appareils de saisie, son aide sur Windows et son expertise GTK, Daniel Novomesky pour avoir fait de HEIF/AVIF et JPEG-XL des formats de première importance…
N’oublions pas les contributeurs récurrents tels que Massimo Valentini, Lloyd Konneker… (que ferions-nous sans ces personnes qui n’abandonnent pas GIMP après tant d’années ?!) et les nouveaux arrivants prometteurs comme Stanislasv Grinkov.
Maintenant, applaudissons nos empaqueteurs : Jernej Simončič fait partie de GIMP depuis aussi longtemps que je m’en souvienne, fabriquant sans accrocs les installateurs Windows, un coéquipier solide sur lequel s’appuyer ; l’histoire de macOS est plus chaotique et pourtant Lukas Oberhuber a fait un travail titanesque ces derniers mois, donc j’espère qu’il restera parmi nous ; du côté de Flatpak, Hubert Figuière est d’une grande aide également (et j’espère secrètement 🤫 qu’il prendra ma suite pour la maintenance de nos flatpak stable, beta et nightly !).
Au final, GIMP, c’est beaucoup plus que ses seuls développeurs, c’est une communauté. Que ferions-nous sans les personnes qui aident à maintenir le site web, à trier les bogues, à gérer nos infrastructures et tout le reste ? Et n’oublions pas les traducteurs, si nombreux ! Je vous adore tous ! Désolé de ne pas citer tout le monde (si je vous ai oublié, ne le prenez pas mal, il y a juste trop de gens qui font du bon boulot parmi nous !).
Quand j'en parle, je définis GIMP tout autant comme un logiciel communautaire qu’un Logiciel Libre, ou plus simplement j’appelle cela un Logiciel Libre Communautaire. Ce double concept est extrêmement important à mes yeux et c’est la raison pour laquelle j’aime GIMP et pourquoi Aryeom comme moi-même (du projet ZeMarmot, à partir duquel nos contributions majeures ont réellement débuté) sommes restés. C’est un projet d’humains qui se rencontrent et essaient de construire quelque chose de bien ensemble (même si les buts personnels de chacun peuvent différer). Tout fonctionne merveilleusement du moment que nous nous souvenons d’être bienveillants les uns avec les autres. 🤗
Donc, à tous les contributeurs (quelles que soient leurs spécialités) qui ont aidé GIMP jusque-là, je veux dire un énorme merci ! GIMP est ce qu’il est grâce à vous !
🙏
GIMP 2.10.30 sorti juste avant noël
Sur le site de GIMP, cette sortie avait une dépêche dédiée, mais puisque cette traduction a tardé, j’ai fusionné les deux nouvelles (la sortie et le compte-rendu de l’année) pour LinuxFr.
En bref, GIMP 2.10.30 est principalement une sortie corrective qui contient néanmoins quelques améliorations intéressantes de prise en charge de formats en particulier pour le format PSD (divers sous-cas du format nouvellement ou mieux gérés) et AVIF (utilisation de l’encodeur AOM de préférence à rav1e car les performances du premier ont été améliorées significativement dernièrement).
Nous avons aussi continué à travailler sur la prise en charge améliorée des changements sur les environnements Windows, macOS et Linux/Wayland (car on le sait, tout n’est pas une nouvelle fonctionnalité ou une correction de bogues ; parfois on doit changer du code simplement pour suivre des changements perturbateurs en amont).
GIMP 3.0 en approche
Avec quatre versions de développement déjà sorties, vous savez que nous travaillons très dur sur le futur : GIMP 3.0.
Quelques fonctionnalités ont pris beaucoup de temps, principalement quand nous avons changé la logique du cœur du projet. Je pense en particulier au code de sélection multiple de calques. Le problème n’est pas le fait que sélectionner plusieurs éléments dans une liste serait difficile à implémenter, mais plutôt que l’ensemble des fonctionnalités de l’application ont toujours été implémentées avec le présupposé qu’il n’y a jamais plus d’un seul calque ou un seul canal sélectionné. Donc que se passe-t-il quand il y en a maintenant 2, 3 ou davantage sélectionnés ? Chaque fonctionnalité, chaque outil, chaque greffon et filtre doit être repensé pour ces nouveaux cas d’utilisation. C’est un travail énorme et cela fait deux ans que je m’y attelle cahin-caha, tout en continuant aussi le port vers GTK3 ou le développement d’autres fonctionnalités ainsi que les revues de code des autres contributeurs. Heureusement, ce travail sur la multi-sélection de calques/canaux approche de sa conclusion, sans pour autant être complètement fini.
C’est donc un jalon important vers la sortie de GIMP 3.0.
Au fait, une partie de ce travail a été de se débarrasser du concept d’"éléments enchaînés" (l’icône ⛓ dans la fenêtre ancrable Calques) en faveur de la sélection multiple (ainsi que la recherche et le stockage de sets de calques comme concept remplaçant la capacité à sauvegarder les calques enchaînés). Cette partie est également terminée. J’en parlerai davantage dans la dépêche de sortie de GIMP 2.99.10.
Calques enchaînés remplacés par recherche de calques + icônes de verrous déplacés — version de développement
Parmi les autres éléments bloquants que j’avais listés il y a un an, nous avançons progressivement sur notre port GTK3 et la prise en charge de Wayland, ainsi que sur la stabilisation de l’API des greffons. J’espère que tous cela sera bientôt considéré comme étant dans un suffisamment bon état pour considérer publier une sortie "candidate" (Release Candidate – RC).
D’un autre côté, l'invasion spatiale a été le parent pauvre de 2021 et est certainement le sujet sur lequel il nous faudra revenir très bientôt. Il en est de même pour la platforme d’extensions.
GEGL, babl et ctx
Le cœur 🫀⚙️ du GIMP moderne est GEGL, un projet de bibliothèque presque aussi vieux que GIMP lui-même, développé par les mêmes personnes, quand bien même la première tentative d’intégration a seulement eu lieu dans GIMP 2.6, et qui, depuis lors, fait doucement son chemin pour être le moteur principal derrière la plupart des manipulations de pixel dans le logiciel.
Le développement de GEGL a été ralenti depuis 2019, mais principalement parce qu’il devient chaque jour plus stable, ce qui signifie surtout que le code se consolide. C’est donc une bonne situation.
Maintenant, ce serait tout de même injuste d’oublier de parler des prises en charge récentes du modèle de couleur CMYK dans GEGL, ce qui signifie que nous sommes un pas plus proche d’une meilleure prise en charge dans GIMP.
Une autre aventure excitante est le nouveau projet sur lequel travaille Øyvind Kolås : ctx, une bibliothèque de graphisme vectoriel.
Bien sûr cela peut paraître futile si on développe une application de graphisme matriciel, mais il y a en fait beaucoup de sujets concomitants. Un de ces sujets est l’interface graphique elle-même qui est généralement rendue par des primitives vectorielles. Dans le cas de GTK, le rendu est produit via Cairo. Øyvind a beaucoup travaillé pour faire un rendu à la fois plus joli et plus rapide que Cairo, ou au moins équivalent dans de nombreux cas. ctx inclue également la gestion des couleurs depuis le début tel une partie intégrante de la plateforme.
Bien sûr ctx est en plein développement comme on peut le voir par le nombre de commits. Donc il faut garder raison et observer à ce stade, mais c’est certainement un projet intéressant puisque Øyvind est clairement un développeur R&D aguerri.
Il y a d’autres choses pour lesquelles ctx est utile, telles que les quelques opérations de GEGL avec des composants vectoriels qui ont déjà été portées vers cette nouvelle bibliothèque (par ex. gegl:fill-path) et le rendu de texte aussi se fait dorénavant le plus souvent via des formes vectorielles (donc qui sait ce qu’il se passera quand nous améliorerons la prise en charge du texte ?). GIMP ne va pas se réorienter vers du graphisme vectoriel, mais nous pourrions parfaitement avoir plus de fonctionnalités basées sur du vectoriel dans l’avenir (quiconque suit un peu mon travail sur ZeMarmot par exemple sait que nous cherchons vraiment à améliorer les manières d’intégrer SVG dans GIMP, comme dans mon expérimentation de calque-lien vers des images externes, non encore intégrée).
Quand nous ferons plus de prise-en-charge vectorielle dans GIMP, ctx sera sans aucun doute une solution potentielle de choix.
Je sais que Øyvind me dirait que ctx est en fait beaucoup plus vaste que ces quelques usages que j’ai résumés ici. Donc permets-moi de m’excuser à l’avance, Øyvind ! C’est la raison pour laquelle ce billet est en mon nom, assumant mes propres limitations dans la compréhension de tes plans futurs, et prêt à être agréablement surpris et étonné plus tard ! 🤯
Infrastructures, documentation
Dans tout projet logiciel, il y a une constante qui est pratiquement invisible, et pourtant extrêmement importante : l'infrastructure.
Vous avez peut-être remarqué que nous en avons parlé un peu plus qu’à l’accoutumée en 2021 parce que certains manques m’ont toujours ennuyé dès mes premières contributions à GIMP. J’ai ainsi toujours regretté que nous n’ayons un système de construction de binaires distribuables plus solide, automatisé et transparent (ce qui est aujourd’hui le cas pour Windows, macOS et Linux via Flatpak), une meilleure gestion des miroirs de téléchargement, une meilleure intégration continue pour le développement et une meilleure documentation pour l’utilisateur final (sous l’élan de Jacob ces derniers temps ! Et nous prévoyons d’automatiser davantage la publication et la politique de test en ligne du manuel de GIMP, ce qui devrait voir le jour en 2022)…
2021 a également été l’occasion de réaliser des changements dans la documentation pour les développeurs : Akkana Peck (bien connue pour avoir écrit des livres sur GIMP) et Lloyd Konneker ont aidé à mettre en place un début de documentation pour porter les greffons et scripts de la version 2.10 vers la version 3.0. Akkana a aussi aidé à mettre en place les règles de génération de références de l’API pour Python et JavaScript (avec g-ir-doc-tool). Plus récemment, Niels De Graef a migré la génération de notre documentation C des API depuis gtk-doc vers gi-docgen, produisant une documentation web beaucoup plus moderne pour les développeurs de greffons. Rien de cela n’est encore disponible en ligne mais seulement inclus dans le dépôt des sources pour l’instant. Mettre en place une procédure de mise à jour en ligne pour ces documentations est aussi sur la TODO list.
Nouvelle documentation d’interface pour les développeurs de greffons – version de développment
Tous ces sujets prennent beaucoup de temps et sont aussi nécessaires pour atteindre un niveau d’utilisation de GIMP plus agréable. Donc je suis déjà assez fier de ce que nous avons fait en 2021 et vraiment excité à propos de nos plans pour 2022.
Plans pour 2022
Vous vous demandez peut-être maintenant : quand est-ce que sortira GIMP 3.0 ?
Et non, désolé, comme toujours, nous ne répondons pas à une telle question. 😛
Ce que je peux dire, c’est que nous y travaillons dur et je suis le premier à vouloir que cela advienne au plus tôt.
Comme expliqué, hors le code en lui-même, le travail sur les infrastructures est aussi chronophage. Or je souhaite que nos nouvelles infrastructures de manuels en ligne ainsi que notre cadriciel web d’extensions soient prêts pour la sortie de GIMP 3.0. Idéalement je souhaite également mettre en place un tout nouveau site web pour développeurs avec de la documentation à jour.
Donc les évolutions sont en fait assez nombreuses et il ne s’agit pas seulement du code du logiciel (qui n’est pas tout à fait prêt non plus, de toutes façons).
N’oubliez pas que vous pouvez donner au projet et personnellement financer plusieurs développeurs de GIMP, de manière à en valoriser et accélérer le développement. Comme vous le savez, moi-même en tant que mainteneur de GIMP et Aryeom — qui est, dans l’ombre, responsable d’énormément d’améliorations, design, tests et de nouvelles fonctionnalités — (tous deux via le projet ZeMarmot, notamment sur Patreon et Liberapay; vous pouvez donc considérer ces comptes comme les comptes officiels de maintenance de GIMP, la majorité du code vient de là), de même qu’Øyvind en tant que mainteneur de GEGL (sur Patreon et Liberapay) sommes financés de manière participative pour pouvoir travailler à plein temps essentiellement sur du Logiciel Libre et de l’Art Libre.
Tout financement est apprécié pour nous aider à voir ces efforts aboutir, car nous ne sommes toujours pas pérennes.
Je vous souhaite à tous une merveilleuse année 2022. 🥳
Aller plus loin
- Compte rendu annuel de GIMP - 2021 (26 clics)
- Sortie de GIMP 2.10.30 (40 clics)
- Précédente sortie d'une version stable (2.10.28) sur LinuxFr (27 clics)
- Faire un don pour soutenir le projet GIMP et ses développeurs (27 clics)
- Télécharger GIMP (33 clics)
# Libre et communautaire
Posté par Thomas Debesse (site web personnel) . Évalué à 8.
Tout à fait. Certains diront que le libre n’oblige en rien d’être communautaire, ce qui est vrai, c’est pour cela qu’il faut le préciser. Libre et communautaire. =)
ce commentaire est sous licence cc by 4 et précédentes
# Remerciements
Posté par Foxy (site web personnel) . Évalué à 9.
Merci pour ce CR très complet et pour ton travail pour maintenir/développer ce fabuleux outil qu'est Gimp.
# J'utilise Gimp
Posté par Watchwolf . Évalué à 6.
J'utilise Gimp plusieurs fois par semaine, alors un grand MERCI :)
# GitHub sponsor ?
Posté par dzecniv . Évalué à 4.
Salut,
Ne veux-tu pas créer un compte GitHub sponsors ? https://github.com/Jehan
C'est une option pas mal parmi celles existantes: Patreon a un frais mensuel de paiement par carte, Liberapay n'est pas clair dans les dons mensuels et se casse un peu la gueule, Paypal c'est moins visible (et ça accepte les dons récurrents ?)…
[^] # Re: GitHub sponsor ?
Posté par Thomas Debesse (site web personnel) . Évalué à 8.
Oui ça accepte les dons récurrents, voir par exemple le bouton donner avec paypal sur cette page : https://film.zemarmot.net/fr/donate
Ça propose un choix de plusieurs montants possibles, ou la possibilité de faire un don à montant libre, et de cocher la case pour le rendre récurrent (mensuel). Sur cette page le bouton n’est pas un lien mais un formulaire, et je ne sais pas si le lien produit est durable donc je mets une copie d’écran :
D’ailleurs j’aimerai bien savoir comment c’est fait ce genre de formulaire avancé. Le mieux que j’arrive à produire pour moi-même c’est ça et je peux soit saisir un montant de base, soit aucun, mais pas proposer une sélection.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: GitHub sponsor ?
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
En fait j'en ai entendu parler bien entendu, mais j'ai jamais regardé de près car mon compte Github est un peu moribond (comme on peut le constater en cliquant le lien) puisque la plupart de mes contributions sont dans des dépôts hors Github.
Donc je me suis toujours dit que ça donnerait pas envie. Si on regarde ça, on a l'impression que je suis un développeur du dimanche. Pourquoi on me sponsoriserait là dessus pour quelqu'un qui utilise Github comme référence?
Enfin bon, je peux toujours jeter un œil à ce que ça implique.
Github sponsors n'a aucun frais?
En fait, Liberapay est actuellement notre première source de dons (plus que les autres plateformes). Et c'est les frais les plus bas (bon je sais pas pour Github sponsors, tu as l'air de dire que c'est encore mieux), et aussi le plus simple à gérer.
Le fait que ce soit hebdomadaire est aussi bien plus confortable. En conséquence (je pense), les donations fluctuent beaucoup plus dessus, mais on a constamment des petites rentrées de dons utilisables. C'est bien plus utile pour un projet actif, je trouve.
J'apprécie aussi que la plateforme soit un logiciel libre, gérée par une association française à but non lucratif.
Ensuite c'est vrai que c'est devenu un peu plus compliqué depuis qu'ils ont changé de fournisseur financier mais ont continué de garder la même logique frontale alors que le backend ne correspond plus. Je peux voir comment cela peut être un peu confus pour les gens. Je suis d'accord qu'ils pourraient y gagner à remodeler la logique. Mais bon, le fait est que ça n'empêche pas la plateforme d'être toujours là.
Et puis c'est toujours plus facile à dire qu'à faire de changer la logique de fonctionnement, notamment pour les donateurs (et projets cibles de donation) existants. Peut-être que c'est la raison. Et je ne voudrais pas présumer qu'une transition vers une nouvelle logique se passerait sans accroc, c'est pas comme si je peux leur assurer.
En effet comme le dit Thomas Debesse. En plus normalement nous avons le statut d'organisme à but non lucratif chez Paypal donc on a des frais un peu moindres que des organismes commerciaux, quoique je suis jamais sûr car c'est jamais écrit nulle part, et quand je calcule les frais des donations directes, je comprends pas toujours si ça marche bien. 🤷
J'ai rien "développé" si c'est la question (d'ailleurs c'est sur le site Paypal). De mémoire, c'est juste des widgets qu'on peut créer quelque part dans l'interface de Paypal (j'ai fait ça y a longtemps, je saurais plus dire). Rien de vraiment extravagant.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: GitHub sponsor ?
Posté par dzecniv . Évalué à 5.
OK merci à vous deux pour le complément d'infos. +1 pour Liberapay (où je participe :) ), mais je suppose que le ratio personne prête à donner / personne qui le fait n'est pas trop bon sur Liberapay (à cause des limitations).
Oui, GitHub sponsors c'est sans frais.
Exact, on ne voit pas tes contribs Gimp sur GitHub, mais peu importe à la limite, pour celles et ceux qui savent, ça fait juste un moyen de plus pour faciliter les dons :)
my 2c
# Abandon du fork Glimpse depuis un an
Posté par Oliver (site web personnel) . Évalué à 4. Dernière modification le 25 février 2022 à 21:44.
Merci à la communauté GIMP. J’utilise GIMP depuis une vingtaine d’années. Au début, je n’y comprenais pas grand-chose. Mais à force de l’utiliser et d’expérimenter ses menus j’arrive de mieux en mieux à sortir des résultats impressionnants. Mais, je suis conscient que je maîtrise seulement 1 % de ses possibilités. En même temps, je n’ai pas le courage (ni le temps) de lire les tutoriels (ni regarder des tutoriels vidéos).
Pour info, le fork Glimpse n’est plus maintenu depuis un an pile. Le dernier post explique que le contributeur principal, Bobby Moss, croulait sous les tâches annexes : modération, tri des bogues, empaquetage, échanges avec le projet GIMP, médias sociaux, administration système, tests, documentation… Cette situation était due à la raréfaction des contributeurs durant la pandémie, malgré le nombre croissant d’utilisateurs.
Mais Bobby avait besoin de son job à plein temps pour subvenir à ses besoins financiers, et son employeur ne voulait pas qu’il s’implique autant à Glimpse. Son employeur lui a conseillé d’arrêter temporairement sa participation au projet, ce qu’il a fait.
Au bout de 10 semaines, Bobby revient et découvre le projet au point mort. N’ayant plus l’énergie, ni le temps, pour tout redémarrer, Bobby a préféré quitter le projet, en fermant ses droits d’accès. Personne d’autre ne voulait/pouvait s’occuper du projet et tous les dépôts de code source ont été passés en mode « lecture seule ». Les donations que le projet Glimpse continuait à percevoir (800 $) ont été rendus à l’Open Collective.
C’est dommage, car ce fork pouvait apporter de bonnes idées à la structure du code source de GIMP, et tenter d’inventer une nouvelle UX/UI.
J’espère que ce type d’abandon n’arrivera pas à GIMP (Jehan arrête la moto, c’est trop dangereux). Continuons de soutenir financièrement les contributeurs, et toute la communauté GIMP. ;-)
Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)
[^] # Re: Abandon du fork Glimpse depuis un an
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 5.
L'information avait été partagé :
Et d'après les commentaires là et ailleurs, il y a peu de gens qui vont les regretter d'une part, et GIMP ne risque pas d'avoir le même sort de si tôt d'autre part.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Abandon du fork Glimpse depuis un an
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Ils n'ont strictement rien fait structurellement (pas même en frontend, et juste des bricoles en surface) dans le code source de GIMP. Me croyez pas sur parole, allez regarder le dépôt.
La quasi totalité des commits des contributeurs de Glimpse, c'était genre retirer des mentions à GIMP, retirer le logo (une mascotte en logo pour un logiciel sérieux?! Mais quelle horreur! On n'est pas là pour rigoler!), mettre à jour le README ou autres documents internes, mettre des liens de financement (c'est important! Les sousous! Même/surtout si on n'a rien fait de concret), les paquets et ce genre de trucs. Les seules rares choses un peu plus "profondes" dans le code, c'est probablement quand ils ont retiré les divers "easter eggs", parce que vous comprenez un logiciel sérieux ne peut pas contenir de blagues! 🙄
Tout le reste, quand on regarde leur historique, les rares commits un peu plus complexes que j'ai vu… ce sont des commits à nous du dépôt principal qu'ils backportaient. Ou en tous cas, j'ai pas vu leurs commits sérieux. Ah oui, parce que le coup du "on contribue en retour à GIMP" est totalement bidon évidemment. On n'a pas vu une seule correction de bug ou une seule proposition d'amélioration de GIMP par un contributeur de ce fork. Pas un seul patch proposé! Alors si vraiment j'ai manqué un vrai commit qui vaut quelque chose dans leur arbre (ça reste possible, je me suis contenté de feuilleter 2 ou 3 fois leur dépôt, je vais pas non plus prétendre avoir tout regardé en détail et m'y être intéressé plus de 10 minutes), ce qui est sûr, c'est qu'ils l'ont pas contribué en retour et l'ont gardé jalousement.
Donc le coup du fork utile, laissez moi rire.
En fait, c'est pas tout à fait vrai, on a eu une seule petite contribution sur un paquet de quelqu'un considéré comme un contributeur de ce fork, sur la toute fin de celui-ci. Ironiquement ce contributeur est l'un de ceux à l'origine du fork et pourtant il me semble qu'il n'a en fait jamais contribué dessus (mais à GIMP, 1 commit donc au final; peut-on alors considérer cela comme un retour du fork? Enfin bon, si on veut, admettons: il y a donc eu un patch mineur de paquet après genre 2 ans de dénigrement!).
Pour autant que je sache, ils n'ont fait que du FUD, des attaques des contributeurs de GIMP, beaucoup de stress. Beaucoup beaucoup de mal donc…
Je parle un peu ici des faux contacts positifs qu'ils ont prétendu avoir avec nous tout du long leur existence. En fait, ce n'est positif que de notre côté envers eux puisque nous sommes des gens civilisés, contrairement à eux qui ont débuté leur histoire par du lynchage en règle et qu'on n'a donc jamais chassé cette unique personne qui squattait notre canal de discussion tant qu'elle restait correcte. On n'a aussi jamais menti ou répandu de fausses histoires sur leur projets aux média ou lors d'interviews (contrairement à eux encore une fois), ou même tout court. Et ainsi de suite.
Sinon en bilan final du fork, je rappellerais uniquement qu'on sait que l'un de nos contributeurs principaux a été dégoûté du logiciel libre et a arrêté un moment de contribuer pendant quelques mois. Il nous a dit que c'était concrètement ce fork qui l'a dégoûté. Il est donc revenu ensuite quelques mois puis a à nouveau disparu. Cette fois, on n'a plus de nouvelles depuis plus d'un an et je me dis que c'est sûrement encore la même raison et qu'il a pas digéré complètement les méchancetés. Je parle d'un contributeur qui contribuait à peu près autant que moi, qui est resté plusieurs années avec nous, était super sympa, vraiment extrêmement bon techniquement… de la belle époque dorée où GIMP avait trois gros contributeurs (4 en comptant GEGL) et où tout semblait possible. Sincèrement, il serait encore là, tout irait beaucoup plus vite (c'est simple, il contribuait à peu près comme moi, donc on doublerait plus ou moins le rythme des évolutions principales côté GIMP). GIMP 3.0 serait peut-être déjà sorti, qui sait.
Comme je disais plus haut: ce fork a fait beaucoup de mal. Ils n'ont rien apporté mais on sait bien ce qu'ils ont fait subir, voire perdre. Alors ça me fait toujours de la peine quand je lis ce genre de commentaires sur ce que ce gentil fork plein de gentils lyncheurs a pu apporter et comme c'est trop dommage car ils étaient trop constructifs. Limite c'est grâce à eux si GIMP est ce qu'il est aujourd'hui. Malheureusement c'était plus ou moins leur discours public pendant leur existence déjà, alors je comprends qu'on tombe dans le piège. Mais ça fait mal et ça dénie le travail (réel lui) des dizaines de contributeurs réels de GIMP. Franchement le jour où ils ont fait une campagne marketing en racontant que le développement de GIMP était mort depuis 2012, campagne reprise dans des journaux grand public, dont français, j'ai été dégoûté, déprimé et j'ai moi-même pensé un instant à tout laisser tomber. Bon je me suis assez vite ravisé mais la tentation de jeter l'éponge est forte dans de tels cas. 2012, c'est en plus justement l'année où j'ai commencé à contribuer à GIMP, donc avec leur "petit" mensonge, ils ont en quelque sorte nié l'entièreté de mes contributions à GIMP (et celle de notre projet, ZeMarmot). Là comme ça, l'air de rien. Ça fait mal.
Étonnamment quand ils ont changé leur fusil d'épaule et se sont mis à dire tout simplement l'inverse, c'est à dire que "c'est pas leur faute, ils peuvent pas rivaliser avec les trop nombreux gros contributeurs de GIMP, vous comprenez"… ben peu semblent avoir remarqué l'incohérence du discours (alors que quelques semaines auparavant à peine, ils affirmaient aux journalistes, jusque dans leur site web et leur FAQ que le développement de GIMP était mort depuis 2012). 🤷 C'est un peu désespérant.
En fait un problème déjà à la base est qu'ils se plaçaient en "rival" justement, dans une logique de compétition (même s'ils disaient officiellement l'inverse sauf que dans les faits, ils disaient sans cesse du mal de nous, de notre code, ils mentaient sur le fait qu'on "refusait" des fonctionnalités — sous entendu contrairement à eux —, mensonge des plus éhontés pour quiconque sait comment on travaille… double discours quoi!), alors que GIMP est un projet communautaire (dans notre logique, on n'a aucun "concurrent" et GIMP n'est pas un produit. On s'en fiche si vous voulez utiliser un autre logiciel, on vous souhaite de trouver ce qui vous plaît et nous on veut juste faire de notre mieux. On n'est pas après des "parts de marché"). Or on était leur upstream et ils apportaient quasi rien au dessus. En gros, ils sciaient la branche sur laquelle ils se trouvaient. Pas étonnant qu'avec une telle attitude destructrice, ça n'ait pas duré.
Ce qui est bien certain, c'est que ce nouveau discours était tout aussi faux (y a certes des dizaines de contributeurs, mais pour la plupart des contributeurs de passages; je l'ai dit: dans notre belle époque qui a duré quelques années, on n'était que 3 gros contributeurs, 4 en comptant babl/GEGL; regardez les stats récentes pour voir que de nos jours, on n'est plus que 2 vraiment gros contributeurs sur babl/GEGL/GIMP et quelques petits contributeurs réguliers).
Enfin bon, on n'a rien contre les vrais forks constructifs. Je parle même potentiellement de ceux qui n'aiment pas notre direction technique mais ont agi en êtres humains civilisés, avec une réponse purement technique, pas de lynchage, pas d'attaque ad-hominem. Par exemple pendant quelques années, j'ai essayé de rallier à notre cause et j'ai invité (tous frais payés par GIMP, mais la personne n'a jamais répondu) le mainteneur de GIMP Painter à des conférences pour qu'on puisse discuter. Aux dernières nouvelles, cette personne n'était pas d'accord sur des points techniques mais n'a jamais dit du mal de nous, et n'a jamais essayé de se faire sa pub en dénigrant son projet mère. Contrairement à Glimpse qui ont été nocifs et toxiques du début à la fin et pendant toute leur existence avec des campagnes anti-GIMP. Je n'ai aucun mal à dire du bien de GIMP Painter (qui me paraissait très intéressant et constructif; et faire un travail de qualité). Mais Glimpse? C'est juste un projet malsain.
Ahahah. 🤣
Je suis un conducteur prudent. En outre, je ne conduis pas tant que ça. La plupart de mon temps se passe chez moi (télé-travail), je fais toutes mes courses du quotidien à pied (marché et boutique vrac de proximité), les trucs légèrement plus loin en vélo (qui en l'occurrence est potentiellement plus dangereux que la moto quand je vois les voitures et le fait que notre ville s'en fout des vélos!). J'utilise la moto (mon unique moyen de transport motorisé, toujours la même d'ailleurs, elle a plus de 30 ans maintenant) qu'une fois de temps en temps quand il n'y a pas le choix. Pour tout dire, j'ai fait environ 60.000 km (ou bien 70.000? Je sais plus; y a aussi eu une petite période où le compteur était cassé) quand je vagabondais avec. Puis depuis 10 ans, j'ai dû faire 10 ou 20.000, pas plus. Donc je dirais que le risque existe mais est limité. 😅
P.S.: sinon je devrais vraiment arrêter de répondre sur ce sujet de Glimpse parce que c'est le genre de truc qui fout en l'air ma journée et mon moral (et j'ai donc du mal à me retenir de répondre), mais vraiment ce projet a été tellement toxique et a fait tellement de mal que ça me fout toujours de mauvaise humeur quand je vois des gens qui commencent à dire que ce projet a apporté beaucoup, alors que c'est vraiment l'inverse. Ils ont fait perdre beaucoup et font partie de ces projets qui mettent vraiment à mal l'écosystème du logiciel libre.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.