Jehan a écrit 1667 commentaires

Oui, il ne faut pas prendre ma critique trop mal. Disons que c'est une critique dite "constructive", dans le sens où ce serait bien que la prochaine fois, une procédure de relance par email (qu'on est libre d'ignorer, mais au moins y aura eu tentative de rameuter les contributeurs de l'époque) soit mise en place pour ce types de cas particuliers.
Je suis un contributeur assez régulier de linuxfr mais je ne peux pas constamment vérifier la liste de toutes les dépêches en rédaction.

J'ai repêché une bonne partie du texte de celle-là ; il avait sauté dans des modifications de trop grande envergure.

En effet. Justement c'était une des dernières choses dont je me rappelais de cette dépêche. Un jour, je reviens sur la page de rédaction et le texte a complètement disparu. Il me semble qu'à l'époque, j'ai demandé sur le chat à la personne qui l'avait initiée ce qu'il se passait, et il me disait qu'il prévoyait une refonte, ou une découpe en plusieurs dépêches de taille plus petites (lesquelles ne sont jamais venues, il me semble), ou quelque chose comme cela. Cela empêchait donc de contribuer davantage et d'en améliorer le texte. Les contributions se sont retrouvées bloquées. J'en étais resté là personnellement.

Enfin bon, je dis cela car je vois mon nom plusieurs fois dans la dépêche, avec cette idée de micro-revue de chaque logiciel, qui je pense est toujours une bonne idée, mais j'aurais probablement édité massivement mes revues. Et là c'et vrai que j'en suis assez moyennement content. Ça m'a surpris de la voir paraître ainsi, on va dire. Un peu comme si un patch buggué, en cours et que j'ai noté comme un "proof-of-concept" à ne surtout pas intégrer tel quel, se retrouvait accepté et intégré dans un logiciel.

Mais bon, c'est pas la fin du monde non plus. :P
Et ce n'est pas à prendre comme une critique acerbe. Je précise, au cas où. ;-)

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Cf. l'interview. ;-)

Plus sérieusement ceci dit, c'est justement le moment de bosser sur GTK+3 puisqu'il est maintenant stable. Je pense que GTK+4 ne sera pas considérée comme stable avant 2 ans (si je me souviens bien de la news sur le changement de version. À moins que ce fut 3 ans?). Tu vas me dire, le temps de sortir GIMP 3, les 2 ou 3 ans seront passés. Mais en fait, j'aimerais pouvoir accélérer les rythmes de sortie drastiquement (en tous cas, si je parviens à en vivre, c'est l'un de mes buts).

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Le but me semble donc justement de laisser l'utilisateur décider ce qui est bien pour lui, totalement.

Tout à fait. Avec un mode de fenêtrage unique, on pourra faire tout ce qu'on peut déjà faire avec les 2 modes, et plus.

Exemple typique de problème: quelqu'un aime le simple fenêtrage, mais les images ne peuvent pas être détachées. On ne peut donc avoir deux images côte-à-côte. Seul le multi-fenêtrage le permet.
En fait, en y repensant, les différences entre le simple et multi fenêtrage ne sont pas si grandes et sont très artificielles. Il n'y a aucune raison d'avoir 2 modes. Il faut juste une flexibilité du fenêtrage de manière générale.

Il faut laisser le maximum de choix à l'utilisateur plutôt que de décider ce qui est bien pour lui soi, non?

Le simple et multi-fenêtrage sont justement des choix qui ont été faits pour les gens. Si on veut laisser un vrai choix, il ne faut plus de modes de fenêtrage.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

des boîtes à outils masquables (qui se transforment en "onglet" sur les côtés lorsque non utilisés et apparaissent lorsque la souris passe dessus)

Perso, j'ai toujours détesté les trucs qui "bougent tout seul", se cache ou apparaissent, etc. juste au passage de la souris. Parce que ça apparaît tout le temps quand je ne le veux pas, et c'est le meilleur moyen de cliquer là où on ne le veut pas. Par exemple, j'ai désactivé l'apparition de l'overview dans GNOME en mettant la souris en haut à gauche, car je trouve cela énervant au plus haut point.
Ensuite c'est personnel, car de toutes évidences, ce type de GUI auto-apparente est utilisé dans plein de logiciels.

Par contre, oui l'idée est intéressante, mais je choisirais donc un clic de souris sur l'onglet plutôt qu'un simple survol, personnellement.

Aussi connais-tu le raccourci Tab (équivalent du menu "Windows" > "Hide Docks") qui permet justement de cacher et afficher l'ensemble des docks au simple clic d'un bouton?

je pense que c'est le meilleur compromis entre le fenêtrage unique "à la Photoshop" et le "multi-fenêtre habituel de Gimp que certains critiquent (un peu trop).

En fait le multi-fenêtrage a son fan-club aussi. En général, ceux qui aime le multi-fenêtre ne supportent pas le simple fenêtrage. Personnellement mon but est d'arrêter la différenciation entre multi et simple fenêtrage. Il ne faut qu'un seul mode de fenêtrage qui permette de mélanger les deux logiques: rassembler les fenêtres en une, mais en séparer seulement certaines, etc.
En fait on a ça partiellement pour les docks qui peuvent déjà être séparés dans une fenêtre différente même en mode simple fenêtrage. Mais la boîte à outil ne le peut pas. Ni les images qui sont forcément en onglet.

Pour moi, cela n'a aucun sens de maintenir une différenciation totalement artificielle entre ces 2 modes.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Salut,

Je pense que mes commentaires y sont pour grand chose dans ta remarque, et je suis d'accord. Déjà à l'époque, quand j'ai fait ces commentaires, j'espérais lancer les gens à en faire plus. Le but était d'aller au delà de la description marketing qui veut tout et rien dire. Ceci dit, certains commentaires étaient déjà un peu basés sur des expériences un chouille ancienne à l'époque, alors maintenant!

Ceci dit, je pense qu'aucun de mes commentaires ne va dans le syndrome "ça plante et j'ai pas réussi à faire ça, donc pas terrible". Mes échecs sont toujours recherchés et j'ai en général vérifié la fonctionnalité en ouvrant (ou trouvant) des rapports de bugs. Quant aux plantages récurrents, pour moi c'est rédhibitoire.

Ceci dit, d'après moi, ce fut une erreur de publier cette news ainsi sans au moins revoir un minimum son contenu (ou contacter les nombreux contributeurs de l'époque pour leur proposer une revue avant publication). J'aurais probablement eu beaucoup de choses à revoir, même dans mes propres contributions de l'époque.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Oui je suis d'accord. Je trouve ça triste que la façon dont l'article est tourné, on a l'impression que seuls ces tablettes fonctionnent sous Linux. C'est malheureusement assez représentatif du développement sous Linux (plein de logiciels s'appellent Wacom-quelque-chose alors qu'ils ne sont plus Wacom-spécifique), et de la prise en charge des tablettes en règles générales (même sous Windows, ou MacOS; Wacom a simplement un quasi monopole du matos graphique).

