Voici la suite et fin de notre série d’articles consacrée à Nicolas Perriault. Nous vous invitons à lire la première partie et la deuxième partie si n’est pas déjà fait.
Développer un projet open source est un challenge important, surtout lorsque ce projet devient de plus en plus connu et utilisé.
C’est particulièrement le cas pour Nicolas qui a porté seul un projet open source avec plusieurs milliers de stars sur Github, CasperJS, et cela a eu un prix auquel il ne s’était clairement pas préparé, notamment en terme de charge de travail.
La montée en charge
Depuis la reprise du projet en solo, les contraintes s’accentuent avec le temps.
Il reçoit de plus en plus de mails chaque jour en lien avec le projet, il doit régler sans cesse les issues, il ne se rémunère évidemment pas et surtout, passe beaucoup de son temps à s’occuper de ce projet au lieu de travailler pour gagner sa vie.
Mais, même s’il pense régulièrement à tout arrêter, il ne reste pas moins fier de ce petit outil sympa et, consciencieux, il ne veut pas laisser tomber les gens qui l’utilisent.
Il a également conscience de la reconnaissance et des retombées économiques que cela peut potentiellement lui apporter dans le futur.
Il décide donc de continuer à s’investir, peaufine la doc, crée un site Internet, un logo, et ouvre ainsi les vannes d’un projet qui va l’épuiser des mois durant.
Nicolas va d’ailleurs jusqu’à dire, après coup, que son rapport à ce projet est comparable au Syndrome de Stockholm, c’est-à-dire un rapport affectif pour quelque chose qui commence à envahir son existence négativement.
Malgré tout, après plusieurs mois, conscient de la tournure des choses, il tente de constituer une core team, idéalement de 5 développeur·se·s qui utilisent CasperJS, afin de se libérer du poids grandissant d’un projet que des équipes chez Google ou Linkedin commencent à utiliser.
Mais cela s’avère plus compliqué que prévu.
La descente aux enfers
Transmettre les informations lui prend un temps fou et, même si de nouvelles personnes s’occupent désormais du projet, Nicolas reste le leader, sans assurance aucune que l’équipe va gagner en autonomie.
La suite lui donnera d’ailleurs raison puisqu’au final une seule personne de l’équipe ainsi constituée va continuer à travailler sur CasperJS, essentiellement sur des patchs.
Très rapidement Nicolas ne s’occupe plus que de CasperJS.
Les enjeux deviennent énormes au point qu’il refuse des missions pour s’en occuper, qu’il passe ses nuits dessus, ses weekends, ses vacances, et, au bout du compte, il n’arrive pas à sortir du cycle infernal.
Et là, c’est le Burn-out.
Du jour au lendemain, épuisé nerveusement, il annonce qu’il cherche un repreneur en urgence.
Nicolas envoie un mail à toute la mailing list pour annoncer qu’il est à bout, qu’il n’a plus de vie, et que si les utilisateur·rice·s aiment ce projet alors il·elle·s doivent le reprendre, vite.
Après diverses péripéties, un developpeur de Linkedin s’étant proposé de reprendre le projet avant de se désengager quelques mois plus tard, c’est d’un ministère français que la solution viendra, où un développeur utilisant énormément la solution en interne, se manifeste pour récupérer les clés.
On fait le bilan
Le bilan que Nicolas tire des ces aventures est clair et précis.
D’abord, et tout simplement, qu’il faut s’assurer de prendre toute la mesure des responsabilités incombant à la maintenance d’un projet open source populaire.
Car pour peu que le projet prenne de l’ampleur, l’engagement personnel peut rapidement devenir intense, particulièrement quand de grosses entreprises l’utilisent, les utilisateurs pro de solutions open sources ayant de grosses attentes.
Qui plus est, selon lui, il est également irresponsable de lancer plein de petits projets open source non maintenus à droite et à gauche.
Lorsqu’on n’a pas le temps de maintenir un projet on crée potentiellement des problèmes aux utilisateur·rice·s de celui-ci, car d’expérience Nicolas sait qu’il est plus facile de consommer que de produire, et qu’il ne faut donc pas s’attendre à ce qu’ils ou elles s’impliquent outre mesure dans un projet.
Enfin, il n’existe pas encore de business model viable pour se rémunérer sur le temps passé à s’occuper de projets open source.
Preuve en est les 300 maigres dollars de dons récupérés sur toute la durée du projet, soit environ 5 ans, à travers un bouton Paypal qui selon lui « ne sert à rien ».
Sur ce sujet la courte aventure Sensio lui avait déjà laissé un goût amer car l’entreprise faisait rentrer de l’argent avec du conseil, de la formation ou encore de la certification, ce qui lui semblait déjà être un modèle « casse gueule ».
Éditer des solutions open source entraîne beaucoup de difficultés à trouver un modèle éthique et viable, le code étant gratuit, et surtout peut devenir la source d’un certain nombre de dérives.
Par exemple le simple fait que quelqu’un arrive avec une certification X ou Y alors qu’il n’y a aucune certitude que cette personne soit en capacité de régler les problèmes des clients.
Conclusion
Nicolas mène actuellement des jours heureux dans le sud de la France où il continue à travailler à distance pour Allo-Media, startup dans laquelle il s’éclate.
Il m’avouera à la fin de la conversation qu’il continue à jeter un coup d’œil de temps en temps sur le Github de CasperJS et par me donner le lien Youtube de ce créateur d’un projet open source très connu, Bootstrap, dont il valide clairement un discours dans lequel il ne se reconnaît que trop bien.
Avis aux amateur·rice·s :