L’histoire des logiciels libres et open source est marquée par une opposition constante entre économie de don et économie marchande

L’histoire des logiciels libres et open source est marquée par une opposition constante entre économie de don et économie marchande.

Organiser le don dans les communautés métier : Comment la « réciprocité », modèle économique des communautés des logiciels libres et open source, s’organise-t-elle dans les communautés de logiciels de bibliothéconomie.

Plan:
Introduction : enjeux des SIGB libres sur le marché français
La pureté du modèle communautaire garantit-elle la pérennité du logiciel ?
1. La réciprocité du don comme clé de la communauté
1.1 Définitions de la communauté
1.2 Les formes du don : don altruiste, troc, reversement
1.3 Le don dans les communautés « métier »
2 Les possibles critères de pérennité des logiciels libres et open source
2.1 Trois Critères de maturité
2.2 Trois Critères de composition
2.3 Trois critères liés à la culture du don
3 L’avis des acteurs des SIGB libres et open source
3.1 Méthode et contexte de l’enquête
3.3 Les Trois Critères de maturité
3.3 Les trois Critères de composition
3.4 Les trois critères liés à la culture du don
Discussion et conclusion

Introduction : enjeux des SIGB libres sur le marché français
Selon l’étude Redhat, publiée fin avril 2009 et reposant sur l’analyse de l’investissement des entreprises commerciales, les politiques publiques et l’action des communautés et du secteur de l’enseignement, la France est la première nation pour l’activité open source devant l’Espagne, l’Allemagne, l’Australie, la Finlande et le Royaume Uni, les Etats-Unis se classant en 9ème position. Pourtant, en 2008, le logiciel libre ou open source représente une faible part de l’économie logicielle française avec 3,6% (1105 millions d’euros) des dépenses en logiciel et service mais sa croissance est forte (32,7% par an) ce qui lui permettrait d’atteindre 10% des dépenses en 2012 .

Dans cette activité, les logiciels de bibliothéconomie (SIGB ), représentent une niche étonnante : un projet d’équipement logiciel sur 46 en 2007 concernait un logiciel Libre ou open source, ce rapport est passé à un sur 9 en 2008 , ce qui montre un intérêt exceptionnel des professionnels de la gestion de l’information pour cette économie particulière. Les hypothèses de Pintat (2003), Morgan (2004), Morin (2004), Rogel (2004), semblent confirmées : la culture des professionnels de l’information rencontre celle des communautés libres, mais les communautés prennent des formes très diverses selon les produits considérés, l’ampleur et l’ancienneté de la communauté, sa centralisation, l’investissement des société de développement de logiciels et des entreprises utilisatrices, le ratio entre les membres prescripteurs et de membres développeurs.

LA PURETE DU MODELE COMMUNAUTAIRE GARANTIT-ELLE LA PERENNITE DU LOGICIEL ?
Si les logiciels documentaires sont une activité de niche du secteur informatique, ils représentent néanmoins des sommes non négligeables pour les entreprises et les organismes publics. Il est donc important de mesurer la pérennité de ces logiciels et leur capacité à évoluer pour s’adapter aux besoins des professionnels. Cependant, il n’existe actuellement pas d’outils méthodologiques ni d’indicateurs permettant de le faire.

On a coutume de désigner l’entité de production d’un logiciel open source par le vocable « communauté » et il est commun de dire que la pérennité et la qualité d’un logiciel OS repose sur la solidité et l’excellence de sa communauté. Les méthodes d’évaluation des projets libres intègrent dans leurs grilles des critères d’évaluation des communautés de développeurs et attribuent de meilleures notes aux projets dont les contributeurs sont nombreux et dont l’activité est à la fois, importante et visible sur les forums et listes de diffusion. A l’inverse le « fork », c'est-à-dire la scission d’une communauté en deux groupes distincts faisant évoluer le logiciel sous deux formes incompatibles, est un événement défavorable qui augmente le risque-utilisateur.

La conclusion de « l’Etude comparative des principaux SIGB libres » publiées par Tristan Müller (Muller, 2008, 24) postule qu’une communauté démontre d’autant plus de potentiel de vitalité et de pérennité qu’elle présente une communauté nombreuse et internationale, que plusieurs sociétés et consultants commerciaux offrent un support mondial au produit et que son leadership se renouvelle. A l’inverse un « modèle d’affaire entrepreneurial » et « l’indisponibilité d’une solide infrastructure de collaboration publique et libre, gage d’adoption et de transparence », sont considérés dans cette étude comme des critères défavorables pour la pérennité et la vitalité.

Ces approches nous semblent présenter le même biais : considérer apriori et sans démonstration que la pureté du modèle de production collaboratif garantit l’efficacité du processus de développement et du modèle économique. Or si le développement collaboratif bénévole en équipes internationales distantes est un modèle novateur, passionnant et prometteur, la posture manichéenne consistant à refuser d’en considérer les fragilités à côté des avantages est dangereuse notamment lorsqu’il s’agit de produire des évaluations destinées aux usagers. Un excès de louanges ne peut que susciter à terme chez les usagers une déception et une méfiance à l’égard du modèle.

Nous nous proposons donc de discuter les critères de pérennité et de vitalité des échanges au sein des communautés de SIGB. Dans un premier temps nous nous intéresserons à la littérature scientifique internationale afin de cerner la nature des échanges (dons, trocs, reversements) effectués au sein des communautés. Nous en dégagerons neuf critères susceptibles d’influer sur l’intensité et la durabilité des échanges. Enfin nous discuterons ces critères à la lumière d’entretiens libres menés en 2009 auprès de quelques acteurs jouant un rôle de premier plan dans l’écologie du SIGB libre en France.

1. La réciprocité du don comme clé de la communauté
1.1 DEFINITIONS DE LA COMMUNAUTE
Le terme « communauté » se définit de façons diverses. Selon le contexte de son emploi il s’agit soit d’un groupe de personnes habitant le même secteur (définition territoriale), soit « un collectif de personnes possédant et jouissant de façon indivise d'un patrimoine en commun » (droit français), soit un « groupe de populations qui ont des modes de vie similaires » (écologie) ou « qui respectent les mêmes règles de vie » (communauté religieuse) ou « partagent un centre d’intérêt commun » (community of practice de Lave & Wenger 1991). Les membres des communautés ont des interactions continues, constituant un réseau de relations, mais, avec l’arrivée des réseaux, s’est superposée à la notion de proximité et d’interaction territoriale, celle d’une interaction médiée (communauté virtuelle). Selon Maurice Godelier (2009) la communauté se distingue du clan ou de la tribu en ce sens qu’elle n’implique pas une relation de parenté entre ses membres. Elle n’est pas non plus une société laquelle se définit par l’existence de rapports politico-religieux régissant des relations d’autorité et de pouvoir.

