Nous essayons de plus en plus chez Synbioz de rendre à la communauté open source ce qu’elle nous a donné tout au long de ces années.
C’est donc tout naturellement que nous aussi participons aux projets libres que nous utilisons au quotidien ou en publions dans le but d’en faire profiter la communauté.
En ce qui me concerne j’aime travailler sur Homebrew, Oh My Zsh et tout particulièrement Rails.
Nous essayons donc de dégager du temps pour travailler sur ces projets communautaires. J’aimerai aujourd’hui vous expliquer pourquoi cela nous intéresse et nous tiens à cœur mais aussi et surtout comment participer à des projets open source, sous quelles formes et quelles sont les bonnes pratiques.
Dans le cadre de Synbioz mais également à titre personnel, bien des raisons font que j’aime participer à des projets open source.
En premier lieu, c’est l’envie de m’améliorer qui me pousse à participer, découvrir les bonnes pratiques mises en œuvres dans les outils que j’utilise au quotidien. J’essaie donc de voir comment est organisé le code, comment il est écrit, quels sont les idiomes et essaie autant que possible d’en tirer des leçons pour intégrer ces bonnes pratiques dans mes développements.
Une chose est certaine et on s’en rend très vite compte, ça fonctionne. On repère rapidement les choses qu’on n’aurait pas implémenté de la même façon, on en tire directement les leçons et bien souvent on aperçoit un cas d’utilisation qu’on pourrait en faire.
Il est incontestable que même en se cantonnant à la lecture du code de gros projets bien écrit, vous progresserez et apprendrez des choses.
Le deuxième point non-négligeable est le fait que mettre son nez sous le capot vous fera découvrir des possibilités et des options que vous ne connaissiez pas dans l’outil.
Cela vous permettra également de mieux comprendre certains comportements qui vous semblez obscures.
Contrairement à ce qu’on peut croire, la lecture de code de gros projets est relativement aisée. Les bons projets sont la plupart du temps bien écris et découpés. Les différentes briques sont découplées, vous n’aurez donc pas besoin de comprendre l’ensemble de la machine pour étudier une brique donnée. Bien évidemment il y aura la barrière du langage si vous êtes novice dans ce dernier mais il n’en reste pas moins que lire le code, essayer de le comprendre vous fera beaucoup progresser.
J’utilise Rails depuis environ 10 ans et malgré cela, en lisant son code, j’apprends encore des choses à propos de fonctionnalités que j’utilise pourtant depuis longtemps. Il s’avère que les documentations d’API couvrent rarement l’ensemble des possibilités que fournissent certaines briques ou méthodes. Lire les définitions de méthodes n’est jamais du temps perdu.
Après avoir utilisé pendant des années des logiciels libres, il est naturel de vouloir aider soit en écrivant des logiciels ou librairies qui manquent cruellement, soit tout simplement en participant à des projets existants notamment ceux que vous utilisez vous même.
Vous aurez un vrai sentiment de fierté lorsque votre premier patch sera intégré au dépôt officiel du logiciel / framework / librairie que vous utilisez depuis si longtemps. En plus de cela, votre contribution aidera sans nul doute d’autres utilisateurs qui faisaient face au bug que vous avez corrigé, qui attendaient la fonctionnalité que vous avez implémenté ou encore qui n’arrivaient pas à utiliser une méthode donnée à cause d’une erreur dans la documentation.
Contribuer à un projet open source c’est forcément entrer en contact avec les principaux acteurs de ce projet. En effet vous devrez communiquer pour expliquer pourquoi vous voulez intégrer telle ou telle fonctionnalité, parfois vous justifier sur l’implémentation d’un correctif ou encore détailler une anomalie remontée sur le système de suivi.
Dans tous les cas, il y a de fortes chances qu’un des développeurs principaux se rapproche de vous. Au fur et à mesure de vos contributions, vous apprendrez à les connaître et inversement. Ces développeurs seront souvent de bon conseil quand il s’agira de discuter vos choix techniques. Plus ces développeurs vous connaîtront plus l’inclusion de vos fonctionnalités et correctifs se fera rapidement, avec moins d’aller-retour puisque vous aurez gagné en expérience.
Comment un développeur peut être plus crédible dans son rôle d’expert dans une technologie donnée qu’en en étant l’un des acteurs ? Si vous participez beaucoup au développement d’un framework, il y a de fortes chances que vous en connaissiez très bien le fonctionnement et que vous sachiez l’utiliser sur le bout des doigts.
C’est un atout majeur qui souligne votre expertise dans ce domaine, que ce auprès d’employeurs ou de clients.
Il ne faut pas négliger cette partie, participer à un projet open source quand on est un geek c’est principalement parce que c’est amusant. S’intégrer au processus de développement, proposer des solutions, des fonctionnalités, échanger avec les autres développeurs, c’est un peu le passe temps préféré de tout bon geek.
Il est donc important de choisir les projets auxquels vous voulez participer en fonction de vos goûts, vos préférences et non pas choisir un projet parce qu’il est simplement à la mode. Vous ne prendrez aucun plaisir à participer à un projet qui utilise un langage qui vous débecte ou qui ne correspond pas du tout aux outils que vous avez l’habitude d’utiliser.
Pour vous aiguiller je vais vous parler de ma propre expérience, à savoir les contributions à Rails. C’est un très bon exemple car beaucoup de projets open source fonctionnent sur le même modèle.
Ici il est question de travailler en Ruby avec du code versionné à l’aide de Git et hébergé sur Github. C’est d’ailleurs le système de ticket de Github qui est utilisé pour remonter les anomalies.
Alors, concrètement, que pouvez-vous faire pour participer ? Plusieurs possibilités existent et permettent à des personnes de tout niveau de participer.
La chose la plus élémentaire à faire quand vous ne savez pas sur quoi travailler est de parcourir les tickets ouverts pour prendre connaissance des anomalies repérées par d’autres personnes.
Vous pourrez dire à l’auteur si c’est effectivement un bug ou pas, en discuter avec lui, demander des précisions ou en apporter si vous avez déjà fait face au problème.
Ce que j’aime faire quand un ticket remonte une anomalie en ne faisant que la décrire est de procéder à l’écriture d’un morceau de code de test reproduisant l’anomalie.
Cette étape est importante puisqu’elle permet dans un premier de confirmer ou infirmer la reproductibilité de l’anomalie. Dans un deuxième temps, si l’anomalie est avérée, ça permet à l’ensemble des autres développeurs de facilement tester ce bug de leur côté et de se servir de vos tests comme base lors de leurs tentatives de correction.
Si vous ne vous sentez pas capable de corriger une anomalie, ça n’empêche pas votre implication dans le ticket sous toutes ces formes.
Un point souvent négligé est la documentation. Rails possède une API conséquente ainsi que des guides concernant divers sujets. Il arrive que ces documentations ne soient pas à jour sur des points de détail, qu’un cas d’utilisation ne soit pas mentionné, qu’un exemple ne fonctionne pas ou encore que des subtilités d’utilisation soient mal ou non documentées.
Il est très simple de participer à l’amélioration de la documentation, vous n’avez nullement besoin d’être un expert pour apporter votre pierre à l’édifice.
S’il vous arrive en utilisant Rails de rencontrer des dysfonctionnements ou un manque dans la documentation, n’hésitez pas à créer un ticket pour partager votre découverte, savoir si d’autres ont ce problème et par la même occasion lancer le processus de correction de l’anomalie.
Que vous soyez en mesure ou non de corriger le problème importe peu, ici l’idée est simplement de faire savoir que le problème existe et de le documenter le plus précisément possible.
Pour faciliter la tâche, l’équipe de Rails a mis à disposition deux gabarits qui permettent grâce à très peu de code de reproduire les anomalies et de les confronter à la dernière version de Rails ou n’importe quelle version qui vous intéresse.
Ces gabarits sont disponibles aux adresses suivantes :
Le premier gabarit est dédié à la reproduction de bugs liés à ActiveRecord. Le second quant à lui est orienté ActionController.
Vous pourrez donc facilement créer les modèles, routes, contrôleurs dont vous avez besoin pour vos tests et il ne vous restera plus qu’à remplir la méthode de test pour mettre en évidence l’anomalie.
Une fois fait, vous pouvez partager ce code via un Gist par exemple et donner son url en commentaire du ticket pour faciliter la tâche des autres développeurs.
Quand vous avez ce gabarit de test, toute modification dans votre clone local du code de Rails est directement reflétée. Si vous lancer à nouveau votre fichier, les tests prendront en compte vos modifications. Cela permet donc de tester facilement les modifications en relançant ses tests à loisir.
C’est particulièrement pratique.
Les pull request (souvent notés «PR» dans les tickets) sont visibles aux yeux de tous, vous pouvez donc parcourir les pull requests ouvertes comme vous le feriez pour les tickets.
Parcourir ces pull requests vous permettra de voir les changements apportés, de le tester chez vous pour confirmer la résolution du problème. Vous pourrez également commenter les changements ligne par ligne pour relevez des choses qui vous semblent étranges ou encore faire des commentaires d’ordre plus général pour approuver les changements ou les contester.
Les développeurs ne sont pas des machines et parfois des soucis dans les modifications (style, bug, problème de performance) peuvent leur échapper. N’hésitez donc pas à participer si quelque chose vous saute aux yeux. Si vous voyez des améliorations possibles, faites en part.
Si vous trouvez ou créez un ticket que vous vous sentez capable de résoudre, lancer vous.
Quand vous souhaitez participer à Rails, la première chose à faire est de créer un fork du projet dans votre espace. C’est sur ce fork que vous pourrez apporter des corrections ou écrire de nouvelles fonctionnalités.
Pour chaque nouvelle contribution, il vous faudra créer une branche dédiée à cette contribution. Cela permet aux autres développeurs d’intégrer très facilement vos contributions grâce au système de pull requests.
Une pull request apparaîtra dans le projet principal et permettra à ses développeurs de voir les modifications apportées, de savoir si les modifications sont intégrables en l’état, si les tests passent mais aussi il leur sera possible de discuter directement de vos modifications au sein de votre pull request sous forme de commentaires généralistes ou même sur une ligne précise de vos modifications.
La plupart du temps des allers-retours seront nécessaires entre les développeurs et vous pour arriver à une solution satisfaisante composée de plusieurs commits créés au fur et à mesure des discussions.
Ne vous découragez pas. Les développeurs principaux sont souvent exigeants, tatillons et parfois même optus. Il n’accepteront donc votre pull request que lorsque le code sera propre, testé, sans détour inutile.
J’ai ici volontairement orienté mon discours autour du projet Ruby on Rails mais le principe reste très largement similaire dans la plupart des projets étant hébergés sur Github.
Lors de vos premières contributions, le processus vous paraîtra peut-être un peu compliqué ou fastidieux mais tout cela est nécessaire pour assurer un produit de qualité. Au fur et à mesure de vos participations tout deviendra naturel et vous arriverez à proposer des tickets complets ou des pull requests répondants aux standards de qualité avec très peu d’effort et de temps.
Si votre but est d’améliorer vos compétences et mieux comprendre vos outils alors participez à des projets open source. Vous apprendrez beaucoup !
L’équipe Synbioz.
Libres d’être ensemble.
336 avenue de Dunkerque
59130 Lambersart
5 rue de douai
75009 Paris
1 rue du Guesclin
44000 Nantes
Nos conseils et ressources pour vos développements produit.