Dans le Libre : gratter ses propres démangeaisons
Je commence avec cet article une série de billets intitulée « Dans le Libre » afin de mettre en avant certaines bonnes habitudes à avoir lorsqu’on évolue dans le milieu du Logiciel Libre, toutes issues de mon expérience personnelle 
N’hésitez pas à compléter dans les commentaires.
Lorsqu’on est développeur du Libre, que l’on est attaché à cette communauté et donc que l’on souhaite évoluer et participer à ce mouvement, il est important de gratter ses propres démangaisons. Qu’entend-on par là ? À partir d’un exemple concret nous allons présenter les différentes étapes qu’un Libriste va suivre dans le processus visant à gratter ses propres démangeaisons.
Identifier le besoin
Disons que pendant vos heures de travail, vous devez opérer la même tâche plusieurs fois par jour. Une fois cette contrainte identifiée, comment allez-vous réagir ? Un développeur du Libre, aimant consacrer son temps à troller sur le Journal du hacker ou LinuxFR cherchera naturellement au bout d’un moment à automatiser la tâche en question.
La tâche est moins triviale qu’il n’y paraît. En effet certaines tâches sont difficilement automatisables, par leur complexité et vont requérir de subdiviser la tâche elle-même en de nombreuses sous-tâches afin de réussir l’automatisation. L’identification du besoin se double d’une définition des étapes nécessaires à la réalisation de l’automatisation de la tâche en question.
Lorsque j’ai fondé le Journal du hacker, je répondais à un besoin simple : il n’existait pas à l’époque de site d’information de partage de liens orienté Logiciel Libre, communautaire et francophone, à la Hacker News pour les anglophones. En présentant ce besoin à mon entourage, j’avais à chaque fois confirmation de la situation et du besoin qui en découlait. L’idée paraissait donc prometteuse.
Le Journal du hacker, un projet communautaire issu d’un besoin clairement identifié
La recherche de la solution et réutiliser l’existant
Une fois le besoin identifié, le Libriste doit d’abord chercher une solution existante. Coder bille en tête un nouveau programme est 99% du temps une erreur. En effet coder un nouveau programme implique :
- un investissement en temps important pour arriver à la première version fonctionnel
- un investissement en temps pour chaque évolution nécessaire
- un investissement en temps pour la maintenance du programme
- un investissement en temps pour l’industrialisation de la distribution du programme
Pour en revenir à notre exemple, on peut commencer par chercher un logiciel qui permet d’effectuer la tâche en question et lancer le logiciel de façon automatisée aux heures auxquelles cette tâche doit être exécutée. Il est donc nécessaire d’effectuer une recherche sur les solutions déjà disponibles parmi les logiciels libres pour effectuer la tâche en question.
Une bonne recherche sur Github vous fera gagner beaucoup de temps
Typiquement les tests des différentes solutions seront effectués lors de cette étape pour :
- vérifier que les solutions trouvées marchent (la seule existence d’un dépôt Github parlant de votre problème ne garantit pas que le programme proposé fonctionne ou fonctionne dans votre cas précis)
- choisir la plus adaptée à votre besoin. Confronter à l’utilisation d’un programme commercial, à un service en ligne ou à un petit script à héberger vous-même, il vous reviendra d’évaluer de manière intelligente la solution qui se maintiendra la mieux dans le temps selon vos contraintes
Un excellent exemple de ce réflexe que doit avoir le Libriste est le projet Feed2tweet, petit projet qui récupère un flux RSS pour l’envoyer vers Twitter. Feed2tweet a divergé depuis rss2twitter , à l’abandon depuis 2 ans. Mais rss2twitter était codé en Python, un langage que je maîtrise, sous licence MIT, fonctionnait bon gré mal gré et avait une base de code lisible. Il suffisait donc dans un premier temps de le faire évoluer et de le documenter. Une grande partie du travail nécessaire pour créer un logiciel ex nihilo a ainsi été économisé.
Feed2tweet, un projet peu coûteux au démarrage en temps de travail grâce aux facilités offertes par le Logiciel Libre
Un nouveau projet est né
Mais parfois vous défrichez une terre inconnue. Vous êtes le premier à ressentir un nouveau besoin. Ou alors personne n’a pris le temps d’automatiser la tâche qui vous oblige à intervenir manuellement. Qu’à cela ne tienne, vous êtes un programmeur ou vous souhaitez le devenir et vous allez vous y coller. C’est l’exemple parfait de gratter ses propres démangeaisons.
Vous vous lancez donc dans l’aventure. C’est la grande excitation d’écrire un bout de code sans précédent.
Quelques conseils pour les débuts de votre nouveau projet :
- Il est nécessaire d’arriver rapidement à un premier résultat, pour commencer à combler votre besoin et vous encourager à poursuivre dans votre démarche
- Rendez public votre projet dès la version 0.1. Cela vous permet de vous inscrire dès le début de votre projet dans l’optique d’un projet du Logiciel Libre et de confronter immédiatement votre travail à l’avis de la communauté. Cela n’est pas toujours facile (voire souvent difficile), nous y reviendrons dans un article ultérieur.
- Soignez la présentation de votre projet et sa communication dès le début ! J’insiste sur ce point, Il vous faut dès la première version une documentation claire, des exemples percutants du besoin que comble votre programme et de son utilisation ainsi qu’une communication aussi large que possible (sites communautaires, réseaux sociaux). Ces différents éléments sont des conditions sine qua none à l’arrivée de potentiels contributeurs, intéressés par votre projet
J’insiste sur ce dernier point. Considérez votre programme comme non-abouti et non-présentable tant que votre documentation n’est pas écrite et qu’un plan minimal de communication n’est pas prévu. À ce stade, la fiabilité du programme et ses fonctionnalités sont moins importantes que son image publique. C’est de toute façon la première version, personne ne s’attend à un programme stable. Par contre les gens attendent une présentation claire des buts de votre projet.
Lorsque j’ai écrit Retweet, un outil pour retweeter automatiquement selon de nombreux critères, j’ai eu conscience que l’intérêt du programme pouvait être mal compris. J’ai donc soigné dès le début la documentation du projet ainsi que la communication. Aujourd’hui avec une cinquantaine d’étoiles sur Github, 8 versions et 3 contributeurs, Retweet est un projet qui vit sa vie car il comble un besoin correctement décrit et que son utilisation est efficacement documentée avec une communication régulière via les sites communautaires, mais aussi via Twitter et Diaspora*.
Savoir communiquer autour de son projet est aujourd’hui crucial
Gratter ses propres démangeaisons mène à manger ce que l’on prépare
Vous avez donc créé un nouveau projet qui comble pour l’instant votre besoin. Mais très rapidement combler ce premier besoin a mener à en découvrir d’autres. Vous avez besoin de nouvelles fonctionnalités, de flexibilité dans l’utilisation de votre programme afin de gérer davantage de cas d’utilisation et vous permettre de continuer à diminuer le temps consacré à la tâche d’origine.
Vous découvrez donc de nouveaux besoins en utilisant votre propre programme. C’est ce qu’on appelle en anglais « Eat Your Own Dog Food » (manger sa propre nourriture pour chien). Et le détail de ce processus bien plus complexe qu’il y paraît au premier abord et les conséquences qu’il a sur votre projet seront abordés dans le prochain article de cet série 
Et de votre côté ? Avez-vous comblé vos propres besoins par la création d’un projet du Logiciel Libre ? N’hésitez pas à en parler dans les commentaires !
