Créer un module JHipster : une façon de contribuer à l’open source

De nombreux logiciels utilisés aujourd’hui, notamment par les développeurs, sont open source : Linux, Git, MySQL, Node.js, Docker, etc. On entend souvent parler de ce terme sans même savoir vraiment de quoi il en retourne.

Qu’est-ce que l’open source ?

Pour commencer, il convient de définir ce qu’est l’open source. C’est un concept qui désigne un code source ouvert et qui s’applique aux logiciels mais également à tout type d’invention. Est considéré comme open source un logiciel ou une invention dont la licence répond aux critères fixés par l’Open Source Initiative (OSI) fondée en 1998 aux États-Unis pour se démarquer du logiciel libre (free software).

Logo de l’Open Source Initiative

Les dix critères listés dans l’Open Source Definition sont les suivants :

1. Redistribution libre : La licence n'empêche aucune partie de vendre ou de céder le logiciel
2. Code source : Le programme doit inclure le code source et doit permettre la distribution tant du code source que de sa forme compilée
3. Travaux dérivés : La licence doit permettre les modifications et les travaux dérivés, ainsi que leur distribution dans les mêmes conditions que la licence du logiciel original
4. Intégrité du code source de l'auteur : La licence doit explicitement autoriser la distribution de logiciels construits à partir de code source modifié
5. Pas de discrimination contre les personnes ou les groupes : La licence ne doit pas discriminer une personne ou un groupe de personnes
6. Pas de discrimination contre des domaines de compétences : La licence ne doit empêcher personne d’utiliser le programme dans un domaine d’activité spécifique
7. Distribution de la licence : Les droits attachés au programme doivent s'appliquer à tous ceux à qui le programme est redistribué, sans nécessité de conclure une licence additionnelle avec ces parties
8. La licence ne doit pas être spécifique à un produit : Les droits attachés au programme ne doivent pas dépendre de son appartenance à une distribution logiciel particulière
9. La licence ne doit pas restreindre d'autres logiciels : La licence ne doit pas imposer de restrictions à d'autres logiciels distribués avec le logiciel sous licence
10. La licence doit être neutre sur le plan technologique : Aucune disposition de la licence ne peut être basée sur une technologie ou un style d'interface individuel

Il est important de souligner que le fait de créer un dépôt GitHub ou GitLab ne fait pas d’un projet un projet open source.

Quelles sont les différences avec le logiciel libre ?

La Free Software Foundation créée par Richard Stallman en 1985 pose quatre règles pour définir un logiciel comme étant libre :

1. La liberté d'exécuter le programme, pour tous les usages
2. La liberté d'étudier le fonctionnement du programme et de l'adapter à ses besoins
3. La liberté de redistribuer des copies du programme (ce qui implique la possibilité aussi bien de donner que de vendre des copies)
4. La liberté d'améliorer le programme et de distribuer ces améliorations au public, pour en faire profiter toute la communauté.

On voit tout de suite que certains critères se recoupent dans les deux définitions : liberté d’exécution, de lecture, de modification, d’amélioration et de partage.

Il existe deux grands types de licences. D’un côté, les licences possédant un copyleft par opposition au copyright bien que les deux possèdent des similitudes. De l’autre, celles n’en possédant pas.

Voici une définition du copyleft :

“Le copyleft est une méthode générale pour rendre libre un programme (ou toute autre œuvre) et obliger toutes les versions modifiées ou étendues de ce programme à être libres également.”

Copyleft

Concrètement, côté logiciel libre, la principale licence utilisée est celle intégrant un copyleft : la licence publique générale GNU ou GPL (la v3 datant de 2007). Côté open source, dans la pratique, figurent principalement deux grandes licences sans copyleft : la BSD et l’Apache 2.0. En réalité, la notion d’open source et de logiciel libre se recoupent et sont confondues bien souvent.
Je ne m’attarderai pas ici sur les subtilités entre chaque licence car l’OSI propose une description détaillée des licences libres et open source.
Il est important de noter qu’une majorité de logiciels open source sont également des logiciels libres et que cela a causé un abus de langage au fil des années.

