Les dangers d’un projet géré par une seule personne

Twitter Facebook Google Plus Linkedin email

Il y a quelques temps, sur Twitter j’ai vu passer quelque chose de vraiment sympa pour ceux qui touchent souvent à du code, à savoir la coloration multiples des différents niveaux de crochets/accolades imbriqués pour faciliter la lecture en cas d’indentation douteuse. J’ai voulu tester ça sur Sublime Text et ça ne s’est pas passé comme prévu. Un symptôme qui peut arriver à d’autres projets.

Un week-end qui s’annonçait bien…

Voilà le Tweet qui m’a saucé :

La réponse était disponible en déroulant les discussions, ce qui n’est pas toujours évident pour ceux qui découvrent Twitter. Et donc j’ai voulu installer ça sur Sublime Text. Si vous n’avez pas déjà lu mes articles précédents et que vous découvrez cet éditeur de code, il existe un outil de référence pour faciliter l’installation et la gestion des addons, Package Control, qui a un site dédié.

Le plugin que je comptais installer est BracketHighlighter, dont le code est disponible sur Github si vous êtes fondus d’installation à la main. Son développeur recommande toutefois l’installation via Package Control. Cependant, j’ai eu droit à un message d’erreur dégueulasse en cherchant à installer le package :

Bon, c’est donc parti pour un peu de debug, de recherches Qwant, je tombe sur la page de troubleshooting (traduit littéralement, fusiller les troubles), qui ne m’aide pas tant que ça mais du coup je sais maintenant qu’elle existe, et comme je n’ai pas plus d’infos je me tourne vers le forum. Je passe sur le fait qu’il repose sur cette horreur de Discourse et tombe sur LE sujet qui m’explique et m’apprend beaucoup trop de choses d’un coup.

« Vous êtes le maillon faible »

J’ignorais complètement le fait, mais via les discussions je découvre que cet utilitaire repose sur les épaules d’une seule personne. Site web, serveur qui héberge le dépôt pour les extensions, développement du plugin, et donc financement de tout ça. Et il s’avère que le serveur en question était arrivé à saturation, ce qui a au passage corrompu la base de données. Avant d’arriver à saturation, la taille de la base avait rendu sa routine de sauvegarde inopérante. Le serveur avait été installé il y a plus de six ans, tout à la main.

La résolution a pris du temps, puisqu’elle a pris la forme d’un nouveau serveur et la définition de playbooks Ansible pour permettre de futurs déploiements plus rapides et automatisés. Il aura également fallu reproduire plusieurs semaines de mises à jour et d’ajouts de plugins à la base de données puisque la sauvegarde ne fonctionnait plus.

Je n’ai pas vu de message insultant sur l’incompétence du gars ou sa lenteur à réparer, ce qui me rassure quand je vois les torrents de merde qui se déversent fréquemment (regardez les commentaires d’applications mobiles gratuite quand une nouvelle version fout la merde, les humains sont vraiment des déchets), que du soutien voire même des conseils d’amélioration, et la question notamment du support financier a été amenée sur le tapis. C’est là qu’on apprend que si l’auteur a démarré ça de manière complètement indépendante, il travaille maintenant pour Sublime HQ, qui développe Sublime Text. mais le projet est resté complètement indépendant et maintenu sur du temps libre. La revue et la publication des extensions sur le channel sont tout de même à la charge de deux autres personnes, mais le coût financier principal est effectivement dans les mains d’un seul homme, qui investit mille dollars par an dans l’infrastructure. Et prévoit d’en mettre un peu plus pour pouvoir faire de nouveau des sauvegardes fiables. C’est toujours mieux qu’un budget clopes vous me direz, mais tout de même…

La difficulté à gérer un projet seul

On le voit, si apparemment le budget n’est pas tant un problème, gérer seul sur son temps libre limité n’a pas été de tout repos quand ça a pété : plusieurs jours pour restaurer les services, devoir tout remonter sur du neuf parce que l’ancien était saturé, et point valable pour tout hébergement géré de manière indépendante, quid de la sécurité ? (au moins ça tourne pas sur du WordPress, mais apparemment sur une application Python)

Je comprend très bien la situation, hébergeant moi-même ce blog et ayant beaucoup moins de temps libre, aussi bien pour l’écriture que la maintenance, c’est difficile. Et Arowan est aussi bien moins disponible qu’avant pour maintenir l’infrastructure quand je ne suis pas là. Sans rentrer dans trop de détails, on est toujours en Proxmox 4, la VM du blog est toujours en Debian 8 (les travaux pour sa remplaçante sont au point mort, par flemme), je dois passer une fois par semaine à peine sur les différentes VMs pour vérifier/faire les mises à jour, car je n’ai jamais pu faire en sorte qu’unattended-upgrades fonctionnent sur celles-ci alors que ça tourne nickel sur mon cluster swarm, je dois toujours monter l’environnement test du blog sur ce dernier pour bosser sur une refonte, bref, je pourrais continuer comme ça longtemps sur les projets au ralenti voire en pause à cause de ce temps libre qui manque (sans parler de la motivation parfois).

Et je ne pense pas être le seul dans ce cas, donc quand on voit des sujets discutant d’automatiser un max de choses, ou de reposer sur des prestataires de services qui s’occupent d’un max de choses pour vous, il n’y a rien de surprenant, c’est d’ailleurs ce qui a fait le succès du « cloud public » et d’outils dit « devops » qui permettent de gagner un max de temps sur les opérations du quotidien.

Quid de la gouvernance « commerciale » ?

Je l’ai dit, le développeur qui a démarré le projet de manière complètement indépendante travaille maintenant pour la société qui développe l’éditeur de code. Pourquoi dès lors ne pas se poser la question de la pérennisation d’un utilitaire qui a certainement contribué au succès dudit éditeur ? Parce que franchement, gérer à la main l’installation et la maintenance des plugins c’est une tannée, et même si manifestement le développeur n’est pas près de lâcher son bébé, si jamais les imprévus de la vie font qu’il doit tout abandonner, comment faire pour que le projet survive correctement ? Parce que si le code de l’utilitaire est open-source, je ne sais pas ce qu’il en est de la partie serveur, et la reprise d’un nom de domaine n’est pas non plus triviale pour s’assurer d’une transparence du côté des utilisateurs.

Parce que bon, des outils open-source chapeautés par des sociétés, n’en déplaise aux extrémistes, c’est très, très, très courant. Canonical, ça vous dit quelque chose ? Ben ce n’est pas une association loi 1901, mais une société qui vit de contrats de supports et de déploiement sur la base d’une distribution Linux développée en source ouverte et fournie gratuitement au public (leurs contributions aux projets « de base » sont plus nombreuses qu’auparavant). Gnome et une palanquée d’autres projets ne seraient pas ce qu’ils sont sans le support de RedHat, qui fait la même chose que Canonical mais qui a commencé il y a vingt ans. Quand vous regardez les plus gros contributeurs du noyau Linux, il est loin le temps où les développeurs indépendants sur leur temps libre étaient la norme, désormais les contributeurs sont souvent payés par leur employeur pour bosser sur le noyau, et Microsoft est même maintenant un des plus gros contributeurs, un comble !. Malgré tout le noyau reste un logiciel libre accessible à tous, c’est donc que ce modèle est possible.

Pour Package Control on peut donc imaginer pas mal de formes de soutien :

  • Libérer du temps de travail de Will Bond (puisque c’est son nom, il est grand temps de le préciser) pour qu’il l’investisse dans la gestion de l’utilitaire, mais il garde la main sur tout ce qui s’en rapproche (domaine, serveur…), pareil pour la gestion de « l’annuaire »
  • Gestion de l’infrastructure en interne, ce qui comprend serveur et nom de domaine, en laissant la main sur le développement de l’utilitaire et de l’annuaire
  • Intégration directe à Sublime Text, avec donc récupération de tous les éléments qui le concerne : infrastructure, développement, annuaire.

On pourrait évidemment penser à n’importe quel hybride des quelques idées que je viens de proposer. Ne serait-ce que pour conserver un équilibre entre ce qui est géré en interne et ce qui est géré par la communauté, en effet, il ne s’agirait pas de trop fermer l’accès à l’annuaire pour conserver l’intérêt des développeurs tiers pour la création, la publication et l’évolution d’extensions.

Si vous pouvez, soutenez

Je sais que c’est un message qui commence à être vomitif (comme tous les YouTubers qui mendient les pouces bleus et les partages à chaque fin de vidéo), mais il y a effectivement pas mal de formes de soutien et elles sont d’autant plus importantes que le nombre de personnes impliquées sur un projet est restreint (voire ici, unique). Un synonyme de soutien en particulier dans le monde du logiciel libre/open-source, c’est la contribution, et ça, j’en ai déjà parlé il y a un bon moment maintenant mais c’est toujours aussi valide aujourd’hui, presque plus quand on voit les complaintes de certains par rapport au nombre d’utilisateurs passifs qui pose problème sur certains projets.

(crédit image : Mohamed Elhusseiny)

Poster un Commentaire

avatar
  S’abonner  
Notifier de