Jim Zemlin : « La seule chose qui peut ralentir l’open source, ce sont les problèmes de sécurité »

« Un grand pouvoir implique de grandes responsabilités ». Jim Zemlin, directeur de la Fondation Linux, aurait pu reprendre à son compte cette citation célèbre issue du comics Spiderman. Depuis sa création en 2000, l’organisation qu’il préside depuis 2007 a largement contribué à l’avènement des logiciels et systèmes open source. Si les OS Linux ne peuvent pas réaliser avec Windows sur le marché du desktop, le noyau Linux est au cœur de l’architecture de nombreuses solutions IT.

La standardisation des technologies ouvertes a engendré une nouvelle complexité. Les plateformes, les applications et les logiciels sont constitués de plus en plus de composants open source. Cependant, les pratiques en matière de cybersécurité n’ont pas atteint le même niveau de normalisation. La Fondation Linux a bien conscience de son influence et cherche à combler les lacunes en la matière. Dans cet entretien, Jim Zemlin exhorte les entreprises et les développeurs à renforcer la sécurité de leurs solutions et systèmes.

LeMagIT : Lors du premier jour de l’Open Source Summit Europe, vous vous êtes évertués à pointer du doigt les défauts des logiciels ouverts ainsi que les problèmes légaux rencontrés. Pourquoi cela ?

Jim Zemlin : Au cours des quinze dernières années, je me suis présenté devant les gens pour leur dire ô combien l’open source est formidable, donc je pense que nous devons aussi travailler sur les aspects qui ne le sont pas autant. Nous sommes arrivés au point où l’open source est devenue une partie omniprésente de n’importe quel produit ou service technologique. Cela fait fonctionner tout, particulièrement Linux. Selon les études que j’ai consultées, Linux représente 100 % du marché des superordinateurs. C’est 80 % du secteur des smartphones, c’est 65 % des systèmes embarqués, c’est la majorité des environnements informatiques en entreprise, c’est 90 % des services cloud public, tout comme 75 % des applications modernes. L’open source est une composante critique de l’industrie et même de la société.

Cela engendre des responsabilités. Il faut s’assurer qu’un logiciel ou un OS comme Linux fournissent un haut niveau de sécurité, de robustesse, etc. Ces systèmes ouverts peuvent impacter un grand nombre de personnes et nous devons faire en sorte de minimiser les aspérités, même si cela est très difficile à faire. Un projet comme KernelCI, qui est un environnement de test du noyau Linux est très important parce que la qualité de cet élément affecte tout le monde. Les utilisateurs de mobiles profitent de ces meilleures phases d’essai, principalement pour éviter les problèmes de sécurité. Je pense que vous allez me voir parler constamment de cet aspect à l’avenir.

Quant aux difficultés autour de la propriété intellectuelle, c’est un sujet sans fin (rire). Les gens aiment engager des procès contre d’autres personnes pour un rien. Ce que nous voulons, c’est faire en sorte que l’innovation et les logiciels ne soient pas inhibés par des défis légaux.

LeMagIT : Pouvez-vous (re) présenter KernelCI, l’objet de la principale annonce de l’Open Source Summit Europe ?

Jim Zemlin : La communauté et les éditeurs ont enfin choisi un seul framework de tests pour le noyau Linux. Habituellement, ils le faisaient dans leur côté sans échanger leurs résultats. C’est le moment où tout le monde se dit « nous allons adopter ce framework afin de partager les données de toutes les opérations effectuées ». Cela devrait améliorer la couverture de tests et augmenter de manière significative la remontée de bugs grâce aux rapports des entreprises participantes. Aujourd’hui, nous avons encore un problème de ce côté-là, parce que cela implique de vérifier un grand nombre de configurations. KernelCI devrait être la réponse à ce problème.

LeMagIT : 225 projets ont rejoint la Fondation Linux. Comment faites-vous pour maintenir une cohérence dans leur gestion ?

Jim Zemlin : Chaque projet dispose de sa propre infrastructure et beaucoup d’entre eux profitent de GitHub. Nous n’avons pas besoin de réinventer cet outil. Je pense que notre rôle est de mettre en place des procédures qui vont au-delà du fait de publier du code sur GitHub. Que ce soit des événements comme l’OSSE, des programmes de formation ou la tenue des audits de sécurité – par exemple la Cloud Native Foundation nous engage pour des tests de haut niveau –, c’est ce genre de choses que nous faisons pour tous les projets hébergés par la fondation. En fait, je passe un temps considérable à construire une infrastructure évolutive qui permet à tous les membres de profiter des mêmes procédures et connaissances des systèmes pour conduire leurs avancées.

LeMagIT : Vous n’avez donc pas de conflits entre les projets ?

Jim Zemlin : Oh, nous avons des conflits. Nous avons listé les meilleures pratiques, mais nous ne les avons pas rendues obligatoires. J’aimerais que les membres de la Fondation adoptent un ensemble commun de procédures, mais cela reste difficile de l’imposer à tout le monde. Nous laissons les gens prendre leur propre disposition, j’ai juste besoin de concevoir le processus pour intégrer cette dimension.

LeMagIT : Parfois, les projets au sein d’une même communauté ou d’une fondation se chevauchent, sont des doublons. Rencontrez-vous ce type de situation ?

