Koha, logiciel libre ET communautaire. La stratégie de BibLibre

Ce billet est particulièrement long, mais sa longueur est corrélée à son importance !
Après une introduction dans laquelle je rappelle la particularité communautaire de Koha, je rappelle le « workflow » pour intégrer des nouveaux développements, puis précise la méthode de travail que BibLibre a décidé d’adopter vis à vis de ses clients.

La particularité de Koha
Koha est né il y a 11 ans en Nouvelle Zélande, et a fait ses premiers pas en France en 2002, par l’intermédiaire de votre serviteur. L’originalité depuis le début de ce projet, c’est qu’il est porté par une communauté internationale, et pas par une société qui en assure l’essentiel du développement. A ce jour, presque 150 personnes différentes ont participé, un peu ou beaucoup à son développement !

Je crois que les bibliothèques choisissent Koha pour deux raisons :

• la première raison est fonctionnelle : c’est un excellent outil, fonctionnellement complet, qu’utilisent plusieurs universités et de grandes bibliothèques de lecture publique.
• la seconde est inhérente à son coté communautaire : Koha est réellement un outil qui ne « capture » pas la bibliothèque : ils ont le choix du prestataire, il y en a plusieurs uniquement en France, et de nombreux de par le monde.

J’ai passé, avant de créer BibLibre, cinq années comme consultant, à intervenir dans diverses conférences et écoles à expliquer que la liberté que donne une licence ne vaut que si l’on peut s’en servir. Et le meilleur moyen de s’en servir, c’est de ne pas dépendre d’un prestataire.

La création de BibLibre n’a rien changé à cette conviction.

Le développement de nouvelles fonctionnalités

Nos clients sont parfois amenés à nous demander de développer de nouvelles fonctionnalités : Koha est déjà très complet, mais il peut toujours être amélioré. L’une des principales difficultés auxquelles nous sommes confrontés tient au calendrier des marchés publics et de son « incompatibilité » avec les règles d’une communauté : nous signons un contrat avec un client, le développement doit être fait dans un délai fixé dans le contrat. Ensuite, il est proposé à la communauté Koha pour inclusion dans la version officielle.

C’est cette dernière phase qui est la plus délicate : les impératifs temporels sont différents, mais les choix fonctionnels et/ou techniques peuvent également l’être.

Nous constatons qu’il est maintenant essentiel pour nous d’être très clairs sur le circuit :

1. Une bibliothèque nous passe commande d’un développement, via un marché. Dans notre réponse au marché, nous essayons de comprendre la demande fonctionnelle de la bibliothèque, mais également d’élargir à tous les utilisateurs de Koha. Il va de notre responsabilité de prévoir un développement qui puisse convenir à tous. Cela peut entraîner un surcoût, du moins en apparence. Par exemple, nous prévoyons toujours de développer une fonctionnalité qui soit « MARC agnostique ». Afficher tel champ dans tel écran, ca peut sembler trivial. Mais pouvoir définir où est ledit champ en MARC21, UNIMARC, NORMARC ou autre, ça l’est nettement moins. Notre parfaite connaissance de Koha est un atout. Nous devons également penser aux utilisateurs existants et à la mise à jour de leur version.
2. lorsque le contrat/marché est signé, nous faisons deux choses :
   1. nous rédigeons les spécifications avec la bibliothèque. La bibliothèque est notre client, nous devons répondre à son besoin avant tout.
   2. nous transmettons ces spécifications [en anglais] sous forme de RFC à la communauté Koha. Cela permet parfois d’avoir des retours qui peuvent enrichir l’idée. C’est, à minima, un moyen d’annoncer ce que nous allons faire.
3. lorsque le développement est terminé, la bibliothèque le valide, nous le déployons en production. Ces développements sont mis dans une « branche de développement » spécifique au client (git est l’outil qui nous sert à déposer et suivre le code source)
4. en parallèle du déploiement en production, la fonctionnalité développée pour la bibliothèque, est portée sur la « version communautaire ». Si des conflits se produisent, ce qui est fréquent : la version communautaire évolue rapidement !, nous les résolvons (ce qui peut être complexe). Ensuite, le développement soumis à la communauté et nous entrons dans le « workflow communautaire ».

Le calendrier communautaire n’est pas le celendrier de notre client.
Il arrive dans certains cas qu’un développement en production chez un client soit intégré au bout d’une longue période.
En 2009 et 2010, nous avons choisi d’avoir une branche « BibLibre », qui intègre immédiatement tous les développements validés par nos client. Ainsi tous nos clients profitaient de notre travail. Nous constatons aujourd’hui que certains développements, faits pour l’université de Lyon 3 autour des règles de circulation, ne sont toujours pas intégrées à la version officielle de Koha. Ces développements, nos clients en bénéficient déjà. Mais si nous leur proposions de passer en version 3.4, publiée récemment, ils perdraient ces fonctionnalités.
D’un autre coté, ils en gagneraient d’autres (un éditeur wisiwyg -au lieu de taper du HTML- pour les news pour n’en citer qu’un).

Ce problème est crucial.
Au point qu’il était devenu nécessaire, pour faire cohabiter les nécessités du travail en communauté et nos devoirs contractuels vis à vis de nos clients, de trouver et d’adopter une méthode de travail adéquate.

Nous en avons donc tiré la conclusion que le choix de départ (ie : faire profiter immédiatement de nos développements à nos clients) risquait de « capturer » nos clients dans une « fourche » de Koha que nous ne voulons pas faire.

Notre méthode de travail

Notre organisation est donc maintenant la suivante :

• nous déployons nos nouveaux clients uniquement avec la version officielle communautaire.
• si des développements sont financés, il sont faits sur une branche spécifique, et déployés uniquement chez le client. Ledit client n’a donc plus une version communautaire (momentanément).
• lorsqu’une nouvelle version communautaire sort nous faisons, avec les bibliothèques concernées, le point sur les développements de leur branche spécifique vis à vis de leur intégration dans la version officielle.
  • S’il n’y a plus de différence, nous « basculons » sur une version communautaire
  • S’il reste des différences, il y a trois possibilités :
    • nous pouvons porter les fonctionnalités spécifiques sur la nouvelle version, nous déployons chez le client cette version.
      Cela supposera dans la plupart des cas un contrat de maintenance spécifique : cette opération de portage peut être très complexe et chronophage
    • nous ne pouvons pas porter les développements et la bibliothèque souhaite conserver ses fonctionnalités spécifiques : nous ne pouvons pas mettre à jour, la version n’évoluera plus, sauf actions de maintenance, que nous assurerons selon le contrat de maintenance
    • nous ne pouvons pas porter ces développements et la bibliothèque choisit de renoncer au développement spécifique, ou bien un nouveau développement fonctionnellement équivalent a été fait par ailleurs : nous « basculons » sur une version communautaire

Le lecteur attentif pourra se poser trois questions :

• Oula, je suis en « 3.2/BibLibre », je ne pourrais plus jamais rebasculer en version communautaire ? La réponse est : Si. Nous travaillons avec chris pour intégrer dans Koha 3.6 les développements touchant à la circulation faits pour Lyon 3, et ce sont les derniers développements notables qui sont dans la version 3.2/BibLibre et pas dans la version officielle. Nous prévoyons donc de basculer tous nos clients en version 3.6.
• la bibliothèque X a financé une fonctionnalité qui est très intéressante, et dont j’ai absolument besoin immédiatement. Je ne peux pas « l’avoir » ? La réponse courte est : non. La réponse complète est : nous vous suggérons d’attendre que ce développement soit dans la version officielle, c’est votre intérêt à long terme. Mais en cas de nécessité, nous vous proposerons une prestation particulière, avec, donc, un coût financier, pour intégrer ledit développement dans une « branche client » spécifique, qui ne sera déployée que chez vous. Vous devenez alors, au moins pour un temps un client « version spécifique » et non « version communautaire », avec les particularités expliquées ci-dessus.
• heu… ca veut dire que c’est pas OpenSource tant que ce n’est pas dans la version communautaire ? La réponse est : si. Tout ce que nous développons est disponible sous licence GNU/GPL, sur notre dépôt git.biblibre.com. Il suffit de se positionner sur la branche du client pour récupérer tous ses développements.

Conclusion
J’espère que ce billet aura permis d’éclairer votre lanterne. Notre investissement dans le développement de la « Communauté Koha » reste plein, entier, et irréversible. A la fois pour que vous soyiez définitivement sûrs de la liberté que vous apporte Koha, mais aussi parce que nous sommes convaincus que « tout seul on va plus vite, ensemble, on va plus loin ». Et nous préférons aller loin !

Si vous êtes client chez nous et que vous avez une quelconque question par rapport à ce billet, n’hésitez pas à vous rapprocher de moi, de Philippe Chabanon, ou de votre chef de projet.