Jehan a écrit 1633 commentaires

J'aimerais savoir si les développeurs (comme vous) sont assez rémunérés pour continuer à développer ce magnifique logiciel libre.

Ah et j'ai oublié de répondre sur ce petit point personnellement. Moi à l'heure actuelle, je suis sans-emploi. Je ne touche pas non plus de chômage (déjà parce que j'ai toujours démissionné de moi-même et mon dernier emploi classique était hors-UE), ni aucune allocation à ce jour. Je suis donc ce qu'on appelle un "précaire". Ensuite je vis ok, hein. Je suis quelqu'un qui a besoin de peu ("minimaliste" serait mon style de vie, diraient certains). Je n'ai pas besoin (ni ne veux) de grande télé qui prenne tout mon mur; mon ordi perso (celui avec lequel je fais tous mes développements) a 5 ou 6 ans, il me semble (et je compte le garder tant qu'il fonctionne ou peut être réparé par mes petites mains); j'ai pas besoin d'un grand appart; l'ensemble de mes vêtements tient dans une seule étagère de placard (c'est véridique! J'invite quiconque à le vérifier… bon + les vestes. Ma veste de moto à elle seule prend quasi autant de place que le reste de mes affaires au complet); et comme je dis toujours: il faut que l'ensemble de mes affaires importantes puissent tenir dans un sac à dos de voyage au plus, à tout moment… et j'ai travaillé par le passé donc j'ai quelques fonds propres (que je mange progressivement, ça ne durera pas éternellement, il faut bien se l'avouer!).

Donc j'espère que ça répond sur le plan plus personnel "comme vous" de ta question. Suis-je assez rémunéré pour développer ce magnifique logiciel libre? Malheureusement non! :P

Et si notre crowdfunding ne décolle pas, alors il est évident qu'un jour, je devrai faire face aux tristes réalités de la vie (expression consacrée, hein! Perso la vie, je pense qu'on peut l'avoir heureuse plutôt que triste, ce pourquoi je fais ce projet pour diriger ma vie dans le sens que je veux; j'espère que je me trompe pas!) et trouver un boulot chiant, comme tout le monde, puis diminuer progressivement mes contributions à GIMP (plutôt que les augmenter comme ce fut le cas continuellement depuis quelques années).

Il ne tient qu'aux contributeurs de ZeMarmot de faire en sorte que cela n'arrive pas (oui je fais un peu de rentre-dedans, mais faut ce qu'il faut! :p).

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

J'aimerais savoir si les développeurs (comme vous) sont assez rémunérés pour continuer à développer ce magnifique logiciel libre.

Ahahahahah, la bonne blague. ;-)
Nous ne sommes pas payé pour développer GIMP. ZeMarmot est justement une de mes tentatives pour faire exactement cela: être payé pour développer mes logiciels libres de choix, en particulier GIMP.
Aucun des développeurs GIMP à ce jour n'est payé pour travailler sur GIMP, ni par le projet GIMP même, ni par une entité tierce. Tout le monde a un job à côté, qui souvent n'a rien à voir (le mainteneur par exemple, le seul dév qui fait plus que moi sur GIMP, a — si je ne m'abuse — sa propre grande librairie en Allemagne).

GIMP effectivement n'a pas d'entité propre et donc la fondation GNOME gère ses finances. Cet argent est utilisé pour réunir régulièrement les développeurs, au moins une fois par an (ce sera 2 fois en 2017; et en 2015 aussi sauf que nous n'avions pu être présent qu'une fois), au minimum lors du Libre Graphics Meeting. GIMP nous sponsorise alors en nous remboursant le trajet et en nous hébergeant (dans un grand appart où tous les contributeurs sont logés; régulièrement il arrive qu'il n'y ait pas assez de lit et que 2 gars se retrouvent à partager un grand lit!).

Donc l'argent que vous donnez à GIMP directement est très bien dépensé et je vous encourage à le faire, car c'est très important de pouvoir bien traiter ses contributeurs, de les faire se rencontrer pour discuter en live régulièrement (sans le financement, beaucoup ne pourraient se permettre de voyager régulièrement dans le cadre d'un hobby), pour discuter le futur de GIMP, mais aussi simplement pour les faire se sentir appréciés et donc qu'ils continuent à contribuer. Sans ça, pas de GIMP aussi extraordinaire qu'il est à l'heure actuelle!
Mais il ne faut pas croire que des dévs sont payés avec cet argent pour autant. Pas à l'heure actuelle, ni depuis des années (et je pense que cela n'a même jamais été le cas). Si vous voulez aller dans ce sens, alors c'est typiquement des projets comme ZeMarmot (avec LILA, Libre comme l'Art, une asso loi 1901 derrière pour gérer l'argent) à qui il faut donner, puisque payer un développeur pour développer GIMP est l'une des cibles financières, clairement édictée, du projet.

Bon je ne veux pas donner l'impression de diverger l'argent de GIMP et s'il vous plaît, tous ceux qui veulent donner à GIMP, faites le! :-)
Mais si vous voulez assurer un dév payé sur GIMP, alors donnez aussi à ZeMarmot! ;-)

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

Bonjour. Merci du compliment! :-)

Tout le monde est libre, mais si vous vous décidez à donner, cela nous fera très plaisir assurément. ;-)

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

Il serait bien de voir le travail accompli en quelques années

Ça ne fait pas vraiment "quelques années". En fait depuis la fin du crowdfunding initial (1 juillet 2015), cela fait exactement un an et 6 mois. En 2015, on a travaillé sur la pré-prod (design des persos, finalisation de l'histoire, storyboarding, on est allé en recherche de terrain dans les Alpes pour se créer des ressources vidéos et photos…). En fait, y a presque 3 mois à retirer qui furent utilisés sur un autre projet dont les fonds ont été réinjectés dans ZeMarmot. Début 2016, nous avons commencé la prod, me semble-t-il (en mars, je crois, de mémoire, à peu près la période où nous avons commencé Patreon/Tipeee). Par "production", on entends qu'Aryeom a commencé à dessiner les images "mouvantes" qui constitueront le film. Cela fait donc 1 an mois de préparation (pour info, c'est rien; les films ont souvent des années de "développement" puis des mois de pré-production avec toute une équipe; dans notre cas, on a un peu mergé développement et pré-prod en un seul concept et compressé cela sur un an) et 9 mois de dessin, dont 3 mois — encore — sont quasi partis à la poubelle à cause de l'entorse (Aryeom a pu dessiner un peu de la main gauche sur une partie, mais ce fut beaucoup de travail gâché qui aurait peut-être été mieux utilisé à se reposer entièrement).

Ça c'était pour retracer un peu le parcours.
Sur la progression de travail maintenant: le pilote a 6 scènes, et Aryeom a quasiment fini d'animer et de "nettoyer" la première scène. Il restera donc à faire l'animation et nettoyage des 5 scènes restantes, puis la peinture des décors, le coloriage de l'animation, la musique, le générique de fin…
Beaucoup beaucoup de travail en perspective pour une personne seule… C'est pourquoi nous avons besoin de fonds, déjà pour pouvoir payer le travail fait seul, puis pour pouvoir engager d'autres animateurs.

un budget de plusieurs milliers d'euros tout de même

Oui, un budget de plusieurs milliers d'euros… mais je sais pas si tu connais un peu les budgets des films d'animation au cinéma (ou même à la télé). ;-)
Déjà faut savoir que même en moyenne ou "au minimum", c'est au dessus du budget des films "live" (= avec acteurs filmés) car cela prend énormément plus de temps et de personnes. En gros la prod (= tournage) d'un film live, c'est 2 mois, voire parfois 1 mois avec les coupes de budget (quelques mois pour un film Hollywood qui a beaucoup de sous). La prod d'un film d'animation, cela peut potentiellement s'étendre sur des années avec des dizaines d'animateurs payés temps plein. En tous cas, même si avec un style simplifié et une prod expédié, ce ne sera pas juste quelques mois, au moins 1 an, avec plein d'animateurs, je dirais. Forcément ça va chiffrer différemment.

Y a quelques jours, nous étions au festival "Carrefour de l'Animation" au Forum des Images de Paris, avec l'invité spécial Michael Dudok de Wit, en tant que réalisateur de "La Tortue Rouge". À une des questions "De quel budget a besoin un tel film d'animation?" lors d'une de ses confs, il a répondu au minimum environ 3 ou 4 millions d'euros. Et encore, là on parle sur le marché Européen car aux US, ils multiplient ce chiffre par 10; et bien plus si on parle de films Disney ou Pixar qui ces dernières années s'approchent d'années en années des 150 millions d'euros par film animé.

Donc à côté de cela, nos "plusieurs milliers d'euros" font pâle figure. ;-)
Je pense pas vraiment que l'ajout de l'adverbe "tout de même" soit très approprié quand on sait ce que coûte d'animer. En fait, je vais le dire franchement: j'ai même avancé moi-même, personnellement plusieurs milliers d'euros que je ne suis absolument pas sûr de revoir un jour (et sans avoir jamais été payé).