Les sciences humaines se sont intéressées à ce qui constitue le ciment des communautés open source. Le travail de Marie Coris (2007) nous intéresse particulièrement puisque, constatant une absence de définition du terme communauté dans le contexte logiciel, il propose un retour aux sources de l’anthropologie maussienne en posant la communauté de développeurs libres comme un réseau social du don c’est à dire soudé par un acte reproduit et répété par ses membres dans un système d’attentes réciproques. La pérennité de la communauté suppose donc la réciprocité du don mais, alors que dans l’acte marchand le don s’exerce au profit d’un individu identifié (le client), et le la rémunération garantie par le contrat, achève systématiquement le processus de don-contre-don, le don des communautés libres s’effectuerait au profit d’inconnus sans certitude de retour ni garantie d’un contre don d’un poids équivalent. La confiance dans la volonté et la capacité des autres membres inconnus de poursuivre l’échange est donc un élément central. Coris rejoint sur ce point Magnus Bergquist et Jan Ljungberg (2001) dans leur analyse de la culture du don (gift culture) non comme un processus économique archaïque, mais comme un jeu sophistiqué de relations de pouvoir, d’acceptations et d’exclusions aboutissant à une hiérarchie au sein de laquelle les « newbies » doivent faire preuve d’allégeances aux règles communautaires et franchir les étapes de validation ou de refus de leurs contributions par les « core developpers » constituant un processus informel d’apprentissage.

Or la notion de communauté n’apparaît pas dans les critères de définition des logiciels libres ni dans ceux des logiciels open source , qui se concentrent sur les modalités de distribution du logiciel et non sur les modalités de leur fabrication. Le terme communauté apparaît assez peu dans « the Cathedral and the Bazaar », texte fondateur des organisations open-source. Eric Steven Raymond y décrit un leader, coordinateur « charismatique » et tout puissant, distribuant des tâches de debuggage à des « utilisateurs-bidouilleurs » : « Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.” (Raymond, 1998) . Le co-developpement y apparaît comme un mode de management, une façon de motiver les béta-testeurs, mais sans que le pouvoir de décision n’échappe au leader historique.

On peut donc se demander si les outils conceptuels des sciences humaines n’ont pas tendance à renforcer le caractère paritaire et collaboratif des projets open source en négligeant la réalité, conforme au principe du libre, des nombreux logiciels actifs produits par un unique développeur (Krishnamurthy, 2002) ou par une société éditrice.

1.2 LES FORMES DU DON : DON ALTRUISTE, TROC, REVERSEMENT
L’échange n’est pas non plus inscrit dans la définition de base de ce type de logiciels. La libre distribution d’un code ouvert n’implique pas la réciprocité. Il s’agit bien plutôt d’un don aveugle puisque le donateur ne connaît pas tous les destinataires, lesquels de leur côté ne reçoivent pas le don mais viennent le prendre à leur guise. Le don peut être altruiste, c'est-à-dire totalement désintéressé ou motivé par l’utopie Hacker de la construction d’une société affranchie des droits de propriété et des relations marchandes (Himanen, 2001) ou plus simplement par le sentiment d’un devoir à l’égard des autres contributeurs.

Pour que le processus de développement s’inscrive dans la durée il faut qu’il comporte une motivation pour le développeur. Karim R. Lakhani et Robert G. Wolf (2005) identifient un ensemble de motivations combinées : stimulation intellectuelle de la création de code ou plaisir du travail avec les membres de la communauté (lorsqu’elle existe), satisfaction d’améliorer ses compétences grâce au « peer review », émulation entre développeurs. Cependant au-delà de ces motivations intrinsèques un certain nombre de bénéfices peuvent être attendus : rétribution immédiate (certains développeurs sont délégués par leur société pour participer à des projets open source) ou différée (le développeur reçoit en échange du code fournit une considération et une réputation qui accroissent sa valeur sur le marché du travail) (Coris, 2007). Lorsque l’auteur du développement open source est une société éditrice, le don peut entrer dans une stratégie marketing visant à promouvoir d’autres produits ou des services (Scopsi, 2008 (a)).

Le troc est une forme particulière de rétribution. Le reversement (revealing )aboutissant à l’échange de code apparait comme le bénéfice le plus caractéristique de cette activité. Chaque contributeur reçoit en retour un logiciel amélioré ou des modules additifs qui constituent son retour sur investissement et garantit une évolution sans limite du produit puisque chaque reversement entraîne l’obligation morale d’autres reversements (Bergquist et Ljungberg, 2001).

Mais ce processus vertueux ne va pas de soi et pour fonctionner nécessite que plusieurs mécanismes soient réunis :

- des compétences en nombre suffisant ou une attractivité suffisante pour attirer des sociétés de services informatiques et construire une écologie favorable ;
- des paramètres techniques : le logiciel doit techniquement présenter une structure modulaire pouvant accueillir une fabrication « émiettée » (Demaziere, Horn, Jullien, 2005) ;
- un dispositif de confiance (Quéré, 2005) : les membres doivent avoir confiance dans la capacité et la volonté des autres membres de conduire le logiciel à sa maturité, dans la capacité du « core » de maintenir un haut niveau de qualité du code, et dans la volonté de TOUS de ne pas rompre le projet par un fork,
- une gouvernance et des outils de coordination en ligne.