Pour une réponse plus constructive, de ce que j'en sais, la plupart des tablettes ont une prise en charge sous Linux, mais pas forcément par défaut dans le noyau (contrairement aux Wacom, qui de par leur notoriété et aussi parce qu'y a une développeuse de l'entreprise Wacom qui contribue, ont tous les modèles — ou presque, je n'ai pas le détail — pris en charge rapidement dans le noyau Linux). Pour certaines de ces autres tablettes, il faut donc parfois installer des pilotes additionnels.
Un fil de discussion sur le forum MyPaint est assez intéressant, car en listant les tablettes qui fonctionnent, on peut voir beaucoup de cas d'usage de tablettes diverses sous Linux (attention, lire chaque post en détail, y en a pour tous les OS, c'est pas du Linux-only): https://community.mypaint.org/t/which-graphic-tablets-models-work-on-mypaint-1-2-0/269/1
On y découvre aussi pas mal de marques (certaines ne sont pas dispos en Europe ceci dit; d'autres c'est l'inverse, etc.).

Personnellement on a été beaucoup intéressé par ces autres marques, notamment pour les histoires de prix en effet (ça peut diviser par 4 ou 5 pour produit équivalent!). En plus, Wacom, malgré leur notoriété, essuie beaucoup de critiques. Il suffit de voir les avis et notes sur les sites de vente en ligne. Il n'est pas rare par exemple de voir des acheteurs renvoyer des écrans à 2000 ou 3000 € parce qu'y a des poussières sous l'écran (difficilement acceptable pour ce type de prix, en effet). Aussi la qualité colorimétrique laisserait beaucoup à désirer, c'est-à-dire que même après calibration avec les meilleures sondes du métier, la couleur est mauvaise (on ne peut confirmer ou infirmer, on n'a pas les sous pour en avoir!). En tous cas, c'est ce qu'on lit souvent en commentaire ou dans les forums. Beaucoup d'artistes disent que leur configuration habituelle est un écran Wacom pour dessiner et un bon écran autre à côté pour vérifier les couleurs. C'est assez navrant quand on voit le prix de ces écrans et le fait que leur cible est justement des graphistes! On a nous même eu quelques problèmes avec la qualité de fabrication des Wacoms. Ce problème de soudure du port USB qui doit être refait après quelques années est super classique (une recherche web remonte plein plein de résultats). Et à ce moment là, plus de garantie et un service après-vente super cher.
Je pense que leur quasi-monopole les fait peut-être un peu se reposer sur leurs lauriers. Pourquoi payer de la R&D et de la QA à essayer de faire des bons écrans/tablettes si de toutes façons, ils sont seuls sur le marché?

À côté de cela, les autres marques reçoivent de bien meilleures notes en moyenne (bien sûr l'effet moins cher joue; donc la comparaison qualitative est difficile). Mais alors qu'a Wacom de plus que les autres?
Bon déjà ils sont les seuls à avoir du très haut de gamme, en méga HiDPI, avec la petite télécommande aimantée, etc. Perso cela n'est pas absolument nécessaire pour nous. Même les boutons, beaucoup d'autres marques n'en ont pas; mais soit y a le clavier à proximité de toutes façons, soit si on travaille bien sur la GUI pour optimiser le travail avec touch+stylo, on doit pouvoir faire aussi pratique que les boutons physiques.
L'autre truc connu qu'ils sont les seuls à avoir sont les stylos sans batterie (parce qu'ils ont un brevet dessus, à ce que j'ai compris, empêchant les autres de faire de même; youhou vive l'innovation par les brevets!). Mais en lisant les commentaires nombreux ou en testant les autres stylos, on se rend compte que ce n'est pas vraiment bloquant. Les batteries ne sont pas si lourdes de nos jours, et de toutes façons, à part si vous prévoyez de ne pas dormir pendant des jours, y aura pas de problème de batterie.
Le seul truc qui a été vraiment bloquant pour nous est le "tilt". Il s'agit de la reconnaissance de l'angle du stylo (pas tous les modèles ont ça, pas les Bamboo par exemple. Mais Intuos et au dessus, si). Par exemple Aryeom typiquement va associer le tilt à la taille de la brosse et la pression à l'opacité. Je n'ai trouvé cette fonctionnalité chez aucune autre marque que Wacom (ont-il aussi un brevet sur ça?). Tous les autres n'ont que la prise en charge de la pression. De notre côté, c'est l'unique fonctionnalité qui nous empêche vraiment d'aller voir ailleurs. :-/ Une fois qu'on est habitué à utiliser toutes les fonctionnalités d'un stylo Wacom Intuos et au-dessus, il est difficile de revenir en arrière.

J'espère que ça changera bientôt, car un monopole n'est jamais une bonne chose.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Ni Gnome,

Financer GIMP ne finance pas GNOME! J'explique cela dans le premier paragraphe ici.

ni les films d'animation ne sont ma tasse de thé.

Tu n'es pas obligé de vouloir faire ou voir du film d'animation pour apprécier notre travail sur GIMP.
De mémoire, j'ai implémenté des corrections de bugs et de plantages par dizaines, notamment ai corrigé des plantages massifs sur l'utilisation de tablette graphique (avant nous, une micro-coupure de la connexion de la tablette faisait planter GIMP et MyPaint! Autant dire que ces 2 logiciels n'était pas utilisable au quotidien par des illustrateurs non masochistes…), prise en charge du standard XDG pour les fichiers de configuration, ai participé à l'intégration des brosses MyPaint, ai implémenté la peinture en symétrie, ai intégré la recherche d'action, ai lancé le travail sur les nouvelles icônes et nouveaux thèmes, ai créé le Flatpak de GIMP, fait beaucoup de correctifs et changements en rapport avec l'internationalisation (j'aime beaucoup les langues donc l'internationalisation d'application est un sujet qui me passionne) comme par exemple une vraie prise en charge des méthodes d'entrée dans l'outil texte, ai poussé à de meilleurs valeurs par défaut, ai fait des dizaines de revues de code, ai aidé à la prise en charge de webp, ai ajouté la prise en charge de la modification des options dans le système de migration des fichiers de configuration, etc.
On en fait des choses en plus de 500 commits.

Tu n'es donc pas obligé d'apprécier les films d'animation (ni voir ni faire) pour apprécier mon travail et sa portée bien au delà du sujet "animation" pure. ;-)

si en plus c'était reconnu par le fisc

Désolé. L'association LILA n'est pas une association reconnue d'intérêt général ou d'utilité publique.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Pour du 12 bits, je sais pas si y a des formats d'image qui ont cette profondeur, mais si oui, on devrait alors pouvoir exporter en 12 bits sans problème à partir d'une image de travail 16 ou 32

Le reproche qui est fait au 8bit (256 valeurs) pour la photographie ce n'est pas d'être insuffisant pour le stockage ou la visualisation en jpg, c'est de générer des "crans" dans une suite de traitement et d'obtenir un histogramme en peigne. Ce phénomène s’atténuerait à chaque augmentation de la précision, il serait moins sensible en 11bits (2048 valeurs par canal) par exemple pour le traitement, même si l'exportation finale se ferait en 8 bits.

Je sais pas trop où tu veux en venir en disant cela. Tu t'imagines bien que je sais à quoi sert de travailler en 16 ou 32 bits. D'ailleurs c'est bien pour cela que je fais la différence entre le format de travail et le format d'export dans le bout de texte que tu cites toi-même.

J'insiste sur ces valeurs intermédiaires car j'ai constaté avec la version de développement qu'en 16bits pour un fichier issu d'un 10Mpix certains traitements prennent du temps

Essaie en 32 bits, ce sera peut-être plus rapide. La seule raison de travailler en 16 bits seraient éventuellement pour des problèmes d'espace disque. Sinon autant travailler dans le format interne qui est en 32 bit.

ce n'est plus l'utilisation fluide de la 2.8, c'est vrai aussi que je n'ai pas une machine ni très récente ni haut de gamme, c'est probablement le cas aussi d'une majorité d'utilisateurs de Gimp.

Ça dépend vraiment pour quoi. Beaucoup de choses sont bien plus rapides en 2.9/2.10 qu'en 2.8 (notamment dans les effets, maintenant des opérations GEGL); mais y a aussi des choses plus lentes en effet.
Je veux aussi noter que GIMP reste un logiciel de traitement d'image pour utilisateur avancé (c'est la première cible), qui auront normalement du meilleur matériel, adapté au traitement graphique (un procédé lent par définition car ça se repose sur beaucoup de calculs). Ensuite ce n'est pas une excuse et y a évidemment des choses qu'il serait vraiment bien d'optimiser. L'amélioration ne s'arrête jamais! ;-)
Néanmoins il est bon de rappeler ce que GIMP est: un logiciel qui fait du traitement lourd et complexe. Avoir une meilleure machine si c'est une utilisation habituelle ne serait pas une mauvaise idée.

Avec des valeurs intermédiaires les inconvénients du 8bits seraient bien atténués tout en gardant une fluidité d'utilisation, et comme le 16bits ne semble pas indispensable y compris par les fabricants d'appareils photo ..

Tu veux dire proposer du 12, 14 bits, etc.? Ça ne changerait rien. Le nombre de bit ne changera pas la vitesse de calcul. Au contraire, si tu veux éviter un max les conversions, travaille en 32 bits.
Pour info, certains développeurs parmi nous veulent même se débarrasser du menu de choix des précisions pour que GIMP reste constamment dans son format optimal (32 bit float linear). La logique est que ce choix ne fait que perturber les gens qui ne comprennent pas bien comment tout cela marche, même si parfois ils croient avoir compris et vont alors faire des choix qui les desservent (et je m'inclus volontiers dans cette liste de gens, attention! Ce sont des sujets super compliqués et je veux pas te donner l'impression de te prendre ou qui que ce soit de haut. J'ai d'ailleurs récemment acquis un livre sur les couleurs pour essayer d'approfondir mes connaissances sur ce sujet). Il me semble que cette argumentation a du sens même si ce genre de choses sont encore en discussion. Personnellement je préfère que GIMP prenne ce genre de choix pour moi.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Je suis entièrement d'accord avec ppb31 ! :/

Alors soyons clair: je vous comprends tous les deux tout à fait. Si ça ne tenait qu'à moi, on aurait sorti une 2.10 en cachant toutes les fonctionnalités non finies y a plus d'un an. Mais voilà d'une, ça ne tient pas qu'à moi; de deux ça aurait été probablement une erreur quand je vois les changements de fond qui sont faits en ce moment par Mitch. On aurait sorti GIMP sans ces changements, cela aurait probablement été un très gros problème et même un boulet sur le long terme pour GIMP (car on fait attention à la compatibilité descendante, donc on doit être aussi sûr que possible de ne pas sortir avec des choses qui seront ensuite un poids à vie dans GIMP). Et c'est aussi dans ces moments-là où je suis content de pas être seul sur GIMP, du fait que ça ne tient pas qu'à moi, car je fais équipe avec plein d'autres gens compétents. :-)
C'est notre synergie qui fait de GIMP un logiciel final plutôt pas trop mal. ;-)

Et puis c'est exactement pour corriger ce problème de sortie qui prennent trop de temps qu'on allège nos règles de sorties en espérant ainsi pouvoir accélérer la sortie des majeures.

On nous fait languir et presque baisser « le soutient » (à l'instar de la garde) avec cette histoire d'un 2.9 avec du 16 bits pour les initiés… Donc à la fois oui, et non… :/

Quand je parlais que l'utilisation de la 2.9 était possible, ce n'était nullement pour dire que ça existe et que c'est sorti, donc qu'il faut simplement l'utiliser. J'ai d'ailleurs bien mis en garde sur les problèmes possibles. J'ai juste donné une alternative potentielle pour des utilisateurs avancés (car y en a pas mal sur linuxfr), au cas où ça intéresse de savoir. On est nombreux à utiliser la 2.9 en "production".
Mais oui je me rends bien compte que ce n'est pas la même chose qu'une stable et je suis bien conscient du problème de sortie. :-/

Et finalement, si tout cela ne tenait également qu'au financement ?

Tout à fait, c'est vraisemblablement le fond du problème. D'ailleurs merci encore pour y participer. ;-)
GIMP n'est pas une entreprise avec des délais à tenir, etc. C'est un projet communautaire essentiellement et on ne peut par forcer un bénévole à se dépêcher pour sortir une version dans les temps. Parallèlement nous ne sommes que 2 développeurs à vouloir essayer de vivre du logiciel libre et donc du développement de GEGL ou GIMP et le succès est mitigé pour le moment.

Donc je dirais que le fond du problème, c'est que d'un côté, y a l'image que les gens ont de GIMP (ils imaginent un gros projet avec des centaines de gars dont pas mal bossent dessus à temps plein, mais certains "saboteraient" le projet de l'intérieur) et la réalité, les faits (quelques péquins qui font ce qu'ils peuvent, la plupart en bénévoles sur leur temps libres; certains essaient de se financer, mais on n'y est pas encore).
Idéalement on arriverait à aligner la réalité à l'image (sans les parties "sabotage").

Parce que même si je comprends tout à fait ce que vous dites, ppb31 et toi, et je vois complètement votre "point de vue extérieur (utilisateur lambda non développeur)" (en reprenant les mots de ppb31), ben y a la réalité qui intervient: y a des limites à ce que quelques personnes seules dans leur coin peuvent faire. Et même si on aimerait en faire plus en se faisant payer (dans mon cas), en attendant on n'en a pas les moyens.

Enfin voilà, on fait ce qu'on peut. On espère que ça suffira et que vous apprécierez quand même!

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Justement à ce propos, il serait bien d'en savoir un peu plus sur les modes de donations (flattr ou autres) ; tout n'est pas très clair ?!

Pour GIMP? Alors déjà, comme tu le notes, oui nos fonds GIMP sont gérés par la fondation GNOME. C'est un peu comme si on avait un compte chez GNOME (et si je ne me trompe pas, ils prennent un pourcentage pour payer l'administratif supplémentaire que ça leur donne). La raison, c'est que GIMP en soi n'a pas d'entité juridique propre. C'est ce qu'on appellerait une association de fait dans les pays francophones (au moins en France et Belgique). Mais note bien que cet argent donné à GIMP va vraiment à GIMP. GNOME garde une comptabilité distincte et cet argent donné pour nous n'est absolument pas utilisé par GNOME. Il est juste gardé par eux en notre nom.

Ensuite à quoi sert cet argent? Il sert principalement à réunir les développeurs régulièrement, dans des évènements comme Wilber Week ou Libre Graphics Meeting. Cela ne paye pas directement du développement. Mais comme Pierre Jarillon le note dans un commentaire, les rencontres de développeurs restent très importantes et ne sont pas à négliger. Je ne veux surtout pas donner l'impression de vouloir minimiser cela et si c'est là où tu veux donner, merci!

Pour soutenir plus directement du développement, tu peux donner mensuellement directement à 2 développeurs seulement (c'est expliqué sur la page officielle de donation de GIMP), c'est à dire les 2 seuls développeurs en lien avec GIMP qui essaient de vivre du logiciel libre: Øyvind Kolås, le mainteneur de GEGL, et moi-même (second plus gros contributeur de GIMP après Michael Natterer, mainteneur de GIMP). Øyvind fait donc des trucs plutôt côté moteur graphique; moi je travaille plus sur l'interface graphique, l'utilisabilité, etc. J'ai aussi énormément travaillé sur la stabilité. C'est simple quand on a commencé à utiliser GIMP, en 2012, il plantait pour un oui ou pour un non. C'est d'ailleurs comme ça que j'ai vraiment commencé à contribuer (parce que j'ai commencé à corriger des bugs, puis de plus en plus) et depuis j'ai corrigé pas mal de crashs et bugs et j'aime à penser que de nos jours, on est pour beaucoup dans sa stabilité (c'est simple, on l'utilise des heures durant, tous les jours, et ça marche). Les contributions d'Øyvind et moi-même sont tout aussi essentielles et complémentaires; c'est à toi de voir ce que tu préfères financer.
Bon le financement d'Øyvind marche bien mieux que le notre, j'imagine que c'est beaucoup pour le fait que c'est parce qu'il est dans le projet depuis 13 ans, alors que nous seulement 5 ans. Et aussi qu'on est nul en marketing. Sûrement aussi que le double côté film + développement nous dessert car certaines personnes ne semblent pas vouloir payer pour un film d'animation, juste du développement logiciel. Mais pour moi, c'est essentiel, car je ne coderais pas sur GIMP autant si ça ne nous servait pas justement au quotidien. Nous sommes des contributeurs car c'est notre outil quotidien. C'est donc indissociable pour moi.

Voilà tu sais tout. Tu as donc 3 cibles de financement: le projet GIMP core (tu paieras alors tout le côté communautaire), Øyvind si tu veux financer du développement sur GEGL, et ZeMarmot pour financer du développement sur GIMP même, à un peu tous les niveaux. On peut être financé par Tipeee en euro, patreon en dollar, ou comme noté dans un autre commentaire, tu peux donner directement à l'association LILA qui est l'organisme chapeautant le projet ZeMarmot, évitant ainsi des frais de plateforme (par exemple avec un virement bancaire récurrent), avec un message expliquant que cette donation est pour le développement sur GIMP principalement.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Donc GIMP depuis 98, avec pas mal d'espoir de rattraper l’éternel Photoshop.

Juste pour être sûr qu'on se comprend, notre objectif n'est pas de "rattraper" Photoshop, ni de le copier. On fait notre propre logiciel de création graphique, aussi bien qu'on puisse et en Libre. Le but de GIMP n'a jamais été d'être un clone. Je ne dis pas que c'est ce que tu voulais dire. C'est pas très clair. Mais au cas où, je le précise car c'est un commentaire qu'on a régulièrement. :-)

Les soucis ne sont pas les fonctionnalités mais le flous éternel autour 12 et 16 bits natif. Les soucis ne sont pas les fonctionnalités mais le flous éternel autour 12 et 16 bits natif.

Il n'y a pas vraiment de flou, c'est très simple: en 2.8, y a prise en charge de 8 bits seulement, et en 2.10 y aura prise en charge 16 et 32 bits pour l'image de travail. :-)
Pour du 12 bits, je sais pas si y a des formats d'image qui ont cette profondeur, mais si oui, on devrait alors pouvoir exporter en 12 bits sans problème à partir d'une image de travail 16 ou 32.

Ensuite comme quelqu'un le note, la version de développement (estampillée 2.9) est déjà très fonctionnelle et stable au quotidien et te permettrait déjà de travailler des images en 16/32 bits. On utilise essentiellement la version 2.9 depuis plus d'un an pour le projet ZeMarmot. Maintenant soyons clair que c'est une version de développement et il peut y avoir de la casse. Pour une utilisation pro de la version de développement, il convient d'être tout de même un utilisateur éclairé au cas où les choses se passent mal. On fait gaffe, mais on ne peut absolument pas assurer une stabilité parfaite entre 2 versions de développement. Mais ça reste faisable. On le fait bien (mais évidemment en tant que développeur de GIMP, je suis un utilisateur assez éclairé aussi!).

Dractable, Krita, Blender ex.. avancent à pas de géants avec des moyens pas forcement plus important.

Vu de notre côté, on avance aussi bien, mais c'est moins visible car on ne sort pas de version avec nos avancées. Et donc oui, vu de l'extérieur, ça n'a pas l'air d'avancer et c'est frustrant, je le comprends tout à fait. D'où le problème de versionnement qu'on essaie de résoudre et dont je parle dans cette news.

Ensuite "des moyens pas forcément plus importants"… alors Darktable oui, c'est le seul de la liste où c'est vrai. Mais Blender ont leur fondation derrière qui a maintenant des moyens de plus en plus conséquents (pas encore gigantesque, mais ils font quand même des crowdfunding à plusieurs centaines de milliers d'euros, et touchent du financement européen du même ordre de grandeur, ils ont leur cloud avec abonnement, etc.), et Krita ont créé leur propre fondation et font du marketing à fond, des crowdfundings, etc.

GIMP reste essentiellement communautaire. Néanmoins il y a quelques développeurs, notamment moi, qui essayons justement de nous donner des moyens financiers. Le jour où notre financement Tipeee ou Patreon sera de quelques milliers par mois, alors oui on pourra commencer à dire qu'on commence à avoir des moyens pour développer GIMP professionnellement. À ce jour, le développement de GIMP est financé avec des cacahuètes.

Donc oui les numéros de version compte ça fait plus de 5 ans que le 3 est attendu

Qui attend le 3? On n'a même pas vraiment commencé à travailler dessus. Bien sûr, on a quelques commits de temps en temps, mais c'est minime. On maintient la branche juste assez pour qu'elle compile avec GTK+3. Et de temps en temps, on fait quelques trucs, mais c'est pas assez pour dire qu'y a du dév actif.
Le développement actif est quasi essentiellement sur la version 2.10. C'est là où les choses se passent et la seule version à attendre pour l'instant.

la 2.10 va encor donner l'impression que l'on avance à tous petit pas

Je ne comprends pas, le problème est juste une histoire de numéro? Chez GIMP, le second nombre indique une sortie majeure. 2.10 sera autant une majeure que 3.0. De même que 2.8 était une sortie majeure.
Bonne chose, mauvaise chose, je ne sais pas. Peut-être que cela changera un jour. J'ai l'impression qu'historiquement, cela suit simplement les versions de GTK+. Avec l'accélération du versionnement de GTK+, ça voudrait d'ailleurs dire que les versions de GIMP risquent d'accélérer aussi beaucoup après GIMP 3. On verra.

si GEGL est le moteur complet par défaut avec effectivement une prise en charge natif du 16 b et + politiquement ça ferrait dans les chaumières OUF !!!

Ben oui, GEGL a la prise en charge du 16 bit (même 32 bit, qui est maintenant le format natif de GIMP). C'est ce qu'on dit. Je pense que tu n'as simplement pas suivi les nouvelles de GIMP depuis… 4 ou 5 ans? ;-)
Bon bien sûr, ça implique de suivre les news de dév, puisqu'il n'y a effectivement pas de sortie de version stable. Donc je comprends l'incompréhension, pas de problème.

mais si les version avancent à tous petit pas ce la parais suspect à plus d'un

Qu'est-ce qui paraît suspect? Que GIMP est un logiciel libre développé à 99.999% par du bénévolat dans le temps libre, que personne ne bosse à temps plein, payé, et qu'on est pas un business? J'ai du mal à comprendre où tu veux en venir.

Personnellement j'aimerais bien en vivre et pouvoir faire cela (développer GIMP) à temps plein. Mais pour cela, il faut nous soutenir financièrement sur les liens du projet ZeMarmot donnés juste au dessus. Parce qu'autrement, nous dire que ça paraît "suspect" que ça avance pas plus vite, ben ça me fait juste mal au cœur. ;-(

À l'heure actuelle mon état d'esprit est le suivant: on finit notre épisode cette année et si on a pas atteint un financement acceptable pour vivre décemment (à l'heure actuelle, le financement ne paye même pas un loyer, surtout qu'on fait tout dans les règles et qu'y a des charges sociales en salaire, etc. C'est pour te dire que si y a une définition de la précarité, je rentre dedans), ben on commencera à chercher des alternatives et mon implication à GIMP en souffrira probablement drastiquement malheureusement. Et il n'y aura rien de "suspect" au fait que la rapidité de développement de GIMP diminuera beaucoup plus puisque je suis le second plus gros contributeur depuis plusieurs années. Ensuite il reste Mitch, qui fait 2 fois plus de commits que moi en ayant son propre business. Je sais pas vraiment comment il fait (enfin si, je sais; il contribue à GIMP depuis 20 ans et connaît son code bien mieux que moi, et aussi il a beaucoup plus d'expérience de développement en général que moi). Mais il est entièrement bénévole alors lui reprocher aussi de pas aller assez vite serait tout aussi aberrant.
Voilà j'espère que ça te donne une autre perspective sur le développement de GIMP et les "moyens" (assez imaginaires) que tu sembles imaginer derrière son développement.

Donc je souhaite bon courage à toutes les équipes de développent, je continuerai à promouvoir se formidable logiciel.
Bonne et belle journée à tous le monde

Merci. En tous cas, tu as l'air de bonne foi et amical (contrairement à d'autres cas; malheureusement contribuer à GIMP, c'est s'exposer à pas mal d'insultes et de haine et je suis pas toujours bien taillé pour cela; mais je travaille pour me durcir le caractère et être moins sensible à la méchanceté, car des fois ça a été dur). Mais je te conseillerais de faire attention dans ton choix de mots car ils peuvent être assez mal pris. Surtout quand justement je cherche à en vivre mais n'y arrive pas (j'ai parfois l'impression de faire des appels au crowdfunding dans le vide).
J'espère que mon explication t'aura un peu éclairé sur GIMP et son développement. :-)

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Quelle serait la différence entre version mineure et majeure dans ce cas si les mineures ont de nouvelles fonctionnalités ?

Pour l'instant il y a quand même de grandes différences. En tous cas 2.10 avec un changement profond du moteur graphique (certes déjà en cours, mais jusqu'alors GEGL n'était utilisé que pour des trucs superficiels, maintenant c'est vraiment partout); puis 3.0 avec le passage à GTK+3, ce qui va débloquer aussi beaucoup de choses normalement, avec prise en charge améliorée des tablettes, amélioration des thèmes, route vers HiDPI, etc. Plein de choses merveilleuses et féériques qui nous sont promises. Ensuite je suis persuadé que tout ne sera pas magique et qu'il faudra travailler un peu pour y arriver, mais au moins on sera sur le chemin. Pour l'instant avec GTK+2, on est un peu contre un mur.

Mais oui peut-être qu'à terme, la différence entre une mineure et une majeure pourra s'amenuiser. Est-ce un mal? Je ne pense pas. Même le noyau Linux n'a pas vraiment de différence entre ses majeures et ses mineures. On le voit bien dans les emails de Linus pour décider les passages de majeures, en général il l'accompagne d'une blague, genre "j'ai plus assez de doigts pour compter". Et voilà on est passé sur une majeure version 4.x du noyau sur un coup de tête et un sondage sans aucune autre logique que "est-ce que vous avez envie ou pas qu'on passe à v4?"
Est-ce un problème? Je ne pense pas vraiment, surtout si ça permet de rendre le développement plus énergique (on peut sans cesse créer des nouvelles fonctionnalités attrayantes!).

Ce serait un système à la Firefox ou à la Libreoffice ?

Firefox, oui. Je ne sais pas quel système utilise LO, mais si c'est comme Firefox, alors oui aussi.

La seule chose que je voudrais faire différemment que Firefox, c'est de garder une promesse de stabilité de l'API un certain temps. Et pour ça, les versions à point restent un bon moyen simple pour reconnaître la stabilité, contrairement à un simple entier. Firefox, de ce que je comprends, c'est qu'ils cassent l'API sur un coup de tête un peu n'importe quand, et que pour un dév de plugin, il faut vraiment se tenir à jour à chaque version et lire le changelog en détail. Avec une promesse de stabilité basé sur un numéro de version, c'est facile: le premier chiffre est le même, donc mon plugin continuera à fonctionner.
Je pense que cela reste un très bon intérêt aux numéros à point.

Ensuite, je me réserve le droit de changer d'avis dans un sens ou l'autre. ;-)

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Salut !

Je ne m’attendais pas à ce que ça passe en première page. Sinon, j’aurais mieux écrit mon journal…

Dans ce cas, je tiens à préciser que lorsque je parle de « résumé des points importants », ce sont des points importants « personnels ". D’autres contributeurs ont aussi bossé sur des choses très importantes. Notamment, il y a eu un travail (qui est toujours en cours) très important sur la base de Linear is the new black par Pippin, Mitch et les contributeurs GEGL. Ce travail se base sur le principe que les images en 32 bits flottants en lumière linéaire sont le format de travail idéal.

Aussi, les modes de calques (et plein d’autres fonctionnalités) ont été revus et l’interface utilisateur mise à jour par Mitch, en se basant sur le travail précédent. Bien sûr, comme la compatibilité descendante est un besoin majeur pour nous, les anciennes implémentations de modes sont toutes présentes à vie et utilisées en chargeant de vieux documents (de sorte qu’un ancien XCF aura toujours le même rendu, même dans 10 ans)¹ mais l’interface utilisateur est faite de telle sorte que les nouveaux documents utiliseront les nouvelles implémentations (bien qu’il restera possible de trifouiller pour retrouver les anciennes). Je ne veux pas trop parler de cela en détail, car j’ai peur de dire des bêtises.

Un peintre et contributeur (de rapports de bogues, d’idées, de propositions d’amélioration…), Americo Gobbo, fait d’ailleurs pas mal de recherche sur les nouvelles possibilités de GIMP en la matière, surtout les applications directes à la peinture numérique grâce aux nouveaux modes de calques. Notamment, il peint en texturant ses brosses. Voir ses expérimentations, par exemple ça ou encore ceci ou cela… Il fait aussi quelques vidéos intéressantes sur le sujet.
Il n’était pas présent à Wilber Week (il sera à LGM, je l’ai invité au nom de GIMP car son travail est intéressant et important pour améliorer GIMP et son interface graphique), mais ses expérimentations de brosses et textures se basent directement sur des changements de code de janvier.

Lands Improvisations, par Americo Gobbo (expérimentations d’ajout de texture sur les brosses avec les modes de blend/composition)

Et c’est sans parler du travail de Elle Stone (qui n’était pas présente non plus mais est souvent sur IRC), une experte des couleurs et algorithmes, l’une des plus grosses critiques de GIMP, mais en même temps une contributrice majeure en revue de code et d’algorithme ultra‐poussé (elle n’est pas développeuse, mais elle lit le code à l’occasion et fait des correctifs algorithmiques), tests de versions de développement au pixel près, pointage de problème (on ne peut rien cacher sous le tapis avec elle !) avec force insistance, etc. Je ne comprends pas tout ce qu’elle dit car elle est très calée, mais ses revues sont de grande valeur.

On a aussi eu un contributeur (qui ne veut pas voir son nom cité) dont le trip est d’implémenter des algorithmes de recherche, et il a fait pas mal de contributions sur GEGL et aussi sur GIMP lors du Wilber Week. Il fait d’ailleurs du code de très bonne qualité. On espère qu’il restera avec nous. :-)

Il s’est donc passé pas mal de choses pendant et autour de cette Wilber Week. On était plusieurs développeurs et contributeurs sur place (et d’autres qui ne pouvaient venir, genre Ell, un contributeur majeur de ces derniers mois). Voilà, je voulais donc revenir un peu sur mon impression de compte‐rendu, qui a l’air bien terne si jamais on croit que c’est le compte‐rendu complet de Wilber Week : ça ne l’est pas ! C’était un compte‐rendu tout à fait personnel. D’ailleurs, on prévoit aussi un compte‐rendu plus global de l’évènement sur gimp.org.

C’est personnel dans le sens : je m’y suis impliqué. Pas dans le sens « le reste m’intéresse pas », bien entendu. :P
C’est super excitant ce que d’autres font en parallèle. C’est ça aussi qui est cool : travailler dans une équipe hétéroclite qui bosse sur plein de trucs différents tous très intéressants ! Franchement, je n’aimerais pas donner l’impression que Wilber Week, c’était juste pour faire un paquet Flatpak et discuter du changement de logique de version à dix personnes pendant une semaine (aussi intéressants que soient ces deux items !). Cette dépêche a peut‐être été promue un peu vite. Si j’avais su… Il aurait fallu la compléter un peu avant. :-)
Mais merci quand même ! ;-)

