Tout projet commence par la sélection des bons outils. Qu’est-ce qui nous permettra d’aller le plus vite et le plus efficacement possible ?

Même en se contentant de cette question simple, vous êtes partis pour de long débats sur les vertus et les vices de tel ou tel CMS/bibliothèque/cadriciel/langage… Ne vous y trompez pas, lorsqu’on en arrive là, l’informatique n’a rien de plus « scientifique » ou « objectif » qu’autre chose. Il y a tout autant de modes arbitraires et de mauvaise foi qu’ailleurs.

Déjà qu’on est pas rendu avec ça, qu’en plus il faut se poser une autre question : comment puis-je faire un projet vraiment libre ?

Parce que la licence ne vaut pas grand chose en soi

Si vous voulez faire du libre, il ne suffit pas de poser une licence GPL sur votre code, loin s’en faut ! Si vous voulez faire les choses comme il faut, il y a trois point à considérer :

•     Chercher à améliorer l’existant plutôt que de faire du neuf
•     Documenter et faciliter le partage
•     Répercuter les modifications

Concrètement, chacun de ces points prend du temps ! C’est évident pour la documentation, mais ça n’est pas moins vrai pour les autres points. Dans mon précédent travail, mon chef d’équipe faisait des pieds et des mains pour que le direction nous laisse du temps pour transformer nos développements en plugins dignes de ce nom (écris en respectant les bonnes pratiques et réutilisable par la communauté)… Malheureusement, ce temps n’étant pas facturable, nous devions nous contenter de codes fait à la va vite (ou de gros plugins utiles seulement à un projet donné). Pourquoi voit-on tant de projets fait par une seule personne ? Pourquoi voit-on tant de projets qui réinventent la poudre ? Parce que c’est plus simple que de s’adapter à de l’existant !
En revanche, entre ça et une collaboration, qu’est-ce qui apporte les meilleurs résultats ?

Se greffer proprement

Dogmazic est basé sur Mediagoblin et j’ai passé pratiquement autant de temps sur l’un que sur l’autre. S’agissant d’un projet tout jeune, il y avait beaucoup de choses qui n’était pas tout à fait finies au moment où nous avons rejoint le projet, en particulier sur les plugins. C’est assez logique, lorsqu’on fait un logiciel on fait en priorité ce dont on a besoin… comment prévoir qu’un hurluberlu allait vouloir tordre le logiciel dans tout les sens pour faire une archive musicale ? La solution simple aurait été de partir de zéro et de tout recoder nous même… mais à quoi bon avoir deux Mediagoblins ? Du coup il a fallu pas mal de discussions et de code (merci Paroneayea !!) pour arriver à un système de plugins qui m’évite de modifier le noyau du logiciel (et permettant de partager mes modifications en retour). Si aujourd’hui Mediagoblin à un bon système de plugins, c’est grâce à Dogma !

S’adapter

Les décisions sur le design d’un logiciel sont toujours le fruits d’un compromis mûrement réfléchit or, sans connaître les raisons de ces choix (et les visées globales ou a long terme du logiciel) impossible de savoir si il s’agit d’une bonne décision. Facile donc d’arriver en pointer du doigt ce qui cloche, mais fondamentalement ça ne sert à rien parce que sans connaitre les tenants et les aboutissants vous êtes sûr de tomber à côté. Il faut prendre du temps pour s’acclimater et comprendre pourquoi l’équipe à agit de cette façon. Il faut donc lire le code, les maillings, poser des questions… C’est long ! Mais au final, lorsqu’on modifie le code, on est sûr de ne pas avoir à le ré-écrire entièrement parce qu’il ne respect pas les bonnes pratiques.

S’adapter beaucoup

Je l’ai déjà dit, Mediagoblin est très jeune. Or, la réalisation d’un logiciel passe forcément par un processus pénible d’essais et d’échecs. On se rend souvent compte après des heures de développements qu’on est coincé par une dépendance trop limité ou une petite erreur de design qu’on a pas pu voir venir avant ce moment fatidique. Que faire alors ? Tout changer !

Lorsqu’on se greffe à un tel logiciel, et que ça arrive, on se retrouve souvent avec un code qui ne marche plus à cause de ça. Il faut donc corriger le code en fonction. Pourquoi ne pas prendre un logiciel plus avancé alors ? Simplement parce qu’il n’y en a pas ! De plus, cela nous permet de faire des retours sur d’éventuelles régressions liées aux modifications de Mediagoblin. C’est un peu le principe de bosser en équipe finalement… sur le long-terme on y gagne parce pour quelques heures perdues à réviser le code, on gagne toutes les améliorations apportées par la modification originale.

Se reposer ou être libre

Thucydide ne s’y ai pas trompé, on ne peux pas être libre « passivement ». De plus soyons franc : tout ceci est chiant ! Lorsqu’on a un projet en tête, on a qu’une envie c’est d’avancer ! Devoir rédiger des documentations sur son propre travail, s’adapter à d’autres techniques (qu’on ne maîtrise pas forcément – avec l’apprentissage que ça implique), prendre le temps d' »universaliser » son travail (pour qu’il servent à d’autres projets)… ça donne rapidement envie de ronger le frein. Ceci étant dit, sans ça, est-ce que le libre s’en ne s’en retrouve-t-il pas réduit à un texte juridique inapplicable en pratique ?

Il existe d’ailleurs de grosses lacunes dans le domaines lorsque l’on sort de gros projets bien rodés…. trop de développeurs abandonnent leurs projets frustrés faute de réelles collaborations.