L'open source est un domaine central dans le développement logiciel, pour la simple et bonne raison que nous utilisons toutes et tous quotidiennement des librairies open source dans nos projets : des langages aux frameworks, en passant par des libs utilitaires, des connecteurs, etc. L'opinion générale présente l'open source comme quelque chose de prestigieux mais d'extrêmement compliqué. S'il y a un peu de vrai dans cette idée, le but de cet échange est désacraliser l'OS, de comprendre ce que cela peut apporter à sa carrière, à sa pratique professionnelle, et de découvrir les conseils d'un contributeur open source pour savoir par où commencer et comment s'y préparer au mieux. Jean Michelet est développeur dans la team Plugin sur le projet Fastify, extrêmement populaire dans l'écosystème JavaScript et Node.js.
Quelles sont les bonnes et les mauvaises raisons pour s’essayer à l’open source ?
C'est très subjectif.
D'abord, beaucoup de personnes pensent "logiciel open source" et "logiciel libre" de manière interchangeable, alors qu'il existe souvent des nuances. À ce sujet, lire : "En quoi l'open source perd de vue l'éthique du logiciel libre" par Richard Stallman.
Ensuite, certains diront qu'il ne faut pas faire de l’open source uniquement pour trouver un emploi ou acquérir de la notoriété. La réalité est qu’il est vraiment difficile de généraliser, tant les motivations peuvent varier en fonction de vos compétences, de vos valeurs et de vos objectifs...
Comment choisir le bon projet open source ?
Si vous ne savez vraiment pas par où commencer, voici 5 conseils :
Contribuez à une solution que vous utilisez. Cela renforcera votre compréhension des outils dont vous dépendez, vous aidant ainsi à résoudre des bugs et à proposer des fonctionnalités pertinentes. Cela renforcera aussi votre image d'expert de la solution.
Choisissez un projet où vous pouvez avoir un impact. Contribuer sur un logiciel open source publié par Microsoft, Meta ou Vercel et sur Fastify, maintenu par une communauté de bénévoles, n'est pas la même chose. Dans des projets maintenus par les géants de la tech, il y a déjà des développeurs bien payés pour faire le travail, et votre rôle se résumera souvent à corriger des bugs gratuitement. Sur des projets tenus par des bénévoles, vous aurez probablement plus d'opportunités.
Essayez de faire des contributions utiles. "Software is just a tool to help accomplish something for people - many programmers never understood that. Keep your eyes on the delivered value, and don't overfocus on the specifics of the tools." - John Carmack
Lisez les codes de conduite et renseignez-vous sur les mainteneurs. Certains codes de conduite sont assez libres, d'autres plus stricts. En général, on vous demande simplement de bien vous comporter, de ne pas prendre les remarques personnellement et de ne pas discriminer les contributeurs, ce qui me paraît tout à fait souhaitable. En pratique, renseignez-vous sur l'historique et la communication publique des mainteneurs pour savoir à qui vous avez affaire et si cela vous convient.
Ne vous dispersez pas. En tout cas, pas au début. Choisissez un projet et passez quelques semaines dessus.
Par où commencer une fois que j’ai choisi le bon repo ?
Commencez par lire les règles de contribution, puis cherchez une issue accessible. Les projets annotent souvent ce type d’issue avec le label "good first issue".
Pour le projet Fastify, nous répertorions toutes les "good first issues" de l'ensemble des repos ici : https://fastify.dev/contribute/
Il existe d’autres sites qui répertorient ou aident à faire sa première contribution:
Quelles compétences as-tu le plus développées en contribuant à des projets open source ?
Je ne sais pas si je peux faire une liste de compétences clés, mais pour citer quelques améliorations :
Lire et comprendre le code des autres.
Écrire des tests avec une couverture optimale.
Communiquer en asynchrone.
Accepter la critique brut de décoffrage (les gens n'ont pas de temps à perdre dans l’open source).
Considérer l'existant et comment des modifications peuvent affecter les utilisateurs finaux.
La liste est longue...
De manière générale, le développement de librairies et de frameworks demande beaucoup de rigueur. Lorsque vous faites une erreur, cela peut impacter des milliers, voire des millions d'utilisateurs.
Quel a été le plus grand défi que tu as rencontré lors de tes premières contributions et comment l’as-tu surmonté ?
Lorsque j'ai voulu contribuer à TypeScript, il m'a fallu du temps et de la patience. Intégrer un gros projet aussi populaire que TypeScript est clairement coûteux cognitivement. J'ai commencé par étudier le compilateur en lisant des documentations sur le fonctionnement interne, j'ai discuté avec certains développeurs de Microsoft sur Discord, qui m'ont conseillé, et j'ai lu les règles de contribution.
Une fois que je me suis senti prêt, j'ai choisi une issue pas trop complexe : https://github.com/microsoft/TypeScript/issues/56997. Il s'agissait d'un bug dans l'émetteur de code, et j'ai finalement réussi à faire accepter ma PR. J'étais très content, mais aujourd'hui, je préfère contribuer uniquement à Fastify, car même si ça m'intéresse beaucoup, les développeurs de Microsoft n'ont pas besoin de moi. C'était un challenge intéressant et gratifiant.
As-tu ressenti un impact direct de l’open source sur ta carrière ou tes opportunités professionnelles ?
Oui, ce qui m'a surpris, c'est le nombre de développeurs seniors, n'utilisant pas forcément Node.js, qui m'ont envoyé des demandes de connexion sur LinkedIn. Je pense que beaucoup apprécient la démarche de transparence (Talk is cheap, show me the code). Lorsque vous contribuez publiquement, vous ne trompez personne ; vous exposez vos points forts comme vos lacunes, et c'est beaucoup plus rassurant que de parier sur un CV séduisant en apparence.
Sur le plan professionnel, l'entreprise pour laquelle je travaille actuellement m'a repéré suite à mes contributions open source, et aucune entreprise avec laquelle j'ai été en processus de recrutement depuis ne m'a demandé de passer des tests techniques. Certains développeurs ont proposé de m'aider à trouver un emploi ou de me placer sur des missions, mais je ne me suis jamais senti à l'aise avec ça. Être exposé à des développeurs de très haut niveau, comme c'est souvent le cas dans l'open source, peut donner une vision distordue du marché et de votre valeur personnelle.
Quels conseils donnerais-tu à quelqu’un qui craint de ne pas être "assez bon" pour contribuer ?
Choisissez un projet à votre portée et faites abstraction de vos éventuels problèmes d'ego.
Premièrement, à moins d'être débutant, vous êtes probablement suffisamment compétent pour trouver une contribution à votre niveau.
Deuxièmement, il faut vraiment comprendre que faire des erreurs publiquement est acceptable, même si vous êtes senior, CTO, encadrez d'autres développeurs, ou même si vous êtes un expert LinkedIn auto-proclamé qui donne des conseils à tout le monde.
D'une manière générale, s'interroger constamment sur ses capacités intellectuelles, ses compétences, se comparer aux autres est toxique et ne change rien à la réalité. Vous savez probablement déjà que vous n'êtes pas Terence Tao, et vous n'êtes pas non plus en charge du projet Manhattan. Donc, pas la peine de vous torturer l'esprit avec des problèmes qui n'existent pas ; la vie est trop courte pour ça. Si vous ne parvenez pas à comprendre et/ou résoudre une issue, prenez-en une autre.
Comentários