Inclusion, diversité et communication positive dans les projets open source

Publié le par

Préambule

Depuis quelques années, les problématiques de diversité d’origine, de genre et de culture dans les projets open source sont un sujet récurrent dans le monde des technologies de l’information. Le mouvement “Women in Tech”, par exemple, existe depuis 1989. Et certains projets comme Drupal ont même discuté du sujet dès 2014.

Les incidents récurrents depuis de nombreuses années entre la communauté afro-américaine et la police aux Etats-Unis ont rendu le sujet prioritaire au printemps 2020 pour nombre d’entreprises occidentales et de projets open source basés aux USA. Elles en ont profité pour communiquer sur leurs bonnes intentions, leur culture interne, etc.

Cela a un impact à court et moyen terme dans les logiciels, documentations et services: l’idée est d’enlever les vocabulaires de type à connotation négative, par exemple “master/slave”, pour préférer un langage neutre culturellement et surtout, le plus descriptif possible. Avec d’autres initiatives comme les codes de conduite, une meilleure répartition des rôles dans les projets, etc., l’objectif est d’attirer de nouveaux contributeurs et d’augmenter leur diversité d’origine et de culture.

Cet article est le résultat d’un long travail sur le sujet dans le cadre de mon travail en tant qu’expert de l’open source. Je vous propose ici une version adaptée récemment pour la publication sur mon blog, basée sur un document qui m’a servi à faire des ateliers et de la communication sur le sujet.

Le sujet étant clivant, les commentaires sont les bienvenus mais doivent être respectueux. En cas de débordement, je les fermerai sur cet article.

 

1. Une synthèse des problématiques clés de l’inclusion et de la diversité pour les projets open source

1.1 Un peu d’histoire

Tout d’abord, il convient de rappeler que ce n’est pas une problématique nouvelle. Les premières réflexions sur le sujet dans les projets open source datent pour certaines de 2014-2015.

Le fait est que beaucoup de projets ont leurs contributeurs distribués sur la planète, qu’ils soient salariés ou experts indépendants. Plusieurs organisations ont cependant montré qu’il y a un problème de diversité dans le monde de la technologie en général, lié en particulier au comportement des développeurs.

La plus importante étude sur le sujet est celle conduite en partenariat avec GitHub qui indique lors de sa publication:

  • Si l’auteur d’un pull request est identifié comme étant une femme, il a 80% de chance en moins d’être validé même s’il est pertinent et de qualité.
  • En général, le code proposé par des femmes est pourtant de très bonne qualité.
  • Pour cette raison, comme dans les jeux vidéo en ligne, beaucoup de femmes ont un avatar et un “nickname” masculin.

Cela conduisait aussi par le passé de nombreuses personnes à refuser de venir aux conférences, pour conserver leur tranquillité: quelle horreur en effet pour le statut de leurs contributions, voire pour leur carrière, si on découvrait qu’en fait elles ne sont pas ce qu’on pensait…
En savoir plus: Gender differences and bias in open source: pull request acceptance of women versus men

On se souvient de ce qui s’est passé chez Uber après la révélation des agressions envers les femmes par des managers protégés. On en a eu d’autres exemples depuis, par exemple avec Ubisoft. Les projets open source ne font pas exception même si on en parle moins. Voici deux exemples:

La problématique qu’on ne soupçonne pas au premier abord est que cela éloigne de potentiels contributeurs qui préfèrent donc aller participer à des projets ouverts d’esprits, respectueux et bien modérés. Les grandes fondations du logiciel libre et open source comme les fondations Linux ou Eclipse (chez qui j’ai travaillé) se sont saisies du sujet dès 2015, d’abord avec des Code of Conduct appliqués strictement, aussi bien en ligne que « IRL » (meetups, conférences).

Le travail effectué dépasse la simple notion homme/femme, pour inclure les personnes issues de la diversité (comme on dit en France), mais aussi celles porteuses de handicap, les LGBTQIA+, ou encore faire attention à ce que la nourriture sur un événement puisse convenir à toutes les personnes, de toute origine et culture. L’idée est que chaque personne puisse voir son identité respectée, aussi bien en ligne à l’abri derrière un écran, que lors de rencontres sur les conférences et les meetups.

