Différences

Ci-dessous, les différences entre deux révisions de la page.

--- namespace:coso [2018/04/26 18:02]
chloe [Documenter outils et méthodes]
+++ namespace:coso [2019/02/18 23:09] (Version actuelle)
@@ Ligne 1: / Ligne 1: @@
+#Comité pour la science ouverte
+Quelques propositions et remarques formulées dans ma candidature comme membre du groupe-projet Logiciel libre - Open source du Coso :
+http://www.bibliothequescientifiquenumerique.fr/ami-pour-la-constitution-du-comite-pour-la-science-ouverte-coso/
+----
+[...]
+Je compte 10 ans d’engagement associatif et professionnel dans le développement et le soutien au logiciel libre. J’en ai une expérience très concrète, y compris dans ses difficultés et échecs, et ai observé de nombreuses initiatives dont beaucoup sont restées isolées, difficile voire impossible à maintenir.
+###Maîtres d’ouvrage et maîtres d’œuvre
+Je fais aujourd’hui le constat suivant, que la mention que vous faites de « Software Carpentry » illustre bien : d’une part l’édition logicielle, en particulier libre, est encore considérée comme une activité « annexe » qui peut être assurée au sein de laboratoires n’ayant que peu de ressources, en particulier humaines, pour de tels travaux. D’autre part on considère que les chercheurs peuvent apprendre à coder pour répondre à leurs besoins.
+Dans le contexte d’un groupe-projet Logiciel Libre – Open Source j’apporterais clairement une orientation contraire et la nécessité de changer le statut donné au développement logiciel pour la recherche. Il ne s’agit pas d’enseigner aux chercheurs à coder mais bien de reconnaître que la recherche, dans toutes les disciplines a besoin de développeurs experts. C’est aux chercheurs de monter des cahiers des charges fonctionnels (exprimer le besoin) en collaboration avec des développeurs, et à ces derniers de transmettre à leurs collègues chercheurs une certaine littératie informatique, sans que ceux-ci ne deviennent en aucun cas développeurs. Le dialogue avisé entre les deux expertises est indispensable mais chacun est expert en son seul domaine, sauf exceptions.
+Je crois que la première tâche d’un tel comité serait donc de renverser ce point de vue auprès des autorités de la recherche, à tous les niveaux. De la même façon qu’on ne demande pas aux laboratoires de recherche en biologie d’élever leurs souris ou de fabriquer leurs centrifugeuses on ne peut demander aux chercheurs, quelle que soit la discipline, de développer leurs propres logiciels. L’informatique est une science à part entière et le développement logiciel un métier. Les chercheurs non développeurs doivent être maîtres d’ ouvrage  et non maîtres d’œuvre logiciel libre.
+Pour autant il ne s’agit pas de centraliser le développement de logiciels « couteau-suisse » qui répondraient aux besoins de chacun. Comme pour toute recherche, la multiplicité des projets est indispensable. Certains projets libres, tels que des moteurs de recherche comme SolR par exemple, peuvent répondre à de nombreux besoins. Ce qui n’empêche pas le développement de Philologic plus orienté « humanités ». Pour des besoins fins et des approches diverses une liberté de développer est nécessaire, ne serait-ce que pour des « briques » logicielles.
+###Des départements de R&D informatique auprès des chercheurs
+Cela implique de créer, au sein des institutions de recherche ou à l’extérieur, des « départements de R&D » spécialisés dans le développement de LL pour la recherche. Le modèle de l’Adullact, que j’observe depuis de nombreuses années me semble un excellent cas d’étude dans ce sens. L’Adullact a pour objectif de soutenir et coordonner l'action des Administrations et Collectivités territoriales dans le but de promouvoir, développer et maintenir un patrimoine de logiciels libres utiles aux missions de service public.
+J’avais moi-même envisagé il y a quelques années un projet de forge logiciel libre pour les métiers de l’édition (https://framablog.org/2011/09/14/forge-metiers-edition-chloe-girard/), qu’elle soit publique ou privée, libre ou payante. Ce projet a été laissé en suspend faute de temps.
+De telles structures, qui offrent des moyens et cadres de développement professionnels aux chercheurs rendent caduques de telles choses « qu’un canal pour suivre l’évolution des bonnes pratiques de développement des logiciels, et accéder à des formations pertinentes pour améliorer la réutilisabilité des logiciels qu’ils développent ou adaptent ». Les développeurs professionnels ont cette expertise et les chercheurs méritent de travailler avec de tels experts qui leurs transmettent au passage ce savoir. Je parle d’expérience.
+###Documenter outils et méthodes
+En accord avec vous et l’ACM((https://www.acm.org/ , https://www.acm.org/publications/task-force-on-data-software-and-reproducibility)), il m’apparaît très important de labelliser des articles offrant les moyens de la reproductibilité en donnant les liens vers les logiciels. À quoi il faudrait ajouter le détail des « réglages » de ces logiciels au cours de la recherche, à l’instar des méthodologies techniques dans un article de science « dures ». Mentionner les outils, indiquer leur version, leurs réglages et leurs dépendances. Cela manque notamment dans la plupart, pour ne pas dire tous les projet d’humanités numériques que j’étudie.
+###Licences
+La question des licences m’apparaît comme déjà très documenté (voir notamment Benjamin Jean, « Option Libre. Du bon usage des licences libres », sous licence LAL 1.3 ; GNU FDL ; Creative Commons By-Sa, 978-2-9539187-4-8, Décembre 2011, Framasoft, librement téléchargeable) mais il s’agirait peut-être en effet de produire une documentation simplifiée, sous forme de wiki destiné précisément aux chercheurs/développeurs. Mais dans un contexte de structures de développement expertes, la question des licences ne serait pas laissée à des chercheurs non développeurs démunis face à ces licences.
+###Valorisation
+Quant aux questions de valorisation, deux questions se posent :
+  * d’une part la valorisation sur le plan scientifique : c’est un point fondamental qui doit en effet être défendu par le Coso. La maîtrise d’ouvrage dans le développement d’un logiciel « métier » est en effet un travail scientifique.
+  * d’autre part la valorisation économique : c’est un problème que les éditeurs de logiciel libre connaissent bien. Il faut lire sur ce point l’ouvrage de François Élie (professeur de philosophie, développeur autodidacte et président de l’Adullact), « L’Économie du logiciel libre ». Le logiciel étant libre n’importe quelle structure peut ensuite commercialiser du service ou des licences (rien n’empêche de commercialiser du logiciel libre !), y compris une unité de recherche si son statut le lui permet. À partir du moment où les sources sont libres, n’importe qui peut acheter du service à ses développeurs si cela l’intéresse. Ce qu’une unité de recherche peut valoriser économiquement sur un logiciel libre c’est son expertise sur celui-ci pour évolution et maintenance, création d’un module, etc. Comme l’écrit François Élie, « un logiciel libre est gratuit une fois qu’il a été payé ». Le Coso peut certainement documenter les modèles économiques du logiciel libre auprès des chercheurs, c’est un point également important, lié de très près aux questions de licences.
+###Moissonnage des projets
+En ce qui concerne une cartographie des initiatives existantes, ainsi que des acteurs et de leurs pratiques je suis d’avis qu’il faut éviter à tout prix les registres centralisés à maintenir, qui ne sont jamais assez maintenus. Comme pour les ressources documentaires (par exemple norme et protocole DC-OAI), je préconise que chaque équipe de développement publie des métadonnées normées sur son projet logiciel, métadonnées moissonnées et publiées en temps réel sur une plate-forme. Le Coso pourrait réfléchir à une norme façon Dublin Core mais pour les projets logiciel libre et Open Source, si une telle norme n’existe pas déjà.
+[...]