Mais nous faisons cela avec plaisir, par passion et parce que c'est un pari sur l'avenir. Une expérimentation qui — nous l'espérons — pourra sortir de ce statut pour devenir une vraie production.

Donc voilà, j'espère avoir répondu à ta question, et probablement même un peu plus. ;-)

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

De bonnes questions! Et quelqu'un m'a posé la question de cette nouvelle plateforme par email y a quelques jours d'ailleurs.

Je suis sensible à la question des frais prélevés par les plateformes de financement participatif.

Je vais répondre à divers points ci-dessous, mais avant toute chose je voulais noter qu'il existe aussi une alternative sans frais (pour quiconque est en zone SEPA): une donation directement à l'association LILA. Si c'est fait par virement par exemple, ça peut même être un virement permanent mensuel d'un petit montant, et on retrouve le même principe que Tipeee/Patreon/Liberapay/autre… sauf que c'est sans frais (enfin je ne sais pas si c'est dans les règles SEPA ou juste un service habituel des banques, mais il me semble que dans toutes les banques françaises du moins, les virements faits depuis le compte internet et en zone SEPA sont sans frais; j'ose espérer que c'est pareil dans les autres banques européennes).
À ce jour, personne n'a fait de petite donation mensuelle de cette façon. Les quelques donateurs qui font des virements, c'était pour des dons un peu plus gros.

Le RIB de l'asso est disponible sur le site et les donations accompagnées d'un petit email sont les bienvenues. :-)

Ceci dit, donner sur Tipeee/Patreon, ça permet aussi une visibilité. Certains donnent parce que d'autres donnent et il me semble que le plus dur est de démarrer. Donc avoir beaucoup de donateurs, ça entraîne les autres.

Est-ce que vous pourriez, sur les pages où vous indiquez les différentes options pour vous soutenir, indiquer les frais de chacune de ces plateformes ?

Je vais le faire ici, mais pas sur les pages de soutien. Le but n'est pas de faire des pages à rallonge, mais quelque chose de simple. Déjà je suis pas doué pour ça, et j'ai tendance à trop complexifier nos pages!

Je viens de regarder, cela semble être 5% pour Patreon et 8% pour Tipeee—Tipeee a fait disparaître la page lisible qui explique leurs frais et c'est assez douteux de leur part.

"Douteux", je ne sais pas. Je ne pense pas, même. Je pense que c'est simplement une startup plus jeune et comme beaucoup de startups, ils font l'erreur de faire pleins de changements bling bling partout avant de consolider l'existant. Je suis sans cesse en train de pester contre les bugs de la plateforme (notamment quand j'écris mes news) et je leur ai remonté plusieurs fois les bugs (la réponse est invariablement rapide et amicale, me disant que le bug est connu et que les dévs y travaillent… on va dire qu'ils sont pas rapides, hein! ;p).
Tout ça pour dire qu'ils n'ont pas fait disparaître la page qui explique les frais, je viens de la retrouver sur leur site en moins de quelques minutes en cliquant le lien "How it works", puis je sélectionne "Creator". On y lit que c'est effectivement une commission de 8%. Je pense qu'ils ont simplement refait cette page pour la énième fois. Faut pas voir le mal partout. ;-)

Pour Patreon, oui ils prennent 5%; ensuite dans les faits, en comptant les frais hors plateformes (en gros quand les contributeurs paient par un service de paiement, donc les frais Paypal pour le dire autrement), on monte bien au delà (car beaucoup de gens paient par Paypal). Dans notre cas, je constate des frais de paiement de 6% environ tous les mois, donc 11% au total. Autant les frais de plateformes sont fixes, autant ceux de paiements ne le sont pas par contre. La solution pour les diminuer serait que les contributeurs ne passent pas par Paypal pour payer, ou à défaut de faire de plus grosses donations (Paypal ayant une partie fixe, les frais Paypal diminuent en pourcentage en donnant plus).

Avez-vous envisagé d'utiliser des plateformes avec moins de frais, comme Liberapay récemment présentée ici ?

Oui j'y avais pensé sauf qu'à l'époque où j'ai découvert, on avait déjà commencé Tipeee. Changer signifie donc dire à nos 31 (à l'heure d'écriture) contributeurs récurrents de changer et nous suivre ailleurs. Bien sûr certains le feraient, mais ce serait très présomptueux de notre part de supposer qu'ils feraient tous un compte sur encore une autre plateforme sur un claquement de doigt.
D'un autre côté, tu me diras, on se ferait un nouveau public aussi de gens qui au contraire rechignent à aller sur ces plateformes. Mais se créer une base de contributeurs prend vraiment un temps fou. C'est simple, ça fait 9 mois et on en est à juste 31 tippers récurrents pour 150€ (+ 1 tipper unique ce mois). Alors certes, ça a l'air peu (et c'est peu, soyons franc), mais c'est 9 mois de labeur!

Ensuite je sais que je suis pas le plus grand génie du marketing, loin de là. Je sais que je pourrais faire bien mieux et plus. Mais c'est lourd. Tu remarqueras que j'ai ni compte perso twitter ni Facebook (et je n'ai jamais eu, ni n'en veux un), cela ne m'intéresse pas et franchement je me fais violence pour faire du "réseau social" pour le projet. Ça explique d'ailleurs pourquoi nos comptes ZeMarmot restent avec tristement peu de "followers" sur ces réseaux car je me limite à "l'utile" (j'ai une info pertinente, je l'envoie), je fais peu de partages (pas que je veuille pas, mais pour ça faut utiliser la plateforme vraiment et lire ce qui passe! Je le fais de temps en temps pour aider mais seulement quand ça a un lien au moins pas trop éloigné avec notre projet, donc du logiciel libre, de l'art libre, du copyright…) et surtout j'envoie pas de photos de nos déjeuners ou de notre chat (que nous n'avons pas).
Je préfèrerais passer ce temps à coder (je passe bien trop de temps à faire des trucs qui ne m'amusent pas, mais sont nécessaires) mais faut bien le faire, sinon ben y aurait 0 contributeurs et on aurait arrêté le projet. ;-(
Tout ça pour dire que j'ai quand même fait pas mal pendant 9 mois, dont des trucs que j'avais jamais fait de ma vie, et notre résultat, c'est ces 31 tippers. Donc j'ai pas envie de faire table rase et de tout reprendre de zéro, même pour la promesse d'économiser 8% de frais.

J'aurais connu au tout début, y a de fortes chances qu'on aurait essayé Liberapay. Malheureusement ça s'est joué à quelques mois. Maintenant on va pas faire retour arrière. Et tu t'en doutes, on est les premiers à préférer n'avoir aucun frais de fonctionnement à payer. :P

Quand on fait un crowdfunding ponctuel, avoir une plateforme connue est important pour la visibilité.

Ce n'est pas ma raison principale. Je pense qu'il y a un peu de vrai, l'effet réseau tout ça. Mais je crois que c'est quand même beaucoup du pipeau marketing de ces plateformes pour se rendre indispensable (les gens doutent, se disent qu'ils veulent pas risquer un échec sur une plateforme peu connue, et paf! ils sont pris au piège!) et qu'au final, ça joue juste pour quelques petits micro-pourcents sur le succès total. Comme toi, je pense que notre communication personnelle a bien plus d'impact et joue pour 99% (stats au doigts mouillé) du succès (ou de l'échec).
Si je choisis de passer par ces plateformes, c'est vraiment pour la tranquillité d'esprit sur plein de choses chiantes: ils ont une infrastructure web (un site) qui tombe peu en panne, des admins qui sécurisent et des développeurs qui corrigent les bugs, s'occupent d'aller récupérer l'argent tous les mois, de l'envoyer sur le compte de l'association, on a un historique des contributeurs téléchargeable en .csv (on fait un film, on aura besoin de générer notre liste de générique de fin!), on a des factures et des relevés mensuels. On n'a plus que la com' à faire (et comme je dis plus haut, c'est déjà beaucoup). C'est pour toutes ces raisons que j'y vais. Et en ce sens, les frais sont bien dépensés. Alors oui ils sont importants et je préférerais moins de frais. Idéalement une asso qui fait des frais "au coûtants" (pour les serveurs et les salaires de quelques permanents pour la pérennité) pourrait aussi faire l'affaire. Ce serait peut-être même plus rassurant que Liberapay. Attention, qu'on me fasse pas dire ce que je n'ai pas dit: je n'ai jamais testé Liberapay et je dis pas que c'est pas bien! Je dis juste que pour la tranquillité de l'esprit, il pourrait être intéressant de penser à avoir un système de frais pour assurer la qualité de service, mais simplement sans but profitable (uniquement des frais de fonctionnement donc).

Ce que je trouve le plus intéressant dans Liberapay est l'aspect associatif qui va a priori chercher à trouver un système juste. C'est la raison pour laquelle j'aurais peut-être choisi Liberapay si j'avais connu à temps. La commission en soi, si elle assure un service de qualité (sans interruption, rapide, sans prise de tête, sécurisé et avec toutes les dispositions légales prises, etc.), ne me dérange pas plus que ça.

Enfin, vous recevez de l'argent tous les mois, donc si une plateforme plus petite/fragile coule dans deux ans, ce n'est pas un drame.

Comme expliqué plus haut, ce serait quand même un sacré coup dur. Bien sûr que certains contributeurs arriveraient à nous retrouver, mais je suis sûr qu'on en perdrait pas mal au process (notamment tous ceux qui donnent à plein de projets et qui ne ne souviennent plus forcément bien à qui, combien, etc.).

Note bien que ça ne m'empêcherait pas de privilégier une petite plateforme tout de même si on débutait le projet, parce que j'ai toujours aimé les outsiders ainsi que les services associatifs. Mais une fois lancé, un tel évènement fâcheux n'en serait pas moins un obstacle. Pas un "drame" certes, mais des embêtements et des jours de communication à relancer qui n'en sont pas pour autant bienvenus.

Je ne vois pas de raison de ne pas multiplier les options.

Moi si. Trop d'options, c'est vraiment dur. Déjà on est sur 2 plateformes car je me suis dit à l'époque que c'était une bonne idée de proposer aussi du dollar US. Ben tu vois, avec le recul, je commence à penser que c'était une erreur. Je dois tout faire en double! Bien sûr, les news, c'est globalement les mêmes textes, sauf que:

• Sur Tipeee, je sais qu'on a beaucoup de français, je mets donc toujours le texte français en premier; et réciproquement.
• Je dois relire pour transformer "tippeur" en "patron" selon la plateforme.
• Chaque plateforme a sa propre GUI web, home-made (avec vraiment des paradigmes super différents!), donc après le copier-coller, je dois refaire la mise en page. C'est du html derrière et on pourrait se dire que ça pourrait être directement édité, mais ils font tous leurs petits traitements internes qui pête le html déjà fait venant d'ailleurs. Genre tu sauves, et paf! quand tu reviens sur la news en cours d'écriture, elle est toute zarb, pas du tout comme tu l'avais laissée. J'ai essayé une fois et ça a été tellement la galère qu'après 1 heure d'édition, j'ai été obligé de jeter la news et d'en refaire une de zéro sans copier-coller la mise-en-page, juste le texte. Pas une partie de plaisir, je le dis!

Et ça, c'est juste les news inter-plateforme. Ensuite y a le problème qu'à chaque communication externe, je dois donner 2 liens, et expliquer pourquoi y en a 2 (on va pas perdre le futur contributeur du type indécis dès le clic de lien!). Quand je fais des petites images personnalisés avec les logos des plateformes, je le fais aussi en double. Et puis donner l'explication USD/EUR, c'est jamais joli (je parle esthétique genre d'un bouton)!
Si je fais un tweet, avec 2 liens, ça commence à plus faire beaucoup de place avec la limitation de taille. Sans compter que ça fait "touffu" et "pas simple".
Au niveau "communication", avoir une seule icône avec une marmotte qui fait un truc marrant (en rapport avec le fait de donner), et le texte "Contribue financièrement!", ce serait bien plus puissant, et générique en plus (même plus besoin de s'embêter avec les logos des plateformes: y a un seul endroit, c'est là, venez et aidez ZeMarmot!).

Au moins, là y avait pourtant une raison à peu près valable: 2 monnaies différentes. Si en plus, je dois rajouter une troisième option, je dis quoi? "Là c'est USD, là c'est EUR avec frais et là EUR sans frais"?
Non ça devient super laborieux. Si on change, on change. Mais on ne multiplie pas les options. Même les 2 plateformes, je me dis régulièrement qu'on a fait une erreur et que ça aurait peut-être été bien mieux avec une seule. D'ailleurs si jamais le financement sur l'une décolle alors que l'autre devait stagner, on abandonnerait peut-être cette dernière (en proposant aux contributeurs de contribuer dans l'autre devise. Je pense que certains — ceux qui donnent plus — seraient ok).
Et puis comme je disais plus haut, il existe déjà une alternative pour donner sans frais en fait, la plus simple: direct à l'asso par virement ou chèque, sans intermédiaire autre que les banques, ni plateformes web. Simplement c'est moins "visible", plus pour les donateurs aguerris et qui veulent aller au plus direct. Il n'est donc absolument pas nécessaire de rajouter une nouvelle plateforme pour remplir ce rôle. :-)

Voilà! J'espère que j'ai répondu à toutes tes questions. Pour la plupart, on se les est posées nous-même à plusieurs reprises et c'est donc le résultat de notre expérience avec ces plateformes (côté "créateur"). D'ailleurs je crois que tu es un de nos récents contributeurs, non? Merci beaucoup! :-)

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

Disons que si tu sais exactement ce que tu cherches dans cette section des alternatives….

Je comprends pas ce que tu veux dire. C'est une section qui marche pas pour les gens qui savent ce qu'ils cherchent? Donc le graphiste qui veut une alternative à Photoshop, ben la section "Alternatives" n'est pas bonne pour lui car il sait ce qu'il cherche?

Ou alors tu essaies de jouer sur les mots entre ce qu'on cherche et ce qu'on trouve? Parce qu'en l’occurrence, notre graphiste, il sait exactement ce qu'il cherche, et donc tape en 1 centième de seconde "photoshop" sans se prendre la tête avec (sans même voir!) de l'auto-complétion, par contre il ne sait pas ce qu'il va trouver.

Enfin voilà. Je vais arrêter là. Je voulais juste tester, donner un avis et faire un rapport de bug (que j'estime assez factuel: "la recherche marche pas en changeant la casse", je comprends même pas pourquoi avoir besoin de m'expliquer sur 3 commentaires sur le sujet) parce que j'aime beaucoup Framasoft et ce que vous faites. Mais apparemment mes commentaires sont mal pris et en plus sans cesse répondu soit avec de l'ironie ou de la mauvaise foi. Donc bon ok, j'ai compris: mes commentaires sont pas bienvenus. :-/

Je vous souhaite quand même de la joie et surtout de beaucoup vous amuser pour 2017! :-)

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

Il faut effectivement s'aider de l'auto-complétion.

Ah bah fallait le voir qu'y avait de l'auto-complétion! :-)
Franchement ce genre de trucs (autocomplétion), c'est typiquement les fonctionnalités dont on se rend pas compte quand on tape vite et qu'on sait exactement ce qu'on cherche.
C'est comme l'autocomplétion dans le moteur de recherche web, j'ai commencé à utiliser cela sur les smartphones car j'y tape trop lentement. Donc quand je vois que ça m'affiche un truc que je commençais à taper, je clique. Mais sur mon ordi… j'ai même pas le temps de voir ce que ça veut m'afficher.

Donc non, faut pas se baser là-dessus pour faire un système de recherche. Ce type de fonctionnalité est une bonne aide à la recherche, mais ne doit pas être indispensable pour réussir sa recherche.

Cette section des alternatives est accessoires. Ce n'est vraiment pas là-dessus que nous misons pour l'intéret de cet annuaire.

Ok, cool. Alors pourquoi la mettre?

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

Moi je suis pas d'accord avec cette phrase. Quand je fais des logiciels nouveaux et donc peu répandus, je ne les note jamais. Ce serait quand même un peu osé! Un peu comme si un cuisinier votait pour sa propre cuisine en ajoutant la remarque "exquis et belle présentation!" dans une vote de 5 personnes lors d'un repas familial.

Donc pas de problème pour voter pour des logiciels massivement utilisés surtout quand on sait que son vote sera noyé dans la masse, comme il n'y aurait pas de honte à voter pour soi à des élections nationales par exemple, mais on va pas voter pour soi-même sur un vote confidentiel avec 3 péquins, ou pire où on serait le seul à donner son avis! Ce serait totalement ridicule.

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

Si je veux rapporter des bugs ou des problèmes sur le site, je fais juste plein de messages sur linuxfr, à chaque fois que j'ai une remarque? Ou y a un tracker?

Bon en tous cas, j'ai déjà trouvé un bug: dans la section "alternative logicielles", la recherche semble prendre la casse en compte, ce qui est — je pense — une erreur. Ainsi si je cherche "Photoshop", j'ai des résultats, mais pas "photoshop".

Sinon je me demande si cette section "alternatives" est vraiment utile puisqu'on peut déjà faire une recherche équivalente (et qui fonctionne mieux pour le coup, quelque soit la casse) dans la recherche principale. Mais c'est plus une question en suspens, et je ne m'attends pas à ce qu'elle vous fasse retirer la dite-section. :-)
Sans compter que ça met le focus sur des logiciels propriétaires comme si les logiciels libres proposés ne sont que des "clones", ce qui, dans beaucoup de cas, n'est absolument pas le cas. Donc j'ai jamais été très fan de ce type de listing personnellement.

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

