Accepter et entendre la critique dans le libre

Je n’aime pas qu’on me dise comment je dois utiliser un outil/logiciel/produit. Si il est bien conçu/pensé alors son utilisation, sa prise en main sera simple et naturelle. Elle aura du sens.

Il est nécessaire de fournir une documentation évidemment. C’est une bonne chose de présenter, argumenter, justifier les choix effectués (fonctionnement, technos, architecture, UI/UX…) : Pourquoi on a fait ça, comment on l’a fait. Pourtant il y a une chose cruciale à ne pas oublier : Une grosse partie des utilisateurs ne lira pas la doc, se fout complètement de vos problématiques et justifications. Ils veulent un truc qui tombe sous le sens, qui soit pratique/utile pour eux, qui fonctionne de manière simple. Si l’utilisateur pense avoir affaire à un outil/logiciel/produit mal conçu, vos arguments et justifications n’en feront pas quelque chose de bien conçu. L’utilisateur adaptera peut-être son comportement, sera moins critique, plus compréhensif car il aura compris le pourquoi/comment mais cet outil/logiciel/produit demeurera mal foutu dans son esprit.

Je vois régulièrement ça dans le logiciel libre : « Bon c’est mal foutu mais voilà l’explication »… mais ça reste mal foutu ! C’est comme si on avait intégré/accepté l’idée que le logiciel libre est imparfait, mal fini. C’est une véritable culture. De là découle le très fameux « c’est un logiciel libre, contribue ». Non ! Il faut accepter, entendre la critique. C’est bien plus constructif que tenter une justification.

Il faut de l’empathie pour comprendre, c’est-à-dire se mettre à la place de l’autre (ici l’utilisateur). L’utilisateur dit « c’est mal foutu », on lui explique que non et pourquoi puis on lui rappelle/rétorque « tu peux l’améliorer, tu peux contribuer ». Il est intéressant de souligner que souvent on lui explique qu’il a tort en justifiant un choix technique par exemple alors que l’utilisateur donne seulement/simplement son ressenti.

J’aime bien la blague (certains appellent ça un argument) de la possibilité de contribuer. Quiconque a déjà contribué sait que c’est loooooooiiiiiiiinnnn d’être simple. En vrac complet : 1/ La doc est en Anglais, on communique en Anglais, on remonte les issues en Anglais 2/ Prenons GitHub. Il faut connaître (de « simples » utilisateurs ne connaissent pas), il faut avoir un compte, il faut savoir créer/remonter une issue ou un bug 3/ Il faut savoir. Combien d’utilisateurs sont à des années-lumière de pouvoir juste expliquer de manière compréhensible le problème rencontré ? 4/ La contribution simple, systématique, rapide, on n’est pas loin du mythe. Une pull-request peut rester des semaines/mois sans être pushée dans le projet, évidemment elle peut être rejetée. Ce n’est pas parce que le logiciel est libre que les contributions sont systématiquement acceptées et que l’accueil est chaleureux (il est souvent inexistant). Pour la simplicité, voir les points précédents

Oui il est possible de contribuer en théorie, dans la pratique c’est nettement plus compliqué. L’utilisateur signale juste un problème, il n’est pas dans une démarche/réflexion pour contribuer et même si il l’était, le chemin restant avant qu’il le fasse est long et difficile.

Une majorité d’utilisateurs est dans une position de consommateurs. L’utilisateur n’est pas satisfait, il le dit. Le sympathisant du libre, le contributeur doit se mettre à son niveau, comprendre son besoin. Il doit lui tendre la main sinon l’utilisateur restera déçu, impuissant et incapable d’utiliser l’outil/logiciel/produit pour finir par aller voir ailleurs.

Certains penseront que ce n’est pas une grosse perte. Je cite une devise Framasoft : « Parce que ce serait l’une des plus grandes opportunités manquées de notre époque si le logiciel libre ne libérait rien d’autre que du code ».