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

15 April 2018

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.

Graphique de WakaTime du temps passé sur l'éditeur de texte pour Kamo.social. Il ne débute pas au 1er janvier, car le projet a été renommé depuis.

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.

Heroku est un hébergeur qui propose de mettre son application en ligne très rapidement sans avoir besoin de connaissances spécifiques ni de passer du temps à configurer. À un certain coût, certes.

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 :

Une CI qui teste chaque nouvelle contribution contribuer à assurer la qualité du projet sur le long terme

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)

Une documentation comme celle de Stripe propose de rapidement aller dans le vif du sujet

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 ?