Comment contribuer à un logiciel libre ?

Que vous sachiez développer ou non, vous pouvez contribuer !

Vous utilisez tous, tous les jours, du logiciel libre. Si, si.

Ce n’est pas toujours bien visible, mais de nombreux logiciels sont en fait des logiciels libres, ou sont au moins bâtis sur des technologies mises à disposition sous une licence libre. Et si vous ne me croyez pas, sachez que vous êtes en ce moment même en train d’en utiliser un pour lire ces quelques mots : Zeste de Savoir est en effet distribué sous la licence GNU GPL version 3 ou ultérieure, et son code source est disponible à toutes et à tous sur le dépôt GitHub officiel du projet.

Or, qui dit logiciel libre, dit que tout le monde peut y participer. Ce n’est qu’une question de temps et d’envie. Même pas besoin de savoir écrire la moindre ligne de code pour cela. Mais alors, comment faire ?

Nous allons voir dans cet article qu’il existe bien plus de façon de contribuer à un logiciel libre, quel qu’il soit, que de "simplement" contribuer à son code directement. Vous êtes prêts ? Alors, allons-y ! :pirate:

Le logo de cet article est mis à disposition sous la licence Free Art License 1.3 par Vladimir Tsarkov. Retrouvez l’image originale sur le site du projet GNU.

Ce qu'il ne faut pas faire

Avant de parler de ce que vous pouvez faire, il va me falloir enfoncer une ou deux portes ouvertes pour vous faire part de quelques comportements souvent perçus comme indésirables, que vous ne devriez pas adopter. Ne vous inquiétez pas, rien de bien méchant, mais c’est toujours bon à rappeler. ;)

Demander quand ça sort

Un logiciel libre est très souvent maintenu par des gens qui le font sur leur temps libre. En effet, peu d’entreprises donnent des moyens à leurs salariés pour leur permettre de développer un projet libre sur leur temps de travail, et souvent, quand c’est le cas, c’est parce qu’elles peuvent en tirer un profit.

Pour cette raison, il est souvent assez mal vu de demander aux mainteneurs d’un logiciel libre (quel qu’il soit), quand sortira telle nouvelle version, ou encore quand une nouvelle fonctionnalité sera mise à disposition, ou même quand un bug sera résolu. Tout simplement parce que cela dépend du temps dont dispose les mainteneurs pour gérer le projet. Dites-vous que cela embête autant les développeurs que vous qu’un bug puisse exister, et que ça les embête encore plus de ne pas savoir quand ils pourront y remédier. Leur demander ce genre d’information, aussi innocent soit-il, ne fait que leur apporter de la pression inutile.

Pire, n’intimez jamais aux contributeurs de prendre en charge votre problème en priorité, et n’imposez jamais de deadline. C’est le meilleur moyen pour votre ticket d’être rangé dans la catégorie futur lointain et pour vous d’être banni à vie du projet.

Parfois, les mainteneurs proposent une feuille de route (roadmap) pour donner de la visibilité à plus ou moins long terme. Si elle est absente, c’est qu’ils ne souhaitent pas (ou ne peuvent pas) communiquer de date.

Être désagréable

Cela peut sembler évident, mais n’oubliez jamais de rester cordiaux lorsque vous remontez un bug. Même si ce dernier vous impacte beaucoup. Gardez en tête que ce sont des humains qui traitent les tickets, et qu’ils le font parce qu’ils aiment le projet autant que vous. Se montrer insultant ne rend service à personne, pas même à vous.

Notez que la plupart des projets libres possèdent maintenant un code de conduite, qui rappelle ces règles. Celles-ci s’appliquent bien sûr également aux mainteneurs eux-mêmes, pour éviter des situations désastreuses comme celle qu’a connue il y a quelques années le projet Linux, dont le fondateur a dû se retirer quelques mois suite à des plaintes sur son comportement auprès de nombreux contributeurs.

Des contributions techniques

Écrivez du code

Cela ne surprendra sûrement personne, et même si cet article se veut une ressource montrant d’autres moyens de contribuer, il serait stupide de ma part de ne pas rappeler cette évidence : un des meilleurs moyens de voir avancer un projet libre qu’on aime, c’est encore d’écrire du code. Si vous avez des connaissances techniques, n’hésitez pas à le faire. Si vous n’êtes pas habitué à contribuer à un logiciel libre, n’hésitez pas à demander de l’aide. Les mainteneurs seront toujours ravis de vous aider à ouvrir votre première pull request !

