Je vais donner un autre point de vue, qui est complètement le cul entre 2 chaises. Mais c'est vraiment comme cela que je vois la contribution au logiciel libre.
Mais s'il souhaite vraiment collaborer au projet, alors je préfère qu'on en discute ensemble avant qu'il se mette à coder.
Alors d'un côté, tu as totalement raison. Si quelqu'un te file un méga-patch de centaines/milliers de lignes pour une grosse fonctionnalité dont tu ne veux pas, c'est dur de le rejeter (pour plein de raisons). Mais pour garder une cohérence au projet, ben des fois, faut bien.
Ceci dit, de l'autre côté, la personne essaie parfois de contacter, et se retrouve sans réponse pendant des jours, voire des semaines. Le truc, c'est que c'est totalement normal. On est des êtres humains, on fait des choses parfois en dehors du code. Et même si on devait coder quotidiennement à temps plein, ça ne signifie pas pour autant qu'on est obligé de répondre à toute question à la minute. On a une vie quoi.
Cependant la personne qui demande a aussi une vie. Attendre des jours, des heures même souvent, c'est dur quand on a une idée qu'on veut développer! On se met à le faire dans sa tête, on y passe des heures à y penser (qu'on a l'impression de perdre et on se dit qu'on aurait déjà bien avancé si on s'était mis directement à coder). Bien sûr, on pourrait/devrait juste poser la question et passer à autre chose en attendant la réponse (si même elle arrive). Mais l'humain est pas si rationnel et quand on a une idée en tête, c'est souvent pas si simple de "passer à autre chose".
En outre, du côté des mainteneurs, on entend très souvent la fameuse "Je suis développeur, je peux aider, vous m'expliquez ce que je dois faire?". Le truc, c'est que c'est pas si simple. D'ailleurs c'est peut-être même symptomatique d'un développeur à l'expérience limité de demander cela, comme s'il s'attendait à ce qu'on puisse lui décrire un logiciel énorme de tête en quelques minutes dans le détail. Car c'est le détail qui importe (bon bien sûr, on peut en faire dire de tête le nom de pas mal de fichiers ou fonctions et où plus ou moins précisément doit se passer tel ou tel changement, mais y a des limites quand même); oui je peux décrire la structure globale de GIMP en quelques minutes, mais une description si globale en général est inutile pour un développeur qui veut implémenter un truc précis. Il espère donc que tu lui dises où et quoi changer. Mais si on vérifie cela, on a déjà fait la moitié du boulot nous-même et on y a passé pas mal de temps.
Donc quand on donne juste une description simple, soit le contributeur potentiel comprend et il fait, soit (et c'est 90% des cas), il abandonne au bout d'un moment (et peut-être se dit que les dévs sont pas cool, ils aident pas les nouveaux, alors forcément…).
Là où je veux en venir, c'est qu'une demande qui vient avec un patch vaut 1000 propositions d'aide. C'est concret, c'est là, on sait tout de suite à quoi s'attendre (au niveau qualité du code notamment et on a une idée de ce qu'on pourra demander ou non à cette personne), etc. La proposition d'aide, notre réponse est invariablement "c'est cool, on attend le patch!" sans pour autant y mettre un espoir fou. On sait que dans beaucoup de cas, ça ne viendra pas. Je me rappelle même une fois une personne nous avoir dit avoir reçu un financement pour une fonctionnalité (j'ai retrouvé le ticket). Ce fut la première et dernière fois qu'on a entendu parler de lui.
Et en ce sens d'ailleurs, l'auteur du journal a très bien fait. Proposer un patch fonctionnel est la meilleure chose à faire quand on veut vraiment une fonctionnalité. C'est ce que j'ai appris au fil des ans, et désormais quand je veux vraiment quelque chose, je ne me pose pas la question: je la code moi-même. Attendre les autres mène rarement à l'obtention de la fonctionnalité (et ce, même si les développeurs du logiciels sont d'accord sur la fonctionnalité sur le principe; ça ne leur crée pas du temps magiquement ni ne la met en haut de leurs priorités: s'ils n'en estimaient pas eux-même le besoin au préalable, accepter qu'un autre puisse en avoir le besoin — et ce faisant accepter que cette fonctionnalité vaut le coup — ne change pas leur propre besoin).
Donc mon conseil aux contributeurs, c'est: oui bien sûr, discuter, c'est toujours bien! Mais ça ne veut pas dire que vous ne devez pas prendre un peu les devants. Les bons mainteneurs apprécient si vous avez un peu d'indépendance et que vous fassiez une implémentation dès le début. C'est la meilleure intro en tant que contributeur.
Par contre, oui, il faut être conscient que ça ne veut pas dire pour autant que votre patch sera accepté. Peut-être qu'il nécessitera juste des corrections. Peut-être que le mainteneur ne sera pas d'accord avec certains choix et qu'il faudra faire des compromis. Peut-être même (le pire des cas) que votre patch sera au final rejeté après avoir passé plein de temps pour coder et pour ensuite discuter et défendre la fonctionnalité. Ça arrive. Ça m'est aussi arrivé, et pas qu'une fois (même si globalement cela reste rare! Si vous êtes un bon développeur avec de bonnes idées, peu de mainteneurs refuseront tous vos patchs sans y penser à 2 fois, en tous cas pas les bons mainteneurs).
Mais vous savez quoi? C'est la vie! C'est pas une spécificité du développement logiciel. Dans plein de trucs dans la vie, il m'est arrivé de gâcher mon temps, en faisant ceci ou cela qui s'est avéré inutile ou refusé, ou autre. C'est chiant, mais bon. C'est pas la mort! On passe à autre chose.
En gros, la conclusion, c'est: que vous soyez mainteneur ou contributeur, soyez conscients que vous parlez avec des êtres humains:
L'autre a aussi une vie, il n'est pas votre esclave, et notamment son temps ne vous est pas réservé (donc les réponses peuvent prendre du temps notamment).
Il peut faire des erreurs aussi; par exemple même oublier de répondre! Donc le relancer n'est pas mal pris, du moment que c'est pas en insistant lourdement tous les jours, cf. point précédent. Je considère souvent que relancer après 2 ou 3 semaines est une bonne moyenne. Répondre à un email ou un message de rapport après quelques semaines n'est absolument pas rare. On met un sujet dans un coin de notre TODO liste pour "plus tard", puis on répond quand on peut. Après quelques semaines sans réponse, on peut cependant se dire que la personne a peut-être oublier.
Il peut avoir des priorités différentes que vous (et c'est ok). Il faut savoir l'accepter et mettre en valeur les compromis.
On a un développeur qui a fait quelques patchs (de très mauvaise qualité technique d'ailleurs, donc énormément de temps de revue) pour GIMP et qui plusieurs fois nous dit des trucs genre "ce que je déteste le plus, c'est de perdre mon temps" dès qu'on se met à discuter ses patchs (pas pour les rejeter, mais réellement pour les discuter afin d'arriver au meilleur choix, qu'on ne sait pas forcément). Non seulement c'est très passif-agressif, met directement la discussion sur une mauvaise ambiance, mais en plus c'est oublier que nous aussi on existe. Nous non plus n'aimons pas perdre notre temps. Qui aime cela?
Mais on fait ce qu'on fait pour aboutir au meilleur logiciel ensemble, pas pour "perdre du temps". Si quelqu'un ne comprend pas ça, autant ne pas faire de logiciel libre.
Je comprends qu'un utilisateur puisse faire des modifications pour son propre usage (les licences libres servent à ça). Mais s'il souhaite vraiment collaborer au projet, alors je préfère qu'on en discute ensemble avant qu'il se mette à coder. En ce moment, par exemple, j'ai trois contributions pour Sozi que je ne souhaite pas intégrer : une parce qu'elle n'est pas complète, une qui s'apparente à un bricolage et qui mériterait d'être réécrite, et une autre parce qu'elle me semble incohérente avec la philosophie du projet.
Alors je le disais, il faut savoir refuser certaines contributions inadéquates. Ensuite sans plus de détails, je ne peux pas dire si c'est le cas des contribs que t'as reçue. Ceci dit, il faut aussi savoir demander à un contributeur à corriger son code pour le voir intégrer (cas de 2 des 3 contributions: demande au premier de compléter son patch, et au second de le refaire proprement).
Souvent aussi il faut savoir prendre de son temps pour faire faire fleurir les contributions. Je l'ai déjà dit, je fais beaucoup de revue de code dans GIMP. Mais soyons clair, la majorité de ce que je relis et corrige ne m'intéresse pas personnellement (ni pour notre projet ZeMarmot). Mais j'en vois l'intérêt pour d'autres et pour l'amélioration de GIMP en général. Si on devait refuser tous les patchs dès que le contributeur n'est pas capable de mieux, alors GIMP aurait genre moitié moins de fonctionnalités. La plupart du temps, on repasse derrière les patchs pour les peaufiner (et ce, même si la fonctionnalité ne nous intéresse pas personnellement!). Et d'autres repassent aussi derrière moi. Et ainsi de suite.
C'est aussi ça qui fait la qualité d'un logiciel libre: on n'est pas tout seul avec notre code et nos propres limitations.
Perso je n'aime pas tous les choix faits dans GIMP et j'en ai discuté plus d'un. Mais si je contribue, c'est parce que ce qu'on fait tous ensemble, j'aurais été incapable de le faire seul (de même pour les autres contributeurs). Et ça j'en suis très conscient. On a un logiciel extrêmement cool et puissant parce qu'on a travaillé ensemble, on a tous compromis ensemble.
Donc j'espère que tu ne refuses pas des fonctionnalités juste parce qu'elles ne t'intéressent pas. Ce serait tout de même un peu triste.
Bien sûr si la fonctionnalité a pour effet de rendre d'autres fonctionnalités moins bonnes, c'est une autre histoire. Mais ce n'est pas le cas de la plupart des fonctionnalités.
Je comprends qu'un utilisateur puisse faire des modifications pour son propre usage (les licences libres servent à ça).
Perso notre build de GIMP local utilisé pour ZeMarmot a quelques petites différences, mais très mineures. Ce sont quelques détails qui ont été refusés dans GIMP (pour de bonnes raisons, même si je suis pas d'accord). J'en ai pas fait une maladie et je vais sûrement par forker GIMP (de manière publique j'entends) pour cette raison. Mais on garde ces différences au strict minimum.
Notre but n'est pas d'avoir notre propre GIMP mais d'améliorer le GIMP de base. Ne serait-ce que pour la qualité. C'est bien simple: presque tout ce que j'ai codé est d'autant mieux car d'autres gens sont passés derrière et ont aussi amélioré.
D'ailleurs l'un de mes buts dans GIMP est d'améliorer considérablement l'API et ses possibilités justement pour ne plus avoir de GIMP patché en local du tout. Je veux pouvoir transformer nos quelques différences de code en dur en plug-ins à la place.
Le truc, c'est aussi que maintenir un fork, c'est aussi un travail de dingue. Il faut le faire si vraiment tu n'as aucun choix (ou que tes différences sont vraiment minimes). Alors c'est vrai que c'est bien que ce soit possible, mais ce n'est absolument pas le plus intéressant dans les licences libres, selon moi. La possibilité d'un fork personnel est seulement une manière de rendre le pire cas "moins pire" (toujours d'après moi). :-)
Bon y a aussi les forks après abandon d'un projet par exemple, ou d'autres types de fork qui sont totalement différents. Je parle du cas du fork sans raison profonde, genre juste "comme ça je fais ce que je veux".
L'autre problème que je rencontre parfois, c'est qu'une fois la nouvelle fonctionnalité ajoutée, les contributeurs disparaissent et on se retrouve tout seul pour maintenir leur code.
C'est effectivement une réalité, et la majorité des cas. Ensuite, je le rappelle (cf. plus haut): les contributeurs aussi ont une vie et des priorités. On peut leur demander d'aider mais on peut pas leur en vouloir s'ils refusent. J'ai personnellement contribué à des dizaines de projets (voir OpenHub et c'est loin d'être exhaustif!) et GIMP est le premier (hormis ceux que je maintiens ou ai créés) sur lequel je suis resté. Je ne pourrais pas humainement participer activement à tous les projets auxquels j'ai envoyé un patch.
Ça ne m'empêche pas de vouloir une fonctionnalité ailleurs et de la coder de temps en temps, mais oui le mainteneur doit être conscient que ça ne veut pas dire que je signe un contrat avec mon sang pour rester à ses côtés jusqu'à ma mort.
En tant que mainteneur de projet libre, c'est quelque chose à accepter. Ensuite bien sûr tu peux vouloir un projet petit et simple à maîtriser et qui prenne peu de temps en refusant de le rendre communautaire. C'est un choix et chacun est libre de le faire. Ensuite faudra pas espérer que son projet s'envole vers des sommets. On peut pas tout avoir. Bien sûr, pour beaucoup de gens, ce n'est pas ce qu'ils veulent. S'ils font le choix en plein conscience, c'est bien.
Personnellement je pense que ce n'est pas mauvais d'accepter de lâcher un peu prise parfois. D'ailleurs si les gens ne restent pas, c'est parfois aussi car certains mainteneurs peuvent garder trop de mainmise sur leur projet.
Au contraire, les plus gros projets ont des co-mainteneurs (voire ont changé de mainteneur à plusieurs reprises), et même quand parfois le créateur est resté depuis le début, cela ne l'a pas empêché de prendre des sous-mainteneurs (comme le noyau Linux) à tel point que dernièrement on a eu plusieurs exemples de tels mainteneurs qui essaient de rendre le projet encore plus indépendant d'eux (je pense bien sûr à Linus Torvalds et Guido Van Rossum).
La chose qui m'a fait rester sur GIMP? Très rapidement le mainteneur m'a attribué sa confiance. Au bout d'un mois ou 2, après plusieurs patchs, Mitch me dit en gros "tu fais chier avec tous tes patchs, ils sont tous bien, tiens prends toi un accès en écriture à git comme ça je gagne du temps". Franchement ça m'a impressionné. Je me suis dit "Waw juste comme ça, je peux pousser mes commits dans GIMP?". Il m'a donné sa confiance et j'ai d'autant plus fait gaffe à ce que je poussais et pendant longtemps je continuais à demander des revues de code avant de pousser dès que ce n'était pas totalement trivial. Au final je suis le plus gros développeur de GIMP sur la dernière année. Ce fut une très bonne leçon et j'essaie de l'appliquer aussi maintenant: dès que quelqu'un fait du code de qualité évidente et qu'il reste un peu, c'est le moment où faut "l'accrocher" avant qu'il aille voir ailleurs. Je lui propose donc d'avoir son accès en écriture. :-)
Alors soyons clair, ça marche pas tout le temps. Même ainsi, beaucoup de contributeurs disparaissent au bout d'un moment. Mais ça vaut le coup d'essayer.
Dans tous les cas, je ne suis pas seul à maintenir le code. On n'est pas beaucoup, mais je suis pas seul. Et c'est passé par le fait que le mainteneur (et tous les sous-mainteneurs) a su donner sa confiance aux gens et surtout a lâché un peu du lest. Il accepte qu'il ne sait pas tout, que certains sont de très bons développeurs (voire meilleurs que lui), qu'ils ont aussi de bonnes idées, que le logiciel peut servir à plus que ce dont lui se sert, etc.
En fait, le logiciel libre et/ou communautaire, quand c'est bien fait, je pense que ça peut faire de nous des bons philosophes. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Oui. Cet article essaie de se la jouer neutre officiellement, mais sa tournure montre clairement que le journaliste est carrêment pour cette loi, genre "on reprend le contrôle du web". C'est marrant car ils ont vraiment joué sur cet aspect "David contre Goliath" dans le marketing pour cette loi, genre d'un côté les méchantes "tech sociétés" et de l'autre les "pauvres petits artistes". Alors qu'en vrai, y avait effectivement notamment ces grosses sociétés du web, mais de l'autre côté, c'était surtout les grosses sociétés d'ayant-droits.
En fait avec cette loi, ce qui pourrait se passer:
Les grosses sociétés du web? Ben soit éventuellement elles retirent leurs agrégateurs (par ex. Google News) de l'Europe. Ça avait déjà été fait par exemple en Belgique, qui était même allé plus loin, et finalement les journaux se sont rendus compte que ne pas être présent sur Google News, c'est pas terrible pour le business. Soit les grosses sociétés du web se plie aux règles et paient les droits (ce fut la fin de l'affaire belge quand tout le monde a compris que Google News, c'est pas si mal finalement). Pour Google (et autres grosses boîtes du genre), ces droits sont rien du tout au final.
Quant aux filtres d'upload, Google et consort mettront en place les dits filtres (ça prendra juste quelques jours, après tout, c'est pas comme s'ils avaient pas des milliers de développeurs et admins faits pour, hein!).
Pour les très gros médias et grosses sociétés de droits d'auteur spécialisés dans la recherche de droits (avec des équipes spécialisés dont c'est le boulot à temps plein), c'est une aubaine et ils vont se faire des pépettes en or (qu'ils pourront sainement redistribuer aux salariés qui en ont le plus besoin, et puis si on se plaint que c'est pas si juste, on peut toujours virer la personne en lui versant d'autant plus; c'est logique, on vire quelqu'un pour avoir profité du système, autant partir en profitant encore plus, comme ça au moins la critique est doublement méritée!).
Les "artistes" et autres créateurs de leur côté, ben ils touchaient des cacahouètes avant, et ils continueront à… toucher des cacahouètes. On notera les superbes communiqués de presse que nous envoient d'ailleurs les sociétés de droits d'auteur précédemment citées, par exemple ici l'ADAMI (cliquez pour voir en plus gros):
On nous rassure donc avec des "Ce vote est une première étape capitale vers une rémunération juste et proportionnelle à l’exploitation de votre travail sur Internet", bien sûr! On y croit tous!
Par contre, même si on touchera toujours autant de rien, on aura de plus en plus de mal à faire diffuser nos œuvres. Non parce que tu comprends, si tu joues Jean-Sébastien Bach et le met sur un site, on pourra venir t'expliquer que ça appartient à Sony Music Global et donc ton partage se verra interdit (je le disais plus haut: les grosses plateformes n'auront aucun mal à implémenter les filtres… d'ailleurs ce cas de Bach est un cas déjà réel qui s'est produit sur Facebook). Et va y pour te plaindre et essayer de débloquer ton œuvre et ton compte (ah oui parce que les filtres, ben c'est pas des humains!).
Pire! Si jamais tu arrives au final à faire entendre raison à un humain du support de la plateforme et à faire diffuser ton œuvre, après un parcours du combattant, et qu'elle se retrouve même partagée! Youhou! Tu te dis que toi aussi, tu vas pouvoir commencer à te faire des pépettes en droits d'auteur! Que nenni! Tu n'as pas les équipes de SACEM ou Adami, tu auras bien du mal à savoir qui diffuse ton œuvre, et à part si tu fais que ça de ta journée (plutôt que jouer au piano!), ben tu pourras demander aucun sous. Et par défaut, les équipes d'ayant-droit vont toutes attribuer les droits à Sony Music de toutes façons (car ils utiliseront les mêmes logiciels pour détecter les ayant-droits que les filtres anti-upload, bien sûr!).
Tu l'auras compris: dans un cas comme dans l'autre (que tu sois affilié ou non), biiiip, tu perds!
Quant aux petites plateformes et sites, parlons en! Eux, avec leurs 2 employés (qui ont heureusement appris à créer un site en 24h avec une formation Pôle Emploi! C'est des as!) ou 5 bénévoles (après le boulot et le week-end), ça leur prendra un peu plus que quelques jours de développement pour un résultat… disons que déjà que si Facebook et Youtube auront des faux-positifs à foison (prédiction du jour comme déjà confirmé), je pense qu'on pourra juste jamais rien uploader en paix sur un petit site communautaire (soyons clairs, une petite entreprise ou asso voudra pas prendre trop de risque avec la loi et fera des filtres plus bloquants que l'inverse)!
De toutes façons, on le sait bien, hein. Internet, c'est Google et Facebook. Le reste, c'est le "Darknet" et c'est rempli de méchants terroristes!
Alors résumons: les gros médias et sociétés de droits? Ils vont se faire plein de brouzoufs! Les grosses boîtes du web? Bah, une petite épine dans le pied, on a perdu une bataille, passons et réfléchissons simplement au prochain moyen de se faire du blé avec vos données perso. Les créateurs? Vous touchez déjà 50€ par an, maintenant ce sera 51€, youhou! Vous êtes riches! Par contre faut pas vous imaginer pouvoir créer en dehors du système en uploadant vous-mêmes, passez par les gros médias SVP (faites nous confiance…)! Les petites plateformes? Bandes de pirates (avec des crochets et des bandeaux sur les yeux), crevez! Laissez les vrais boîtes gérer toutes les œuvres publiées!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
L'argent de GIMP est utilisé uniquement pour les frais communautaires. Par exemple, cela permet aux contributeurs de se rencontrer une fois par an (frais de transports et d'hébergement) à Libre Graphics Meeting, voire à Wilber Week (si on en réorganise) pour une semaine de hacking.
Il est aussi déjà arrivé régulièrement que GIMP aide financièrement d'autres projets libres ou des évènements (en particulier Libre Graphics Meeting qui a parfois eu du mal à joindre les deux bouts si GIMP n'avait pas été là pour sauver les meubles).
Cela peut aussi être utilisé si on a besoin de faire des autocollants ou un kakémono (l'an dernier, un contributeur a participé à une conf aux US et a fait faire un kakemono GIMP ainsi), ou autre chose du genre.
Enfin cela peut être utilisé pour du matos.
Par contre, cela n'est pas utilisé pour des salaires (ce qui est le plus coûteux et au final le plus nécessaire). GIMP n'a pas de structure pour embaucher. Ceci dit, le projet pourrait sûrement donner à LILA, ce qui servirait à payer des salaires dans une structure. Mais certains contributeurs trouvent que donner cet argent de cette façon ne serait pas juste pour certains contributeurs bénévoles qui font aussi beaucoup, etc.
Personnellement je trouve cette logique peu constructive et serait (bien évidemment) heureux si cet argent pouvait nous servir pour rendre viable les tentatives de professionnaliser nos contributions à GIMP. Mais bon, je suis clairement parti pris et je ne veux pas créer une mauvaise ambiance autour de questions financière.
À la place, je dis clairement aux gens: si vous voulez financer du développement dans GIMP, vous pouvez donner à LILA; si vous voulez financer la partie communautaire, nos réunions bénévoles, etc. alors donnez à GIMP.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Les captures d'écran montrent de vieilles interfaces, les photos du hardware antédiluvien, le texte est vieux et mériterait une revue, plein de fonctionnalités sont absentes. Etc. etc.
On accepte aussi des tutos (sous licence libre seulement, comme le manuel) récent et de qualité: https://www.gimp.org/tutorials/
Je suis pas sûr de comprendre. GIMP a déjà un concept de répertoire utilisateur vs. répertoire système pour les plug-ins, et ce depuis très longtemps.
Ensuite sous Windows, je pense que le répertoire système serait $PREFIX/lib/gimp/2.0/plug-ins/ ($PREFIX étant là où GIMP est installé).
Mais non ce n'est absolument pas nouveau et ce n'est pas de cela dont je parle ici. Je parle juste d'une nouvelle organisation des plug-ins, où on demande de mettre chacun dans son propre répertoire afin d'éviter la pollution de DLLs apportés par un plug-in tiers.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
On avait déjà publié nos rapports, mais c'est vrai qu'on l'a pas fait dernièrement. LILA est une micro asso et c'est vraiment dur de tenir tout à jour dans les temps. Mais c'est noté. On va essayer de faire les choses au plus carré (en fait, ça a toujours été notre but de faire le plus carré et transparent; j'ai un peu honte qu'on y arrive même pas!). Tu as entièrement raison de dire que ce type de transparence est important.
Quoiqu'il en soit, les donations vont à ce jour principalement dans la production de ZeMarmot. C'est notre seul gros projet à ce jour (notez qu'on ne serait pas contre d'autres projets en parallèle si des gens cherchent une structure dans l'Art Libre pour développer leur projet; mais à ce jour, y a pas vraiment, même si y a eu un peu). LILA fait des salaires intermittents en bonne et due forme.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
C'est quand même très récent. Le redressement d'image est sorti dans la 2.10.4, soit début juillet. En 2 mois, je pense qu'il est impossible de connaître tout GIMP.
Je travaille sur le code de GIMP depuis 6 ans, et je découvre sans arrêt des trucs. Aryeom travaille quotidiennement dans GIMP, toute la journée (du matin au soir, en continu… enfin hors pause et éditions vidéos, etc. ;p), et c'est pareil. Toutes les 2 semaines, y a un "quoi on peut faire ça? C'est cool!".
Alors que tu n'aies pas trouvé une fonction par hasard en 2 mois, ça me semble absolument pas étonnant. Et franchement je doute qu'on puisse attribuer ça (ou en déduire) un problème ergonomique quelconque sur l'emplacement de la fonctionnalité. :P
GIMP fait partie de ces outils pour professionnels, vraiment très complets et avec des fonctionnalités tellement nombreuses qu'il faudrait des jours à ne faire que ça pour toutes les essayer et comprendre leur utilisation (et encore même là, ça veut pas dire qu'on verrait immédiatement un usage concret immédiat). Ce n'est pas forcément un mal. On me demande pas de connaître le moindre rouage de mon hardware et tout le code source de mon système d'exploitation pour l'utiliser (cela ne m'empêche pas d'être un développeur décent, je pense). Pourtant je suis sûr que je ferais des choses extraordinaires si je connaissais tout sur tout. ;-)
Quant au fait que l'outil de mesure s'appelle ainsi, perso je le vois un peu comme une sorte de règle, et même si la fonction première est en effet de mesurer, l'utiliser pour remettre droit me paraît au contraire une évolution des plus naturelles (cf. les règles niveau à bulle).
Quant aux repères, comme quelqu'un le note, on peut afficher des grilles, on peut aussi utiliser des guides de canevas, et enfin l'outil de rotation lui-même a une fonctionnalité de guides qui peuvent avoir divers formats (règle de 3, de 5, diagonales, etc.). Voir les options de l'outil de rotation.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Quelqu'un peut-il corriger "東京で住んでいる" en "東京に住んでいる"?
C'était pas Tokyo mais Paris (et j'ai fait exprès de le laisser en alphabet plutôt que katakana, histoire de montrer l'orientation mixte).
Quoiqu'il en soit, en cherchant sur le web, il semblerait en effet que 'で' est moins utilisé/utilisable, car ce n'est pas une action. Quoique apparemment certains japonais disent (sur des forums) utiliser habituellement 'で' dans une telle phrase, mais il apparaît tout de même que ce n'est en effet pas du japonais littéraire.
Perso la phrase me paraissait grammaticalement correcte, mais bon… c'est pas comme si je parlais bien japonais! :P
Je note tout de même que tu me demandes carrêment de corriger la capture d'écran. Ahahah! Désolé, je vais pas perdre une seconde là-dessus (le but, c'était de montre l'orientation mixte; objectif atteint!). :P
Tu es d'ailleurs la première personne à me faire la moindre remarque sur cette erreur.
Sinon, dépêche intéressante, mais j'aurais aimé savoir ce que ça veut dire, "redressement d'image".
Ce n'est peut-être pas le bon terme. Comme souvent, quand je traduis mes dépêches GIMP de l'anglais vers le français, je vérifie s'il y a déjà une traduction (en gros, je regarde le fichier fr.po des traductions de l'interface en français). Il n'y en avait pas pour "straighten" (et toujours pas d'ailleurs, je viens de regarder). Alors j'ai traduit comme je pouvais. Même maintenant je continue à pas trouver ça si mal d'ailleurs, faute de mieux.
Mais je suis ouvert à des propositions (pas que ça serve à grand chose; je suis pas dans l'équipe des traducteurs et n'ai donc pas mon mot à dire de toutes façons).
Comme quoi, il semblerait que je parle mal le français ET le japonais! C'est la fin! ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Déjà un peu d'explication du problème pour bien comprendre. Windows cherche les DLLs dans cet ordre:
Le répertoire où se trouve le binaire
le répertoire courant
les divers répertoires système
enfin les répertoires listés dans le PATH.
Pour le binaire principal gimp-2-10, c'est facile car il suffit de mettre toutes nos DLLs dans le même répertoire $PREFIX/bin/. Elles seront toujours trouvées en premier.
Le problème est pour les plug-ins qui sont dans $PREFIX/lib/gimp/2.0/plug-ins/ et lorsque ces plug-ins souhaitent utiliser certaines des bibliothèques livrées avec GIMP (qui sont donc dans $PREFIX/bin/).
On pourrait simplement mettre les librairies à côté de chaque plug-in, mais cela signifierait dupliquer les bibliothèques un certain nombre de fois. Et en plus ça ne permettrait plus aux plug-ins tiers de profiter des biblios livrées. Donc ce n'est pas acceptable.
À la base, on rajoutait donc $PREFIX/bin au début du PATH (qui est spécifié dans un script de lancement). Mais si jamais une application installe une DLL (que nous utilisons, mais dans une version incompatible) dans un répertoire système, alors cette DLL est trouvée avant et les ennuis commencent.
Une autre solution à laquelle je pensais est de jouer avec le répertoire courant (le faire pointer sur $PREFIX/bin) mais il se trouve que si SafeDllSearchMode est activé (apparemment une valeur de la base de registre), le répertoire courant est soudainement cherché après les répertoires système aussi! Donc ça marcherait plus (enfin surtout ça dépendrait de la configuration de l'OS).
La solution est donc d'utiliser SetDllDirectoryW() pour donner la priorité à $PREFIX/bin, et pour être précis le mettre entre le répertoire du binaire (permettant aux plug-ins de bypasser nos biblios au besoin) et les répertoires système. C'est donc une solution au niveau du code.
Un cas supplémentaire que nous avons corrigé dans 2.10.6 fut les plug-ins 32-bit lancé dans un environnement 64-bit. Dans ce cas, on doit leur donner un répertoire différent avec des versions 32-bit de nos bibliothèques (on le met dans $PREFIX/32/bin par défaut, mais j'ai mis un flag pour changer ce répertoire à la compilation). Je détecte donc le bitness d'un plug-in avant de le lancer et lui assigne le bon répertoire de bibliothèques avec SetDllDirectoryW().
Un nouveau cas dont j'ai récemment pris connaissance (et pas encore corrigé) est les plug-ins scripts lancés par un interpréteur 32-bit sur environnement 64-bit (si le script utilise des bibliothèques compilées). Dans ce cas, on devra détecter le bitness de l'interpréteur.
Par exemple notre installeur embarque seulement Python en 32-bit (je ne suis pas sûr pourquoi). Donc des scripts python un peu complexe qui utilise des biblios C risquent de ne pas fonctionner.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Dans votre article, si je veux vous soutenir GIMP c'est pour des projets tierces (la marmotte, tout ça…).
Ce projet tiers est ce qui permet de contribuer à GIMP et a fait de moi l'un des plus gros développeurs de GIMP ces dernières années (même le plus gros selon le décompte).
C'est simple, sans ZeMarmot, pas de GIMP. Je contribuerai alors sûrement à d'autres logiciels libres, selon mes autres besoins, mais je n'ai pas besoin de GIMP personnellement plus que ça (enfin régulièrement, je découpe, redresse, rend plus net, etc. des photos; mais pour cette utilisation basique, GIMP est déjà largement au niveau). Là on en a vraiment besoin, dans un projet professionnel, au quotidien 8h par jour.
(0) On a besoin qu'il soit stable. Quand on faisait les premiers tests avec Aryeom Han, GIMP crashait pour un rien (c'était vers 2012). Ça foutait la honte. Mes premières années de contribution, j'ai corrigé beaucoup de crashs (de mémoire, y en avait en utilisant une tablette graphique; y en avait aussi des supers mauvais lorsqu'on utilisait un IME, en particulier avec le coréen, dans l'outil texte, et plein d'autres dont je me souviens même plus) et autres problèmes de stabilité. Bon j'en corrige encore régulièrement, mais GIMP est devenu beaucoup plus stable.
(1) Toujours dans la recherche de stabilité, on a besoin de pouvoir aisément débugger et parer aux problèmes (qui arrivent sur tous logiciels même les plus stables). Donc j'ai implémenté une sauvegarde des images au moment du crash (pour ces bugs survivants qu'on n'a pas encore corrigés!), et GIMP propose maintenant au lancement suivant de tenter une récupération des images qui étaient en cours d'édition, ainsi qu'un système de débug qui génère automatiquement des backtraces, non seulement pour les crashs, mais aussi utilisables lors de WARNING et CRITICAL en cours d'utilisation (permet d'améliorer le logiciel en découvrant des bugs plus subtils). C'est l'une de mes fonctionnalités fétiches. Le nombre de bug qu'on a pu corriger depuis que j'ai implémenté cette fonctionnalité est impressionnant. Corriger des bugs est devenu simple, et les gens nous envoient désormais des rapports de bugs utiles, même lorsqu'ils ont aucune idée de ce qu'il s'est passé, qu'ils savent pas du tout parler anglais ni écrire des rapports de bug bien formés.
(2) On rajoute des fonctionnalités. Dernièrement je travaille beaucoup sur tous les détails pour les écrans haute densité de pixel (l'écran principal de travail d'Aryeom ne l'est pas pourtant, mais je sais qu'on y viendra; autant préparer GIMP en amont). Le système d'extension indiqué plus haut bien sûr me semble important. Nous aussi on utilise quelques plug-ins, mais très peu. Franchement c'est impossible de savoir ce qui existe et ce en quoi on peut faire confiance. Et surtout chercher, installer et faire marcher des vieux plug-ins peut être une vraie galère (et pourtant je suis développeur, c'est dire!).
Dans les quelques années passées, j'ai été responsable de plusieurs autres fonctionnalités, et je travaille à d'autres fonctionnalités encore (comme l'animation, comme on sait ici).
(3) On fait de la revue de code. Ça paraît bien moins sexy, mais c'est primordial. L'histoire de GIMP est parsemée de fonctionnalités sympas qui ont été perdues car personne n'a eu le temps de les vérifier. Je ne jette la pierre à personne: ça prend un temps fou. Dans cette sortie par exemple, l'écriture verticale n'aurait probablement jamais été intégré sans moi (je suis allé chercher le contributeur, j'ai fait la revue, les tests, les commentaires sur chacune de ses modifications; en tout j'y ai passé quelques heures).
Même le Marathi, j'ai vu un email perdu sur la liste de discussion des traducteurs auquel personne ne répondait; le problème est que cette langue n'avait plus de coordinateurs. J'ai donc essayé de relancer à la place des traducteurs (qui allait sûrement abandonner à un moment donné) et de leur donner espoir pour ne pas les décevoir (un espoir qui a abouti!).
Le redressement horizontal, j'ai retrouvé un vieux patch perdu dans le bugtracker et très basique. J'ai fait de la revue, retravaillé au dessus (car il n'était pas vraiment utilisable en l'état); Ell a fait de même ensuite. Et maintenant ça fait une super fonctionnalité.
Dans le passé, je me souviens bien de la recherche d'action (une de mes fonctionnalités préférées!). J'y ai passé un temps considérable. Le patch était cool, mais écrit par des étudiants. J'y ai passé de très nombreuses heures à corriger ce qui devait l'être, à rendre la fonctionnalité vraiment utilisable simplement, et à l'améliorer énormément. Maintenant je pourrais pas faire sans!
Pour info, dans GIMP, on a des règles stricts et du code de très bonne qualité globalement (bien sûr plus localement, on trouve beaucoup d'horreurs ici et là, comme dans tout gros code). Donc la revue est primordiale. On fait pas comme certains logiciels qui acceptent tout et n'importe quoi.
(4) On fait évoluer la politique interne. Je suis celui notamment qui a poussé depuis plusieurs années (tous les ans, à chaque fois qu'on se rencontrait au Libre Graphics Meeting) pour une nouvelle politique de sortie permettant de sortir des versions macros avec de nouvelles fonctionnalités (plutôt qu'attendre 6 ans encore pour une sortie majeure!). Et voilà, maintenant tous les mois, GIMP sort avec des fonctionnalités cool. Les gens se disent maintenant que GIMP est super actif, et on se met à avoir plus de contributions (j'ai l'impression; mais ça peut aussi être simplement car on a sorti 2.10, ou autres raisons).
(5) On a créé et on maintient le flatpak pour que les linuxiens aient GIMP facilement et rapidement à chaque sortie (GIMP est maintenant dispo sous Linux à chaque sortie avant toutes les autres plateformes!).
Et sûrement plein d'autres choses.
Ensuite soyons clair: je ne souhaite pas mettre tous les éclairages sur ZeMarmot uniquement. En particulier le mainteneur, Mitch, fait un travail de dingue, connaît le code de GIMP et ses rouages bien mieux que moi. Sans parler de Ell, un alien venu d'ailleurs, qui nous optimise GIMP aux petits oignons (avec du code d'excellente qualité) depuis qu'il est arrivé. Je ne suis pas seul (heureusement!), et on a tous les 3 une grosse part dans le succès de GIMP.
Mais clairement je ne pense pas que ce soit exagéré d'affirmer que le projet ZeMarmot a vraiment contribué largement à propulser GIMP dans une nouvelle ère. On travaille sur GIMP pour un vrai projet, au quotidien (oui je me répète) et ça vaut énormément de contributions aléatoires sans but. C'est un peu une symbiose de l'artiste et des outils. Chacun a besoin de l'autre.
Si avec cela, ce n'est pas suffisant, alors je ne sais pas ce qui l'est. Je rappelle qu'on est officiellement associé à GIMP d'ailleurs (bien sûr même! Je suis un dév majeur). Même le site web gimp.org suggère de donner directement à ZeMarmot sur la page donation, ainsi que dans ses news régulières (comme la dernière news dont cette dépêche sur Linuxfr est plus ou moins une traduction un peu retravaillée). J'aurais du mal à voir comment ça pourrait être plus limpide. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
On sait pas trop non plus. J'ai aussi vu passer des trucs vite fait, mais rien qui dit clairement "c'est bon, tout va bien". Ils font pas beaucoup de communications, c'est dommage.
J'aime beaucoup Liberapay, mais tant qu'on n'a pas de message clair comme quoi ils sont à nouveau dans la course, on peut pas vraiment donner le lien.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Tu me reprends sur la distinction entre manager et gérer ? :)
Tu parles du fait que c'est de la gestion d'extension dans GIMP? Si oui, bien sûr que là on parle de gestion (c'est même le titre), mais il s'agit du fait d'installer, désinstaller, mettre à jour et afficher des infos sur des extensions. C'est la partie côté cliente.
Ça veut pas dire qu'on gère l'extension au sens de vraiment s'en occuper. Si elle est bourrée de bugs, si elle marche pas même, c'est pas notre problème au delà de fournir des outils (pas immédiatement, mais probablement rapidement) pour que les gens puissent indiquer une extension qui fonctionne ou pas sur telle ou telle version de GIMP. Et si l'extension n'est pas maintenue, on ne s'en occupera pas plus.
Je dirais que c'est notre problème si on découvre des malware et là oui, on intervient et on vire l'extension. À ce moment, quand il y a intention malfaisante évidente (ou grosse faille de sécurité très dangereuse), il est évidemment de notre responsabilité de réagir. Mais ça s'arrête là. C'est en ce sens là qu'on ne gère pas les extensions (côté serveur) au delà de proposer aux gens de les héberger.
Ça se discute. Tu pensais faire des revues pour les brosses par exemple ? Ce sont des vecteurs d'attaque eux aussi. On peut voir le chargement d'un fichier comme une exécution d'un programme dans une sandbox et c'est régulièrement un vecteur d'attaque.
Les données inertes (brosses, images splash, thèmes, icônes, dégradés, etc.) ne subiront en effet pas de revue préalable, contrairement aux données exécutées (plug-ins) qui doivent être évidemment validées avant d'être diffusées.
Ensuite bien sûr que des vecteurs d'attaques peuvent exister avec des données inertes. Cela a toujours existé et existera toujours. On a tous entendu parler de failles permettant d'exécuter du code caché dans des images par exemple.
Néanmoins cela n'est pas un comportement normal, et ainsi dire "On peut voir le chargement d'un fichier comme une exécution d'un programme dans une sandbox" est faux, en tous cas pour le type de fichiers que tu cites (brosses) ou que je cite (images) [bien sûr, il existe des fichiers avec du code fait pour être exécutés, comme les fameuses macros de traitement de texte; de tels fichiers doivent donc être considérés comme du code]. Donc non, charger une bosse ou une image n'est pas la même chose qu'exécuter un programme. Ce sont des données inertes faites pour une utilisation donnée, pas pour exécuter du code tiers. Quand cela arrive, c'est un comportement anormal, autrement dit un bug (le plus souvent dans le logiciel, parfois dans le format lui-même) et qui doit alors être corrigé.
Aussi cela n'a rien à voir avec les extensions. Ce type de bug, quand il existe, existerait déjà dans GIMP et pourrait déjà se produire. Les extensions ne sont qu'un conteneur supplémentaire (ajoutant un peu de sémantique au contenu, indiquant de quoi il s'agit, un nom, une description, des liens annexes, une version, etc.).
Alors c'est pas si simple, je sais que ce n'est même pas le début du projet, mais ça rend publique toute une politique et ça vous expose à du bad buzz (grand publique ou de communauté), des discussions interminables, etc.
Les haters ont toujours existé et existeront toujours. Je le sais bien, je parle moi-même régulièrement sur Linuxfr de cela. Soyons clair, ça me touche et c'est dur. Mais je ne vois pas en quoi faire ou non des extensions pourrait changer quoi que ce soit à cela.
En fait par rapport aux comportements inadéquats, ma politique perso est de rester neutre (si possible, parfois c'est dur de tenir) et d'expliquer aux gens justement ce que je disais: GIMP est un logiciel libre, le logiciel libre, ça ne marche pas comme ils semblent le penser. En plus on n'est pas une entreprise, et on développe de façon volontaire. Et non, on ne réagit pas bien aux menaces et insultes. Par contre on est heureux d'aider les gens agréables, et tout ce qu'on demande, c'est que ces gens comprennent aussi ce qu'il en est, et qu'on contribue principalement bénévolement, souvent sur du temps libre.
Eh ben, tu me croiras peut-être pas, mais être clair (et poli) désamorce pas mal de situations. Les gens se rendent compte qu'ils ont un peu été des malotrus, se calment, parfois même (ça arrive!) s'excusent.
Ensuite oui, ça n'est pas du 100%. Et certains sont juste là pour haïr, comme je disais. On ne peut rien pour cela. Mais encore une fois, je vois pas le rapport avec les extensions. Ces personnes trouveront de quoi redire pour chaque nouvelle fonctionnalité qu'on apportera. On va quand même pas s'arrêter d'améliorer nos logiciels pour ces gens là! En tous cas, perso, c'est pas pour eux que je développe. :-)
est-ce que les développeurs auront suffisamment la foie pour ne jeter l'éponge ?
Je crois que tu cherches des problèmes là où y en a pas. :-)
Pourquoi qui que ce soit jetterait l'éponge pour quelques aigris? Si ça devait arriver, crois moi, ça serait arrivé y a trèèèès longtemps (comme tout gros logiciel connu, on collectionne quelques aigris).
Au pire du pire, si vraiment ça se passait super mal, on pourra toujours arrêter notre système d'extensions tiers (et n'héberger que nos propres extensions, voire un choix très restreint d'extensions sélectionnées au cas par cas, comme quelqu'un le propose plus haut). Perso je trouverais cela un peu dommage, mais si on devait en arriver là, c'est pas la mort.
Soyons clair, je ne pense pas qu'on en arrivera là. Je vois aucune raison à cela.
Ah oui, et:
bad buzz
Encore une fois, du vocabulaire de startup hipster. On s'en fout du "bad buzz". Je dirais même qu'on vit dans un monde où cela n'existe pas. Il y a des gens sympas, des gens moins sympas, ça s'arrête là. Si ce prétendu grand méchant bad buzz devait avoir eu raison de nous, ça serait arrivé y a très longtemps.
Je préfère t'avertir de mes craintes, pour que tu sois moins surpris si (malheureusement) ça arrive.
Merci beaucoup de t'inquiéter pour nous.
Je pense perso que tu te fais du mouron pour rien. :P
Si le type de problème dont tu parles devait arriver, je pense pas que ce soit parce qu'on ait ajouté un système de gestion d'extension dans GIMP. Ahahahah!
Sur ce, j'arrête de répondre sur cette news. J'ai un peu l'impression de trop l'accaparer en hors-sujet là, alors que c'est censé parler de ce super logiciel qu'est G'Mic. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Nos installeurs contiennent la version 32 et 64-bit et installent la version appropriée. C'est écrit juste sous le bouton de téléchargement. Donc prends simplement l'installeur unique et ça te mettra la bonne version.
ou en fait uniquement pour Windows >=7
Ça oui par contre. C'est pas qu'on veut pas prendre en charge de plus vieux Windows, mais on n'a quasi aucun dév Windows (approximativement 0) alors on fait ce qu'on peut. Prendre en charge de vieilles versions veut dire plus de boulot car on doit contourner des problèmes de manières plus compliquées (même si des versions récentes ont peut-être amené des solutions simples).
Notre ligne directrice pour savoir si on prend en charge un OS (Windows ou macOS), c'est que cette version de l'OS doit au moins être encore pris en charge par son éditeur. Windows XP, y a plus de support depuis avril 2014 (d'après Wikipédia) et on parle quand même d'un système sorti en 2001, soit y a 17 ans!
Il est peut-être temps de mettre à jour. Et si le matériel est juste trop ancien, on peut mettre un Linux avec bureau léger. Ou si vraiment on est nostalgique des vieilles années et qu'on veut garder l'OS d'époque absolument (faire attention à l'accès internet, etc. dans ce cas), ben on prend sur soi et on garde aussi les vieux logiciels (y compris GIMP 2.8). :-)
Enfin bon, tout cela pour dire qu'il n'y a pas vraiment de solutions miracle, désolé. On peut pas prendre en charge indéfiniment un système, surtout si même son éditeur ne veut plus le prendre en charge. Ce serait vraiment se tirer une balle dans le pied.
Je veux bien le compiler, mais c'est possible de le compiler en 32 bits pour XP (et un CPU Pentium3) avec Visual Studio (MSVC), ou faut obligatoirement utiliser un autre système de build ?
Tout est possible. Ensuite je crois que la plupart des gens qui compilent GIMP pour Windows le font depuis un Linux (même notre build officiel est cross-compilé, il me semble). Donc ce sera clairement cela le plus simple.
Et je suis pas certain que ce build fonctionnera de toutes façons. Ne pas prendre en charge Windows XP, ça veut surtout dire qu'on a peut-être (probablement) utilisé des APIs Windows qui n'existaient pas encore dans XP. Donc tu te retrouveras à devoir patcher le code en fonction des parties qui poseront problème. Si tu le fais sans perte de fonctionnalité ni rendre le code surcompliqué (et avec un code propre), on veut bien le patch (on n'est pas absolument contre Windows XP, on ne le prend pas officiellement en charge, c'est tout).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Quand tu gère des extensions du deviens responsable au moins en parti d'elles.
On ne les gèrera pas. On les hébergera. Mais oui tu as raison quand même qu'on aura notre part de responsabilité.
Actuellement rien ne cloisonne les extensions, donc tu veux faire de la revue et le build chez toi.
Même si GIMP lançait des sandbox, la revue et compilation doivent être faites de notre côté. Héberger aveuglément un binaire d'inconnus complets est une aberration.
C'est la raison pour laquelle les plug-ins compilés ne seront pas acceptés tant qu'on n'aura pas l'infra. Certains bénéficieront d'exception évidente comme G'Mic. C'est expliqué dans mon article.
C'est super comme idée, mais je crains que ça ne consomme toute ton énergie (je serais heureux de me tromper !)
Je ne prévois pas de gérer le site. Je suis développeur pas animateur de communautés. Nous avons une très grosse communauté avec des gens très actifs et même pas mal plutôt techniques. Des gens comme Pat David et Elle Stone seront parfaitement capables de gérer le quotidien (et de sélectionner les futur modérateurs si le contenu grossit vite).
Aussi on pourra y aller lentement. Si les gens sont pas contents du temps de revue, ce n'est pas notre problème. L'un des énormes avantages que l'on a est qu'on n'essaie pas de faire du business. Nos actions ne sont pas dirigées par des contraintes économiques. Ça rend GIMP très résistant aux problèmes car personne ne peut nous forcer à rien ni nous presser.
Bon j'arrête là. Cette dépêche est au sujet de G'Mic pas de GIMP! :P
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Non ce n'est pas envisageable. De même que notre installeur Windows ne contient pas G'Mic (pas plus que tout autre plug-in tiers), ni notre DMG pour macOS.
Les builds officiels de GIMP ne contiennent (et ne contiendront toujours) que les plug-ins core de GIMP, c'est à dire ceux maintenus par les développeurs de GIMP. On a déjà bien suffisamment de boulot (avec très peu de développeurs) pour ne pas non plus se donner plus de travail. En outre si quelqu'un fournit un paquet, il est de-facto responsable de son contenu (or on ne développe/maintient pas G'Mic). Pour G'Mic, c'est un logiciel suffisamment complexe et élaborée pour qu'on se rende bien compte que si David venait à arrêter demain (on touche du bois pour que ça ne soit pas le cas!), on ne serait pas à même de le maintenir à sa juste valeur.
Donc non, on ne peut pas.
De même que David, je pense qu'il préfère garder l'indépendance dans ses sorties, etc. et ne pas dépendre de nos choix de sortie.
La tendance est plus à la création d'un système d'extension (voir ma news pour GIMP 2.10.6 qui devrait être publiée d'ici quelques jours) qui permettra d'installer facilement G'Mic et autres plug-ins, tout en laissant les développeurs de ces plug-ins en garder la main complète. Tout le monde y gagne. Et je sais, de source sûre, que David aime l'idée. ;-)
D'ailleurs une fois que cela sera en place, il est même possible que certains des plug-ins core actuels puissent devenir des extensions à leur tour (toujours maintenus par nous, mais avec un rythme de développement parallèle), ce qui permettrait des menus moins touffus de fonctions que peu de monde utilisent par exemple. À voir…
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Perso je pense que la prévisu sur canevas serait super utile, même pour les traitements lents.
Pour ma part, je trouve donc que l'idée d'adopter systématiquement une prévisualisation on-canvas n'est pas excellente.
La prévisualisation n'a pas à être activée par défaut. ;-)
Il vaut mieux dans ce cas pouvoir effectuer les traitements plutôt sur de petites portions d'images pour prévisualiser le résultat.
GIMP donne aussi la priorité au rendu de la partie visible à l'écran, et le mipmapping aide aussi beaucoup si un zoom (avant ou arrière) est fait. Et je sens que les choses vont s'améliorer encore dans le futur pour optimiser la sensation de fluidité (ou du moins de pas avoir une expérience trop désagréable), même avec des traitements lents.
L'édition non-destructive aura a priori le même genre de limitations.
Ce sera clairement utile pour l'édition non-destructive également. Faire un changement dans les paramètres d'un effet peut te prendre 10 minutes, mais dans tous les cas, tu devras le refaire (ton effet). Dans le cas de l'édition non destructive, au moins tu pourras voir les paramètres utilisés précédemment et repartir de là. Dans le cas de l'édition destructive, tu as intérêt à avoir bien gardé une copie du calque d'origine et tu ne sais même pas l'ensemble des traitements faits, et avec quels paramètres, à part si tu les as notés bien consciencieusement (ce que certains font dans le nom du calque par exemple).
Pour moi, il n'y a rien d'équivoque là. Mais je crois qu'on a déjà eu cette discussion et qu'on pourra encore l'avoir à l'avenir. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
j'ai aussi souvenir d'un dev' de chez GNOME ou GIMP, je ne sais plus, assez imbus de lui-même, qui ne donnait pas spécialement envie d'utiliser GIMP
Je ne contribue que depuis (relativement) récemment, c'est à dire depuis 2012. Mais il paraît que certains des anciens contributeurs de l'époque d'avant n'étaient pas très cool, voire peut-être même un peu toxique. Mais ce n'est que du "on dit" car je ne les ai pas connus.
En tous cas, de nos jours, ce n'est plus le cas. :-)
[HS]Vous ne faites plus de lives ZeMarmot ? J'y passais de temps en temps même s'il n'y avait pas grand monde, c'était reposant de regarder quelqu'un dessiner. Après j'imagine que monter tout le setup pour si peu de résultat était peut-être un peu frustrant.[/HS]
On a un peu mis en pause pour diverses raisons. Déjà y a le côté technique. Le logiciel de streaming (libre) faisait quand même beaucoup souffler la machine (qui a déjà beaucoup à faire quand on fait de l'animation), voire était plutôt instable (cela nécessite OpenGL 3.2, ce qui veut dire qu'on doit installer les pilotes Nvidia proprio, et même là, ce n'est pas parfait). Le pire n'est pas seulement que ça plantait parfois, mais qu'il arrivait à faire freezer la session graphique de temps en temps. OBS Studio est cependant très connu et une référence a priori chez les gens qui font du live, même s'ils savent pas que c'est libre. Y a peut-être quelque chose à configurer mieux. Et aussi j'ai cru comprendre que la version Linux est moins stable de manière générale. À voir…
Ensuite oui, y avait pas tant de monde, et on se disait que ça valait pas forcément le coup.
Mais surtout, Aryeom a eu une petite période de blues ces derniers mois (je l'ai déjà dit, l'un comme l'autre, on se pose beaucoup de questions; on nous dit constamment que GIMP peut lever beaucoup de financement participatif, mais dans les faits, notre financement est faible), voire un petit burnout. Donc elle a préféré continuer à travailler sans les lives. Mais là je lui ai montré ton message, et elle se dit qu'il faut peut-être les recommencer. On verra!
P.S.: ne pas hésiter à laisser un message si on reprend les lives. Ça fait toujours plaisir et ça donne moins l'impression de faire un direct dans le vide. Faut pas donner tous les mercis qu'à moi. Y aurait rien de tout cela sans Aryeom non plus.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
"22 commits par jour"
[…]
Tu parles de "depuis 2.10.2" et je ne sais pas quand tu as fait le calcul
Je ne me souviens plus du calcul exact de l'époque mais je peux en refaire un.
En gros, je regarderais les commits faits entre GIMP 2.10.2 et 2.10.4, et ce, sur master, car c'est là où se passe vraiment le développement (pas sur la branche gimp-2-10 en particulier qui ne contient que les backports pour la série stable).
Sur master, y a un tag GIMP_2_10_2 mais pas GIMP_2_10_4 car on a créé la branche gimp-2-10 justement à la sortie de GIMP 2.10.2 (donc c'est là où les 2 branches ont commencé à diverger). Pour le commit d'arrêt, je vais donc prendre un commit qui correspond à la date de sortie de GIMP 2.10.4, soit le 2018-07-04. Je prends le dernier commit à cette date. Note que ce n'est probablement pas le calcul que j'avais fait à l'époque, car j'imagine que j'avais pris HEAD qui était sûrement différent à l'époque (soit un peu avant, soit un peu après la sortie. Je ne suis pas sûr quand j'ai démarré cette dépêche collaborative). Quoiqu'il en soit, voyons le nombre de commits:
Comme il s'agit d'une période de 45 jours, je fais une moyenne, soit: 972 / 45 ≈ 21,6. Voilà (avec un arrondi, ça fait 22 ;p).
Ensuite soyons clair: GIMP 2.10.2 est le moment où on a divergé vers le port GTK+3, comme je viens de le dire, donc ça veut notamment dire qu'on a mergé tout le travail fait sur GTK+3 (dont la majorité avait été faite ce même avril/mai, après la sortie de GIMP 2.10.0!) d'un seul coup. En un sens, ça a clairement boosté les statistiques. D'un autre côté, tant qu'on ne merge pas une branche de fonctionnalité, elle ne rentre dans aucune statistique. Faut bien qu'elle le rentre un jour (de même que j'ai des dizaines de commits qui attendent dans des branches de fonctionnalité en cours, et un jour, je les verserai dans master d'un coup, mais en attendant, c'est comme si ils n'existaient pas). De toutes façons, il y avait clairement un moment, qui correspond à la sortie de GIMP 2.10.0 où on a vraiment eu un gros pic de contributions.
Si maintenant tu remontes plus loin, par exemple le début d'année, comme tu le proposes, on a une moyenne à 11 commits par jours:
"plusieurs années que le développement est aussi actif"
De manière générale, il y a forcément des hauts et des bas dans le développement. Surtout que comme on est 3 à faire la plupart des commits, forcément il suffit qu'il y ait une période où l'un de nous est peu actif pour que les stats baissent (par exemple pour le mainteneur, c'est souvent les fins d'année où il a moins le temps de contribuer car il a un commerce), de même qu'y a des périodes où tout le monde s'active. Quand je dis qu'on est très actif depuis des années, ça veut pas dire qu'y un taux constant de contributions à tout moment (ce serait pas humain!). D'ailleurs, ailleurs dans un commentaire, je dis même que notre développement s'accélère au contraire (ce qui ne veut pas dire que ça ne va pas se calmer à un moment, et puis de toutes façons, il y a des limites humaines à notre rythme de contributions!). Voilà, donc en gros, faut pas non plus s'attacher au mot près. Je donnais les stats entre 2.10.2 et 2.10.4, qui étaient effectivement de 22 commits par jour en comptant dans git, et c'était effectivement un très gros pic.
Enfin les stats, c'est aussi beaucoup du "marketing", soyons clair. De toutes façons, on peut faire dire beaucoup de choses aux nombres, on le sait tous. Rien que le choix d'unités est sujet à critique. Un commit, est-ce vraiment un critère adéquat? Faut-il compter le nombre de lignes à la place? Compte-t-on alors les lignes de commentaires (important aussi) ou juste le code pur et dur? Et qu'en est-il de ceux qui ont un code plus concis ou plus élagué (par exemple déclaration et définition sur des lignes distinctes, etc.)? Comment compte-t-on le temps de recherche, diagnostic, lecture de docs? Le temps pris pour des choses (importantes) autre que du code (écriture de news, docs, etc.), même? D'ailleurs peut-on même simplement compter le temps passé par les contributeurs pour GIMP (réponse directe: non, c'est du logiciel libre, on sait pas combien de temps passe chacun), et alors qu'en est-il des gens simplement plus efficaces que d'autres? Etc. Etc. Etc.
Ma conclusion, c'est que ce sont des stats. Les miennes étaient vraies (comme montrées plus haut) car notre branche master a réellement 22 commits par jour entre GIMP_2_10_2 et la sortie de 2.10.4. Ensuite ça vaut ce que ça vaut (pas grand chose, ou beaucoup, c'est selon).
Là où je voulais en venir avec ces stats, c'est que c'est du développement vraiment très actif. Et d'ailleurs tu es d'accord sur ce point. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ah je pensais que tu parlais du développement en cours, parce qu'on nous fait souvent la remarque qu'on devrait sauter direct à GTK+4. On y a pensé nous-même d'ailleurs (on a une news vieille d'avant même la sortie de 2.10 où on évoque la possibilité) mais on a décidé que ce n'est pas une bonne idée (pas avant stabilisation du moins).
Je sais bien qu'on approche enfin du bout du tunnel et que la prochaine version majeure sera la bonne, mais je doute que ce soit encore pour cette année. Je me trompe ? :D
Ahahah. Qui sait?! Moi j'en sais rien en tous cas. On y travaille, mais on donne pas de dates. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je pense que tu te méprend sur mon commentaire (ou alors, je me suis vraiment mal exprimé, et je m'en excuse).
T'inquiètes, je n'avais pas pris mal ton commentaire. J'essayais simplement d'y répondre pertinemment. Le fait est que quand on fait quelque chose similaire à notre projet, on semble se récolter tous les conseils du monde. Ce n'est pas mal, soyons clair. C'est un peu fatigant, mais ce n'est pas mal. D'ailleurs je suis sûrement aussi le premier à donner des conseils à d'autres quand ils se lancent par exemple en indépendant (je ne suis d'ailleurs pas certains si mes conseils sont si pertinents et si je contribue pas à fatiguer ces gens, même s'ils ne me le disent pas par politesse).
Le truc, c'est aussi que beaucoup de ces conseils sont des trucs que je sais, ou même que je sais ne pas marcher, voire souvent que j'ai déjà essayé maintes fois. Je pourrais te citer toute une liste des classiques (mais je vais pas le faire sinon rallonger encore plus le commentaire).
Dans ce fil, on me propose de faire une fondation GIMP (je l'ai entendu 20 fois), qu'il faut plus d'argent (captain Obvious), que beaucoup attendent les fonctionnalités X ou Y (on accepte les patchs!). D'ailleurs la pertinence de ta liste de fonctionnalités est vraiment sujette à question. Genre quand tu me dis:
Et même si le développement est vraiment actif, la première chose que l'on voit, c'est que Gtk+ 4 va bientôt sortir, mais que GIMP utilise toujours une version obsolète
Ben… non GTK+3 n'est pas obsolète. C'est la version à jour de GTK+. Non, on ne va pas commencer à travailler sur une version "mouvante", pas sortie et donc qui va constamment casser son API. On a bien assez de boulot (et comme tu le notes, on est peu nombreux). Travailler sur une version de développement serait comme se tirer une balle dans le pieds pour être sûr que GIMP 3 ne sorte jamais (ou dans 10 ans) et qu'on ait constamment à corriger notre code (comme si on n'avait pas assez de travail!). Surtout qu'on parle de GIMP, pas d'une petite application mono-fonctionnalité de 10 000 lignes de code (qui elle, oui, peut se permettre des changements dans son toolkit, éventuellement… enfin si elle ne prévoit pas de sortir d'ici quelques années!).
Nous avons une règle au sujet de nos dépendances pour la branche master: il faut qu'elle soit dispo dans Debian Testing. Cela la rend suffisamment récente pour travailler avec des dépendances qui ne sont pas dépassées, et en même temps, on sait que cette dépendance fera son apparition dans les autres distribs d'ici 1 an ou 2.
Attendons que GTK+4 sorte et soit stable pour le considérer.
Tu vois, clairement, c'est aussi un conseil de quelqu'un qui n'est pas sur le terrain. :P
Mais reconnais que vous êtes une petite équipe. Si demain il devait arriver malheur à l'un d'entre vous (ne serait-ce que Mitch ou toi), ou que pour x raison vous ayez soudainement envie de passer à autre chose, le développement serait sérieusement ralenti.
C'est vrai, mais c'est le cas de 99.99% des logiciels Libres. Je viens de regarder (encore) l'activité de Blender. Ils ont à peine plus de gros développeurs que nous (si je regarde 2018, je dirais 4 vraiment gros développeurs). Ensuite oui, je suis sûr que Firefox ou Apache n'ont pas ce problème. Mais pour en arriver là, ce n'est pas juste un ou 2 commerciaux qu'il faut engager.
Donc non, la professionnalisation ce n'est pas un gros mot.
Et je suis totalement d'accord, puisque j'ai répondu que c'est exactement ce que l'on fait! ;-)
Comme l'a mieux expliqué Zatalyz, ça commence par trouver quelqu'un capable de faire du marketing et trouver des financements
Il y a un million de trucs à répondre à ça! Déjà, comment le paie-t-on? On est une asso, on fait du tout-libre, etc. Donc effectivement si quelqu'un veut aider bénévolement parce qu'il veut promouvoir le la création Libre (un des objectifs de l'asso), on n'est pas contre. Dans les faits, on a eu des aides ponctuelles déjà, de par le passé, mais on ne va pas pousser ces gens à travailler d'arrache-pied sans être payés. Perso j'aimerais que tous ceux qui travaillent soient payés (correctement en plus), idéalement. Je fais partie de ces gens qui considèrent que c'est normal de payer quelqu'un pour un travail et je ne veux surtout pas trop profiter des gens (même raison pour laquelle je n'aime pas les stages par exemples, et surtout les stages non-payés; on nous en a encore proposé y a pas longtemps et c'est pour moi de l'exploitation de jeune mains d'œuvre). Or si on paye cette personne, ben nous on n'a plus de sous (je rappelle que depuis quelques années, on jongle avec quasi rien).
Ensuite y a la fameuse réponse, oui mais cette personne est censée ramener plus que ce qu'elle coûte! Donc une fois engagée, elle ramènera de quoi vous payer. Déjà ce n'est pas sûr. De même que j'expliquais qu'il peut y avoir de mauvais dévs, il peut aussi y avoir de mauvais commerciaux (quand on parle de financement, ou marketing pour la pub; au passage, tu me parles de 2 postes différents là comme si c'était la même chose!). Donc ce n'est pas sûr qu'ils ramènent quoi que ce soit. Peut-être se retrouvera-t-on à les payer pendant 6 mois sans qu'il n'y ait aucun retour puis on doit leur dire au revoir, et entretemps, le projet a pu tomber à l'eau (car un développeur et une réalisatrice, ça mange aussi). Ensuite y a le fameux sujet: ces gens sont-ils vraiment ceux qui ramènent l'argent? On retrouve souvent ce sujet de discussion lorsqu'on se demande s'il est vraiment normal de payer des CEOs des prix exorbitants (et l'une des 2 réponses est souvent: oui mais ils sont censés ramener plus que leur salaire). Soyons honnête 2 minutes, les commerciaux sont ceux qui mettent leur nom sur le papier et qui signent, mais en général, sans le travail des techniciens (développeurs, animateurs, etc.) qu'ils ont vendus, y aurait rien eu à vendre. Prenons l'exemple de cette récente donation de 400 000 $ à GNOME/GIMP. Cela a-t-il été ramené par les commerciaux/CEO en arrière-plan qui ont démarché le donateur? Peut-être (ou pas, j'en sais rien, c'est pas écrit). Ce donateur aurait-il donné de toutes façons si y avait juste eu des développeurs parce qu'il aime GNOME/GIMP indépendamment d'un quelconque démarchage? Peut-être aussi. Le fait est qu'on n'en sait rien pour GNOME. Ce n'est malheureusement pas si simple à répondre, mais il est vraiment très pertinent de se poser la question.
Par contre côté GIMP, on peut répondre tout de suite: on ne savait rien de cette affaire, on n'a pas démarché, donc cette donation n'a rien à faire avec un quelconque marketing/commercial (et non ce n'est pas GNOME qui a demandé pour nous). Ce qui tend à invalider l'assertion qu'il faille du marketing pour de gros financements. :-P
je vois que chez Wikimedia […]
Très bon exemple, si je me souviens bien, à l'époque (qui a duré de nombreuses années, alors même que Wikipédia était déjà connue et dans le Top 10 mondial des sites visités), leur seul employé était un admin. Car au final, ça sert à rien d'avoir du marketing et du commercial si l'exécutif ne fonctionne pas. La première chose à faire, c'était d'avoir un site qui fonctionne. De même que pour nous, la première chose, c'est de faire un film. :-)
Ça ne serait pas mieux de ne plus avoir à se soucier de tous ces problèmes, de pouvoir bosser sereinement sur un projet qui te tient à coeur ?
Alors oui, je suis entièrement d'accord avec tout ce que tu dis sur le fond. Je ne me méprenais pas sur ton commentaire précédent non plus, de même que je veux être clair pour que tu ne te méprennes pas sur le mien. Mes réponses ne sont pas aigries ni en colère, ni quoi que ce soit de négatif. C'est pour cela que j'essaie de les parsemer de smileys (mais apparemment ça marche pas). Et là, quand je te réponds, je souris. Promis, c'est pas un mensonge! :P
Je sais aussi que mes longs commentaires à rallonge (j'arrive pas à faire court!) peuvent faire croire le contraire, mais ils ne signifient pas un état de désaccord.
Donc, reprenons: oui je suis d'accord… mais comme je l'ai expliqué, ce n'est pas si simple. Dire "il vous faut du marketing", c'est une recette de grand mère qui est à la fois évidente et à la fois pas en phase avec le monde réel qui ne prend pas en compte le fait qu'il faut payer cette personne, que ce n'est pas dit que cette personne va vraiment ramener des fonds, et surtout que ce n'est absolument pas sûr que je n'aurais plus à me soucier de rien. Par exemple, je l'ai dit, par le passé, on m'a déjà proposé de m'aider pour du financement (qu'on n'a pas eu), et au final, j'ai passé 90% du temps sur le dossier car c'est moi qui connaissais le mieux le dossier (note que je n'en veux pas du tout à cette personne qui m'a quand même aidé sur les 10% et je suis reconnaissant, mais c'est pas ce que j'appelle "ne plus se soucier des problèmes"). Ça c'est la réalité. :-)
Alors oui, LILA existe déjà (à qui je donne dix euros tous les mois)
Merci beaucoup pour cela! :-)
Perso je relativise notre taille. Oui on est petit et ridicule, et c'est pour cela qu'on ne peut pas engager quelqu'un en espérant qu'il soit doué et ramène soudainement beaucoup, tout en se mettant à négliger tout l'exécutif. En même temps, on arrive à tenir depuis quelques années. J'y crois personnellement. Certes cela ne m'empêche pas de régulièrement rappeler les gens de notre existence en demandant de nous soutenir, mais je suis confiant que ça va aller en s'améliorant, même si j'ai aussi mes périodes (très régulières) de doute.
En fait je pense que tes conseils sont vrais, mais simplement mettent la charrue avant les bœufs. Ils ne seront applicables que quand l'asso aura réussi à nous rémunérer convenablement d'abord. Un projet qui ne pense pas à l'exécutif d'abord ne vaut rien. Et ce jour là, quand on aura des sous en plus, alors on pourra penser à engager du marketing.
Wikipédia, c'était pareil, ils ont commencé par rémunérer l'exécutif. De même que la fondation Blender, quand ils ont eu des sous, ils ont payé du développement (et des animateurs avec leurs fameux Open Projects), etc. On ne commence pas un projet sans sous avec du marketing et du commercial. Enfin si, certains le font. On appelle ces projets des vaporwares. :P
En tous les cas, c'est mon point de vue et aussi la position de LILA à ce jour. Peut-être qu'on a tort (mais je crois pas).
Ah et dernier détail: tu ne peux pas nous comparer avec la Blender Foundation (née en 2002), la Wikimedia Foundation (2003), la Mozilla Foundation (2003), la Linux Foundation (2000) ou je-ne-sais quelle autre fondation ou association qui ont 15 ans ou plus, qui fonctionne confortablement et avec laquelle tu nous compares (nécessairement car tu cherches des points de comparaison et ce sont les organismes que l'on connaît bien dans le Libre). LILA existe techniquement depuis presque autant (on l'a fondé avec un ami en 2005, pour un projet de Musique Libre qui n'a pas connu le jour), mais dans les faits, elle est tombée en sommeil et est née à nouveau en 2015. Si tu veux nous comparer, prend les autres organismes nés récemment et tu verras qu'elles sont toutes aussi petites que nous, voire qu'elles ont plus de mal que nous.
Il y a 15 ans, déjà c'était plus simple car il y avait encore peu de projets, donc dès que l'un d'eux émergeait avec du code fonctionnel et commençait à se professionnaliser, les gens se ruaient dessus avec leur portefeuille ouvert. De nos jours, les projets florissent quotidiennement. Les gens donnent toujours, mais ils répartissent leurs dons. Regarde donc tous ces autres projets récents dans le Libre: ils ont tous autant de mal que nous.
En outre, même ces gros projets d'antan n'ont pas commencé avec les sommes de maintenant. Donc il faudrait nous comparer avec leur situation d'antan (probablement un peu meilleure que nous, car peu de projets à l'époque encore une fois, mais meilleure de très peu).
Voilà. Je pense qu'on peut conclure ici. Encore une fois, mes longues réponses ne sont ni des attaques ni des défenses (je ne me suis pas senti attaqué). Ce sont juste des explications de notre situation, et je le fais en détaillant un peu comment marchent les choses de mon point de vue (qui peut être erroné, mais en même temps, c'est ainsi que je le vis au quotidien, donc même si j'ai peut-être tort, j'ai du mal à m'en défaire). Et donc oui, on professionnalise le développement de GIMP et la réalisation d'un film libre (ce sont des faits; on a du mal, mais on y arrive en partie); mais non, je ne pense pas que cela peut passer par l'emploi de gens au marketing à notre stade (sauf s'ils veulent le faire bénévolement pour LILA, mais même là, on ne peut pas accepter n'importe qui juste parce qu'ils veulent, et surtout je peux pas aller les chercher: ils doivent proposer d'eux-même, c'est une partie de la définition du bénévolat).
Désolé. Je suis conscient que c'est pas facile de voir l'état d'esprit des gens à l'écrit, surtout avec un long pavé comme les miens. :P
Pour moi, vous êtes vraiment sur la bonne voie avec tout ce qui est mis en place ces dernières années, que ce soit avec Gimp ou The Marmot. J'espère que vous trouverez des renforts pour que ces financements puissent se débloquer :)
Merci. On pense aussi être sur la bonne voie, même si on est pas sûr que notre véhicule tiendra le coup jusqu'au bout parce que cette voie est un peu caillouteuse. Et oui on espère aussi qu'on trouvera du financement. ;-)
Si tu veux, et si tu es à Paris, je serais heureux d'en discuter autour d'un café (mon email traîne partout, notamment sur mes commits) et tu verras qu'il n'y avait pas méprise. Juste désaccord sur le process, mais sans aucun mauvais esprit. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Plus qu'une fondation, je pense que les gens attendent surtout une professionnalisation (même si tu préfères une bande de potes hippies :p)
Ben écoute d'un côté, on a une fondation (hypothétique) qui paieraient des salaires pour améliorer GIMP et de l'autre une association (non hypothétique, elle existe) qui paie des salaires pour améliorer GIMP. Mais le premier cas serait de la professionnalisation et le second une bande de potes hippies. Euh… Ce serait pas une nouvelle version du bon et du mauvais chasseur là? ;-)
Sérieusement c'est un peu triste. On a l'impression que vous vous attachez au nom. Parce qu'on n'a pas "GIMP" dans le nom, c'est soudainement pas "professionnel"? Ou alors je vois pas. Parce que soyons clair, c'est un peu la seule différence là.
accélération du développement
Je pense que peu de logiciels peuvent se targuer d'avoir un développement aussi intense que nous. Attention, je dis pas qu'y en a pas qui ont un développement encore plus actif. Je suis sûr que Firefox par exemple nous coiffe au poteau. Par contre comparons par exemple avec un logiciel tel que Blender.
Voyons le nombre de commits dans GIMP (master) depuis le début de l'année et depuis début 2017:
Voilà, GIMP a plus de 40% de commits en plus sur les 8 derniers mois. Ensuite si on remonte le temps, Blender gagne du terrain, on a à peu le même nombre de commits sur les 20 derniers mois et ça s'inverse en remontant plus loin. Notre activité n'a fait que s'accélérer depuis des années, continuellement. Je sais pas trop ce que tu veux de plus.
Et tout cela, avec en gros 3 core développeurs (Mitch, Ell et moi-même) qui faisons à peu près le quart des commits chacun (puis y a d'autres développeurs, certains plus réguliers que d'autres). Je crois qu'on n'a vraiment pas de quoi avoir honte de notre petite équipe. Peu peuvent se targuer d'une telle activité.
Comme tu le soulignes toi-même, c'est juste une histoire de perception (ou encore "a priori"). Un logiciel comme Blender, on va lire qu'ils sont méga actifs, etc. Mais pas GIMP? Ensuite cette perception n'est heureusement pas généralisée, car (comme je le dis dans l'article), notre image a vraiment changée et je ne lis plus personne dire que le développement de GIMP est lent. Tu es le premier que je lis ressortir cela depuis un bon moment. :P
Pour résumer, plus de pognon pour pouvoir faire plus de choses, puisque apparemment, les bénévoles compétents et motivés sur le long terme, ça ne court pas les rues.
Ben les employés compétents et motivés aussi, je t'assure. Je ne sais pas exactement ton champs d'activité (mais si tu traînes ici, les probabilités que ce soit quelque chose dans l'informatique sont grandes!), mais dans le développement logiciel, tu trouves aussi (c'est à dire comme dans tout métier) beaucoup d'incompétents. L'argent ne fait rien à l'affaire.
Et pour avoir eu aussi mes expériences professionnelles dans le développement logiciel en entreprise (comme on peut s'y attendre), laisse moi te dire que notre petite équipe de bénévoles "hippie" n'a vraiment rien à envier à tes supers employés qui seraient plus à même que nous d'offrir aux gens ce dont ils rêvent. Franchement j'ai rarement vu un tel regroupement de gens compétents que dans notre micro équipe (non seulement les 3 au cœur, mais aussi ceux qui bossent sur GEGL, ainsi que certains réguliers qui font pas tant de patchs, mais quand ils en font ou quand ils réagissent, tu te dis que tu aimerais bien les voir plus souvent!).
En conclusion, je voudrais boucler et revenir à ce que j'ai dit au début de ce commentaire: oui LILA est professionnelle. Et lever des fonds participatifs pour employer des développeurs est exactement ce que nous essayons de faire. Franchement avant de parler d'engager de nouveaux développeurs/designers, on aimerait bien pouvoir avoir au moins assez pour payer ceux qui contribuent actuellement et aimeraient bien en vivre (nous sommes 2: le mainteneur de GEGL et moi-même sur GIMP, voire 3 en comptant Aryeom qui de temps en temps fait des illustrations pour gimp.org, des icônes, des ateliers, ou autres, et surtout aide en donnant continuellement des retours pour améliorer GIMP et son interface en tant que professionnelle l'utilisant au quotidien; aucun de nous n'a actuellement assez pour financer un salaire minimum).
Je dois avouer avoir un peu du mal à comprendre. Beaucoup nous disent que si nous faisions des crowdfunding pour améliorer GIMP, ils donneraient. Mais la réalité, c'est qu'on le fait depuis environ 2 ans maintenant (et oui, c'est officiel, nos crowdfundings sont listés dans la page donation de GIMP). On a donc déjà professionnalisé GIMP depuis 2 ans. Il ne tient maintenant qu'à vous tous de nous permettre de ne pas abandonner en si bon chemin (parce qu'on y pense plutôt régulièrement malheureusement). :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Les fonds de GIMP ont toujours été gérés par la fondation GNOME. Cette annonce ne change absolument rien du tout. Mais vraiment rien.
Ensuite si on décide que cet argent peut aller en salaires, une partie peut éventuellement être donnée à LILA.
Encore une fois, relire mon commentaire. Je ne comprends pas pourquoi vous voulez absolument une "fondation" alors qu'on a déjà tout ce qu'il faut. C'est une obsession sur le nom?
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
D'un autre côté, on parle de centraliens. S'ils doivent faire un emprunt, ils devraient pouvoir le rembourser assez vite avec un brut moyen de 52 000 € par an.
Cela implique que les étudiants doivent rentrer dans les cases. Si une personne décide de ne pas aller vers un boulot classique d'ingénieur centralien, et probablement avec un salaire moindre, alors il ne peut plus rembourser. Donc on le force à faire quelque chose de sa vie qu'il ne veut pas forcément.
Je ne dis pas cela au hasard. Il y a pas mal d'années par exemple, j'ai failli acheter un petit appart, pour lequel je me serais endetté pour des dizaines d'années et aurait été incapable de lâcher mon boulot d'ingénieur (sauf pour un autre, si possible avec le moins de vacances entre-deux). Puis je me suis ravisé et ai décidé que je préférais vivre bien. Par la suite, j'ai même démissionné (sans autre boulot en perspective), j'ai vagabondé, ai vécu dans plusieurs pays (en travaillant là-bas parfois, parfois non). Puis de nos jours, je fais du Logiciel Libre (pendant des années entièrement bénévolement) et je développe GIMP avec des salaires qui feraient rigoler (jaune) n'importe quel ingénieur (soyons clair, on parle même pas de salaire en sortie d'école, et de loin; mais vous êtes tous bienvenus pour aider à notre financement collaboratif si vous aimez GIMP ;p).
Mais globalement je suis heureux de ma vie, j'aime ce que je fais et mon but ultime n'est pas de rouler sur l'or (même si j'aimerais bien être bien payé, soyons clair; mais "vivre bien" passe en priorité).
Alors forcer les gens à prendre un prêt dès leurs premiers pas en tant qu'adulte signifie ne plus leur donner de choix sur ce qu'ils feront de leur vie. Ils doivent au plus vite marcher au pas. Ensuite certains, c'est exactement ce qu'ils veulent et ils sont très heureux avec cette vie. Mais pas tous.
Et la réponse éventuelle "ces personnes ne sont pas obligés d'aller en école d'ingénieur" n'est pas acceptable. Pourquoi serait-il interdit d'avoir de bonnes études d'ingénieur sans vouloir rentrer dans les cases professionnellement ni s'endetter? Tout ce que j'ai dit précédemment peut aussi s'appliquer à un ingénieur (comme à n'importe quel métier, donc n'importe quelles études).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Oui : contactez-moi d'abord
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Forker ou ne pas forker ?. Évalué à 10.
Je vais donner un autre point de vue, qui est complètement le cul entre 2 chaises. Mais c'est vraiment comme cela que je vois la contribution au logiciel libre.
Alors d'un côté, tu as totalement raison. Si quelqu'un te file un méga-patch de centaines/milliers de lignes pour une grosse fonctionnalité dont tu ne veux pas, c'est dur de le rejeter (pour plein de raisons). Mais pour garder une cohérence au projet, ben des fois, faut bien.
Ceci dit, de l'autre côté, la personne essaie parfois de contacter, et se retrouve sans réponse pendant des jours, voire des semaines. Le truc, c'est que c'est totalement normal. On est des êtres humains, on fait des choses parfois en dehors du code. Et même si on devait coder quotidiennement à temps plein, ça ne signifie pas pour autant qu'on est obligé de répondre à toute question à la minute. On a une vie quoi.
Cependant la personne qui demande a aussi une vie. Attendre des jours, des heures même souvent, c'est dur quand on a une idée qu'on veut développer! On se met à le faire dans sa tête, on y passe des heures à y penser (qu'on a l'impression de perdre et on se dit qu'on aurait déjà bien avancé si on s'était mis directement à coder). Bien sûr, on pourrait/devrait juste poser la question et passer à autre chose en attendant la réponse (si même elle arrive). Mais l'humain est pas si rationnel et quand on a une idée en tête, c'est souvent pas si simple de "passer à autre chose".
En outre, du côté des mainteneurs, on entend très souvent la fameuse "Je suis développeur, je peux aider, vous m'expliquez ce que je dois faire?". Le truc, c'est que c'est pas si simple. D'ailleurs c'est peut-être même symptomatique d'un développeur à l'expérience limité de demander cela, comme s'il s'attendait à ce qu'on puisse lui décrire un logiciel énorme de tête en quelques minutes dans le détail. Car c'est le détail qui importe (bon bien sûr, on peut en faire dire de tête le nom de pas mal de fichiers ou fonctions et où plus ou moins précisément doit se passer tel ou tel changement, mais y a des limites quand même); oui je peux décrire la structure globale de GIMP en quelques minutes, mais une description si globale en général est inutile pour un développeur qui veut implémenter un truc précis. Il espère donc que tu lui dises où et quoi changer. Mais si on vérifie cela, on a déjà fait la moitié du boulot nous-même et on y a passé pas mal de temps.
Donc quand on donne juste une description simple, soit le contributeur potentiel comprend et il fait, soit (et c'est 90% des cas), il abandonne au bout d'un moment (et peut-être se dit que les dévs sont pas cool, ils aident pas les nouveaux, alors forcément…).
Là où je veux en venir, c'est qu'une demande qui vient avec un patch vaut 1000 propositions d'aide. C'est concret, c'est là, on sait tout de suite à quoi s'attendre (au niveau qualité du code notamment et on a une idée de ce qu'on pourra demander ou non à cette personne), etc. La proposition d'aide, notre réponse est invariablement "c'est cool, on attend le patch!" sans pour autant y mettre un espoir fou. On sait que dans beaucoup de cas, ça ne viendra pas. Je me rappelle même une fois une personne nous avoir dit avoir reçu un financement pour une fonctionnalité (j'ai retrouvé le ticket). Ce fut la première et dernière fois qu'on a entendu parler de lui.
Et en ce sens d'ailleurs, l'auteur du journal a très bien fait. Proposer un patch fonctionnel est la meilleure chose à faire quand on veut vraiment une fonctionnalité. C'est ce que j'ai appris au fil des ans, et désormais quand je veux vraiment quelque chose, je ne me pose pas la question: je la code moi-même. Attendre les autres mène rarement à l'obtention de la fonctionnalité (et ce, même si les développeurs du logiciels sont d'accord sur la fonctionnalité sur le principe; ça ne leur crée pas du temps magiquement ni ne la met en haut de leurs priorités: s'ils n'en estimaient pas eux-même le besoin au préalable, accepter qu'un autre puisse en avoir le besoin — et ce faisant accepter que cette fonctionnalité vaut le coup — ne change pas leur propre besoin).
Donc mon conseil aux contributeurs, c'est: oui bien sûr, discuter, c'est toujours bien! Mais ça ne veut pas dire que vous ne devez pas prendre un peu les devants. Les bons mainteneurs apprécient si vous avez un peu d'indépendance et que vous fassiez une implémentation dès le début. C'est la meilleure intro en tant que contributeur.
Par contre, oui, il faut être conscient que ça ne veut pas dire pour autant que votre patch sera accepté. Peut-être qu'il nécessitera juste des corrections. Peut-être que le mainteneur ne sera pas d'accord avec certains choix et qu'il faudra faire des compromis. Peut-être même (le pire des cas) que votre patch sera au final rejeté après avoir passé plein de temps pour coder et pour ensuite discuter et défendre la fonctionnalité. Ça arrive. Ça m'est aussi arrivé, et pas qu'une fois (même si globalement cela reste rare! Si vous êtes un bon développeur avec de bonnes idées, peu de mainteneurs refuseront tous vos patchs sans y penser à 2 fois, en tous cas pas les bons mainteneurs).
Mais vous savez quoi? C'est la vie! C'est pas une spécificité du développement logiciel. Dans plein de trucs dans la vie, il m'est arrivé de gâcher mon temps, en faisant ceci ou cela qui s'est avéré inutile ou refusé, ou autre. C'est chiant, mais bon. C'est pas la mort! On passe à autre chose.
En gros, la conclusion, c'est: que vous soyez mainteneur ou contributeur, soyez conscients que vous parlez avec des êtres humains:
On a un développeur qui a fait quelques patchs (de très mauvaise qualité technique d'ailleurs, donc énormément de temps de revue) pour GIMP et qui plusieurs fois nous dit des trucs genre "ce que je déteste le plus, c'est de perdre mon temps" dès qu'on se met à discuter ses patchs (pas pour les rejeter, mais réellement pour les discuter afin d'arriver au meilleur choix, qu'on ne sait pas forcément). Non seulement c'est très passif-agressif, met directement la discussion sur une mauvaise ambiance, mais en plus c'est oublier que nous aussi on existe. Nous non plus n'aimons pas perdre notre temps. Qui aime cela?
Mais on fait ce qu'on fait pour aboutir au meilleur logiciel ensemble, pas pour "perdre du temps". Si quelqu'un ne comprend pas ça, autant ne pas faire de logiciel libre.
Alors je le disais, il faut savoir refuser certaines contributions inadéquates. Ensuite sans plus de détails, je ne peux pas dire si c'est le cas des contribs que t'as reçue. Ceci dit, il faut aussi savoir demander à un contributeur à corriger son code pour le voir intégrer (cas de 2 des 3 contributions: demande au premier de compléter son patch, et au second de le refaire proprement).
Souvent aussi il faut savoir prendre de son temps pour faire faire fleurir les contributions. Je l'ai déjà dit, je fais beaucoup de revue de code dans GIMP. Mais soyons clair, la majorité de ce que je relis et corrige ne m'intéresse pas personnellement (ni pour notre projet ZeMarmot). Mais j'en vois l'intérêt pour d'autres et pour l'amélioration de GIMP en général. Si on devait refuser tous les patchs dès que le contributeur n'est pas capable de mieux, alors GIMP aurait genre moitié moins de fonctionnalités. La plupart du temps, on repasse derrière les patchs pour les peaufiner (et ce, même si la fonctionnalité ne nous intéresse pas personnellement!). Et d'autres repassent aussi derrière moi. Et ainsi de suite.
C'est aussi ça qui fait la qualité d'un logiciel libre: on n'est pas tout seul avec notre code et nos propres limitations.
Perso je n'aime pas tous les choix faits dans GIMP et j'en ai discuté plus d'un. Mais si je contribue, c'est parce que ce qu'on fait tous ensemble, j'aurais été incapable de le faire seul (de même pour les autres contributeurs). Et ça j'en suis très conscient. On a un logiciel extrêmement cool et puissant parce qu'on a travaillé ensemble, on a tous compromis ensemble.
Donc j'espère que tu ne refuses pas des fonctionnalités juste parce qu'elles ne t'intéressent pas. Ce serait tout de même un peu triste.
Bien sûr si la fonctionnalité a pour effet de rendre d'autres fonctionnalités moins bonnes, c'est une autre histoire. Mais ce n'est pas le cas de la plupart des fonctionnalités.
Perso notre build de GIMP local utilisé pour ZeMarmot a quelques petites différences, mais très mineures. Ce sont quelques détails qui ont été refusés dans GIMP (pour de bonnes raisons, même si je suis pas d'accord). J'en ai pas fait une maladie et je vais sûrement par forker GIMP (de manière publique j'entends) pour cette raison. Mais on garde ces différences au strict minimum.
Notre but n'est pas d'avoir notre propre GIMP mais d'améliorer le GIMP de base. Ne serait-ce que pour la qualité. C'est bien simple: presque tout ce que j'ai codé est d'autant mieux car d'autres gens sont passés derrière et ont aussi amélioré.
D'ailleurs l'un de mes buts dans GIMP est d'améliorer considérablement l'API et ses possibilités justement pour ne plus avoir de GIMP patché en local du tout. Je veux pouvoir transformer nos quelques différences de code en dur en plug-ins à la place.
Le truc, c'est aussi que maintenir un fork, c'est aussi un travail de dingue. Il faut le faire si vraiment tu n'as aucun choix (ou que tes différences sont vraiment minimes). Alors c'est vrai que c'est bien que ce soit possible, mais ce n'est absolument pas le plus intéressant dans les licences libres, selon moi. La possibilité d'un fork personnel est seulement une manière de rendre le pire cas "moins pire" (toujours d'après moi). :-)
Bon y a aussi les forks après abandon d'un projet par exemple, ou d'autres types de fork qui sont totalement différents. Je parle du cas du fork sans raison profonde, genre juste "comme ça je fais ce que je veux".
C'est effectivement une réalité, et la majorité des cas. Ensuite, je le rappelle (cf. plus haut): les contributeurs aussi ont une vie et des priorités. On peut leur demander d'aider mais on peut pas leur en vouloir s'ils refusent. J'ai personnellement contribué à des dizaines de projets (voir OpenHub et c'est loin d'être exhaustif!) et GIMP est le premier (hormis ceux que je maintiens ou ai créés) sur lequel je suis resté. Je ne pourrais pas humainement participer activement à tous les projets auxquels j'ai envoyé un patch.
Ça ne m'empêche pas de vouloir une fonctionnalité ailleurs et de la coder de temps en temps, mais oui le mainteneur doit être conscient que ça ne veut pas dire que je signe un contrat avec mon sang pour rester à ses côtés jusqu'à ma mort.
En tant que mainteneur de projet libre, c'est quelque chose à accepter. Ensuite bien sûr tu peux vouloir un projet petit et simple à maîtriser et qui prenne peu de temps en refusant de le rendre communautaire. C'est un choix et chacun est libre de le faire. Ensuite faudra pas espérer que son projet s'envole vers des sommets. On peut pas tout avoir. Bien sûr, pour beaucoup de gens, ce n'est pas ce qu'ils veulent. S'ils font le choix en plein conscience, c'est bien.
Personnellement je pense que ce n'est pas mauvais d'accepter de lâcher un peu prise parfois. D'ailleurs si les gens ne restent pas, c'est parfois aussi car certains mainteneurs peuvent garder trop de mainmise sur leur projet.
Au contraire, les plus gros projets ont des co-mainteneurs (voire ont changé de mainteneur à plusieurs reprises), et même quand parfois le créateur est resté depuis le début, cela ne l'a pas empêché de prendre des sous-mainteneurs (comme le noyau Linux) à tel point que dernièrement on a eu plusieurs exemples de tels mainteneurs qui essaient de rendre le projet encore plus indépendant d'eux (je pense bien sûr à Linus Torvalds et Guido Van Rossum).
La chose qui m'a fait rester sur GIMP? Très rapidement le mainteneur m'a attribué sa confiance. Au bout d'un mois ou 2, après plusieurs patchs, Mitch me dit en gros "tu fais chier avec tous tes patchs, ils sont tous bien, tiens prends toi un accès en écriture à git comme ça je gagne du temps". Franchement ça m'a impressionné. Je me suis dit "Waw juste comme ça, je peux pousser mes commits dans GIMP?". Il m'a donné sa confiance et j'ai d'autant plus fait gaffe à ce que je poussais et pendant longtemps je continuais à demander des revues de code avant de pousser dès que ce n'était pas totalement trivial. Au final je suis le plus gros développeur de GIMP sur la dernière année. Ce fut une très bonne leçon et j'essaie de l'appliquer aussi maintenant: dès que quelqu'un fait du code de qualité évidente et qu'il reste un peu, c'est le moment où faut "l'accrocher" avant qu'il aille voir ailleurs. Je lui propose donc d'avoir son accès en écriture. :-)
Alors soyons clair, ça marche pas tout le temps. Même ainsi, beaucoup de contributeurs disparaissent au bout d'un moment. Mais ça vaut le coup d'essayer.
Dans tous les cas, je ne suis pas seul à maintenir le code. On n'est pas beaucoup, mais je suis pas seul. Et c'est passé par le fait que le mainteneur (et tous les sous-mainteneurs) a su donner sa confiance aux gens et surtout a lâché un peu du lest. Il accepte qu'il ne sait pas tout, que certains sont de très bons développeurs (voire meilleurs que lui), qu'ils ont aussi de bonnes idées, que le logiciel peut servir à plus que ce dont lui se sert, etc.
En fait, le logiciel libre et/ou communautaire, quand c'est bien fait, je pense que ça peut faire de nous des bons philosophes. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Conclusion étrange
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Directive sur le droit d’auteur adoptée. Évalué à 10.
Oui. Cet article essaie de se la jouer neutre officiellement, mais sa tournure montre clairement que le journaliste est carrêment pour cette loi, genre "on reprend le contrôle du web". C'est marrant car ils ont vraiment joué sur cet aspect "David contre Goliath" dans le marketing pour cette loi, genre d'un côté les méchantes "tech sociétés" et de l'autre les "pauvres petits artistes". Alors qu'en vrai, y avait effectivement notamment ces grosses sociétés du web, mais de l'autre côté, c'était surtout les grosses sociétés d'ayant-droits.
En fait avec cette loi, ce qui pourrait se passer:
Les grosses sociétés du web? Ben soit éventuellement elles retirent leurs agrégateurs (par ex. Google News) de l'Europe. Ça avait déjà été fait par exemple en Belgique, qui était même allé plus loin, et finalement les journaux se sont rendus compte que ne pas être présent sur Google News, c'est pas terrible pour le business. Soit les grosses sociétés du web se plie aux règles et paient les droits (ce fut la fin de l'affaire belge quand tout le monde a compris que Google News, c'est pas si mal finalement). Pour Google (et autres grosses boîtes du genre), ces droits sont rien du tout au final.
Quant aux filtres d'upload, Google et consort mettront en place les dits filtres (ça prendra juste quelques jours, après tout, c'est pas comme s'ils avaient pas des milliers de développeurs et admins faits pour, hein!).
Pour les très gros médias et grosses sociétés de droits d'auteur spécialisés dans la recherche de droits (avec des équipes spécialisés dont c'est le boulot à temps plein), c'est une aubaine et ils vont se faire des pépettes en or (qu'ils pourront sainement redistribuer aux salariés qui en ont le plus besoin, et puis si on se plaint que c'est pas si juste, on peut toujours virer la personne en lui versant d'autant plus; c'est logique, on vire quelqu'un pour avoir profité du système, autant partir en profitant encore plus, comme ça au moins la critique est doublement méritée!).
Les "artistes" et autres créateurs de leur côté, ben ils touchaient des cacahouètes avant, et ils continueront à… toucher des cacahouètes. On notera les superbes communiqués de presse que nous envoient d'ailleurs les sociétés de droits d'auteur précédemment citées, par exemple ici l'ADAMI (cliquez pour voir en plus gros):
On nous rassure donc avec des "Ce vote est une première étape capitale vers une rémunération juste et proportionnelle à l’exploitation de votre travail sur Internet", bien sûr! On y croit tous!
Par contre, même si on touchera toujours autant de rien, on aura de plus en plus de mal à faire diffuser nos œuvres. Non parce que tu comprends, si tu joues Jean-Sébastien Bach et le met sur un site, on pourra venir t'expliquer que ça appartient à Sony Music Global et donc ton partage se verra interdit (je le disais plus haut: les grosses plateformes n'auront aucun mal à implémenter les filtres… d'ailleurs ce cas de Bach est un cas déjà réel qui s'est produit sur Facebook). Et va y pour te plaindre et essayer de débloquer ton œuvre et ton compte (ah oui parce que les filtres, ben c'est pas des humains!).
Pire! Si jamais tu arrives au final à faire entendre raison à un humain du support de la plateforme et à faire diffuser ton œuvre, après un parcours du combattant, et qu'elle se retrouve même partagée! Youhou! Tu te dis que toi aussi, tu vas pouvoir commencer à te faire des pépettes en droits d'auteur! Que nenni! Tu n'as pas les équipes de SACEM ou Adami, tu auras bien du mal à savoir qui diffuse ton œuvre, et à part si tu fais que ça de ta journée (plutôt que jouer au piano!), ben tu pourras demander aucun sous. Et par défaut, les équipes d'ayant-droit vont toutes attribuer les droits à Sony Music de toutes façons (car ils utiliseront les mêmes logiciels pour détecter les ayant-droits que les filtres anti-upload, bien sûr!).
Tu l'auras compris: dans un cas comme dans l'autre (que tu sois affilié ou non), biiiip, tu perds!
Alors résumons: les gros médias et sociétés de droits? Ils vont se faire plein de brouzoufs! Les grosses boîtes du web? Bah, une petite épine dans le pied, on a perdu une bataille, passons et réfléchissons simplement au prochain moyen de se faire du blé avec vos données perso. Les créateurs? Vous touchez déjà 50€ par an, maintenant ce sera 51€, youhou! Vous êtes riches! Par contre faut pas vous imaginer pouvoir créer en dehors du système en uploadant vous-mêmes, passez par les gros médias SVP (faites nous confiance…)! Les petites plateformes? Bandes de pirates (avec des crochets et des bandeaux sur les yeux), crevez! Laissez les vrais boîtes gérer toutes les œuvres publiées!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Soutenir Gimp
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.6 : rien ne nous arrête !. Évalué à 10. Dernière modification le 05 septembre 2018 à 17:42.
Ça dépend.
L'argent de GIMP est utilisé uniquement pour les frais communautaires. Par exemple, cela permet aux contributeurs de se rencontrer une fois par an (frais de transports et d'hébergement) à Libre Graphics Meeting, voire à Wilber Week (si on en réorganise) pour une semaine de hacking.
Il est aussi déjà arrivé régulièrement que GIMP aide financièrement d'autres projets libres ou des évènements (en particulier Libre Graphics Meeting qui a parfois eu du mal à joindre les deux bouts si GIMP n'avait pas été là pour sauver les meubles).
Cela peut aussi être utilisé si on a besoin de faire des autocollants ou un kakémono (l'an dernier, un contributeur a participé à une conf aux US et a fait faire un kakemono GIMP ainsi), ou autre chose du genre.
Enfin cela peut être utilisé pour du matos.
Par contre, cela n'est pas utilisé pour des salaires (ce qui est le plus coûteux et au final le plus nécessaire). GIMP n'a pas de structure pour embaucher. Ceci dit, le projet pourrait sûrement donner à LILA, ce qui servirait à payer des salaires dans une structure. Mais certains contributeurs trouvent que donner cet argent de cette façon ne serait pas juste pour certains contributeurs bénévoles qui font aussi beaucoup, etc.
Personnellement je trouve cette logique peu constructive et serait (bien évidemment) heureux si cet argent pouvait nous servir pour rendre viable les tentatives de professionnaliser nos contributions à GIMP. Mais bon, je suis clairement parti pris et je ne veux pas créer une mauvaise ambiance autour de questions financière.
À la place, je dis clairement aux gens: si vous voulez financer du développement dans GIMP, vous pouvez donner à LILA; si vous voulez financer la partie communautaire, nos réunions bénévoles, etc. alors donnez à GIMP.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Transformations dans l'outil de mesure
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.6 : rien ne nous arrête !. Évalué à 7.
Ça s'appelle un manuel. ;-)
D'ailleurs si des gens veulent aider, aux dernières nouvelles, il est pas à jour.
Pour contribuer, ça se passe là: https://gitlab.gnome.org/GNOME/gimp-help
Les captures d'écran montrent de vieilles interfaces, les photos du hardware antédiluvien, le texte est vieux et mériterait une revue, plein de fonctionnalités sont absentes. Etc. etc.
On accepte aussi des tutos (sous licence libre seulement, comme le manuel) récent et de qualité: https://www.gimp.org/tutorials/
Pour contribuer (tutos ou site en général), c'est là: https://gitlab.gnome.org/Infrastructure/gimp-web
Y a plein de manières de contribuer, pas que du code. :-)
De notre côté, oui on voudrait faire plus de posts aussi, mais bon on arrive pas à faire le temps pour ça, alors…
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Plug-ins et Windows
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.6 : rien ne nous arrête !. Évalué à 3.
Je suis pas sûr de comprendre. GIMP a déjà un concept de répertoire utilisateur vs. répertoire système pour les plug-ins, et ce depuis très longtemps.
Ensuite sous Windows, je pense que le répertoire système serait
$PREFIX/lib/gimp/2.0/plug-ins/($PREFIXétant là où GIMP est installé).Mais non ce n'est absolument pas nouveau et ce n'est pas de cela dont je parle ici. Je parle juste d'une nouvelle organisation des plug-ins, où on demande de mettre chacun dans son propre répertoire afin d'éviter la pollution de DLLs apportés par un plug-in tiers.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Soutenir l'un des logiciels les plus important du projet GNU !
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.6 : rien ne nous arrête !. Évalué à 7.
On avait déjà publié nos rapports, mais c'est vrai qu'on l'a pas fait dernièrement. LILA est une micro asso et c'est vraiment dur de tenir tout à jour dans les temps. Mais c'est noté. On va essayer de faire les choses au plus carré (en fait, ça a toujours été notre but de faire le plus carré et transparent; j'ai un peu honte qu'on y arrive même pas!). Tu as entièrement raison de dire que ce type de transparence est important.
Quoiqu'il en soit, les donations vont à ce jour principalement dans la production de ZeMarmot. C'est notre seul gros projet à ce jour (notez qu'on ne serait pas contre d'autres projets en parallèle si des gens cherchent une structure dans l'Art Libre pour développer leur projet; mais à ce jour, y a pas vraiment, même si y a eu un peu). LILA fait des salaires intermittents en bonne et due forme.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Transformations dans l'outil de mesure
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.6 : rien ne nous arrête !. Évalué à 6.
C'est quand même très récent. Le redressement d'image est sorti dans la 2.10.4, soit début juillet. En 2 mois, je pense qu'il est impossible de connaître tout GIMP.
Je travaille sur le code de GIMP depuis 6 ans, et je découvre sans arrêt des trucs. Aryeom travaille quotidiennement dans GIMP, toute la journée (du matin au soir, en continu… enfin hors pause et éditions vidéos, etc. ;p), et c'est pareil. Toutes les 2 semaines, y a un "quoi on peut faire ça? C'est cool!".
Alors que tu n'aies pas trouvé une fonction par hasard en 2 mois, ça me semble absolument pas étonnant. Et franchement je doute qu'on puisse attribuer ça (ou en déduire) un problème ergonomique quelconque sur l'emplacement de la fonctionnalité. :P
GIMP fait partie de ces outils pour professionnels, vraiment très complets et avec des fonctionnalités tellement nombreuses qu'il faudrait des jours à ne faire que ça pour toutes les essayer et comprendre leur utilisation (et encore même là, ça veut pas dire qu'on verrait immédiatement un usage concret immédiat). Ce n'est pas forcément un mal. On me demande pas de connaître le moindre rouage de mon hardware et tout le code source de mon système d'exploitation pour l'utiliser (cela ne m'empêche pas d'être un développeur décent, je pense). Pourtant je suis sûr que je ferais des choses extraordinaires si je connaissais tout sur tout. ;-)
Quant au fait que l'outil de mesure s'appelle ainsi, perso je le vois un peu comme une sorte de règle, et même si la fonction première est en effet de mesurer, l'utiliser pour remettre droit me paraît au contraire une évolution des plus naturelles (cf. les règles niveau à bulle).
Quant aux repères, comme quelqu'un le note, on peut afficher des grilles, on peut aussi utiliser des guides de canevas, et enfin l'outil de rotation lui-même a une fonctionnalité de guides qui peuvent avoir divers formats (règle de 3, de 5, diagonales, etc.). Voir les options de l'outil de rotation.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Mes nyeux!
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.6 : rien ne nous arrête !. Évalué à 6.
C'était pas Tokyo mais Paris (et j'ai fait exprès de le laisser en alphabet plutôt que katakana, histoire de montrer l'orientation mixte).
Quoiqu'il en soit, en cherchant sur le web, il semblerait en effet que 'で' est moins utilisé/utilisable, car ce n'est pas une action. Quoique apparemment certains japonais disent (sur des forums) utiliser habituellement 'で' dans une telle phrase, mais il apparaît tout de même que ce n'est en effet pas du japonais littéraire.
Perso la phrase me paraissait grammaticalement correcte, mais bon… c'est pas comme si je parlais bien japonais! :P
Je note tout de même que tu me demandes carrêment de corriger la capture d'écran. Ahahah! Désolé, je vais pas perdre une seconde là-dessus (le but, c'était de montre l'orientation mixte; objectif atteint!). :P
Tu es d'ailleurs la première personne à me faire la moindre remarque sur cette erreur.
Ce n'est peut-être pas le bon terme. Comme souvent, quand je traduis mes dépêches GIMP de l'anglais vers le français, je vérifie s'il y a déjà une traduction (en gros, je regarde le fichier
fr.podes traductions de l'interface en français). Il n'y en avait pas pour "straighten" (et toujours pas d'ailleurs, je viens de regarder). Alors j'ai traduit comme je pouvais. Même maintenant je continue à pas trouver ça si mal d'ailleurs, faute de mieux.Mais je suis ouvert à des propositions (pas que ça serve à grand chose; je suis pas dans l'équipe des traducteurs et n'ai donc pas mon mot à dire de toutes façons).
Comme quoi, il semblerait que je parle mal le français ET le japonais! C'est la fin! ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: dll hell
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.6 : rien ne nous arrête !. Évalué à 10.
Déjà un peu d'explication du problème pour bien comprendre. Windows cherche les DLLs dans cet ordre:
Pour le binaire principal
gimp-2-10, c'est facile car il suffit de mettre toutes nos DLLs dans le même répertoire$PREFIX/bin/. Elles seront toujours trouvées en premier.Le problème est pour les plug-ins qui sont dans
$PREFIX/lib/gimp/2.0/plug-ins/et lorsque ces plug-ins souhaitent utiliser certaines des bibliothèques livrées avec GIMP (qui sont donc dans$PREFIX/bin/).On pourrait simplement mettre les librairies à côté de chaque plug-in, mais cela signifierait dupliquer les bibliothèques un certain nombre de fois. Et en plus ça ne permettrait plus aux plug-ins tiers de profiter des biblios livrées. Donc ce n'est pas acceptable.
À la base, on rajoutait donc
$PREFIX/binau début duPATH(qui est spécifié dans un script de lancement). Mais si jamais une application installe une DLL (que nous utilisons, mais dans une version incompatible) dans un répertoire système, alors cette DLL est trouvée avant et les ennuis commencent.Une autre solution à laquelle je pensais est de jouer avec le répertoire courant (le faire pointer sur
$PREFIX/bin) mais il se trouve que siSafeDllSearchModeest activé (apparemment une valeur de la base de registre), le répertoire courant est soudainement cherché après les répertoires système aussi! Donc ça marcherait plus (enfin surtout ça dépendrait de la configuration de l'OS).La solution est donc d'utiliser
SetDllDirectoryW()pour donner la priorité à$PREFIX/bin, et pour être précis le mettre entre le répertoire du binaire (permettant aux plug-ins de bypasser nos biblios au besoin) et les répertoires système. C'est donc une solution au niveau du code.Un cas supplémentaire que nous avons corrigé dans 2.10.6 fut les plug-ins 32-bit lancé dans un environnement 64-bit. Dans ce cas, on doit leur donner un répertoire différent avec des versions 32-bit de nos bibliothèques (on le met dans
$PREFIX/32/binpar défaut, mais j'ai mis un flag pour changer ce répertoire à la compilation). Je détecte donc le bitness d'un plug-in avant de le lancer et lui assigne le bon répertoire de bibliothèques avecSetDllDirectoryW().Un nouveau cas dont j'ai récemment pris connaissance (et pas encore corrigé) est les plug-ins scripts lancés par un interpréteur 32-bit sur environnement 64-bit (si le script utilise des bibliothèques compilées). Dans ce cas, on devra détecter le bitness de l'interpréteur.
Par exemple notre installeur embarque seulement Python en 32-bit (je ne suis pas sûr pourquoi). Donc des scripts python un peu complexe qui utilise des biblios C risquent de ne pas fonctionner.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Soutenir Gimp
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.6 : rien ne nous arrête !. Évalué à 10. Dernière modification le 30 août 2018 à 12:44.
Ce projet tiers est ce qui permet de contribuer à GIMP et a fait de moi l'un des plus gros développeurs de GIMP ces dernières années (même le plus gros selon le décompte).
C'est simple, sans ZeMarmot, pas de GIMP. Je contribuerai alors sûrement à d'autres logiciels libres, selon mes autres besoins, mais je n'ai pas besoin de GIMP personnellement plus que ça (enfin régulièrement, je découpe, redresse, rend plus net, etc. des photos; mais pour cette utilisation basique, GIMP est déjà largement au niveau). Là on en a vraiment besoin, dans un projet professionnel, au quotidien 8h par jour.
(0) On a besoin qu'il soit stable. Quand on faisait les premiers tests avec Aryeom Han, GIMP crashait pour un rien (c'était vers 2012). Ça foutait la honte. Mes premières années de contribution, j'ai corrigé beaucoup de crashs (de mémoire, y en avait en utilisant une tablette graphique; y en avait aussi des supers mauvais lorsqu'on utilisait un IME, en particulier avec le coréen, dans l'outil texte, et plein d'autres dont je me souviens même plus) et autres problèmes de stabilité. Bon j'en corrige encore régulièrement, mais GIMP est devenu beaucoup plus stable.
(1) Toujours dans la recherche de stabilité, on a besoin de pouvoir aisément débugger et parer aux problèmes (qui arrivent sur tous logiciels même les plus stables). Donc j'ai implémenté une sauvegarde des images au moment du crash (pour ces bugs survivants qu'on n'a pas encore corrigés!), et GIMP propose maintenant au lancement suivant de tenter une récupération des images qui étaient en cours d'édition, ainsi qu'un système de débug qui génère automatiquement des backtraces, non seulement pour les crashs, mais aussi utilisables lors de WARNING et CRITICAL en cours d'utilisation (permet d'améliorer le logiciel en découvrant des bugs plus subtils). C'est l'une de mes fonctionnalités fétiches. Le nombre de bug qu'on a pu corriger depuis que j'ai implémenté cette fonctionnalité est impressionnant. Corriger des bugs est devenu simple, et les gens nous envoient désormais des rapports de bugs utiles, même lorsqu'ils ont aucune idée de ce qu'il s'est passé, qu'ils savent pas du tout parler anglais ni écrire des rapports de bug bien formés.
(2) On rajoute des fonctionnalités. Dernièrement je travaille beaucoup sur tous les détails pour les écrans haute densité de pixel (l'écran principal de travail d'Aryeom ne l'est pas pourtant, mais je sais qu'on y viendra; autant préparer GIMP en amont). Le système d'extension indiqué plus haut bien sûr me semble important. Nous aussi on utilise quelques plug-ins, mais très peu. Franchement c'est impossible de savoir ce qui existe et ce en quoi on peut faire confiance. Et surtout chercher, installer et faire marcher des vieux plug-ins peut être une vraie galère (et pourtant je suis développeur, c'est dire!).
Dans les quelques années passées, j'ai été responsable de plusieurs autres fonctionnalités, et je travaille à d'autres fonctionnalités encore (comme l'animation, comme on sait ici).
(3) On fait de la revue de code. Ça paraît bien moins sexy, mais c'est primordial. L'histoire de GIMP est parsemée de fonctionnalités sympas qui ont été perdues car personne n'a eu le temps de les vérifier. Je ne jette la pierre à personne: ça prend un temps fou. Dans cette sortie par exemple, l'écriture verticale n'aurait probablement jamais été intégré sans moi (je suis allé chercher le contributeur, j'ai fait la revue, les tests, les commentaires sur chacune de ses modifications; en tout j'y ai passé quelques heures).
Même le Marathi, j'ai vu un email perdu sur la liste de discussion des traducteurs auquel personne ne répondait; le problème est que cette langue n'avait plus de coordinateurs. J'ai donc essayé de relancer à la place des traducteurs (qui allait sûrement abandonner à un moment donné) et de leur donner espoir pour ne pas les décevoir (un espoir qui a abouti!).
Le redressement horizontal, j'ai retrouvé un vieux patch perdu dans le bugtracker et très basique. J'ai fait de la revue, retravaillé au dessus (car il n'était pas vraiment utilisable en l'état); Ell a fait de même ensuite. Et maintenant ça fait une super fonctionnalité.
Dans le passé, je me souviens bien de la recherche d'action (une de mes fonctionnalités préférées!). J'y ai passé un temps considérable. Le patch était cool, mais écrit par des étudiants. J'y ai passé de très nombreuses heures à corriger ce qui devait l'être, à rendre la fonctionnalité vraiment utilisable simplement, et à l'améliorer énormément. Maintenant je pourrais pas faire sans!
Pour info, dans GIMP, on a des règles stricts et du code de très bonne qualité globalement (bien sûr plus localement, on trouve beaucoup d'horreurs ici et là, comme dans tout gros code). Donc la revue est primordiale. On fait pas comme certains logiciels qui acceptent tout et n'importe quoi.
(4) On fait évoluer la politique interne. Je suis celui notamment qui a poussé depuis plusieurs années (tous les ans, à chaque fois qu'on se rencontrait au Libre Graphics Meeting) pour une nouvelle politique de sortie permettant de sortir des versions macros avec de nouvelles fonctionnalités (plutôt qu'attendre 6 ans encore pour une sortie majeure!). Et voilà, maintenant tous les mois, GIMP sort avec des fonctionnalités cool. Les gens se disent maintenant que GIMP est super actif, et on se met à avoir plus de contributions (j'ai l'impression; mais ça peut aussi être simplement car on a sorti 2.10, ou autres raisons).
(5) On a créé et on maintient le flatpak pour que les linuxiens aient GIMP facilement et rapidement à chaque sortie (GIMP est maintenant dispo sous Linux à chaque sortie avant toutes les autres plateformes!).
Et sûrement plein d'autres choses.
Ensuite soyons clair: je ne souhaite pas mettre tous les éclairages sur ZeMarmot uniquement. En particulier le mainteneur, Mitch, fait un travail de dingue, connaît le code de GIMP et ses rouages bien mieux que moi. Sans parler de Ell, un alien venu d'ailleurs, qui nous optimise GIMP aux petits oignons (avec du code d'excellente qualité) depuis qu'il est arrivé. Je ne suis pas seul (heureusement!), et on a tous les 3 une grosse part dans le succès de GIMP.
Mais clairement je ne pense pas que ce soit exagéré d'affirmer que le projet ZeMarmot a vraiment contribué largement à propulser GIMP dans une nouvelle ère. On travaille sur GIMP pour un vrai projet, au quotidien (oui je me répète) et ça vaut énormément de contributions aléatoires sans but. C'est un peu une symbiose de l'artiste et des outils. Chacun a besoin de l'autre.
Si avec cela, ce n'est pas suffisant, alors je ne sais pas ce qui l'est. Je rappelle qu'on est officiellement associé à GIMP d'ailleurs (bien sûr même! Je suis un dév majeur). Même le site web gimp.org suggère de donner directement à ZeMarmot sur la page donation, ainsi que dans ses news régulières (comme la dernière news dont cette dépêche sur Linuxfr est plus ou moins une traduction un peu retravaillée). J'aurais du mal à voir comment ça pourrait être plus limpide. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Soutenir Gimp
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.6 : rien ne nous arrête !. Évalué à 5.
On sait pas trop non plus. J'ai aussi vu passer des trucs vite fait, mais rien qui dit clairement "c'est bon, tout va bien". Ils font pas beaucoup de communications, c'est dommage.
J'aime beaucoup Liberapay, mais tant qu'on n'a pas de message clair comme quoi ils sont à nouveau dans la course, on peut pas vraiment donner le lien.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Génial, mais on peut pas télécharger !
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche G’MIC 2.3.4 : traiter ses images, en se disant « déjà 10 ans ! ». Évalué à 5. Dernière modification le 23 août 2018 à 18:39.
Tu parles du fait que c'est de la gestion d'extension dans GIMP? Si oui, bien sûr que là on parle de gestion (c'est même le titre), mais il s'agit du fait d'installer, désinstaller, mettre à jour et afficher des infos sur des extensions. C'est la partie côté cliente.
Ça veut pas dire qu'on gère l'extension au sens de vraiment s'en occuper. Si elle est bourrée de bugs, si elle marche pas même, c'est pas notre problème au delà de fournir des outils (pas immédiatement, mais probablement rapidement) pour que les gens puissent indiquer une extension qui fonctionne ou pas sur telle ou telle version de GIMP. Et si l'extension n'est pas maintenue, on ne s'en occupera pas plus.
Je dirais que c'est notre problème si on découvre des malware et là oui, on intervient et on vire l'extension. À ce moment, quand il y a intention malfaisante évidente (ou grosse faille de sécurité très dangereuse), il est évidemment de notre responsabilité de réagir. Mais ça s'arrête là. C'est en ce sens là qu'on ne gère pas les extensions (côté serveur) au delà de proposer aux gens de les héberger.
Les données inertes (brosses, images splash, thèmes, icônes, dégradés, etc.) ne subiront en effet pas de revue préalable, contrairement aux données exécutées (plug-ins) qui doivent être évidemment validées avant d'être diffusées.
Ensuite bien sûr que des vecteurs d'attaques peuvent exister avec des données inertes. Cela a toujours existé et existera toujours. On a tous entendu parler de failles permettant d'exécuter du code caché dans des images par exemple.
Néanmoins cela n'est pas un comportement normal, et ainsi dire "On peut voir le chargement d'un fichier comme une exécution d'un programme dans une sandbox" est faux, en tous cas pour le type de fichiers que tu cites (brosses) ou que je cite (images) [bien sûr, il existe des fichiers avec du code fait pour être exécutés, comme les fameuses macros de traitement de texte; de tels fichiers doivent donc être considérés comme du code]. Donc non, charger une bosse ou une image n'est pas la même chose qu'exécuter un programme. Ce sont des données inertes faites pour une utilisation donnée, pas pour exécuter du code tiers. Quand cela arrive, c'est un comportement anormal, autrement dit un bug (le plus souvent dans le logiciel, parfois dans le format lui-même) et qui doit alors être corrigé.
Aussi cela n'a rien à voir avec les extensions. Ce type de bug, quand il existe, existerait déjà dans GIMP et pourrait déjà se produire. Les extensions ne sont qu'un conteneur supplémentaire (ajoutant un peu de sémantique au contenu, indiquant de quoi il s'agit, un nom, une description, des liens annexes, une version, etc.).
Les haters ont toujours existé et existeront toujours. Je le sais bien, je parle moi-même régulièrement sur Linuxfr de cela. Soyons clair, ça me touche et c'est dur. Mais je ne vois pas en quoi faire ou non des extensions pourrait changer quoi que ce soit à cela.
En fait par rapport aux comportements inadéquats, ma politique perso est de rester neutre (si possible, parfois c'est dur de tenir) et d'expliquer aux gens justement ce que je disais: GIMP est un logiciel libre, le logiciel libre, ça ne marche pas comme ils semblent le penser. En plus on n'est pas une entreprise, et on développe de façon volontaire. Et non, on ne réagit pas bien aux menaces et insultes. Par contre on est heureux d'aider les gens agréables, et tout ce qu'on demande, c'est que ces gens comprennent aussi ce qu'il en est, et qu'on contribue principalement bénévolement, souvent sur du temps libre.
Eh ben, tu me croiras peut-être pas, mais être clair (et poli) désamorce pas mal de situations. Les gens se rendent compte qu'ils ont un peu été des malotrus, se calment, parfois même (ça arrive!) s'excusent.
Ensuite oui, ça n'est pas du 100%. Et certains sont juste là pour haïr, comme je disais. On ne peut rien pour cela. Mais encore une fois, je vois pas le rapport avec les extensions. Ces personnes trouveront de quoi redire pour chaque nouvelle fonctionnalité qu'on apportera. On va quand même pas s'arrêter d'améliorer nos logiciels pour ces gens là! En tous cas, perso, c'est pas pour eux que je développe. :-)
Je crois que tu cherches des problèmes là où y en a pas. :-)
Pourquoi qui que ce soit jetterait l'éponge pour quelques aigris? Si ça devait arriver, crois moi, ça serait arrivé y a trèèèès longtemps (comme tout gros logiciel connu, on collectionne quelques aigris).
Au pire du pire, si vraiment ça se passait super mal, on pourra toujours arrêter notre système d'extensions tiers (et n'héberger que nos propres extensions, voire un choix très restreint d'extensions sélectionnées au cas par cas, comme quelqu'un le propose plus haut). Perso je trouverais cela un peu dommage, mais si on devait en arriver là, c'est pas la mort.
Soyons clair, je ne pense pas qu'on en arrivera là. Je vois aucune raison à cela.
Ah oui, et:
Encore une fois, du vocabulaire de startup hipster. On s'en fout du "bad buzz". Je dirais même qu'on vit dans un monde où cela n'existe pas. Il y a des gens sympas, des gens moins sympas, ça s'arrête là. Si ce prétendu grand méchant bad buzz devait avoir eu raison de nous, ça serait arrivé y a très longtemps.
Merci beaucoup de t'inquiéter pour nous.
Je pense perso que tu te fais du mouron pour rien. :P
Si le type de problème dont tu parles devait arriver, je pense pas que ce soit parce qu'on ait ajouté un système de gestion d'extension dans GIMP. Ahahahah!
Sur ce, j'arrête de répondre sur cette news. J'ai un peu l'impression de trop l'accaparer en hors-sujet là, alors que c'est censé parler de ce super logiciel qu'est G'Mic. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Génial, mais on peut pas télécharger !
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche G’MIC 2.3.4 : traiter ses images, en se disant « déjà 10 ans ! ». Évalué à 10.
Salut,
Nos installeurs contiennent la version 32 et 64-bit et installent la version appropriée. C'est écrit juste sous le bouton de téléchargement. Donc prends simplement l'installeur unique et ça te mettra la bonne version.
Ça oui par contre. C'est pas qu'on veut pas prendre en charge de plus vieux Windows, mais on n'a quasi aucun dév Windows (approximativement 0) alors on fait ce qu'on peut. Prendre en charge de vieilles versions veut dire plus de boulot car on doit contourner des problèmes de manières plus compliquées (même si des versions récentes ont peut-être amené des solutions simples).
Notre ligne directrice pour savoir si on prend en charge un OS (Windows ou macOS), c'est que cette version de l'OS doit au moins être encore pris en charge par son éditeur. Windows XP, y a plus de support depuis avril 2014 (d'après Wikipédia) et on parle quand même d'un système sorti en 2001, soit y a 17 ans!
Il est peut-être temps de mettre à jour. Et si le matériel est juste trop ancien, on peut mettre un Linux avec bureau léger. Ou si vraiment on est nostalgique des vieilles années et qu'on veut garder l'OS d'époque absolument (faire attention à l'accès internet, etc. dans ce cas), ben on prend sur soi et on garde aussi les vieux logiciels (y compris GIMP 2.8). :-)
Enfin bon, tout cela pour dire qu'il n'y a pas vraiment de solutions miracle, désolé. On peut pas prendre en charge indéfiniment un système, surtout si même son éditeur ne veut plus le prendre en charge. Ce serait vraiment se tirer une balle dans le pied.
Tout est possible. Ensuite je crois que la plupart des gens qui compilent GIMP pour Windows le font depuis un Linux (même notre build officiel est cross-compilé, il me semble). Donc ce sera clairement cela le plus simple.
Et je suis pas certain que ce build fonctionnera de toutes façons. Ne pas prendre en charge Windows XP, ça veut surtout dire qu'on a peut-être (probablement) utilisé des APIs Windows qui n'existaient pas encore dans XP. Donc tu te retrouveras à devoir patcher le code en fonction des parties qui poseront problème. Si tu le fais sans perte de fonctionnalité ni rendre le code surcompliqué (et avec un code propre), on veut bien le patch (on n'est pas absolument contre Windows XP, on ne le prend pas officiellement en charge, c'est tout).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Génial, mais on peut pas télécharger !
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche G’MIC 2.3.4 : traiter ses images, en se disant « déjà 10 ans ! ». Évalué à 6.
On ne les gèrera pas. On les hébergera. Mais oui tu as raison quand même qu'on aura notre part de responsabilité.
Même si GIMP lançait des sandbox, la revue et compilation doivent être faites de notre côté. Héberger aveuglément un binaire d'inconnus complets est une aberration.
C'est la raison pour laquelle les plug-ins compilés ne seront pas acceptés tant qu'on n'aura pas l'infra. Certains bénéficieront d'exception évidente comme G'Mic. C'est expliqué dans mon article.
Je ne prévois pas de gérer le site. Je suis développeur pas animateur de communautés. Nous avons une très grosse communauté avec des gens très actifs et même pas mal plutôt techniques. Des gens comme Pat David et Elle Stone seront parfaitement capables de gérer le quotidien (et de sélectionner les futur modérateurs si le contenu grossit vite).
Aussi on pourra y aller lentement. Si les gens sont pas contents du temps de revue, ce n'est pas notre problème. L'un des énormes avantages que l'on a est qu'on n'essaie pas de faire du business. Nos actions ne sont pas dirigées par des contraintes économiques. Ça rend GIMP très résistant aux problèmes car personne ne peut nous forcer à rien ni nous presser.
Bon j'arrête là. Cette dépêche est au sujet de G'Mic pas de GIMP! :P
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Génial, mais on peut pas télécharger !
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche G’MIC 2.3.4 : traiter ses images, en se disant « déjà 10 ans ! ». Évalué à 10.
Non ce n'est pas envisageable. De même que notre installeur Windows ne contient pas G'Mic (pas plus que tout autre plug-in tiers), ni notre DMG pour macOS.
Les builds officiels de GIMP ne contiennent (et ne contiendront toujours) que les plug-ins core de GIMP, c'est à dire ceux maintenus par les développeurs de GIMP. On a déjà bien suffisamment de boulot (avec très peu de développeurs) pour ne pas non plus se donner plus de travail. En outre si quelqu'un fournit un paquet, il est de-facto responsable de son contenu (or on ne développe/maintient pas G'Mic). Pour G'Mic, c'est un logiciel suffisamment complexe et élaborée pour qu'on se rende bien compte que si David venait à arrêter demain (on touche du bois pour que ça ne soit pas le cas!), on ne serait pas à même de le maintenir à sa juste valeur.
Donc non, on ne peut pas.
De même que David, je pense qu'il préfère garder l'indépendance dans ses sorties, etc. et ne pas dépendre de nos choix de sortie.
La tendance est plus à la création d'un système d'extension (voir ma news pour GIMP 2.10.6 qui devrait être publiée d'ici quelques jours) qui permettra d'installer facilement G'Mic et autres plug-ins, tout en laissant les développeurs de ces plug-ins en garder la main complète. Tout le monde y gagne. Et je sais, de source sûre, que David aime l'idée. ;-)
D'ailleurs une fois que cela sera en place, il est même possible que certains des plug-ins core actuels puissent devenir des extensions à leur tour (toujours maintenus par nous, mais avec un rythme de développement parallèle), ce qui permettrait des menus moins touffus de fonctions que peu de monde utilisent par exemple. À voir…
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Génial, mais on peut pas télécharger !
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche G’MIC 2.3.4 : traiter ses images, en se disant « déjà 10 ans ! ». Évalué à 5.
Oui c'est malheureusement un des trucs (le flatpak de GIMP et les plug-ins) sur lesquels il faudrait bosser plus. :-/
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Aperçu
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche G’MIC 2.3.4 : traiter ses images, en se disant « déjà 10 ans ! ». Évalué à 10.
Perso je pense que la prévisu sur canevas serait super utile, même pour les traitements lents.
La prévisualisation n'a pas à être activée par défaut. ;-)
GIMP donne aussi la priorité au rendu de la partie visible à l'écran, et le mipmapping aide aussi beaucoup si un zoom (avant ou arrière) est fait. Et je sens que les choses vont s'améliorer encore dans le futur pour optimiser la sensation de fluidité (ou du moins de pas avoir une expérience trop désagréable), même avec des traitements lents.
Ce sera clairement utile pour l'édition non-destructive également. Faire un changement dans les paramètres d'un effet peut te prendre 10 minutes, mais dans tous les cas, tu devras le refaire (ton effet). Dans le cas de l'édition non destructive, au moins tu pourras voir les paramètres utilisés précédemment et repartir de là. Dans le cas de l'édition destructive, tu as intérêt à avoir bien gardé une copie du calque d'origine et tu ne sais même pas l'ensemble des traitements faits, et avec quels paramètres, à part si tu les as notés bien consciencieusement (ce que certains font dans le nom du calque par exemple).
Pour moi, il n'y a rien d'équivoque là. Mais je crois qu'on a déjà eu cette discussion et qu'on pourra encore l'avoir à l'avenir. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Positive attitude
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.4 : on garde le rythme !. Évalué à 4. Dernière modification le 15 août 2018 à 18:42.
Je ne contribue que depuis (relativement) récemment, c'est à dire depuis 2012. Mais il paraît que certains des anciens contributeurs de l'époque d'avant n'étaient pas très cool, voire peut-être même un peu toxique. Mais ce n'est que du "on dit" car je ne les ai pas connus.
En tous cas, de nos jours, ce n'est plus le cas. :-)
On a un peu mis en pause pour diverses raisons. Déjà y a le côté technique. Le logiciel de streaming (libre) faisait quand même beaucoup souffler la machine (qui a déjà beaucoup à faire quand on fait de l'animation), voire était plutôt instable (cela nécessite OpenGL 3.2, ce qui veut dire qu'on doit installer les pilotes Nvidia proprio, et même là, ce n'est pas parfait). Le pire n'est pas seulement que ça plantait parfois, mais qu'il arrivait à faire freezer la session graphique de temps en temps. OBS Studio est cependant très connu et une référence a priori chez les gens qui font du live, même s'ils savent pas que c'est libre. Y a peut-être quelque chose à configurer mieux. Et aussi j'ai cru comprendre que la version Linux est moins stable de manière générale. À voir…
Ensuite oui, y avait pas tant de monde, et on se disait que ça valait pas forcément le coup.
Mais surtout, Aryeom a eu une petite période de blues ces derniers mois (je l'ai déjà dit, l'un comme l'autre, on se pose beaucoup de questions; on nous dit constamment que GIMP peut lever beaucoup de financement participatif, mais dans les faits, notre financement est faible), voire un petit burnout. Donc elle a préféré continuer à travailler sans les lives. Mais là je lui ai montré ton message, et elle se dit qu'il faut peut-être les recommencer. On verra!
P.S.: ne pas hésiter à laisser un message si on reprend les lives. Ça fait toujours plaisir et ça donne moins l'impression de faire un direct dans le vide. Faut pas donner tous les mercis qu'à moi. Y aurait rien de tout cela sans Aryeom non plus.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Fréquence de commits un peu exagérée
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.4 : on garde le rythme !. Évalué à 5. Dernière modification le 09 août 2018 à 23:18.
Je ne me souviens plus du calcul exact de l'époque mais je peux en refaire un.
En gros, je regarderais les commits faits entre GIMP 2.10.2 et 2.10.4, et ce, sur
master, car c'est là où se passe vraiment le développement (pas sur la branchegimp-2-10en particulier qui ne contient que les backports pour la série stable).Sur master, y a un tag
GIMP_2_10_2mais pasGIMP_2_10_4car on a créé la branchegimp-2-10justement à la sortie de GIMP 2.10.2 (donc c'est là où les 2 branches ont commencé à diverger). Pour le commit d'arrêt, je vais donc prendre un commit qui correspond à la date de sortie de GIMP 2.10.4, soit le 2018-07-04. Je prends le dernier commit à cette date. Note que ce n'est probablement pas le calcul que j'avais fait à l'époque, car j'imagine que j'avais prisHEADqui était sûrement différent à l'époque (soit un peu avant, soit un peu après la sortie. Je ne suis pas sûr quand j'ai démarré cette dépêche collaborative). Quoiqu'il en soit, voyons le nombre de commits:Comme il s'agit d'une période de 45 jours, je fais une moyenne, soit:
972 / 45 ≈ 21,6. Voilà (avec un arrondi, ça fait 22 ;p).Ensuite soyons clair: GIMP 2.10.2 est le moment où on a divergé vers le port GTK+3, comme je viens de le dire, donc ça veut notamment dire qu'on a mergé tout le travail fait sur GTK+3 (dont la majorité avait été faite ce même avril/mai, après la sortie de GIMP 2.10.0!) d'un seul coup. En un sens, ça a clairement boosté les statistiques. D'un autre côté, tant qu'on ne merge pas une branche de fonctionnalité, elle ne rentre dans aucune statistique. Faut bien qu'elle le rentre un jour (de même que j'ai des dizaines de commits qui attendent dans des branches de fonctionnalité en cours, et un jour, je les verserai dans
masterd'un coup, mais en attendant, c'est comme si ils n'existaient pas). De toutes façons, il y avait clairement un moment, qui correspond à la sortie de GIMP 2.10.0 où on a vraiment eu un gros pic de contributions.Si maintenant tu remontes plus loin, par exemple le début d'année, comme tu le proposes, on a une moyenne à 11 commits par jours:
De manière générale, il y a forcément des hauts et des bas dans le développement. Surtout que comme on est 3 à faire la plupart des commits, forcément il suffit qu'il y ait une période où l'un de nous est peu actif pour que les stats baissent (par exemple pour le mainteneur, c'est souvent les fins d'année où il a moins le temps de contribuer car il a un commerce), de même qu'y a des périodes où tout le monde s'active. Quand je dis qu'on est très actif depuis des années, ça veut pas dire qu'y un taux constant de contributions à tout moment (ce serait pas humain!). D'ailleurs, ailleurs dans un commentaire, je dis même que notre développement s'accélère au contraire (ce qui ne veut pas dire que ça ne va pas se calmer à un moment, et puis de toutes façons, il y a des limites humaines à notre rythme de contributions!). Voilà, donc en gros, faut pas non plus s'attacher au mot près. Je donnais les stats entre 2.10.2 et 2.10.4, qui étaient effectivement de 22 commits par jour en comptant dans git, et c'était effectivement un très gros pic.
Enfin les stats, c'est aussi beaucoup du "marketing", soyons clair. De toutes façons, on peut faire dire beaucoup de choses aux nombres, on le sait tous. Rien que le choix d'unités est sujet à critique. Un commit, est-ce vraiment un critère adéquat? Faut-il compter le nombre de lignes à la place? Compte-t-on alors les lignes de commentaires (important aussi) ou juste le code pur et dur? Et qu'en est-il de ceux qui ont un code plus concis ou plus élagué (par exemple déclaration et définition sur des lignes distinctes, etc.)? Comment compte-t-on le temps de recherche, diagnostic, lecture de docs? Le temps pris pour des choses (importantes) autre que du code (écriture de news, docs, etc.), même? D'ailleurs peut-on même simplement compter le temps passé par les contributeurs pour GIMP (réponse directe: non, c'est du logiciel libre, on sait pas combien de temps passe chacun), et alors qu'en est-il des gens simplement plus efficaces que d'autres? Etc. Etc. Etc.
Ma conclusion, c'est que ce sont des stats. Les miennes étaient vraies (comme montrées plus haut) car notre branche master a réellement 22 commits par jour entre GIMP_2_10_2 et la sortie de 2.10.4. Ensuite ça vaut ce que ça vaut (pas grand chose, ou beaucoup, c'est selon).
Là où je voulais en venir avec ces stats, c'est que c'est du développement vraiment très actif. Et d'ailleurs tu es d'accord sur ce point. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: avec insistance
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.4 : on garde le rythme !. Évalué à 2.
Va pas donner de mauvaises idées aux gens! :P
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: GIMP Fundation ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.4 : on garde le rythme !. Évalué à 5.
Ah je pensais que tu parlais du développement en cours, parce qu'on nous fait souvent la remarque qu'on devrait sauter direct à GTK+4. On y a pensé nous-même d'ailleurs (on a une news vieille d'avant même la sortie de 2.10 où on évoque la possibilité) mais on a décidé que ce n'est pas une bonne idée (pas avant stabilisation du moins).
Ahahah. Qui sait?! Moi j'en sais rien en tous cas. On y travaille, mais on donne pas de dates. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: GIMP Fundation ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.4 : on garde le rythme !. Évalué à 9. Dernière modification le 05 août 2018 à 10:57.
T'inquiètes, je n'avais pas pris mal ton commentaire. J'essayais simplement d'y répondre pertinemment. Le fait est que quand on fait quelque chose similaire à notre projet, on semble se récolter tous les conseils du monde. Ce n'est pas mal, soyons clair. C'est un peu fatigant, mais ce n'est pas mal. D'ailleurs je suis sûrement aussi le premier à donner des conseils à d'autres quand ils se lancent par exemple en indépendant (je ne suis d'ailleurs pas certains si mes conseils sont si pertinents et si je contribue pas à fatiguer ces gens, même s'ils ne me le disent pas par politesse).
Le truc, c'est aussi que beaucoup de ces conseils sont des trucs que je sais, ou même que je sais ne pas marcher, voire souvent que j'ai déjà essayé maintes fois. Je pourrais te citer toute une liste des classiques (mais je vais pas le faire sinon rallonger encore plus le commentaire).
Dans ce fil, on me propose de faire une fondation GIMP (je l'ai entendu 20 fois), qu'il faut plus d'argent (captain Obvious), que beaucoup attendent les fonctionnalités X ou Y (on accepte les patchs!). D'ailleurs la pertinence de ta liste de fonctionnalités est vraiment sujette à question. Genre quand tu me dis:
Ben… non GTK+3 n'est pas obsolète. C'est la version à jour de GTK+. Non, on ne va pas commencer à travailler sur une version "mouvante", pas sortie et donc qui va constamment casser son API. On a bien assez de boulot (et comme tu le notes, on est peu nombreux). Travailler sur une version de développement serait comme se tirer une balle dans le pieds pour être sûr que GIMP 3 ne sorte jamais (ou dans 10 ans) et qu'on ait constamment à corriger notre code (comme si on n'avait pas assez de travail!). Surtout qu'on parle de GIMP, pas d'une petite application mono-fonctionnalité de 10 000 lignes de code (qui elle, oui, peut se permettre des changements dans son toolkit, éventuellement… enfin si elle ne prévoit pas de sortir d'ici quelques années!).
Nous avons une règle au sujet de nos dépendances pour la branche master: il faut qu'elle soit dispo dans Debian Testing. Cela la rend suffisamment récente pour travailler avec des dépendances qui ne sont pas dépassées, et en même temps, on sait que cette dépendance fera son apparition dans les autres distribs d'ici 1 an ou 2.
Attendons que GTK+4 sorte et soit stable pour le considérer.
Tu vois, clairement, c'est aussi un conseil de quelqu'un qui n'est pas sur le terrain. :P
C'est vrai, mais c'est le cas de 99.99% des logiciels Libres. Je viens de regarder (encore) l'activité de Blender. Ils ont à peine plus de gros développeurs que nous (si je regarde 2018, je dirais 4 vraiment gros développeurs). Ensuite oui, je suis sûr que Firefox ou Apache n'ont pas ce problème. Mais pour en arriver là, ce n'est pas juste un ou 2 commerciaux qu'il faut engager.
Et je suis totalement d'accord, puisque j'ai répondu que c'est exactement ce que l'on fait! ;-)
Il y a un million de trucs à répondre à ça! Déjà, comment le paie-t-on? On est une asso, on fait du tout-libre, etc. Donc effectivement si quelqu'un veut aider bénévolement parce qu'il veut promouvoir le la création Libre (un des objectifs de l'asso), on n'est pas contre. Dans les faits, on a eu des aides ponctuelles déjà, de par le passé, mais on ne va pas pousser ces gens à travailler d'arrache-pied sans être payés. Perso j'aimerais que tous ceux qui travaillent soient payés (correctement en plus), idéalement. Je fais partie de ces gens qui considèrent que c'est normal de payer quelqu'un pour un travail et je ne veux surtout pas trop profiter des gens (même raison pour laquelle je n'aime pas les stages par exemples, et surtout les stages non-payés; on nous en a encore proposé y a pas longtemps et c'est pour moi de l'exploitation de jeune mains d'œuvre). Or si on paye cette personne, ben nous on n'a plus de sous (je rappelle que depuis quelques années, on jongle avec quasi rien).
Ensuite y a la fameuse réponse, oui mais cette personne est censée ramener plus que ce qu'elle coûte! Donc une fois engagée, elle ramènera de quoi vous payer. Déjà ce n'est pas sûr. De même que j'expliquais qu'il peut y avoir de mauvais dévs, il peut aussi y avoir de mauvais commerciaux (quand on parle de financement, ou marketing pour la pub; au passage, tu me parles de 2 postes différents là comme si c'était la même chose!). Donc ce n'est pas sûr qu'ils ramènent quoi que ce soit. Peut-être se retrouvera-t-on à les payer pendant 6 mois sans qu'il n'y ait aucun retour puis on doit leur dire au revoir, et entretemps, le projet a pu tomber à l'eau (car un développeur et une réalisatrice, ça mange aussi). Ensuite y a le fameux sujet: ces gens sont-ils vraiment ceux qui ramènent l'argent? On retrouve souvent ce sujet de discussion lorsqu'on se demande s'il est vraiment normal de payer des CEOs des prix exorbitants (et l'une des 2 réponses est souvent: oui mais ils sont censés ramener plus que leur salaire). Soyons honnête 2 minutes, les commerciaux sont ceux qui mettent leur nom sur le papier et qui signent, mais en général, sans le travail des techniciens (développeurs, animateurs, etc.) qu'ils ont vendus, y aurait rien eu à vendre. Prenons l'exemple de cette récente donation de 400 000 $ à GNOME/GIMP. Cela a-t-il été ramené par les commerciaux/CEO en arrière-plan qui ont démarché le donateur? Peut-être (ou pas, j'en sais rien, c'est pas écrit). Ce donateur aurait-il donné de toutes façons si y avait juste eu des développeurs parce qu'il aime GNOME/GIMP indépendamment d'un quelconque démarchage? Peut-être aussi. Le fait est qu'on n'en sait rien pour GNOME. Ce n'est malheureusement pas si simple à répondre, mais il est vraiment très pertinent de se poser la question.
Par contre côté GIMP, on peut répondre tout de suite: on ne savait rien de cette affaire, on n'a pas démarché, donc cette donation n'a rien à faire avec un quelconque marketing/commercial (et non ce n'est pas GNOME qui a demandé pour nous). Ce qui tend à invalider l'assertion qu'il faille du marketing pour de gros financements. :-P
Très bon exemple, si je me souviens bien, à l'époque (qui a duré de nombreuses années, alors même que Wikipédia était déjà connue et dans le Top 10 mondial des sites visités), leur seul employé était un admin. Car au final, ça sert à rien d'avoir du marketing et du commercial si l'exécutif ne fonctionne pas. La première chose à faire, c'était d'avoir un site qui fonctionne. De même que pour nous, la première chose, c'est de faire un film. :-)
Alors oui, je suis entièrement d'accord avec tout ce que tu dis sur le fond. Je ne me méprenais pas sur ton commentaire précédent non plus, de même que je veux être clair pour que tu ne te méprennes pas sur le mien. Mes réponses ne sont pas aigries ni en colère, ni quoi que ce soit de négatif. C'est pour cela que j'essaie de les parsemer de smileys (mais apparemment ça marche pas). Et là, quand je te réponds, je souris. Promis, c'est pas un mensonge! :P
Je sais aussi que mes longs commentaires à rallonge (j'arrive pas à faire court!) peuvent faire croire le contraire, mais ils ne signifient pas un état de désaccord.
Donc, reprenons: oui je suis d'accord… mais comme je l'ai expliqué, ce n'est pas si simple. Dire "il vous faut du marketing", c'est une recette de grand mère qui est à la fois évidente et à la fois pas en phase avec le monde réel qui ne prend pas en compte le fait qu'il faut payer cette personne, que ce n'est pas dit que cette personne va vraiment ramener des fonds, et surtout que ce n'est absolument pas sûr que je n'aurais plus à me soucier de rien. Par exemple, je l'ai dit, par le passé, on m'a déjà proposé de m'aider pour du financement (qu'on n'a pas eu), et au final, j'ai passé 90% du temps sur le dossier car c'est moi qui connaissais le mieux le dossier (note que je n'en veux pas du tout à cette personne qui m'a quand même aidé sur les 10% et je suis reconnaissant, mais c'est pas ce que j'appelle "ne plus se soucier des problèmes"). Ça c'est la réalité. :-)
Merci beaucoup pour cela! :-)
Perso je relativise notre taille. Oui on est petit et ridicule, et c'est pour cela qu'on ne peut pas engager quelqu'un en espérant qu'il soit doué et ramène soudainement beaucoup, tout en se mettant à négliger tout l'exécutif. En même temps, on arrive à tenir depuis quelques années. J'y crois personnellement. Certes cela ne m'empêche pas de régulièrement rappeler les gens de notre existence en demandant de nous soutenir, mais je suis confiant que ça va aller en s'améliorant, même si j'ai aussi mes périodes (très régulières) de doute.
En fait je pense que tes conseils sont vrais, mais simplement mettent la charrue avant les bœufs. Ils ne seront applicables que quand l'asso aura réussi à nous rémunérer convenablement d'abord. Un projet qui ne pense pas à l'exécutif d'abord ne vaut rien. Et ce jour là, quand on aura des sous en plus, alors on pourra penser à engager du marketing.
Wikipédia, c'était pareil, ils ont commencé par rémunérer l'exécutif. De même que la fondation Blender, quand ils ont eu des sous, ils ont payé du développement (et des animateurs avec leurs fameux Open Projects), etc. On ne commence pas un projet sans sous avec du marketing et du commercial. Enfin si, certains le font. On appelle ces projets des vaporwares. :P
En tous les cas, c'est mon point de vue et aussi la position de LILA à ce jour. Peut-être qu'on a tort (mais je crois pas).
Ah et dernier détail: tu ne peux pas nous comparer avec la Blender Foundation (née en 2002), la Wikimedia Foundation (2003), la Mozilla Foundation (2003), la Linux Foundation (2000) ou je-ne-sais quelle autre fondation ou association qui ont 15 ans ou plus, qui fonctionne confortablement et avec laquelle tu nous compares (nécessairement car tu cherches des points de comparaison et ce sont les organismes que l'on connaît bien dans le Libre). LILA existe techniquement depuis presque autant (on l'a fondé avec un ami en 2005, pour un projet de Musique Libre qui n'a pas connu le jour), mais dans les faits, elle est tombée en sommeil et est née à nouveau en 2015. Si tu veux nous comparer, prend les autres organismes nés récemment et tu verras qu'elles sont toutes aussi petites que nous, voire qu'elles ont plus de mal que nous.
Il y a 15 ans, déjà c'était plus simple car il y avait encore peu de projets, donc dès que l'un d'eux émergeait avec du code fonctionnel et commençait à se professionnaliser, les gens se ruaient dessus avec leur portefeuille ouvert. De nos jours, les projets florissent quotidiennement. Les gens donnent toujours, mais ils répartissent leurs dons. Regarde donc tous ces autres projets récents dans le Libre: ils ont tous autant de mal que nous.
En outre, même ces gros projets d'antan n'ont pas commencé avec les sommes de maintenant. Donc il faudrait nous comparer avec leur situation d'antan (probablement un peu meilleure que nous, car peu de projets à l'époque encore une fois, mais meilleure de très peu).
Voilà. Je pense qu'on peut conclure ici. Encore une fois, mes longues réponses ne sont ni des attaques ni des défenses (je ne me suis pas senti attaqué). Ce sont juste des explications de notre situation, et je le fais en détaillant un peu comment marchent les choses de mon point de vue (qui peut être erroné, mais en même temps, c'est ainsi que je le vis au quotidien, donc même si j'ai peut-être tort, j'ai du mal à m'en défaire). Et donc oui, on professionnalise le développement de GIMP et la réalisation d'un film libre (ce sont des faits; on a du mal, mais on y arrive en partie); mais non, je ne pense pas que cela peut passer par l'emploi de gens au marketing à notre stade (sauf s'ils veulent le faire bénévolement pour LILA, mais même là, on ne peut pas accepter n'importe qui juste parce qu'ils veulent, et surtout je peux pas aller les chercher: ils doivent proposer d'eux-même, c'est une partie de la définition du bénévolat).
Désolé. Je suis conscient que c'est pas facile de voir l'état d'esprit des gens à l'écrit, surtout avec un long pavé comme les miens. :P
Merci. On pense aussi être sur la bonne voie, même si on est pas sûr que notre véhicule tiendra le coup jusqu'au bout parce que cette voie est un peu caillouteuse. Et oui on espère aussi qu'on trouvera du financement. ;-)
Si tu veux, et si tu es à Paris, je serais heureux d'en discuter autour d'un café (mon email traîne partout, notamment sur mes commits) et tu verras qu'il n'y avait pas méprise. Juste désaccord sur le process, mais sans aucun mauvais esprit. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: GIMP Fundation ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.4 : on garde le rythme !. Évalué à 10. Dernière modification le 04 août 2018 à 09:15.
Ben écoute d'un côté, on a une fondation (hypothétique) qui paieraient des salaires pour améliorer GIMP et de l'autre une association (non hypothétique, elle existe) qui paie des salaires pour améliorer GIMP. Mais le premier cas serait de la professionnalisation et le second une bande de potes hippies. Euh… Ce serait pas une nouvelle version du bon et du mauvais chasseur là? ;-)
Sérieusement c'est un peu triste. On a l'impression que vous vous attachez au nom. Parce qu'on n'a pas "GIMP" dans le nom, c'est soudainement pas "professionnel"? Ou alors je vois pas. Parce que soyons clair, c'est un peu la seule différence là.
Je pense que peu de logiciels peuvent se targuer d'avoir un développement aussi intense que nous. Attention, je dis pas qu'y en a pas qui ont un développement encore plus actif. Je suis sûr que Firefox par exemple nous coiffe au poteau. Par contre comparons par exemple avec un logiciel tel que Blender.
Voyons le nombre de commits dans GIMP (master) depuis le début de l'année et depuis début 2017:
Maintenant dans Blender (master):
Voilà, GIMP a plus de 40% de commits en plus sur les 8 derniers mois. Ensuite si on remonte le temps, Blender gagne du terrain, on a à peu le même nombre de commits sur les 20 derniers mois et ça s'inverse en remontant plus loin. Notre activité n'a fait que s'accélérer depuis des années, continuellement. Je sais pas trop ce que tu veux de plus.
Et tout cela, avec en gros 3 core développeurs (Mitch, Ell et moi-même) qui faisons à peu près le quart des commits chacun (puis y a d'autres développeurs, certains plus réguliers que d'autres). Je crois qu'on n'a vraiment pas de quoi avoir honte de notre petite équipe. Peu peuvent se targuer d'une telle activité.
Comme tu le soulignes toi-même, c'est juste une histoire de perception (ou encore "a priori"). Un logiciel comme Blender, on va lire qu'ils sont méga actifs, etc. Mais pas GIMP? Ensuite cette perception n'est heureusement pas généralisée, car (comme je le dis dans l'article), notre image a vraiment changée et je ne lis plus personne dire que le développement de GIMP est lent. Tu es le premier que je lis ressortir cela depuis un bon moment. :P
Ben les employés compétents et motivés aussi, je t'assure. Je ne sais pas exactement ton champs d'activité (mais si tu traînes ici, les probabilités que ce soit quelque chose dans l'informatique sont grandes!), mais dans le développement logiciel, tu trouves aussi (c'est à dire comme dans tout métier) beaucoup d'incompétents. L'argent ne fait rien à l'affaire.
Et pour avoir eu aussi mes expériences professionnelles dans le développement logiciel en entreprise (comme on peut s'y attendre), laisse moi te dire que notre petite équipe de bénévoles "hippie" n'a vraiment rien à envier à tes supers employés qui seraient plus à même que nous d'offrir aux gens ce dont ils rêvent. Franchement j'ai rarement vu un tel regroupement de gens compétents que dans notre micro équipe (non seulement les 3 au cœur, mais aussi ceux qui bossent sur GEGL, ainsi que certains réguliers qui font pas tant de patchs, mais quand ils en font ou quand ils réagissent, tu te dis que tu aimerais bien les voir plus souvent!).
En conclusion, je voudrais boucler et revenir à ce que j'ai dit au début de ce commentaire: oui LILA est professionnelle. Et lever des fonds participatifs pour employer des développeurs est exactement ce que nous essayons de faire. Franchement avant de parler d'engager de nouveaux développeurs/designers, on aimerait bien pouvoir avoir au moins assez pour payer ceux qui contribuent actuellement et aimeraient bien en vivre (nous sommes 2: le mainteneur de GEGL et moi-même sur GIMP, voire 3 en comptant Aryeom qui de temps en temps fait des illustrations pour gimp.org, des icônes, des ateliers, ou autres, et surtout aide en donnant continuellement des retours pour améliorer GIMP et son interface en tant que professionnelle l'utilisant au quotidien; aucun de nous n'a actuellement assez pour financer un salaire minimum).
Je dois avouer avoir un peu du mal à comprendre. Beaucoup nous disent que si nous faisions des crowdfunding pour améliorer GIMP, ils donneraient. Mais la réalité, c'est qu'on le fait depuis environ 2 ans maintenant (et oui, c'est officiel, nos crowdfundings sont listés dans la page donation de GIMP). On a donc déjà professionnalisé GIMP depuis 2 ans. Il ne tient maintenant qu'à vous tous de nous permettre de ne pas abandonner en si bon chemin (parce qu'on y pense plutôt régulièrement malheureusement). :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: GIMP Fundation ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.4 : on garde le rythme !. Évalué à 7.
Les fonds de GIMP ont toujours été gérés par la fondation GNOME. Cette annonce ne change absolument rien du tout. Mais vraiment rien.
Ensuite si on décide que cet argent peut aller en salaires, une partie peut éventuellement être donnée à LILA.
Encore une fois, relire mon commentaire. Je ne comprends pas pourquoi vous voulez absolument une "fondation" alors qu'on a déjà tout ce qu'il faut. C'est une obsession sur le nom?
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Bon
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Écoles d'ingénieurs: les frais augmentent. Évalué à 10. Dernière modification le 03 août 2018 à 09:13.
Cela implique que les étudiants doivent rentrer dans les cases. Si une personne décide de ne pas aller vers un boulot classique d'ingénieur centralien, et probablement avec un salaire moindre, alors il ne peut plus rembourser. Donc on le force à faire quelque chose de sa vie qu'il ne veut pas forcément.
Je ne dis pas cela au hasard. Il y a pas mal d'années par exemple, j'ai failli acheter un petit appart, pour lequel je me serais endetté pour des dizaines d'années et aurait été incapable de lâcher mon boulot d'ingénieur (sauf pour un autre, si possible avec le moins de vacances entre-deux). Puis je me suis ravisé et ai décidé que je préférais vivre bien. Par la suite, j'ai même démissionné (sans autre boulot en perspective), j'ai vagabondé, ai vécu dans plusieurs pays (en travaillant là-bas parfois, parfois non). Puis de nos jours, je fais du Logiciel Libre (pendant des années entièrement bénévolement) et je développe GIMP avec des salaires qui feraient rigoler (jaune) n'importe quel ingénieur (soyons clair, on parle même pas de salaire en sortie d'école, et de loin; mais vous êtes tous bienvenus pour aider à notre financement collaboratif si vous aimez GIMP ;p).
Mais globalement je suis heureux de ma vie, j'aime ce que je fais et mon but ultime n'est pas de rouler sur l'or (même si j'aimerais bien être bien payé, soyons clair; mais "vivre bien" passe en priorité).
Alors forcer les gens à prendre un prêt dès leurs premiers pas en tant qu'adulte signifie ne plus leur donner de choix sur ce qu'ils feront de leur vie. Ils doivent au plus vite marcher au pas. Ensuite certains, c'est exactement ce qu'ils veulent et ils sont très heureux avec cette vie. Mais pas tous.
Et la réponse éventuelle "ces personnes ne sont pas obligés d'aller en école d'ingénieur" n'est pas acceptable. Pourquoi serait-il interdit d'avoir de bonnes études d'ingénieur sans vouloir rentrer dans les cases professionnellement ni s'endetter? Tout ce que j'ai dit précédemment peut aussi s'appliquer à un ingénieur (comme à n'importe quel métier, donc n'importe quelles études).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]