1.3 LE DON DANS LES COMMUNAUTES « METIER »
Un dernier phénomène, majeur pour l’analyse des logiciels open source du monde des bibliothèques, vient compliquer ce processus : celui, qualifié par Raymond (1998) de « last virgin territory », de l’émergence de logiciels destinés à de non développeurs.
Parmi ceux-ci les logiciels « métier » dont la couverture fonctionnelle épouse étroitement les pratiques d’une profession posent des questions particulières. Ces produits sont destinés à être manipulés par des utilisateurs non développeurs et les informaticiens d’entreprise ne les maîtrisent pas toujours. La production de ces logiciels nécessite l’association de deux compétences: celles du développeur et celles de l’expert métier, ici le bibliothécaire. Ces deux compétences sont porteuses de cultures et d’attentes diverses (Jullien et Zimmermann, 2005).
Dans ce contexte la réciprocité du don est rendue plus complexe par la différence des compétences : lorsqu’il s’exerce, l’échange de code, nécessite un acteur supplémentaire, un « tiers développeur », qui prenne en charge la production du code pour le bibliothécaire dans le cadre d’un classique contrat de prestation de service, introduisant des relations marchandes au sein de l’économie open source. Mais le plus souvent la réciprocité prend des formes indirectes et l’usager contribue en « versant » les informations qu’il détient : recueil des besoins, normes et formats professionnels à respecter, contraintes organisationnelles à prendre en compte pour l’ergonomie, ou bien en prenant en charge les tests fonctionnels, la documentation utilisateur, l’assistance des « newbies ». Enfin la communauté considère qu’un nombre important d’usagers constitue en soi un bénéfice pour le projet et une garantie de pérennité. On est donc bien loin d’un troc, puisque l’équité des contributions n’est pas évaluable. Michel Gensollen (2004,18) considère que la gestion des logiciels open source s’apparente à celle « d’un bien non rival » dans la mesure où la consommation du bien virtuel par les uns ne prive pas les autres puisque les fichiers informatiques sont duplicables à l’infini. Une utilisation opportuniste du logiciel sans contribution en contre partie n’a pas d’effets négatifs sur les autres utilisateurs (à part un manque à gagner en termes de contribution).

Ces communautés « métiers » hybrides sont – elles porteuses de fragilités nouvelles et compromettent – elles à terme le principe d’échange ? Et quels éléments contribuent à renforcer ces échanges ? C’est ce que nous avons étudié en interrogeant divers acteurs du logiciel libre destiné aux bibliothèques.

2 Les possibles critères de pérennité des logiciels libres et open source
A la lumière des études scientifiques que nous avons brièvement exposées neuf points ont été sélectionnés comme de possibles indices de pérennité :
2.1 TROIS CRITERES DE MATURITE
A/ l’ancienneté de la communauté
L’ancienneté d’une communauté est rassurante car elle suppose des liens solides entre contributeurs et un logiciel mature, les communautés de plus de trois ans sont donc mieux notées par la méthode QSOS (cf note en page 2). Cependant un logiciel plus ancien et mature nécessitant moins de contribution peut conduire à une désaffection des contributeurs. Il deviendra alors difficile de maintenir une activité et une compétence sur le produit.
B/ la taille de la communauté.

La méthode QSOS crédite d’une meilleure note les communautés comportant plus de sept développeurs et une équipe de direction des développements de plus de 5 personnes. Pourtant Krishnamurthy (2002) constate que l’immense majorité des programmes Open Source matures de Sourceforge est développée par un petit nombre d’individus et que la majorité des cent projets les plus actifs de cette plateforme comporte un seul acteur. Le faible nombre de développeurs n’est donc peut être pas un handicap tandis qu’un nombre important de développeurs peut entraîner des difficultés d’organisation et d’homogénéisation des développements, voire des divergences de vues conduisant au fork.

C/ l’expérience surmontée d’un fork
Une communauté qui a connu un fork et a réussi à y survivre fait la preuve de sa plasticité. Elle montre ainsi sa capacité à maintenir sa ligne de développement en refusant des reversements non conformes ou sa capacité à reformer une communauté cohérente après avoir subi une scission. Ce contexte est donc mieux noté dans QSOS qu’une communauté n’ayant subi aucune péripétie.

2.2 TROIS CRITERES DE COMPOSITION
D/ Les caractéristiques professionnelles des membres de la communauté
Deux situations modifient le sens et la condition de la relation de don : la première est la communauté « métier » mêlant des membres développeurs et des usagers jouant le rôle d’experts métier non développeurs dont les centres d’intérêt peuvent diverger. L’autre est l’hybridation des communautés accueillant des membres appartenant à des sociétés tirant leur subsistance de prestations de service liées au produit. Même si ces derniers respectent à la lettre le principe de reversement gratuit leur participation peut être assimilée à une activité marchande indirecte puisque la notoriété et le réseau de relations tissé au sein de la communauté renforce le portefeuille de clients de l’activité commerciale. Cette situation est classique de l’économie Open Source et est certainement un facteur de sa pérennité.

E/ La hiérarchie interne et la répartition des rôles selon les profils de membres
Dans le cas des communautés métier il est intéressant de noter la teneur des contributions des utilisateurs usagers, leur participation et leur influence sur la définition et l’administration des versions. Rappelons que selon Jullien et Zimmermann (2005), développeurs et utilisateurs métier du libre n’ayant pas les mêmes motivations et ne poursuivant pas exactement les mêmes objectifs, des filtres ont tendance à se mettre en place entre les deux profils : listes de diffusions, outils de communication, langues et jargons différents.

F/ Gouvernance du don
La mise en place de structures organisationnelles et de plateforme de formalisation des échanges favorisent-elles l’activité de reversement ? Les procédures d’assurance qualité et les outils de gestion de bug sont favorablement notés dans QSOS, cependant, Krishnamurty souligne que parmi les cents projets les plus actifs de Sourceforge, trente trois n’échangent aucun message et que la grande majorité en échange très peu.

2.3 TROIS CRITERES LIES A LA CULTURE DU DON
G/ Maturité de la culture du don chez les membres usagers
La culture hacker est bien connue par les professionnels de l’informatique, mais peut être moins assumée par les « experts métier ». Une tendance à la reproduction de la relation « client/fournisseur » peut être observée dans les communautés métier (Scopsi, 2008(b)). Des outils d’éducation à la culture et aux procédures du don peuvent être mis en place.

H/ L’ « épaisseur » de la communauté,
Certaines caractéristiques des communautés rendent plus difficiles l’accès au don. Les communautés très centrées autour d’un « dictateur bienveillant » ou « verrouillées » par une société éditrice, découragent, parfois volontairement, les contributions de nouveaux arrivants. Des communautés bénévoles mais très électives ou reposant sur un noyau d’individus très complices peuvent aussi être décourageantes ; enfin, les outils de communication des communautés internationales peut être un frein à la participation à la vie du projet.

I/ Les outils d’émulation
Comment le don est-il explicitement valorisé au sein des communautés ? Les contributions sont-elles comptabilisées? Les membres sont-ils labellisés en fonction de leurs contributions ? Quelle image les membres ont-ils de l’action de reverser ?

