Comment et pourquoi publier vos projets d'entreprise en open source

Ludwine Probst : Bonjour à toutes et à tous, je suis Ludwine et vous écoutez le podcast Human Coders. Dans chaque épisode de ce podcast, j'invite un ou une dev ou un professionnel de l'informatique pour parler de techno, de pratiques de développement ou de sujets plus généraux, mais toujours en lien avec l'informatique. Au programme également, des parcours de dev qui, j'espère, vous inspireront. Tous les épisodes sont disponibles sur SoundCloud ou votre application de podcast préférée. Pensez à vous abonner et à nous laisser des commentaires ou des likes, ça nous fera toujours plaisir. Bonjour Pierre-Yves.

Pierre-Yves Lapersonne : Bonjour.

Ludwine Probst : Est-ce que tu peux commencer par te présenter s'il te plaît ?

Pierre-Yves Lapersonne : Je m'appelle Pierre-Yves Lapersonne, je suis ingénieur logiciel chez Orange où je travaille notamment sur les applications mobiles iOS et Android. Je fais aussi partie de ce qu'on appelle la gouvernance open source du groupe, qui fait que j'accompagne différents projets dans leur volonté de publier des éléments en open source, de contribuer à des projets existants ou d'embarquer de l'open source au travers de produits.

Ludwine Probst : Aujourd'hui, on va parler d'open source dans le cadre de l'entreprise. Est-ce que tu peux nous donner un petit peu de contexte ?

Pierre-Yves Lapersonne : Le constat est simple : lorsqu'on travaille dans une ESN, une SSII, chez un éditeur de logiciel ou dans une boîte qui fait du développement, à un moment, on peut se poser la question de savoir si on veut publier quelque chose en open source ou pas. Le faire est tout sauf anodin. Cela implique beaucoup de choses sur le plan juridique et légal, cela peut avoir des impacts sur le portefeuille de brevets ou sur le business. Quand on a la tête dans le guidon et qu'on travaille sur sa librairie ou son projet, on peut soit avoir des freins et ne pas avoir envie de publier parce que c'est notre "bébé", soit avoir envie de le faire mais il ne faut pas le faire n'importe comment. La question est de savoir à quoi il faut faire attention avant de se lancer pour éviter de faire des boulettes.

Pourquoi publier un projet en open source ?

Ludwine Probst : Dans quel cas est-il pertinent de publier son projet en open source ? On n'a pas forcément toujours intérêt à le faire.

Pierre-Yves Lapersonne : Cela dépend de ce qu'on veut faire. Quand on publie quelque chose en open source, si on s'en donne les moyens, cela permet d'attirer des compétences et des contributeurs qu'on n'a pas forcément au sein de la boîte. Si je crée un outil ou un projet mais que je manque de développeurs ou que j'ai perdu la compétence entre-temps, le mettre en open source va attirer des gens partout dans le monde qui vont se dire que le projet est sympa et vont avoir envie de contribuer. C'est une façon de sous-traiter les contributions et les évolutions à des personnes qui ont des compétences que tu n'as plus.

Ludwine Probst : Cela peut aussi avoir un avantage pour le recrutement ou pour l'image de l'entreprise ?

Pierre-Yves Lapersonne : En 2020, une boîte dans la tech qu'on ne voit pas en conférence, dans des meetups, dans des user groups et qui ne fait pas d'open source, on finit par se poser des questions sur sa visibilité. Il y a aussi le fait que parfois, tu n'as pas le budget pour recruter, mais des personnes sur leur temps libre vont contribuer. Pour les développeurs, les profils GitHub ou GitLab servent de portfolio. Si quelqu'un contribue à des projets sérieux, on voit que c'est une personne motivée.

Ludwine Probst : On n'a pas forcément le temps en interne de développer un projet de grande envergure. L'ouvrir permet d'avoir plus de bras et un impact plus fort.

Pierre-Yves Lapersonne : Parfois, tu te concentres sur ton projet pour réduire le time-to-market, mais il te manque des développeurs. L'ouvrir en open source, si tu cloisonnes bien les features que tu veux, permet d'avoir des regards externes qui vont te signaler des failles de sécurité ou des points à revoir. Tu gagnes en compétences par rapport à ce que tu as déjà.

Les freins et les points d'attention

Ludwine Probst : Vois-tu des freins qui pourraient faire douter les entreprises ou les développeurs ?

Pierre-Yves Lapersonne : Il peut y avoir des blocages légaux. Si tu as un portefeuille de brevets sur ton produit et que tu publies en open source, tu risques de dégommer ton portefeuille. Il faut aussi faire attention si une filiale ou un partenaire a un produit équivalent sur lequel il base son business ; tu pourrais lui savonner la planche. Il y a aussi la propriété intellectuelle. Si tu travailles pour un client ou avec un prestataire, la paternité du code peut ne pas t'appartenir. C'est ce qui est défini au travers des CLA (Contributor License Agreement) qui définissent les termes et à qui appartient le code.

Ludwine Probst : Si je décide de me lancer, à quoi dois-je faire attention dans le code ?

Pierre-Yves Lapersonne : Il faut faire attention à tout. D'abord, s'assurer qu'il n'y a pas de données sensibles : adresse IP publique, mots de passe (même de test), identifiants ou adresses mail. Des adresses mail qui fuitent, c'est une porte d'entrée au phishing. Ensuite, attention au copier-coller de code. On va tous sur Stack Overflow ou GitHub, mais si tu récupères du code sur GitHub qui n'a aucune licence, il est par défaut propriétaire. Ce n'est pas intuitif, mais c'est comme ça.