Très bonnes remarques. L'ancien site était "moche" (i.e. pas à la mode 2.0) mais on avait effectivement une vision d'ensemble des catégories de logiciel. Je me souviens en effet qu'il m'arrivait régulièrement de chercher des logiciels par catégorie sur votre site. Genre si j'avais envie de voir la liste des logiciels email, ça se faisait en 2 clics.

Ensuite c'est vrai que les catégories ont tendance à se perdre dans les UIs modernes et à remplacer cela par de la recherche évoluée. Mon desktop ne propose plus de menus par défaut et je m'en porte pas plus mal, bien au contraire. Je lance maintenant tous mes logiciels en 2/3 appuis de lettres. Si c'est là où vous voulez en venir avec Framalibre, il faudrait probablement donner une place plus prépondérante au champs de recherche (et notamment sur mobile, le champs de recherche en tête serait la vue par défaut!) et avoir un algo de recherche qui assure bien.

Une courte introduction sur ce que l'on trouve sur le site serait bienvenue, surtout que son contenu est élargi.

C'est vrai aussi. Pour ceux qui arrivent sur cette page directement.

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

Les étoiles sont une moyenne des notes données par les divers contributeurs ou c'est juste la dernière note donnée par un éditeur?
Je viens d'éditer la notice de GIMP (qui ne s'est pas appelé "The Gimp" depuis longtemps, en fait je l'ai personnellement uniquement connu sous l'acronyme "GIMP" et je viens de vérifier: ça ne s'appelle plus "The Gimp" depuis la 2.4, presque 10 ans!), et j'ai voulu "voter". Bien sûr, biaisé :P, je mets 5 étoiles (c'était à 4). Or je constate maintenant que la notice montre 5 étoiles pour tous. Ai-je juste pesé dans la balance ou bien mon "vote" n'en était pas un et a juste remplacé la note précédente?
Si c'est le cas, ce n'est pas une très bonne fonctionnalité car elle reflète juste l'avis du dernier éditeur. :-/

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

Sur le plan de l'architecture, je vois rien dans le C4 en contradiction avec le fait qu'il prend presque tout.

Il faudrait être un peu plus clair: il prend tout et n'importe quoi, même des patchs qui cassent l'architecture actuelle? Ou bien des patchs qui revoient (et donc améliorent) l'architecture?

C'est pas du tout la même chose. En effet, je suis totalement d'accord qu'il faut pas être à cheval sur une architecture, même si c'est soi-même qui l'a conçue, on peut toujours faire mieux (ou évoluer progressivement). Un gars qui propose un changement profond qui remanie entièrement certaines parties architecturales du programme (ces changements doivent avoir du sens bien sûr!) est tout à fait viable et peut même être très bon. À partir de l'inclusion, cela devient donc simplement la nouvelle architecture (donc rien n'est cassé).
Ce genre de contributions arrivent d'ailleurs régulièrement et sont les bienvenues. Ce qui importe, c'est d'avoir un code propre qui respecte les dernières règles fixées.

Par contre, si tu parles vraiment d'accepter des patchs qui cassent les choix architecturaux sans les revoir (donc on se retrouve avec du code hybride où les règles établies ne sont pas suivies), alors je suis absolument pas d'accord.

Note que je n'ai aucune idée si Pieter Hintjens pense ainsi ou pas, et cela ne m'intéresse absolument pas de savoir. Il n'est pas nécessaire de continuer sur la discussion de savoir si on lui rends justice ou pas (pas pour moi en tous cas). Je parle de l'idée générale d'accepter n'importe quel patch qui casse l'architecture, que ce soit ce que cette personne promouvait ou pas.

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

Hmm… Je ne vois pas du tout par quelle logique tu es passé de mon commentaire au tien.

Si à partir d'une certain taille critique, cela devient trop risqué de le bouger

J'imagine que sur ce point, tu fais référence à ce que j'ai dit y a plusieurs commentaires sur la revue stricte. Mais ce n'était pas le sens. "Revue stricte" ne signifie pas "on ne bouge pas". Non un projet avec revue stricte, quand il bouge, il met un point d'honneur à le faire bien. Bien souvent, "faire bien" veut cependant dire "prendre son temps", pas accepter des patchs à la va-vite parce qu'ils "marchent" et tant pis pour l'archi, les règles de code et pour la réflexion sur une meilleure UI et sur l'expérience utilisateur en général !

Est-ce que ça ne veut pas dire que tout gros projet est destiné à être forké ?

"Destiné", je ne sais pas mais l'histoire montre que c'est courant, oui. GIMP a eu au moins 2 forks qui ont fait parlé d'eux. Ensuite les forks sont-ils souhaitables? Parfois oui bien sûr mais si la raison est essentiellement "ils sont chiants à prendre du temps et à vouloir vérifier mon code", je trouve cela dommage. Des 2 forks de GIMP, l'un (GIMP Painter) a des fonctionnalités qu'on voudrait vraiment avoir, on a manifesté notre intérêt, discuté avec le dèv… le problème ? Alors que la 2.8 était sortie, il développait sur des tarballs de la 2.6. De nos jours, il développe sur la branche 2.8 alors que le core a énormément évolué avec l'intégration de GEGL pour la 2.10. En gros il ne semble pas intéressé par notre processus de développement et fait tout à sa sauce. Personnellement je trouve que c'est très dommage et une raison de forker un peu triste. On veut de ses innovations, mais bien entendu elles ne valent pas un reset de tout notre code depuis 2.8! En fait, je lui ai redemandé récemment s'il ne veut pas travailler sur notre branche master et j'ai l'impression qu'il se fait beaucoup d'idées et qu'il s'imagine nos pensées. Quand il dit par exemple qu'il pense que la core team et lui ont des visions du design d'UI différente… je me demande vraiment d'où il peut tirer cela. Déjà même si on parle souvent de "core team" pour simplifier, il n'y a pas une pensée similaire en notre sein. On est surtout un groupe d'individuels. Parfois on a des idées similaires, parfois non, puis on discute, on argumente, parfois on change d'avis…
En plus je crois pas du tout qu'on bloquerait l'idée d'une toolbar horizontale (au contraire, j'y pense même très régulièrement et j'ai pas eu besoin de connaître GIMP-painter pour y penser), ce qu'il semble dire, etc. Quand il dit qu'avec le "succès" de GIMP painter, ça permettra aux dévs de GIMP de se rendre compte des vrais besoins des utilisateurs et aussi ça nous montrera comment implémenter ces fonctionnalités, je pense que ce développeur se fait beaucoup d'illusions sur son travail. Je pense qu'il est un dév très compétent et avec de bonnes idées, mais comme tant d'autres le sont. Il serait un très bon ajout à notre équipe pour faire évoluer GIMP plus vite et mieux (surtout s'il bénéficie de revue de code! Mais il semble ne pas vouloir subir cela); mais seul de son côté, non il n'est pas notre "modèle" à suivre. Et non on n'a pas le temps de regarder son code, surtout si celui-ci se base sur une branche totalement obsolète (vieille de très nombreuses années)!

Dans ce cas, pourquoi donc appeler au fork ici par exemple? C'est pour moi un exemple typique de gâchis de ressources de qualité. :-/

Ensuite, oui y a eu des cas où le fork a été très bénéficiaire (libreoffice vient à l'esprit immédiatement). Mais le fork est un outil qui a un poids et un prix conséquents. Il faut bien peser le pour et le contre avant de s'y lancer.

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

C'est vrai. C'est aussi une possibilité que beaucoup de projets bordéliques aient pu disparaître justement pour cette raison.

Ceci dit, il est toujours possible de réorganiser un projet, surtout quand il est encore petit. Et la qualité du code d'un même développeur va en augmentant avec le temps (d'habitude). On a tous été débutant, et donc on a fait des erreurs en tant que tel, qu'on ne fait plus 10 ans plus tard (on en fait d'autres! :P). Donc y a beaucoup de projets qui peuvent commencer bordéliques et avec une archi mal barrée qui peuvent encore être sauvés avant de devenir in-maintenable. J'imagine qu'un meilleur critère pour la survie est donc de savoir rattraper les erreurs de jeunesse à temps.
Ensuite, qui peut dire? S'il y avait une recette pour faire des gros projets à succès et que tu la trouves, tu es riche! ;-)

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 as répondu sur le mauvais message, mais c'est pas grave. ;-)

Je me suis un peu renseigné sur la position du dev ZeroMQ sur ce sujet je pense qu'elle est beaucoup plus fine que le "laisser faire" dont tu parles—le journal ne lui rend pas vraiment justice sur ce point.

Ok. Pour ma part, je n'ai pas cherché plus loin et me suis juste basé sur les dires du journal. Ça m'amusait que juste quelques heures après mon message, il y ait justement un journal qui parle du même sujet.

L'idée globalement est que chaque projet devrait décider un ensemble de critères pour les patch proposés, qui puissent être jugés objectivement (par une personne qui connaît bien le code), et ensuite que le travail du mainteneur devrait se limiter à vérifier que les critères ont été appliqués, et si oui inclure le patch.
[…]

The user or Contributor should write the issue by describing the problem they face or observe.
The user or Contributor should seek consensus on the accuracy of their observation, and the value of solving the problem.

Bon bah au final, c'est donc plus une revue stricte de contribution (ça m'a même l'air complètement le contraire de ce que dit le journal, donc tu as bien raison en disant que ça ne rende pas justice!) et ça se rapproche du type de revue que fait un logiciel comme GIMP (ou beaucoup d'autres).

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

Tu dis "les deux se défendent" comme s'il y avait deux positions discrètes, le tout-va et le toujours-nickel. En pratique il y a un continuum et on peut être "plus souple" ou "plus strict" sans passer d'un extrême à l'autre.

Bien sûr. Mais comme c'est une histoire de philosophie de maintenance, on rencontre souvent les extrêmes.
C'est marrant (et j'imagine, le hasard) car justement le journal qui te suit parle de cela, mais de l'autre point de vue.

