De nos jours, il est difficile de concevoir le développement d’une solution professionnelle (site web, application métier, application mobile, …) sans utiliser de composants venant du monde Open Source. Ces composants peuvent être un framework, une librairie, une base de données ou encore simplement l’implémentation d’un protocole quelconque.
Un logiciel open source n’est pas seulement un logiciel dont le code est disponible en consultation. En effet le seul fait d’ouverture de code source n’implique forcément que ce dernier peut être modifié voire utilisé. Un vrai logiciel open source doit respecter des critères de liberté étendues qui permettent notamment sa réutilisation, sa modification et la production de logiciels qui en sont dérivés. Ce sont ces critères qui permettent à un code open source de devenir un projet communautaire. N’importe quel développeur tiers pourra dès lors proposer ses modifications et contribuer ainsi à l’amélioration du code en termes de qualité, de sécurité mais aussi de fonctionnalités. Le monde open-source n’exclue pas la contribution de la part de grandes corporations, bien au contraire la présence d’un joueur important dans la vie d’un projet open source s’avère généralement très bénéfique à celui-ci.
Chez Webnet j’ai eu l’occasion de rencontrer des développeurs passionnés qui souhaitaient mettre en œuvre leur énergie, créativité et professionnalisme en participant à la vie de différents projets open source tels que le framework Symfony, la librairie d’ORM Doctrine et différents bundles liés.
Cet article tente de dresser une liste des raisons qui poussent (ou devraient pousser) les développeurs à sacrifier une part de leurs temps à la contribution aux projets open-source mais également pourquoi des sociétés comme Webnet, en tant qu’entreprise concevant des solutions digitales possèdent également un intérêt à contribuer à ces mêmes projets.
Incités par le pôle R&D de Webnet (PLANET), nos collaborateurs ont commencé à participer aux projets open source existants et ont démarré plusieurs projets open source.
La motivation des développeurs
Créer une application robuste et évolutive, de manière élégante tout en ressentant du plaisir durant son développement, requiert des composants réutilisables open source de bonne qualité. Ils devront idéalement être testés et libres de tout bug ou presque, flexibles et riches en fonctionnalité, compréhensibles et documentés… Je n’ai rien oublié ?
Les développeurs sont les consommateurs uniques de ces composants. Ils sont dans le même temps les seuls intéressés à les améliorer, la seule source de feedback et les seuls à pouvoir faire tout ça réellement.
Les développeurs débutants considèrent les frameworks et les librairies tierces comme un environnement externe pour leurs applications qui peuvent parfois leurs sembler hostiles. Ils les combattent et ils en souffrent. Avec l’expérience on commence à voir ces frameworks et librairies tierces comme partie intégrante de son application, on les adopte au sein de son espace de travail, on en accepte la responsabilité. De plus en plus on souhaite corriger le bug rencontré dans le composant tiers plutôt que le contourner. Puis on pense à élargir une fonctionnalité de composant plutôt que de créer un bout de code spécifique dans son application qui ne profitera qu’à celle-ci. Finalement la motivation première consiste à améliorer sa propre vie professionnelle, intégré dans le composant, la modification ou correction pourra profiter sans efforts à l’ensemble des autres applications sur lesquelles le développeur sera amené à travailler.
La seconde motivation est le développement professionnel et personnel d’un développeur. La contribution à un composant implique une étude approfondie d’un état actuel de ce composant. Il est nécessaire d’examiner son code source qui complète la documentation et qui souvent constitue la meilleure documentation. Ma profonde conviction est que c’est le seul moyen de devenir un expert d’un framework ou d’une librairie. En effet, la documentation classique et l’expérience d’utilisation ne suffisent pas. Quant au développement personnel, la contribution aux projets open source implique forcément des relations humaines entre personnes d’un niveau professionnel différent, d’une origine et d’un contexte culturel différents. Il faut savoir, par exemple, faire face au refus de la communauté d’intégrer votre contribution. Il faut également parfois oser défendre sa vision contre la majorité, argumenter, rassembler les gens autour de votre idée. La collaboration et le travail en équipe sont des compétences précieuses dans tous les aspects de la vie, et contribuer à l’open source est une excellente formation.
Enfin, contribuer est une idée philosophique qu’il faut prendre et donner quelque chose en retour. Bien qu’il n’y ait aucune obligation à le faire, certains développeurs ressentent la nécessité de soutenir le projet open source qu’ils utilisent selon ce précepte.
Les objectifs des sociétés
Un grand nombre de sociétés informatiques dont Webnet ont bien conscience que les projets open source jouent un rôle important dans leur métier. Un composant sécurisé et robuste signifie une application sécurisée et robuste, un client final heureux et un contrat rempli. La situation contraire est vraie aussi : la faille d’un composant open source entraîne la faille d’une application. Webnet encourage ces développeurs à reporter et à corriger les bugs mais également à élargir les fonctionnalités de projets open source.
Le support de projets open source permet également à la société de bâtir une équipe d’experts. Les experts PHP confirment par exemple leur maîtrise de Symfony soit via la certification soit par la contribution, soit les deux. Dans les yeux d’un talent qui recherche un nouveau poste, la société qui s’engage sur ces projets open source est très attractive. C’est une sorte de gage pour le candidat qu’il pourra progresser au sein de cette société, entouré de personnes compétentes qui l’aideront à améliorer ses connaissances et compétences. Personnellement, j’ai été convaincu à rejoindre Webnet du fait de la présence de plusieurs développeurs certifiés sur Symfony.
Enfin, la société contribuant aux projets open source confirme son expertise dans ce domaine aux yeux de clients potentiels tout en gagnant en visibilité par rapport à ces concurrents.
Tu m’as convaincu, comment contribuer ?
Il existe de nombreux moyens de contribuer au développement d’un projet open source. Prenons l’exemple du framework Symfony que nous utilisons majoritairement chez Webnet.
Symfony a publié un guide qui précise les étapes à suivre pour effectuer différents types de contribution. Cette description est tellement bien détaillée et précise que vous pourrez penser à la bureaucratie excessive qui règne dans Symfony. Mais je vous assure que c’est une bonne documentation (surtout pour les débutants) qui facilite beaucoup le processus d’évolution de Symfony.
Voici différentes tâches dont vous pourriez vous acquitter afin de participer à la poursuite de la réussite de Symfony :
- Reporter un bug peut sembler trop facile : il suffit de juste ajouter une nouvelle « issue » dans https://github.com/symfony/symfony/issues. Je vous conseille néanmoins de vérifier la documentation dans un premier temps, puis de faire une recherche sur internet, visiter StackOverflow en recherchant les questions qui ressemblent à la vôtre. Si vous êtes persuadé ensuite que c’est bien un bug, il vaut mieux rassembler le plus d’informations possibles pour que les autres puissent reproduire l’anomalie et la valider en tant que telle.
- La revue des « issues » est une tâche récurrente pendant la gestion d’un projet open source qui prend beaucoup de temps. Il y a ceux qui reportent des bugs, ceux qui les confirment et ceux qui les corrigent. Parfois il ne s’agit pas vraiment d’un bug mais d’une mauvaise utilisation de Symfony. Dans ce cas il faut conseiller au développeur qui a reporté l’anomalie la méthode pour éviter le problème.
On pourrait illustrer ces différentes tâches via les revues que nous avons effectuées dernièrement :
- Ici il ne s’agissait pas d’un bug de Symfony mais de Doctrine.
- Ici le bug n’a jamais pu être reproduit.
- Ici la discussion autour d’une amélioration proposée n’a pas permis d’aboutir à l’évolution envisagée.
- Ici le bug a pu être confirmé et a été corrigé.
- Une « Pull request » est une proposition de code prêt à être fusionné avec le projet. Il ne faut jamais oublier qu’avec la correction / ajout de code dans le projet il faut vérifier/corriger/ajouter des tests unitaires et des tests d’intégration.
Voici un exemple de nos « pull requests » :
Ici nous avons corrigé un bug du composant Serializer de Symfony. Le composant Serializer est conçu pour transformer les objets en un format spécifique (XML, JSON, YAML, …) et inversement. Le problème a concerné le décodage d’un objet à partir du document XML. Par sa nature XML n’indique pas si un élément enfant est un seul élément direct possible ou un tableau avec un seul élément.
Si on prend l’exemple de ce document XML :
Rien n’indique q’un un autre auteur puisse être ajouté, comme par exemple :
Auparavant le deserializer décodait ces deux documents dans des structures différentes :
Et
Notre correction a visé à harmoniser ces deux structures dans le cas où le sérialiser savait que plusieurs auteurs pouvaient être présents :
Bien que la correction ne contienne que 3 lignes de code, les tests unitaires, eux, ont pris une centaine de lignes.
- Participer aux conférences en tant que visiteur ou en tant que speaker est un moyen très plaisant pour participer à la vie de communauté. Vous êtes bienvenus au stand de Webnet sur les Symfony Live 2019 à Paris.
Enfin, au-delà de la participation à des projets tiers vous pourriez ouvrir le code de vos propres composant réutilisables. Récemment Webnet a mis en ligne une librairie permettant d’anonymiser une base de données afin de rester en conformité avec les demandes de la RGPD – Database anonymizer. Nous espérons perfectionner cette librairie grâce aux feedbacks de ses utilisateurs et proposer aux autres développeurs un outil pratique et de qualité !
