Le temps libre (et précieux) du développeur open source

Dans mon précédent article «Faut-il un nouveau OpenStreetMap ?» je mettais en avant les problèmes de qualité qu'il pouvait y avoir dans l'écosystème d'OpenStreetmap. Ces problèmes sont compréhensibles lorsque l'on sait qu'il s'agit de l'œuvre notamment de bénévoles. De ce point de vue, les projets open source/libre comme OpenStreetMap sont formidables. Voyez-vous tout ce qu'il est possible de faire sur son temps libre et sans être payé ? Mais justement, ce temps libre…

En effet la plupart des projets open source et libres sont développés durant le temps libre de leurs développeurs et développeuses. Rares sont les personnes pouvant y travailler à temps plein et être payé pour cela. Cela signifie que les projets open source sont d'abord des projets personnels qui sont le résultat d'un investissement personnel important.

L'investissement personnel

Prenons l'exemple du dernier projet open source Kamo.social sur lequel nous travaillons avec mon équipe. D'après l'outil WakaTime, j'ai passé environ 75h30 à coder dans mon éditeur de texte du 1er janvier au 15 avril 2018. Le calendrier nous indique que nous sommes la 15ème semaine de l'année donc après un rapide calcul (75,5 / 15 = 5) on peut estimer que j'ai travaillé dans l'éditeur de texte en moyenne 5h par semaine.

Mais cette durée, comme je le précise, c'est seulement le temps que je passe dans mon éditeur de texte. Elle ne prend pas en compte le temps que je passe sur Internet, ou IRL, à trouver des solutions aux problèmes techniques rencontrés, ni le temps que l'on passe à faire des réunions en équipe chaque semaine, ni encore le temps que je passe à communiquer à propos du projet.

Vous pourrez constater sur le graphique de WakaTime que j'ai passé plus de temps à coder au début que maintenant. J'avais commencé avec entre 4h et 7h par jour durant trois jours début janvier lorsque le projet s'appelait encore Comminterest et dont les stats ne sont pas affichées avec celles de Kamo. Mais aujourd'hui je passe moins de temps à coder. Il y a deux raisons à cela. La première c'est qu'actuellement je réfléchis à certaines contraintes techniques explicitées dans mon article précédent, pour lesquelles je n'ai pas encore de solutions, et la seconde c'est que je devais m'occuper d'autres tâches personnelles.

Il y a une partie du temps que je passe à travailler activement sur Kamo.social mais il y a aussi une partie de mon temps que je passe à penser de manière passive au projet. Je peux parfois avoir des idées pour améliorer le service. Et ces idées je les ai car j'ai une partie du cerveau qui est quasiment toujours en train de penser à Kamo.

Un projet open source prend donc beaucoup de temps à être développé en terme de code, et selon en quoi il consiste, il peut aussi prendre du temps via les tâches connexes qui ne sont pas toujours visibles. Être mainteneur d'un projet open source peut donc être une perspective qui fait peur à certains. Être contributeur est déjà moins anxiogène.

La qualité des services open source

Pour augmenter la qualité des projets open source, il nous faut améliorer les outils pour les développeurs de sorte à leur faire gagner du temps. Moins de temps passé à faire de la configuration permet de passer plus de temps sur des nouvelles fonctionnalités ou d'avoir plus de vie sociale, au choix. Et si on permet aux personnes de contribuer en donnant seulement une heure de leur temps, alors on peut bénéficier de l'aide de beaucoup plus de personnes et améliorer la qualité du projet.

Par exemple pour Kamo.social, alors que j'ai les compétences pour installer un serveur étant moi-même devops, j'ai fait le choix de débuter le projet sur Heroku qui détecte automatiquement que le projet est en Ruby on Rails et permet d'avoir un service en ligne avec juste un git push. À un prix de 7$ par mois, je trouve cela raisonnable compte-tenu de tout le temps que cela m'économise en installation et maintenance. Si jamais le projet venait à grandir et demander plus de performances, alors je reconsidèrerais de passer sur un serveur moins cher que j'aurais installé moi-même car Heroku devient très vite cher dès qu'on passe à des offres plus importantes.

Aussi, pour revenir aux problèmes que j'ai rencontrés avec l'utilisation de plugins Leaflet pour OpenStreetMap, je suis prêt à contribuer pour les améliorer, mais il faut tout d'abord que mon premier contact avec soit positif. Si le plugin ne s'installe pas facilement, ou pire ne s'installe pas du tout, je ne vais pas avoir envie d'aller plus loin. Mais si je peux déjà l'installer et l'utiliser de manière basique facilement, alors je peux envisager de contribuer pour corriger quelques bugs et ajouter des fonctionnalités.

Notre temps à tous est précieux. Il est préférable de le passer à développer de nouveaux services pertinents ou de sortir se promener sous un ciel ensoleillé plutôt que de le passer à rouspéter devant un programme qui ne fonctionne pas correctement ou une documentation qui n'explique pas clairement la démarche à suivre. Pour encourager les contributions, nous devons les rendre motivantes et réduire les freins.

Et concrètement, comment faciliter les contributions ?

Des solutions, certaines existent déjà. Je pense tout d'abord aux méthodes de qualité en programmation :

• La méthode du TDD et utiliser une Continuous Integration par exemple permet de conserver la qualité du projet sur le long terme.
• Utiliser un linter permet de forcer une cohérence du code et faciliter de nouvelles contributions via des règles d'écriture clairement décrites.
• Générer une documentation automatiquement à partir des commentaires de code permet de faciliter l'entrée de nouveaux contributeurs et ceci sans trop de temps investi du côté du mainteneur.
• Proposer une installation automatisée de l'environnement de développement (avec Docker ou Ansible par exemple)

Développer des outils intermédiaires offre aussi un gain de temps. Si vous constatez que vous faites souvent la même chose, pourquoi ne pas écrire un script pour l'automatiser et ensuite le partager ? (C'est mon côté devops qui écrit)

Et puis, on l'oublie souvent, mais pourtant c'est très important : la communication. Lorsque vous faites quelque chose, dites-le, partagez-le. D'autres personnes pourront en bénéficier. Si vous rencontrez un problème, partagez-le, quelqu'un l'aura peut-être déjà rencontré et pourra vous aider. Et faites en sorte que la solution soit accessible à tout le monde. S'il n'y a pas d'espace de communication (comme un forum), il faut en créer un. S'il existe déjà mais qu'il n'est pas accueillant, il faut alors le revoir (changer son aspect, promouvoir une culture de la bienveillance) pour permettre à de nouvelles personnes de s'intégrer.

Plus généralement, Github a mis en ligne un site web dédié pour donner des conseils sur comment contribuer et comment maintenir un projet open source. Github a aussi un site web pour promouvoir le "Open Source Friday" qui invite chacun à contribuer tous les vendredis.

Tout ce que j'ai décrit précédemment permet à de nouvelles personnes de plus facilement s'intégrer à un projet et de collaborer avec le moins de freins possibles. Mais il ne s'agit pas des seules solutions possibles pour améliorer la qualité des projets open source et préserver le temps des développeurs open source. On peut encore trouver d'autres solutions ensemble.

Êtes-vous prêts à faciliter les contributions et à accueillir de nouveaux contributeurs et de nouvelles contributrices ?