[1] Pour la petite histoire, sous Photoshop, pa exemple, certains fichiers identiques peuvent apparaître différemment selon qu’ils sont ouverts avec CS5 ou CS6. C’est un problème assez sérieux pour des gens qui travailleraient en équipe avec versions disparates (problème classique dans le logiciel propriétaire, car mettre à jour signifie payer une mise à jour de licence) ou simplement pour réutiliser ses vieux documents.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Je confirme, ZeMarmot a reçu un soutien très généreux de GNU Computer. Merci beaucoup! :-)

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Par contre une version mineure n'en est plus une si des nouveautés apparaissent.

Pourquoi? C'est qu'une question de définition. Hormis le fait qu'historiquement beaucoup de projets (dont GIMP) suivaient effectivement cette définition, tu peux tout à fait redéfinir, et dire par exemple qu'une version majeure, c'est quand tu changes quelque chose de… majeur justement (comme le moteur graphique, cas de GIMP 2.10, ou le toolkit graphique, cas de GIMP 3), et une mineure, c'est le reste.

D'ailleurs, si on souhaite se rapprocher du "versionnement sémantique", utilisé massivement, surtout pour des bibliothèques (peu les logiciels finaux) libres, tu peux tout à fait rajouter des fonctionnalités dans une mineure. Ce qui importe, c'est de le faire en restant compatible avec l'existant (tant qu'on ne change pas de version majeure). GIMP fournissant aussi une API (pour les plugins), c'est le cas, ça l'a toujours été et ne changera pas: les plugins existants resteront compatibles (d'ailleurs le numéro majeur considéré pour la libgimp est le premier, comme habituellement en semver, alors que pour le logiciel GIMP, c'est le second qui fait la majeure; donc notre API est encore plus conservative que le logiciel graphique, et c'est bien).

Personnellement le type de sortie continue que je vois, on ne ferait simplement plus de différence entre majeure et mineure. Simplement on pourrait sortir sans arrêt des mises-à-jour, que ce soit avec juste un correctif, ou avec une nouvelle fonctionnalité. Comme beaucoup de logiciels font de nos jours (notamment Firefox). Je sais que ça a fait jaser à l'époque de Firefox et que les gens ont cru que c'était juste un coup marketing (pour avoir le numéro de version le plus haut possible), mais je pense que cela pourrait vraiment libérer le développement. Pouvoir sortir des nouveautés sans arrêt, dès qu'elles sont vraiment finies, c'est super. Pourquoi s'encombrer avec des règles artificielles?
Bien sûr, il faudra garder des règles de compatibilité pour les plugins tout de même. Par exemple sur Firefox justement, les problèmes sont nombreux et beaucoup d'entre nous perdent des plugins régulièrement aux mises-à-jour. ;-( Un peu plus de stabilité serait bienvenu.
Donc en un sens, on peut garder les concepts de majeures et mineures mais limiter cela aux APIs ou aux changements graphiques vraiment profonds. Et c'est un peu la direction que nous prenons avec GIMP.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Je n'ai pas regardé plus loin, mais juste en vidant mes cookies, je peux voter deux fois :/

Ah. Je n'ai pas testé. On avait vu qu'on ne pouvait pas voter avec un second ordinateur dans le même appart (donc même IP) donc j'ai supposé que ça se base vraiment sur l'IP. Mais si tu dis que juste vider ses cookies suffit, alors c'est vraiment programmé n'importe comment.
Déjà que même de base la logique d'un vote par IP n'est pas très bonne, déjà parce que ça interdit à plusieurs personnes de voter si derrière la même IP (typiquement la famille derrière une même box, ou ses collègues au boulot), mais surtout car — comme tu l'indiques — ça rend le bourrage facile. Beaucoup de fournisseurs d'accès ne garantissent pas d'IP stable, en particulier avec des connexions 3G.

(et vu leur remontée fulgurante depuis hier, je soupçonne assez fortement les deux premiers actuels)

Le second, c'est nous. Et si on est second (et on a même été premier pendant un moment), c'est grâce à linuxfr! Merci Linuxfr. :-)
On était genre 5ème, puis j'ai publié ce journal, et en une demi journée, on a passé tout le monde (c'est simple, j'ai publié en début de soirée, le lendemain au réveil, on était premier). Ça a continué sur la lancée pendant une bonne journée ou plus, et à un moment on a même eu plus de 200 votes d'écart avec le second! Mais là ça s'est calmé; les votes pour GIMP Motion augmentent encore régulièrement, mais plus très vite. :-/
Donc notre remontée fulgurante, c'est pas du bourrage, c'est du linuxfrage (le site avec un lectorat de libriste si grand qu'il est connu pour faire des DDOS involontaires de petits serveurs lorsque certains liens sont si intéressants que tout le monde clique!). ;-)

Le premier, on s'est posé la question, en effet. Surtout que hier soir, quand ils nous ont dépassé, on a lancé des messages sur les réseaux sociaux pour activer nos soutiens; lorsqu'on a difficilement grimpé à leur niveau et dépassé de quelques votes, ils ont soudainement fait un bon de plus de 100 votes en genre 30 minutes. Ça m'a paru suspect.
Ensuite je veux pas médire sans savoir. Ils ont peut-être une communauté très vaste aussi et savent bien faire jouer leur communication. Apparemment ils ont une "app" de téléphone et poussent les utilisateurs à voter en promettant de débloquer des fonctionnalités lorsqu'ils atteignent des paliers de vote.
Au final, même s'ils utilisent vraiment des techniques de changement d'IP (mais j'en sais rien), ce n'est certes pas fair-play, mais peut-être pas contre les règles. Le règlement n'indique pas que les votes doivent être limités à un par personne physique. Il dit juste:

limité à un seul vote par adresse IP

Nous on va continuer à la jouer cool, ne serait-ce que parce que j'ai pas que ça à faire que de piper les dés. On va se contenter de lancer quelques appels comme on l'a fait sur linuxfr et espérer que la communauté du libre saura être plus importante en nombre. Pour moi, LinuxFR a encore fait (il y a 2 jours, avec le nombre de vote impressionnant qu'on a eu) une démonstration épatante du pouvoir de la communauté du logiciel libre… et en plus seulement à l'échelle francophone!

Le premier gagne automatiquement 1500€ ?

Oui. Par contre, le gagnant du prix du public est "disqualifié" automatiquement des prix du jury (ce que je trouvais totalement idiot au début, soit dit en passant car le grand prix est de 5000 €! Mais maintenant que je me rends compte que c'est si simple de "bourrer les urnes", c'est peut-être la raison).

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Oui y a encore plein de trucs avec lesquels je suis pas tout à fait heureux. En plus le fait d'être bloqué sur GTK+2 n'aide pas. J'ai hâte qu'on passe à GIMP 3 pour profiter de certaines nouvelles widgets.

Ceci dit, quand tu parles de "manipulation de fenêtres", j'imagine que tu parles des divisions en panneaux que l'on peut redimensionner en cliquant-déplaçant la bordure. Peut-être que ça se voit pas bien en vidéo, mais c'est en fait assez simple et intuitif car ce type de GUI est très classique. En plus j'ai fait ce screencast juste avant d'uploader, sur mon ordi portable qui a un écran assez restreint. Avec un grand écran, voire plusieurs écrans (configuration classique chez les graphistes et animateurs), ce type de problème se poserait beaucoup moins.
Mais ça n'empêche pas que plein de choses doivent être améliorés quand même. :-)

Pour le moment, j'essaie de me concentrer surtout sur le cœur de certaines fonctionnalités, et accélérer les chargements, etc. (ça se voit pas dans la vidéo, car c'est pas le but; le traitement d'image pour la vidéo, c'est pas facile pour obtenir un bon compromis entre une prévisualisation fluide, ce qui veut en général dire qu'il y a eu du préchargement, et une GUI qui soit réactive malgré le dit-préchargement).

Donc bon, oui y a du boulot! Par conséquent merci pour avoir cliqué! Si on gagne, ça me donnera du temps pour pouvoir travailler dessus. :-)

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Je ne peux pas te donner de réponse avisée sur ton problème exact. Par contre, dans tous les cas : sauvegarde tes données. Quand tu fais ce genre de manips, il ne faut jamais supposer qu'il n'y aura aucun problème. voilà pour mon conseil du jour. ;)

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Très bon (ou mauvais) code qui sera juger… par des développeurs (dont c'est le métier)

Dont c'est le métier? Pas forcément. On ne regarde que la qualité du code, pas le CV. La personne pourrait être éboueur de profession ou pilote de course qu'on ne le saurait même pas. Si le code est bon, on l'intègre, sinon on propose des améliorations possibles pour intégration ultérieure potentielle (on appelle cela de la "revue de code" et on en reçoit tous, même les mainteneurs des plus gros projets demandent aux autres qu'ils revoient leur code).

Ça me va si celui qui me dit ça est à même de l'évaluer
…
(vous par un développeur, nous par un designer)

Donc un projet qui n'a aucun designer ne pourra alors jamais en avoir puisque les designers ne pourront jamais être jugé par un designer déjà présent? Là y a comme un problème de poule et d'œuf, non?

ça peut être des devs s'ils savent

C'est déjà mieux. Pourtant tu continues à faire bien trop de distinction, à classer les gens et les mettre dans une case ('dév', 'designer'…), à confondre qualité et profession/métier (comme je l'ai dit et je le répète ça joue, bien entendu, mais c'est loin d'être du 100%)… Et surtout tu dis ça, mais clairement en vrai tu juges sans savoir si ce sont des gens qui "savent". As-tu fait un background check sur l'ensemble des gens que tu as cité et moqué (pour ne pas dire craché dessus, disons le clairement) dans ton post de blog? J'ai quand même l'impression que tu me classeras direct dans la catégorie "sale développeur qui y comprend rien" si on a affaire sur un projet. Or j'ai fait de l'ergonomie à l'université, avec des projets où j'ai fait des tests utilisateurs, etc. Ensuite je n'ai pas poursuivi du tout dans ce domaine et suis le premier à dire que je suis loin d'un expert design ou ergonome. Mais ça n'en reste pas moins un sujet qui m'intéresse, je lis sur le sujet, je veux en savoir plus, etc. Alors dans quelle catégorie je rentre? Suis-je quand même un "dév qui sait"?
C'est une question bien rhétorique car je ne m'attends pas à ce que tu me répondes direct. Enfin… j'espère que tu n'allais pas le faire. Ce serait bien présomptueux. Et c'est là mon point d'argument: tu ne peux pas avoir d'avis sur chaque contributeur à un projet avec juste quelques messages en arrivant sur un nouveau projet. Et ce que ce soit pour la programmation ou le design.

