Open Source Is Not One Thing: A Typology of Open-Source Software Sub-Genres
Cet article soutient que le logiciel libre n'est pas une entité homogène mais se compose plutôt de quatorze sous-genres distincts présentant des moteurs, une gouvernance et des financements variés, et propose une typologie ainsi qu'un programme de recherche pour remédier à la faible généralisabilité des résultats empiriques à travers ces diverses catégories.
Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète
Imaginez que vous entriez dans une bibliothèque géante et que quelqu'un vous dise : « Tous les livres ici ne sont que des "livres". Ils fonctionnent tous de la même manière. » Vous pourriez acquiescer, mais si vous regardiez vraiment, vous verriez une énorme différence entre une bande dessinée, un manuel médical, un journal intime et un contrat juridique. Ils ont des auteurs différents, des raisons d'exister différentes et des règles différentes sur la façon dont vous pouvez les utiliser.
Cet article soutient que le Logiciel Libre (Open Source Software - OSS) est exactement comme cette bibliothèque. Les chercheurs traitent souvent tout le code open source comme un grand groupe uniforme, mais les auteurs disent : « Non, ce n'est pas une seule chose. » C'est en réalité une collection de 14 « sous-genres » différents, chacun ayant sa propre personnalité, ses propres règles et sa propre façon de survivre.
Voici une décomposition simple de leurs conclusions en utilisant des analogies du quotidien :
1. Le gros problème : l'erreur du « taille unique »
Imaginez un médecin qui étudie comment les gens se remettent d'une fracture du bras. Il étudie un athlète professionnel, un bambin et une personne âgée. S'il fait la moyenne des résultats et dit : « Voici comment tout le monde guérit », il se trompe. L'athlète a besoin d'un plan différent de celui du bambin.
L'article dit que les chercheurs commettent la même erreur avec les logiciels. Ils étudient un projet populaire (comme un système d'exploitation Linux) et supposent que leurs conclusions s'appliquent à tous les logiciels. Or, un projet géré par une seule entreprise à but lucratif est totalement différent d'un projet géré par des bénévoles pour aider un village dans un pays en développement. Si vous essayez d'appliquer les règles de l'« entreprise » au projet des « bénévoles », cela pourrait échouer.
2. La solution : un « menu » de 14 types de logiciels
Les auteurs ont créé un « menu » (une typologie) pour classer les logiciels en 14 catégories distinctes basées sur qui les pilote, qui dirige le spectacle et qui paie les factures.
Voyez ces catégories comme différents types de restaurants :
- Le restaurant de chaîne (Soutenu par une entreprise) : Dirigé par une grande corporation (comme Red Hat ou GitLab). Ils veulent gagner de l'argent, donc ils contrôlent le menu et la direction.
- Le collectif de food trucks (Gouverné par une fondation) : Un groupe d'entreprises concurrentes (comme Google et IBM) rejoignent une organisation à but non lucratif neutre (comme la Linux Foundation) pour construire une cuisine partagée. Ils se mettent d'accord sur des règles pour ne pas se battre autour du fourneau.
- Le jardin communautaire (Piloté par la communauté) : Pas de patron. Des bénévoles cultivent des légumes parce qu'ils aiment le jardinage. Le meilleur jardinier décide de ce qu'on plante ensuite, pas la personne qui possède le terrain.
- La cuisine caritative (OSS pour le bien social) : Construite spéciftmplément pour nourrir les affamés ou aider lors de catastrophes. Le but n'est pas le profit ; c'est de sauver des vies. Les gens qui travaillent ici restent plus longtemps parce qu'ils sont passionnés par la mission.
- La cafétéria scolaire (Éducatif) : Des étudiants cuisinent des repas pour apprendre à gérer une cuisine. Ils sont là pour une note, pas pour une carrière.
- Le passionné solitaire (Loisir/Solo) : Une personne construisant un gadget cool dans son garage pour le plaisir. Si cette personne tombe malade, le projet s'arrête (c'est ce qu'on appelle un « faible facteur de remplacement » ou truck factor).
- Le panneau de protestation (Protestware) : Un développeur modifie secrètement son code pour envoyer un message politique ou saboter un système. Le but n'est pas de corriger un bug ; c'est de faire passer un message.
- La plomberie invisible (Infrastructure numérique critique) : Ce sont les petites pièces de code ennuyeuses (comme
curlouOpenSSL) sur lesquelles tout l'internet repose. Elles sont souvent maintenues par un ou deux bénévoles fatigués qui ne sont pas assez payés. Si elles cassent, tout l'internet fuit.
3. Pourquoi cela importe (L'agenda de recherche)
Les auteurs ne font pas que lister ces types ; ils disent aux chercheurs de cesser de les mélanger.
- Le problème du « transfert » : Si vous découvrez comment garder les bénévoles heureux dans un projet de « Jardin Communautaire », ce conseil pourrait ne pas fonctionner pour un projet de « Restaurant de Chaîne ». L'article demande : Est-ce qu'une règle qui fonctionne pour un type de logiciel fonctionne pour les autres ? La réponse est probablement « non ».
- Les angles morts : Certains types de logiciels sont bien étudiés (comme les grands projets communautaires), mais d'autres sont ignorés. L'article souligne que nous en savons très peu sur le « Protestware » (logiciels utilisés pour le sabotage politique) ou la « Technologie Appropriée Open Source » (outils pour les besoins de base dans les zones pauvres). Ce sont les « recoins sombres » de la bibliothèque qui ont besoin de plus de lumière.
4. La conclusion
L'article conclut que l'Open Source est pluriel, et non singulier. Ce n'est pas seulement du « code » ; c'est un mélange d'entreprises, de charités, d'écoles, de passionnés et de militants politiques.
En reconnaissant ces 14 « sous-genres » différents, nous pouvons :
- Mieux comprendre : Arrêter de faire de mauvaises généralisations sur le fonctionnement des logiciels.
- Mieux aider : Si vous voulez soutenir un projet, vous devez savoir de quel type de projet il s'agit pour apporter l'aide appropriée.
- Mieux étudier : Les chercheurs doivent étiqueter le « type » de logiciel qu'ils étudient pour que leurs résultats aient du sens.
En bref : Tous les logiciels libres ne sont pas créés égaux, et traiter les logiciels ainsi cache la véritable histoire.
Noyé(e) sous les articles dans votre domaine ?
Recevez des digests quotidiens des articles les plus récents correspondant à vos mots-clés de recherche — avec des résumés techniques, dans votre langue.