Jim Zemlin : Nous évitons de nous retrouver dans cette situation. Les projets vivent généralement un cycle de vie identique. Vous avez le code initial, les développeurs commencent à en entendre parler, puis la solution est adoptée, ensuite cela conduit à une phase de maintenance. Nous essayons de les gérer tout au long de ce cycle le plus efficacement possible en réduisant le nombre de doublons.

Mais à chaque étape, il y en a. Au départ, c’est souvent une question d’innovation, car les développeurs établissent plusieurs concepts. Ce n’est pas grave. Par exemple, les environnements de containerisation Kubernetes, Docker ou encore DockerSwarm cohabitent. Mais à un certain moment, il ne doit en rester qu’un. Pour l’instant, Kubernetes l’emporte, mais une autre technologie pourrait le remplacer à l’avenir.

LeMagIT : Quelles sont les priorités actuelles de la Fondation Linux ?

Jim Zemlin : Je me concentre sur des sujets concernant la sécurité, les architectures hardware ouvertes – en impliquant Risc-V, Open Power et la Chips Alliance – et l’open data. Nous recevons également beaucoup de demandes de la part d’entreprises qui veulent comprendre la stratégie générale liée à l’open source et comment gérer et maintenir les logiciels ouverts. Nous avons mis en place une initiative nommée « To Do Group » dont le but est d’apprendre à ces sociétés à mieux gérer ces processus.

LeMagIT : En 2016, vous disiez aux entreprises « êtes-vous prêts pour l’open source ? » Que leur dites-vous maintenant ?

Jim Zemlin : Je pense que le positionnement derrière cette question reste d’actualité concernant certains aspects. Les professionnels doivent être prêts à adopter un plus haut niveau de sécurité dans un contexte open source. Ils doivent s’occuper correctement de leurs chaînes d’outils qui contiennent énormément de composants libres. Les gens devraient se préparer pour cela maintenant. En fait, c’est déjà trop tard (rire).

LeMagIT : Concernant la gestion des logiciels open source, ne pensez-vous pas que les services managés sont la solution ?

Jim Zemlin : Non, vous devez encore savoir ce qu’il y a dans votre stack. Vous pouvez utiliser les services d’un fournisseur de cloud, mais vous ne pouvez pas externaliser les décisions techniques. Cela ne veut pas dire pour autant que les entreprises comme IBM, Google, WMware et autres font un mauvais travail, au contraire.

LeMagIT : Dans un entretien avec LeMagIT, Michael Howard, PDG de MariaDB, assure que l’open source vit une époque de renaissance parce qu’enfin il y a un modèle économique rentable : celui du cloud. Partagez-vous cet avis ?

Jim Zemlin : Quand j’ai rencontré ma femme il y a quinze ans, elle m’a demandé lors de notre premier rendez-vous quel métier j’exerçais. Je lui ai répondu que je travaillais pour cette ONG [Le Free Standard Group N.D.L.R.]. Elle était très déçue. Je plaisante, mais quinze ans plus tard nous vivons bien cette renaissance de l’open source. Et je pense que cela ne va pas ralentir, en fait son adoption accélère. Le nombre de lignes de code et de programmes nécessaires pour faire fonctionner une application moderne ne peut pas provenir d’une seule entreprise.

L’ère du « social coding » sur GitHub en est la preuve. La seule chose qui peut ralentir l’open source, ce sont les problèmes de sécurité. Ils pourraient entamer la confiance dans ces technologies. Je pense que cela s’applique également aux solutions propriétaires. La complexité de la chaîne de logiciels devient très difficile à gérer. Vous avez des millions de projets, et vous avez des centaines, parfois des milliers de composants dans tous les produits. Suivre à la trace tous ces éléments est presque impossible.

Combien de projets sont accessibles depuis GitHub ? Plus de 78 millions. Combien d’entre eux sont-ils vraiment utiles ? Peut-être 5000 ? 2000 ? Nous avons conduit plusieurs recherches pour savoir quels sont ceux qui sont les plus partagés dans le monde, qui les écrit et pourquoi ils le font. Finalement de ces 78 millions de projets disponibles sur GitHub, les développeurs en utilisent environ 1 % tous les jours.

Ces programmes populaires sont mis au point par 10-20 % des membres de la communauté qui écrivent la majorité du code. Les autres repèrent et corrigent les bugs. Je pense qu’il est très important de savoir qui se trouve derrière ces logiciels ou ces éléments. Ces développeurs doivent être appréciés à leur juste valeur. Ils permettent de comprendre comment un projet a été construit pour en renforcer la sécurité, par exemple. Sans cette approche, l’open source risque de perdre son élan.

LeMagIT : Pensez-vous qu’une chaîne d’outils normalisée permettrait de réguler la complexité de l’open source ?

Jim Zemlin : Nous essayons de créer des standards concernant l’échange de paquets de données dans les logiciels, nous essayons d’automatiser la gestion des builds, nous essayons d’identifier les projets de sécurité importants qui peuvent aider à résoudre ce type de problème. Nous observons comment améliorer la sécurité des gestionnaires de paquets, etc. Il y a beaucoup de choses qui peuvent être faites pour cela.