Pieter Hintjens est un développeur récemment décédé et ce serait sa pensée qu'il explique dans des articles:

En partant de ces postulats, il considère qu'une architecture parfaite est secondaire. D'autant plus qu'elle repose déjà sur un grand bazar (pas une de vos dépendances n'est codée pareil). Par conséquent, lorsqu'on réalise un projet communautaire, toute contribution est bonne à prendre. Il nous invite à donc à être laxiste sur les conditions d'acceptation d'un patch. Ainsi, on permet une plus grande participation. Une intelligence collective se met en œuvre. Le groupe peut proposer des solutions plus pertinentes et adaptées. L'ensemble des intervenants est plus motivé. Ce qui attire plus de monde et diversifie la communauté. Elle passe ainsi dans un état propice à la résolution pertinente de problèmes.

C'est vraiment à l'inverse de ce qu'on fait dans un logiciel qui va contrôler plus sérieusement les patchs. Même s'il y a aussi un entre-deux possible, ici on voit plus des philosophies opposées. C'est pour ça que je fais ce genre de séparation (même si tu as raison). Ensuite je comprends bien ce point de vue laxiste aussi et je pense qu'il marche mieux pour les plus petits projets (petit notamment en nombre de lignes/fichiers). Pourquoi? Parce qu'un peu de bordel est acceptable dans ce cas. Ça reste lisible. Pour lancer un projet, c'est sûrement idéal même d'être très laxiste sur la revue de patch. Je n'étais pas là à l'époque, mais je suis sûr que ça a dû être le cas au début de GIMP aussi.
De nos jours, GIMP est un projet gigantesque en terme de fichiers, lignes de code, et fonctionnalité. Et pourtant il est globalement extrêmement bien organisé. L'architecture sépare bien les diverses parties du code (le "core" fonctionnel, les actions, la peinture, la gestion de fichier, les opérations graphiques, le GUI… et bien plus de sous-séparations encore). Le style de code est plutôt bien respecté partout (rendant le code très lisible). Etc.
Si on se mettait à accepter un patch qui casse nos diverses règles juste parce qu'il "marche", je pense que ce serait le début de la fin et qu'au bout d'un an, le code ne serait plus aussi maintenable.
C'est pas parfait mais c'est une base de code étonnamment bonne pour un projet de 21 ans. En fait je me rends compte que pas mal de gros projets sur lesquels j'ai contribué ont des bases globalement saines, alors que beaucoup de petits projets sont des bordels sans nom. Cela correspondrait donc à mon intuition comme quoi le laxisme du réviseur de code est probablement une bonne méthode pour les projets naissants, mais pas forcément autant pour les gros projets.

Tu ne parles que des "bons cas" dans les deux scénarios. […] ne dit rien, et le patch stagne. Dans les conflits dont on entend parler où un mainteneur bloque un projet, c'est souvent ce genre de problèmes à la base, où les gens s'accrochent à une notion de qualité qui a l'effet de geler le projet. C'est très facile de tomber dans ce travers là, ça m'est arrivé à moi aussi, et je pense que que c'est important d'en être conscient.

C'est vrai, ça arrive très souvent, surtout quand y a peu de développeurs. Et là aussi GIMP est un parfait exemple car nous sommes trop peu. Je ne crois pas qu'il y ait de vraie solution, et en particulier, je doute que transiger sur la qualité soit vraiment la solution. Comme je le disais, ce serait le meilleur moyen de bousiller le projet en rendant son code non-maintenable à moyen terme. On en accepte 1, puis 2, puis 10, puis 100. Et voilà, la base de code est flinguée.

Le second problème est les problématiques de design d'UI. Beaucoup de patchs bloquent sur les choix UI car les utilisateurs et contributeurs ont tous ce "petit quelque chose qui va rendre GIMP 1000 fois mieux!", disent-ils. Bien sûr, ils ne voient que leur utilisation, et parfois même pas forcément une utilisation habituelle. Genre ils basent leur patch sur leur expérience d'un projet où ils ont dû faire une tâche assez répétitive et ils se sont alors dit que si y avait tel bouton là pour faire ça, ça aurait vachement simplifié leur tâche donc ils font un patch et le défendent corps et âme. Mais je suis même pas sûr qu'une fois ce projet terminé, ils aient jamais besoin d'utiliser ce bouton encore. Et quand bien même, y a des millions d'autres utilisateurs de GIMP.
Le truc, c'est que si on devait accepter tous les patchs pour ajouter des boutons, à ce jour y aurait 1000 boutons dans chaque dock. En fait je trouve qu'y en a déjà trop. Je parle même pas de l'ordre des boutons ou fonctions. C'est simple, on a dû avoir des demandes pour toutes les combinaisons possibles. Si on acceptait chaque fois un patch pour changer l'ordre, GIMP serait totalement schizophrène et changerait l'ordre de ses boutons constamment.

Ce qu'il nous fait, c'est une GUI plus personnalisable, mais forcément ce patch n'est pas aussi simple si on veut le faire bien (c'est d'ailleurs dans mes cartons). ;-)

