Vite fait, parce que c’est la saison des grands ménages mais aussi les vacances :-), un sélection d’outils open :
– Annotum est une extension de Worpress qui permet d’en faire un outil de publication scientifique.
– Showme : une plateforme ouverte de vidéos pédagogiques, sur toutes sortes de thèmes (art, musique, langues, sciences…)
– CASH Music : une plateforme open source de publication en direction des artistes
– Il n’y a pas que Zotero dans la vie : il y a aussi Mendeley, et voici une série de tutoriels vidéo en français.
– F1000Research : open peer-review, publication rapide, datasets, révisions, multi-format, le tout sous licence CC ; bref, un nouveau projet éditorial à suivre.
Archive for the 'Open source' Category
Le marché du mardi, n°46
Published 26/04/2012 I went to the market , Open Access , Open source Leave a Comment
J’ai assisté les 26 et 27 mai au 2ème symposium Koha organisé par l’association KohaLa à Lyon. Organisation remarquable, à mettre au crédit des collègues du SCD de Lyon 2 (à part la wifi qui n’a guère fonctionné, mais les collègues n’y sont pour rien). Contre toute attente*, 2 journées très riches d’interventions variées, laissant la part belle aux retours d’expériences et abordant des thématiques cruciales comme le rapport avec les fournisseurs dans le contexte du logiciel libre ou les changements organisationnels induits par le passage à Koha. Et des ateliers plus techniques (sur XSLT et SQL, et même une install party !) qui ont eu paraît-il un franc succès auprès des participants. Les diaporamas et les podcasts des journées seront bientôt mis à disposition sur le futur site du symposium, où l’on trouvera également celles de l’année passée. Juste quelques notes sur les conférences auxquelles j’ai assisté :
Travailler avec les professionnels du libre
Bon casting pour cette table ronde qui rassemblait P. Poulain pour BibLibre, R. Ganier pour Progilone et F. Aubriot pour PLOSS Rhône Alpes, animée avec pertinence par F. Elie, président de l’ADULLACT. Les points saillants que j’ai relevés :
– Le manque d’info sur les développements est un handicap pour les sociétés de services comme pour les bibliothécaires. L’exemple de mutualisation Lyon 2 / Lyon 3 / St Etienne fait figure d’exception, la plupart des bibliothèques déployées ou en cours de déploiement ne partage pas ses développements. Pour atténuer cette opacité, le mot d’ordre c’est la mutualisation : KohaLa pourrait être, sinon le lieu, du moins la caisse de résonance pour ce type d’information. L’AG de l’association qui a eu lieu en fin de journée a, du reste, validé la mise en ligne d’un annuaire des établissements déployés, enrichi de la liste des développements en cours ou prévus.
– Le manque de structuration de la communauté française : la communauté des utilisateurs est assez réduite et peine à collaborer, et l’investissement des bibliothécaires dans la communauté internationale est quasi-nul (c’est un prestataire, en l’occurrence Paul Poulain, qui fait le lien) ; on évoque la barrière de la langue, of course… mais il faudra bien définir, à un moment ou un autre, le rôle de chacun (bibliothécaires et prestataires)
– Le temps des marchés publics n’est pas adapté à l’évolution rapide des logiciels libres ; le passage du modèle de feature-based releases (on sort une nouvelle version une fois que toutes les fonctionnalités prévues sont prêtes) à une logique de time-based releases (on sort une nouvelle version selon une fréquence définie à l’avance, si les fonctionnalités ne sont pas prêtes cette fois, elles seront dans la version suivante), décidé par la communauté Koha (une nouvelle version tous les 6 mois), devrait être un atout pour les établissements. C’est toute l’économie de la maintenance des systèmes qui est en jeu derrière.
Les changements dans l’organisation du travail : Retours d’expérience du SAN Ouest Provence, des SCD de Lyon 2 et de Lyon 3
– La mise en place de Koha a induit une dynamique de « work in progress » au SAN Ouest Provence : démarche permanente d’apprentissage, d’évolution. Volonté d’être contributeurs du logiciel, et mise à disposition des ressources humaines nécessaires en informatique
– Accélération de la dématérialisation des procédures pour les acquisitions à Lyon 2, au prix d’une augmentation certaine du temps de traitement des commandes – les développements en cours pour St Etienne devraient améliorer les choses.
– Repérage de besoins en formation des personnels aux bases de l’informatique à Lyon 3 ; certaines fonctionnalités (relances, réservations, outils d’interactivité avec l’usager) soulèvent des questionnements chez les personnels et incitent à une réflexion sur une nouvelle organisation de certains services.
Des outils pour extraire des statistiques dans Koha : Birt (F. Barré, Lyon 2) et JasperReports (L. Prête, Progilone)
Birt et JasperReports sont 2 outils open source de création de rapports. Leur intérêt principal est qu’ils permettent d’agréger des données provenant de sources différentes (par exemple les prêts et les entrées) : on peut ainsi réaliser de véritables tableaux de bord pour suivre l’activité de tel ou tel secteur de sa bibliothèque. Les 2 ont une communauté d’utilisateurs assez active, Lyon 2 s’investit et proposera bientôt un mode d’emploi en français pour Birt. JasperReports peut être installé sur un serveur pour une utilisation mutualisée, Progilone développe l’intégration d’une connexion à JasperServer pour la BULAC.
Koha, d’un petit centre de doc à un grand SCD : Retours d’expérience à l’école d’architecture de Nantes (CERMA), au SCD de Lyon 2 et à la BM de Nîmes
3 établissements assez différents, qui reflètent bien la diversité des possibilités de Koha.
– Du travail mais pas de regret pour le laboratoire CERMA : malgré de nombreux problèmes de reprise de données (export manuel, pertes de liens entre les notices), le gain en ergonomie et en fonctionnalités est appréciable. Un investissement humain important est nécessaire, et beaucoup d’espoirs sont placés dans la communauté.
– Expérience positive de la coopération avec Lyon 3 et St Etienne pour Lyon 2 : les coûts ont vraiment été partagés, les compétences mutualisées, et l’organisation de formations ouvertes à tous les partenaires a permis de constituer un socle de connaissances commun. L’articulation avec des prestataires différents et des versions différentes de Koha, la difficulté de récupérer les développements des partenaires et de les intégrer dans la version de Lyon 2 constituent les principaux désagréments rencontrés ; au final le SCD a un outil qu’il maîtrise et qui représente une économie sur le long terme.
– Inscription du choix de Koha dans la stratégie informatique globale de la ville à Nîmes, avec un engagement de la DSI pour mobiliser les moyens nécessaires pour mener le projet à bien. Implication moindre de la DSI depuis le déploiement (changement de priorités), forte attente de la mutualisation avec les autres établissements pour les développements futurs.
Quelques réflexions plus globales pour terminer ce trop long billet :
– La nécessité de disposer d’un informaticien a été relevée par tous les intervenants (ce qui ne fait que renforcer une impression déjà évoquée sur ce blog) ; plus largement, la question des ressources humaines à mettre a disposition pour ce type de projet est cruciale (autour de 3-4 ETP pour les projets présentés, et cela ne semble pas suffisant)
– La mutualisation des développements est capitale : KohaLa va relancer une enquête pour constituer l’annuaire des établissements et de leurs développements évoqué plus haut.
– La synchronisation des calendriers de la communauté / des prestataires / des établissements reste une difficulté, que la publication des développements et/ou des cahiers des charges des uns et des autres permettra peut-être de contourner, au moins partiellement.
* J’avais je l’avoue quelques appréhensions : allais-je tomber en pleine convention de barbus mangeurs de pizza ou me retrouver dans une réunion Tupperware de Bisounours idéalistes ?
[photos : National Media Museum, satane]
Dans Why Not Grow Coders from the inside of Libraries?, Bohyun Kim (Library Hat) s’interroge sur le manque de compétences techniques en interne dans les bibliothèques :
« Ca ne serait pas génial si chaque petite bibliothèque disposait d’un développeur en interne ? On utiliserait tous des logiciels open source, avec des fonctionnalités sur-mesure, correspondant exactement à nos projets et aux besoins de nos communautés d’utilisateurs. Les bibliothèques deviendraient alors des consommatrices de technologie réellement avisées, et plus de simples clientes à la merci de systèmes bancals. Et même, cela les re-positionnerait en tant que contributrices des technologies permettant au public d’accéder à l’information et aux ressources scientifiques. Je suis sûre qu’aucun bibliothécaire n’aurait d’objection à cette proposition. Mais en ces temps de restrictions budgétaires continues, conserver du personnel de bibliothèque est un défi en soi, alors engager un développeur…
Mais pourquoi devrions nous en passer par là ? Les bibliothécaires sont sans doute les professionnels les plus compétents techniquement après les informaticiens, les scientifiques, les ingénieurs et les personnels du marketing. Alors pourquoi n’y a-t-il pas plus de bibliothécaires qui codent ? Pourquoi n’assistons nous pas à un déferlement de bibliothécaires-développeurs ? Après tout, nous vivons à une période où le web est la plateforme sur laquelle se déroulent pratiquement toutes les activités humaines, et où les bibliothèques changent leurs noms pour des appellations comme « learning centers ». Développer ne me semble pas trop compliqué ni trop difficile à apprendre pour n’importe quel bibliothécaire, quel que soit son parcours. Les bibliothèques proposent aujourd’hui un large éventail de ressources et de services en ligne, et déploient et utilisent de nombreux outils, du SIGB au système de gestion électronique de documents, qu’elles pourraient certainement utiliser avec un grand profit des personnels capables de développer. »[…]
Pour elle, le problème vient en partie du fait que les compétences informatiques ne sont pas suffisamment valorisées au sein des établissements, qui ont tendance à recruter uniquement en dehors des bibliothèques. Alors que, ce type de compétences s’acquérant souvent en auto-formation, sur le temps personnel des agents, ce sont généralement des personnes motivées, qui pourraient apporter un vrai plus. A cela s’ajoute le fait que, quand elles existent, ces compétences sont utilisées de façon fragmentaire : rares sont les bibliothécaires qui développent à plein temps. En filigrane, il y a aussi la question de la formation : les vagues notions de html survolées dans la plupart des cursus initiaux ne font pas des codeurs aguerris…
Le sujet devient plus brûlant pour les bibliothèques qui utilisent des logiciels libres – il a été abordé lors d’une session la dernière conférence Code4lib consacrée à l’open source en bibliothèque :
« Les participants [à la conférence] habitués à travailler avec des logiciels libres étaient unanimes sur le fait que l’adoption du libre n’est pas bon marché. On croit souvent à tort qu’en adoptant des logiciels libres, les bibliothèques vont faire des économies. Mais, si c’était le cas, cela ne serait pas à court terme. Le libre nécessite d’avoir en interne du personnel technique formé, capable de bien comprendre le fonctionnement des logiciels pour tirer avantage de leur flexibilité au profit de leur établissement. Ce n’est pas du gratuit prêt à l’emploi qui démarre au quart de tour. Adopter les logiciels en open source donne certes aux bibliothèques une certaine liberté pour expérimenter et améliorer leurs services, et de fait les rend plus autonomes, mais les bénéfices ne viennent pas sans investissement. On peut alors se demander pourquoi les bibliothèques n’utiliseraient-elles pas, simplement, les services de sociétés tierces assurant le support de systèmes ou de logiciels libres. Mais sans la capacité à comprendre le code source, et les méthodes pour le modifier selon ses propres besoins, comment les bibliothèques pourraient-elles exploiter le potentiel du libre ? Et parvenir à des relations plus cordiales entre bibliothécaires et vendeurs ? »
[photos : rezponze]
Ce qu’il manque à (« mon ») Koha
Published 14/11/2010 Open source , SIGBs generally suck Leave a Comment
La version 3.2 de Koha vient d’être annoncée, Nicole Engard nous en liste les nouveautés. Je travaille pour ma part sur une version sans nom de Koha, quelquepart entre la 3.2 et la 3.4, qui intègre les développement faits pour Aix-Marseille, pour Lyon 3 et pour Nîmes. Ma brève expérience du sujet me laisse à penser que, si on veut vraiment travailler avec un logiciel libre, il faut en connaître les défauts aussi bien que les qualités. Donc j’ai fait une petite liste au père noël, non pas de défauts, mais juste de quelques unes des choses qui me semblent manquer dans le Koha actuel (enfin, uniquement pour les modules qui m’intéressent : OPAC, gestion des lecteurs, stats) et qui sont susceptibles d’intéresser d’autres utilisateurs (on ne sait jamais, si quelqu’un manque d’inspiration pour son cahier des charges) :
– une connexion à Electre : le webservice est développé côté Electre, mais pas côté Koha. Une fois ce développement en place, à nous les couvertures sans lien vers Amazon, les résumés et les tables des matières (moyennant un abonnement annuel, cela va sans dire)
– une fonction d’enrichissement des notices depuis plusieurs sources de données, paramétrable : à l’heure actuelle, si on active Amazon et Google Books en même temps, on voit bien que l’affichage n’est pas prévu pour ça. Et impossible de se connecter à une autre source que celles proposées. Or ce serait pas mal de pouvoir utiliser Electre pour la production française et une autre base pour la production internationale. Ou bien de se brancher sur les sommaires des revues qui disposent d’un fil RSS. Ou encore d’afficher des couvertures ou du contenu depuis une base de documents numérisés, etc.
– un module de gestion des tables de correspondances : si vous souhaitez utiliser les webservices d’Apogee et d’Harpège pour récupérer les données sur les lecteurs, préparez-vous à un gros travail sur les correspondances entre codes-étape, cycle de l’étape et j’en passe. Actuellement les modifications sont faites manuellement via un editeur pour geeks pas très convivial ; sachant qu’il y a pour une université moyenne entre 600 et 800 correspondances à faire, susceptibles de changer tous les ans, c’est un vrai besoin.
– un outil de gestion des listes : la possibilité de créer des dossiers et sous-dossiers, mais aussi un moyen de gérer la durée de vie de la liste. En cas d’utilisation « massive » de cette fonction – et c’est possible, ça fait partie des services « vendeurs », j’ai testé auprès des chargés de TD – il va être vite difficile de s’y retrouver…
– idem pour les statistiques : il faut pouvoir organiser les rapports statistiques SQL dans des dossiers et sous-dossiers, sous peine de perdre en lisibilité. Parce qu’il faut bien le reconnaître, beaucoup de données sur les notices passent par des requêtes SQL.
– une séparation plus claire de ce qui est public et de ce qui ne concerne que les professionnels : actuellement les listes, les formats d’export sont communs – ce qui peut rendre la présentation à l’OPAC quelque peu confuse pour l’utilisateur.
[photo : David Reeves]
Une fois n’est pas coutume, 2 mots sur ce qui se passe en ce moment dans mon SCD : au bout de 2 ans de préparation, la migration est terminée, nous avons quitté Loris et nous sommes en production sur le logiciel de gestion de bibliothèque open source Koha. Nous ne sommes pas seuls dans cette galère aventure : il s’agit d’un projet inter-universitaire, qui aboutit à un catalogue commun aux 3 universités d’Aix-Marseille. En chiffres, cela représente 705 000+ notices bibliographiques, 1 200 000+ exemplaires, 78 000+ lecteurs potentiels, dans un réseau de 53 bibliothèques (BU et bibliothèques associées).
Notre installation fonctionne avec le système de carte à puce des étudiants et personnels déjà à l’oeuvre dans les universités, nous interrogeons les bases de gestion des scolarités et des personnels (Apogée / Harpège) au moyen de webservices, ce qui nous permettra, à terme, d’avoir une information à jour en quasi-temps réel.
Qu’en dire de plus ? Tout n’est pas encore complètement calé, mais on peut déjà faire l’essentiel : faire des prêts/retours, récupérer les données qui redescendent du Sudoc, cataloguer… Bref rien que de très normal pour un SIGB. Quelques « innovations » intéressantes cependant – pour ce que je peux en juger, n’étant pas utilisatrice du système – du côté de l’OPAC : on peut récupérer des fils RSS sur ses requêtes, les notices ont des URLs pérennes et tout ça est compatible avec Zotero.
Pour ceux que ça intéresse (?), nous sommes sur une version quelque part entre la 3.2 et la 3.4, les décors sont de Roger Harth et les costumes de Donald Cardwell notre prestataire technique est BibLibre et l’assistance à maîtrise d’ouvrage est assurée par Doxulting.
[photo : Violaine Bavent]
Dans ce post du koha blog, Owen Leonard donne quelques conseils aux bibliothèques qui se lancent dans les SIGB libres en externalisant leur hébergement (il parle de Koha, mais à mon avis cela vaut pour les autre systèmes aussi) :
– Insistez pour avoir accès à votre base de données : vous êtes propriétaires de vos données (des lecteurs aux autorités), vous devez pouvoir y accéder à tout moment (pour faire des sauvegardes complémentaires par exemple, ou les tester sur un autre système).
– Ne vous limitez pas aux données : intéressez-vous à toutes les procédures mises en place par votre prestataire autour de la base de données (tout ce qui tourne autour des imports notamment, et des mises à jour : toutes ces opérations que l’on ne voit pas et qui sont pourtant primordiales pour le bon fonctionnement du système) – infos qu’il me semble indispensable d’avoir quelquepart, même quand on héberge son SIGB localement.
– Exigez que les développements que vous financez soient reversés à la communauté, histoire de ne pas vous retrouver coincé avec un système que seul votre prestataire maîtrise, ce qui rend les choses beaucoup plus compliquées le jour où vous décidez d’en changer. Si les développements vous sont spécifiques – ça peut arriver – là aussi, avoir une documentation complète à portée de clic sur ce qui a été fait est essentiel.
Travailler autrement
Published 05/02/2010 e-volution , Open source , Profession , Uncategorized 3 Comments
« Nous devons apprendre de nouveaux modes de travail si nous voulons maximiser la valeur de Koha dans nos organisations :
– Réfléchissez en fonction de ce que VOUS voulez, et pas de ce qui existe
– Apprenez les compétences de base de l’administration du système, et prenez la responsabilité du paramétrage de Koha pour qu’il soit conforme à ce que VOUS voulez
– Devenez à l’aise sur un outil de réseautage comme irc
– Apprenez à identifier, à décrire et à signaler les bugs, puis à tester les corrections
– Dites-vous « et si… ? » – et proposez des suggestions d’améliorations
– Puis rejoignez la conversation au sein de la communauté, pour vous assurer que les développeurs aient bien compris ce que vous vouliez, et réfléchissez au moyen de l’inclure dans la branche de développement principale
– Trouvez un développeur pour réaliser ce dont vous avez besoin si vous même n’êtes pas programmeur
– Apprenez à demander de l’aide et à en donner aux autres
– Partagez vos analyses et réflexions, vos trucs et astuces et vos supports internes (comme des tutoriels ou des vidéos)
– Devenez un adepte du travail collaboratif sur les wikis
– Financez des développements pour la communauté, sans les garder égoïstement pour vous-mêmes
– Et co-financez des développement conséquents avec d’autres organismes pour en partager les coûts, et que cela bénéficie à tout le monde ».
Ce sont les suggestions que Joann Ransom propose aux bibliothécaires qui se lancent dans l’aventure du libre avec Koha dans Users vs developpers : not in my universe ! Elle souligne la nécessité de sortir de la relation traditionnelle client-vendeur – pourtant si confortable – pour que les bibliothécaires arrivent à reprendre le contrôle de leur outil de travail. Il me semble qu’en France, on est loin de certains points de cette liste (passer à IRC après des décennies de messagerie, c’est pas gagné…), mais on se rapproche d’autres (le SUDOC a amené une certaine forme de travail collaboratif, au moins parmi les catalogueurs). Ce qui me paraît crucial ici, c’est le fait de savoir ce que nous voulons : finalement, avons-nous jamais réfléchi à ce que devrait être notre SIGB idéal ? Ne nous contentons-nous pas bien souvent de reproduire à l’identique les spécifications du système précédent dans nos cahiers des charges de réinformatisation ?
[photo : LuChOeDu]
L’open source c’est nous aussi
Published 01/02/2010 Marketing et promotion , Open source , Outils cools 3 Comments
Dans la série « le dire, c’est bien, le faire, c’est mieux« , et parce que j’ai pris l’habitude, depuis Biblioacid, de faire les choses par moi-même quand elles n’existent pas, j’ai décidé d’apporter une modeste contribution aux outils open source que j’utilise :
– J’ai commencé à traduire en français certaines pages de la documentation en ligne de Zotero : pour démarrer, je me suis attelée à « Comment rendre son site Zotero-compatible« , « Comment demander un nouveau style » et « Les standards et logiciels compatibles« . Si vous voulez vous y mettre, il faut vous créer un compte pour l’accès au wiki, qui est différent du compte que vous pouvez avoir par ailleurs sur le site de Zotero.
– J’ai également créé sur Zotero un groupe Koha, ouvert à tous, qui permet d’alimenter collaborativement une bibliographie sur ce logiciel.
Utiliser des logiciels libres, c’est déjà bien, mais il me semble qu’il n’est pas si difficile que ça d’aller un peu plus loin, de donner un petit coup de main discrètement, de temps en temps… Et vous, vous faites quoi pour l’open source ?
[photo : esc.ape]
Qui a dit que le monde du libre était un long fleuve tranquille ?
La nouvelle est tombée hier après midi : PTFS, une société de services pour les bibliothèques, rachète Liblime, la principale société qui assure le support de Koha pour de nombreuses bibliothèques américaines – et qui avait suscité le débat à l’automne 2009 en proposant à sa clientèle une version « privatisée » de Koha (LLEK).
Ce rachat, qui doit être finalisé courant janvier, amène à PTFS les compétences en terme de développement spécifiques à Koha de la douzaine d’employés de Liblime, ainsi que la centaine de contrats en cours (représentant près de 500 établissements).
PTFS édite Archivalware, une solution de bibliothèque électronique, de gestion électronique de documents, etc, et travaille déjà avec des briques Koha ou Evergreen – ça me fait un peu penser à la société Jouve. D’après le communiqué de presse, PTFS envisage de faire converger ses outils et ses compétences pour proposer aux bibliothèques, par exemple, une solution tout-en-un pour gérer aussi bien les collections physiques qu’électroniques (une extension ERM est évoquée).
PTFS a une branche en Europe, Une autre société, PTFS Europe, indépendante de PTFS (mais qui distribue ses produits) proposera aussi du support sur Koha, ce qui élargit potentiellement le nombre de prestataires sur ce marché. Parallèlement, Bywaters Solutions et Biblibre, les 2 autres sociétés spécialisées dans le logiciel libre pour les bibliothèques, annoncent qu’elles vont proposer conjointement du développement et du service autour de Koha à la clientèle américaine.
Ces nouvelles me paraissent de bon augure pour le secteur du libre.
Ca paraît tellement énorme, c’est tellement pas dans notre culture, et pourtant : Sirsi-Dynix, multinationale spécialisée dans les solutions pour les bibliothèques (qui commercialise en France le SIGB Horizon), a diffusé auprès de certains de ses clients américains ce document « d’information » sur les SIGB open source, qui n’est rien moins que de la propagande anti-open source de base [il présente du reste un certain nombre de caractéristiques du FUD (Fear, uncertainty and Doubt), une technique de désinformation utilisée en marketing et en politique]. Ce document a été rendu public sur le site Wikileaks, qui est « une version non censurable de Wikipédia, qui vise à divulguer et à analyser des documents, dont la source ne puisse pas être identifiable et pour une diffusion à grande échelle. Elle associe la protection et l’anonymat que permettent les toutes dernières technologies de cryptographie, à la transparence et à la simplicité d’une interface wiki. »
Allez, juste un petit extrait qui m’a plu :
« Les systèmes propriétaires ont plus de fonctionnalités. Point. Les systèmes propriétaires sont plus conviviaux. Sirsi-Dynix développe son SIGB depuis plus de 30 ans. Il dispose d’une gamme de fonctionnalités de premier ordre. Il est important de noter que Sirsi-Dynix travaille pour 2 principaux groupes d’utilisateurs – les bibliothécaires qui traitent les ressources de la bibliothèque pour les acquisitions, le catalogage, le prêt, le PEB etc. Et les utilisateurs finaux qui utilisent les fonctions de l’OPAC comme le prêt autonome. Les développeurs de solutions open source passent la plus grande partie de leur temps à faire en sorte que les opérations internes de développement se passent correctement, alors que tout cela est au point chez nous depuis 30 ans. »
Les systèmes propriétaires ont plus de fonctionnalités. Point. Les systèmes propriétaires sont plus conviviaux.
Les systèmes propriétaires ont plus de fonctionnalités. Point. Les systèmes propriétaires sont plus conviviaux.
Les systèmes propriétaires ont plus de fonctionnalités. Point. Les systèmes propriétaires sont plus conviviaux.
Peut-être si on se le récite comme un mantra on finira par oublier toutes les fois où l’on a regretté que nos SIGB n’aient pas telle ou telle fonctionnalité (allez, une au hasard : des flux rss ?), ou ne soient pas plus orientés-utilisateurs ?
Le reste est du même tonneau, et montre, à mon sens, que l’open source est en train de gagner du terrain sur ce micro-marché qu’est celui des logiciels de bibliothèques : pourquoi ce genre de réaction défensive si l’open source ne représentait pas une sérieuse concurrence ?
[photo : 4PIZON]
Marlène's corner 