Introduction
Lorsque nous avons un projet libre en tête, il est possible de le démarrer. Voici quelques conseils afin de rendre ce projet accessible aux contributeurs et aux utilisateurs potentiels.
Créer un dépôt libre
La première étape consiste généralement à créer un dépôt (Git ou autre) public et facilement accessible. L’utilisation de dépôt personnel (sur son propre serveur) a des avantages, mais cache l’existence du projet aux éventuels utilisateurs et contributeurs.
Les plateformes les plus utilisées présentement sont Github et Gitlab. Certains projets plus vieux utilisent SourceForge.
Choisir une licence
La première chose à faire avant de rendre disponible votre code source, c’est de choisir une licence libre pour le projet.
Ce petit site (en anglais seulement) permet de choisir une licence libre. D’ailleurs, une page de ce site permet d’avoir une comparaison détaillée et simple à comprendre de différentes licences libres. Il est par contre important de comprendre que ce n’est qu’un minuscule sous-ensemble de toutes les licences libres qui existent. Vous pouvez regarder ici pour voir toutes les licences libres existantes présentement.
Garder la branche principale propre
Lorsque nous sommes administrateur un projet libre, il est toujours possible que quelqu’un veuille utiliser, compiler ou effectuer un « fork » du projet. Il est donc nécessaire de toujours s’assurer d’avoir une branche principale (« master » ou « main ») fonctionnelle et stable. Lorsque vous faites des modifications substantielles au projet, assurez-vous de travailler dans une branche à part et assurez-vous également de bien tester le projet avant d’effectuer la fusion (« merge »).
Créer un fichier LISEZMOI
Un fichier lisezmoi (ou README) est un incontournable dans un projet libre. Il indique toutes les informations nécessaires pour utilisé ou pour participer au développement du logiciel. En général, ce fichier contient: une description du projet, les auteurs, la licence, les procédures de compilation, l’information de développement (standard, environnement de test, etc.), la mécanique de report d’anomalie (bogue ou ajout de nouvelle fonctionnalité), la façon de contacter les développeurs, etc.
En général, on utilise le langage Markdown pour créer ce fichier.
Créer un ChangeLog
Un ChangeLog est important afin de s’assurer que les développeurs qui participent au développement du logiciel puissent savoir ce qui a été fait comme développement dans les différentes versions du logiciel. Ça peut leur permettre de bien gérer leurs « fork » et également se tenir au courant de la progression du logiciel.
Ce ChangeLog peut également permettre aux utilisateurs du logiciel de savoir s’ils doivent absolument mettre à jour leur logiciel dans les plus brefs délais (pour des mises à jour de sécurité par exemple), ou bien s’ils peuvent attendre que le moment soit opportun pour eux de le faire (pour des ajouts de fonctionnalités par exemple).
Minimalement, un ChangeLog doit contenir les numéros de version du logiciel ainsi que les modifications qui ont été effectuées. Sachez qu’il n’est pas nécessaire d’être très précis. Des informations comme « Correction de plusieurs bogues » ou bien « Ajout de la fonctionnalité X » sont des informations parfaitement valides dans un ChangeLog.
Utilisez un rapporteur d’anomalies (« issue list »)
Afin que les utilisateurs du logiciel puissent informer les développeurs du projet lorsqu’ils trouvent des anomalies (bogues) ou lorsqu’ils pensent à une nouvelle fonctionnalité qui serait intéressante dans le logiciel, il est important de créer un rapporteur d’anomalies (ou « issue list »).
Un bon rapporteur d’anomalie doit être entièrement public (tous les usagers peuvent créer de nouveaux apports, sans être membres du dépôt Git). Il est généralement important d’avoir la possibilité de discuter sur les anomalies et les nouvelles fonctionnalités proposées afin de savoir ce que la communauté du projet en pense. Certains systèmes permettent également d’affecter certains développeurs aux anomalies ou nouvelles fonctionnalités inscrits dans le rapporteur d’anomalies.
Prévoyez un système de communication officielle pour le développement et le soutien
Afin de s’assurer que le rapporteur d’anomalies ne se remplisse pas de simples questions, ou de discussion quelconque entourant le logiciel, il peut être important de prévoir une méthode de discussion autre. Par exemple, plusieurs logiciels libres utilisent des listes de courriels (« mailing list »), d’autres utilisent des salons Matrix, d’autres utilisent des canaux IRC, etc. En général, des systèmes de communication utilisant des standards ouverts sont utilisés, puisque plusieurs utilisateurs de logiciels libres ont cette préoccupation à coeur. Par exemple, si vous décidez que la communication du logiciel se fera avec Facebook, il se peut que plusieurs développeurs ne puissent pas participer aux discussions parce qu’ils ne voudront pas que leurs informations soient utilisées dans un environnement fermé et propriétaire comme Facebook. Il est donc important de prendre cela en considération afin de s’assurer d’avoir un maximum de participation au projet.
Utilisez des outils d’intégration continue
Enfin, une bonne pratique est de créer une suite de tests assez robuste afin et de créer un script d’intégration continue qui fait qu’à l’instant qu’une modification du projet sera envoyée (« push ») sur le dépôt Git (ou autre), ce script validera toutes les compilations et les tests du projet. Si une composante ne compile pas ou qu’un test ne se déroule pas correctement, l’outil d’intégration continue pourra avertir le développeur.
Cet outil est très utile puisqu’il permet à un développeur ayant effectué un « fork » de s’assurer que les modifications qu’il a faites n’a pas brisé le logiciel avant d’effectuer un « pull/merge request ». Donc, le développeur ayant effectué les modifications sauve du temps et le responsable du dépôt officiel sauve du temps. C’est donc gagnant-gagnant pour tout le monde.
Auteur: Louis Marchand
Sauf pour les sections spécifiées autrement, ce travail est sous licence Creative Commons Attribution 4.0 International.