Souvent, les sources d’un projet comportent un fichier nommé CONTRIBUTING qui explique comment prendre en main le projet, installer ses dépendances et comment écrire sa contribution, donc pensez à bien le lire !

Vous voulez aider au développement, mais vous ne savez pas par quoi commencer ? Jetez un œil aux tickets ouverts ! Les plus "faciles" pour se lancer1 possèdent souvent le badge good first issue pour signaler qu’elles peuvent être prises en charge par des personnes qui souhaitent faire leurs premières armes sur le projet avant de se lancer sur des choses plus complexes.

Signalez les bugs

Un problème souvent rencontré par les mainteneurs est la tendance que peuvent avoir les utilisateurs à rester silencieux sur les bugs qu’ils peuvent rencontrer. Peut-être par peur de passer pour un casse-pied, ou même par habitude de rester passif, comme l’imposent bien des logiciels propriétaires. Parfois, simplement parce qu’ils ne savent pas comment faire.

Certains logiciels libres proposent un moyen de signaler un bug directement depuis l’application elle-même (via le menu Aide), mais ce n’est pas toujours le cas. Le plus simple pour savoir comment signaler un bug est encore de rechercher l’information sur le site officiel du projet.

Vous ne parlez pas anglais ? Recherchez un forum consacré au projet dans votre langue et demandez de l’aide ! Les plus gros projets libres sont souvent supportés par des communautés dans des langues diverses, et possèdent un forum dédié à cela. Leurs membres se donneront une joie de vous aider !

Testez les bêtas, ou même les alphas

Souvent, les moyens ou le temps des mainteneurs ne leur permettent pas de tester le projet sur toutes les machines qu’ils voudraient. Que vous utilisiez un système ésotérique ou non, pris en charge ou non, testez-le sur votre machine !

Une nouvelle bêta, ou même une alpha, est publiée ? Testez-la !

Vous savez compiler un logiciel ? Clonez le dépôt, compilez le programme et testez-le !

Vous remarquez un comportement étrange pendant vos tests ? Un plantage ? Signalez-le !

  1. Évidemment, tout est relatif, selon le projet et votre expérience dans la technologie. N’allez pas croire que les tickets annotés "faciles" sur le projet Linux le seront autant que celles du framework Symfony, par exemple ! :P↩

Des contributions pas trop techniques

Traduisez le projet

Le projet n’est pas disponible dans votre langue, ou la traduction comporte des coquilles ? Vous comprenez bien l’anglais, et vous souhaitez proposer une traduction dans une langue actuellement non prise en charge ? Le moment est venu de proposer une traduction !

La plupart des logiciels libres sont traduits par leur propre communauté. La façon dont il faut s’y prendre varie beaucoup : cela peut aller de la simple modification de fichiers directement dans les sources du projet, à l’utilisation d’un outil dédié.

Si vous avez envie de traduire un logiciel, mais ne savez pas lequel, vous pouvez aussi rechercher des projets sur Weblate, un service (libre, on ne se refait pas !) de traduction communautaire très populaire dans le milieu.

Parlez du projet autour de vous

Cela peut paraître étrange de le rappeler, mais un logiciel vit avant tout grâce à sa communauté. Et il n’y a rien de plus satisfaisant pour ses mainteneurs que de voir les membres de cette communauté en parler autour d’eux.

Les logiciels libres n’ont généralement pas la force de frappe de beaucoup de logiciels propriétaires, qui gagnent plus rapidement leur base utilisateurs grâce à la publicité déployée par les entreprises qui les vendent. C’est ce qui fait, par exemple, que si vous faites de la photographie, vous aurez probablement déjà entendu parler d’Adobe Lightroom, mais peut-être pas de darktable.

Soutenez le projet financièrement

Pour maintenir un logiciel libre, il faut du temps. Et comme disait Benjamin Franklin, le temps, c’est de l’argent. C’est d’autant plus vrai aujourd’hui.

De nombreux mainteneurs manquent cruellement de temps pour travailler sur le développement du logiciel libre qu’ils adorent. Pire, parfois, ils doivent même investir régulièrement dans du matériel (c’est souvent le cas des mainteneurs de pilotes libres).

