[fr] Cinq ans de projets libres : bilan et retour d'expérience sur la contribution

Voilà 5 ans que je produis du logiciel libre. J'ai pris l'habitude de publier chaque année mon retour d'expérience sur ce sujet. J'ai parlé de mes premiers pas, de mes doutes, de ce que j'ai appris sur le code, des présentations publiques, de la communauté et enfin de l'impact du logiciel libre sur l'entreprise. C'est déjà un bon tour de la question. Alors qu'est ce qui ferait un bon sujet pour cette année ? Et bien je vais simplement vous parler de la contribution. C'est l'essence du projet libre, je ne pouvais passer à côté. À travers cet article, je vais donc vous raconter ce que j'ai ressenti en étant des deux côtés de la barrière. Mais, avant de rentrer plus dans les détails, je vous donne le contexte avec un résumé de mes aventures de l'année passée !

Ce que j'ai fait cette année

J'ai encore beaucoup codé et principalement en Coffeescript pour le navigateur et le serveur (Node.js). Je voulais développer mieux et essayer d'autres langages mais je n'y suis pas arrivé. J'ai beaucoup travaillé dans l'urgence et n'ai pas testé de nouveaux outils.

J'ai surtout focalisé mes efforts sur Cozy. En effet, le projet a pris de l'ampleur. La communauté s'est beaucoup développée. J'ai aussi plus de collègues. Autre fait notable, maintenant je travaille non seulement avec des gens très compétents mais aussi avec des personnalités du milieu ! Parmi eux nous trouvons Tristan Nitot qui a notamment fondé Mozilla Europe, et Bruno Michel qui, entre autres choses, a refait et maintient LinuxFr.org. J'ai donc évolué dans un environnement très stimulant et instructif.

Mais surtout cette année, chez Cozy, nous avons eu à gérer beaucoup de contributions tant internes (des collègues) qu'externes. D'un côté l'équipe Cozy s'est affirmée et a grandi. De l'autre, de nombreuses personnes sont venues contribuer. L'impact n'est donc pas négligeable… Car faire les bonnes choses pour que les gens travaillent bien en équipe est difficile. Mais bien intégrer des contributions diverses et aléatoires l'est encore plus (heureusement que je n'étais pas seul pour y faire face). Malgré ça j'ai quand même pu contribuer à droite et à gauche. Dans la suite, je vais donc vous faire part de comment j'ai vécu l'expérience en tant que contributeur et intégrateur de contributions.

Contribuer

Faire un rapport de bug

C'est l'action de transmettre la description d'un bug que l'on a rencontré aux auteurs du logiciel. C'est un acte qui parait anodin mais qui requiert d'être bien fait pour être productif. En effet, si le message rédigé n'est pas compréhensible, il n'est pas traitable. Rédiger un rapport de bug demande de la rigueur sur la rédaction. Cela demande aussi de bien décrire le contexte dans lequel le bug se produit.
J'en ai peu rédigé mais j'étais, à chaque fois, content de le faire. Par contre, j'ai parfois été un peu déçu par les réponses reçues. En effet, les réactions des développeurs sont diverses : dans certains cas, les demandes sont ignorées ou fermées un peu brutalement (les développeurs ont vite fait de mettre ça sur le dos d'une dépendance). Heureusement elles peuvent être bien reçues et traitées. On est alors remercié, ce qui est plutôt sympa.

Exemple : Voici un rapport de bug que j'ai rédigé. L'interaction est intéressante. On me demande de rédiger un test en échec lié à mon bug. Un autre contributeur vient corriger le bug ensuite.

Corriger une documentation

C'est l'action d'ajouter un élément manquant ou de corriger une faute d'orthographe dans une documentation. Encore une fois, cela demande de bien rédiger mais au final cela ne prend pas trop de temps. Ce genre de corrections est toujours bien apprécié et accepté. C'est vraiment un bon moyen de commencer à contribuer à un projet.

Exemple : Là je corrige une documentation. Cela intervient après une discussion pour en savoir plus sur l'état du projet. Le mainteneur intègre vite la modification et me remercie.

Faire une correction de bug