La méthode d’enquête ne permet pas d’aborder ici les caractéristiques techniques du produit qui ne devraient pas être négligées car elles pèsent sur la réalité de la production collaborative. Une construction modulaire, permettant l’association de briques logicielles sous forme de plug in favorise le développement partagé. Mais ces structures se rencontrent dans les logiciels les plus récents.

3 L’avis des acteurs des SIGB libres et open source
3.1 METHODE ET CONTEXTE DE L’ENQUETE
Une enquête initiale, réalisée en 2008 sur le mode qualitatif auprès de dix utilisateurs de SIGB libre a montré que la participation active à une communauté de logiciel libre n’allait pas de soi. Cette impression fut confortée par les participants à des séminaires de formation au SIGB libre, déjà testeurs de ces produits qui, tout en soulignant l’intérêt de participer à l’invention d’un nouveau modèle de projet, déclaraient que des formations à la gestion et à la participation à la communauté leur serait bien utile.

Notre projet initial était de questionner des acteurs de deux CMS libres et de deux SIGB libres, afin d’ouvrir la problématique aux techniques documentaires. Mais en avançant dans la problématique il s’est avéré que le marché des CMS et celui des SIGB diffèrent profondément le premier concernant un public plus large et des fonctionnalités moins liées aux pratiques d’une communauté professionnelle que le second. Le CMS ne peut être considéré comme un logiciel « métier », or la rencontre d’une communauté professionnelle avec une communauté libre nous semble particulièrement intéressante dans les SIGB. Le périmètre de l’étude a donc été réduit aux communautés PMB et Koha, principaux SIGB libres implantés en France.
D’autre part, au début de l’enquête, en septembre 2009, un événement s’est produit dans le monde des SIGB libres : le « fork » opéré par la société américaine Liblime, l’un des membres historiques de la communauté Koha pourtant présentée comme un modèle de gouvernance (notamment dans l’étude Müller). Ce fork, bien qu’il ne compromette pas le devenir du produit a été vécu avec émotion par la communauté internationale de Koha et a occasionné des prises de position sur le web qui révèlent beaucoup de l’état d’esprit des utilisateurs à l’égard des relations d’échange et de la culture du don au sein de leur communauté. Il aurait été dommage de ne laisser qu’une portion congrue à ces témoignages.

Les données ont été collectées de septembre à novembre 2009

par entretiens libres auprès de :

- Ludovic Méchin, Directeur général de Doxulting société de conseil indépendante intervenant en assistance à maîtrise d’ouvrage auprès des bibliothèques et médiathèques.
- Nicolas Morin, conservateur des bibliothèques, membre de la société Biblibre fortement impliquée dans la communauté Koha.
- Pascale Nalon, Bibliothécaire, présidente de l’association Kohala réunissant les utilisateurs de Koha.
- Eric Robert Directeur du développement de PMB services, société éditrice du SIGB libre PMB.

Dans les blogs et outils ouverts sur le web de la communauté Koha :

- le blog de BibLibre http://www.biblibre.com/blog.
- « Marlène’s Corner » le blog consacré au web 2.0 de Marlène Delhaye, bibliothécaire et co-éditrice de Biblioacid. http://marlenescorner.blogspirit.com/.
- les archives de la liste Koha et notamment les réactions au message de Joshua Ferraro (CEO de Liblime) du 16 septembre 2009. http://lists.katipo.co.nz/mailman/listinfo/koha.
- « Library matters » le blog de Joann Ransom “Deputy Head of Libraries” du Horowhenua Library Trust , initiateur néo zélandais du projet Koha, notamment l’article du 14 septembre 2009 consacré au fork Koha http://library-matters.blogspot.com/2009/09/liblime-forks-koha.html.
- « Librarians Matter » blog de Kathryn GreenHill bibliothécaire australienne, et notamment son article du 19 septembre 2009 consacré au fork koha. http://librariansmatter.com/blog/2009/09/19/the-koha-fork-and-being-the-... .- Les archives publiques du canal IRC de la communauté internationale Koha http://stats.workbuffer.org/irclog/koha/.

Enfin, il est ponctuellement fait référence sous le nom « enquête 2008 » à une série d’entretiens réalisés en 2008 auprès d’utilisateurs de SIGB libres à laquelle nous avons déjà fait allusion. Six utilisateurs de PMB y avaient anonymement participé.

Notre analyse relève d’une approche clairement ethnométhodologique s’intéressant non tant aux positions officielles et à l’exactitude des faits énoncés, qu’aux opinions et croyances exprimées comme témoins de la représentation que leurs auteurs se font de leur communauté et de leur place dans cette structure sociale. A ce titre, les propos relevés sont à considérer comme de propos individuels et non comme des prises de position officielles.

3.3 LES TROIS CRITERES DE MATURITE
A/ l’ancienneté de la communauté
Koha (né en 1999) et PMB (2002) ont des âges comparables et se sont implémentés en France à peu près à la même période (approximativement entre 2002 et 2004). Leurs choix d’organisation sont radicalement différents. L’évolution de PMB est financée selon la présentation de son site web « par PMB Services sur ses fonds propres ou majoritairement par ses clients ». La société éditrice PMB services considère que « c’est grâce à ce modèle entrepreneurial que le logiciel a acquis rapidement une couverture fonctionnelle et une stabilité reconnues par les utilisateurs » PMB s’est rapidement implanté dans un très grand nombre de petites bibliothèques communales aux besoins homogènes permettant des projets « bien huilés, faciles et rapides, avec un coût humain plutôt faible » (ER). Les cibles se sont diversifiées progressivement (centres de documentation privés, CDI de collèges et lycées, enseignement supérieur), le plus gros client représentant 10% du chiffre d’affaire. PMB compte environ 5000 sites installés à la connaissance de l’éditeur.

Koha est issu d’une communauté internationale et informelle de développement et s’est directement implanté dans l’enseignement supérieur sous l’influence du projet de l’Ecole des Mines en 2003, suivi avec grand intérêt par les bibliothèques d’université et de grandes écoles. La communauté ne peut pas disposer de fonds propres et les évolutions majeures sont financées par les clients dans le cadre de projets commandés à l’une ou l’autre des SSLL constituant le noyau de développeurs Koha, ou sont directement financées par ces SSLL. Ce mode de fonctionnement communautaire provoque un développement par « à coups » où certaines fonctionnalités restent en attente puis se développent brusquement lorsqu’un commanditaire prend la décision de les financer. Le « wiki Koha » recense quelques centaines de sites installés dans le monde.