Ces besoins amènent de plus en plus souvent les mainteneurs à ouvrir des campagnes de dons, afin de financer leurs projets. Ils n’ont généralement pas de gros besoin, mais cela leur permettrait souvent de travailler dans de bien meilleures conditions, sans se préoccuper de s’ils pourront manger à la fin du mois.

Le financement est donc un excellent moyen d’aider un projet que vous aimez à s’améliorer. Bien entendu, ne le faites que si vous voulez et pouvez vous le permettre !

Si vous ne trouvez pas de page de financement pour le projet que vous souhaitez soutenir, n’hésitez pas à aller jeter un œil par exemple sur Liberapay (qui est aussi un logiciel libre, décidément !), ou même sur le dépôt de code du projet.

Je maintiens un logiciel libre, comment appeler à contribuer ?

Vous développez un logiciel libre, mais vous peinez à avoir des contributions sur celui-ci ? Il existe de nombreuses façons d’appeler les personnes à contribuer, voyons lesquelles pourraient vous convenir !

CONTRIBUTING : un fichier pour les gouverner tous

Une des méthodes les plus simples pour informer vos potentiels contributeurs sur les diverses façons de contribuer est de créer un fichier expliquant comment faire. Par convention, on le nomme généralement CONTRIBUTING ou CONTRIBUTE.

Certains projets comme Linux, ont fait le choix d’un autre nom de fichier comme MAINTAINERS. Peu importe, le tout est d’avoir un fichier à disposition afin de donner les premières billes à vos futurs contributeurs pour installer le projet sur leur machine et commencer la bagarre. Cela peut même se trouver dans le fichier README si ça vous chante !

Mettez-y tous les moyens possibles de contribuer, que ce soit en terme de code ou non (un peu comme ce que je fais dans ce guide), cela aidera vos futurs contributeurs !

Ouvrez des tickets de tâches à venir

Si vous avez prévu des tâches bien spécifiques à réaliser sur votre projet, ouvrez des tickets sur votre bug tracker afin de permettre à tout le monde de voir ce que vous aimeriez faire. Ainsi, si une personne ayant des capacités techniques passe par là, elle pourra piocher dans la liste et réaliser la tâche pour vous.

Pensez également à annoter vos tickets à l’aide d’étiquettes afin de préciser la nature de votre ticket : s’agit-il d’un bug ? d’une amélioration fonctionnelle ? d’une optimisation ? Sur GitHub, il est également courant d’ajouter une étiquette good first issue ("bon ticket pour démarrer") pour informer que votre ticket est un bon départ pour une première contribution. N’hésitez pas à l’utiliser pour tout ticket demandant seulement de faibles compétences.

Ces conseils ne sont que quelques uns des moyens les plus courants de contribuer un logiciel libre. Comme vous pouvez le constater, la plupart d’entre eux consistent surtout à donner un peu de son temps pour faire du logiciel que vous aimez un logiciel encore meilleur. Bien d’autres méthodes existent, parfois même des moyens auxquels les mainteneurs n’avaient pas pensé.

Soyez créatifs !

Ces contenus pourraient vous intéresser

18 commentaires

Merci pour cet article très utile !

Juste pour préciser un fait assez peu connu : « logiciel libre » ≠ « logiciel ouvert aux contributions ». D’ailleurs, le côté « ouvert aux contributions » ou « développement communautaire » n’est présent dans aucune définition formelle du logiciel libre, que ça soit celle de l’EFS ou de l’OSI par exemple.

Ce qui est le plus souvent refusé, c’est la contribution directe au code (la possibilité de fork, créer un clone du logiciel avec ses propres modifications et diffuser cette version, est autorisée par les licences libres). C’est aussi fréquent, sur les petits logiciels, qu’il n’y ait pas de possibilité de traduction ou de soutien financier. Par contre on ne vous interdira jamais de parler du projet autour de vous :)

La raison est tout simplement que si on accepte les contributions tierces, il faut les gérer, et ça prends du temps et de l’énergie… par exemple, le jeu Shattered Pixel Dungeon est un jeu multiplateformes libre (GPL v3), fork d’un autre projet (Pixel Dungeon) lui-même libre, mais tous deux non communautaires.

