Avec cet article, je veux vous montrer en quoi il est facile de contribuer au logiciel libre, grâce à deux exemples. Le premier ne nécessite aucune connaissance en programmation puisqu’il s’agit d’un apport de traduction. Le second, quant à lui, requiert quelques connaissances en script shell, mais si peu que j’espère que cela restera compréhensible aux yeux de tous. Je donne les grandes lignes sans être exhaustif.

Manque de traduction

La traduction, encore nommée internationalisation (i18n) « localisation » (l10n), est sans doute le plus bel exemple où l’on contribue directement au coeur du logiciel mais sans aucun prérequis de programmation, tout au plus il faudra être sensibilisé à la gestion de projet libre. L’effort de traduction est tout aussi important à mes yeux que le soin apporté à la programmation. Un logiciel mal ou peu traduit fait souvent mauvaise impression et peut aller jusqu’à son abandon pour les nombreux utilisateurs non-anglophones.

L’exemple que j’ai choisi m’est venu lorsque j’ai parlé du logiciel grsync à un ami. grsync est une interface graphique GTK au puissant rsync permettant la synchronisation de répertoires. Après avoir installé la version 1.0.0 (qui s’avère être la dernière version comme l’atteste le site du projet), je vois que certaines phrases (que l’on nomme techniquement chaine de caractère) reste en anglais. Une première chose à se méfier est de penser que ce que l’on a sous les yeux est le dernier avancement du logiciel. Ce n’est bien sûr pas le cas, car des modifications du code peuvent être effectuées tous les jours sans pour autant qu’il y ait de nouvelles versions. Il faut donc aller sur le gestionnaire de version du projet afin de récupérer la version la plus avancée.

La traduction se fait, peu ou prou, de la même manière que ce que j’ai pu décrire dans cet article. Sur le SVN du projet, on ira toujours dans le tronc (trunk) et on va jusqu’au répertoire po et télécharger FR_fr.po. On modifie et on se fait un petit patch. Pour cela, je vous conseille la lecture de cette page par exemple. Je n’ai personnellement pas utilisé cette méthode, j’ai préféré git, mais on n’est pas obligé d’aller jusque là.

Voila le résultat.

Correction d’un bug logiciel

Attaquons nous maintenant à la correction d’un bug sur un logiciel. L’idée m’a été soufflée par une conférence de Parinux sur la distribution légère Slitaz. Lors d’une démonstration (c’est toujours comme ça ), le conférencier a voulu ouvrir le gestionnaire de paquet et a entré un mot de passe erroné. Après validation, rien ne s’est passé. Après une dizaine de secondes, il s’est souvenu avoir changé le mot de passe et a pu ouvrir le gestionnaire de paquet. On a là un bug manifeste, l’utilisateur aurait dû être prévenu de l’erreur sur le mot de passe. Les gens qui ont fait un peu de programmation dans leur vie sentent de suite que c’est un cas non géré, un type de bug fréquent.

L’avantage pour cette démonstration est que le site est partiellement en français car le créateur est suisse. On arrive alors sans trop de peine à la partie développement. On a remarqué que le programme portait le doux nom de subox, et une petite recherche nous montre que dans slitaz-tools/tinyutils on retrouve le code source de subox.

On récupère le code et on va donc chercher à corriger le bug. La ligne qui attire mon attention est celle-ci :

<action>echo $PASSWD | su -c "$SU_CMD" &</action>

On remarque alors qu’en cas d’échec, rien n’est prévu. Je propose donc de la remplacer par ceci :

<action> if [[ $(echo $PASSWD | su -c "$SU_CMD" &) ]]; 
then gtkdialog --center --program=ERROR_DIALOG;fi;</action>

où ERROR_DIALOG est une fenêtre qui comporte le message d’erreur. Je passe le détail de la création de cette fenêtre, tout est dans le rapport de bug, et un simple coup d’oeil sur le premier tuto gtkdialog ou la lecture d’autres scripts de la distro permet d’écrire sans problème ce morceau de code. Une fois mon fichier modifié, j’en ai crée un patch.  Le code étant petit, j’ai ajouté le programme complet en fichier attaché.

Le rapport final est disponible là, en attente d’un dev pour correction

Je n’ai pas la prétention que le patch soit idéal ou parfait. Sans doute ne respecte-il pas la politique de la distribution que je ne connais pas, mais quand bien même cela ne plairait pas aux développeurs, cela leur montrera très clairement le problème et une possibilité de résolution. Ceci accélérera dans aucun doute la résolution du bug.

Bien sûr, parfois on n’arrive pas à corriger le bug. On peut avoir qu’une piste voir rien du tout… nul n’est parfait. Dans tous les cas, il faut toujours ouvrir un rapport et indiquer les éventuelles pistes.

Conclusion

Les contributions au logiciel libre peuvent se faire sans connaissances particulières : écriture de documentations, entraide sur les canaux de communication, animations de manifestations… mais on peut avoir envie d’aller plus loin, de découvrir les rouages du moteur.

J’espère ainsi avoir montré, via ces deux exemples, en quoi il est possible de contribuer au code d’un logiciel libre soit sans connaître un langage ou soit sans être un codeur fou. Par contre, il est vrai qu’il faut être un peu familier de la gestion des projets et des outils associées (sourforge, svn, mercurial…), suffisamment pour savoir s’y repérer et récupérer un bout de code. Il existe pléthore de petits logiciels et de petits projets qui ne demandent que ce type de contribution.

Bref, si vous hésitez, même si vous pensez ne pas être à la hauteur, foncez ! Il n’y a pas de petites contributions. L’aventure est extraordinaire, on apprend plein de choses, c’est très enrichissant. En espérant vous avoir convaincu…