Le « travail invisible » dans l’écosystème open source — la moitié n’est pas documentée
Auteurs : John Meluso (Cornell Univ.), Amanda Casari & Katie McLaughlin (Google LLC), Milo Z. Trujillo (Northeastern Univ.)
Publication : janvier 2024, prépublication d’un article de l’ACM
Original : arXiv:2401.06889v2
Résumé
Les logiciels open source (OSS) ne reposent pas uniquement sur l’écriture de code. La gestion de communauté, la rédaction de documentation, l’organisation d’événements, la gestion financière, les rapports de bugs, la modération de contenu et bien d’autres activités non liées au code rendent possibles la maintenance et l’évolution des projets. Pourtant, ces activités restent le plus souvent un « travail invisible » (invisible labor).
Cette étude menée conjointement par des chercheurs de Cornell, Google et Northeastern montre qu’environ la moitié (50 %) du travail open source est invisible, et que deux tiers des tâches (environ 66 %) ne sont pas connues des autres. Plus de la moitié des répondants ont indiqué qu’une part importante de leur travail n’est ni reconnue ni récompensée.
Aperçu de l’étude
- Méthode d’enquête : sondage mené de janvier à juin 2022 auprès de 142 développeurs OSS dans le monde
- Approche : application d’une technique cognitive d’« anchoring » afin d’amener les participants à évaluer eux-mêmes dans quelle mesure leur travail est « visible » ou « reconnu »
- Questions clés :
- À quel point le travail invisible est-il fréquent dans l’écosystème open source ?
- Quels facteurs renforcent cette « invisibilité » ?
Principaux résultats
- Compensation : seule la moitié des répondants a déclaré avoir reçu du « crédit » pour son travail.
- Visibilité : environ 2/3 des tâches sont invisibles ou connues seulement d’un petit nombre de personnes.
- Facteurs d’invisibilité :
- Les activités hors code ne sont pas automatiquement enregistrées par les systèmes (par exemple, les graphiques GitHub ne reflètent que le codage)
- Des écarts de reconnaissance apparaissent selon des facteurs sociaux (genre, région, structure organisationnelle, etc.)
- Déséquilibre des systèmes de récompense — il y a des « merci », mais pas de véritables opportunités ni de rémunération
Effet cognitif : si l’on parle d’abord de « visibilité », cela paraît moins invisible
Fait intéressant, les réponses variaient selon l’ordre du questionnaire — selon qu’on demandait d’abord aux participants de penser à la « visibilité » ou à l’« invisibilité ».
Les participants à qui l’on rappelait d’abord la « visibilité » ont évalué leur travail comme davantage « visible » et ont jugé moins importante l’importance du « crédit ».
À l’inverse, ceux qui étaient d’abord amenés à penser à l’« invisibilité » ont répondu que leur travail était moins connu et ont accordé davantage d’importance au fait d’être reconnus.
Cela suggère que l’effet d’ancrage (anchoring effect) influence aussi l’évaluation du travail dans l’open source.
Des témoignages parlants
« Personne ne remarque les revues de code ni la documentation. »
« Il arrive souvent que le nom soit mal écrit, voire complètement omis. »
« Les contributions à la communauté ne sont pas reconnues, seuls les commits de code sont considérés comme des “contributions”. »
« Les statistiques des outils automatisés déforment les efforts réels. »
Les chercheurs qualifient ces réactions de « cross-purpose attribution », expliquant que lorsque les motivations individuelles (plaisir, reconnaissance, sentiment d’appartenance, carrière, etc.) entrent en conflit avec le système de récompense de la communauté, le « travail invisible » s’intensifie.
Enseignements de l’étude
-
« Open » ne veut pas dire automatiquement « visible ».
Même si le code est public, les personnes et les processus derrière lui sont facilement oubliés. -
La récompense ne se limite pas à l’argent.
Le fait d’être cité nommément ou d’avoir ses contributions consignées constitue aussi une récompense importante. -
Responsabilité de la conception des plateformes.
Les grandes plateformes comme GitHub devraient afficher de manière quantitative les activités hors code (gestion des issues, traduction, animation de communauté, etc.). -
Nécessité de rendre visibles les différentes formes de contribution.
En adoptant des systèmes de classification des contributions comme CRediT (standard de contribution des chercheurs), il devient possible de reconnaître clairement aussi les apports hors développement, comme la documentation technique ou l’animation de communauté.
Conclusion
Cette étude remet sur le devant de la scène le travail hors du code lorsqu’on parle de durabilité de l’open source.
Le « public » ne garantit pas l’« équité ». Elle rappelle que le véritable caractère « open » de l’open source ne peut reposer uniquement sur le code, mais doit s’appuyer sur une transparence sociale où toutes les contributions sont visibles.
4 commentaires
Même en entreprise... T^T
Il y a énormément de travail annexe et invisible, réalisé à titre personnel, qui n’entre pas dans la répartition officielle des tâches
(par exemple quand il y a beaucoup de petites tâches au point de se dire « c’est vraiment du travail ? », ou quand elles reviennent très souvent)
Bien sûr, on ne renforce pas non plus les effectifs pour ce genre de tâches, donc l’usage de l’IA pour ces petits boulots a augmenté
Je me dis que si les salariés coréens utilisent autant l’IA, c’est peut-être aussi parce qu’ils ont un fort désir de résoudre ce travail invisible en dehors du JD ; à l’étranger, au moins, le JD est davantage décrit de façon concrète et on essaie de le respecter)
En réalité, désormais, même si l’on fournit énormément de travail, on a l’impression que ce sera perçu comme produit par l’IA.
Je pense qu’en réalité, ce problème ne concerne pas seulement l’open source, mais s’applique à toutes les organisations. Il y a beaucoup de contributions qui passent sous le radar.