Evaluer la réutilisabilité des communs open source

Image :

Description en une ligne : Cette page propose une approche pour évaluer la réutilisabilité et la facilité de contribution de projets open source, un substrat des communs numériques.

Description :

Des projets open source, mais pas forcément des communs

Voici quelques exemples de projets open source qui n'encouragent pas la collaboration:

• les projets qui publient leur code, mais pas régulièrement. Ici impossible de contribuer car on ne sait pas ce qui est fait en interne par les devs
• Les projets qui publient régulièrement mais avec tellement de devs en interne qu'il est difficile de s'y greffer. Ici, il faut souvent trouver un problème et demander à l'équipe l'autorisation de travailler dessus avant de commencer, au cas où ils aient déjà prévu de (ou ne souhaitent pas) le faire
• Les projets très complexes ou la manière de contribuer n'est pas décrite (normalement on inclut un fichier CONTRIBUTING pour cela), du coup impossible de démarrer de manière autonome
• Les projets qui nécessitent des ressources inaccessibles. Elles peuvent être matérielles, comme Yandex qui a récemment publié un algorithme d'IA qui nécessite plusieurs mois de calculs dans un datacenter, ou logicielles, comme les projets ou certaines briques sont fermées, typiquement un GAFAM qui partage une partie de son code, mais tellement dépendante du reste des outils payants qu'il est difficile de faire sans.

Cette étude contient des indicateurs précis pour déterminer si les projets open source sont similaires aux exemples ci-dessus.

L'effort de créer un commun

Il est important de noter que les projets open source ne profitent pas tous des bénéfices d'une mise en commun de la même manière. En effet, pour certain d'entre eux, l'effort et l'investissement nécessaire pour encourager la contribution sont trop importants par rapport aux gains.

On peut citer dans cette catégorie les projets complets, ou l'ajout de fonctionnalités vient au détriment d'un cœur stable et identifié. Par exemple, un code simple 'addition' qui somme deux chiffres bénéficierait négativement d'une fonctionnalité de soustraction. On peut aussi citer les projets très complexes, ou l'expertise nécessaire pour participer de manière productive est limité à quelques individus. L'ouverture vers l'extérieur et le grand publique n'a pas beaucoup de sens dans cette situation.

Ce dernier point rejoint le sujet de la rivalité des communs. Alors que le code open source est bien une ressource non rivale, utilisable par tous sans réduction de sa valeur. Les communs numériques ont tout de même une ressource rivale dans la disponibilité des "maintainers" ou porteur de projets. Plus un projet investit dans sa documentation et son appel aux contributions, plus le nombre de contributions à faible valeur ajoutée augmente. En effet, sur des projets de taille importante, l'écrasante majorité des contributeurs sont des débutants ayant besoin d'assistance pour mieux comprendre le projet avant de pouvoir participer, et pour beaucoup d'entre eux, cette étape de participation n'arrive jamais. Dans ce cas, la contribution, souvent prenant la forme de question ou "issue", a une valeur négative pour le projet, elle consomme la ressource non rivale et n'apporte rien en retour.

Pour éviter ce genre de situations, certains maintainer prennent alors la décision volontaire de limiter l'accessibilité de leurs projets, soit par offuscation d'explications, soit un plaçant le code source sur un site moins populaire.

Plateformes de publication open source

GitHub est de loin la plateforme la plus populaire dans l'écosystème de l'open source. Paradoxalement, cette dernière n'est pas un projet open source, avec un propriétaire qui était historiquement contre l'ouverture de code: Microsoft.

Pour autant, ce qui fait son succès par rapport à ses alternatives comme Bitbucket et GitLab (open source), sont ses fonctionnalités communautaires. Étant tous basés sur la même technologie: git, c'est bien l'aspect communautaire qui vient différencier leurs usages et leurs utilisateurs. À ce niveau, GitHub se présente presque comme un réseau social de développeurs, alors que les alternatives se concentrent sur le partage du code.

Un porteur de projet va donc choisir sa plateforme en fonction de ses besoins, souvent fortement influencé par ses expériences passées et par son environnement professionnel: une entreprise qui utilise la suite Jira d'Atlassian utilisera très probablement Bitbucket pour ses intégrations. Si le but est l'ouverture au plus grand nombre dans l'idée de créer une communauté, GitHub est la solution. Si le but est d'affirmer des positions plus libristes et d'attirer des profils plus rares, mais qualifiés, GitLab a du sens.

On retrouve d'ailleurs régulièrement des projets qui migrent d'une plateforme à une autre car leur politique d'ouverture a changé dans le temps. C'est le cas du projet Chouette dans cette étude.

