L'identité est importante dans l’open source, mais pas dans le sens que l’on pourrait croire. Par exemple, Lili Cosic travaille pour Red Hat, et elle est également responsable de la maintenance au sein de la communauté Kubernetes, et responsable de kube-state-metrics. Si Red Hat encourage Lili Cosic dans le travail qu’elle effectue pour Kubernetes, l’entreprise n’a pas de regard sur son implication. L'open source est un domaine distinct et personnel. Ou, comme l'a expliqué Mme Cosic dans une interview, dans l'open source, « vous portez toujours la casquette de l'entreprise, et vous portez aussi la casquette de responsable de la maintenance, mais vous veillez toujours à bien séparer les deux rôles ».

Lili Cosic situe ce premier lien particulier avec l’open source à ses 13 ans, le jour où sa mère lui a acheté un ordinateur. C’est là qu’elle s’est mise à développer de « petites choses comme des scripts ou des pages web ou des choses comme ça ». Mais son exploration du codage ne s'est pas arrêtée là, et il est utile de comprendre le processus par lequel elle est devenue une mainteneuse de Kubernetes, et le rapport avec son travail chez Red Hat.

Une faute de frappe et un travail cohérent

La première contribution de Lili Cosic n'était pas particulièrement prometteuse. Selon elle, son chemin vers l'open source a démarré par une faute de frappe : « Je pense que cette expérience de la faute de frappe est vécue par la majorité des développeurs. C’est elle qui m’a poussé à ouvrir une requête pull dans le document ReadMe de Docker ». Encouragée par sa capacité à participer et à améliorer un projet, Lili Cosic s’est un peu plus impliquée. Et de plus en plus… Ses contributions ne concernent pas les fonctionnalités les plus remarquables de Kubernetes ou d'autres projets. Et ce n'était pas, selon elle, la meilleure façon de contribuer au projet. « La cohérence est la clé. Peu importe si l’on contribue à de gros morceaux ou à de petits morceaux de code. L’essentiel est de contribuer de manière cohérente sur une certaine période.

En général, cette contribution doit être constante pendant au moins quelques mois, ce qui inclut l'examen des requêtes pull et la réponse aux questions sur GitHub Issues ou sur les listes de diffusion ou sur Slack ou quelque chose de ce genre ». Comme l’explique encore, « en fait, il est préférable de contribuer à de plus petits morceaux afin de connaître l'ensemble de la base de code. Si vous ne contribuez qu'à une seule fonctionnalité importante, vous ne connaîtrez jamais la base de code complète. Certes, vous pouvez devenir responsable de cette fonctionnalité, mais pas de l'ensemble du projet ».

Mais c’est l'approche communautaire de Kubernetes qui a surtout favorisé son intérêt pour la contribution.

Ce que la communauté Kubernetes a compris

D’après de nombreux témoignages, Kubernetes est différent. Alors que Linux a la réputation d'être une communauté parfois caustique, la communauté Kubernetes est accueillante. C’est aussi l’avis de Lili Cosic : « Tout n'est pas parfait, mais la communauté Kubernetes est l'une des plus accueillantes communautés open source que je connaisse ». Et elle attribue sans hésiter cette différence à la nature du groupe de contributeurs de Google : « Je pense que c’est très lié au fait que beaucoup de mentorés du Google Summer of Code (GSoC) étaient des femmes. Parmi elles, on trouve par exemple Nikhita Raghunath, membre du GSoC en 2017, qui fait maintenant partie du Comité directeur de Kubernetes. En termes de pourcentage, les femmes restent minoritaires, mais c'est plus encourageant ».

« Un autre avantage de la communauté Kubernetes, c’est qu’elle permet de démarrer un projet de zéro, et pas forcément de s’impliquer dans un projet bien établi. De plus, la communauté Kubernetes est volontairement inclusive », a-t-elle ajouté. « Á la Cloud Native Computing Foundation (CNCF), une équipe entière est dédiée à l’amélioration de l'expérience de la contribution, ce qui aide beaucoup. Ils font beaucoup d'efforts pour être accueillants avec les nouveaux arrivants ». Sur le plan émotionnel, il pourrait sembler souhaitable d’éprouver le « syndrome de l'imposteur » à certains degrés, mais dans le domaine de la technologie, pour les groupes sous-représentés, cela peut être plus difficile à surmonter. « Á long terme, cette atmosphère accueillante peut encourager plus de diversité parmi les contributeurs ». Ce qui, à son tour, peut améliorer la qualité des logiciels.

Communauté/Entreprise : le respect des rôles

Mais cette diversité n'a pas vraiment de rapport avec les entreprises qui paient les salaires des développeurs. Ce sont les développeurs eux-mêmes qui sont reconnus au sein d'un projet. Il est pratique de supposer qu'un ingénieur travaillant pour IBM, par exemple, contribue au code de tel ou tel projet de l’entreprise. Cela peut être le cas des projets où IBM est le contributeur dominant (ou le seul contributeur), mais ce n'est pas ce qui se passe dans l'open source en général. L’Apache Software Foundation est très explicite sur ce point : « Nous croyons fortement dans le respect des rôles. Votre rôle au sein de l’ASF vous est assigné personnellement et vous est confié par vos pairs. Il n'est pas lié à votre emploi ou à votre employeur ou à votre entreprise actuels ».

Lili Cosic a été tout aussi claire quand on lui a demandé quel impact son rôle chez Red Hat OpenShift pouvait avoir sur son travail pour Kubernetes : « On a toujours conscience d’avoir deux casquettes. On porte toujours le chapeau de l'entreprise, mais on reste aussi responsable de maintenance et l’on fait toujours en sorte de bien séparer les deux. On veut toujours s’assurer de cette distinction pour le bien du projet ». Mais, on peut toujours se demander si son travail sur kube-state-metrics ne la met pas en position d’orienter le projet au profit de Red Hat ? « Les responsables de la maintenance ne travaillent pas nécessairement sur les fonctionnalités. Ils sont là pour s'assurer que le projet est sain... Chaque fois que je prends une décision sur les fonctionnalités, je n’y pense jamais du point de vue Red Hat. Je me demande si elle s’inscrit bien dans l’objectif du projet ? », a-t-elle répondu. « Récemment, une personne de Red Hat a ouvert une fonctionnalité. Or ce n'est pas dans les attributions de kube-state-metrics. Nous l'avons donc rejeté. Nous devons nous en tenir à ces normes. Ce n'est pas un projet Red Hat. C'est un projet pour la communauté. Mon travail chez Red Hat n’a pas nécessairement d’influence sur les projets que je maintiens. L’entreprise décide uniquement de la répartition de mon temps de travail. Chaque fois que quelqu'un de chez Red Hat dira : « Je veux cette fonctionnalité dans kube-state-metrics », j’agirai toujours comme responsable de maintenance plutôt que comme employé de Red Hat ».

Ainsi, quand Lili Cosic rencontre (virtuellement, en ces temps de pandémie) les deux autres responsables de la maintenance de kube-state-metrics, ils ne parlent pas de ce que tel ou tel fournisseur veut dans la prochaine version 2.0. Ils discutent simplement de ce qui est nécessaire pour faire avancer le projet du point de vue de la maintenabilité, tout comme de la suppression de la dette technique et de la détermination des types de données à collecter. C'est ainsi que l'open source est censé fonctionner : des individus, travaillant ensemble dans une communauté, pour créer des logiciels de qualité. Pour Lili Cosic et la communauté Kubernetes, il semble que l'open source fonctionne comme elle est supposée fonctionner.