Je pense que tu accepterais moins ces "refus de patches" et de contributions si elles étaient repoussées par des non devs sur des prétextes fallacieux. "Tenez j'ai codé un système pour améliorer la sécu" "lol non on en veut pas et on aime pas ton indentation".

L'indentation dans le code est importante et on intègre les problèmes d'indentation dans la revue de code. On appelle cela le "style" du code, il doit rester cohérent dans l'ensemble du code pour que celui-ci reste lisible et compréhensible. Ce n'est absolument pas une sorte de réaction de kikoolol comme tu sembles le penser, est même potentiellement insultant (comme beaucoup de choses que tu sembles penser des développeurs) et montre une incompréhension du travail de développeur.
Bien sûr si c'est l'unique problème, on pourrait simplement intégrer le patch et corriger l'indentation ensuite nous-même, ce qu'on fait parfois. Mais c'est important de le dire et de demander au contributeur de corriger lui-même son indentation. Si on veut garder les contributeurs et les pousser à continuer, ils doivent savoir quelles sont nos règles pour améliorer leurs patchs au fur et à mesure. En plus ce genre de choses sont très bien prises par les contributeurs justement. Tout revue de code est en générale bien reçue (en tous cas par les développeurs qui n'ont pas un égo surdimensionné, qui veulent vraiment aider, qui veulent aussi apprendre parfois, etc.) et montre bien qu'on s'intéresse au patch et qu'on veut l'intégrer.
Donc très mauvais exemple. Et ça montre que tu ne comprends pas du tout ce que font les développeurs encore une fois.

