Des difficultés de la participation aux logiciels libres
8 mar. 2009
Par Strider - Linux - Lien permanent
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.
Commentaires
Hello,
pour reprendre ton exemple as-tu contacté xbright (l'auteur de bluemindo) pour comprendre le code? Parce que tel est le problème aussi.
Certain dev ne veulent pas intégré d'autre patch (ce qui est apparemment le cas de Rythmebox) mais bien souvent les gens ne demande pas avant s'il serait possible d'avoir de la documentation. Personnellement, dans chaque projet que je créer s'il n'y a personne pour participer (ce qui est le cas au début) je me contrefiche de la doc. La seul chose que je fait c'est des commentaire suffisamment complet pour que je le comprennent en le relisant par après...
Actuellement je travail avec une autre personne sur un projet (l'autre est venu s'ajouter après) résultat je me suis mis à produire de la documentation.
Il faut se rendre compte que la doc est en général quelque chose de hait des développeurs.
Mais ton sujet comme celui de xbright posent énormément de question. Je pense surtout qu'il rappel que nombre de dev opensource||libre sont des gens qui n'y connaissent rien et essaye, mais auquel personne n'essaye d'expliquer ce qu'es uml, meurisse ou autre.
GrummfyPour le cas Bluemindo, disons que c'était le but de l'expérience de se lancer dans le développement sans solliciter l'auteur. J'ai tout d'abord commencer par prendre contact avec xbright en lui annonçant la couleur : je veux participer mais d'abord, je me débrouille de mon coté.
striderSi cela avait été une situation plus réelle et non une expérience, il est évident qu'un dialogue doit se créer avec le chef de projet.
Bien sur que faire de la documentation n'est pas une tache très amusante, mais n'existe t'il aucun outil permettant de générer un schéma UML (ou autre, pourvu que ce soit suffisament visuel) a partir du code source ?
J'ai l'impression que beaucoup de développeurs on choisi un cycle d'ingénieur dans leurs études, or moi j'ai fait le choix de ne pas aller jusque la et du coup il me manque certainement des bases sur certains aspect de la conception logicielle. Mais lesquels ? Je trouve beaucoup de tutoriels sur comment coder, comment utiliser telle ou telle librairie mais rarement des articles traitant d'une vue plus globale du développement.
Comme tu le dis, peux de tuto sur le cycle de développement ou simplement la gestion de projet et lorsque cela existe c'est souvent trop abscons pour être compris.
Quand au programme pour généré de l'UML à partir des source, personnellement je les trouve souvent lourd et très mal fait, mais cela existe! Cependant vu que beaucoup de développeur OpenSource||libre (je parle pour les petits projet hein!) ne connaissent pas du tout ce qu'est un cycle de développement, UML, etc donc ils auront difficile à produire quelque chose.
D'où l'intérêt si on s'y connait un peu d'aider un projet en expliquant ou produisant de la doc sur le sujet pour ce projet!.
De la javadoc, phpdoc ou autre peuvent facilement être produit pour peux qu'on en apprenne la syntaxe et il existe des style de syntaxe pour documentation dit universel (via doygene par exemple). mais là cela devient souvent un combat avec le dev principal (ce que je fait si j'estime le projet intéressant et que j'y contribue amplement ...)
Pour moi, il est clair que ben souvent c'est par méconnaissance que de la doc(développeur) n'existe pas.
GrummfyIl existe quelques logiciels de "retro engineering" pour générer des diagrammes UML (diagramme de classes par exemple) a partir du code source (je pense ici a ArgoUML) mais comme le dit Grummfy, ce n'est pas la panacée.
Créer une bonne documentation demande beaucoup de travail... et ce n'est pas l'étape la plus trepidente du projet ! Mais les avantages sont multiples: une bonne documentation permet d'attirer plus facilement des contributeurs sur un projet, et permet également (même au dev principal) de pouvoir se replonger plus facilement dans le code lorsqu'il s'agit de développer de nouvelles fonctionnalités quelques années plus tard...
RunningTrackerDe la doc, de la doc, de la doc ! Si un développement n'est pas documenté, c'est un mauvais développement, quelle que soit la qualité du code en lui-même.
Je suis confronté quotidiennement à ce problème dans mon activité professionnelle, qui n'a rien à voir avec du libre, mais tout à voir avec du développement. Je dois diriger des équipes de développeurs qui sont susceptibles d'intervenir sur le code produit par d'autres développeurs, 2 jours ou 2 ans auparavant.Si le développement n'est pas documenté, c'est la mort du projet. Dans notre cas, c'est une mort financière, (le projet nous coûte plus qu'il ne nous rapporte). Dans le cas du LL, c'est tout simplement le code qui est mort.
Ce problème n'est donc pas spécifique au LL. C'est un problème de mentalité du développeur. Il ne devrait tout simplement pas exister dans le LL, puisqu'effectivement, le code est susceptible d'être repris par n'importe qui, et pas seulement par une équipe professionnelle (comme dans mon cas).
En clair, si vous développez, documentez. C'est au moins aussi important.
Poupoul2Je tiens à mettre un bémol à cette analyse : c'est typiquement ce que ressent un contributeur débutant. Tout le monde est passé par là. Mais plus on acquiert d'expérience, plus tout cela va vite et c'est logique.
Pour ceux qui font des arts martiaux, pensez à votre ceinture jaune : tout vous semblait super dur et vous étiez super fier d'avoir cette foutue ceinture jaune. Maintenant que vous êtes ceinture noire, vous avez l'impression que le programme de la ceinture jaune est trivial et s'apprend en une demi leçon.
C'est pareil pour les logiciels. Si tu as peu d'expérience de python et pas d'expérience pygtk, cela va te sembler énorme. Si au contraire tu utilises cela tous les jours, ça va te sembler trivial.
Au début, je pensais comme toi et puis, avec le temps, c'est devenu plus fluide. Il y a quelques temps j'ai envoyé plusieurs patchs pour un jeu en python. Entre le moment où j'ai lancé le jeu pour la première fois et le moment où le patch était sur le bugtracker il s'est écoulé... 15 minutes ! (j'ai découvert un bug qui me gênait dès les premières minutes de jeu). La semaine passée, j'ai voulu faire un patch pour Rhythmbox alors que ça fait un sacré bout de temps que je fais plus de C : cela m'a pris une heure dont 45 minutes d'installation des librairies.
Et pourant, je ne suis vraiment pas très expérimenté et je suis pas du tout un bon codeur. Je commence juste à trouver mes marques. Mais cela peut prendre plusieurs années.
Et dis toi bien que le code source des logiciels libres *est* clair. Très clair même. Tu n'as peut-être jamais vu de bon gros code source propriétaire. C'est juste qu'à ton niveau tu voudrais que chaque ligne te soit expliquée précisément. C'est juste pas possible et, dans quelques années, tu ne comprendras même plus qu'on ne puisse pas comprendre les lignes en question.
PloumJe rajoute à cela que coder et programmer est, intrinsèquement, quelque chose de compliqué.
Quand on sort de l'école, on a écrit deux boucles while, un super projet de jeu de dames et on croit savoir programmer. Du coup, contribuer au libre (ou à n'importe quel projet) semble ardu. Mais c'est tout simplement car on ne sait *pas* programmer.
Est-ce que tu sais parler espagnol parce que tu as lu un "précis de grammaire espagnole" ? Pas du tout. Tu sais à peine dire "Hola" et "gracias". Mais maintenant, tu vas pouvoir apprendre. Tu vas petit à petit commencer à comprendre, petit à petit arriver à exprimer des idées.
Au début, c'est frustrant et ton billet suinte de cette frustration.
Mais ce n'est pas une critique. Tout le monde passe par là ! Seulement, il y a ceux qui s'accrochent et qui, un beau jour, commencent à trouver les choses faciles et ceux qui se convainquent que c'est forcément le monde extérieur qui a tort et qui devrait s'adapter à eux.
Ploumsalut Ploum, content de te voir passer par la :)
striderJe suis globalement d'accord avec tes deux commentaires, je n'ai pas forcément une grande expérience de la programmation (enfin c'est relatif, j'ai débuté il y a 15 ans quand même) ,ce qui me manque c'est surtout l'expérience de la participation a un code qui n'est pas le mien.
Je ne veux pas que les choses tombent toutes cuites en claquant des doigts, mais simplement avoir quelques outils qui simplifierait cet apprentissage.
Ensuite je met vraiment sur deux plans différents la connaissance de la programmation et la participation a un projet existant. Si dans le cas de Rhythmbox personne ne reprends le projet, c'est qu'il y a effectivement un problème. D'un autre coté si tu as pu soumettre un patch en une heure, alors oui, l'expérience aide bien a mieux si retrouver au sein du code.