Corriger un bug ne requiert pas de comprendre toute l'architecture de l'application. Ce qui est consommateur de temps c'est de s'assurer que les tests automatiques du projet fonctionnent toujours et d'en ajouter s'il en manque. Enfin, il faut bien commenter sa modification. Généralement cela se passe bien.
Attention, assurez-vous aussi que personne ne travaille déjà sur ce bug avant. Pour cela vous pouvez en discuter sur le ticket concerné.

Je n'ai malheureusement pas retrouvé d'exemple à ce sujet.

Ajouter une fonctionnalité

Je ne me suis lancé là-dedans qu'une fois et, malheureusement, l'expérience fut assez mauvaise. Ayant beaucoup utilisé le framework Express JS pour Node.js, je me suis dit qu'il serait intéressant d'y contribuer. J'ai donc choisi une demande d'amélioration simple de leur côté. Cela m'a demandé beaucoup de boulot. J'ai d'abord dû bien comprendre la demande et me documenter sur la fonctionnalité demandée (permettre au framework d'alimenter un traceur à des fins de debug).
J'ai posé de nombreuses questions pour être sûr que je n'étais pas à côté de la plaque. Ensuite j'ai dû comprendre une partie du code du framework. Enfin j'ai pu développer la fonctionnalité demandée. Au début j'ai eu du feedback intéressant du mainteneur principal sur ce que j'avais réalisé. Mais ensuite d'autres contributeurs sont venus donner leur avis. Pertinents mais un peu perfectionnistes à mon goût. J'ai quand même joué le jeu et ai subi plusieurs allers et retours. Finalement mon code n'a jamais été fusionné.
Conclusion, ajouter une fonctionnalité importante n'est pas toujours bien reçu. Il ne faut pas s'attendre forcément à un retour positif.

Exemple : Pour le projet Express, mon ajout aboutira à une discussion de 49 commentaires sans fusion au final. À l'inverse voici une modification bien reçue par l'auteur de Kresus, une application de gestion bancaire. Cette fois l'auteur est très content !

Faire une présentation sur une techno pas à soi.

J'ai fait deux présentations concernant la base de données dans le navigateur PouchDB. Les auteurs étaient très contents. Je me suis senti utile : c'était motivant pour eux et ça faisait découvrir une belle techno à plein de gens.

Exemple : Voilà la vidéo de ma présentation aux Human talks sur PouchDB. Les auteurs ont aussi manifesté leur joie sur les réseaux sociaux suite à ma contribution sur cette présentation faite à DotJS.

Faire un don

Des fois le moyen le plus simple d'aider est de faire un don. Cela peut permettre à un groupe ou organisation d'améliorer ses conditions de travail ou les services qu'il propose. Ainsi j'ai aidé l'April et le projet Salut à Toi. J'ai encore vu des gens contents !

Bénévolat

J'ai fait un peu de bénévolat au FOSDEM. Cela consistait à réaliser des actions simples comme m'occuper du vestiaire. C'est une contribution qui a permis de rendre l'événement un peu mieux. En plus, c'est à la portée de tout le monde. Pareil que pour le talk, le niveau de satisfaction était élevé ! C'est le genre de contributions auxquelles on ne pense pas toujours mais bien utile. Les gens de l'événement m'ont chaleureusement remercié et j'ai gagné du karma et un tee-shirt FOSDEM Volunteer.

C'est fini pour la partie contributeur. Passons maintenant à la partie recevoir une contribution. Mais avant ça, je voulais décerner une mention spéciale au projet PouchDB. L'accueil des auteurs et leur rigueur m'ont bien motivé !

Recevoir une contribution

Recevoir une traduction

La traduction est une belle contribution car elle permet à des gens non techniques de participer. C'est très stimulant d'en recevoir une. Bien la gérer par contre n'est pas évident. Car lorsque les messages de l'application bougent, les traductions sont perdues. De plus les gens non techniques ne sont pas familiers des outils de gestion de version. Il faut donc souvent se tourner vers des outils en ligne dédiés à la traduction collaborative.