Pour te donner un exemple plus artistique (car il se trouve que j'ai un certain bagage dans le milieu artistique, moi-même déjà, mais aussi en collaboration technique avec des artistes). C'est un peu comme si un dessinateur utilisait son propre style dans un film d'animation au lieu d'utiliser le style du film (donc y aurait un perso différent stylistiquement des autres dans la scène). Tu peux transposer ça avec des arts plastiques où plusieurs artistes travaillent sur une même œuvre, sur la musique aussi avec des musiciens qui jouent ensemble, etc. Bien sûr, je parle pas d'œuvres où mélanger des styles très différent est justement le but (type cadavre exquis!), mais de trucs plus classiques. Il y a un moment où l'harmonisation du style des intervenants est tout aussi important que la compétence intrinsèque de chacun si on veut que l'œuvre finale soit belle. [*] On appelle cela du travail d'équipe!

Sur ces belles paroles, je pense que ce sera mon dernier message. J'ai pas l'impression que la discussion va vraiment évoluer et surtout j'ai le sentiment que tu as juste une dent contre les développeurs de logiciel libre, voire contre le logiciel libre dans son ensemble (à la façon dont tu as l'air d'attaquer quasi chaque projet).
C'est vraiment dommage car on a en effet vraiment besoin de designers. Ce pourquoi j'essayais de donner mon avis sur la question pour voir si on pouvait amender les choses. J'ai pas l'impression. :-/

[*] P.S.: après réflexion, mon parallèle n'est pas idéal car l'indentation n'influe pas directement sur le logiciel final (contrairement au style d'un dessin pour une œuvre dessinée). L'indentation en programmation est plus une histoire d'organisation. Un meilleur parallèle serait alors simplement des gens qui travaillent ensemble mais quelqu'un qui refuserait de suivre l'organisation du groupe. Genre il range des dossiers par date alors que tout le monde a décidé de ranger par ordre alphabétique (car c'est son style d'organisation, il veut pas qu'on lui impose un autre, vous comprenez!). Bien sûr, on peut quand même arriver à un travail acceptable, mais cela met clairement des bâtons dans les roues de la dynamique globale.
Je garde quand même l'autre exemple car plus artistique et te parlera peut-être plus, et je pense que c'est pas si différent au final, car la conclusion est la même: il s'agit au final de travail d'équipe et il faut savoir parfois faire des concessions sur son style le temps d'un projet.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Hmm… J'ai répondu sur le blog par correction, mais je me rends compte que la vraie discussion se passe apparemment ici. Même l'auteur d'origine ne semble plus répondre qu'ici. Allez hop! Je recopie ma réponse (rédigée en s'adressant à ce designer).