Je rajoute aussi que les développeurs sont les maitres sur leurs projets. Soyez polis, ne demandez pas « quand est-ce que ça sort »… et ne remettez pas en cause leur façon de fonctionner. S’ils utilisent une pile logicielle et des outils qui vous paraissent étranges, respectez-le : c’est leur fonctionnent sur leur projet, qu’ils font souvent sur leur temps libre. Si vraiment vous êtes persuadé qu’ils pourraient gagner beaucoup à changer quelque chose… posez d’abord la question avant d’arriver avec une « solution » toute prête.

+8 -0

Bel article, merci !

Un autre moyen de contribuer à un projet est d’écrire de la doc.
Je ne sais pas comment ça se transpose dans un projet open-source puisque je n’ai pas eu ce réflexe sur mes maigres contributions, mais sur des projets pro auxquels j’ai participé, j’ai profité de mon temps d’intégration où j’appréhende le projet pour noter comment j’ai installé l’environnement, ce que j’ai compris de l’archi, etc… ça m’a permis de me concentrer en formalisant ce que j’apprenais, ça a permis aux collègues de me confirmer que j’avais bien compris ou non, et ça a permis au projet d’être plus complet et approchable. J’ai trouvé que c’était une bonne idée que l’on m’avait suggéré, même si évidemment la doc, c’est pas très glamour.
Ce n’est pas possible sur tous les projets évidemment, certains ne donnent pas l’accès aux docs, où ont des docs suffisamment poussés pour que ce soit difficile de compléter, mais des fois les docs sont présentes dans le dépôt source ou sur un dépôt connexe et il est possible d’y contribuer, c’est un peu moins technique que le code et ça permet d’avoir une bonne vision pour s’y plonger après.

+6 -0

Merci, c’est très bien d’écrire des articles sur ce sujet.

Une petite remarque de forme: l’enchaînement du premier titre et du deuxième sous-titre donne: "Ce qu’il ne faut pas faire > Restez poli". On dirait qu’il ne faut pas rester poli. Le sous-titre gagnerait à être reformulé ("Être désagréable" ?), et le verbe devrait être à l’infinitif.

+1 -0

Merci pour vos retours et vos conseils supplémentaires :D

Merci, c’est très bien d’écrire des articles sur ce sujet.

Une petite remarque de forme: l’enchaînement du premier titre et du deuxième sous-titre donne: "Ce qu’il ne faut pas faire > Restez poli". On dirait qu’il ne faut pas rester poli. Le sous-titre gagnerait à être reformulé ("Être désagréable" ?), et le verbe devrait être à l’infinitif.

gasche

Tu n’es pas le seul à m’avoir fait cette remarque, je vais faire la correction, merci. :)

+0 -0

Et les contributions au support utilisateur, à la communication/promotion, à l’organisation administrative, à l’entretien des infrastructures numériques du projet, à l’organisation d’événements autour du projet… On ne peut pas tout couvrir dans un seul article, et ça ne serait pas forcément très digeste.

+2 -0

Certes, mais je trouve dommage d’oublier qu’un logiciel c’est une partie programmation et une partie graphisme. Graphismes qui ont tendance à être oubliés alors que c’est un problème majeur du logiciel libre depuis un moment, en termes d’attrait et d’ergonomie des logiciels. Cette dernière ergonomie qui en plus permettrait de réduire le besoin ed support utilisateur ;)

+0 -0

Moui; tous les logiciels n’ont pas forcément une interface graphique, et tu mélanges des choses assez différentes, le graphisme d’une part (illustrations, icônes etc.) et l’ergonomie / expérience utilisateur de l’autre. (Peut-être que tu utilises le graphisme pour parler en général de design ? Ou alors tu penses à des domaines spécifiques comme le jeu vidéo ?)

+0 -0

Trop souvent, on perd à l’esprit que l’on aborde une culture dans le domaine informatique. On ne perçoit plus, sauf les caractéristiques. En cela, je ne suis pas vraiment d’accord avec cet article.

lion_de_mer

Le logiciel libre est en effet associé à une culture passionnante, qui mériterait d’y dédier un article entier (en fait, il semble qu’il y ait eu un projet dans ce sens, mais il n’a pas abouti).

