L soual abf 21 mai 2010_opensource
description
Transcript of L soual abf 21 mai 2010_opensource
que signifie aujourd'hui, pour une que signifie aujourd'hui, pour une bibliothèque, monter un projet open bibliothèque, monter un projet open
source ?source ?
Table ronde ABFTable ronde ABF2121 mai mai 20102010
Laurent Soual (doXulting)
Sommaire
Introduction : contexte et enjeux des logiciels libres en bibliothèque1 - Une analyse des risques et des choix
2 - Avant le choix : les étapes de décision
3 - Le cahier des charges
4 - La mise en oeuvre
Introduction : contexte actuel et enjeux des logiciels libres en documentation et bibliothèque
De quoi parle-t-on : ce que je peux faire avec un logiciel libre
Ne pas confondre gratuit (free en anglais) et open source ou libre (free également en anglais…)
un logiciel open source peut être payant un logiciel propriétaire (code source non ouvert), peut être gratuit
open source : ce que je peux faire techniquement : étudier le code source pour en comprendre la logique copier des parties de code pour faire un autre logiciel corriger des bugs ajouter des fonctions manquantes améliorer les fonctions existantes l'associer à un autre code supprimer une partie du code...
Ce que je peux faire légalement : Utiliser le programme dans mon activité professionnelle, en cours, le
donner à des élèves, à des clients le vendre (sans reverser de droits d'auteurs) associé à d'autres
logiciels ou intégré dans le code d'un autre produit , ou encore en version modifiée
dans le cadre défini par la licence.
Etat du marché français
Tous secteurs confondus, le logiciel libre atteindrait 10% des dépenses en
2012, soit une croissance de 32,7% par an.
(Source PAC/OPIIEC)
SIGBKohaPMB
Greenstone
Outils de diffusionMoCCAMVUFind
BlackLightLibraryFind
…
CMS ECM GED+ ou - orientés portail
Ez publishSpip (php mysql)Alfresco(Java)Nuxeo (J2EE)
Drupal, Typo3…
Infrastructure/brique
SGBD : MySQL, PostGre...Moteurs de recherche : Lucene,Sol-R, Tsearch...
HTTP : ApacheAutres : eXist (gestion de bdd xml)
Utilitaires
Editeurs XML,gestion de bibliographie,
Gestion d'enquêtesuite bureautique
gestion de planning...
Les logiciels libres d’ECM/CMS/GED
Le marché GED /ECM / CMS
SPIP, JOOMLA, DRUPAL,Typo3, eZpublish, Jahia,
Nuxeo, Alfresco
On dénombre 240 logiciels libres dans le domaine ECM/CMS
Marché : prometteur international (européen) concurrentiel
Les logiciels libres en bibliothéconomie
SIGBKohaPMB
Evergreen
Outils de diffusionMoCCAMVUFind
BlackLightLibraryFind
CMS ECM GED+ ou - orientés portail
Ez publishSpip (php mysql)Alfresco(Java)Nuxeo (J2EE)
Drupal…
Infrastructure/brique
SGBD : MySQL, PostGre...Moteurs de recherche : Lucene,Sol-R, Tsearch...
HTTP : Apache
Utilitaires
Editeurs XML,gestion de bibliographie,
Gestion d'enquêtesuite bureautique
gestion de planning...
Etat du marché français (suite)
Logiciels pour bibliothèques : 42 Millions d’Euros de CA en 2008 (en baisse
de 7% par rapport à 2007)
Source Tosca consultants
14 logiciels gratuits proposé sur le marché français en 2010 (Source Tosca) dont une minorité sont des logiciels open source au sens strict (PMB, Koha, Evergreen…) dont certains n’ont pas encore d’implémentation connue (Evergreen) les services sur ces logiciels sont offerts par des sociétés bénéficiant d’un quasi-monopole de fait
101 logiciels choisis sur le marché français en 2009, tous types de logiciels,
toutes versions (Source Tosca) 1 064 en BM, 25 en BDP, 6 522 en milieu scolaire, 317 en BU, 1 152 en bib. spécialisées BM 47 %, bib. spé. 31 %, écoles 9 % (hors BCDI)
Etat du marché français (suite)
Palmarès des SIGB retenus par fournisseurs en 2009 (Source Tosca) BM :
1. C3RB (Orphée) : 145
2. Décalog (Atalante, Carthame, Paprika) : 102
3. PMB Service (PMB) : 78
4. Agate Distribution (Agate, Amandine) : 61
5. AFI (Pergame) : 58 Bibliothèques spécialisées :
1. CRDP Poitou-Charentes (BCDI) : 258
2. PMB Services (PMB) : 124
3. Kentika (Kentika) : 118
Choisir le libre n’est plus un aventure
mais
• des logiciels de maturité différentes
• peu de recul sur le ROI (notamment pour les SIGB)
• peu de certitude sur la pérennité des communautés
• un modèle économique en évolution
• nouveaux acteurs
• nouvelles postures (redéfinition de la relation client/founisseur, nouveaux processus)
Le choix de « passer au libre » : contexte actuel
1 - une analyse des risques et des choix.
Tableau des choix
Projet traditionnel : Projet LOS :
Choix d’un fournisseur Choix d’un logiciel libre ou propriétaire
Choix du logiciel
Décision de développer des additifs
Décision de reverser les additifs
Décision de développer des additifs
Choix d’un prestataire
Quand et pourquoi passer au libre?
Quel investissement pour quel ROI?
Quels partenaires?
On « bascule » dans le libre
- Choix lié à l’absence de budget
- Ou à la volonté de passer au libre
- Procédures ou documents de consultation peu adaptés à une consultation mixte
- Budgets ou subventions inadaptés à une consultation mixte (budgets d’investissement ou de fonctionnement)
La comparaison entre logiciel libre et propriétaire est une situation encore peu fréquente
Quand et pourquoi passer au libre?
La couverture fonctionnelle
Attente :
Un logiciel plus complet ou un logiciel aussi complet mais moins cher
Risque : en cas de logiciel immature
Phase d’attente Décollage
Quand et pourquoi passer au libre?
En finir avec le verrouillage éditeur
Obligation de faire appel à l’éditeur pour certaines actions par manque de documentation par manque d’ouverture du logiciel
Ex : export de données
Pression sur les migrations « chantage » au contrat de maintenance arrêt des prestations et non maintien des compétences sur l’ancien produit
Rachats prédateursun produit est racheté par un éditeur dans l’intention de le tuer et de migrer le parc de clients sous son propre produit.
Quand et pourquoi passer au libre?
Evaluer la capacité de son organisation Le décideur :
Culture du modèle libre?
Confiance dans la communauté choisie?
Le service juridique :
Capacité à accepter un autre modèle de résolution de conflit que celui du contentieux?
Le service informatique:
Confiance dans la qualité des LL?
Capacité à revenir à une appropriation technique (ressources, savoir-faire) et non plus à une gestion des externalisations.
Capacité à maintenir un niveau de connaissance du produit suffisant pour ne pas être assujetti à un prestataire.
Les collaborateurs :
Capacité d’acceptation du modèle communautaire et de ses contraintes (tests des produits, tests des mises à jour), capacité à réguler et modérer les demandes d’évolution.
Le chef de projet :
Disponibilité, conscience des limites de ce qu’il peut contrôler
Capacité à endosser la responsabilité sans possibilité de la dériver sur un éditeur
Capacité à dire non à certaines demandes d’évolution
Quand et pourquoi passer au libre?
Cas du ROI direct
ROI
DEVELOPPEMENT
+
+
-
-
Moins on développe, plus le ROI est élevé (et rapide)
Attitudes possibles :
Choisir un logiciel dont les fonctionnalités correspondent exactement aux besoins fonctionnels (s’il existe)
Attendre qu’un logiciel atteigne la couverture fonctionnelle souhaitée
Adapter le besoin à l’offre : se contenter des fonctionnalités existantes
Quel investissement, quel ROI?
Cas du ROI par échange
On investit dans le développement jusqu’au moment où la couverture fonctionnelle attire d’autres membres qui développent à leur tour
DEVELOPPEMENT
+
+
-
-
ROI Décollage
Implique :Confiance du décideur dans la communautéTrès bonne relation avec la communautéPouvoir attendre un ROI à moyen terme
Risque :Que le décollage ne se produise pasQue le décollage se produise trop tard
Quel investissement, quel ROI?
Cas du ROI par notoriété
Les efforts de développements sont compensés par un capital immatériel : notoriété, attention de l’environnement professionnel, situation privilégiée dans la communauté ou dans le réseau d’activité
DEVELOPPEMENT
+
+
-
-
ROIimmatériel
Avantages :Bénéfice du leadership (individuel ou de la part de l’organisation)Bénéfice du précurseur : la communauté est plus attentive et
réactive dans les premières années.
Difficulté : Convaincre le décideur
Quel investissement, quel ROI?
Axiome :
Il n’y a pas d’opposition tranchée entre éditeur traditionnel et communauté libre
Quels partenaires?
Éditeur propriétaire
Éditeur libreÉditeur propriétaireCommunauté
hyper centralisée
Communauté centralisée
+ développeurspériphériques
Joyeux bazar
En théorie tout le monde peut assurer des prestations de service sur des systèmes ouverts sous licence open source
Quels partenaires? le cas du prestataire de service “historique”
En pratique celui qui a développé le produit ou qui le suit depuis ses origines sera plus compétitif
Pratique courante :
Faire appel à la société de service de l’éditeur libre ou du leader de la communauté
Risques• Non respect de la méthodologie projet (mise en concurrence)• Situation de monopole (coûts plus élevés)• Dissuasion des nouveaux entrants• Risque de verrouillage prestataire
Ouvrir largement la consultation à d’autres prestataires
Risque : prestataire ne connaissant pas bien les fonctionnalités ou nos métiers
Lancer une consultation globale sur les besoins fonctionnels, sans préjuger du produit, open source ou propriétaire
Les intégrateurs répondent avec un logiciel libre ou propriétaire de leur choix
Peut être le modèle qui se dégagera avec la maturité des LL.
Quels partenaires? autres choix
Conclusion (provisoire)
La fin des processus projets ?
Des tâches amont toujours essentielles
Des budgets à gérer
Des mises en concurrence indispensables
L’approche logiciel ne doit pas supplanter l’approche fonctionnelle
Des rôles et des responsabilités à définir clairement
2 - Avant le choix
Le paradoxe du libre (pour l'utilisateur) :
Comment exercer la “liberté d'accéder au code source, de l'étudier, de l'adapter » quand on n'est pas informaticien ou que l’on ne dispose pas de ressources internes suffisantes ?
en louant les compétences d'un tiers technique.
Comment se donner des garanties d'assistance, de correction, d'évolution ?
en contractant avec un tiers technique, ou avec une structure issue de la communauté.
Les nouveaux modèles économiques et techniques
Paradoxe du libre (pour la communauté de développeurs) :
en troquant le modèle du bénévolat contre un modèle marchand pour rémunérer les techniciens.
Comment « faire le job » quand il y a plus de prescripteurs que de développeurs dans la communauté et qu'il faut en outre assurer une assistance à l'utilisation?
Les nouveaux modèles économiques et techniques
La décision
Choisir de choisir : on fait le choix du libre un logiciel libre a été évalué et jugé adéquat ou l’offre libre est jugée suffisamment conséquente
(cas des ECM, par exemple, et depuis peu des couches OPAC 2.0)
mise en œuvre réalisée en interne ou appel à un prestataire
Choisir de ne pas choisir : on souhaite mettre en concurrence l’offre libre et l’offre propriétaire
l’offre libre n’est pas suffisante ou assez convaincante ou bien l’on souhaite se donner des garanties de mise en œuvre
procédure classique de mise en concurrence (appel d’offres)
Relativité du critère budgétaire
Dans un projet open source les critères budgétaires ne doivent pas être prépondérants
coûts d’investissements moindres
mais dichotomie charges internes / charges externes
coûts de licences nuls ou presque (cas des open source à distribution
payante)
mais des droits attachés aux licences qui peuvent être complexes
Évaluer les coûts cachés
investissement temps humain
coût interne ou externalisation (études et développements)
des mises en œuvre qui s’allongent dans le temps
La nécessaire analyse préalable
Dans un projet open source le critère organisationnel est crucial
un projet open source ne peut être mené sans équipe
il n’est plus possible de dériver la responsabilité sur un éditeur (externalisation de la responsabilité)
Le « plus » du prototypage
Conclusion : le temps passé par les équipes est plus important. On y gagne en adhésion et motivation, on y perd en ressources mobilisées
Dans un projet open source on ne peut pas faire l’économie d’une analyse préalable
Cette analyse préalable doit répondre aux questions suivantes :
l’outil pressenti répond il aux besoins minimaux ?
les contraintes ont-elles été analysées ?
le contexte organisationnel a-t-il été pris en compte ?
si cette étude est externalisée, elle constitue un coût à prendre en compte
La nécessaire analyse préalable
Evaluer les communautés de développement libre
- évaluer la communauté site web, forums, listes de diffusion
- critères d’évaluation Mesurer le nombre et la variété des participants Vérifier la proximité d’intérêt des institutions concernées S’assurer de l’importance et du positionnement des développeurs Vérifier que les procédures de contributions sont bien formalisées
- identifier les compétences SSLL consultants équipes informatiques dans des établissements parties prenantes de la
communauté croiser avec des critères thématiques (qui fait quoi en terme de maintenance
évolutive, de reprise de données, d’intégration, …)
Caractéristiques des communautés des applications métier (Koha, PMB…) :
nombre de membres réduit, parfois concentrés dans une société de service ou dans un établissement
membres non techniciens
développeurs non praticiens
fonctionnalités : diverses, mouvantes
utilisateurs en attente d'assistance
contexte d'utilisation exclusivement professionnel
Recenser et évaluer les communautés de développement libre
Caractéristiques des communautés d'infrastructures ou des applications transverses (MySQL, Typo3, Alfresco…) :
nombre de membres important
membres techniciens
contributeurs / utilisateurs
fonctionnalités homogènes
utilisateurs autonomes
contextes d'utilisation divers (y compris recherche)
Evaluer les communautés de développement libre
3 - Le cahier des charges
Choix a priori : trouver un prestataire
Objet du cahier des charges
Trouver un prestataire pour la mise en oeuvre du logiciel identifié
Type de consultation : prestation de services
Options possibles : • au forfait
implique de connaître parfaitement le logiciel, d’en connaître les limites et les capacités et de définir très précisément la prestation attendue : type de prestation (paramétrages, migration de données, développement, intégration)
Si développement, il faut décrire les développements attendus et leur destination (reversement ou non)
s’adresse plutôt à des prestataires qui connaissent le métier
• au temps passé (régie) recrutement d’une compétence technique pour réaliser des
prestations qui peuvent ne pas être définies précisément à l’avance ne dispense pas de bien connaître le logiciel et implique un pilotage
informatique stricte en interne peut s’adresser à des prestataires qui ne connaissent pas le métier ou le
domaine
Choix a posteriori : trouver une solution
Objet du cahier des charges
Acquérir un logiciel et faire assurer sa mise en oeuvre
Type de consultation : acquisition et mise en œuvre de logiciel(s) (voire de matériel associé)
Options possibles : • avec prototypage en tranche ferme
prototype sur un nombre restreint de licences prototype sur un nombre limité de fonctions
dans les 2 cas, implique disponibilité pour tester le prototype et un planning étiré
• sans prototypage
Autres options possibles :• dialogue compétitif
envisageable pour des projets novateurs et sans caractère d’urgence
Le cahier de charges ne doit pas être un faux nez !
4 - La mise en oeuvre
typologie des projets libres et open source
Développement collaboratif
On développe les fonctions manquantes que l'on reverse à la communauté
« Sur étagère »
le logiciel est accepté tel que sans modifications.
Intégration
Plusieurs logiciels Open Source sont associés sous une même interface graphique/ergonomique/fonctionnelle
S'éloigner ou non du standard
Cas de développements additionnels reversés (et intégrés par la communauté) :
Fonctionnement classique d'une communauté, les modifications sont intégrées au logiciel et seront disponibles dans les nouvelles versions.
Cas de développements additionnels non reversés ou non intégrés par la communauté :
Renoncement aux nouvelles versions. éventuellement création d'un fork.
Ou
Documentation rigoureuse des additifs et réintégration des ajouts à chaque chargement d'une nouvelle version. Coût récurrent
typologie des projets libres et open source
Spécificités d’un projet « libre »
identification et évaluation des logiciels open source
évaluation de la communauté
choix du reversement ou non des modifications
absence de relation client/fournisseur dans le cas d'un travail direct avec la communauté
si prestataire (SSLL) il ne s’engage que sur ses prestations, et non sur l’évolution du logiciel
Similitudes avec un projet “propriétaire”
analyse des besoins
gestion projet des développements
relation client/fournisseur dans le cas d'un recours à une SSII
Similitude et spécificités
Repenser la relation contractuelle ?
L’engagement à l’aune du libre…
- Plusieurs acteurs Le commanditaire (maîtrise d’ouvrage) Le prestataire (maîtrise d’œuvre) La communauté
Or seul le commanditaire et le prestataire sont liés contractuellement
- Un positionnement non étanche Le commanditaire peut faire partie de la communauté Le prestataire également, quand il n’en est pas la composante principale ou le
prescripteur en chef La communauté n’est pas sensée connaître le lien contractuel entre le
commanditaire et son prestataire… - Quelles seraient les règles de bonne conduite ?
Le prestataire ne doit pas s’engager contractuellement sur des évolutions et des développements en sachant que ceux-ci doivent être validés par la communauté sinon, il doit proposer les modalités précises de gestion des développements additionnels
Le prestataire ne doit pas invoquer les décisions de la communauté pour ne pas honorer un engagement contractuel
Le commanditaire doit se doter de garde fous organisationnels pour que la communauté ne s’immisce pas dans ses arbitrages fonctionnels et techniques et ne lui impose pas son propre calendrier
5 – conclusion
dans une période pionnière, le coût d’un projet open source n’est pas nécessairement déterminant par rapport à une solution « propriétaire »
le retour sur investissement n’est pas immédiat solution non viable si non portée par une équipe l’avenir du projet open source (retour sur
investissement rapide) réside donc dans la mutualisation (consortium, groupements d’achat..)
…ce qui est dans la logique communautaire du libre