J'ai failli le faire

J'ai failli le faire. Les mêmes questions sont encore revenues: A quoi bon ? Est-ce que c'est la peine de continuer comme ça ? Et si j'étais passé à côté ? Avec elles, la tentation d'abandonner, de jeter l'éponge.

Ca fait plusieurs années maintenant que ces questions me hantent régulièrement. Et si je me trompais ? Qu'est-ce que j'y gagne à continuer comme ça, après tout, alors qu'il serait si facile de laisser tomber, que ce serait plus simple, voire définitif. Peut-être même que j'y trouverais une certaine paix.

La dernière fois, ça m'a repris quand j'ai entendu parler de Floobits, un outil pour coder à plusieurs, chacun dans son éditeur préféré (Vim, Emacs ou SublimeText). C'était alléchant, des perspectives formidables.

Depuis des années, j'utilise mon propre éditeur de code, que j'ai moi-même développé, une sorte d'Emacs en OCaml, configurable en OCaml. Je me souviens que je n'avais pas envie de coder en ELisp pour rajouter à Emacs des fonctionnalités type IDE pour OCaml. Alors j'ai commencé à développer un embryon d'IDE pour OCaml, dont l'éditeur était bien sûr la partie centrale. Il pouvait accueillir des fenêtres d'édition et d'affichage spécialisées pour certains types de fichiers, comme les dump OCamldoc.

Avec le temps, et surtout le manque de temps, je n'ai maintenu de la suite originale d'outils pratiquement que cet éditeur, qui a donc maintenant son dépôt à lui tout seul sur Github.

Ce développement m'a apporté beaucoup d'expérience et j'ai rencontré les mêmes problèmes sûrement que les développeurs d'autres éditeurs. Je me suis d'ailleurs parfois inspiré des solutions qu'ils avaient adoptées (cf. cette note).

J'ai surtout gagné un contrôle sur mon outil principal de travail. Si une fonctionnalité me manquait, j'étais, je suis toujours, en capacité de l'ajouter: Je connais le code, OCaml est un langage puissant, les deux combinés font qu'ajouter une fonctionnalité simple est assez rapide. Je peux également utiliser tout un tas de bibliothèques existantes que je connais déjà pour les avoir déjà utilisées dans d'autres développements.

Mais parfois je n'ai tout simlement pas le temps ou pas l'envie d'implémenter une nouvelle fonctionnalité pour un besoin ponctuel. C'est la limite à l'utilisation de ses propres outils. En l'occurrence, il y a très peu d'utilisateurs et je suis le seul contributeur. Ce n'est pas un problème, je n'ai jamais fait énormément de publicité, j'ai surtout mis le code à disposition parce qu'il m'est utile et pourrait l'être à d'autres.

Découvrant Floobits, j'ai (re)pris conscience de cette limite. Les utilisateurs d'Emacs, Vim ou SublimeText peuvent tout de suite profiter de ce service. Avec mon éditeur, si je veux en profiter aussi, je devrais coder l'interface avec le service.

Puisque de plus en plus de plateformes de développement offrent des APIs pour accéder à leurs fonctionnalités depuis d'autres outils, il est probable que les éditeurs les plus populaires se verront dotés les plus rapidement des accès à ces nouveaux services.

Par ailleurs, si je voulais profiter de Floobits pour coder avec quelqu'un qui utilise déjà l'un des trois éditeurs supportés, je devrais moi aussi utiliser l'un de ces éditeurs, ou bien coder l'interface avec ce service dans mon éditeur.

L'éditeur, qui auparavant était un outil très personnel et qui communiquait relativement peu, devient de plus en plus connecté lui aussi. La liaison avec le gestionnaire de versions du code était déjà une fonctionnalité discriminante pour certains¹.

J'ai alors le choix: rejoindre la communauté des utilisateurs des éditeurs que l'on pourrait qualifier de "standards" et profiter immédiatement de toutes les fonctionnalités présentes et à venir ou bien continuer d'utiliser mon éditeur, moins puissant mais sur mesure, et que j'ai la capacité d'adapter à mes besoins.

Autrement dit, je peux dépendre encore un peu plus des choix faits par d'autres, déléguer, en quelque sorte abandonner (une partie de) ma souveraineté. Dans ce cas je me retrouve appartenir à une communauté, et j'en suivrai le mouvement tant qu'il est supportable pour moi.

D'un autre côté, je peux garder la maîtrise de mon outil, savoir ce qu'il fait, et peut-être surtout comment il le fait. Dans ce cas, j'ai le risque de m'exclure des possibilités offertes par les nouveaux services, et donc d'être exclu des pratiques de mes pairs, donc au final exclu de la communauté.

On pourrait me répondre que j'ai aussi la possibilité de prendre le temps d'apprendre pour pouvoir développer et intervenir sur le code d'un éditeur soutenu par une commuanuté dynamique, voire même faire un fork et le synchroniser régulièrement pour profiter des améliorations faites dans la branche originale.

En effet. Mais si j'ai le temps de faire cela, alors j'ai aussi le temps de le faire dans mon propre éditeur. Et synchroniser régulièrement un fork ne met pas à l'abri de modifications par d'autres impactant mes propres réalisations et les remettant potentiellement en cause, ou entraînant un lourd travail d'adaptation. Il faut toujours composer avec la forme que les idées des auteurs donnent au logiciel.

Bref, la tentation est revenue. J'y ai encore résisté. Ai-je raison ou tort ? La réponse à cette question dépend de comment on envisage son métier par rapport aux impératifs de rapidité et d'efficacité ambiants.

La rapidité, l'efficacité ne se mesurent pas tout simplement en temps passé pour implémenter une fonctionnalité. Il faudrait pouvoir connaître l'impact de l'éditeur utilisé sur la forme du code produit, forme qui impacte l'avenir du logiciel. Par exemple, un éditeur avec moult fonctionnalités pour générer des parties du code a sûrement un impact sur ma façon de penser, d'appréhender un problème et la façon la plus "efficace" d'implémenter sa résolution.

Maîtriser mon éditeur, c'est aussi maîtriser ma façon de travailler, pouvoir adapter mon outil à ma façon de penser, à mon rythme.

Je ne suis pas encore prêt à lâcher prise.