Aujourd’hui, j’ai pensé faire quelque chose de légèrement différent et discuter un peu sur les attentes que l’on peut avoir à rendre son code public.
Je me suis dit qu’il serait intéressant d’interviewer un membre de notre groupe qui possède une solide expérience dans ce type d’activité, Tariq Daouda, afin de tirer profit de ses expériences passées.

Alors, sans plus attendre, on se jette à l’eau !

JP:
Bonjour Tariq, je suis bien content que tu aies accepté cette invitation. Je pensais te poser quelques questions en rapport avec ce qui peut se produire lorsque l’on décide de rendre de son code (une librairie, un plugin ou peu importe) public. Ceci dans l’espoir que nos lecteurs acquièrent une meilleure compréhension des enjeux soulevés par cette activité.
T:
Ça me fait plaisir d’être ici et de partager mon expérience !

JP:
Super, nous nous concentrerons sur trois de tes projets, disponible publiquement depuis ton dépôt GitHub. Notamment: pyGeno, Mariana et pyArango. Puisque les trois librairies s’adressent à des auditoires différents, nous devrions pouvoir faire abstractions des préoccupations spécifiques à un auditoire donné.
Quelle était ta motivation principale à partager ta première librairie ?
T:
Hmmm.. C’est une bonne question…
Je crois, et ceci se rattache à pyGeno spécifiquement, que je savais d’emblée que je désirais écrire une publication scientifique autour de cette librairie. Et puisqu’un des pré-requis à une publication de ce type est le partage de la ressource dans le domaine public, je me suis dit que je serais aussi bien de m’acquitter de cette tâche tout de suite. J’avouerai que je voulais aussi m’assurer que ma librairie soit à la hauteur de mes attentes en terme de simplicité d’utilisation, alors obtenir un peu de rétroaction de la part d’autres usagers faisait définitivement partie de mes motivations. Finalement, il m’apparaissait pertinent que d’autres fassent usage de ma librairie dans un contexte différent de celui dans lequel je l’utilisais, moi. De cette façon, je trouverais peut-être quelques anicroches dans le code qui, autrement, seraient passées inaperçues !

JP:
Bien sûr ! Car on sait tous ce qui se produit quand on met notre code dans les mains de quelqu’un d’autre… S’il y a un défaut quelque part, il est instantanément découvert!
Donc un mélange de rétroaction et de débuggage… Intéressant !
Parlons popularité, GitHub offre deux métriques qui permettent de juger de la popularité d’un projet: les étoiles et les « fourches » (forks). Laquelle préfères-tu et pourquoi ?
T:
J’aime vraiment les étoiles ! Mais bon, j’aime aussi les forks… Tant qu’ils donnent lieu à des pull requests.

JP:
Ouais, car sur GitHub, la seule façon de soumettre des modifications au code d’un « dépôt » (repository) pour un usager qui n’a pas accès au dépôt original est de fourcher le projet, modifier la fourche et ensuite l’utiliser pour générer un pull request.
T:
Exactement. J’aime vraiment recevoir des pull requests ! Étonnamment, Mariana n’a pas généré beacoup de pull requests.. J’en ai reçu plus pour pyGeno et pyArango. Je suspecte que la nature des usagers impacte grandement leur relation aux librairies. Par exemple: j’ai reçu bon nombre de PRs pour pyArango de la part de membres de l’équipe de développement d’ArangoDB.

JP:
Ha ! J’imagine qu’ils voient ta librairie d’un très bon oeil 🙂
T:
N’est-ce pas ?! 🙂
Mais pour ceux qui ne font que fourcher mes projets, je crois que plusieurs finissent par oublier l’existence du projet… C’est pour ça que je préfère les étoiles.

JP:
Et dirais-tu que tu as perçu une forme d’appropriation de ton code par les usagers ?
T:
Définitivement ! J’ai reçu bon nombre de requêtes d’ajout de fonctionnalités, certains usagers ont corrigé des coquilles dans la documentation de pyGeno et d’autres ont mis à jour pyArango afin qu’il supporte la nouvelle version de l’API d’ArangoDB. Mais le meilleur exemple d’appropriation que j’ai vu a été la mise en place des procédures d’Integration Continue (Continuous Integration) pour Mariana et pyArango. Des gens ont pris le temps nécessaire pour en faire la mise en place et ont ensuite soumis un PR.. Ce niveau d’implication m’a vraiment surpris !

JP:
Incroyable, alors le code s’est bel et bien mis à vivre par lui-même.. Sous ta supervison, bien sûr!
On peut donc affirmer que l’expérience GitHub a bien livré des avantages probants.
D’accord, attaquons-nous maintenant à un sujet épineux: le choix d’une licence. Voilà certainement un aspect avec lequel la plupart d’entre nous sommes moins confortables mais qui a tout de même des impacts important sur l’utilisabilité du code. Quelle licence as-tu choisie et pourquoi ?
T:
Bon point. J’ai choisi la licence Apache version 2.0 plutôt que les licences plus courantes telles que GPLs ou MIT. J’ai spécifiquement choisi cette licence car elle prévoit une attribution expresse des droits de brevet des contributeurs aux utilisateurs. De plus, c’est une licence très utilisée dans le monde des startups et des compagnies informatiques telles qu’ArangoDB, alors ça me semblait un choix approprié.
JP:
Intéressant !
T:
Je suggérerais aux gens intéressés à libérer du code de visiter le site Choose a licence, il est simple, bien fait et très utile.