Le constat est que dès lors, les keynotes speakers, les track managers, etc. dans les grands événements open source sont désormais mixtes. Et des personnes qui ne seraient jamais venues il y a quelques années viennent aux événements, y ont un stand ou présentent un talk.

1.2 Rappel du contexte BLM et de son écho pour l’industrie Tech

Aux USA, le mouvement BLM (Black Live Matter) a incité les grands groupes technologiques à prendre position durant l’été 2020, souvent à grand coup de com’ sur les réseaux sociaux et d’articles de blog ou dans la presse tech.

L’origine vient du fait qu’il existe deux types de vocabulaires largement utilisés, et très critiqués. Le premier, “master/slave”, est sorti de son contexte historique lié à l’esclavage des humains et utilisé pour décrire un mécanisme relationnel ou architectural entre deux services (ex: très utilisé avec les bases de données). Le deuxième, autour de black et white, comme “blacklist/whitelist”, ou encore “blackhat/whitehat”, qui introduisent des biais indirects: le blanc est associé au bien et le noir l’est au mal. 

C’est ce qu’on appelle un biais implicite. Pour en savoir plus, lisez ce très bon article sur Wikipedia:
https://en.wikipedia.org/wiki/Implicit_stereotype

Ces vocabulaires ont été utilisés par les inventeurs de l’informatique moderne aux USA dès les années 60-70, dans un contexte socioculturel très différent d’aujourd’hui. Et bien que leurs définition et usages dans la technologie aient été documentés avec le temps, ils montrent qu’un contexte culturel en particulier a été choisi à l’époque (en gros, parler anglais couramment, être blanc et de culture occidentale). Il aurait été plus pertinent pour le long terme d’utiliser dès le départ un vocabulaire purement descriptif, fonctionnel, et compréhensible par tout un chacun, sans connotation culturelle (exemple: allowlist/denylist, goodhat/badhat, primary/replica, …).

1.3 Le besoin de vocabulaire descriptif et inclusif pour favoriser la diversité

Que ce soit dans un fichier « contributing.md », la documentation d’un projet, le code source, ou une offre d’emploi, le ton et le vocabulaire employés sont cruciaux. Une personne s’intéressant à une technologie ou à un emploi voit très rapidement par qui et pour qui c’est écrit (on parle ici principalement de contribuer du code, mais ce n’est pas réservé qu’aux devs, bien sûr).

Les noms de variables, des fonctions, des hook, des paramètres d’API, etc. ou encore, les exemples utilisés pour illustrer des concepts architecturaux sont souvent liés à la culture des créateurs ou des mainteneurs du projet. La première barrière, que l’on oublie souvent, est qu’il faut communiquer en anglais. Et si en plus il faut comprendre des références culturelles, des tournures idiomatiques (exemple: « frais comme un gardon » en français = « fresh like a cucumber » in English), la courbe d’apprentissage devient beaucoup plus lourde pour une personne ayant grandi dans un contexte socioculturel différent (sans même parler de l’utilisation de termes discutables comme “master/slave”).

Utiliser un vocabulaire neutre et descriptif, sans connotation culturelle, est alors préférable. Et c’est ce qui est en train de se passer ces dernières années dans le monde de la technologie en général, grâce aux conseils d’administrations des projets, des fondations et des entreprises qui ont pris position.

L’avantage est que tout pourrait désormais être plus explicite pour un non occidental (exemple: “allowlist” est plus explicite que “whitelist” ou “greenlist”). Nombreux sont en effet les contributeurs avec des références culturelles différentes des occidentaux: pays de l’Est Européen et Russie, la Chine, l’Afrique, etc. Cela diminue la courbe d’apprentissage, rend explicite les usages, et montre le soin apporté à accueillir tout le monde avec respect et tolérance.

Pour conclure ce point, le cabinet d’études McKinsey & Company confirme dans une étude la corrélation entre diversité et profits des entreprises: Delivering through diversity. Pour résumer, la diversité, c’est bon pour les affaires.