Une autre différence entre open source et logiciel libre réside dans le fait que le logiciel libre met surtout l’accent sur une certaine philosophie alors que l'open source a une vocation plus marquée à commercialiser ses logiciels. Le logiciel libre comme l’explique Richard Stallman “fait campagne pour la liberté des utilisateurs de l'informatique” alors que l’open source “met surtout l'accent sur les avantages pratiques et ne fait pas campagne pour des principes”. Richard Stallman dit souvent que le logiciel libre est à prendre dans le sens de “liberté d’expression” plutôt que d’”entrée libre”. L’open source insiste en outre sur le fait que la conception et le développement d’un logiciel n’est pas gratuit. Certaines entreprises créent d’ailleurs des outils open source respectant totalement les critères de l’OSI tout en proposant à côté des prestations payantes, notamment de support. L’un des excès observés par rapport à cela est celui de l’openwashing qui est au logiciel open source ce que le greenwashing est à l’écologie, certaines personnes n’hésitant pas à saupoudrer leurs offres commerciales d’open source pour vendre sans respecter les principes sous-jacents.

Signalons aussi au passage que certaines organisations pratiquent l’inner source. C’est le cas de Leroy Merlin et Adeo ou encore Décathlon qui sous leur organisation GitHub proposent l’ouverture en interne du code de leurs projets à tous leurs collaborateurs susceptibles d’avoir besoin de ces projets. Il s’agit ici d’appliquer les principes de l’open source au sein d’une entreprise et de son système d’information.

Enfin, le concept d’open source s’oppose évidemment à celui de closed source ou logiciel propriétaire qui ne remplit donc pas les critères de l’OSI. Certains outils sont dans ce schéma avant d’ouvrir leurs sources lors de la mise à disposition d’une version majeure. Ce fut par exemple le cas du framework Vue.js pour la version 3.

Pourquoi contribuer à l’open source ?

Il y a de nombreuses raisons de contribuer à l’open source :

• Pour un besoin spécifique sur un outil ou un projet disponible et utilisé sur son propre projet ou son périmètre chez un client ou sur un projet personnel. Pourquoi ne pas corriger un bug ou proposer une évolution sur Quarkus ou Kubernetes ?
• Pour monter en compétence en développant, en découvrant de nouveaux patterns de développement ou d’architecture et surtout en rencontrant des gens expérimentés qui ont des connaissances souvent pointues dans certains domaines.
• Pour participer à un projet intéressant et porteur de sens, utile à la société, utile à de nombreux développeurs.
• Pour remonter un bug ou une faille de sécurité sur un outil utilisé massivement.
• Pour faire partie d’une ou plusieurs communautés.
• Pour sortir de sa zone de confort et se remettre en question pour progresser.

Comment contribuer à l’open source ?

Il n’est parfois pas facile de trouver un sujet ou un projet sur lequel on se sent légitime et sur lequel on souhaite investir du temps. Il existe néanmoins de nombreux moyens d’apporter sa contribution à l’open source.

L’idéal est évidemment d’avoir déjà ciblé un ou plusieurs projets sur lequel on peut apporter quelque chose. Il s’agira alors en général soit d’un projet que l’on connaît déjà et sur lequel on veut apporter notre pierre à l’édifice (par exemple JHipster ou Quarkus), soit d’un outil ou d’une application que l’on utilise plus ou moins régulièrement sur un périmètre donné et que l’on souhaite améliorer ou corriger.

Si l’on a déjà une idée intéressante, il est bien sûr possible de créer son propre projet open source respectant les critères de l’OSI et en choisissant une licence adaptée.

Enfin, certaines initiatives permettent à certaines occasions de se lancer. C’est le cas du Hacktoberfest qui se déroule comme son nom l’indique en octobre en clin d'œil à l’Oktoberfest, la fête de la bière de Munich en Allemagne. L’objectif à atteindre ici est au moins quatre pull requests, qu’elles soient validées ou non, sur des projets open source participant à l’initiative. Ippon propose à cette occasion souvent des soirées pour y contribuer !

JHipster aussi possède ses propres évènements avec par exemple la JHipster Conf à Paris en 2018 et 2019 avec des conférences en français et en anglais puis en 2020 le JHipster Code à Bordeaux plutôt axé sur une journée de contribution sur des sujets donnés. L’open source a d’ailleurs été abordé lors d’une conférence sur OpenCollective de Pia Mancini en 2019.

Une fois un projet open source trouvé, comment concrètement y contribuer ? De multiples façons :

• en proposant de la revue de code sur des pull ou merge requests
• en proposant soi-même des pull ou merge requests pour corriger des bugs ou proposer des améliorations
• ou encore en créant des issues pour remonter des bugs ou proposer des améliorations.

