Contributions communautaires

Flus se base(ra) sur un logiciel libre ET communautaire : FreshRSS. En me basant sur un logiciel construit par d’autres, je décide de jouer le jeu et de reverser le maximum de mes améliorations de code au pot commun. Bien sûr, je suis un peu biaisé puisque j’ai moi-même initié FreshRSS : ce pot commun a longtemps été mon propre pot. Je réalise toutefois aujourd’hui que celui-ci est désormais bel et bien possédé par une communauté.

J’ai le souvenir que mes précédentes contributions étaient facilement intégrées, sans forcément de longues revues de code. C’était à la fois confortable et dangereux pour la stabilité du logiciel. Ce confort je le retrouve sur la plupart de mes projets libres, notamment Lessy que je développe grandement seul (quand je prends le temps de le faire). Je me rends compte que j’y ai pris goût.

C’est pourquoi mes deux dernières contributions importantes à FreshRSS m’ont questionné. La première consistait à ajouter l’ajout de la validation des adresses emails ; la seconde à ajouter une configuration pour lancer aisément un environnement de développement. Ces deux « pull requests » ont généré pas mal de commentaires et de suggestions d’amélioration auxquelles je ne m’attendais pas. L’intégration à la branche principale a donc pris plus de temps que je ne le pensais.

Les remarques et suggestions étaient tout à fait pertinentes et je suis extrêmement reconnaissant aux personnes qui ont pris le temps de relire mon code de les avoir faites : il y a une véritable addition des idées et connaissances pour arriver à un « mieux ». J’avais adoré ce travail d’équipe lorsque j’étais salarié et je prends toujours du plaisir à ce genre d’expérience aujourd’hui. Je me pose toutefois la question du long terme : aurai-je toujours l’énergie de proposer mes améliorations à la branche communautaire ?

La question n’est pas si différente de celle du travail au sein d’une équipe en entreprise. Elle diffère pourtant sur un point essentiel : en entreprise, une équipe possède des membres bien identifiés avec des temporalités communes (i.e. ils et elles bossent « en même temps »). On peut donc s’améliorer et avancer véritablement ensemble. Une communauté est par essence plus volatile et avec des temporalités complètement différentes ; l’exercice n’est donc pas le même pour ce qui est de la communication et du travail « ensemble ».

Il n’est absolument pas question de comparer qualitativement ces deux fonctionnements. Simplement, les contributions communautaires me questionnent dans le cadre d’une entreprise qui devra, à terme, me permettre de vivre. Comment gérer les « urgences » auxquelles je risque d’être confronté ?

Évidemment, des solutions existent. Flus fonctionnera notamment sur une branche spécifique sur laquelle je pourrai intégrer des fonctionnalités qui n’existent pas encore dans la version communautaire (mais attention, le code sera toujours ouvert).

La réflexion à laquelle ce questionnement me mène plutôt, c’est que l’urgence ne peut plus devenir une norme. En contribuant à une communauté qui ne possède pas les mêmes attentes et la même temporalité que moi, je m’impose des garde-fous. En jouant la carte de la communauté, je suis forcé de travailler différemment de si j’avais gardé le code pour moi. Est-ce que ce sera mieux ? Je le crois et l’espère.

J’ai hâte de savoir ce que ça donnera sur du plus long terme.