L’ancienneté d’un logiciel libre même si elle est toujours un critère favorable ne suffit donc pas pour rendre compte de la maturité d’un produit car elle aussi liée aux conditions de sa croissance. En outre la progression d‘un produit n’est pas indéfiniment linéaire. L’atteinte de la maturité, c’est à dire le point où les fonctionnalités intéressant le plus grand nombre d’utilisateurs sont développées et stables, constitue un palier temporel au-delà duquel les fonctions demandées n’intéresseront plus qu’un segment de la communauté. Les conditions de rentabilité des développements s’en trouvent modifiées et les développeurs peuvent adopter de nouvelles stratégies. Ainsi, après une dizaine d’années d’investissement exclusif à Koha, BibLibre a décidé de contribuer à d’autres communautés.

B/ la taille de la communauté.
Pour Ludovic Méchin « une communauté de clients large et variée compte plus que la diversité des développeurs. C’est le nombre de clients qui compte ». Pour Pascale Nalon le foisonnement est à la fois un atout et une fragilité : « c’est dynamique mais il faut un release manager pour tenir la barre ». Selon elle le nombre d’utilisateurs ne nuit pas à la cohérence de contributions « les choses s’autorégulent (...) Il n’y a pas de demandes qui s’excluent ».
L’accroissement du nombre d’usagers de PMB conduit à une perte de visibilité notamment sur les communautés internationales d’utilisateurs qu’Eric Robert suit comme la communauté française au travers de leurs lises de diffusion. « Le PMB belge a ses propres mailing liste (et des usagers se sont constitués en association), il y a une liste espagnole où s’investissent des utilisateurs d’Amérique du sud. Pas de liste italienne. Le Maghreb est coupé : ils ont PMB, le traduisent, mais pas de retour de la communauté. En Afrique, c’est plus opaque » (ER). Cette situation n’exclut pas le risque d’un fork qui fédèrerait une communauté d’utilisateurs étrangers autour d’un prestataire local, même si « les prestataires de services qui fédèrent une communauté respectent la société éditrice qui alimente leur activité grâce à son produit » (ER).

C/ l’expérience surmontée d’un fork
PMB Services en refusant les reversements de code (voir section H), n’encourage pas la multiplication de compétences de développement ce qui limite a priori le risque de fork. L’éditeur se trouve cependant en très classique situation de concurrence à l’égard des autres prestataires de services compétents sur l’installation, le paramétrage et la formation à PMB : « Cela arrive sur des réponses à des appels d’offre, d’autres prestataires répondent avec PMB. Si on n’était pas capable de le supporter humainement on n’aurait pas fait du libre. Ca nous force à être meilleurs que les autres, plus innovants. Nos concurrents ont toujours un certain retard. On a des services plus diversifiés» (ER). Si l’éditeur ne cite pas les autres prestataires sur son site, il contribue cependant en France à l’entretien d’un écosystème favorable, mais très contrôlé, en orientant certains clients à des prestataires de confiance ou en contractant avec certains d’entre eux pour échanger des prestations.

Koha a connu une alerte début 2008 lorsque la communauté de développement a refusé le reversement du « connecteur SUDOC » faisant craindre à la communauté française d’être contrainte au fork. Le « fork » LibLime en 2009 a porté un nouveau coup au moral de la communauté. En lançant immédiatement le développement d’une nouvelle version le noyau de développeurs a montré la capacité de la communauté à surmonter cette scission, ce qui est un point noté très favorablement par la méthode QSOS. Cependant Pascale Nalon est consciente que ces alertes successives laissent des traces chez les utilisateurs « on peut apprendre de l’expérience SUDOC comme du fork. L’association est là pour faire de l’explication de texte. Pour que les gens ne crient pas au loup. C’est une éducation à se faire.(…) Ca aiguise ma vigilance, à la communauté hors prestataire d’être vigilante pour annoncer clairement les problèmes ». Il reste dans l’éco système Koha une certaine méfiance teintée de fatalisme « la question du fork se posera peut être à BibLibre » reconnaît Ludovic Méchin. « Devant les réalités économiques, il faut continuer à faire du chiffre, quand on a quinze employés il faut faire entrer quinze salaires » s’inquiète Pascale Nalon. Sur son blog Katheryn GreenHill tente de calmer les esprits : « Vufind has several forks and this seems to be the community choice”.

3.3 LES TROIS CRITERES DE COMPOSITION
D/ les caractéristiques professionnelles des membres de la communauté
Le terme de communauté recouvre des réalités diverses. Pour Eric Robert la « communauté » est un ensemble international composé des clients de PMB services, des utilisateurs de PMB non clients de la société, des prestataires de services impliqués dans des projets PMB. Ils sont matérialisés par leur participation à des listes de diffusion ou leur constitution en association. La société est clairement distinguée de la communauté.
Dans l’écosystème Koha, le terme de communauté désigne les sociétés de service participant au développement du logiciel et les bibliothèques utilisatrices de Koha (représentées par des bibliothécaires ou des informaticiens) qu’elles soient ou non clientes des sociétés composant le noyau de développeurs. Cela souligne le caractère englobant et ouvert de la communauté. Des nuances sont cependant apportées par Pascale Nalon qui évoque parfois « deux communautés différentes qui interagissent » ou parle de « communauté hors prestataires » pour désigner les usagers des bibliothèques.
Les demandes de formation formulées auprès de Kohala par de nouvelles sociétés de service issues du logiciel « traditionnel » et désireuses d’intégrer la communauté remettent en question le positionnement de l’association : faut-il respecter absolument le principe d’ouverture et favoriser l’entrée de toute société au risque d’introduire des prestataires plus opportunistes que sincèrement attachés aux principes du libre ? Comment pour l’association réguler et arbitrer l’informel ? Respecter l’exigence d’ouverture tout en se préservant des prédateurs ? «Il ya un rôle de cautionnement pas facile. C’est un rôle nouveau.» (PN)