Ce que je fais : je remercie la personne et la renvoie vers Transifex, la plateforme que nous utilisons chez Cozy. Utiliser un outil dédié est beaucoup plus pratique que demander aux gens d'utiliser Git et Github.

Recevoir un rapport de bug

Une autre contribution à la portée de tous… Enfin de ceux familiers avec les outils de gestion de tickets ! C'est très satisfaisant d'en recevoir une car elle vous démontre que d'autres personnes se servent ou veulent se servir de votre application. Toutefois le rapport de bug se doit d'être bien rédigé pour ne pas faire perdre trop de temps en aller et retours. Recevoir beaucoup de rapports de bugs peut s'avérer oppressant.

Ce que je fais : je remercie la personne. Ensuite, je demande des détails si nécessaire. Lorsque le travail est terminé et livré, je vérifie avec la personne que le bug est bien résolu. Si c'est ok ou si je n'ai pas de nouvelles dans les semaines qui suivent je ferme le bug.

Exemple: Un rapport de bug simple et bien traité (remerciements et confirmation inclus).

Recevoir une demande d'amélioration, un feedback

De même que précédemment, c'est très satisfaisant et requiert au contributeur de maitriser un outil de gestion de tickets. Toutefois ces demandes sont généralement difficiles à prendre en compte. La liste des bugs et des idées est souvent déjà suffisante. Là où ça devient très parlant, c'est quand la demande se répète, on comprend donc qu'il faut faire quelque chose.

Ce que je fais : je remercie la personne et laisse le ticket ouvert jusqu'à implémentation de la fonctionnalité.
Plus récemment j'ai demandé aux contributeurs de plussoyer une demande si elle leur plait. C'est un bon moyen d'évaluer la popularité de celle-ci.

Exemple : Voilà une simple demande d'amélioration que j'ai traitée pour la lib request-json. Par contre des fois la demande est automatiquement fermée par Github suite à l'intégration du correctif, ce qui n'est pas très sympa pour le contributeur.

Recevoir une correction de bug

C'est une très bonne contribution à recevoir. Par contre, si le correctif n'est pas parfait, c'est délicat de demander d'améliorer des modifications (ajout de commentaires ou de tests par exemple). Heureusement, les contributeurs sont assez contents de bien faire le travail, donc on peut être exigeant. Une fois intégré, c'est une petite victoire. Le bug a été corrigé sans votre intervention et la communauté du logiciel se renforce !

Ce que je fais : Suite aux remerciements, je fais une revue du correctif et fusionne les changements si tout est ok. Je rajoute le nom du contributeur à la liste des contributeurs (quand j'y pense).

Exemple : Ici je remercie le contributeur et intègre ses changements. Il apparait ensuite dans liste des contributeurs.
Certains associent systématiquement une modification à un ticket. Même si je ne le fais pas, il faut bien admettre que c'est une bonne pratique.

Recevoir une correction de documentation

Très agréable aussi, ces corrections se valident très rapidement et rendent le projet plus crédible.

Ce que je fais : Je vérifie, je remercie, j'intègre des modifications et rajoute à la liste des contributeurs.

Exemple : Ici j'intègre des corrections d'anglais sur la doc de Cozy. Je montre ma joie et j'intègre.

Recevoir une fonctionnalité

Cette contribution est plus délicate. En effet d'un côté c'est très plaisant de la recevoir. De l'autre l'implémentation n'est pas toujours satisfaisante. En effet, pour le contributeur c'est difficile de coder dans le style du ou des mainteneurs principaux et de bien faire l'implémentation. Par contre si c'est bien fait, ce n'est que du bonheur !

Ce que je fais : Ma réaction est très variable. Ça n'arrive pas si souvent et c'est vraiment du cas par cas. Si j'ai une recommandation, c'est de bien expliquer dans un ticket avant de coder ce que vous comptez faire.
Pour les contributions mal fichues, je demande au contributeur de corriger. Pour les détails, je les prends à ma charge pour ne pas le décourager. Intégrer ce genre de modifications prend du temps dans tous les cas.

Exemple : Voici un ajout de fonctionnalité qui a demandé du boulot aux deux parties. Le code ne nous convenait pas tant dans l'architecture que dans le style. Nous avons fait la revue de code pour apprendre le style attendu. Ensuite nous avons aidé le contributeur à revoir son architecture pour qu'elle nous satisfasse.

Recevoir beaucoup de code

Cela n'arrive pas souvent mais quand c'est le cas, il n'y a pas à dire, on est très content ! Malheureusement, parfois ça devient difficile. Car intégrer toutes les modifications impose un certain rythme qui n'est pas facile à tenir.

Ce que je fais : ce n'est arrivé qu'une fois et j'ai fini par refuser les modifications qui m'étaient envoyées. Au début je faisais de mon mieux pour tout intégrer et faire en sorte que ça respecte la philosophie du projet. Mais je n'ai pas pu tenir le rythme. J'ai fini par fermer une demande de modifications. Le code n'était pas commenté, les commits étaient peu clairs et je n'avais plus le temps de remettre le tout au propre. Le contributeur s'est vexé et a arrêté de faire des modifications.

Exemple : Ce cas m'est arrivé pour le projet expérimental Cozy Light. Après de nombreux échanges, j'ai refusé cette modification. Je dois avouer que je ne savais pas du tout comment gérer la situation. Et l'effet s'est bien ressenti. Après ça le contributeur s'est vexé et a arrêté de contribuer.

Voir une app se développer sur la plateforme

Celle-ci est le genre de contribution qui n'existe pas pour tous les projets. Au mieux, les projets proposent au contributeur de faire des greffons. Mais le projet Cozy permet de réaliser des applications complètes. Pour les plateformes, c'est un peu la contribution ultime. En effet on voit un autre projet se développer au dessus d'un autre. Ensuite, le nouveau projet se constitue à son tour sa propre communauté !

Exemple : L'application Kresus est partie d'un fork d'une app existante. Un an après, voici le sujet Kresus sur le forum de Cozy. L'auteur y annonce ses nouveautés. Le sujet engendre une discussion de près de 200 messages. Tout le monde est content !

Voir un contributeur en aider un autre

Là on voit la communauté du projet qu'on a initié devenir autonome. C'est un peu l'extase pour le mainteneur !

Exemple : Là un contributeur se pose une question sur le processus d'installation. Un autre vient lui fournir une explication.

Recevoir des encouragements

Cela arrive par courriel, via le forum ou via IRC. Encore une fois c'est génial de recevoir ce type de message. Ça coûte pas grand chose, donc ne vous retenez pas si vous aimez bien un projet ! J'en ai encore reçu un hier. C'est très encourageant.

Conclusion

Et voilà, le bilan se termine ici. La contribution est le moment le plus exaltant du projet libre. Les esprits se connectent pour réaliser un travail collaboratif. La magie se crée. Quand j'ai commencé à écrire du code libre, ce qui m'attirait le plus était de faire les choses enfin proprement et à ma manière. Aujourd'hui, ce qui me motive le plus c'est de voir le projet vivre sa vie et d'observer les interactions des contributeurs.

L'acte de contribuer permet de faire avancer significativement les projets que vous aimez. Les mainteneurs gagnent du temps, sont aiguillés dans la bonne direction et sont plus motivés. C'est aussi l'occasion pour vous de progresser techniquement et sur le plan rédactionnel. Bref, c'est une bonne source de points de karma à portée de main. N'hésitez pas à en abuser !

Ce bilan est aussi l'occasion de clore un premier cycle exploratoire du monde du logiciel libre. J'ai couvert les thèmes principaux que sont la mise en place d'un projet, son évangélisation, le rapport à la communauté, comment il s'intègre dans une entreprise et enfin comment se vit une contribution.
Pour les cinq prochaines années, rien est décidé mais j'ai déjà quelques idées. En dehors de continuer à travailler sur Cozy et Newebe, je vais essayer de découvrir d'autres langages (Go et Lua probablement). Et ce en contribuant plutôt qu'en montant un nouveau projet. Une autre chose que j'aimerais bien faire est de tester un développement écrit en Espéranto plutôt qu'en anglais (au moins dans les commentaires). Je n'en dis pas plus pour le moment, car je réserve cette histoire pour un prochain épisode !