Evaluer la réutilisabilité des communs open source

Image:

Short description: 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 publiant leur code, mais pas régulièrement. La contribution est complexe faute de visibilité sur les avancées internes des équipes coeur.
• Les projets publiant régulièrement, mais avec un grand nombre de développeurs internalisés à une strucutre. Dans se cas, se greffer au projet est complexe et il faut généralement isoler 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 traiter.
• Les projets très complexes ou la manière de contribuer n'est pas décrite (par exemple via un fichier CONTRIBUTING). Sans ce contexte, la contribution en autonomie est compliquée.
• Les projets nécessitant des ressources inaccessibles. Elles peuvent être matérielles, comme Yandex et sa récente publication d'un algorithme d'IA nécessitant plusieurs mois de calculs dans un datacenter, ou logicielles, comme les projets ou certaines briques sont fermées, typiquement un GAFAM partageant une partie de son code, mais dont la dépendante reste trop forte avec un ensemble d'outils fermés.

Cette étude propose des indicateurs précis pour déterminer si un projet open source s'apparente à l'un des 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.

Nous retrouvons dans cette catégorie les projets "complets", ou l'ajout de fonctionnalités vient au détriment d'un cœur stable et identifié. De même pour les projets très complexes, ou l'expertise nécessaire pour participer de manière productive est limité à quelques individus. Dans les deux cas, une ouverture vers la contribution extérieure risque de desservir le projet.

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, l'étape de contribution "utile" n'arrive jamais. Dans ce cas, la contribution, souvent prenant la forme de question ou "issue", chronophage pour le projet, et consommatrice de cette ressource humaine.

Pour éviter ce genre de situations, certains maintainers 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 ses fonctionnalités communautaires font son succès par rapport à ses alternatives comme Bitbucket et GitLab (open source). É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 utilisatrice de la suite Jira d'Atlassian utilisera très probablement Bitbucket pour bénéficier des intégrations entre logiciels. Si le but est l'ouverture au plus grand nombre dans l'idée de créer une communauté, GitHub est généralement favorisé. Toutefois, si l'optique est d'affirmer des positions plus libristes et d'attirer des profils plus rares, mais qualifiés, GitLab est une alternative plébiscitée.

Il est d'ailleurs fréquent que des projets migrent d'une plateforme à une autre, suite à un changement de politique d'ouverture. (Exemple avec le projet Chouette, porté par enRoute)

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.

Toutefois, une particularité de la mobilité est sa relation avec l'open data, poussée par un cadre législatif imposant l'ouverture. De fait, 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

Nous proposons ici un bref état de l'art des initiatives existantes d'indicateurs pour l'évaluation des communs numériques ouverts.

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 généralement présent lorsque les communautés deviennent plus grandes, et pose un cadre sur le comportement attendus des contributeurs.

Ces fichiers sont les premiers consultés par un potentiel contributeur, avant même d’ouvrir le code source. Si absents, il est complexe d'évaluer le charactère commun d'un projet.

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.

Le guide propose 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 à ouvrir à la contribution. De fait, un projet se voulant très contributif, mais ne correspondant qu’à un seul type sur 3, risque des recontrer des difficultés à convaincre sa 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

Theme: Logiciel Libre

Organization related to this knowledge: FabMob

Referent (person): Alex Bourreau

Community of interest: Communauté des Communs Numériques de la Mobilité

Other informations: