L soual abf 21 mai 2010_opensource

1 901 vues

Publié le

0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
1 901
Sur SlideShare
0
Issues des intégrations
0
Intégrations
545
Actions
Partages
0
Téléchargements
29
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • que signifie aujourd'hui, pour une bibliothèque, monter un projet open source, quelles compétences mobiliser en interne et en externe, comment présenter l'option et mener à la décision, etc. La présentation devrait inclure aussi la question des coûts (dans l'absolu mais aussi dans une approche comparative avec les solutions propriétaires, en termes d'investissement et en termes de maintenance)  et  l'état et les évolutions du marché, les difficultés à prendre en compte. C'est l' approche alternative
  • SIGB : la mode des gratuits bouscule le marché CMS ECM se partagent entre : orientés Web (CMS) et Ged (plus rares) Alfresco. Ezpublish et Drupal ont gagné les entreprises (plus rapides à intégrer que typo3), plus complets que SPIP et Djoomla. Tendances : l’ouverture des api microsoft (decision européenne anti monopole) permet une intégration avec la suite bureautique. Alfresco se dote d’outils collaboratifs Tendances actuelles : SAAS Recherche d’une intégration plus grande entre GED et orientation web. Infrastructure : moccam : récupération en ligne de notices unimarc est intégré à des portails.
  • Ged Numérisation, traitement, group ware, archivage des documents de l’entreprise selon utilité légale. WCM : rédaction, validation, mise en ligne des contenus des sites web intrane textranet, génération de sites multilingues Collaboratif : agenda partagé, forums, edition de doc , messageire instantanée, visio conférence, partage d’applications Workflow-BPM : documentaire : circuit de validation de documents ou workflow métier dématérialisation des procédures. + ou _ orientés publication Certains gèrent des alertes de fin de cycle de vie
  • SIGB : la mode des gratuits bouscule le marché CMS ECM se partagent entre : orientés Web (CMS) et Ged (plus rares) Alfresco. Ezpublish et Drupal ont gagné les entreprises (plus rapides à intégrer que typo3), plus complets que SPIP et Djoomla. Tendances : l’ouverture des api microsoft (decision européenne anti monopole) permet une intégration avec la suite bureautique. Alfresco se dote d’outils collaboratifs Tendances actuelles : SAAS Recherche d’une intégration plus grande entre GED et orientation web. Infrastructure : moccam : récupération en ligne de notices unimarc est intégré à des portails.
  • L soual abf 21 mai 2010_opensource

    1. 1. que signifie aujourd'hui, pour une bibliothèque, monter un projet open source ? Table ronde ABF 21 mai 2010 Laurent Soual (doXulting) [email_address]
    2. 2. Sommaire Introduction : contexte et enjeux des logiciels libres en bibliothèque 1 - 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
    3. 3. Introduction : contexte actuel et enjeux des logiciels libres en documentation et bibliothèque
    4. 4. De quoi parle-t-on : ce que je peux faire avec un logiciel libre <ul><li>Ne pas confondre gratuit ( free en anglais) et open source ou libre ( free également en anglais…) </li></ul><ul><ul><li>un logiciel open source peut être payant </li></ul></ul><ul><ul><li>un logiciel propriétaire (code source non ouvert), peut être gratuit </li></ul></ul><ul><li>open source : ce que je peux faire techniquement : </li></ul><ul><ul><li>étudier le code source pour en comprendre la logique </li></ul></ul><ul><ul><li>copier des parties de code pour faire un autre logiciel </li></ul></ul><ul><ul><li>corriger des bugs </li></ul></ul><ul><ul><li>ajouter des fonctions manquantes </li></ul></ul><ul><ul><li>améliorer les fonctions existantes </li></ul></ul><ul><ul><li>l'associer à un autre code </li></ul></ul><ul><ul><li>supprimer une partie du code... </li></ul></ul><ul><li>Ce que je peux faire légalement : </li></ul><ul><ul><li>Utiliser le programme dans mon activité professionnelle, en cours, le donner à des élèves, à des clients </li></ul></ul><ul><ul><li>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 </li></ul></ul><ul><li>dans le cadre défini par la licence. </li></ul>
    5. 5. 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)
    6. 6. Les logiciels libres d’ECM/CMS/GED SIGB Koha PMB Greenstone Outils de diffusion MoCCAM VUFind BlackLight LibraryFind … CMS ECM GED + ou - orientés portail Ez publish Spip (php mysql) ‏ Alfresco(Java) ‏ Nuxeo (J2EE) ‏ Drupal, Typo3… Infrastructure/brique SGBD : MySQL, PostGre... Moteurs de recherche : Lucene,Sol-R, Tsearch... HTTP : Apache Autres : eXist (gestion de bdd xml) ‏ Utilitaires Editeurs XML, gestion de bibliographie, Gestion d'enquête suite bureautique gestion de planning...
    7. 7. Le marché GED /ECM / CMS GED WCM COllaboratif RM Work flow SPIP, JOOMLA, DRUPAL,Typo3, eZpublish, Jahia, Nuxeo, Alfresco DAM On dénombre 240 logiciels libres dans le domaine ECM/CMS <ul><li>Marché : </li></ul><ul><li>prometteur </li></ul><ul><li>international (européen) </li></ul><ul><li>concurrentiel </li></ul>
    8. 8. Les logiciels libres en bibliothéconomie SIGB Koha PMB Evergreen Outils de diffusion MoCCAM VUFind BlackLight LibraryFind CMS ECM GED + ou - orientés portail Ez publish Spip (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ête suite bureautique gestion de planning...
    9. 9. 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 <ul><li>14 logiciels gratuits proposé sur le marché français en 2010 (Source Tosca) </li></ul><ul><li>dont une minorité sont des logiciels open source au sens strict (PMB, Koha, Evergreen…) </li></ul><ul><li>dont certains n’ont pas encore d’implémentation connue (Evergreen) </li></ul><ul><li>les services sur ces logiciels sont offerts par des sociétés bénéficiant d’un quasi-monopole de fait </li></ul><ul><li>101 logiciels choisis sur le marché français en 2009, tous types de logiciels, toutes versions (Source Tosca) </li></ul><ul><li>1 064 en BM, 25 en BDP, 6 522 en milieu scolaire, 317 en BU, 1 152 en bib. spécialisées </li></ul><ul><li>BM 47 %, bib. spé. 31 %, écoles 9 % ( hors BCDI ) </li></ul>
    10. 10. Etat du marché français (suite) <ul><li>Palmarès des SIGB retenus par fournisseurs en 2009 (Source Tosca) </li></ul><ul><li>BM : </li></ul><ul><ul><li>C3RB (Orphée) : 145 </li></ul></ul><ul><ul><li>Décalog (Atalante, Carthame, Paprika) : 102 </li></ul></ul><ul><ul><li>PMB Service (PMB) : 78 </li></ul></ul><ul><ul><li>Agate Distribution (Agate, Amandine) : 61 </li></ul></ul><ul><ul><li>AFI (Pergame) : 58 </li></ul></ul><ul><li>Bibliothèques spécialisées : </li></ul><ul><ul><li>CRDP Poitou-Charentes (BCDI) : 258 </li></ul></ul><ul><ul><li>PMB Services (PMB) : 124 </li></ul></ul><ul><ul><li>Kentika (Kentika) : 118 </li></ul></ul>
    11. 11. <ul><li>Choisir le libre n’est plus un aventure </li></ul><ul><li>mais </li></ul><ul><li>des logiciels de maturité différentes </li></ul><ul><li>peu de recul sur le ROI (notamment pour les SIGB) </li></ul><ul><li>peu de certitude sur la pérennité des communautés </li></ul><ul><li>un modèle économique en évolution </li></ul><ul><li>nouveaux acteurs </li></ul><ul><li>nouvelles postures (redéfinition de la relation client/founisseur, nouveaux processus) </li></ul>Le choix de « passer au libre » : contexte actuel
    12. 12. 1 - une analyse des risques et des choix.
    13. 13. 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
    14. 14. <ul><li>Quand et pourquoi passer au libre? </li></ul><ul><li>Quel investissement pour quel ROI? </li></ul><ul><li>Quels partenaires? </li></ul>
    15. 15. <ul><li>On « bascule » dans le libre </li></ul><ul><ul><ul><li>- Choix lié à l’absence de budget </li></ul></ul></ul><ul><ul><ul><li>- Ou à la volonté de passer au libre </li></ul></ul></ul><ul><ul><ul><li>- Procédures ou documents de consultation peu adaptés </li></ul></ul></ul><ul><ul><ul><li>à une consultation mixte </li></ul></ul></ul><ul><ul><ul><li>- Budgets ou subventions inadaptés à une consultation mixte </li></ul></ul></ul><ul><ul><ul><li>(budgets d’investissement ou de fonctionnement) </li></ul></ul></ul>La comparaison entre logiciel libre et propriétaire est une situation encore peu fréquente Quand et pourquoi passer au libre?
    16. 16. <ul><li>La couverture fonctionnelle </li></ul><ul><li>Attente : </li></ul><ul><li>Un logiciel plus complet ou un logiciel aussi complet mais moins cher </li></ul><ul><li>Risque : en cas de logiciel immature </li></ul>Phase d’attente Décollage Quand et pourquoi passer au libre?
    17. 17. <ul><li>En finir avec le verrouillage éditeur </li></ul><ul><li>Obligation de faire appel à l’éditeur pour certaines actions </li></ul><ul><li>par manque de documentation </li></ul><ul><li>par manque d’ouverture du logiciel </li></ul><ul><li>Ex : export de données </li></ul><ul><li>Pression sur les migrations </li></ul><ul><li>« chantage » au contrat de maintenance </li></ul><ul><li>arrêt des prestations et non maintien des compétences sur l’ancien produit </li></ul>Rachats prédateurs un 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?
    18. 18. Evaluer la capacité de son organisation <ul><li>Le décideur : </li></ul><ul><ul><li>Culture du modèle libre? </li></ul></ul><ul><ul><li>Confiance dans la communauté choisie? </li></ul></ul><ul><li>Le service juridique : </li></ul><ul><li> Capacité à accepter un autre modèle de résolution de conflit que celui du contentieux? </li></ul><ul><li>Le service informatique: </li></ul><ul><li>Confiance dans la qualité des LL? </li></ul><ul><li>Capacité à revenir à une appropriation technique (ressources, savoir-faire) et non plus à une gestion des externalisations. </li></ul><ul><li>Capacité à maintenir un niveau de connaissance du produit suffisant pour ne pas être assujetti à un prestataire. </li></ul><ul><li>Les collaborateurs : </li></ul><ul><li>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. </li></ul><ul><li>Le chef de projet : </li></ul><ul><li>Disponibilité, conscience des limites de ce qu’il peut contrôler </li></ul><ul><li>Capacité à endosser la responsabilité sans possibilité de la dériver sur un éditeur </li></ul><ul><li>Capacité à dire non à certaines demandes d’évolution </li></ul>Quand et pourquoi passer au libre?
    19. 19. <ul><li>Cas du ROI direct </li></ul>Quel investissement, quel ROI? 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
    20. 20. <ul><li>Cas du ROI par échange </li></ul>Quel investissement, quel ROI? 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 pas Que le décollage se produise trop tard
    21. 21. <ul><li>Cas du ROI par notoriété </li></ul>Quel investissement, quel ROI? 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 + + - - ROI immaté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
    22. 22. <ul><li>Axiome : </li></ul><ul><li>Il n’y a pas d’opposition tranchée entre éditeur traditionnel et communauté libre </li></ul>Quels partenaires ? Éditeur propriétaire Éditeur libre Éditeur propriétaire Communauté hyper centralisée Communauté centralisée + développeurs périphériques Joyeux bazar
    23. 23. <ul><li>En théorie tout le monde peut assurer des prestations de service sur des systèmes ouverts sous licence open source </li></ul>Quels partenaires? le cas du prestataire de service “historique” <ul><li>En pratique celui qui a développé le produit ou qui le suit depuis ses origines sera plus compétitif </li></ul>Pratique courante : Faire appel à la société de service de l’éditeur libre ou du leader de la communauté <ul><li>Risques </li></ul><ul><li>Non respect de la méthodologie projet (mise en concurrence) </li></ul><ul><li>Situation de monopole (coûts plus élevés) </li></ul><ul><li>Dissuasion des nouveaux entrants </li></ul><ul><li>Risque de verrouillage prestataire </li></ul>
    24. 24. <ul><li>Ouvrir largement la consultation à d’autres prestataires </li></ul><ul><li>Risque : prestataire ne connaissant pas bien les fonctionnalités ou nos métiers </li></ul>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
    25. 25. Conclusion (provisoire) <ul><li>La fin des processus projets ? </li></ul>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
    26. 26. 2 - Avant le choix
    27. 27. Les nouveaux modèles économiques et techniques 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 ? <ul><li>en louant les compétences d'un tiers technique. </li></ul>Comment se donner des garanties d'assistance, de correction, d'évolution ? <ul><li>en contractant avec un tiers technique, ou avec une structure issue de la communauté. </li></ul>
    28. 28. Les nouveaux modèles économiques et techniques Paradoxe du libre (pour la communauté de développeurs) : <ul><ul><li>en troquant le modèle du bénévolat contre un modèle marchand pour rémunérer les techniciens. </li></ul></ul>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?
    29. 29. La décision <ul><li>Choisir de choisir : on fait le choix du libre </li></ul><ul><ul><li>un logiciel libre a été évalué et jugé adéquat </li></ul></ul><ul><ul><li>ou l’offre libre est jugée suffisamment conséquente </li></ul></ul><ul><ul><ul><li>(cas des ECM, par exemple, et depuis peu des couches OPAC 2.0) </li></ul></ul></ul><ul><ul><li>mise en œuvre réalisée en interne ou appel à un prestataire </li></ul></ul><ul><li>Choisir de ne pas choisir : on souhaite mettre en concurrence l’offre libre et l’offre propriétaire </li></ul><ul><ul><li>l’offre libre n’est pas suffisante ou assez convaincante </li></ul></ul><ul><ul><li>ou bien l’on souhaite se donner des garanties de mise en œuvre </li></ul></ul><ul><ul><li>procédure classique de mise en concurrence (appel d’offres) </li></ul></ul>
    30. 30. Relativité du critère budgétaire <ul><li>Dans un projet open source les critères budgétaires ne doivent pas être prépondérants </li></ul><ul><ul><li>coûts d’investissements moindres </li></ul></ul><ul><ul><ul><li>mais dichotomie charges internes / charges externes </li></ul></ul></ul><ul><ul><li>coûts de licences nuls ou presque (cas des open source à distribution payante) </li></ul></ul><ul><ul><ul><li>mais des droits attachés aux licences qui peuvent être complexes </li></ul></ul></ul><ul><ul><li>Évaluer les coûts cachés </li></ul></ul><ul><ul><ul><li>investissement temps humain </li></ul></ul></ul><ul><ul><ul><li>coût interne ou externalisation (études et développements) </li></ul></ul></ul><ul><ul><ul><li>des mises en œuvre qui s’allongent dans le temps </li></ul></ul></ul>
    31. 31. La nécessaire analyse préalable <ul><li>Dans un projet open source le critère organisationnel est crucial </li></ul><ul><ul><li>un projet open source ne peut être mené sans équipe </li></ul></ul><ul><ul><li>il n’est plus possible de dériver la responsabilité sur un éditeur (externalisation de la responsabilité) </li></ul></ul><ul><ul><li>Le « plus » du prototypage </li></ul></ul><ul><ul><li>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 </li></ul></ul>
    32. 32. La nécessaire analyse préalable <ul><li>Dans un projet open source on ne peut pas faire l’économie d’une analyse préalable </li></ul><ul><li>Cette analyse préalable doit répondre aux questions suivantes : </li></ul><ul><ul><li>l’outil pressenti répond il aux besoins minimaux ? </li></ul></ul><ul><ul><li>les contraintes ont-elles été analysées ? </li></ul></ul><ul><ul><li>le contexte organisationnel a-t-il été pris en compte ? </li></ul></ul><ul><ul><li>si cette étude est externalisée, elle constitue un coût à prendre en compte </li></ul></ul>
    33. 33. Evaluer les communautés de développement libre <ul><li>- évaluer la communauté </li></ul><ul><ul><li>site web, forums, listes de diffusion </li></ul></ul><ul><li>- critères d’évaluation </li></ul><ul><ul><li>Mesurer le nombre et la variété des participants </li></ul></ul><ul><ul><li>Vérifier la proximité d’intérêt des institutions concernées </li></ul></ul><ul><ul><li>S’assurer de l’importance et du positionnement des développeurs </li></ul></ul><ul><ul><li>Vérifier que les procédures de contributions sont bien formalisées </li></ul></ul><ul><li>- identifier les compétences </li></ul><ul><ul><li>SSLL </li></ul></ul><ul><ul><li>consultants </li></ul></ul><ul><ul><li>équipes informatiques dans des établissements parties prenantes de la communauté </li></ul></ul><ul><ul><li>croiser avec des critères thématiques (qui fait quoi en terme de maintenance évolutive, de reprise de données, d’intégration, …) </li></ul></ul>
    34. 34. Recenser et évaluer les communautés de développement libre <ul><li>Caractéristiques des communautés des applications métier (Koha, PMB…) : </li></ul><ul><ul><li>nombre de membres réduit, parfois concentrés dans une société de service ou dans un établissement </li></ul></ul><ul><ul><li>membres non techniciens </li></ul></ul><ul><ul><li>développeurs non praticiens </li></ul></ul><ul><ul><li>fonctionnalités : diverses, mouvantes </li></ul></ul><ul><ul><li>utilisateurs en attente d'assistance </li></ul></ul><ul><ul><li>contexte d'utilisation exclusivement professionnel </li></ul></ul>
    35. 35. Evaluer les communautés de développement libre <ul><li>Caractéristiques des communautés d'infrastructures ou des applications transverses (MySQL, Typo3, Alfresco…) : </li></ul><ul><ul><li>nombre de membres important </li></ul></ul><ul><ul><li>membres techniciens </li></ul></ul><ul><ul><li>contributeurs / utilisateurs </li></ul></ul><ul><ul><li>fonctionnalités homogènes </li></ul></ul><ul><ul><li>utilisateurs autonomes </li></ul></ul><ul><ul><li>contextes d'utilisation divers (y compris recherche) ‏ </li></ul></ul>
    36. 36. 3 - Le cahier des charges
    37. 37. Choix a priori : trouver un prestataire Objet du cahier des charges Trouver un prestataire pour la mise en oeuvre du logiciel identifié <ul><li>Type de consultation : prestation de services </li></ul><ul><li>Options possibles : </li></ul><ul><ul><li>au forfait </li></ul></ul><ul><ul><ul><li>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) </li></ul></ul></ul><ul><ul><ul><li>Si développement, il faut décrire les développements attendus et leur destination (reversement ou non) </li></ul></ul></ul><ul><ul><ul><li>s’adresse plutôt à des prestataires qui connaissent le métier </li></ul></ul></ul><ul><ul><li>au temps passé (régie) </li></ul></ul><ul><ul><ul><li>recrutement d’une compétence technique pour réaliser des prestations qui peuvent ne pas être définies précisément à l’avance </li></ul></ul></ul><ul><ul><ul><li>ne dispense pas de bien connaître le logiciel et implique un pilotage informatique stricte en interne </li></ul></ul></ul><ul><ul><ul><li>peut s’adresser à des prestataires qui ne connaissent pas le métier ou le domaine </li></ul></ul></ul>
    38. 38. Choix a posteriori : trouver une solution Objet du cahier des charges Acquérir un logiciel et faire assurer sa mise en oeuvre <ul><li>Type de consultation : acquisition et mise en œuvre de logiciel(s) (voire de matériel associé) </li></ul><ul><li>Options possibles : </li></ul><ul><ul><li>avec prototypage en tranche ferme </li></ul></ul><ul><ul><ul><li>prototype sur un nombre restreint de licences </li></ul></ul></ul><ul><ul><ul><li>prototype sur un nombre limité de fonctions </li></ul></ul></ul><ul><ul><ul><ul><li>dans les 2 cas, implique disponibilité pour tester le prototype et un planning étiré </li></ul></ul></ul></ul><ul><ul><li>sans prototypage </li></ul></ul><ul><li>Autres options possibles : </li></ul><ul><ul><li>dialogue compétitif </li></ul></ul><ul><ul><ul><li>envisageable pour des projets novateurs et sans caractère d’urgence </li></ul></ul></ul>Le cahier de charges ne doit pas être un faux nez !
    39. 39. 4 - La mise en oeuvre
    40. 40. 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
    41. 41. 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
    42. 42. <ul><li>Spécificités d’un projet « libre » </li></ul><ul><li>identification et évaluation des logiciels open source </li></ul><ul><li>évaluation de la communauté </li></ul><ul><li>choix du reversement ou non des modifications </li></ul><ul><li>absence de relation client/fournisseur dans le cas d'un travail direct avec la communauté </li></ul><ul><li>si prestataire (SSLL) il ne s’engage que sur ses prestations, et non sur l’évolution du logiciel </li></ul><ul><li>Similitudes avec un projet “propriétaire ” </li></ul><ul><li>analyse des besoins </li></ul><ul><li>gestion projet des développements </li></ul><ul><li>relation client/fournisseur dans le cas d'un recours à une SSII </li></ul>Similitude et spécificités
    43. 43. Repenser la relation contractuelle ? <ul><li>L’engagement à l’aune du libre… </li></ul><ul><li>- Plusieurs acteurs </li></ul><ul><ul><li>Le commanditaire (maîtrise d’ouvrage) </li></ul></ul><ul><ul><li>Le prestataire (maîtrise d’œuvre) </li></ul></ul><ul><ul><li>La communauté </li></ul></ul><ul><li>Or seul le commanditaire et le prestataire sont liés contractuellement </li></ul><ul><li>- Un positionnement non étanche </li></ul><ul><ul><li>Le commanditaire peut faire partie de la communauté </li></ul></ul><ul><ul><li>Le prestataire également, quand il n’en est pas la composante principale ou le prescripteur en chef </li></ul></ul><ul><ul><li>La communauté n’est pas sensée connaître le lien contractuel entre le commanditaire et son prestataire… </li></ul></ul><ul><li>- Quelles seraient les règles de bonne conduite ? </li></ul><ul><ul><li>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é </li></ul></ul><ul><ul><ul><li>sinon, il doit proposer les modalités précises de gestion des développements additionnels </li></ul></ul></ul><ul><ul><li>Le prestataire ne doit pas invoquer les décisions de la communauté pour ne pas honorer un engagement contractuel </li></ul></ul><ul><ul><li>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 </li></ul></ul>
    44. 44. 5 – conclusion <ul><li>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 » </li></ul><ul><li>le retour sur investissement n’est pas immédiat </li></ul><ul><li>solution non viable si non portée par une équipe </li></ul><ul><li>l’avenir du projet open source (retour sur investissement rapide) réside donc dans la mutualisation (consortium, groupements d’achat..) </li></ul><ul><li>… ce qui est dans la logique communautaire du libre </li></ul>

    ×