Dans le Libre : faire sien un logiciel

Utilisant uniquement du Logiciel Libre dans le cadre de mes différents projets, qu’il s’agisse du site d’actualité le Journal du hacker, le site d’emploi dédié au Logiciel Libre et à l’open source LinuxJobs.fr ou encore ce blog, j’ai pu constater l’innovation qui découle du travail sur du code libre et les interactions qui se créent avec les communautés du Libre.

Dans la suite de cet article je m’attacherai à décrire les différentes façons dont  on peut “s’approprier” un logiciel. Par s’approprier un logiciel libre, j’entends l’utiliser et le faire sien au point qu’il remplisse exactement nos besoins, en y contribuant ou en bifurquant (fork) sa base de code au besoin.

Je décrirai différentes formes possibles d’utilisation des bases de code présentes dans le Libre, les interactions qui se créent avec leurs utilisateurs et développeurs autour de ces bases de code. Ces utilisations et leurs conséquences seront basées sur des exemples réels et récents.

Utiliser et contribuer en retour

Lorsqu’on découvre un logiciel libre correspondant à nos besoins, il s’en suit souvent une période d’appropriation. Il faut comprendre par ce terme l’essayer et le faire fonctionner dans le but de remplir nos besoins et non plus seulement ceux du créateur du projet, qui peuvent être légèrement différents. Des adaptations sont parfois nécessaires et la documentation est parfois (souvent ?) incomplète ou tout simplement manquante.

Dans mon précédent article Gratter ses propres démangeaisons, j’ai décrit les étapes selon moi essentielles à vérifier avant de commencer à coder un nouveau projet. Dans cet état d’esprit, lorsque j’ai voulu créer le Journal du hacker, un agrégateur de liens communautaire pour le Logiciel Libre francophone, il me paraissait aberrant de devoir ré-écrire moi-même un moteur à la Hacker News, le site le plus connu de ce type.

Ayant trouvé un autre site sur le même principe, lobste.rs, propulsé lui par un logiciel libre sous licence BSD, j’ai commencé à étudier les sources de ce dernier. Et mes premiers tests d’appropriation  m’ont confronté à un important problème : le moteur ne supportait pas les caractères accentués français. Il fallait donc implémenter l’internationalisation du moteur et écrire la localisation française de l’application.

Ma future contribution à la base de code existante était donc toute trouvée 🙂

Bifurquer pour créer

J’ai abordé dans l’un de mes précédents articles le rôle critique de la bifurcation (fork) dans le Logiciel Libre. Elle est en fait essentielle dans la vie d’un logiciel, ce dernier pouvant socialement (et à terme techniquement) dépérir à cause d’un mainteneur absent ou abusivement fermé aux contributeurs extérieurs. La bifurcation assure de redynamiser la vie de la base de code et du projet autour de celle-ci. Cette action a bien sûr des avantages et des inconvénients, abordés dans l’article.

Pour continuer dans notre exemple du Journal du hacker, rares sont les projets aujourd’hui qui peuvent se permettre d’ignorer les réseaux sociaux. Un site d’information visant les Libristes avait de grandes chances de ne jamais se faire connaître sans être présent sur au moins l’un d’eux, afin de se créer un public. De très nombreux Libristes étant présents sur Twitter, j’investiguais les différentes solutions de relayer les informations du Journal du hacker vers le compte Twitter dédié à ce projet.

Je me suis finalement arrêté sur un petit projet à l’abandon, rss2twitter, permettant de poster chaque entrée d’un flux RSS vers le réseau social Twitter. La base de code de rss2twitter était assez simple pour être rapidement relue et comprise.

Grâce à cette base de code existante, il était possible de passer immédiatement l’outil en production tout en y apportant régulièrement des améliorations selon mes besoins. Et cela tombait plutôt bien, dans le cadre de LinuxJobs.fr j’avais exactement le même besoin pour relayer les dernières offres d’emploi postées sur le site vers Twitter.  Le projet Feed2tweet était né.

J’allais au fil du temps apporter à la communauté un nouvel outil auto-hébergé, codé de façon modulaire dans un langage moderne, plus complet que ses prédécesseurs par des fonctionnalités ajoutées seulement en cas de besoin réel et surtout bien documenté pour qu’il puisse être facilement compris et utilisé par la base d’utilisateurs (et d’éventuels contributeurs) la plus large possible. Ce qui s’est avéré payant avec de nombreuses fonctionnalités entièrement codées par des nouveaux contributeurs. Encore une fois, donner et recevoir.

