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)

lsoual@doxulting.fr

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