Open Source : ce n'est pas si effrayant !

Ce qui suit a été publié avant le lancement des bourses Toptal pour les femmes développeurs.

En tant que développeur, il est passionnant et stimulant de se tenir au courant des dernières tendances technologiques. Chaque jour, de nouveaux langages, frameworks et appareils captent notre attention et stimulent les conversations dans les meetups, les forums et les chats. Cependant, notre communauté de développeurs est faite de personnes, pas d'outils, et il est fascinant d'explorer ses aspects sociopolitiques (faute d'un meilleur mot ; « social » a tendance à être associé aux réseaux sociaux, de nos jours).

Chez Toptal, nous avons récemment eu des conversations intéressantes sur la contribution des femmes à l'open source et sur ce qui peut les empêcher de contribuer davantage, nous avons donc enquêté sur la question. Ayant participé à cette conversation avec Breanden Beneschott et Bozhidar Batsov, je me suis demandé : Bozhidar est l'un des principaux contributeurs open source sur GitHub. Où suis-je? Si vous consultez mon compte GitHub public à ce jour, ce sont principalement de petits projets de test que j'ai utilisés en classe pour mes élèves. Ils sont à moitié cuits et ne sont certainement pas représentatifs de mes compétences ou de mon expertise. (Vous devrez me croire sur parole.) Si quelqu'un envisageait de m'embaucher en fonction de ce qu'il peut trouver dans ce compte, je suppose que j'aurais du mal à gagner ma vie. Pourtant, je suis développeur professionnel depuis plus de 20 ans et, dans mon travail quotidien, j'utilise plus de logiciels open source que je ne me souviens. Au fil du temps, j'ai piraté le noyau Linux pour le plier à un besoin spécifique, peaufiné chaque routeur et NAS que j'ai acheté, attendu patiemment pendant des mois dans la liste d'attente de Raspberry Pi pour mettre la main dessus et obtenir ma domotique maison comme Je l'aime bien. Pourtant, aucun de ces ajustements et tests n'est jamais parvenu à mon GitHub pour devenir open source. De plus, mis à part la correction d'un bogue dans l'une des premières versions de Tomcat, je n'ai jamais contribué à un projet open source. Curieux, n'est-ce pas ?

Vous pourriez penser que c'est juste un manque de temps ou d'intérêt, mais je sais que ce n'est pas le cas. Quant à mes projets personnels, j'ai peut-être pensé que personne ne pouvait vraiment s'intéresser à ce que j'ai fait, mais c'est surtout que l'idée même d'y publier mon travail, à la vue de tous et pour la postérité, me fait très peur. Et bien que vous puissiez toujours supprimer un projet personnel de GitHub, le jour où vous essayez de contribuer à un projet open source largement disponible, il n'y a pas de retour en arrière. Que faire si mon code n'est pas assez bon ? Et si je n'ai pas bien compris le problème ? Que faire si ma pull request est rejetée ? Et si les gens me trollent ?

Une série d'appels rapides avec d'autres amis développeurs, principalement des femmes, m'a rapidement convaincu que je ne suis pas le seul à avoir ce problème, mais pour un ingénieur, il n'y a pas de problèmes, seulement des solutions, n'est-ce pas ?

C'est un problème important à résoudre, car contribuer à un projet open source peut faire une différence considérable :

• Au cours de votre carrière : De nombreux clients regarderont votre social tout avant de décider de vous embaucher ; votre compte GitHub et votre CV LinkedIn sont en tête de liste, ainsi que vos profils Facebook et Twitter. Vous devez les utiliser à bon escient.
• Pour vos compétences techniques : Examiner une base de code écrite par d'autres développeurs, et souvent de très bons développeurs, vous apprend beaucoup. La capacité à extraire le sens d'une base de code mal écrite vous défiera et vous apprendra tout autant.
• Pour vos compétences générales : Les logiciels open source sont un processus collaboratif, et presque tous les projets intéressants sont construits par des équipes. Apprendre à travailler avec d'autres développeurs grâce aux outils que tout le monde utilise, à se fondre dans l'équipe, à communiquer efficacement, c'est ce qui fera de vous un grand développeur, pas seulement un développeur compétent.
• Pour la communauté : Chaque bit que vous contribuez à un projet open source compte. Plus vous contribuez, mieux c'est, mais même corriger une petite faute de frappe dans une traduction améliorera le produit final.
• Pour votre réseau : Vous pouvez envoyer des centaines de CV aux entreprises, mais rien ne fonctionne mieux que d'avoir des collègues avec des relations personnelles. S'impliquer activement dans un projet open source vous assurera de rencontrer des gens et de gagner leur respect, et votre réputation grandira, ce qui est inestimable pour tout professionnel.

Ceci est mon petit voyage personnel dans la lutte contre cette peur. La publication de cet article fait partie du voyage lui-même. Je l'écris dans l'espoir que quiconque est bloqué pour écrire un article de blog, ou qui a peur de faire même une petite contribution, verra qu'au final, ce n'était pas si effrayant. En outre, il est destiné à aider tous ceux qui aimeraient contribuer à l'open source, mais ne savent pas vraiment par où commencer, je vais donc commencer par les bases.

Qu'est-ce qu'un logiciel Open Source et où puis-je le trouver ?

Un logiciel open source, ou OSS en abrégé, est tout logiciel publié avec son code source et inclut une licence qui vous permet de le modifier et de le redistribuer. Il peut être diffusé n'importe où : sur un site Web, via une liste de diffusion ou avec un hibou. Le scénario le plus courant, et celui qui nous intéresse, est celui où la base de code est maintenue sur un référentiel collaboratif. Ici, nous nous concentrons sur GitHub, mais il existe d'autres options, telles que SourceForge et Bitbucket. GitHub est très convivial, possède une énorme base d'utilisateurs, peut être utilisé pour tout type de code et avec n'importe quel environnement de développement que vous utilisez. Surtout, il est également largement utilisé pour les projets non open source. Il y a de fortes chances que votre prochain projet client y soit hébergé, donc savoir comment travailler avec lui est une compétence utile en soi.

Et si je ne sais pas coder ?

Si vous lisez ceci, il est probable que vous souhaitiez apprendre à coder. Vous pouvez trouver des cours incroyables sur plusieurs sites Web gratuits et payants. Vous devez choisir une langue à apprendre ; si vous n'avez pas de préférence, optez pour JavaScript. Vous avez déjà tout ce dont vous avez besoin pour démarrer sur votre navigateur Web et c'est l'une des compétences les plus utilisées et les plus commercialisables. Mon préféré est Python, qui est utilisé à la fois dans le développement Web et dans les applications scientifiques. J'ai aussi un cours pour débutant préféré, "Introduction à l'informatique" sur Udacity. Je l'aime parce que c'est un cours pratique, où vous travaillez sur un projet tout en apprenant. Vous pouvez également trouver plusieurs autres cours sur Coursera, Khan Academy et PluralSight.

Et si je ne connais pas Git ?

Comme mentionné précédemment, il est important de connaître Git, alors suivez un cours Git. Faites-le même si vous travaillez avec Git depuis un certain temps ; vous ne savez pas à quel point vous ne connaissez pas Git jusqu'à ce que vous l'étudiiez vraiment. Faites-le si vous ne pouvez pas expliquer en toute confiance ce que fait la commande rebase . Faites-le même si un mauvais rebase ne vous fait pas peur. J'ai suivi le chemin Git complet sur Code School, mais encore une fois, vous pouvez explorer d'autres sites pour plus d'options.

Comment choisir un projet sur GitHub ?

Il est probable que vous utilisiez des OSS dans votre développement quotidien. Choisir un framework familier est un bon point de départ ; vous êtes déjà familiarisé avec les fonctionnalités et le fonctionnement du framework. Lorsque vous plongerez dans le code source, vous en apprendrez plus et vous comprendrez encore plus clairement sa logique. S'il y a une technologie ou un outil que vous aimez particulièrement, recherchez les projets qui le mentionnent, ou le projet de l'outil lui-même. En dernier recours, vous pouvez consulter les projets sur GitHub Showcases et commencer par choisir une catégorie qui vous intéresse.

Par exemple, une recherche rapide de "Raspberry" dans la recherche de GitHub montre plus de 17 000 dépôts. Il est facile de se perdre, alors recherchez un projet avec une bonne communauté et un bon suivi des problèmes. Lors du choix d'un projet, vérifiez le nombre de :

• Contributeurs : ciblez tout ce qui dépasse dix contributeurs. Cela devrait garantir que le projet a suffisamment d'intérêt et qu'il ne s'agit pas simplement d'un petit effort d'équipe. Si vous êtes nouveau sur l'OSS, ou pas trop doué, limitez votre recherche aux projets avec au plus cinquante contributeurs ; les communautés plus grandes impliquent des bases de code plus grandes et des projets plus compliqués.
• Commits : Optez pour des projets qui ont au moins un millier de commits, et où l'activité la plus récente n'a pas plus d'une semaine. Un projet qui a été inactif pendant un mois ou plus est vieux et obsolète en termes d'OSS, et vous n'obtiendrez probablement pas de réponses rapidement. L'activité quotidienne est le signe d'un projet sain.
• Problèmes : Les problèmes sont des problèmes ouverts, des bogues qui ont été signalés ou des fonctionnalités demandées à implémenter. Ils vous donneront un point de départ et sont une bonne mesure de l'intérêt pour le projet.

Découvrez également quelle est la langue principale du projet ; vous pouvez voir les statistiques de langue dans la barre supérieure de la page principale du projet. Prenez le temps de lire le ton de la discussion, voyez à quel point les commentaires sont amicaux et éduqués. Certains projets sont tristement célèbres pour leurs communautés agressives, ils peuvent donc ne pas être le bon point de départ.

J'ai choisi ScyllaDB, un projet de stockage de données en colonnes, car j'ai une fascination pour les données, tout ce qui est lié aux performances. Je n'ai jamais travaillé avec, mais je m'attends à pouvoir plonger dans sa base de code. Il est peut-être plus simple de travailler avec des outils que je connais, mais je prends cela comme un défi et une occasion d'apprendre quelque chose de nouveau. Pour le reste, il fait parfaitement l'affaire ; il compte 18 contributeurs, 6 500 commits (le plus récent remonte à 23 heures au moment de la rédaction), 178 problèmes ouverts et semble actif.

Qu'est-ce que je fais maintenant?

Tout d'abord, clonez le référentiel et installez le logiciel sur votre machine pour avoir une idée de ses pièces mobiles. Ensuite, commencez à lire les problèmes. Une fois que vous vous sentez prêt, voyez si vous pouvez reproduire le problème sur votre machine, puis commencez à analyser ce qui fait que le logiciel se comporte mal.

Une autre approche serait de trouver quelque chose que vous pouvez améliorer ou modifier vous-même. Peut-être avez-vous remarqué une faute de frappe ou une police mal alignée, par exemple. J'ai choisi de corriger un petit bogue, en particulier un nom de variable erroné utilisé dans la documentation d'un script.

Cela semble minuscule, mais une mauvaise documentation est bien pire que pas de documentation. Les utilisateurs installeront ScyllaDB et suivront les étapes d'installation, ils se fieront aveuglément à ce qui est écrit dans ce script et finiront par être frustrés. C'était parfait pour mes capacités, et pour le réparer, il faudra que je suive tout le processus et que je me familiarise un peu avec la base de code. La correction de bogues est ennuyeuse, mais c'est un bon début pour trouver votre chemin dans un projet.

Création d'un fork

C'est peut-être trivial, mais pour le moment, pour le projet ScyllaDB, je suis Mme Nobody ; il serait risqué de me permettre d'apporter des modifications à leur code sans supervision. Ce que je dois faire, c'est créer un "fork" dans mon propre compte GitHub. Voici mon fork ScyllaDB. C'est mon propre terrain de jeu où j'ai accès à tout le code, et je peux modifier les fichiers comme je le souhaite. Si je voulais créer ma propre version de ScyllaDB et la modifier pour faire quelque chose de complètement différent de son objectif initial, je pourrais le faire ici. La création d'un fork est simple ; allez sur la page principale du projet et cliquez sur le bouton « fork ». Pas effrayant du tout.

Il est temps de corriger le bug

Il est maintenant temps de tester le code sur votre ordinateur et d'apporter les modifications nécessaires. Tout d'abord, assurez-vous d'avoir installé le client Git sur votre machine. Ensuite, ajoutez votre clé publique SSH au GitHub et assurez-vous qu'elle est chargée par votre agent ssh. Obtenir le code localement est simple ; utilisez simplement la commande git clone qui pointe vers votre fork, au lieu de la branche principale :

 git clone [email protected]:acbellini/scylla.git

À présent, vous devriez avoir testé le projet sur la branche principale, vous allez donc construire votre code localement et le tester de la même manière. Gardez à l'esprit que vous devrez bifurquer tous les autres projets GitHub sur lesquels votre projet repose, car les références sont relatives. Dans mon cas, j'ai dû bifurquer seastar, scylla-ami et scylla-swagger-ui.

Le bogue que je dois corriger est relativement simple ; la documentation dans conf/scylla.yaml mentionne trois répertoires configurables : un pour les fichiers de données, un pour les journaux de validation et un, apparemment inutilisé, pour les caches, tous par défaut dans un sous-répertoire de $CASSANDRA_HOME :

En plongeant dans le code, cela montre que les valeurs par défaut sont différentes et, comme mentionné dans le numéro 372 à partir duquel je suis parti, $CASSANDRA_HOME ne doit pas être utilisé. Je valide mon hypothèse en testant le code avec quelques paramètres différents, en supprimant le paramètre du fichier de configuration et en vérifiant quels répertoires sont utilisés. Une fois suffisamment convaincu que tout est correct, je peux ajouter, valider et pousser le fichier modifié :

 git add conf/scylla.yaml git commit -m 'Correct default directories values in conf/scylla.yaml #372' git push

Notez que j'ai introduit le numéro de problème précédé d'un hachage dans le message de validation. Cela indiquera à GitHub de lier automatiquement mon code au problème lui-même.

Une autre chose importante à noter est que, lorsque j'ai examiné le code, j'ai réalisé que le troisième répertoire, celui des caches, n'est en fait pas utilisé. Il est tentant d'aller un peu trop loin et de supprimer ce paramètre lui-même, ou d'ajouter un commentaire qui n'est pas utilisé, mais cela sortirait du cadre du problème #372, et il serait erroné de commettre tout ce qui n'est pas strictement lié à cela publier. Vous devez garder vos changements ciblés et limités à la tâche à accomplir.

À ce stade, le code est corrigé et se trouve sur GitHub, dans mon fork privé. C'est là qu'intervient la partie effrayante : demander aux gens de ScyllaDB d'accepter mon code. C'est ce qu'on appelle une demande d'extraction.

Dernière étape : la pull request

J'aime créer des demandes d'extraction directement depuis l'interface Web sur GitHub. Je trouve cela plus intuitif et sans erreur que d'essayer de le faire à partir de la ligne de commande. Tout ce que j'ai à faire pour créer ma pull request est de cliquer sur le petit bouton vert à côté du nom de ma branche :

Notez que le commentaire a été calculé automatiquement par GitHub. Ma branche a maintenant un nouveau commit, mais depuis la création de mon fork, il y a 14 commits supplémentaires dans le référentiel principal, je vais donc cliquer sur l'icône verte à gauche.

Heureusement, mon seul commit n'entre pas en conflit avec les 14 autres, donc GitHub m'informe que je suis prêt à partir. Je n'ai pas besoin d'ajouter d'autre commentaire ou message. Le message de validation, tout en étant très court, dit tout : ce que fait mon changement de code et à quoi il est lié. Alors que je clique sur le dernier bouton pour confirmer ma demande, je me demande ce que j'ai trouvé de si effrayant il y a quelques jours à peine. Il n'y a aucun monstre qui rugit contre moi en ce moment, et les flammes de l'enfer ne semblent pas brûler. Honnêtement, ce n'était pas effrayant du tout. Dans le cas peu probable où je me trompe, mon correctif ne sera pas accepté et ce sera tout.

Si vous vérifiez maintenant les détails du problème, vous pouvez voir que GitHub a automatiquement ajouté une note indiquant qu'il existe une demande d'extraction faisant référence à ce problème. C'est la magie de ce #372 dans le message de validation. Cela aidera à éviter que d'autres personnes perdent du temps à réparer quelque chose qui a déjà été réparé.

Remarques finales

Maintenant, j'attends que ma demande de tirage soit acceptée, je recevrai une notification lorsque cela se produira. Gardez à l'esprit que cela peut prendre quelques jours, voire des semaines ; quelqu'un doit revoir mon code, tester qu'il fonctionne comme décrit, résoudre le problème et, en fin de compte, s'assurer qu'il n'affecte pas négativement la fonctionnalité du reste du code (lire : crée de nouveaux bogues). Tout cela prend du temps à quelqu'un, alors soyez patient. Au final, lorsque ma pull request sera acceptée, ScyllaDB aura un contributeur de plus, un issue de moins et j'aurai ma première contribution OSS. Maintenant, il est temps pour vous aussi de l'essayer. Après tout, ce n'est pas effrayant du tout.