Pour rappel, PeerTube est une application web, s'installe sur un serveur et tourne via NodeJS. Voir le sommaire pour plus d'informations.

On ne va pas se le cacher : il y a toujours un moment où on regrette l'époque où on travaillait tranquillement sur son projet, en faisant sa tambouille dans son coin. Une fois que le projet grandit et qu'il devient connu, on doit faire face aux critiques, aux jugements, aux phrases du type "je ne comprends pas pourquoi telle ou telle fonctionnalité n'est pas encore implémenté" etc. Toute la difficulté réside dans le fait de trouver un juste au milieu entre se remettre en question et garder le cap qu'on s'est fixé.

C'est un pic ? Non c'est un cap

Il est très important de se fixer un objectif à long terme, afin d'avoir de la cohérence dans les choix qu'on fait en développant un logiciel. Par exemple avec PeerTube, Framasoft crée chaque année une feuille de route sur laquelle on communique et qui nous donne une vision du type de plateforme qu'on espère avoir au mois de décembre.

Cette feuille de route aide les utilisateurs à comprendre la portée du logiciel, et permet aux développeurs de ne pas s'éloigner du chemin fixé. Il me paraît important de créer une application qui fait au début une seule chose, mais qui essaye de la faire correctement.

Par exemple avec PeerTube, parce qu'on utilise le P2P pour soulager la bande passante du serveur on se retrouve quelques fois avec des demandes s'apparentant à un logiciel pour seedbox. Or, nous faisons un logiciel de streaming vidéo. Que PeerTube continue de seeder un torrent après import n'est pas notre objectif. D'avoir un player qui tienne la route si.

Il arrive quelques fois qu'un contributeur crée une fonctionnalité via une PR/MR dont on peut avoir du mal à voir l'intérêt. Il faut pouvoir accepter ce genre de contribution, car nous ne sommes pas les seuls utilisateurs du logiciel : ce qu'on juge peu pertinent, peut l'être pour une majorité des utilisateurs. Néanmoins une PR/MR est un don de code, vous héritez donc de sa maintenance (correction de bugs futurs, amélioration de l'UX, documentation etc). Nous sommes alors en droit de refuser un code que nous jugeons peu acceptable (mal codé, alambiqué, fonctionnalité trop spécifique qui alourdit l'interface etc).

Il est compliqué de savoir où tracer la limite entre accepter n'importe quel code, et être un développeur autoritaire qui refuse toute contribution externe. Encore une fois, la feuille de route peut aider à ajuster cette limite.

L'art d'accepter les critiques

Un cap n'est cependant pas une roadmap. Il faut accepter la critique, et pouvoir la réadapter selon les discussions. On fait souvent un logiciel libre pour les utilisateurs. Si beaucoup jugent une nouvelle fonctionnalité importante, il est peut-être pertinent de réadapter un petit peu la feuille de route fixée. Il est cependant anormal de la changer trop souvent. Si c'est le cas, peut-être que le cap n'était pas le bon. Ou peut-être qu'il y a un soucis de compréhension avec les utilisateurs, et dans ce cas c'est un problème de communication.

Avec PeerTube, beaucoup de personnes s'attendent à ce qu'on fasse comme Youtube et qu'on se dote d'un système de monétisation. Toute la difficulté réside dans le fait d'expliquer que nous n'implémenterons pas ce genre de fonctionnalité, et surtout faire comprendre pourquoi.

Garder son sang froid

Sur Internet, les critiques peuvent être acerbes. Souvent, par des personnes mal informées qui n'auront pas regardé le projet de près. Certaines remarques seront des plaintes, d'autres carrément des insultes. Il est important de garder son sang-froid en toute circonstance. Souvent, il vaut mieux passer outre (la bave du crapaud etc). Mais il peut être important de mettre le holà à certaines critiques répétées (la FAQ du projet est utile dans ces cas là).

Au delà des critiques, certaines personnes vous expliqueront qu'une fonctionnalité précise de votre logiciel est primordiale, et que vous devez travailler dessus "ASAP". D'autres trouveront carrément que vous être un crétin irresponsable de ne pas l'avoir déjà implémentée. Là encore, il faut garder son sang froid et expliquer en étant ferme que vous fournissez gratuitement un logiciel libre, et que les utilisateurs de votre projet ne sont pas vos clients.

Ne pas se faire déborder par les attentes

Ces nombreuses attentes, commentaires et demandes quelques fois pressantes rajoutent une charge mentale bien souvent pénible, qui peut disperser. C'est pour cette raison que le cap est important. Pour ma part, ça me permet de voir où on en est, où on veut aller, et quel chemin on a parcouru.

Il reste important de consulter et trier les issues, mais il faut peut-être s'organiser afin de ne pas les regarder trop souvent. Lorsqu'on fait un logiciel communautaire (sans contrat support), rien n'est vraiment "urgent". Il ne faut pas céder à l'impatience de certains : il suffit de prendre un peu de recul, ne pas hésiter à mettre le nez dehors pour se rendre compte que si le player vidéo ne fonctionne pas sur tel ou tel navigateur à cause d'un bug, ben c'est pas grave. On prendra le temps de le corriger.

Aller voir ce qui se dit concernant le logiciel sur les réseaux sociaux peut-être enrichissant, mais aussi frustrant.. Ne pas hésiter à ignorer ces plateformes pour se protéger, même s'il faut avouer qu'on trouve aussi des commentaires pertinents (remontées de bugs ou améliorations) de personnes qui n'iraient pas forcément sur votre gestionnaire de tickets ou forum.