– Tristan Nitot, Mozilla Europe
- Nicolas Barcet, Ubuntu (Canonical)
- Louis Montagne, Bearstech
- John Lejeune, Hackable Devices
- Luis Belmar, Itaapy

Tristan Nitot fait remarquer en introduction que la notion de croissance, au sens de croissance économique, n’intéresse pas l’association fédère la communauté Mozilla, les revenus qu’elle retire de ses activités étant destinés à assurer la pérennité des projets qu’elle porte.

Cette matinée d’échanges et de découvertes des méthodes et processus à l’intérieur des communautés Open Source et de la conduite de projets en mode agile se propose de répondre aux questions :

- comment gère-t’on une communauté open source?
- projets informatiques classiques et projets open source: différences, ressemblances…
- existe-t’il des critères d’évaluation pour les projets open source?
- quelles sont les implications juridiques et opérationnelles?

Comment gère-t’on une communauté ?

Une gestion complexe très dépendante de la nature et de l’intention des acteurs. L’exemple de Collibri, communauté mise en place au sein du pôle de compétitivité Cap Digital, va regrouper des entreprises, des laboratoires de recherches, aux intentions divergentes. Cette approche est très différentes de communauté du logiciel libre qui font parfois appel à un « dictateur bienveillant », notion qui met à mal l’approche « communataire ».

L’exemple de Mozilla, une communauté travaillant pour elle-même, c’est à dire pour accomplir la mission du Mozilla Manifesto, utilisant des méthodes d’entreprises pour atteindre cette objectif au service du bien commun : l’ouverture d’Internet.

Le « Comment ? » amène la question aux outils et aux usages, outils pour pouvoir travailler à plusieurs wiki, tracker… demandant à connaitre des usages de politesse… Etapes techniques à la création d’une communauté nécessaire mais pas suffisantes pour avoir une communauté. L’existence d’une communauté demandant à formaliser un code de conduite de cette communauté respectant les motivations diverses des acteurs : besoin, économique, gloire, utilité, réseau… Cela nécessite un animateur de la communauté, ou plutôt des animateurs de communautés comme pour Ubuntu. Cela nécessite également que l’instigateur initial, individu ou entreprise ne garde pas la main-mise sur le produit fabriqué par la communauté.

Le développement personnel de chaque individu d’une communauté est une préoccupation importante de l’animateur de la communauté. Chaque contributeur doit trouver au cours de son implication dans une communauté une rétribution correspondant à ses aspirations.

John Lejeune amène la table-ronde sur le terrain du réel, la conception, la production et la distribution de matériel, nécessitant un apport financier plus important… Et la transposition des méthodes du logiciel libre aux matériels permet de dépasser les limites physiques classiques.

Gestion des projets ?

La gestion des projets est-elle similaire ? Pas vraiment ! L’approche agile de pilotage des projets est une constante des différentes communautés qui choisissent une approche itérative, avec une publication de produit à chaque itération qui permet de coller au besoin ou à l’envie des utilisateurs.

Interpellé depuis la tribune pour expliquer ce qu’est l’agilité en trois mots… Beaucoup plus de trois mots pour le faire… Pfff… prévenez-moi la prochaine fois !

Ces utilisateurs étant parfois représentés par un dictateur bienveillant comme il arrive dans les sociétés au développement classique. Mark ShuttleWorth s’est par exemple auto-proclamé dictateur bienveillant de la communauté et à en parallèle mis en place une organisation communautaire avec un contrôle par les pairs. Cette organisation n’est pas représentative de toutes les communautés, Mozilla a par exemple une approche par méritocratie ou les acteurs doivent démontrer qu’ils savent faire avant d’obtenir un badge avalisant une fonction différente, les actions étant toujours réalisées sous le contrôle des pairs. Debian dans son organisation est lui un projet démocratique.

Evaluation d’un projet ou d’une communauté ?

Ubuntu utilise des critères d’inclusion de produits dans la distribution avec les main inclusion requirements qui vont être utilisés pour évaluer ces produits. Ces critères sont bien sur évaluer par les équipes en les appréciant en fonction du besoin. Un sujet d’avenir…

Une remarque dans les questions sur l’utilisation de métrique sur le code produit comme avec le projet Ohloh.

Community management, gestion de communauté ?

Que gère-t-on ? certaines par les personnes et les membres de cette communauté ! Ce que l’on gère c’est plutôt la cohérence du groupe, la motivation des membres pour appartenir au groupe…

Interaction des entreprises avec les communautés :

• travailler comme une communauté
• travailler avec une communauté
• l’entreprise veut fabriquer sa propre communauté

L’histoire de la création de Mozilla, issue de la société Netscape, rachetée par AOL (ce qui n’était pas favorable à des contributions externes) qui va véritablement démarrer à avoir une histoire communautaire à partir du moment ou AOL va jeter l’éponge et que la Fondation Mozilla va être créée.

L’approche d’Ubuntu est différente avec une société Canonical à but lucratif qui finance une communauté Ubuntu à but non lucratif.

OpenOffice.org souffre de certaine volonté de puissance au sein du projet (le rachat de Sun par Oracle va d’ailleurs probablement avoir des développements complexes pour ce projets).

Croissance ?

On en revient en conclusion sur la croissance. Quelle croissance ? Croissance des indicateurs de valeurs partagés au sein d’une communauté. Ces indicateurs ne sont bien sur par des indicateurs uniquement purement économique…

La croissance par le partage dépasse ces indicateurs et il n’y a pas à ce jour d’indicateurs communément partagés permettant de valoriser cette croissance.

Comme pour la croissance du PIB dans notre vie actuelle, les indicateurs économiques sont inadaptés à mesurer notre richesse individuelle et la richesse de nos sociétés !

Les questions et remarques à présent :

Une remarque essentielle de Sophie Gautier (OpenOffice.org) sur l’enthousiasme et le plaisir éprouvé par les contributeurs d’une communauté, et c’est probablement une des capacités essentielles d’un animateur de communauté de susciter cet enthousiasme.

Le Release early / Release often est important, il doit être pris en considération le risque d’épuisement de la communauté si le rythme est trop élevé. En corolaire, il est important de considérer la modularité du produit afin que le produit à sortir ne soit pas trop complexe et demander trop d’effort.

Jean-Baptiste Kempf à la tête du projet VideoLan (VLC) assure de la nécessité de l’enthousiasme puisque c’est le moteur des membres de VLC projet réalisé entièrement par des bénévoles. Il interroge également le release early / release often en posant la question du rythme lié à la complexité.

Plus que de la gestion, c’est plus un rôle de cristallisation de la communauté qui va permettre à l’enthousiasme de s’exprimer au sein de cette communauté.

Une autre question sur le sentiment d’appartenance à une communauté si le produit est géré et contrôlé à 100% par une entité commerciale… Est-ce une communauté ou un fan club ? Tout dépends de l’implication des membres… et de leur capacité à influer sur les orientations du produit.

Une question sur la possibilité de créer des communautés en internes dans les entreprises et même de communautés qui vont pouvoir être publier à l’extérieur de l’entreprise. Les exemples sont nombreux dans l’administration, avec la Gendarmerie nationale et OCS Inventory et GLPI, la création de l’Adullact, la BBC…

L’avantage de la communauté basée sur l’utilisation de licence libre permettant de ne pas perdre de temps à négocier des contrats puisque la licence est déjà là…

Une belle matinée vivement la prochaine !