E/ la hiérarchie interne et la répartition des rôles selon les profils de membre.
Malgré leurs différences, les communautés PMB et Koha présentent une similitude : une organisation concentrique organisées selon une hiérarchie de compétences. Au centre de PMB, la société PMB service peut seule contribuer au développement du produit. Autour, une communauté de bibliothécaires « testeurs/critiques (…) qui lit, débugge mais ne fait pas de développement, car une communauté de développeurs c’est un frein» selon Eric Robert qui reconnaît « que la grande majorité de nos client ne fait pas la différence avec le système propriétaire ». La communauté Koha, malgré son développement communautaire, n’échappe pas à ce modèle : Marlène Delhaye s’en insurge : « on peut s'interroger sur la nature de la relation des bibliothèques au logiciel libre : alors qu'extérieurement cela devrait évoluer en une relation de partenariat (les bibliothèques apportant leur contribution au moins financière au projet), on a l'impression que cela reste une relation client-fournisseur traditionnelle (…). Ce manque d'engagement des bibliothécaires dans la communauté fait que, du coup, tout cela reste "un truc de développeurs"».

Pascale Nalon attribue ce fait à la caractéristique « métier » du SIGB libre : une niche marketing étroite fortement conditionnée par la culture professionnelle et les processus métier des bibliothécaires « On est dans un modèle nouveau de logiciel libre, une niche. Je n’ai pas d’exemple de communauté de logiciel libre sur une niche aussi petite. Nous c’est du métier « pointu », ce n’est pas de la comptabilité ».

Pourtant, selon Nicolas Morin, environ cent dix contributeurs ont participé peu ou prou au développement du logiciel depuis dix ans, ne serait-ce que par l’envoi ponctuel d’un correctif, et la majorité n’a jamais participé à aucune société prestataire. Koha est de fait une communauté particulièrement ouverte. En revanche 90% des développements d’architecture (les « releases » ou versions majeures) sont réalisés par les quatre ou cinq SSLL constituant le noyau dur de Koha. Participer à la correction ou a de menues avancées du code, bien que leur somme constitue une part importante du produit, ne semble pas pleinement satisfaire les utilisateurs qui souhaiteraient peser d’avantage sur les orientations stratégiques des versions. «on retombe dans un modèle où les développeurs mènent la danse alors qu’on, « je » me voudrais co-acteur même si je ne code pas » (PN).

F/Gouvernance du don
Le processus de versement a aussi son importance : PMB Services et la communauté Koha développent sur des plateformes de gestion de versions qui permettent de valider et dédoublonner les apports au fur et à mesure et dont l’utilisation exclut les développeurs par trop amateurs.
La scission opérée par Liblime, est devenue un fork de fait lorsque la société américaine a proposé de verser de temps en temps son code à la communauté et non plus systématiquement au fur et à mesure de sa production selon la règle de la production collaborative « release early, release often ». Verser en une fois une masse de code à valider et intégrer dans une version qui a suivi dans l’intervalle sa propre évolution est très fastidieux selon BibLibre. A l’inverse, Joshua Ferraro considère que livrer le code en temps réel à la communauté, parfois avant que ses propres clients l’aient validé, est une charge de travail considérable « This real-time contribution process created enormous overhead, especially given the volume of development that LibLime is involved in » .

Alors que l’imaginaire du libre repose sur le principe du don et de l’échange, les communautés comme les sociétés éditrices doivent donc consacrer une certaine énergie à refuser les dons indésirables. PMB Services refuse les codes proposés par des prestataires de services qui n’ont pas pris contact avec la société en amont et dont le code risque de s’intégrer laborieusement à l’existant. « Si un prestataire vient sans faire la révolution en ayant une bonne connaissance du modèle conceptuel de données, on sera ouvert, mais pas de jeune développeur fou » (ER).

La communauté internationale Koha élit pour chaque version un « arbitre » issu d’une des SSLL. Après un recensement des candidatures sur le wiki des développeurs, rendez-vous est donné sur le « channel » (essentiellement fréquenté par les développeurs). Tous les présents sur le channel à ce moment livrent leur vote. L’élu jouera le temps d’une version le rôle de « dictateur bienveillant » et validera ou refusera les codes proposés. Le refus est lourd de conséquences pour le contributeur malheureux car le prestataire évincé condamne son client à un fork involontaire : son logiciel n’est plus compatible avec la version officielle.

Le statut de PMB Service lui permet de contrôler les marques et noms de domaines associés au produit. Mais la communauté Koha n’a pas encore d’existence légale. Au fil du temps les SSLL internationales ont déposé elles-mêmes des noms de marques et de domaine dans leur zone géographique respective. Seule leur bonne foi garantit à la communauté qu’elles ne s’accapareront pas ces noms. Selon Nicolas Morin, les soupçons devenaient pesants et, particulièrement depuis le fork LibLime, le principe d’une fondation dépositaire des marques et des domaines s’est imposé. La fondation de droit américain envisagée devrait en outre permettre de percevoir des subventions.

3.4 LES TROIS CRITERES LIES A LA CULTURE DU DON
G/Maturité de la culture du don chez les membres usagers
La culture professionnelle des bibliothécaires offre un lit favorable aux principes du libre « On est dans des réseaux, on échange des livres. Le SUDOC ça ne nous est pas étranger. Il y a une notion de partage. On fait des notices qui vont aller à d’autres. » affirme Pascale Nalon qui reconnaît cependant que le monde des bibliothécaires manque de références par rapport à ce qu’est un logiciel libre et qu’ « il fonctionne beaucoup par référence avec le monde propriétaire ». Les freins ne résident donc pas dans l’esprit du libre. En revanche la co-construction des instances de gouvernance et des outils de communication reste difficile par manque de temps des bibliothécaires mais aussi d’investissement de la part de leurs organismes de tutelle. Lorsqu’elle n’est plus prise en charge par un fournisseur, la veille technologique ou juridique (ici sur les licences) et la négociation des orientations du produit pèsent lourdement sur les professionnels des bibliothèques. La présidente de Kohala regrette le manque de temps et de moyens dont disposent les bibliothécaires pour animer la communauté et ironise « il faudrait qu’une bibliothèque très riche mette un quart de poste sur cette activité, ou que quelqu’un y croie suffisamment pour prendre sur son temps libre ! ».

« Le logiciel libre c’est la parole donnée. » (PN). Le passage du monde contractuel à l’informel nécessite des adaptations culturelles. La confiance devient l’élément central, permettant au don de s’opérer . Or chez Koha la confiance a été mise à mal par le fork récent. La réaction « à chaud » de Joann Ransom au fork LibLime dénonce la promesse rompue: « Recipricocity is the keystone which gives strength to the Koha Community. We do not begrudge vendors taking our gift and building a commercial enterprise out of it, as Liblime, Biblibre and any number of others have done, but the deal is that you give back » (Librarymatters, 14 septembre 2009).

En l’absence de contrat, l’ « affirmation publique » (NM) tient lieu de garantie. Il s’agit donc de proclamer sur la place publique numérique composée de listes de diffusion, chat ou blogs que l’on respectera les intérêts communautaires (par exemple qu’une société n’utilisera pas à titre privé un nom de domaine déposé en lieu et place de la communauté informelle). En cas de manquement à la parole publiquement donnée la sanction viendra de la communauté et la réputation de l’entité sera compromise. La société Equinox Software, fortement impliquée dans le SIGB Evergreen, a ainsi publié le 16 septembre 2009 une vibrante et solennelle profession de fois dans laquelle elle réaffirme sa croyance (« we believe ») dans les principes de l’open source et ses promesses (« we promise ») de respecter les intérêts de sa communauté .

H/ l’ « épaisseur » de la communauté,
Le jeu démocratique de la communauté comporte une lourdeur dans les prises de décision que ne manque pas de souligner Eric Robert : « Une communauté de développeurs c’est un frein, la discussion prend une journée par réunion IRC, pas facile avec le décalage horaire. ».
Malgré l’attrait réel pour la relation entre pairs, le groupe constitué que représente la communauté libre peut parfois décourager les utilisateurs les plus novices freinés par la crainte d’être jugés ou rembarrés. En 2008 un utilisateur de PMB avouait : « je ne me sens pas faisant partie d'une communauté et je n'ose pas faire appel comme à une vraie boite ». (enquête 2008).

La gêne peut aussi être ressentie par les membres les plus motivés. L’énergie à déployer pour participer aux débats du « noyau dur » de Koha, peut être décourageante : l’anglais est la langue obligatoire dans une communauté internationale et il s’agit d’un anglais émaillé de jargon technique ! L’outil de communication privilégié des développeurs le « channel irc » fonctionne 24h00 sur 24h00 en raison des implantations géographiques. Des réunions ou des informations importantes peuvent s’y échanger à toute heure du jour ou de la nuit. Mieux vaut pour les informaticiens des SSLL garder un œil constant sur ce media pour rester « dans le coup ». Mais la temporalité des bibliothécaires est tout autre : « Paul dit « vous n’êtes jamais sur le canal IRC ». mais si je suivais aussi ça, je ne pourrais plus bosser ; Si je prépare une formation et que je dois m’interrompre toutes les trois minutes, je ne peux pas. J’ai peut être un cerveau archaïque et pas Web 2.0 ! » (PN).

I/Outils d’émulation
Mais la communauté est aussi une véritable motivation. Le don prend sens lorsqu’il est vu et reconnu par tous. Sur la plateforme de développement, les contributions sont tracées et comptabilisées. Leur nombre et leur importance confèrent une autorité, ce que ne manque de souligner Joshua Ferraro en évoquant «the volume of development that LibLime is involved in (which historically and currently represents an order of magnitude more than the entire rest of the community combined) » . Les bibliothécaires privilégient les blogs qui leur permettent de rendre compte de l’avancement de leur projet. Ces blogs ont deux fonctions. D’une part ils donnent une visibilité à l’élaboration d’un module attendu par la communauté et éviter l’ « effet tunnel », et Pascale Nalon impute à l’absence d’un tel blog l’émotion soulevée dans la communauté française de Koha par l’épisode du « connecteur SUDOC ». D’autre part, ils permettent à la bibliothèque ou à un groupement de faire connaître ses actions en faveur de la communauté, auto affirmation nécessaire puisque seules les contributions en code sont officiellement tracées par les plateformes de développement. Ce procédé qui a à voir avec l’ « affirmation publique », suscite une certaine émulation et ces blogs se multiplient.

Discussion et conclusion
L’histoire des logiciels libres et open source est marquée par une opposition constante entre économie de don et économie marchande. La progression des activités commerciales liées à cette nouvelle économie logicielle déplace progressivement les débats : opposition gratuit/payant, libre/open source et actuellement développement collaboratif/développement fermé contrôlé par un éditeur. Dans tous ces débats l’une des parties revendique un esprit de partage plus « pur » et reproche à l’autre d’en compromettre le modèle par opportunisme marchand.
Pourtant, l’étude de deux communautés de SIGB open source implantés en France montre que, malgré des politiques de développement radicalement différentes, elles présentent de nombreuses similitudes et notamment s’organisent autour de deux contraintes majeures :

- D’une part préserver la cohérence et la rentabilité de leur activité en contrôlant les contributions pour limiter les modes de contribution contre productifs, quitte pour cela à provoquer des « fork forcés ».
- D’autre part se garantir le plus possible contre les intrusions de prédateurs susceptibles de les affaiblir et de capter une partie du marché en provoquant des forks volontaires.

Dans ces deux objectifs, le degré d’ouverture du développement ne joue qu’un rôle marginal car c’est l’ouverture du code lui-même et donc sa possible appropriation par un tiers opportuniste qui constituent une fragilité. Le développement exclusif par un éditeur ne constitue pas une garantie contre le fork, pas plus que le développement en mode ouvert, notamment pour les logiciels « métier », ne permet à tous les membres de contribuer de façon satisfaisante à l’évolution du produit.
En revanche le statut d’éditeur commercial est plus favorable à la prise de décision même si celle-ci apparaît contraignante et frustrante pour l’utilisateur. De son côté, le mode collaboratif informel reste profondément dépendant de « l’affirmation publique », c'est-à-dire des discours produits sur des espaces publiques de l’internet et donc des conditions et des outils de production de ces discours. Cette situation peut provoquer des inégalités au sein des communautés collaboratives.

Enfin, dans les deux types d’organisations le caractère commercial des participants est affiché diversement : clairement mis en avant par l’éditeur PMB service, en retrait par rapport à l’affirmation de l’esprit de réciprocité dans la communauté Koha. Pourtant les utilisateurs de la communauté Koha perçoivent clairement la pluralité des statuts et analysent la situation en terme de concurrence et de marché.