Dans cet article, je cherchais plutôt à montrer que contrairement à ce qu’on a naturellement tendance à penser, les faire vivre ne consiste pas seulement à écrire du code :)

+1 -0

@Deuchnord: Ce qui est exaspérant c’est que la perception du sujet aurait pu être neutre. En lisant l’article, j’ai parfois l’impression de passer à côté du sujet.

Que faire si cela ne fonctionne pas ? Comment utiliser cela ? Que puis-je faire avec ?

En se posant les bonnes questions, on se rend bien compte que cela concerne toute chose. Or, dans les propos des gens (en reprenant leurs termes), je ne m’y reconnais plus. Citons notamment : libriste, extrémiste, politique, philosophie, idéologie, caricature, stéréotype, pragmatique, laxiste, etc. Néanmoins il faut poser des mots pour se faire entendre. C’est juste navrant lorsque les gens empruntent systématiquement des termes qu’ils ne maîtrisent pas bien.

+0 -0

@Deuchnord: Le problème c’est qu’on assimile le logiciel principalement à la notion de liberté, via la personnification « logiciel libre ». L’erreur est de ne considérer le logiciel que de ce point de vue. À l’inverse, il faut bien comprendre comment est développé un logiciel afin de déterminer s’il faut s’investir.

Il faut généraliser au système d’exploitation parce que ces problématiques sont imbriquées ou corrélable. Le projet GNU ne reconnaît d’ailleurs que les distributions GNU/Linux entièrement libres. Sinon, on est dans une vision purement utilitaire. C’est en cela qu’on parle de philosophie du logiciel libre (ou encore, mouvement du logiciel libre, ou bien, développement communautaire) sauf que ce n’est pas particulier au logiciel.

+0 -0

Salut,

ton message reste un peu cryptique, néanmoins, justement, je pense que la majorité des personnes ici sait très bien comment un logiciel peut être créé. Je dirais même qu’on a tous ici plusieurs expériences de méthodes de développement qui sont très différentes.

La "philosophie" libre peut être étendue à d’autres domaines (dont l’art, on a même des billets à ce propos) mais c’est pas du tout le sujet de l’article ici présent.

Il existe aussi une dimension utilitaire au développement de logiciels. Savoir comment une personne qui a envie d’aider peut le faire est en soi important, et probablement plus que "c’est quoi la pureté idéologique du libre?".

+0 -0

@artragis: Ce que j’ai dit n’est pas forcément très constructif. Néanmoins, il semblerait que vous m’ayez mal compris.

On assimile le logiciel principalement à la notion de liberté, et l’erreur est de ne considérer le logiciel que de ce point de vue. Dès lors, on perçoit essentiellement les caractéristiques du logiciel libre. Or ces caractéristiques ne sont pas intrinsèquement liées au logiciel, cela dépend d’autres facteurs.

Par conséquent, peut-on véritablement considérer qu’il s’agit d’un abus de langage ?

lion_de_mer

C’est d’ailleurs là la séparation existante entre « open source » et « logiciel libre ».

Par conséquent, les gens du mouvement du logiciel libre et du camp de l’open source travaillent souvent ensemble sur des projets concrets comme le développement logiciel. Il est remarquable que des points de vue philosophiques tellement divergents puissent si souvent motiver des personnes différentes à participer aux mêmes projets. Néanmoins, il y a des situations où ces vues fondamentalement différentes mènent à des actions très différentes.

En quoi l’open source perd de vue l’éthique du logiciel libre

+0 -0

Notons quand même que la position de la FSF ou du projet GNU sont des positions spécifiques et plutôt extrêmes, et qu’ils n’ont pas le monopole sur la définition de logiciel libre. Entre autres limites, leur approche du libre en-dehors du logiciel est très parcellaire.

+0 -0

@SpaceFox: Lisez donc l’article « Au-delà des licenses libres ? ». Cette réflexion de Bastien Guerry, hackeur Emacs, travaillant à l’intégration du logiciel libre dans l’administration française, illustre bien la problématique suscitée en filigrane. Sinon, on n’est pas d’accord : je considère également que le rôle de ces organisations cadre essentiellement au logiciel (GNU is Not Unix, Free Software Foundation) et que l’on est dans une posture réaliste (ni particulière, ni radicale).

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte