Si Linus Torvalds a eu autant de succès avec son projet de noyau Unix libre, c'est autant par sa capacité à gérer les contributions externes (et à les organiser en écrivant git) que par sa compétence de programmeur. Voici donc un tour d'horizon de ce qui pourrait bloquer un débutant désirant contribuer au logiciel libre, aspects techniques mis pour une fois de côté.
1. Premier faux problème : « Mais je parle trop mal anglais ! »
Reconnaissons-le, l'anglais est la langue de l'informatique et celle du logiciel libre. Les deux se sont développés historiquement aux États-Unis et le langage des concepteurs initiaux est resté celui des générations suivantes. Une exception à la règle, le langage Ruby, dont la liste ruby-dev est en japonais.
Pour utiliser Linux et la plupart des logiciels libres, on n'a pas besoin de parler anglais. BSD par exemple c'est une autre histoire, la documentation de référence du système, les pages man et l'installeur n'étant souvent pas traduits par manque de ressources.
Par contre, pour contribuer au logiciel libre en général, il faut pouvoir lire et écrire un minimum d'anglais, la documentation technique et les développeurs utilisant déjà cette langue. Ceci dit, en aucun cas on ne vous demandera un haut niveau d'anglais. Il s'agit avant tout de communication écrite où vous aurez le temps de passer par un dictionnaire. Depuis plus de 10 ans que je lis des listes de discussion, je vois régulièrement des utilisateurs italiens, mexicains, japonais s'excuser par avance de leur faible niveau d'anglais et poster un message clairement compréhensible. Un exemple :
Hello,
I'm from Spain, I can read in english BUT write in english is hard ^^. I'm Debian user, I subscribe to this list because I think in this place can I find people using C/C++ and SDL. ¿Are this right?.
Thanks
Sur une liste de discussion ou un forum web, on vous tiendra rarement rigueur de votre niveau d'anglais, sauf si évidemment vous voulez écrire la documentation technique du projet. Au pire, on vous ignorera, ou on vous conseillera parfois une sous-liste ou un sous-forum en français.
2. Deuxième faux problème : « Je suis timide et j'ai peur de me tromper ! »
Sur les listes de discussion et dans de nombreux wikis, vous remarquerez que le plupart des participants indiquent leur vrai nom, associé à leur adresse e-mail. Ceci donne plus de poids, plus de concret à ce que vous dites. Allez-vous prendre plus au sérieux le mail de speedjunkie.overlordz@yahoo.com ou celui de adam.miskievaciaus@linux.lt quand il va falloir essayer de reproduire un bug complexe dans votre programme ?
Il est évident que Google archivant tout, chacun de vos propos sur une liste de diffusion sera conservé de façon indéfinie. De plus, les listes de diffusion sont archivées souvent en de multiples miroirs et bénéficient d'un page ranking élevé, on pourra donc vite vous y retrouver.
Si vous souhaitez absolument garder l'anonymat vous pourrez toujours vous restreindre aux forums de discussion ou à IRC où le pseudonyme est la règle. Dans certains projets de LL, il existe aussi des sous-projets dédiés aux utilisateurs et développeurs débutants, comme debian-mentors et Linux Kernel Newbies.
Un exemple, un forum de MAME (un émulateur de borne d'arcade) issu de l'expérience de l'auteur : une réponse agressive, mais constructive (le thread complet est visible sur http://ur1.ca/8t5r2).
La proposition :
this patch allows mame to build with a system libjpeg if libjpeg >=8 (patch based on mame 0.145).I think the part concerning sliver.c can be directly integrated in mame.
La réponse du développeur :
That's unacceptable - we are not going to put any of this crap into the drivers. Instead, make it so lib/libjpeg/jpeglib.h includes the system header where appropriate.
Traduction : « C'est inacceptable - on ne va pas inclure ce genre de code de m** dans les pilotes. A la place, modifiez lib/libjpeg/jpeglib.h de façon à inclure les headers système si besoin. »
Enfin, n'oubliez pas que les listes de diffusion et les forums ne sont pas là pour taper sur des newbies impénitents, mais pour coordonner le développement de projets dont les contributeurs sont éloignés géographiquement. Le caractère commun de presque tous les développeurs de logiciel libre c'est qu'ils sont débordés par le temps. Aborder des développeurs en exprimant une liste de souhaits sur ce que d'autres devraient faire *pour vous* est souvent un gage de réponse plutôt directe, que certains pourront considérer comme étant agressive. Il suffit de garder ceci en tête, de rester modeste sans tomber dans l'autoflagellation et tout se passera bien.
Un exemple de mail de l'auteur, qui a mené rapidement au résultat souhaité : trois mails plus tard, la documentation officielle de Postgres était corrigée.
Sujet: SHMMAX runtime setting for Postgres Installation
Date: Thu, 24 Nov 2011 16:57:39 +0100
De: Emmanuel Kasper <emmanuel@libera.cc>
A: tech-kern@NetBSD.org
Hi
http://www.postgresql.org/docs/9.1/static/kernel-resources.html, paragraph NetBSD, implies that setting SHMMAX requires editing the kernel config file and a recompile. But I have seen that setting shmmax with sysctl -w kern.ipc.shmmax=value or via /etc/sysctl.conf works however fine on my system. Is that Postgres Documentation outdated ? Am I missing something ?
Manu
3. Troisième faux problème : « Mais je ne suis pas informaticien ! »
Ici, il importe de dissiper deux mythes : tout d'abord l'écriture du code est loin d'être la seule façon de contribuer au logiciel libre, on peut bien évidemment packager, tester et écrire de la documentation. De nombreux projets de logiciel libre sont assez mal documentés, car beaucoup de développeurs ont un profil codeur pur, et une fois l'exploit technique réalisé, estiment que d'autres peuvent documenter le programme. Un contre-exemple, FreeBSD dispose d'un excellent manuel, le FreeBSD handbook, que bien peu de projets de logiciel libre peuvent se targuer d'avoir. Et nul besoin ici d'écrire du C pour l'améliorer.
Enfin, on ignore souvent que des acteurs clés du logiciel libre n'ont jamais été informaticien de formation.
Eben Moglen, qui a co-écrit les versions 2 et 3 de la GPL avec Richard Stallman est juriste.
Feu Frans Pop, un des principaux porteurs de Debian sur les architectures exotiques ne connaissait que le script shell comme langage de programmation.
Steve Langasek, Release Manager de Debian et d'Ubuntu pendant de longues années, possède une maîtrise de... Portugais et Espagnol.
Enfin, Con Kolivas, auteur de patchs complexes concernant l'ordonnancement sous Linux (il est l'auteur du Brain Fuck Scheduler, utilisé dans les mods Cyanogen d'Android) est ... médecin anesthésiste.
Plus modestement, l'auteur de ces lignes a principalement étudié le contrôle de gestion avant de maintenir un paquet Debian.
Conclusion
S'il existe un réel problème qui peut freiner votre investissement dans le logiciel libre, c'est tout simplement... le temps ! Maintenir un paquet ou être actif sur un projet, cela demande plusieurs heures par semaine.
Encore plus important, il faut souvent être prêt à s'impliquer dans la durée. Si ceci semble rebutant, aucun problème : il existe encore beaucoup de pages de wiki à mettre à jour et de rapports de bugs à confirmer, qui sont des tâches ponctuelles et courtes, et dont chaque projet a besoin !