Accueil > Actualités, Divers > fOSSa 2010 (Free Open Source Software Academia)

fOSSa 2010 (Free Open Source Software Academia)

Dernièrement a eu lieu, à Grenoble, la 2ème édition des conférences fOSSa (Free Open Source Software Academia) dont le rôle principal est de promouvoir le logiciel libre. L’école GEM (Grenoble Ecole de Management), située à côté du World Trade Center, a accueilli l’événement sur 4 demi-journées consécutives réparties sur 3 jours.

L’année dernière, la 1ère édition de l’événement s’était focalisée sur les fondamentaux du modèle open source (modèle économique, licences, problèmes juridiques, etc.). Cette année, l’objectif était de réaffirmer les valeurs du logiciel libre mais aussi de réfléchir à son avenir.

En parallèle des sessions de conférences principales avaient lieu un ensemble de « workshops », où différents acteurs du logiciel libre (venant des secteurs publics et privés) venaient présenter leur travail, expliquer leur choix d’aller vers un modèle libre et comment ils le mettent en œuvre au quotidien, avec démonstrations à l’appui !

Et, cerise sur le gâteau, la 2ème journée s’est terminée par une session spéciale de l’AlpesJUG animée par Jason Van Zyl, le fondateur de Maven et Sonatype.

En tout, une petite centaine de personnes étaient présentes chaque jour, réparties entre les sessions principales et les « workshops », ce qui est bien peu au regard de la qualité des interlocuteurs et des présentations.

Objet Direct, qui participe pleinement à la promotion des logiciels libres via son pôle innovation OD Labs, était naturellement présent lors de ces conférences dont nous présentons une partie dans cet article.

1er jour

Le lundi proposait une demi-journée de conférences autour du développement, de l’innovation et de la recherche dans le cadre du logiciel libre.

Pour commencer, Martin Michlmayr, membre de la communauté Debian et responsable de la division open source chez HP, a évoqué la gestion de projet dans le cadre bien particulier des projets open source. Aujourd’hui, la plupart des projets open source fonctionnent encore sur un mode d’auto-gestion, où les différents développeurs assurent eux-mêmes la coordination et s’assignent des tâches. Cependant, ce n’est pas le cas de tous les projets open source. En pratique, une « vraie » gestion de projet est souvent nécessaire pour 2 raisons principales. Premièrement, pour aider les contributeurs à trouver leur périmètre d’intervention en fonction de leurs affinités et de leurs compétences propres (en bref, les aider à s’assigner les « bonnes » tâches). Deuxièmement,  pour motiver (ou re-motiver) les contributeurs en cas de besoin. C’est d’autant plus important que la motivation est l’élément clé des projets open source, dans la mesure où les contributions se font sur la base du volontariat. Pour cela, il faudra au minimum s’assurer que les contributeurs prennent pleinement conscience de l’utilité de leur action et, si possible, organiser des « real-life meetings » (réunions où l’on se rencontre « pour de vrai »). Il peut s’agir de sessions de travail (« hack sessions »), qui ont aussi pour but de stimuler l’efficacité, ou de rendez-vous « sociaux » plus informels.

La gestion de projet doit en fait commencer avec le démarrage de celui-ci. En pratique, démarrer un nouveau projet open source est très (trop ?) facile. Quelques minutes sur SourceForge suffisent. La conséquence directe est que la plupart des projets open source sont obsolètes (pas ou peu de code, pas d’activité régulière…).  Les questions suivantes doivent donc être posées (et trouver une réponse !) avant de démarrer un nouveau projet :

  • A-t-on besoin de démarrer un nouveau projet ? Existe-t-il un autre projet open source répondant au même besoin, et si oui, pourquoi ne pas l’utiliser ?
  • Quel est le langage de programmation ciblé ?
  • Puis-je donner une estimation fiable de la charge initiale de travail ?
  • Quid des aspects juridiques (choix de la licence) ?

Dès lors que le projet est démarré, le chef de projet sera immédiatement responsable d’attirer l’intérêt de la communauté open source en vue de trouver des contributeurs, puis de leur donner les moyens de rentrer dans le projet, et enfin, de les coordonner en rendant le tout sympa  (« make it fun ! ») et valorisant.

Martin précise que les mêmes problématiques sont présentes pour les projets propriétaires qui se tournent, à un moment donné, vers l’open source (c’est ce qu’on appelle communément la transition Cathédrale → Bazar – le terme « cathédrale » s’appliquant aux logiciels propriétaires, tandis que le terme « bazar » désigne – souvent injustement – les logiciels open source).

Il donne ensuite quelques conseils pour assurer la viabilité du projet sur le long terme. Dans ce sens,  l’axe qualité est prépondérant : c’est en garantissant une qualité de code élevée et constante dans le temps, en fournissant une documentation à jour et de bonne qualité, et enfin, en mettant en place autour du projet une infrastructure sérieuse et complète (intégration continue, système de gestion de bugs, etc.) que le projet sera attrayant et incitera constamment de nouveaux contributeurs à le rejoindre. C’est d’autant plus vrai que la qualité permet de réduire le temps de montée en compétence sur un projet. Enfin, l’axe dynamisme est aussi fondamental : en livrant de nouvelles versions régulièrement, cela démontre que le projet est actif.

Sur le plan purement humain, il y a bien sûr autant de styles que de chefs de projet, mais pour Martin, un chef de projet open source doit avoir des qualités bien spécifiques. Pour commencer, il doit faire attention à ne pas exposer de requêtes personnelles publiquement (demander en privé et non pas sur les listes de diffusion). Ensuite, il doit connaître ses contributeurs, ce qui n’est pas forcément simple au vu de leur diversité potentielle : dans quels domaines sont-ils bons ? Par quoi sont-ils intéressés ? Quelles sont leurs circonstances personnelles ? Sur ce dernier point, il faut en effet s’adapter aux contraintes personnelles – par exemple, ménager un contributeur qui vient d’avoir un enfant, impliquer davantage les étudiants pendant la période estivale, etc. Enfin, le chef de projet ne doit pas craindre de s’abstenir des services de contributeurs « indésirables » (pour cause d’incompétence avérée, d’inactivité ou de comportements limites  (trolls, etc.)

La présentation se conclue en évoquant les problématiques à anticiper lorsqu’un projet est amené à grossir rapidement. Il est alors facile de « perdre le contrôle », et, pour limiter les risques, le chef de projet pourra par exemple tenter de construire une sphère autour d’un noyau dur de contributeurs.

Ensuite, nous avons eu la chance d’écouter Chris Aniszczyk, employé chez Red Hat et acteur majeur de l’open source depuis plus de 12 ans, qui siège désormais au conseil d’administration de la fondation Eclipse, en plus d’être « committer representative » (leader technique) de cette dernière. Chris était là pour évoquer l’évolution des systèmes de gestion de sources dans le monde open source au cours des dernières années.

Après un bref rappel du rôle de ces systèmes de gestion de sources (développement collaboratif, suivi des modifications, gestion de branches, etc.) et de l’historique depuis leur apparition, Chris oppose ensuite les 2 approches concurrentes sur lesquelles se basent les solutions courantes, à savoir l’approche centralisée et l’approche distribuée. Dans l’approche centralisée, qui est celle de CVS et de SubVersion (SVN), un serveur central héberge un « dépôt » (repository) sur lequel sont stockées les sources, et chaque client doit effectuer un « check-out » pour récupérer une copie de travail en local. Dans l’approche distribuée, qui est celle de Git et de Bazaar, on fonctionne en mode « peer to peer » : chaque client a son propre dépôt, et la synchronisation des sources se fait par échange de patches (aussi appelés « changesets ») entre les différents clients. Par conséquent, la majorité des opérations se font localement et s’exécutent très rapidement.

Chris nous amène peu à peu à l’essentiel de son discours : les projets open source se tournent de plus en plus vers l’utilisation de ces systèmes distribués, avec les bénéfices suivants :

  • La collaboration est possible sans recours à un mécanisme central d’habilitation ;
  • Le travail en mode déconnecté est possible ;
  • Les données (sources et historique des modifications) sont davantage protégées contre la perte, dans la mesure où le dépôt de chaque client aura naturellement le rôle de backup ;
  • Etc.

Pour finir, Chris évoque la situation au niveau de la fondation Eclipse. Une roadmap y a été définie en 2009 pour migrer progressivement vers Git, qui a été choisi pour ses qualités de rapidité et de scalabilité, pour sa mâturité et sa popularité, ainsi que pour la disponibilité de nombreux outils autours de Git (tels que Gerrit Code Review, qui facilite les processus de revues de code). L’utilisation de CVS est déjà dépréciée, et celle de SVN le deviendra à l’avenir. Eclipse distribue par ailleurs 2 outils facilitant la mise en œuvre de Git : JGit, une implémentation Java de Git, et EGit, un plug-in Eclipse permettant d’intégrer cette technologie à l’IDE Eclipse. L’objectif étant, bien sûr, de bâtir une communauté Eclipse autour de Git. Cependant, la migration vers Git n’est pas une tâche aisée et, aujourd’hui, seulement 10% des projets de la fondation Eclipse ont été migrés (sachant qu’elle héberge actuellement plus de 200 projets). En effet, il n’a pas été facile de convaincre de la nécessité d’une telle migration, et le temps d’apprentissage s’avère plus long que prévu.  Mais, selon Chris, c’est une étape indispensable dans la mesure où l’ensemble de la communauté open source se tourne peu à peu vers ces systèmes distribués de gestion de sources.

La présentation complète de Chris est disponible à cette adresse : http://www.slideshare.net/caniszczyk/evolution-of-version-control-in-open-source

2ème jour

Le mardi proposait une matinée consacrée à l’éducation et une après-midi consacrée au secteur public, le tout bien sûr dans le cadre de la promotion et de l’utilisation des logiciels libres. N’étant présent que durant la matinée, nous ne détaillons ci-dessous que les conférences sur l’éducation.

Pour commencer, Roberto Di Cosmo est venu parler de l’IRILL, Initiative pour la Recherche et l’Innovation dans le Logiciel Libre, qui a pour objectifs de devenir un centre du logiciel libre reconnu  internationalement et articulé autour de 3 axes majeurs : développement, recherche/éducation et industrie.

Positionnement de l'IRILL

L’initiative trouve sa source dans la prise de conscience des changements radicaux apportés par les logiciels libres. Ces changements s’opèrent bien sûr au niveau technologique (l’approche libre change la manière dont les logiciels sont conçus, développés, distribués, vendus, maintenus et enseignés), mais également aux niveaux industriel et économique (l’approche libre stimule la compétition, permet de réduire les coûts et le « time-to-market »). Plus globalement, ils impactent la société toute entière en donnant aux citoyens le contrôle de technologies parfois stratégiques.

L’IRILL doit donc s’attacher à relever les défis accompagnant la croissance du monde open source. D’une part, il y a un défi d’ordre scientifique et technologique lié au fait que la quantité, la taille et la rapidité d’évolution des logiciels distribués dépassent tout ce que nous aurions pu imaginer il y a quelques années. Il y a aussi et surtout un défi d’ordre éducatif que nous décrivons plus finement ci-dessous.

Au niveau éducatif, Roberto prône l’enseignement au logiciel libre avec des logiciels libres. L’enjeu est double : d’une part,  enseigner les valeurs de l’open source à tous, et d’autre part, enseigner aux ingénieurs de demain comment développer dans la sphère open source. Et le challenge est d’envergure car il faudrait pour cela apporter des changements profonds dans le cycle éducatif.

En effet, selon lui, l’approche éducative actuelle n’est pas bonne. D’une part, les écoles et universités partent souvent du principe que les étudiants ont une connaissance parfaite du fonctionnement d’un ordinateur, ce qui est rarement le cas (surtout dans les cursus non liés à l’informatique). Il faudrait donc commencer par augmenter sensiblement le niveau de base en informatique de tous les élèves, en débutant assez tôt dans le parcours éducatif. D’autre part, dans le cadre des cursus spécialisés en informatique, les écoles et universités enseignent encore très souvent selon la formule « écrivez votre programme (ou votre algorithme) sur une feuille de papier ». Roberto considère qu’une meilleure approche serait d’exploiter les exemples de projets modèles mis à disposition par la communauté open source. Il suggère ainsi d’introduire le développement libre dans les cursus spécialisés, et de faire travailler concrètement les futurs ingénieurs sur des projets open source, en créant pour cela des connexions entre les communautés open source et les écoles ou universités.  Faire contribuer les étudiants à de véritables projets serait d’une part plus formateur et d’autre part plus stimulant, et donc au final plus efficace.

La présentation complète de Roberto est disponible à cette adresse : http://www.dicosmo.org/TALKS/Presentation_IRILL_Fossa_2010.pdf

La présentation suivante donnée par Gilles Dowek, professeur à l’école Polytechnique et chercheur au Laboratoire d’Informatique de l’Ecole Polytechnique (LIX) ainsi qu’à l’INRIA, s’inscrit complètement dans la vision exposée par Roberto, mais parle plus spécifiquement du cas de la France. Selon lui, la France est un pays sous-développé au niveau de l’enseignement informatique dans les lycées. Au collège, seuls sont présents quelques cours de technologie allant de la mécanique à l’informatique rudimentaire. Les écoles de l’enseignement primaire et secondaire sont aujourd’hui habilitées à délivrer le B2i (brevet informatique et internet), mais ce brevet cible uniquement l’utilisation de logiciels grands publics (traitement de texte, navigateurs web,…). Par ailleurs, les cours ne sont pas dispensés par des professeurs spécialisés et les critères d’évaluation sont assez flous. Suite à ces observations, un groupe composé de membres de l’ASTI (Association des Sciences et Technologies de l’Information) et de l’ETI (Enseignement Public et Informatique) a soulevé une alerte, envoyé des courriers et organisé des réunions avec les plus hautes instances françaises de l’enseignement pour provoquer une prise de conscience. Et cela n’a pas été en vain, puisque dès 2012, un nouveau cours  d’informatique devrait être proposé aux lycéens de la filière scientifique, dans le cadre de leur choix de spécialisation : ils auraient alors le choix entre les spécialités déjà existantes (maths, physiques, biologie) et une nouvelle spécialité informatique. Cette nouvelle mesure, inscrite dans la cadre de la réforme du lycée, est décrite plus en détails dans cet article du monde informatique. Mais elle n’est qu’une étape parmi d’autres. A terme, l’objectif est d’inscrire l’enseignement informatique dans toute la durée du cycle scolaire entre l’école primaire et l’enseignement supérieur, et ce en trois grandes phases :

  1. De 6 à 12 ans (école primaire et 1ère moitié du collège) : apprendre à utiliser des logiciels grand public (traitement de texte, navigateurs, moteurs de recherche, etc.) et commencer à se poser les bonnes questions : où est stockée l’information manipulée ? Comment est-elle véhiculée d’un point à un autre ? Comment une image est-elle affichée ? Etc. ;
  2. De 13 à 18 ans (2ème moitié du collège et lycée) : découvrir la programmation – comprendre ce qu’est un programme et comment il est écrit, comprendre la distinction entre un programme libre et un programme commercial, apprendre à écrire son propre programme ;
  3. Après 18 ans (enseignement supérieur) : apprendre l’informatique en tant que science à part entière.

Et Gilles insiste sur le fait qu’à toutes les étapes, un équilibre doit être trouvé entre les 4 concepts majeurs de l’informatique : algorithme, machine (système, réseau), langage et information. Ce sont en effet les 4 piliers de l’assertion suivante : « un langage de programmation permet d’écrire des algorithmes qui s’exécutent sur une machine et traitent des informations ».

Le point faible de la réforme actuelle est qu’elle ne prévoit pas l’implication de professeurs spécialisés dans le primaire et le secondaire, dans la mesure où il n’existe actuellement pas de diplôme permettant d’enseigner l’informatique à ces niveaux. Il est donc prévu que les professeurs en place (principalement les professeurs de maths) suivent des préparations spécifiques leur donnant le droit de dispenser les cours d’informatique.

Pour conclure, Gilles répond à la question que tout le monde se posait dans l’assemblée sans oser le dire ouvertement : en quoi cela a-t-il un rapport avec la communauté open source ? Il explique tout d’abord que les logiciels libres seront utilisés à grande échelle dans les différents cursus, mais que ce n’est certainement pas le point le plus important. La raison principale réside dans la similitude qui existe entre l’enseignement et la philosophie open source qui consiste à responsabiliser les acteurs en leur donnant petit à petit du pouvoir. Explorer un projet, regarder son code, comprendre son fonctionnement, y participer en l’enrichissant sont autant d’étapes auxquelles sont confrontés les contributeurs de projets open source. Chacune de ses étapes est nécessaire pour les responsabiliser et leur donner de la maîtrise sur ce qu’ils font. Et c’est cette méthode de responsabilisation que Gilles souhaiterait voir émerger dans les cursus scolaires en informatique. Apprendre à cliquer sur un bouton ne sert pas à grand-chose, quand apprendre les concepts sous-jacents donne du pouvoir.

Didier Courtaud, de l’Université d’Evry, est ensuite venu nous présenter un cas concret de partenariat entre communautés open source et enseignement : le projet COMETE (Course On Mozilla Education and Technologies @ Evry). Ce projet, réalisé en partenariat entre l’Université d’Evry et la fondation Mozilla, découle des observations de forte croissance de la sphère open source (Didier explique que selon le groupe Gartner, d’ici à 2012, au moins 80% de tous les produits logiciels utiliseront des logiciels libres). Il est donc nécessaire de préparer les futurs ingénieurs à cette réalité car les entreprises ont désormais besoin de compétences open-source en interne. Didier explique le choix de Mozilla par 2 raisons : d’une part Mozilla édite et distribue des logiciels libres mondialement reconnus (Firefox, Thunderbird, etc.), et d’autre part, les technologies qui sont utilisées pour réaliser ces produits sont basées sur des standards universels et bénéficient d’un temps d’avance en termes d’innovation. Par ailleurs, le partenariat a été boosté par le lancement de Mozilla Education, dont le but est de fournir des cours en ligne et, plus globalement, enseigner les technologies Mozilla afin de stimuler la contribution aux projets Mozilla. En 2009, 30 étudiants ont participé au cursus COMETE qui est composé d’une partie théorique, donnée par des experts Mozilla, et d’une partie pratique. Cette dernière se présente sous la forme d’un projet proposé soit par la communauté Mozilla, soit par les entreprises qui accueillent les étudiants dans le cadre de leur stage en alternance, si ces dernières acceptent d’utiliser les outils Mozilla en interne. Ce projet sera géré comme un projet open-source : un wiki et/ou un blog  seront mis à disposition pour permettre de suivre leur évolution, des versions intermédiaires seront livrées régulièrement, et le travail collaboratif y sera fortement encouragé (y compris de la part des autres étudiants et de la communauté Mozilla). L’évaluation finale est basée sur un rapport écrit, une présentation orale ainsi que sur cet aspect de collaboration aux autres projets.

Après une année d’existence, le projet COMETE semble être une réussite pour toutes les parties prenantes. D’une part, les étudiants, qui découvrent pour la plupart le monde des logiciels libres, sont en général très enthousiastes à l’idée de travailler dans le cadre de grands projets open source. Et, in fine, leur retour est très positif : ils ont trouvé les projets très bien structurés et d’excellente qualité, ils ont appris  à travailler en mode collaboratif et, cerise sur le gâteau, leur travail est valorisé par le biais de l’intégration dans la prochaine version du produit ! D’autre part, c’est un investissement à long terme rentable pour Mozilla, car une partie des étudiants continueront à contribuer à leurs projets après leurs études et, au minimum, ils participeront dans la diffusion des produits Mozilla dans leurs futures entreprises. Il s’agit donc clairement d’un partenariat gagnant-gagnant. Le seul point qui soulève des questions au terme de la présentation de Didier est celui des attentes en termes de qualité. En effet, la qualité des projets réalisés est-elle au rendez-vous dans la mesure où les contributeurs sont novices ? Si non, quel est le coût de récupération pour Mozilla ?

3ème jour

Le mercredi matin proposait une série de conférences autour de la gestion et de la promotion des communautés open source, animées par des orateurs de grand renom.

Pour commencer, Ross Gardler, vice-président de l’Apache Software Foundation (ASF) est venu dire que la communauté est plus importante que le code lui-même, car elle seule peut garantir la viabilité du code sur le long terme. En effet, regrouper ainsi une multitude de projets open source au sein d’une même communauté présente des intérêts évidents : c’est en facilitant le partage d’idées, de code, de ressources, de compétences et d’outils qu’on peut garantir une meilleure réactivité ainsi qu’une productivité et une qualité optimales.

Ross en profite pour présenter la fondation Apache, qui est loin de se résumer au célèbre serveur HTTP : avec pas moins de 330 membres, plus de 2500 « committers », 82 projets majeurs, 32 projets expérimentaux et 41 projets en incubation, elle s’impose comme l’une des plus grandes communautés open-source. L’ASF, c’est aussi une licence et un processus de développement qui se veut ouvert, transparent et collaboratif, dans le but affiché de voir émerger du code et des produits de grande qualité.

Pour limiter au maximum les risques de perte de contrôle, Ross insiste sur un point essentiel : la neutralité. Ainsi, au sein de l’ASF, toutes les contributions sont basées sur le volontariat. Aucun développeur n’est rémunéré, et aucun intérêt commercial ne prévaut (les intérêts commerciaux sont laissés à l’extérieur de la communauté). Ross admet que la plupart des contributeurs de l’ASF ne sont pas des contributeurs « standard », c’est-à-dire altruistes. En fait, la plupart d’entre eux sont impliqués de façon très intéressée, à savoir qu’ils contribuent pour leur propres besoins.

Ross évoque ensuite un point important qu’il faut impérativement soigner dans les communautés : le processus de décision. L’ASF a décidé de se baser sur un processus piloté par les consensus : toute décision est précédée d’un accord manifeste et si possible unanime. Pour ne pas biaiser  la prise de décision, l’ASF a opté pour une structure à plat, sans hiérarchie de pouvoir. Au sein du groupe de travail concerné par la décision, chaque personne représente une voix et dispose d’un véto. Tout véto doit être justifié et renforcé par une proposition de solution alternative. Quand, occasionnellement, un consensus ne peut être trouvé, le groupe de travail procède alors à un vote.  Ross a remarqué qu’un consensus doit être trouvé (ou, dans le pire des cas, qu’un vote doit être effectué) en moyenne une fois par trimestre au sein des projets en bonne santé.

La conclusion de Ross est simple et à l’image du reste de sa présentation : si vous créez une communauté viable, alors vous créez du code viable.

Enfin, Dave Neary, membre de la communauté GNOME et ancien membre du conseil d’administration de la fondation GNOME, et Ralph Mueller, porte-parole de la fondation Eclipse, se sont livrés à un jeu assez particulier. Alors que le premier évoquait le poison que représentent les « anti-patterns » pour les communautés, le deuxième s’attachait à présenter les remèdes inspirés des meilleurs pratiques de développement.

Parmi les anti-patterns présentés, nous retiendrons le « Cookie Licker » (lécheur de biscuit) qui se rapporte au fait que le propriétaire d’une tâche a tendance à résister lorsqu’un changement (de propriétaire) est demandé ou conseillé. L’image suggérée est simple : si une personne lèche un biscuit et le repose sur la table, personne d’autre ne voudra ensuite le manger. C’est une façon de dire : « je ne peux pas m’occuper de cette tâche tout de suite, mais je me la réserve ». Les symptômes connexes sont l’assignation volontaire de tâches sans concertation et le manque de retours sur avancement. A l’origine du problème, il y a la volonté de bien faire : « je suis le mieux placé pour réaliser cette tâche ». Il y a aussi  le fait que les meilleurs membres ont toujours la fâcheuse tendance au sur-engagement : en s’assignant une tâche, ils pensent vraiment qu’ils pourront se dégager du temps pour la réaliser. Mais entre leur perception à cet instant précis et la réalité, il y a souvent un gouffre. Et le problème est renforcé par le fait qu’une fois l’engagement pris, passer la tâche à quelqu’un d’autre est souvent vécu comme un échec. Les remèdes à cet anti-pattern sont simples : affecter des échéances (« deadlines ») aux tâches, les réassigner lorsque l’échéance est passée, et surtout, faire en sorte de ne pas instaurer un culte de l’échec. Les membres doivent être en confiance même s’ils ne peuvent pas remplir un engagement pour telle ou telle raison. La bonne réaction (celle qu’il faut susciter) est : « OK, je n’ai pas le temps, il vaut mieux que quelqu’un d’autre s’en charge ». La mauvaise réaction (celle qu’il faut éviter) est : « Je n’ai pas eu le temps à cause de l’autre imbécile » (et intérieurement : « zut, j’ai encore merdé »)…

L’anti-pattern suivant est celui du « Help Vampire » (vampire d’aide), dont le symptôme est un membre qui aspire littéralement toute la bande passante des autres membres par ses demandes d’aide et ses questions récurrentes. Là encore, les remèdes à ce poison sont simples et pragmatiques : fournir une documentation à destination des nouveaux membres (et de bonne qualité), expliquer aux nouveaux comment rechercher efficacement des réponses, mais aussi, encourager les  membres récemment arrivés à répondre aux questions des nouveaux membres. Ce dernier conseil s’appuie sur un constat simple : les nouveaux arrivés vont la plupart du temps se poser les mêmes questions.

Il y a ensuite l’anti-pattern du « Headless Chicken » (poulet sans tête), dont le symptôme est un membre en désaccord avec tous les autres membres. Puis, l’anti-pattern connu sous le nom de « Bikeshed Discussion » (discussion sur le hangar à vélo). L’image suggérée par ce dernier est une réunion entre membres hauts placés dans le but de prendre une décision. Si l’on prend les mêmes personnes pour prendre une décision sur un sujet très complexe (par exemple sur des centrales nucléaires) et sur un sujet très simple (par exemple sur la création d’un hangar à vélo), on se rend compte que la plupart du temps, la première décision sera prise très rapidement alors que la seconde pourra venir après des jours de discussion. Cela est lié au niveau de compréhension des personnes impliquées dans la discussion. Dans le cas du hangar à vélo, il y a une tendance à la perte de temps et à la dispersion car on s’attarde sur le moindre détail (par exemple, sur la couleur du hangar à vélo). La solution à ces deux anti-patterns réside dans la capacité à créer une direction de projet, en encourageant les initiatives personnelles et en créant une culture de l’action : c’est en mettant les mains dans le cambouis  qu’on acquiert le bon niveau de compréhension et l’aptitude à discuter des choix avec le recul nécessaire.

Enfin, nous retiendrons l’anti-pattern nommé « Broken Window » (fenêtre cassée). L’image suggérée est celle d’un immeuble aux fenêtres cassées, et on constate souvent que cette vision effraie les gens. Le symptôme est un taux de bruit qui augmente sur les différents canaux d’information du projet. Ce bruit est typiquement provoqué par des discussions hors-sujet (des « bikeshed discussions ») sur les listes de diffusion, du vandalisme ou une mauvaise qualité d’articles sur le wiki ou le blog. Plusieurs solutions existent pour éradiquer ce problème ou au moins limiter ses effets : documenter les bonnes pratiques, rappeler les coupables à l’ordre le plus tôt possible, et répartir équitablement la charge liée à la surveillance et au maintien de l’ordre au sein de l’équipe.

La conclusion qui s’impose est que les communautés sont tout simplement des lieux émotionnels. Il faut faire en sorte que les membres puissent prendre du plaisir dans un environnement sympa et sûr.

Le sentiment qui prédomine au sortir de ces conférences est que les logiciels libres sont à prendre très au sérieux, et que la sphère open source, toujours plus forte, entend bien s’accroître et étendre son influence dans tous les domaines : société, industrie, secteur public, enseignement… Au quotidien, cela se traduit notamment par un dynamisme croissant des communautés open source et un renforcement des liens avec les secteurs éducatif et industriel, souvent au travers de partenariats stratégiques. Il s’agit très clairement d’une vision d’avenir à long terme.

Note : pour aller plus loin, les documents relatifs à la session 2009 sont consultables ici, et ceux de la session 2010 seront probablement mis en ligne sous peu sur le site fOSSa 2010 ou sur slideshare.

  1. Stephane Ribas ;-)
    29/04/2011 à 11:03 | #1

    Très belle article.. je suis scotché :-)

  1. Pas encore de trackbacks