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 certains1.
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.