En général pour proposer des pull ou merge requests il est nécessaire de faire un fork du projet pour pouvoir demander un merge sur la branche principale du projet. À moins d’être ajouté comme contributeur officiel au projet, auquel cas le fork n’est pas obligatoire.

Un élément important à connaître est le CONTRIBUTING.md qui est un fichier markdown à la racine d’un projet et qui permet de savoir comment contribuer et respecter les règles définies au sein de celui-ci (cela peut être des règles de nommage ou des façons de faire sur un périmètre donné).

Comment contribuer à JHipster ?

Un petit rappel de ce qu’est JHipster : un générateur d’applications full-stack basé sur la stack Spring Boot pour le back-end et Angular, React ou Vue pour le front-end. La dernière version majeure (v7) en date est sortie en mars 2021 et comporte de nombreuses nouveautés. JHipster est sous licence open source Apache 2.0. Ce qui signifie concrètement qu’il est possible de l’utiliser et de se baser dessus pour générer des applications destinées à une application commerciale chez un client.

Pour prendre la mesure de l’importance de JHipster en tant que logiciel open source, quelques chiffres s’imposent : à l’heure où j’écris cet article, l’outil a été téléchargé 170338 fois au cours des 30 derniers jours, il a 18410 étoiles sur GitHub et a plus de 600 contributeurs.

Il est possible de contribuer de différentes manières à JHipster :

• Répondre sur les dizaines d’issues présentes et parfois créer une pull request associée pour corriger un bug ou proposer une amélioration
• Faire la chasse aux bugs et aux failles de sécurité
• Participer à la construction de la prochaine version majeure v8 (le socle Yeoman pourrait être remis en question par exemple)
• Créer un blueprint ou un module en fonction de son besoin si le générateur principal ne propose pas une fonctionnalité et s’il n’est pas possible de l’intégrer à ce dernier

Pour encourager les développeurs à contribuer l’association JHipster derrière le projet propose des récompenses sous la forme de bounties allant de 100 à 500 $ en fonction de la criticité et de la difficulté, ce qui n’est pas négligeable !

Il est important de se baser sur le CONTRIBUTING.md du projet pour suivre les guidelines, connaître les contrôles à effectuer et savoir comment pousser sa pull request après avoir fait un fork.

L’une des caractéristiques principales de JHipster est sa modularité. Il comporte de nombreux modules accessibles via la marketplace. Les modules compatibles avec la dernière version majeure portent le tag npm jhipster-7. La documentation rappelle comment il est possible de créer un module sur JHipster notamment via le générateur de module JHipster.

Pour ma part, j’ai commencé à travailler sur JHipster en 2019 à mon arrivée chez Ippon en rejoignant la practice JHipster. Depuis, nous disposons chaque mois d’une journée de contribution par mois (sans compter le temps personnel à côté). Avant la crise sanitaire nous nous déplacions tous à l’agence à Paris pour échanger ensemble : point global pour introduire la journée sur les sujets en lien avec le projet, gros sujets à prendre, travail en groupe sur certains de ces sujets ou des issues. À distance, nous disposons d’un Slack dédié aux contributeurs en anglais et en français.

Rapidement, j’ai choisi de lancer le module Kafka pour JHipster notamment pour intégrer les APIs Producer et Consumer de Kafka. En quelques mois une première version majeure du module utilisable sur un projet en production est sortie. Depuis, certaines évolutions ont eu lieu mais de nombreuses choses restent à faire car Kafka comme JHipster évoluent rapidement. Par exemple, côté Kafka avec l’arrivée de la version 2.8 la dépendance à ZooKeeper disparaît, il faudra donc prendre ce changement en compte dans une prochaine version. De même, il a fallu prendre en compte les modifications effectuées dans le noyau de JHipster lors de la sortie de la version 7.

La principale difficulté est de rentrer dans le code de JHipster car il est basé sur Yeoman et le système d’Embedded JavaScript Templating peut vite devenir un vrai plat de spaghettis. L’idéal est de commencer en pair ou en mob programming avec un développeur expérimenté du projet. Un autre frein peut être de trouver d’autres personnes pour travailler sur un sujet précis. Il est alors nécessaire de bien communiquer sur GitHub (issues, projet principal…), Workplace, Slack ou Twitter pour s’organiser.

Si cela vous intéresse, il reste une vingtaine d’issues dont certains gros sujets, alors n’hésitez pas à venir y contribuer ;-) !