---

Bonjour,

Ce billet dit des choses justes, mais aussi d'autres qui me font peur, notamment après avoir vécu une mauvaise expérience avec un designer dans le libre justement.

Globalement je suis totalement d'accord avec le fait que l'on doit laisser le designer bosser et qu'il est le boss dans son domaine. Il est celui qui doit avoir le dernier mot dans ce qu'il fait.

Par contre, il est normal qu'il y ait une étape intermédiaire entre "inconnu au bataillon" et "mainteneur de tout l'aspect design du logiciel". C'est la même chose pour les développeurs. Dans beaucoup de logiciels libres, si un contributeur fait un très bon code dans une zone que personne n'a touché depuis des lustres, non seulement ce code sera accepté et intégré au logiciel, mais en plus si ce contributeur reste dans le coin et continue à contribuer, il sera considéré comme le "mainteneur" de ce bout de code et celui qui décide. Mais la condition, c'est bien: "si un contributeur fait un très bon code".
Parce que du mauvais code, y en a aussi plein (développeur pro ou pas), et si un développeur se ramène dans un projet avec comme intro "J’ai 11 ans d’expérience dans le développement, j’ai réglé des problématiques conceptuelles sur des sites et des projets stratégiques gargantuesques impliquant des dizaines de personnes juste pour la partie logicielle, donc chill, je peux gérer ton projet", ben ça me fera ni chaud ni froid. Et la réponse sera la même que pour un autre: ok on accepte les patchs, on attend le tien.
Note que j'ai croisé des professionnels qui ont des années d'expérience et dont les compétences m'impressionnent absolument pas, tout comme j'ai croisé des étudiants ou très jeunes développeurs qui trouvaient vraiment des solutions extrêmement pertinentes et qualitatives sur des problèmes très complexes. L'expérience, c'est important, mais ce n'est pas tout. Et ceci s'applique quel que soit le métier.