Tout ça pour dire que même si ce que tu dis est vrai, je ne suis pas sûr que ce soit une mauvaise chose de "s'accrocher à une notion de qualité" et s'y tenir. Mais encore une fois, un projet comme GIMP (ou gcc, et probablement même LLVM, ainsi que tout gros projet avec beaucoup de code et une base d'utilisateur énorme) doit être géré différemment. On ne doit pas s'empêcher d'expérimenter (et on le fait vraiment beaucoup; si t'as l'occasion d'essayer la version de dév, essaie!), mais on ne peut pas non plus faire tout et n'importe quoi.
Encore une fois, je pense donc que ce que tu dis s'appliquera bien mieux à un petit projet qui a tout intérêt à avoir des contributeurs et qui peut se permettre de changer plein de petits trucs très régulièrement.

À ma surprise à l'époque, les contributeurs m'ont demandé d'arrêter: ils n'aiment pas qu'on modifie leurs patchs "derrière eux" parce qu'ils ont vraiment envie d'apprendre comment faire le patch parfait et ils préfèrent donc que je leur explique les changements à faire. Maintenant je ne le fais que très très rarement.

Ah ça m'est jamais arrivé. Mais bon dans mon cas, je ne le fais que soit parce que le contributeur ne répond pas (mais que son patch est suffisamment intéressant pour être intégré moyennant quelques corrections), soit après déjà 3 ou 4 patchs corrigés (mais le contributeur n'a pas compris ou vu tous les problèmes qu'on lui soumettait); donc je pense qu'à ce moment le contributeur est soulagé de ne pas avoir à faire un autre aller-retour revue-patch.
Dans mon cas, j'essaie aussi de le faire aussi rarement que possible.

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

C'est intéressant ce que tu dis. Mais ne préférerais-tu pas et ne serais-tu pas encore plus fier d'avoir une revue de code juste mais stricte, qui te demande de revenir sur ton code, d'intégrer les changements demandés par le réviseur (est-ce la bonne trad pour "reviewer"?), puis que ton patch final soit intégré dans le logiciel sous ton nom à toi (et pas juste une vague citation)?

Personnellement je fais tout mon possible pour que le nom du contributeur reste l'auteur du commit. Bien sûr, si le contributeur ne répond plus, et que je suis obligé de réécrire totalement son patch (car il ne correspond pas à nos critères de qualité) qui à la fin n'a plus rien à voir, je suis bien obligé de me mettre en auteur. Mais j'essaie d'éviter d'arriver à cela. S'il le faut, je laisse du temps passer et attend quelques mois (parce que tout le monde a une vie et je comprends bien qu'ils ne peuvent pas forcément réagir immédiatement à une revue de code) en re-demandant 1 ou 2 fois où ça en est avant d'éventuellement me décider à committer quelque chose moi-même.

Personne ne s'arrachera les cheveux sur ton code et aucun système critique ne mourra par ta faute car ce sera alors du bon code. Ou du moins si problème il y a, ce sera tout autant (voire plus) la faute du réviseur de code (Si on doit absolument chercher un fautif — en reprenant tes termes — mais ce n'est absolument pas la logique habituelle, du moins dans les projets auxquels je participe où on fait du travail collaboratif et tout le monde a le droit à l'erreur; j'ai moi-même de temps en temps des commits qui doivent être annulés, ça arrive, c'est pas la fin du monde et personne ne lance la pierre). Et en plus ton nom sera dans les auteurs. J'aime donner ce petit bout de fierté aux contributeurs et je pense que c'est important de les faire se sentir part au logiciel auquel il contribue.
C'est pour moi l'une des meilleures fonctionnalités des systèmes de versionnement décentralisés. À l'époque de SVN, un contributeur occasionnel n'était qu'une bref citation dans le commit du message au nom d'un autre, même si le commit était 100% de vous (seuls les développeurs "core", c'est à dire ceux avec accès écriture sur le dépôt pouvaient être dans le champs "auteur", et donc un patch d'un contributeur revenait à celui qui le poussait). De nos jours, avec git, mercurial et co., on est capable de donner la véritable paternité d'un code et c'est réjouissant.

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

Je sais que c'est dans l'air du temps de discuter des "mainteneurs grincheux", alors je vais prendre un peu le contre-pieds, en étant régulièrement justement du côté "mainteneur" (ou "reviewer" de code, ce qui peut souvent être vu similairement pas un contributeur) de la barrière.

La partie du message à laquelle — j'imagine — tu fais référence en parlant de mainteneur grincheux qui introduit de la friction dans le développement, est:

L'autre inconvénient c'est que souvent ces personnes se retrouvent à dire "non, on ne va pas faire comme ça, il faut plutôt faire comme ça", et ça ne plaît à personne quand la personne en face essaie juste de faire intégrer un changement qu'on lui a demandé de faire.
<original>The other downside is that it often involves saying "no, let's not do that, let's do this instead" a lot, and that makes people feel bad when they know someone else is just trying to achieve a task someone assigned them.</original>

Moi quand j'ai lu cette phrase, je n'ai pas du tout interprété ça comme toi, mais plutôt qu'y a beaucoup de contributeurs qui ne veulent pas se faire chier, ni même forcément faire du bon code, et surtout pas interagir avec l'équipe et collaborer. Donc de leur point de vue, tout se passe bien si on leur dit "c'est génial, on intègre", mais dès qu'y a un peu de revue détaillée et qu'on leur demande de changer leur code pour intégration, y a plus personne au bout de la ligne (ou du mécontentement).

Daniel Berlin parle des gens à qui on a assigné une tâche (donc typiquement des gens qui contribuent essentiellement parce qu'ils sont payés pour le faire; notons que ça ne signifie pas toujours qu'ils aiment l'idée du Libre, ou de l'OpenSource, plus que ça). Mais il y a d'autres cas. On voit souvent des gens qui font vraiment du lâchage de patch, mais dès qu'on répond avec une revue de code (pas méchante, polie et amicale, mais on leur demande de changer des trucs), on n'a pas de réponse. Bien sûr, ça peut aussi être des problèmes de manque de temps (ça m'arrive moi-même régulièrement de laisser passer des mois avant de revenir sur un patch car j'avais d'autres priorités). Des fois aussi, les jeunes, étudiants ou développeurs moins expérimentés ont beaucoup de mal à corriger leur patch en suivant les indications donnés, etc. Y a plein de raisons possibles.

Pourquoi leur demande-t-on de corriger leur patch? Certains (beaucoup même, j'ai l'impression) projets ont cette tendance à intégrer tout et n'importe quoi. Parfois ils corrigeront après coup, dans un nouveau commit, parfois même pas, alors que le patch de base a clairement des manques, ne suit pas le style du projet, etc. Je pense que l'envie d'avoir de nouveaux contributeurs pour certains mainteneurs surpasse l'envie d'avoir du code de haute qualité. Surtout pour les plus petits projets.
Dans GIMP, on a tendance à demander un haut niveau de qualité pour un patch. Déjà qualité du code même, mais aussi le respect de l'architecture du logiciel (on ne peut pas inclure des headers de n'importe quelle partie du code vers n'importe quel autre partie. Par exemple le core de GIMP n'a aucune notion de GUI, etc.), ou même le style de code. C'est la base: si je contribue sur un projet tiers, je regarde toujours quel est leur style (tabulations, espaces, accolades en début ou fin de ligne?…). On s'en fiche quel style j'aime personnellement quand je contribue. J'impose mon style seulement sur mes projets persos.
Alors bien sûr, c'est un choix et les 2 se défendent: vaut-il mieux tout intégrer et faire plaisir aux contributeurs (quitte à prendre beaucoup de temps après coup pour tout nettoyer derrière) ou demander un haut niveau d'entrée et risquer de perdre des contributeurs (en se faisant appeler "grincheux")? Ce que j'ai tendance à penser sur le sujet:

• beaucoup de petits patchs seraient bien plus vite et bien mieux écrits si on les faisaient nous-même que si on en fait la revue et le commentaire. Alors pourquoi le fait-on? Parce qu'avoir des contributeurs est important et qu'on "utilise" du temps maintenant mais pour potentiellement en gagner beaucoup plus tard si certains contributeurs décident de rester dans le coin, et pourquoi pas devenir des contributeurs majeurs. C'est donc un investissement de temps sur le long terme.
  Alors d'un certain point de vue, vaut-il mieux faire plaisir à un max de ces petits contributeur au cas où on a notre futur contributeur majeur dans le lot? D'un autre côté, si on ne l'a pas habitué à faire de la qualité dès le début, à quoi s'attend-t-on pour la suite? Veut-on vraiment de quelqu'un qui n'est pas capable de suivre un style donné, de revenir sur son code, d'écouter des critiques constructives, de lire et comprendre des revues de code et réorganiser le sien? Peut-être que cela est bien plus rentable sur le long terme. Après tout, comme je le disais, intégrer les petits patchs peut vraiment prendre un temps fou, donc autant que ce temps soit utilisé à bon escient pour le futur du programme. Parfois même, le patch en soi est moins important que la relation qui peut se construire avec le contributeur.

• on essaie d'avoir un code toujours stable sur master, même s'il est expérimental. Il ne faut pas intégrer un commit qui ne compile pas, ou va faire crasher le programme, ou autre mauvais "comportement". Intégrer un patch qu'on sait ne pas être parfait est donc une mauvaise idée. Évidemment on peut rétorquer que si on fait immédiatement un commit de correction derrière le patch du contributeur et on pushe les 2 en même temps, alors on a un changement atomique (quelqu'un qui fetche le dépôt aura les 2 commits d'un coup), mais cela reste non-idéal.
  Une autre possibilité peut être de corriger direct le commit du contributeur (--amend). On le fait souvent d'ailleurs, surtout quand les seuls changements sont des problèmes de style de code. Parfois aussi pour des changements plus importants, voire parfois on fait du gros élagage. Mais on laisse le nom du contributeur en tant qu'auteur du commit. Y a la question alors: jusqu'à quel niveau de changement peut-on toujours considérer ce contributeur comme auteur du commit? C'est pour ça que je rechigne à faire trop souvent cela personnellement, hormis pour des changements vraiment mineurs, et fait plutôt des commits juste après. Mais idéalement on préférerait que les contributeurs nous fassent un patch parfait qu'on n'aura pas à corriger. Et pour cela, ils doivent simplement suivre nos indications de revue de code.