Spécificité des communs numériques de mobilité

En termes de technologies et d'infrastructures, les projets open source de mobilité ne sont pas différents des autres projets open source. Il est probable que certains outils spécifiques existent, et que des développeurs aient des compétences précises liées au sujet. Mais c'est le cas dans tous les secteurs.

Une particularité de la mobilité, comparé au médical par exemple, est sa relation avec l'open data. En effet, la disponibilité et le partage des données de mobilité sont de très bonne source de communs. On peut remarquer d'ailleurs que beaucoup de communs de mobilité ne sont pas des projets open source, mais plutôt open data, le code source ayant peu d'importance.

Identification des indicateurs

Différentes sources existent avec des propositions d’indicateurs assez complémentaires. Elles sont présentées ci-dessus, l’ordre n’a pas d’importance.

Github - Community guidelines

Github propose un outil pour guider sur les bonnes pratiques communautaires des projets. Ces points sont repris dans les très bons guides https://opensource.guide.

Ils couvrent principalement la présence de fichiers:

• Readme ? Est-il clair et à jour ?
• Licence ? À quelle point est-elle ouverte
• Contributing ? Ce fichier est le cœur de la contribution, il doit expliquer les étapes et règles de contribution.
• code of conduct ? Optionnel, ce fichier est en général présent quand les communautés deviennent plus grandes, et qu’il faut être clair sur comment se comporter, et les conséquences en cas de non respects

Ces fichiers sont les premiers consultés par un potentiel contributeur, avant même d’ouvrir le code source. Si absents, il est très dur de considérer le projet comme un commun.

Guides Etalab

Etalab propose un très bon guide d’ouverture de code source pour les administrations: https://guides.etalab.gouv.fr/pdf/guide-logiciels.pdf, deux choses peuvent en être extraites:

Des bonnes pratiques qui viennent compléter celles de github:

• Présence d’un lien vers le site web du projet
• Expliciter auteurs et gouvernance (surtout si une administration participe)
• Préciser les dépendances de l’écosystème
  • Qui réutilise le projet (un projet peu réutilisé n’est pas très bon signe)
  • Sur quoi est basé le projet (un projet très dépendant d’un projet peu ouvert est mauvais signe)

En plus des bonnes pratiques, Etalab propose une division intéressante entre types de partage et types de projets. Avec une recommandation que seuls les projets couvrant deux des trois types sont intéressants à partager au niveau A. On peut en déduire qu’un projet qui se veut très contributif, mais qui ne correspond qu’à un seul des types sur 3, a peu de chance de se trouver une communauté.

• Niveaux de partage:
  • Niveau A ‑ contributif : Le code source est publié, les contributions extérieures sont activement recherchées et traitées.
  • Niveau B ‑ ouvert : Le code source est publié, les contributions extérieures sont traitées mais non activement recherchées
  • Niveau C ‑ publié : Le code source est publié mais les contributions extérieures ne sont pas traitées.
  • Niveau D ‑ non‑communicable : Le code source n’est pas communicable au public.
• Types de projets
  • Le logiciel est-il un module utile à d’autres logiciels libres (ou un logiciel « monolithique » sans utilité pour d’autres logiciels libres)?
  • Le logiciel répond-il à un besoin générique (ou à un besoin spécifique à l’organisme qui le produit)?
  • L’utilisateur final du logiciel a‑t‑il un profil technique (développeur, datascientiste ou designer)?

Que dit la science

L’article https://www.sciencedirect.com/science/article/pii/S0164121222000267#tbl2 présente une vue assez exhaustive de l’état de l’art sur les méthodes d’évaluation de projet open source. Il présente notamment une étude auprès d’une vingtaine d’experts sur leurs critères de choix pour sélectionner et intégrer une solution open source. Il est raisonnable de considérer que ces critères sont similaires pour la facilité de contribution.

L’article est très complet et vraiment intéressant, mais pour des raisons de simplification, voici une liste des points les plus cités par les experts pour évaluer un projet. À chaque ligne, le premier chiffre est le nombre de répondants ayant mentionné ce facteur (23 totaux), le deuxième chiffre est la note sur 5 de l’importance du facteur.

Assez logiquement, on retrouve des points présents dans les autres sources, mais aussi des sujets comme la maturité du projet, la sécurité ou la qualité du code.