Donc oui, je suis totalement d'accord sur le fait qu'il faut laisser travailler et avoir le dernier mot au designer, mais il faut d'abord que ce dernier passe l'étape où on l'accepte comme un designer du projet. Tu ne peux absolument pas critiquer la décision de l'équipe SPIP comme tu le fais, par exemple. Note que je l'aime bien cette proposition de design, mais bon voilà, je contribue/décide pas chez SPIP. J'ai aussi eu des patchs refusés dans ma vie dans divers projets. Souvent j'y ai passé des heures et des heures. Mais voilà, c'est la vie. Je vais pas en faire une sorte de conclusion générale (et négative) sur le processus de développement dans le logiciel libre, ni me faire une opinion générale (et très négative aussi) sur une équipe de gens que je ne connais simplement pas, encore moins aller la diffuser dans un post.

Il y a aussi cette dualité stricte entre designer et développeur, que je n'aime pas. Comme je disais, je suis tout à fait d'accord que le designer doit décider des choses du design. Mais cela ne doit pas l'empêcher de pouvoir écouter les développeurs. Un développeur, c'est pas non plus un abruti qui a du caca dans les yeux, comme tu le dis si poétiquement. Ce n'est pas parce qu'on est développeur qu'on est forcément un débile du design ou qu'on ne peut pas avoir de bonne idées. De même qu'un designer peut aussi avoir de très bonnes idées pour les développeurs (il n'est pas toujours nécessaire de savoir programmer pour comprendre le boulot du développeur, ce n'est qu'une — parfois minime même — partie du boulot de développeur, ce que certains designers ne semblent pas voir).
Je parlais de mauvaise expérience, c'était justement avec un designer qui marquait une triple et très stricte catégorisation des gens: designer, développeur et utilisateur. Je me rappelle même qu'en réunion, une fois, il commence en notant un triangle sur tableau blanc pour noter les 3 catégories clairement séparées (la base de sa philosophie de contribution quoi). Il nous disait alors très clairement que les développeurs étaient des abrutis qui ne devaient absolument pas toucher ou parler du design. Un peu comme toi. Super expérience [ironique], je le dis tout de suite. Comme quoi, y a pas que les designers qui se font mal traiter par les dévs et peuvent mal vivre la collaboration (franchement j'ai très mal vécu cette collaboration et je suis très heureux qu'il soit parti, ça a débloqué beaucoup de choses car justement on le considérait comme le boss du design et on avait accepté son leadership dans ce domaine! Selon moi une erreur puisque c'était ce genre de personne, mais ça montre bien que c'est tout à fait possible). L'inverse existe donc aussi.
Le fait est que le designer est en effet celui avec l'expérience, la connaissance théorique, etc. sur le design. Il est celui qui aura le dernier mot. Ça ne l'empêche pas de pouvoir parfois avoir tort (voire d'être mauvais, comme un développeur peut être mauvais, etc. Le fait d'être un professionnel n'empêche pas cela) ou de pouvoir revoir ses idées en prenant en compte des contre-propositions. Le dév, c'est un techos; mais ça l'empêche pas d'avoir des idées dans le champs du design, et parfois bonnes, qui sait! Quant à l'utilisateur (non parce que ce designer considérait aussi que les gens ne savaient pas ce qui était bon pour eux et qu'il ne fallait donc pas les écouter, ce avec quoi je ne suis absolument pas d'accord non plus; je ne sais pas quelle est ta position sur le sujet, mais puisque tu considères qu'il ne faut écouter que le designer dont c'est le métier, j'imagine que tu te positionnes donc aussi pareil?)… les designers et développeurs sont pas aussi des utilisateurs potentiels? Pourquoi faire une sorte de limite stricte? Au final, les "utilisateurs", ben c'est des gens. Et ils ont aussi le droit à une opinion (même si — encore une fois — oui ils sont pas des designers pros et le(s) designer(s) du projet sera celui avec le dernier mot).

Ensuite dans ma vie, j'ai aussi eu de très bonnes interactions avec des designers (dans le logiciel propriétaire, c'est triste à dire!). Je me souviens de jobs où je lisais une spéc, puis j'allais m'asseoir à côté du designer et faisais quelques commentaires. Parfois il m'expliquait pourquoi mes idées n'allaient pas, puis après une discussion, je comprenais et remballais l'idée. D'autres fois, il comprenait mes idées, était d'accord, et faisait évoluer sa spéc. Franchement, ça se passait super bien, extrêmement bonne collaboration et très bon souvenir. Et c'était aussi un designer avec des années d'expériences, etc. etc. Mais la question n'est pas là!