Ensuite il y a les choix de design de l'application. On ne peut pas accepter tout et n'importe quoi. Et beaucoup de contributeurs semblent penser que changer un "petit" (d'après eux) truc n'a pas besoin d'être discuté. Déjà beaucoup de choses ne sont pas si "petites" même si un contributeur va essayer de vous en convaincre (or s'il est si attaché à voir ce patch intégré, c'est justement que le changement n'est pas si petit à ses yeux). Ensuite chaque fonctionnalité a son fan-club. Même si on se rend compte qu'une fonctionnalité est fondamentalement mauvaise, il y aura toujours quelqu'un pour l'apprécier. Et ça veut dire qu'une fois acceptée, elle sera très dure à retirer plus tard sans se prendre des plaintes et des menaces. En gros quoiqu'on fasse (garder, retirer, changer…), y a toujours quelqu'un pour ne pas être content et le faire savoir, souvent de façon virulente.

XKCD 1172 par Randall Munroe — CC BY-NC.

Ça signifie donc qu'il vaut bien mieux bien réfléchir sur chaque changement de fonctionnalité et chaque nouvel ajout, avant de l'accepter. Pas se dire "on pourra toujours revenir sur la décision plus tard". Car ce n'est pas similaire. Dans un cas, il ne se passe rien; dans l'autre on se prend des coups quoiqu'on fasse. Il est donc tout naturel de calmer les ardeurs et de réfléchir posément les nouvelles fonctionnalités, non seulement sur leur qualité intrinsèque, mais aussi sur le choix d'implémentation. Et donc oui, des fois, ça en revient à dire "non on va pas faire ça, on va faire ça à la place" (ce qui n'est pas un refus, mais une alternative ou différente implémentation — souvent pour des raisons qualitatives du code, donc maintenabilité — pour un comportement final similaire). Et oui, des fois, ça plaît pas forcément.

Mais ça veut pas forcément dire qu'on est grincheux. :P
Perso j'essaie d'être toujours le plus agréable et ouvert possible aux nouvelles idées. Mais ça veut pas dire que je dois laisser mon esprit critique au vestiaire et me passer de prendre des décisions finales quand il le faut. C'est pas facile tous les jours, d'ailleurs. Ensuite, soyons clair: globalement cela se passe bien et la plupart des contributeurs le prennent bien. Mais il arrive des couacs par moment.

En tous cas c'est assez marrant de voir que selon les personnes et leur niveau d'implication dans des projets, à quel point on a un niveau de lecture différent de la même phrase. ;-)

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

Pour info, l'opérateur --> veut dire "aller jusqu'à"

hmm… Je n'ai jamais vu cet opérateur. Bon ensuite je ne peux prétendre connaître les moindres subtilités du C. Par contre il serait en effet indistinguible de '--' suivi de '>' (puisque l'espace n'est pas obligatoire). Donc je doute vraiment qu'un tel op puisse exister.

Dans l'exemple donné, chaque test a simplement l'effet de bord de décrémenter la variable apres coup. Ça ne marche donc que pour un décompte. Un compte croissant devra utiliser '++ >'.

Ensuite je veux bien avoir tort et apprendre quelque chose aujourd'hui. Mais ça me paraîtrait vraiment étonnant que cet op existe. :p

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

J'appellerai pas ça un problème de mésententes, c'est surtout un problème classique de point de vue développeur vs packageur.

Bien sûr. Mais justement cela aurait pu être fait dans la joie et la bonne humeur. ;-)
Par exemple, puisque le packager Debian patchait Owncloud pour justement permettre de sauter des versions lors des mises à jour, peut-être ces patchs auraient-ils pu être repris upstream (et éventuellement corrigés/améliorés/nettoyés selon les standards du projet)? Le fait est que maintenant Nextcloud (et probablement Owncloud) souhaite avoir cette fonctionnalité de toutes façons, les forces auraient pu être jointes plutôt que les ponts rompus.

C'est là où il y a eu mésentente. Avec de simples discussions aimables, bien sûr cela ne résoud pas forcément le problème technique. Peut-être le travail en cours de Debian n'était pas acceptable d'un point qualitatif par Owncloud, mais c'est aussi exprimable de manière constructive sans braquer l'autre côté. Et peut-être que cela aurait abouti à de nouvelles propositions de patchs qui se seraient rapprochées d'un truc livrable. Ou pas. Mais dans tous les cas, ce serait une meilleure situation que maintenant.

C'est le principe d'une revue de code. Quand je lis un patch, j'essaie de passer mes commentaires pour demander au contributeur d'améliorer son patch de manière agréable. Ça marche pas toujours. Certains faisaient juste un lâchage de patch et reviennent de toutes façons jamais. Certains peuvent le prendre mal malgré tous les efforts diplomatiques que l'on puisse faire pour dire que ça n'est pas suffisamment dans nos standards de qualité. Mais bon, faut essayer quand même.
Et dans le cas d'un packager Debian, qui maintient plein de patchs et depuis longtemps, je pense qu'il aurait pu prendre mieux une proposition d'inclure son travail moyennant des changements. Mais pour cela, il aurait fallu discuter (en lisant les commentaires des 2 côtés, j'ai l'impression qu'Owncloud se focalise sur un commit et ne s'est pas rendu compte que c'était une partie d'un travail en cours pour une mise à jour en sautant des versions).