2. Une synthèse sur les exemples d’actions prises par des projets open source notables (avec des exemples de projets d’origine US et non US) + la communication associée

NB: cliquez sur les liens pour ouvrir directement les discussions ou références relatives aux projets/entreprises concernés.

Comme expliqué en introduction, on entre dans un sujet qui ne commence pas du tout en 2020, donc bien avant le sujet BLM : c’est déjà abordé, voire traité par plusieurs langages et projets depuis plusieurs années. Par exemple, chez Drupal (CMS), CouchDB (base de données objet), et Django (framework), les premières contributions en ce sens datent de 2014. Sur Stackoverflow, le Q&A pour les développeurs, le sujet a été abordé dès 2010.

Basecamp et RubyOnRails ont traité le sujet en 2018 sous l’impulsion de DHH, très influent dans les applications webs, ainsi que dans la communauté Python. La même année, Buffer a publié un guide sur le langage inclusif à destination des startups et des projets technologiques. Ce sont des communautés très influentes et elles montrent ainsi l’exemple. En effet, Ruby est aussi utilisé par GitHub, et Python est LE langage de l’IA et du Deep Learning.

A partir du printemps 2020, IBM (et Redhat), MySQL (qui appartient à Oracle), Microsoft (et ses filiales LinkedIn et GitHub), Splunk, Android, OpenSSL, PHPUnit, OpenZFS, JP Morgan, Linux, et plein d’autres ont pris position, et systématiquement une position positive. Git a aussi ajouté durant l’été 2020 une fonctionnalité permettant de changer le nom de la branche par défaut (historiquement, “master”) suite aux nombreux tutoriels montrant comment le faire à posteriori.

On remarque donc des profils très variés: éditeurs historiques, récents, qui font du libre, du propriétaires ou les deux, ou encore qui proposent des services ou des API pour les développeurs.

NB: une bonne partie des entreprises et projets ayant pris des initiatives claires sur le sujet (parfois il y a plusieurs années) ont été fondées par des Européens, ou sont très influencés par des contributeurs européens. Par exemple: Acquia / Drupal, BaseCamp / RubyOnRails, ou plus récemment Buffer.

3. Conclusion

Dans les discussions, que ce soit “online” ou “in real life”, on constate encore beaucoup de clivages forts sur ce sujet. Le but n’est pas de remettre en cause les personnes, leur culture, ou leurs croyances. Mais bien d’aller vers plus d’ouverture d’esprit et de tolérance.

Il est donc temps de regarder son travail de manière critique, mais avec bienveillance. Et de se poser cette question: que puis-je améliorer pour que tout le monde se sente à l’aise dans le cadre de l’écriture collective qu’est un projet open source? Un début de réponse peut être apporté en privilégiant un vocabulaire descriptif, sans biais implicite, et ne nécessitant donc aucune connivence ou compréhension d’une culture en particulier.

Si vous avez besoin de recommandations et d’exemples de bonnes pratiques, voici ce que propose Linus Torvald, qui a fait un travail sur lui-même dans son intérêt et celui de son projet open source. Ceci est un extrait de la mailing list utilisée pour la collaboration sur le projet Linux:

+For symbol names and documentation, avoid introducing new usage of
+'master / slave' (or 'slave' independent of 'master') and 'blacklist /
+whitelist'.
+
+Recommended replacements for 'master / slave' are:
+ '{primary,main} / {secondary,replica,subordinate}'
+ '{initiator,requester} / {target,responder}'
+ '{controller,host} / {device,worker,proxy}'
+ 'leader / follower'
+ 'director / performer'
+
+Recommended replacements for 'blacklist/whitelist' are:
+ 'denylist / allowlist'
+ 'blocklist / passlist'
+
+Exceptions for introducing new usage is to maintain a userspace ABI/API,
+or when updating code for an existing (as of 2020) hardware or protocol
+specification that mandates those terms. For new specifications
+translate specification usage of the terminology to the kernel coding
+standard where possible.

4. Ressources complémentaires

 

Laisser un commentaire