A l’heure où Richard Stallman reconnaît avec regret que « l’usage et le développement de logiciels libres se sont beaucoup plus répandus que l’appréciation de la liberté sur laquelle le mouvement se fonde » , on peut se demander si l’utopie du don réciproque ne constitue pas un verrou psychologique. Dépasser dans les discours, comme cela est déjà le cas dans les faits, le clivage esprit de don/esprit marchand permettrait de se concentrer sur les performances commerciales, exceptionnelles en période de crise, réalisées en France par les SSLL, sur les modifications importantes qu’elles occasionnent sur le marché des éditeurs de SIGB et sur leur contribution majeure au débat professionnel sur l’élaboration des outils des bibliothèques. Poser clairement la question de règles formelles et universellement reconnues régissant les droit et obligations des membres utilisateurs et des sociétés commerciales serait alors facilité. Il ne s’agit pas de nier la liberté d’utilisation des logiciels mais d’accompagner les communautés « métier » d’un « état de nature » à une « démocratie constitutionnelle ».

Bibliographie

BERGQUIST, M., LJUNGBERG, J. (2001). The power of gifts : organizing social relationships in open source communities. Info Systems J, 11, (305-320). (document en ligne) < http://smg.media.mit.edu/classes/library/BergquistLjungberg.Gifts.pdf>
BONACCORSI, A. ROSSI, C. (2006). Comparing motivations of individual programmers and firms to take part in the open source movement: From community to business, in "Knowledge, Technology & Policy", Volume 18, Number 4 / décembre 2006, pp.40-64. (en ligne)
BROCA, S., Du logiciel libre aux théories de l’intelligence collective, tic & sociéré, 2(2), 2008, pp. 52-100.
COMINO, S, MANENTI, F. M. , PARISI, M. L. (2005) From Planning to Mature: on the Determinants of Open Source Take Off. Technical Report 17, Economia, University of Trento. (en lgine) < http://eprints.biblio.unitn.it/archive/00000902/>
DEMAZIÈRE, D., HORN, F., JULLIEN N. (2005). Le travail des développeurs de logiciels libres. La mobilisation dans des "communautés distantes" .Cahiers lillois d'économie et de sociologie 2e semestre, 46, 171-194 (en ligne) < http://hal.archives-ouvertes.fr/hal-00282214/en/>
GENSOLLEN, M. (2004), Economie non rivale et communautés d’information, Réseaux, 2004/2, n°124, pp. 141-206
GODELIER, M., Communauté, Société, Culture - Trois Clefs Pour Comprendre Les Identités En Conflits, CNRS, 2009.
HIMANEN, P, (2001) The hacker ethic and the spirit of the information age.- Random House Inc. New York, NY, USA
JULLIEN, N. , ZIMMERMANN J.B. (2006). Peut-on envisager une écologie du logiciel libre favorable aux nuls ?, Terminal n°97-98, pp. 33-47. (en ligne) < http://www.marsouin.org/IMG/pdf/Jullien-Zimmermann_9-2005.pdf>
JULLIEN, N. , (2007).Développer du logiciel libre, une activité marchande! Cahier de Recherche Marsouin, n° 14 (document en ligne sur ).
KRISHNAMURTHY, S .(2002). Cave or community ? an empirical examination of 100 mature open source project. First Monday, 2002. Available at SSRN:< http://ssrn.com/abstract=667402>
KRISHNAMURTHY, S. (2005), An Analysis of Open Source Business Models.in " making sense of the bazaar: perspectives on open source and free software", Joseph Feller, Brian Fitzgerald, Scott Hissam and Karim Lakhani, eds., MIT Press, Forthcoming. Available at SSRN:< http://ssrn.com/abstract=650001>
LAKHANI, KARIM R. AND WOLF, ROBERT G., Why hackers do what they do: Understanding Motivation and Effort in Free/Open Source Software Projects(September 2003). MIT Sloan Working Paper No. 4425-03. Available at SSRN: http://ssrn.com/abstract=443040 or DOI: 10.2139/ssrn.443040
LAVE, J., WENGER, E., (1991), “Situated Learning: Legitimate Peripheral Participation”, Cambridge University Press
MORGAN, E. L., (2004). Logiciels libres et bibliothèques, BiblioAcid. vol.1, n°2-3, pp.1-7. (document en ligne sur ).
MORIN, N., (2004). Pour un SIGB libre, BiblioAcid. vol.1, n°2-3, pp.8-18. (document en ligne sur ).
MÜLLER, T., (2008). Etude comparative des principaux SIGB libres, « francophonies et bibliothèques : innovations, changement et réseautage » premier congrès de l’Association Internationale Francophone des Bibliothécaires Documentalistes, Montréal, 3-6 août 2008. (document en ligne sur http://bbf.enssib.fr).
RAYMOND, E. YOUNG, B. (2001) The Cathedral & the Bazaar, O'Reilly, 208 p.
ROGEL, C., (2004). Licences publiques, logiciels libres et ouverts : De l’informatique subie aux SIGB flexibles. Bulletin des Bibliothèques de France, t. 49, n° 6. (document en ligne sur http://bbf.enssib.fr).
SCOPSI, C. ; SOUAL, L.; FERRAILLE, J.-F. ; MACHEFER, S., (2007). Mener un projet Open source en bibliothèque, documentation et archive . Paris, Cercle de la Librairie.
SCOPSI, C. ; (2008 (a)), « Usages concurrents et complémentaires des logiciels libres et des logiciels propriétaires », Documentaliste – Sciences de l'information, août 2008, Vol. 45, n° 3, p.18.
SCOPSI, C. ; (2008 (b)) Introduction des SIGB open source dans les bibliothèques françaises : nouveau paradigme ?In « Traitements et pratiques documentaires . Vers un changement de paradigme ? » Actes de la deuxième conférence Document Numérique et Société, CNAM(Paris), Evelyne Broudoux, Ghislaine Chartron (Dir.).- Paris : ADBS,.pp. 51-71.
TOSCA CONSULTANTS, (2009). Bibliothèques – l’équipement informatique en 2008, Livres Hebdo, n° 767.
VON HIPPEL, ERIC A. (2002). Open Source Projects as Horizontal Innovation Networks - By and For Users. MIT Sloan Working Paper No. 4366-02. Available at SSRN:
VON HIPPEL, ERIC A., (2005). Democratizing Innovation. DEMOCRATIZING INNOVATION, MIT Press, Cambridge, MA, April 2005. Available at SSRN: http://ssrn.com/abstract=712763