Au cours des dernières années, j’ai vu ici et là les étincelles d’une discussion éternelle. C’est une question nuancée, mais si je peux résumer, il s’agit de différentes stratégies de développement de fonctionnalités que nous pouvons suivre pour concevoir des éléments, surtout s’ils sont destinés à un marché plus large. Plus précisément, lors de l’ajout d’une fonctionnalité, dans quelle mesure doit-elle être complète et parfaite ?
Il y a quelque temps, j’ai lu un fil de discussion Mastodon sur le fait que VLC n’implémentait pas le saut d’image en arrière. En surface, il s’agit d’un utilisateur indigné qui demande : quel est le problème avec VLC qui n’a pas de bouton « revenir en arrière » ? Une tonne de lecteurs vidéo ont implémenté cette fonctionnalité. Il y a un fil de discussion lié et sa lecture pourrait vous laisser quelques émotions contradictoires. Voici un récapitulatif.
Dans ce qui semble être l’un des nombreux fils de discussion portant sur un bouton « image précédente » dans VLC, il y a une discussion de 82 messages impliquant plusieurs développeurs VLC différents. L’argument des utilisateurs est qu’il semble clairement techniquement possible d’ajouter un bouton « image précédente » dans la pratique, et l’argument des développeurs est que c’est technologiquement complexe à mettre en œuvre dans certains cas – pour certains formats, même impossible à mettre en œuvre ! Examinons alors le raisonnement avancé par les développeurs plus en détail – voici ce que vous pouvez trouver dans le fil de discussion, au mieux de mes capacités.
Le désordre des formats vidéo et des émotions humaines
La compression vidéo peut devenir complexe – vous ne seriez pas surpris d’apprendre que, dans la grande majorité des formats vidéo, les algorithmes de compression stockent généralement les modifications entre les images, avec des images complètes occasionnelles stockées afin que la recherche ne soit pas trop coûteuse. Cela dit, cela peut devenir encore plus complexe que cela, certains formats étant particulièrement peu conviviaux en raison du flou entre ce qui constitue même un cadre séparé. Encore une fois, nous avons des exemples concrets, mais cela crée une interface non unifiée pour les utilisateurs. Je n’ai pas trouvé d’argument avancé par les développeurs de VLC concernant la suggestion d’activer la recherche d’images précédentes pour certains formats et pas pour d’autres, avec des modifications de l’interface utilisateur correspondantes, mais j’ai trouvé une approche différente.
L’essentiel est que les développeurs de VLC ne voient pas de moyen propre d’implémenter la recherche telle quelle. Quoi que fassent les autres lecteurs vidéo, cela doit être étudié, et cela pourrait alors s’avérer être un code désordonné dont les principes ne seront même pas transférés dans VLC sans créer une charge de maintenance. Les développeurs ont la meilleure idée de la base de code, telle qu’elle est, et si elles le sont. Bien sûr, certains utilisateurs ne l’ont pas pris à la légère, et avec des messages extrêmement raisonnables, le fil de discussion a connu une réaction considérable par rapport à ce qui semble être une fonctionnalité évidente qui aurait dû être ajoutée il y a des années.
Bien sûr, il est insensé de conclure que si certaines personnes dépassent les limites, leur argument principal est invalide. D’un autre côté, cela ne crée pas une atmosphère agréable, et la réalité de la condition humaine fera que les aspects négatifs de cette discussion feront de tout travail sur une telle fonctionnalité une expérience de plus en plus désagréable pour les développeurs VLC. S’ils le mettent en œuvre maintenant sous une forme ou une autre, attendez-vous à ce que ce soit un refrain de « je vous l’avais dit », ce qui n’est presque jamais une motivation positive.
Mais l’atmosphère entière de la discussion est désormais trouble, au point que les questions se retrouvent dans une impasse commune : que peut-on vraiment demander à un développeur open source ? D’une part, demander des fonctionnalités est à peu près le seul moyen pour un utilisateur de signaler un de ses besoins – mais lorsque ce besoin a été clairement signalé comme difficile à satisfaire, les questions des utilisateurs peuvent rapidement devenir ennuyeuses et leur gestion devient un travail supplémentaire. le genre dont tous ne sont pas équipés. Ceux d’entre nous qui ont fabriqué des produits ont certainement ressenti la douleur de répondre à une multitude de questions identiques. Certains développeurs préparent des modèles de réponses par e-mail et les envoient sans relâche, et certains s’opposent à l’idée même que ce fardeau relève de leur responsabilité. Lorsque le message implicite des utilisateurs est « vous vous trompez sur votre domaine d’expertise et vous le niez », il peut devenir assez difficile de s’engager de manière calme, et cela va expliquer comment un certain nombre de développeurs de VLC répondent dans le message implicite des utilisateurs. les fils sont assez durs.
VLC est un lecteur merveilleux qui revendique à juste titre un trône dans le royaume des logiciels open source, et je compte personnellement sur lui dans ma vie de tous les jours. Vous ne pouvez pas nier que les développeurs de VLC font quelque chose de bien, ou plutôt, ils font un grand nombre de choses de bien – il est difficile d’écrire un gros logiciel sophistiqué sans une vision cohérente de la façon dont ce logiciel pourrait fonctionner, et de VLC. a prospéré dans le monde open source depuis des décennies maintenant. Il existe de solides arguments en faveur de la confiance dans le jugement des développeurs sur ce point.
Et il pourrait également y avoir de solides arguments pour ne pas faire confiance aux développeurs.
La perfection n’est pas une vertu
Maintenant, le fil Mastodon que j’ai lié aborde le problème sous un angle différent. Cela touche au cœur même de l’argumentation des développeurs et affirme clairement que quelque chose ne va pas fondamentalement dans la façon dont ce problème est abordé au sein du cercle des développeurs de VLC. Il est difficile de nier que, sur d’autres lecteurs, le bouton de saut précédent ne fonctionne que lorsque les utilisateurs s’attendent à ce qu’il fonctionne. Bien sûr, cela ne peut pas fonctionner pour certains formats car la compression est farfelue, on ne s’attend peut-être pas à ce que cela fonctionne pour les flux réseau, mais du point de vue des utilisateurs, c’est une tâche résolue dans ce qui semble être tous les lecteurs sauf VLC. Ainsi, compte tenu de tous les points que nous venons de parcourir, le fil de discussion Mastodon soutient que les développeurs de VLC se trompent sur leur domaine d’expertise. C’est une affirmation forte – comment est-elle formulée ?
L’un des principaux arguments des développeurs est que la fonctionnalité ne peut pas fonctionner parfaitement dans tous les cas. Le problème est que personne ne demandait la perfection. Si les réponses des développeurs se concentrent sur la façon dont une fonctionnalité ne peut pas être implémentée parfaitement mais que les utilisateurs en question ne demandent pas une implémentation parfaite, peut-être que les développeurs abordent cette fonctionnalité sous un angle fondamentalement erroné.
Cela remet en question l’affirmation selon laquelle une mise en œuvre serait complexe : est-elle vraiment aussi complexe que vous le prétendez, ou vous êtes-vous retrouvé dans une impasse en luttant pour une norme impossible ? Les cas de développeurs coincés dans un coin ne sont pas rares, et en lisant le fil de discussion, il n’est vraiment pas clair que ce ne soit pas le cas. Cela conduit les développeurs à communiquer avec force sur un mode de défaillance assez courant, tout en niant avec ferveur que cela puisse être une option.
La déconnexion de la communication n’est pas facilitée par des messages fondamentalement contradictoires. A travers les messages des développeurs, si vous voulez les prendre le plus au sérieux possible, vous pouvez reconstituer ces points sérieux : « nous ne savons vraiment pas comment implémenter cela dans nos standards, nous ne voulons pas fournir aux utilisateurs un mauvaise expérience utilisateur, mais nous sommes ouverts aux pull request ». Cependant, ces points sont entourés de réponses des développeurs telles que « ce n’est généralement pas possible », ou « si c’est si simple, pourquoi ne le faites-vous pas », ou une variante de « cela ne peut pas être fait parfaitement. [but it can be done for some cases]».
De toute évidence, les développeurs open source ne sont pas censés résoudre toutes les demandes de fonctionnalités qui apparaissent, mais c’est le problème, vous êtes censé être en mesure de contribuer à l’open source, et il n’est pas vraiment clair si quelqu’un peut contribuer à résoudre ce problème. Il y a ici deux positions incompatibles : la première est « désolé, nous ne savons pas, aidez-nous si vous le pouvez » et la deuxième est « nous attendons la perfection et savons que c’est impossible ». Cette incompatibilité n’est pas explicite, mais elle est tissée tout au long du fil de discussion lorsque vous lisez entre les lignes, ce qui rend très difficile de déterminer si le travail de quelqu’un serait apprécié au cas où quelqu’un implémenterait la fonctionnalité et ferait une pull request.
Votre pull request aura-t-elle un biais positif en tant que solution à un problème que les développeurs ont du mal à résoudre pour leurs utilisateurs, comme c’est la coutume dans le monde de l’open source, ou sera-t-elle dénigrée en tant que solution à un problème qui ne peut pas être résolu ? parfaitement résolu de toute façon ? Je suppose que vous ne pouvez pas le savoir tant que vous n’avez pas travaillé des heures. Lorsqu’une telle incertitude plane sur vous tout au long de votre recherche d’un moyen de procéder à une mise en œuvre propre, il sera difficile d’oublier que vous pourriez faire littéralement quelque chose de plus prometteur avec votre temps. Et, étant donné le biais de négativité, l’expérience de certaines personnes avec VLC sera-t-elle ternie par la lecture de ce fil de discussion alors qu’elles recherchent une solution à un problème qui est à portée de main chez tous les autres lecteurs ?
Combler le fossé
Les utilisateurs et les développeurs de VLC se parlent, tout en s’envoyant des messages implicites avec un noyau fondamentalement dédaigneux. C’est un problème de communauté open source, mais les pull request et les forks ne sont pas les bons outils ici. De plus, le problème technique est résolu – l’un des derniers messages du fil de discussion nous indique qu’il existe un plugin qui résout ce problème, en ajoutant un bouton ‘image précédente’. Cela peut nécessiter une séquence d’actions capricieuses pour fonctionner ou installer, mais c’est une solution meilleure que de passer à un autre lecteur, quelque chose que vous verrez de nombreuses personnes déclarer dans le fil de discussion avec frustration.
Lorsque vous enfilez les gants de l’utilisateur, qu’avez-vous à dire à un développeur qui essaie de choisir entre une fonctionnalité imparfaitement implémentée et ne pas l’implémenter du tout ? Avec lequel préféreriez-vous travailler ? Et lorsque vous êtes assis à la place d’un développeur, que ressentez-vous à l’idée de travailler sur une fonctionnalité imparfaite qui pourrait se transformer en un fardeau de maintenance, surtout si vous n’arrivez pas à vous sentir à l’aise avec sa mise en œuvre ?