• Community support and adoption 10 4.5
  • Popularity 9 3
    • Nb Stars 13 3
    • Nb Downloads 13 3
  • Community reputation 11 3
  • Community size 13 3
    • Nb Contributors 11 4
    • Community age 12 3
  • Communication 6 3.5
    • Availability of questions/answers 11 3
  • Involvement 9 3
    • Clear project management 1 5
  • Sustainability 11 3
    • Existence of maintainer 11 3
• Documentation 14 4
  • Software requirements 11 3
  • Hardware requirements 8 3.5
  • Roadmap 7 3
• License 21 4
  • License type 20 5
  • License Compatibility 10 3
• Operational SW characteristics 6 4
  • Independence from other SW 11 3
• Maturity 6 3.5
  • Nb releases 10 4
• Quality 6 3.5
  • Reliability 3 4
    • Nb Bugs (open, closed, …)/bug density 8 4
    • Mean time between software failure (MTBF) 8 4
  • Security 15 4
    • Nb security vulnerabilities 12 3
    • Nb Vulnerabilities reported on the NVD portal 14 4
  • Code Quality 13 4
    • Code complexity (class, methods, ..) 10 3
  • Coding conventions 9 3

La méthode de l’article est une extension d’une première méthode d’évaluation : Open Source Maturity Model (OSMM), qui se basait principalement sur la maturité des projets. Elle présente 6 indicateurs, avec un poids pour chacun.

Product software	4
support	2
documentation	1
training	1
product integrations	1
professional services	1

Il est important de noter que la maturité n’est qu’un seul indicateur à prendre en compte quand on parle de réutilisabilité et contribution. En effet, pour beaucoup de contributeurs, il est nettement plus motivant de travailler sur des projets en cours de maturation, plutôt que des projets matures, nécessitant maintenance et une forme de service après-vente.

L’article mentionne aussi OpenHub, une banque de données de projets OpenSource (plus d’un million sont référencés) qui se base en partie sur les critères de l’OSMM

Open Hub, the open source network

Autres indicateurs utilisés par la Fabrique

• Backlog ouverte
  • La backlog résume les tâches prévues pour l’amélioration du projet. Lorsqu’elle est publique, il est plus simple de prévoir et de se positionner sur un sujet futur.
  • Notons tout de même que ce point est très rarement présent sur les projets open source. Il est souvent remplacé par un échange avec le maintainer avant la contribution.
• Nombre et origine professionnelle des contributeurs
  • Très peu de contributeurs n’est pas bon signe. Beaucoup de contributeurs peut aussi être dissuasifs, car le commun a probablement d’expert et non pas de débutants.
  • L’origine des contributeurs a aussi son importance dans le cas où ils proviennent tous de la même structure, il est probablement complexe de s’intégrer à la dynamique de travail.
• Activité de la communauté
  • Issues, sont elles récentes, y a-t-il de l’activité ?
  • Pull requests, y’a-t-il des contributions proposées par la communauté ? Sont elles considérées ?
  • Questions sur d'autres plates-formes, par exemple sur Stackoverflow. Une grande partie de la documentation d’usage des projets se retrouve sous la forme de questions réponses sur ce genre de plateforme. Du fait de leur référencement et fonctionnalités de recherche, il est parfois plus simple de trouver une réponse sur un site de question réponse que dans la documentation d’un logiciel.
• Dépendances
  • Est-ce ultra lié à un ensemble existant ?
    • Par exemple, un projet Amazon qui nécessite la mise en place de plusieurs clusters sur AWS ne facilite pas la prise en main pour de nouveau contributeur, car il existe un coût monétaire d’entrée et une expertise qui dépasse le simple projet.
  • Y a-t-il des briques fermées ou inaccessibles ?
    • Parfois, c'est un simple fichier manquant, caché dans l’arborescence, difficile à identifier sans investir du temps dans le projet.
      • Il est quand même peu probable que cela arrive si le projet est utilisé par plus d’une personne.
• Complexité du projet
  • Certains projets ont une telle complexité que la contribution est quasi impossible. C’est par exemple le cas pour des projets publiés suite à des doctorats, ou seul le docteur est suffisamment expert pour exploiter la solution.

Choix des indicateurs

Dans l’ensemble, il n’est pas nécessaire de répondre de manière exhaustive à tous ces indicateurs car ils sont souvent corrélés: un manque clair de documentation sera nécessairement lié à un nombre plus faible de réutilisateurs, etc…

Néanmoins, établir une liste permet de garder en tête les critères critiques. Elle permet aussi une comparaison plus objective des projets entre eux, même s’ils sont différents en taille et historique.

Tags : Commun, Open Source

Thème : Logiciel Libre

Organisations impliquées dans la ressource : FabMob

Référent (individu) : Alex Bourreau

Autres informations :