Le choix de basculer vers la licence GPL au lieu de la licence MIT a également permis de maintenir dans le Libre ces innovations et de les protéger là où l’utilisation d’une licence plus permissive aurait permis la réappropriation de ces fonctionnalités par un logiciel privateur, cas de figure proscrit par l’utilisation de la GPL.

Innover pour ruser

Quand vous êtes seul avec votre petit projet face au monde et à l’absence d’intérêt de votre communauté pour un projet balbutiant donc non-mature et pour laquelle le concept peut apparaître dans un premier temps flou, il faut ruser pour se faire connaître, pour attirer des utilisateurs qui seront peut-être de futurs contributeurs, bref pour exister.

Ayant constitué au fil du temps un compte Twitter avec un nombre correct d’abonnés, quasiment tous libristes, j’ai commencé à retweeter à la main les premiers articles relayés sur le Journal du hacker. La mayonnaise a semblé prendre et des abonnés à mon compte ont commencé à s’abonner également au compte Twitter du Journal du hacker.

Rapidement la tâche est devenue chronophage, il était temps de l’automatiser. Après avoir testé des services en ligne horribles par leur lenteur, l’amateurisme de l’interface, et leur envahissement de ma vie privée par le rajout de mentions obligatoires à mes propres tweets, j’ai senti le besoin et donc l’opportunité d’écrire un logiciel simple auto-hébergé répondant à mon besoin. De ce besoin est né le projet Retweet.

La démarche était sensiblement la même que pour Feed2tweet. Codé en Python 3, documenté, présentant des exemples  d’utilisation et ouvert aux contributions, Retweet a peu à peu trouvé son public. Il a été complété au fil des versions par des besoins apparaissant à l’épreuve d’une utilisation quotidienne en production, comme décrit dans mon précédent article Manger ce que l’on prépare.  La dernière version 0.10 a été contribuée à 99% par un nouveau contributeur au projet, je ne me suis chargé que de la relecture des changements, des tests et de la publication de cette version.

Sans être véritablement un cas d’appropriation d’un logiciel existant, innover pour ruser est une démarche de réaction face à la constatation d’un besoin existant et non résolu selon vos besoins spécifiques. Cette approche doit rester au cœur de l’approche d’un problème par le Libriste, d’où sa présence dans cet article.

Les grands axes de l’appropriation

Au cours de cet article nous avons présenté trois types d’appropriation d’un logiciel libre :

• utiliser et contribuer en retour : l’utilisation d’un logiciel, la constatation d’un manque par rapport à nos besoins et l’écriture par soi-même des fonctionnalités manquantes, avec comme but de les reverser un jour au projet amont
• bifurquer pour créer : l’utilisation d’un logiciel dont le projet autour est à l’arrêt, avec la réalisation rapide d’une bifurcation pour améliorer la base de code et relancer le projet pour attirer des utilisations/contributeurs, sans volonté de continuer à avoir des liens avec le projet dont on a bifurqué
• innover pour ruser : l’identification d’une tâche récurrente et la création d’un logiciel pour automatiser la tâche, avec la volonté de répondre à notre besoin tout en fournissant des bases solides pour créer un logiciel ré-utilisable par la communauté qui pourra y contribuer en retour

On peut dégager de ces exemples quelques grands axes d’appropriation : il faut s’assurer de la compatibilité du logiciel avec lequel on souhaite travailler avec nos buts. Il faut également être capable de faire évoluer la base de code pour répondre à nos besoins non-satisfaits. En cas de bifurcation ou de création d’un nouveau logiciel, un grand soin doit être apporté à la documentation et à l’assistance des utilisateurs (qui peuvent devenir des contributeurs) pour assurer que le projet soit suffisamment ouvert à la communauté pour être véritablement attractif. Ainsi armés vos utilisateurs et contributeurs seront à même de vous faire des retours utiles pour débugger votre programme ou en améliorer les fonctionnalités.

Et vous ? comment avez-vous fait vôtre un logiciel libre pour répondre à vos besoins ? N’hésitez pas à laisser votre témoignages dans vos commentaires.