L'idée de ce billet m'est venu a la suite de celui de xbright intitulé La difficulté d'exister pour les petits projets de logiciel libre ou son auteur met en avant le manque de contributeurs sur les petits projets Open Source. Hormis le fait d'écrire des rapport de bugs, je n'ai jamais réellement codé pour un projet libre existant, donc j'ai voulu tenter l'expérience en prenant comme projet Bluemindo, le player audio de xbright écrit en Python.
Récupérer un projet et se lancer dans l'analyse de son code source est une tâche très intimidante au premier abord, il faut consacrer un certain temps afin d'apprivoiser les sources, tester le programme, repérer quelle fonction fait quoi, visualiser l'architecture du logiciel. Toutes ces tâches n'existent pas lorsque l'on est le créateur d'un projet puisque l'on est parti de zéro pour arriver au résultat que l'on a en tête.
Il faut dire que les développeurs ne facilitent pas toujours la vie de ceux qui passent derrière. Les difficultés sont multiples : manque de commentaires dans le code, noms de variable peu explicites, identifiants des widgets du fichier Glade laissé avec leur valeurs par défaut (button1, progressbar3, .....).
Un code source ouvert se doit avant tout d'être clair et lisible. Eric S. Raymond évoque ce problème dans le livre "The cathedral and the bazaar" en disant que la clarté du code est plus importante que sa vitesse d'exécution. De mon point de vue, un nom de variable composé d'une seule lettre est toujours un mauvais nom de variable. C'est une perversion venue du monde obscur des mathématiques et qui n'a rien a faire dans la programmation. Les éditeurs de code source modernes supportent tous l'autocomplétion des noms de variable, donc il n'y a aucune raison pour ne pas utiliser des noms explicites qu'ils fassent 15 caractères ou plus.
Une fois que l'on a parcouru une bonne partie du code source de l'application, on commence a saisir le fonctionnement global, et on peut s'attaquer a l'écriture de code... Ouhla, pas si vite ... Ne perdez pas une seule minute a écrire la moindre ligne de code avant d'avoir obtenu l'accord de l'auteur. Open Source ne veux pas dire que c'est la fête et que chacun écrit ce qu'il veut dans un projet, ne contribuez pas avant d'avoir la bénédiction du "benevolent dictator for life", il m'est arrivé de soumettre des patchs qui n'ont pas été accepté et pour plusieurs raisons : l'auteur avait déjà codé la modification de son propre coté ou l'auteur a refusé l'intégration du patch. Ici, on voit la deuxième difficulté : le développeur principal, n'a de comptes a rendre a personne et il ne va pas précéder chaque patch de son cru par un rapport de bug sur sa forge.
J'ai beau avoir trainé dans le monde de l'open source quelques années, avoir quelques bonnes bases en programmation, j'ai toujours l'impression qu'il manque quelque chose d'essentiel afin se saisir complètement le mode de développement du logiciel libre. Les sources sont libres, oui très bien, mais est ce suffisant ? L'exemple de Rhythmbox nous prouve que non, Dans son billet Cyrille Borne exprime ses doutes quand a la viabilité d'un projet Open Source :

Il me semblait pourtant que l'un des intérêts de l'ouverture du code, c'était qu'en cas d'arrêt d'un développeur, un autre apparaît pour prendre la relève. Un système auquel je n'ai jamais cru, tant il est difficile dans le cas de l'écriture d'un code de repasser derrière, si bien que les gens préfèrent créer leur propre application.

Dans les commentaires de ce même billet, RunningTracker cerne très bien le problème :

il est (très) difficile de reprendre un logiciel développé par quelqu'un d'autre. C'est là où la documentation prend tout son sens. Une bonne documentation (avec schémas UML, explication des algos... etc) et un code bien commenté (ce qui est très rare...) facilitent grandement la compréhension et la reprise du code. Je pense qu'en tant que développeurs, nous devrions passer plus de temps sur ces deux aspects (même si c'est parfois rébarbatif).

Dans la communauté, personne ne pense a reprendre le développement de Rhythmbox, et on réfléchi déjà a son successeur. Je peux comprendre : s'il a déjà été compliqué de se plonger au coeur de Bluemindo qui est un projet jeune et écrit en Python, je n'imagine même pas quels efforts il est nécessaire de faire pour comprendre le fonctionnement de Rhythmbox qui est plus mature et codé en C.
La page concernant le développement de Rhythmbox ressemble plus a une mauvaise blague avec ses liens vers SVN et IRC. Avec ces deux éléments, il va être difficile d'aller très loin ...
Maintenant voila ce que je propose :
Utiliser Internet pour ce a quoi il a été construit a la base: permettre a des chercheurs de travailler ensemble. Partager les sources n'est pas suffisant, il faut aussi avoir un système collaboratif permettant d'étudier, d'analyser un projet libre. Il manque un outil qui aide a la compréhension de la programmation, parce qu'il y a un fossé qui est en train de se créer entre les programmeurs vétérans et les novices. Pour reprendre les concepts de Eric Raymond, les plans de la cathédrale doivent être rendus public et le bazaar doit être ordonné.
Il est aussi important a mes yeux d'avoir une documentation centrale, une mère de toutes les documentations, avec tous les langages, toutes les librairies, tous les outils de développement, avec en bonus des tutoriels et des exemples. En quelque sorte l'équivalent de MSDN pour le logiciel libre.
Une grande partie de la communauté reste bloquée dans le test de différentes distributions, la compilation de logiciels, et les rapports de bug. C'est bien mais j'ai envie que les choses aillent plus loin, et pour cela il faut que la marche qui sépare le simple utilisateur du réel contributeur soit plus simple a gravir.