Ensuite je ne connais pas le détail et surtout le passif de discussion. Je ne saurais dire qui est le plus en faute dans l’interaction sociale (et franchement ça m'intéresse pas de savoir). Je constate juste le résultat et trouve cela un peu triste.

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

Oui tout à fait. Ceci dit, de nos jours, on trouve facilement (et pour quasi rien) des clés USB de 8GB ou plus (de la mémoire à 8GB aussi ceci dit, mais pas du tout au même tarif!) donc c'est tout de même une différence.

Mais bon, je chipote (ou j'extrapole, car on a pas les détails de toutes façons!). ;-)

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

Suite à de nombreuses incompréhensions entre les programmeurs d'Owncloud et le mainteneur du paquet Debian, ce dernier a choisi de supprimer tous les paquets Owncloud des dépôts Debian (Source)

Quand on suit un peu les liens, je comprends les problématiques techniques des 2 côtés: Debian veut pouvoir fournir un logiciel stable (sans faire de mise-à-jour majeure forcée si on veut juste profiter des corrections de bug) alors qu'Owncloud veut pousser les gens à mettre à jour le plus possible (et j'imagine qu'en tant que petite boîte, ils n'ont pas forcément les moyens humains pour maintenir trop longtemps de vieilles versions). Le problème était donc que les packagers Debian patchaient Owncloud pour créer leur propre système de mise à jour leur permettant de sauter des versions majeures (le but étant — j'imagine — de pouvoir mettre à jour Owncloud tous les X années, à chaque sortie de Debian, durée pendant laquelle il y aurait eu plusieurs versions majeures d'Owncloud, en ne proposant que les corrections de bugs dans l'intermède).

Perso, je comprends les deux raisons. Le problème semble réellement essentiellement humain, notamment le développeur Owncloud qui dit sur les mailing lists que le mainteneur Debian est un irresponsable. C'est sûr que ce n'est pas forcément très diplomatique. :-/

Il n'y a aucun paquet nextcloud dans Debian à l'heure actuelle […]
ça ressemble à une occasion manquée

Quand on lit ton lien, on se rend compte que les packagers Debian sont surtout vraiment pas chauds et considèrent la relation avec Nextcloud tout aussi problématique que celle avec Owncloud. En fait pire, le dév hostile fait justement partie des gens qui sont partis d'Owncloud vers Nextcloud! Donc en un sens, même si c'était sous le nom "Owncloud" (car à l'époque Nextcloud n'existait pas encore), on pourrait dire que c'est tout autant voire plus la relation avec Nextcloud qui fut rompue.

Ceci dit, le dernier message (à ce jour) de ce rapport de bug dit aussi que Nextcloud a annoncé la possibilité de mettre à jour en sautant des versions, ce qui est exactement ce qui posait problème à Debian et qu'ils espèrent que Debian aura un paquet. Ce n'est donc pas entièrement fermé, semblerait-il. Il faut juste voir comment se passera le côté relationnel car ça semble avoir vraiment été très mal vécu du côté Debian.

En tous cas, c'est toujours triste de lire ce type de mésententes. ;-(

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

La plupart des distrib Live n'ont pas de persistence. En d'autres termes, je pense même pas que ça installe sur la clé mais juste en mémoire. Ensuite je connais pas Mythbuntu ni comment ils ont construit leur clé live. Peut-être est-ce spécialisé pour la persistence des données et non juste pour le test de la distrib?
Si ce n'est pas le cas, c'est en effet très vraisemblablement la cause du problème.

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

Je veux bien que certaines options puissent améliorer la donne, mais rendre un filtre anti-spam inutile, sûrement pas! S'il suffisait juste de quelques options pour avoir une boîte email sans spam et surtout sans faux-positifs (c'est le plus important: on ne veut surtout pas rejeter un email valide, c'est bien pire que de laisser passer quelques spams), alors le spam sur internet ne serait pas un tel problème.

vérification du domaine de l'expéditeur

Ça veut dire quoi ça? Tu acceptes que certains domaines? Genre si t'es pas Gmail ou Yahoo, ça va pas, email refusé?

Ou alors tu veux vérifier si l'email est transmis avec un HELO qualifié avec un nom de domaine? Si c'est le cas, c'est une mauvaise méthode et tu peux te retrouver à bloquer des serveurs tout à fait OK. Tiens une petite recherche vite faite sur le web, qui donne des conseils avec lesquels je suis d'accord.

Ou bien tu parles du SPF? SPF part d'une bonne idée, mais là aussi je me suis rendu compte que dans la réalité, des mails peuvent se perdre. Voici une histoire vraie qui m'est arrivée:

• Quelqu'un de @redhat.com m'a envoyé un email sur mon adresse @gimp.org. Comme j'en ai marre d'avoir 100 adresses, je préfère les alias. Mon adresse @gimp.org est donc un alias sur mon adresse principale.
• Puisque c'est un alias, l'email est passé par les serveur de gnome.org (bien qu'il soit parti de redhat.com).
• Mon serveur a donc reçu un email disant provenir de redhat.com mais en apparence venant de gnome.org. Puisque RedHat a un enregistrement SPF strict et que j'avais configuré mon serveur pour obéir strictement aux règles SPF, ce dernier a rejeté cet email pourtant tout à fait valide (et même possiblement important). Je ne l'aurais jamais su si cette personne de RedHat ne m'avait pas ensuite contacté par une autre adresse pour me prévenir du problème. Et pourtant dans cette exemple tout le monde a fait parfaitement comme on lui demande: RedHat a un enregistrement strict, l'employé envoyait bien depuis les serveurs RedHat, mon serveur avait une politique stricte… SPF ne prend tout simplement pas la possibilité d'alias email en compte.

Depuis j'ai appris ma leçon et je ne configure plus mon serveur email pour appliquer une politique SPF stricte en attendant de trouver une alternative (mais j'ai pas l'impression que ça existe).
SPF a aussi des problèmes dans l'autre sens (envoi d'emails qui sont refusés), similaire aux alias, alors qu'on suit toutes les règles de bonne conduite, mais bon je vais pas détailler chaque cas possible qui peut mal tourner.

blocage des adresses dynamiques

Certains font de l'auto-hébergement et arrivent à associer des IPs dynamiques à un nom de domaine de manière transparente. C'est prise de tête, et je le ferais pas, perso, mais c'est quand même internet et je vais pas les refuser. Les personnes avec IPs dynamiques ne sont pas des sous-citoyens. Internet n'est pas que les gros serveurs des GAFAM.

vérification des listes noires

Les listes noires, ça bloque tout et n'importe quoi. Et pour se faire retirer de certaines, c'est la croix et la bannière. Pour le coup, ça bloque bien plus que des IPs dynamiques, mais aussi souvent des IPs fixes de fournisseurs d'accès (donc on considère qu'un particulier a pas le droit d'héberger un serveur?), et aussi des IPs d'hébergeurs sous prétexte que quelqu'un dans le bloc a loué une fois un serveur pour spammer.
En gros, là c'est Internet == GAFAM++.

Ensuite c'est une discussion qui revient souvent sur linuxfr et je ne vais pas revenir dessus. Je donne cependant mon avis: les listes noires, c'est mauvais.

greylisting

Je pense que c'est la seule bonne idée de la liste.

Forcément si tu configures Postfix pour refuser tout et n'importe quoi, t'as plus de problème de spam, mais en même temps tu limites ton réseau à une micro portion de l'internet. Mon internet à moi, il est quand même un peu plus grand et va au delà de Google et Co.

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

Photoshop: oui. Tout le monde connait photoshop, c'est même passé dans le langage courant: 'oh cette image a été photoshoppee.'

La semaine dernière, j'étais à un festival d'animation sur Paris ("Carrefour du Cinéma d'Animation" au Forum des Images), un endroit avec des pros (des gens qui se font payer pour dessiner ou faire de la 3D, des films, etc.) et des jeunes en école (dont le but est de devenir pro). Lors d'une table ronde, je remarque que la souris a laissé en surbrillance un programme sur l'écran de l'animateur principal: GIMP.

Pendant ce temps, à l'extérieur, les étudiants d'école de cinéma d'animation faisaient des démos (en fait ils préparaient un cadavre exquis animé à présenter pour la fermeture du festival). Au milieu des Maya/Photoshop/After Effects, je repère direct plusieurs Blender (Blender est aussi cochable dans les listes de compétences Pôle Emploi, et de plus en plus de studios l'utilisent).

Ensuite je ne vais pas t'affirmer que Photoshop n'a plus sa place de choix dans les milieux pro. Je pense que si cet animateur avait GIMP sur son ordi, ce n'était probablement pas pour animer, mais par contre ça signifie probablement que lorsqu'il veut modifier une image, GIMP lui convient parfaitement. Ceci dit, des gens comme nous animons avec GIMP — donc c'est pas impossible, note bien — mais parce que nous avons aussi nos outils internes en cours de développement (utilisés au quotidien, pas encore sorti, mais ce sera libre, et d'ailleurs sûrement livré dans GIMP même).

En restant dans le propriétaire, l'un des programmes phare cette année pour le film d'animation 2D est le (relativement) récent TVPaint. Pourquoi phare? Probablement déjà parce qu'il a été utilisé pour La Tortue Rouge dont le réalisateur était l'invité d'honneur cette année, premier film non réalisé par un japonais produit par les studios Ghibli, et qui a gagné plusieurs prix. Donc TVPaint a eu droit à sa conf d'1h30, etc. TVPaint fait un peu parler de lui ces dernières années, on pourrait croire que c'est parce qu'il est développé en France, mais Aryeom (la réalisatrice de "ZeMarmot") connaît des animateurs amis coréens qui ont aussi travaillé avec (en Corée donc). Ce programme a le vent en poupe depuis quelques années. Or — c'est là où je veux en venir — bien que propriétaire, il se trouve qu'il est aussi disponible pour GNU/Linux!
À un moment, quelques années auparavant, on avait presque hésité à l'essayer pour notre projet pour cette raison, mais le fait de travailler avec du propriétaire nous a finalement arrêté car l'un des buts de notre projet est aussi d'améliorer le logiciel libre.

Tiens Pixar eux-même régulièrement montre des démos avec un Desktop sous GNOME (donc Linux), par exemple à SIGGRAPH 2016 (le plus gros salon business de l'animation) lorsqu'ils ont libéré USD, ou encore cette vidéo (où on voit encore le même logiciel tourner sous Linux. Dans la vidéo, ils expliquent clairement qu'ils développent leurs propres outils dès le début, bien que ce documentaire en particulier est orienté vers la collaboration avec Autodesk, donc on voit aussi des ordis sous Windows dans certaines parties). C'est le "backend" qui fut libéré et non le logiciel d'animation que l'on voit à l'écran, lequel doit donc être leur outil interne… notons tout de même que cette GUI tourne sous Linux et donc que les animateurs peuvent produire leur film animé entièrement depuis un bureau Linux!

La conclusion est donc que non, Windows (ou OSX) ne sont absolument pas des obligations dans le monde pro du graphisme (ou de l'animation dans mes exemples. Forcément… je connais cet angle là plus particulièrement…). Je dirais même qu'il a déjà beaucoup perdu de sa superbe par rapport à des années auparavant. Photoshop est probablement ce qui s'utilise le plus encore — forcément il avait un quasi-monopole pendant si longtemps — mais justement par les gens qui ne connaissent pas grand chose (ou ne s'intéressent pas à la technique) et vont donc au plus connu. Mais tous ceux qui étudient vraiment les alternatives voire ont leur propres développeurs vont voir ailleurs. Et après tout, c'est ceux qui entraînent le marché et annoncent donc un futur potentiel pour le grand public également.

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