Au final, je conclurai généralement: le logiciel libre, c'est comme partout, c'est fait d'humains avant tout. Et comme tout entre humains, la collaboration, ça veut aussi dire discuter et savoir prendre un peu sur soi de temps de temps. Aussi savoir accepter les critiques d'ailleurs (du moment qu'elles sont constructives et pas agressives, bien sûr!).
Je trouve que le libre est un très bon environnement pour se former à la fois une estime de soi, mais aussi une forme d'humilité.

Je travaille sur des logiciels libres, dont un très gros, et je suis constamment à la recherche de designers qui accepteraient de prendre la charge du design (ou d'une partie de celui-ci) parce que c'est un très vieux logiciel qui a vraiment une vieille GUI basée sur des paradigmes d'il y a plus de 20 ans (22 ans cette année). Une fois qu'on se sera mis d'accord, on considérera leurs choix comme des décisions. Mais ça ne doit pas empêcher les discussions et clairement je suis à la recherche de quelqu'un qui ne considérera pas les développeurs comme des sous-hommes. Je ne dis pas que c'est nécessairement ton cas. Je n'ai aucune idée de comment se passerait la collaboration avec toi et ne connais pas ton travail, ni n'ai aucun moyen de juger vraiment juste par cet article de blog. Peut-être que ça se passerait super bien, qui sait! Mais j'avoue que ça fait un peu peur de lire ton avis sur la collaboration avec les développeurs, ou du moins ce que je crois en comprendre. :-/

Ensuite je lis peut-être mal entre les lignes et me plante peut-être sur tes dires et intentions. Donc bah j'espère que tu trouveras ton bonheur dans le design de logiciel libre! Car oui, beaucoup de logiciels en ont vraiment besoin (ceux auxquels je contribue aussi sont clairement du lot!). Je suis d'accord sur ce point.
Donc bonne continuation!

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Du coup si on veut installer un logiciel qui utilise une dépendance du runtime GNOME et que l'on a pas ce dernier il faudra tout de même tirer les 250 dépendances (200 de Freedesktop et 50 de GNOME) ?

Non. :-)
Ça se répond en petits morceaux.

1/ Déjà en vrai y a un runtime et un SDK faits en même temps. Le runtime ne contient que ce qui est nécessaire pour exécuter les logiciels (librairies partagées, etc.) alors que le SDK contient aussi les trucs de développement (headers de lib, mais aussi des outil divers comme les autotools, etc.). Les dévs doivent bien sûr installer tout, mais les autres n'installent que le runtime. Ça fait déjà beaucoup moins de dépendances que la liste "naïve" que j'ai faite précédemment avec un grep et un wc pour compter les lignes.

2/ Un runtime comme celui de freedesktop va contenir énormément de libs que beaucoup de logiciels utilisent sans même forcément s'en rendre compte (car pas en dépendance directe). Que ce soit libpng, ou les libs X11 ou Wayland, si votre appli a une GUI, vous en aurez vraisemblablement besoin. Beaucoup de cas d'usage "bureau" feront aussi des appels DBus, même si vous n'en avez aucune connaissance dans votre code. Vous voudrez forcément les libs alsa et pulseaudio pour le son, les diverses libs de Desktop ou d'affichage de texte, etc.
Au final ce sont des libs de base qui sont nécessaires pour quasi toute appli graphique (même si la dépendance n'est pas directe). Il faut bien voir que le "bureau linux" est lui-même vraiment stratifié sur de nombreux niveaux sur lesquels la plupart des logiciels graphiques s'appuient. Dire un chiffre genre "200" bibliothèques peut paraître énorme, mais je vous assure, pour faire tourner votre ordi super-moderne, ça ne l'est pas du tout! Même en espace disque, ce ne sera pas énorme. Beaucoup de libs de base sont très simples et ne tiendront que sur quelques Ko une fois compilés. Le fameux "faire une seule chose et le faire bien".

3/ Si vraiment vous êtes dans un cas exceptionnel où vous pouvez faire tourner l'application sur quasi aucune dépendance, vous êtes libre de faire votre propre runtime super-minimal.
Si vous voulez dépendre du runtime Freedesktop, mais pas de celui de GNOME: supposons qu'il y a une seule lib que vous voulez qui est dans le runtime GNOME, vous pouvez aussi bien l'ajouter dans votre Flatpak et vous baser sur le runtime Freedesktop. Il n'est pas nécessaire de tirer le runtime GNOME.

4/ Aussi il faut bien se rendre compte que si les gens se mettent à installer Flatpak, ils auront probablement déjà les principaux runtimes, dont celui de GNOME (et celui de KDE). Celui-ci est partagé entre les applications et téléchargé une seule fois, donc pas téléchargé pour une application unique. C'est plutôt efficace et permet des Flatpaks de taille réduite.

En outre, côté sécurité, ça signifie que vous bénéficierez de la réactivité de l'équipe de Flatpak (contenu du runtime Freedestop) ainsi que de l'équipe GNOME (runtime GNOME) donc des mises-à-jour de sécurité de ces 2 runtimes. En tant que développeur d'application, c'est autant de dépendances dont on n'aura pas à s'inquiéter.

Au final, je trouve ce système de niveaux de runtime les uns au dessus des autres assez bien et cela permet de bien diluer le travail entre les packageurs de divers projets, de garantir une sécurité plutôt bonne tout en ayant des mises-à-jour fonctionnelles régulières.
Pour le moment, mon expérience est assez positive. Je n'ai que des problèmes d'accès de fonctionnalités du bureau qui ne sont pas encore possible parfois à cause de la problématique "sandbox". Mais ce sont des problèmes connus et sur lesquels l'équipe de Flatpak travaille. Mon interaction avec eux est plutôt constructive jusqu'à présent (GIMP étant un logiciel avec pas mal de dépendances, et qualifiable de relativement complexe, j'ai forcément rencontré plusieurs petits embêtements ici et là).

P.S.: je conclurai avec un truc auquel je viens juste de penser; le fait d'installer des apps KDE est toujours très ennuyeux dans les distribs classiques, car cela va souvent tirer des dizaines d'autres applications graphiques (souvent pas parce que ce sont de vrais dépendances, mais parce que les packageurs de distribs veulent se simplifier la vie et "supposent" que si vous voulez une application KDE, ça veut dire que vous les voulez toutes) qui vont notamment polluer mon overview lors d'une recherche d'application (ou les menus d'application pour ceux qui en ont encore). Cela ne sera — je pense bien — pas possible avec Flatpak et si j'installe une application KDE qui aura été packagé en Flatpak, je pense que je n'aurai que cette app dans mon overview/menu ce qui améliorera le confort d'utilisation. Et au besoin, désinstaller le runtime Flatpak KDE sera 1000 fois plus simple, minimal en taille et propre que me débarrasser des dépendances multiples dans mon système principal. C'est aussi un gros avantage!

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Si ça y répond même plutôt pas mal. :-)
Cf. mon message plus bas.

P.S.: en tous cas pour Flatpak. Pour Docker, je sais pas, mais comme c'est orienté plutôt services et système de prob, j'en doute. Et pour d'autres alternatives de bureau, type Snap, aucune idée non plus du modèle adopté.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Tu cites déjà la réponse dans ton journal. Je pense que Flatpak, si le projet continue dans la bonne direction (ça a l'air d'être le cas pour l'instant), peut être la solution au problème cité.

Note que je ne considère absolument pas que le système de paquet par distribution est cassé pour autant, ni qu'il disparaîtra. C'est simplement complémentaire. L'écosystème logiciel GNU est simplement devenu trop important pour que tous les logiciels intéressants soient inclus dans les paquets gérés par la distrib (on peut voir cela comme un succès du "bureau Linux" si on veut alimenter le troll! :P). Donc il faut trouver des solutions pour répartir mieux le travail, et ça veut en général dire que les développeurs doivent s'y mettre. Par contre — on le sait bien depuis le temps — faire un paquet par distribution n'est pas gérable, surtout si ce sont des logiciels faits sur le temps libre (cas non rare dans le logiciel libre!). Un format standard comme flatpak, utilisable sur toute distribution GNU/Linux, est donc une très bonne alternative.

Mais là, qui va s'assurer que tout vos containers utilisent bien la dernière version patchée d'une bibliothèque critique ?

Alors je sais pas comment ça marche pour Docker que tu cites aussi, mais j'imagine bien qu'y a pas de mise-à-jour automatique (surtout parce que c'est fait pour les serveurs et on veut pas voir des trucs genre maj auto en prod!). Par contre Flatpak a un système de dépôt. En gros, chaque projet aura désormais un mini-dépôt de paquets pour ses logiciels et mettra à jour ses dépendances (note: il est aussi possible de faire des Flatpak standalone, sans dépôt, mais ce n'est pas la procédure conseillée).
Ainsi quand le projet mettra à jour son paquet, l'ensemble des gens qui auront installé ce paquet recevront des notifications qu'une mise-à-jour est dispo. Personne ne se baladera avec des applis et dépendances trouées (tant que le projet upstream est maintenu). Note que le projet n'a même pas à maintenir l'ensemble des dépendances possibles d'un logiciel puisque Flatpak fonctionne par "niveaux" de runtime. Ainsi le projet Flatpak lui-même maintient un runtime "Freedesktop" qui à lui seul contient déjà environ 200 dépendances de base qui vont suffire pour énormément de projets. Le projet GNOME aussi maintient un runtime, basé sur celui Freedesktop et qui ajoute environ 50 dépendances. Le projet KDE aussi maintient un runtime. Un logiciel doit simplement choisir un runtime sur lequel se baser.
Pour énormément de projet, celui signifie qu'il n'y aura peut-être aucune dépendance supplémentaire à ajouter dans le Flatpak (et donc à maintenir), ou très peu. Cela dilue énormément la tâche tout en permettant de rester sécurisé.

• Ainsi pour les distributions, ça ne change pas grand chose: elles peuvent continuer à proposer les logiciels les plus notables notamment, et avoir des mises-à-jour fonctionnelles pas forcément au taquet (mais une fois tous les 6 mois ou 1 an en fonction du cycle de sortie de la distrib). Ça sera suffisant pour la majorité des logiciels.
• Les développeurs eux auront moins de travail puisqu'il n'y aura plus qu'un seul paquet à maintenir pour être dispo partout.
• Enfin tout le monde aura accès à des mises-à-jour immédiates fonctionnelles ET de sécurité si on choisit d'installer le paquet Flatpak upstream.

En tous cas, le projet GIMP par exemple fournira désormais un paquet Flatpak upstream que je crée et maintiens. Je pense que c'est vraiment une avancée car jusqu'à ce jour, les gens sous Windows ont un installeur, ceux sous OSX un DMG, et sous Linux… on leur disait d'attendre le paquet de leur distrib ou de compiler. Ça fait limite "citoyens de seconde zone" (bon c'est pas vrai, hein. Quasi tous les dévs de GIMP sont sous Linux, et donc ça veut dire notamment que la version nux est bien plus stable que les autres! Mais bon on pourrait croire). Ben plus maintenant. Tant que je serai dév de GIMP, les linuxiens auront leur Flatpak (bon à part si une alternative encore mieux fait son apparition bien sûr, ou si je découvre un truc horrible qui me fait changer d'avis sur l'utilité… espérons que non, mais on sait jamais!) et seront toujours des citoyens de première zone! :-D

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

En effet, je pense que leur suite creative cloud a encore une longue vie devant elle. D'ailleurs même le logiciel "Flash" a probablement un avenir sous son nouveau nom Animate. Simplement le "focus" a changé et le but n'est plus d'exporter en format Flash mais en HTML5 ou en d'autres formats vidéos.

Donc oui, Flash, le format, est sur la pente descendante, et Shockwave l'est encore plus (depuis bien plus longtemps puisque cette technologie fut justement totalement éclipsée par Flash quasi dès ses débuts! C'est dire à quel point c'est mort. J'explique cela dans les sections "Premier pas", puis "Age Sombre" de l'article sur Flash) et c'est donc normal que les logiciels dédiés à ces formats disparaissent (ou deviennent génériques comme fut le cas pour "Animate").

Mais effectivement je doute qu'Adobe en tant que société soit mourante. Pas du tout même. Une petite recherche sur le web indique un chiffre d'affaire en croissance. Apparemment ils ont eu une baisse du chiffre en 2013-14 (si je comprends bien comment on lit ces tableaux) mais ils sont repartis en force en 2015.

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Microsoft Office est l'un des fleurons commerciaux de Microsoft. Il me semble — si je ne m'abuse — que cela compte pour une grande part dans les revenus de la compagnie (rapide recherche sur le net, si je comprends bien les graphiques, surtout le dernier, leur suite office fait environ 25% de leur revenu, au delà des produits serveur et des OSes).

Le fait est qu'aujourd'hui comme il y a 20 ans, une chose n'a pas changé: les gens ont besoin d'écrire des textes (courriers, contrats, histoires…) et pour cela les traitements de texte de ce type reste l'outil essentiel de la majeure partie des gens. Les tableurs sont aussi une ressource très commune et ne disparaîtront pas de sitôt, les gens en entreprise ont régulièrement besoin de faire des présentations…

Donc quelle est l'intérêt d'investir dans une suite office, vraiment? Quand tout dans l'utilisation informatique quotidienne des gens ainsi que dans les chiffres de l'entreprise informatique qui vend la suite office la plus utilisée au monde montre qu'il y a un potentiel financier énorme, cela me paraît une bien étrange question… :-)

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]