JP:
Voilà une excellente recommandation. Je suis sûr qu’elle sera appréciée de nos lecteurs.
On entend souvent parler de l’impact de l’anonymité que le web confère. Notamment, que certaines personnes se sentent parfois confortables à tenir des propos qu’ils ne tiendraient pas autrement. As-tu déjà été la cible d’hostilités en relation avec les librairies que tu as choisies de partager ?
T:
Malheureusement, oui.
J’ai reçu des commentaires durs à quelques reprises. Certains d’entre eux avaient parfois leurs fondements (quoique le ton soit tout de même déplacé) mais une fois, alors que je répondais à une question d’un usager sur le site StackOverflow en lui suggérant de regarder l’un de mes projets plus modeste comme solution potentielle à son problème, un usager anonyme est apparu de nulle part et s’est mis à vraiment descendre ma librairie, sans raison apparente ! Il semble que ses commentaires aient vraiment été déplacés et d’un goût douteux car ils ont plus tard été retirés par un modérateur de StackOverflow..
Mais pour être franc, les commentaires positifs que j’ai reçus l’emportent largement sur les négatifs. J’ai reçu bon nombre de commentaires très positifs et encourageants. Et, sans grande surpise, les gens positifs et encourageants se présentent rarement sous le couvert de comptes anonymes.

JP:
Parlons quelque peu de l’aspect de la maintenance de tes librairies.
Un problème récurrent avec les librairies développées par des individus est leur manque de maintenance. Certaines librairies tombent parfois bien en retard des mises à jour de leurs dépendances et deviennent donc carrément inutilisables. Te considères-tu actif au niveau de la maintenance et combien de temps consacres-tu à ces tâches ?
T:
Je suis définitivement actif sur ce front quoique l’ajout de fonctionnalités est parfois laissé de côté. Je tente de corriger les bugs et autres problèmes sérieux rapidement mais l’ajout de fonctionnalités peut être fastidieux et chronophage alors si je n’ai pas de besoin clair pour la fonctionnalité, je n’ai parfois pas de temps à y consacrer.
Dans ce sens, je crois qu’il est important pour les développeurs de mettre en place des mesures qui atténuent la charge de travail liée à la publication de nouvelles versions d’une librairie. Je ne serai pas le premier à affirmer qu’un bon ensemble de tests est un incontournable. Mais le fait d’avoir une bonne batterie de tests permet aussi l’usage de services de type « Integration Continue » (CI). Les services CI sont une des mesures qui m’ont bien servi par le passé en identifiant des bugs que j’avais laissé passer et puisqu’ils roulent par eux-même sans que l’on doive prendre le temps de les lancer, ils sauvent pas mal de temps tout en procurant une bonne dose de tranquilité d’esprit. Et on a tous besoin de tranquilité d’esprit !

JP:
Le fait de rendre son code public en l’exposant sur son dépôt GitHub n’assure en rien que les gens commenceront à l’utiliser. Ils doivent d’abord apprendre que le code existe… Parle-nous un peu de tes efforts de « publicité ».
T:
La publicité, c’est difficile !
Je crois que ça dépend de ton public cible. J’ai essayé avec Twitter au début, mais ça n’a pas très bien marché… Je crois qu’il faut d’abord avoir une solide base de followers pour que les gazouillis aient vraiment un bon impact. Les meilleurs résultats ont été obtenus en publiant des billets sur des sites comme Biostars pour pyGeno et HackerNews pour Mariana quoique je suspecte que ces stratégies livrent tout de même des résultats stochastiques. J’ai aussi donné quelques présentations dans des conférences mais bien que tu t’adresses directement à ton public cible, le nombre de participants est parfois limité. Un truc important à retenir cependant, c’est qu’il faut s’attendre à recevoir beaucoup de contacts directs. Attendez-vous à ce que beacoup de gens vous écrivent à votre boîte de courriel personelle.

JP:
Bien noté. Et comment mesures-tu l’impact de ces activités promotionelles ?
T:
Eh bien, GitHub fournit des statistiques sur les visiteurs et l’activité de ses dépôts. On peut consulter le nombre de vues, de vues uniques, de clones et de clones par machine unique. Alors c’est vraiment ça que je regarde.

JP:
Très bien ! Merci beaucoup pour toutes ces informations, Tariq.
En clôture de l’entrevue, aurais-tu un dernier brin de sagesse à offrir aux développeurs qui songent à libérer leur code dans le domaine public ?
T:
Oui: Les tests sont vos meilleurs alliés!!.
JP:
Alors tu préconiserais donc les tests plutôt qu’une bonne documentation, par exemple?
T:
Definitivement !
La documentation c’est assez facile à faire, mais si tu distribues du code qui marche pas.. Les gens te le laisseront savoir, crois-moi !