Ludwine Probst : Comment être sûr qu'on a le droit de prendre un code sur GitHub ?

Pierre-Yves Lapersonne : Il faut regarder s'il y a un fichier LICENSE. S'il n'y en a pas, c'est propriétaire. Il faut aussi se poser la question de l'originalité du code. Si c'est juste un code qui ouvre une connexion et traite un JSON, l'originalité est pauvre et n'importe qui l'écrirait de la même façon. Par contre, pour des algorithmes plus complexes, c'est différent. Il faut aussi vérifier les licences des dépendances et s'il n'y a pas de clauses particulières, comme des licences "éthiques" qui interdisent l'utilisation pour l'armement ou qui imposent de payer si on dépasse un certain chiffre d'affaires. Des organismes comme la Free Software Foundation ou l'Open Source Initiative surveillent cela. On peut utiliser des outils comme Fossology pour scanner le code et générer un rapport sur les licences et copyrights.

Les étapes de la publication

Ludwine Probst : Une fois le code nettoyé, quelle est l'étape suivante pour publier ?

Pierre-Yves Lapersonne : Il faut préparer le projet pour la publication.

1. Choisir la licence : Il en existe plus de 200. Il y a les licences permissives (MIT, BSD), les licences avec plus de conditions (Apache 2) ou les licences très protectrices et radicales (GPLv3). Le site choosealicense.com peut aider à choisir.
2. Créer le fichier AUTHORS.txt : Pour lister tous les contributeurs. C'est important de créditer les gens, même pour une contribution significative unique.
3. Créer le fichier THIRD-PARTY.txt : Pour lister tous les composants open source utilisés, leurs URL et leurs licences. Certaines licences imposent de mentionner explicitement l'utilisation de la librairie.
4. Ajouter les en-têtes de fichiers : Un petit cartouche avec le copyright et la licence pour éviter d'inclure tout le texte de la licence dans chaque fichier.
5. Préparer la collaboration : Créer un fichier CONTRIBUTING.md pour définir les règles de contribution (merging, coding style).
6. Mettre en place le CLA ou le DCO : Le DCO (Developer Certificate of Origin) est une option lors des commits où le développeur certifie qu'il a le droit de faire cette contribution et qu'il connaît la licence.

Ludwine Probst : On a oublié de parler du README.md !

Pierre-Yves Lapersonne : C'est indispensable. Il doit expliquer à quoi sert le projet, comment l'utiliser, comment le compiler et donner la roadmap. Un bon README avec des captures d'écran suscite l'adhésion et donne envie de forker le projet.

Zoom sur les licences

Ludwine Probst : Peux-tu détailler les types de licences ?

Pierre-Yves Lapersonne : On peut les classer en trois familles :
- Permissives (MIT, BSD) : Très simples, peu de contraintes sur la propriété intellectuelle ou les brevets.
- Semi-protectrices (MPL, Apache 2, Eclipse Public License) : Apache 2 permet de breveter le code en ton nom si c'est toi qui l'as publié, ce qui te protège un peu.
- Protectrices / Copyleft (GPLv3) : Très fortes, elles imposent de rendre disponibles les sources si tu les modifies. C'est l'esprit "libre" à fond pour éviter que d'autres ne fassent du business fermé dessus.

Ludwine Probst : Est-ce qu'on a le droit de changer de licence en cours de route ?

Pierre-Yves Lapersonne : Je pense que oui, certaines licences permettent de proposer des dérivés sous d'autres licences, mais il vaut mieux vérifier avec un juriste pour en être certain.

Ludwine Probst : Est-ce indispensable d'être accompagné par un juriste ?

Pierre-Yves Lapersonne : Selon ton business, ton portefeuille de brevets et la taille de ta boîte, avoir les conseils d'un juriste est nécessaire, voire indispensable, pour ne pas se louper sur des contrats ou des brevets.

Ludwine Probst : Combien de temps prend toute cette procédure ?

Pierre-Yves Lapersonne : Ça dépend. Un petit projet from scratch sans enjeux de brevets peut être prêt en une journée. Un projet plus gros avec des partenaires et des clauses exotiques peut prendre plusieurs semaines ou mois selon le nombre d'interlocuteurs.

Ludwine Probst : Existe-t-il des communautés d'entraide ?

Pierre-Yves Lapersonne : L'Open Source Initiative, la Free Software Foundation, Stack Overflow (pour les questions plus "philosophiques" sur les licences) et les retours d'expérience d'autres entreprises sont de bonnes sources.

Ludwine Probst : Un dernier mot pour conclure ?

Pierre-Yves Lapersonne : La publication en open source ou la contribution apporte du "fun" et est un vrai catalyseur social au sein d'une boîte. Ça attire des talents, ça donne une bouffée d'air frais aux développeurs et ça permet de créer de belles histoires. Il faut tenter l'aventure, mais en se donnant les moyens de bien faire les choses.

Ludwine Probst : Merci beaucoup Pierre-Yves. Si vous avez des questions, n'hésitez pas à nous laisser un commentaire sur notre blog blog.humancoders.com ou à contacter Pierre-Yves directement. À bientôt pour un nouvel épisode !