... mais ce serait peut-être l'une des plus grandes opportunités manquées de notre époque si le logiciel libre ne libérait rien d'autre que du code
Le Framablog a pris l’habitude de suivre les travaux de Bernard Stiegler au sein d’Ars Industrialis. Il faut dire que ça n’est pas tous les jours qu’un philosophe affirme que « le logiciel libre peut redonner sens à nos vies » ! Nous … Lire la suite
Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même. Traduction Framalang : ga3lig, lenod, peupleLa, LAuX, billouche, Goofy, jcr83, purplepsycho, Jej, KoS, Julius22, kalupa, tuki, lamessen, okram + Sinma La collaboration entre … Lire la suite
Entre les biens communs et le communisme, y aurait-il davantage qu’une parenté lexicale ? Le logiciel libre libère-t-il plus que le code ? Est-il l’instrument d’une lutte contre le capitalisme monopolistique, ou bien une ressource développée en marge du temps salarié et … Lire la suite
Kevin Ottens
Kevin Ottens est un « hacker » de longue date au sein de la communauté KDE[1]. Il a largement contribué à la plateforme KDE, en particulier à la conception des API et frameworks. Diplômé en 2007, il est titulaire d’un doctorat en informatique qui l’a amené à travailler, en particulier, sur l’ingénierie des ontologies[2] et les systèmes multi-agents. Le travail de Kevin au KDAB inclut le développement de projets de recherche autour des technologies KDE. Il vit toujours à Toulouse, où il est enseignant à mi-temps dans son université d’origine.
Les communautés du Libre sont principalement animées par l’effort de bénévoles. De plus, la plupart des personnes qui s’impliquent dans ces communautés le font lors de leur cursus universitaire. C’est la période idéale pour s’engager dans de telles aventures : on est jeune, plein d’énergie, curieux et l’on veut probablement façonner le monde à son image. Voilà tous les ingrédients d’un bon travail bénévole.
Mais, en même temps, être étudiant ne laisse pas forcément beaucoup de temps pour s’engager dans une communauté du Libre. En outre, la plupart de ces communautés sont assez vastes et les contacter peut faire peur.
Cela soulève évidement une question dérangeante : si les communautés du Libre ne réussissent pas à attirer la nouvelle génération de contributeurs talentueux, est-ce parce qu’elles ne cherchent pas activement à étendre leur activité dans les universités ? Cette question pertinente, nous avons essayé d’y répondre dans le contexte d’une communauté qui produit des logiciels, à savoir KDE. Dans cet article, nous nous concentrerons sur les aspects auxquels nous n’avions pas initialement pensé mais qu’il nous a fallu aborder pour répondre à cette question.
Tout commence, réellement, par le contact avec les étudiants eux-mêmes. Et pour ça, rien de mieux que de se rendre directement dans leur université et de leur montrer à quel point les communautés du Libre peuvent être accueillantes. À cet effet, nous avons construit un partenariat avec l’université Paul Sabatier de Toulouse plus précisément, avec l’un de ses cursus – nommé IUP ISI (NdT : Ingénierie des Systèmes Informatiques) – axé sur le développement logiciel.
L’IUP ISI était très orienté sur les connaissances « pratiques » et avait à ce titre un programme pré-établi pour les projets étudiants. Un point particulièrement intéressant de ce programme est le fait que les étudiants travaillent en équipe « inter-promotions ». Des étudiants de troisième et quatrième années, généralement en équipes de 7 à 10, apprennent à collaborer autour d’un objectif commun.
La première année de notre expérience, nous nous sommes raccrochés à ce programme en proposant de nouveaux sujets pour les projets, et en nous concentrant sur des logiciels développés au sein de la communauté KDE. Henri Massie, directeur du cursus, a très bien accueilli cette idée, et nous a laissés mettre cette expérience en place. Pour cette première année, nous nous sommes vu attribuer deux créneaux horaires pour les « projets KDE ».
Pour créer rapidement un climat de confiance, nous avons décidé, cette année-là, d’offrir quelques garanties concernant le travail des étudiants :
Au moment de l’écriture de ces pages, cela fait cinq ans que nous menons de tels projets. De petits ajustements dans l’organisation ont été apportés ici et là, mais la plupart des idées sous-jacentes sont restées les mêmes. La majorité des changements ont été le résultat d’un intérêt grandissant de la communauté, désireuse d’établir un partenariat avec les étudiants, et d’une plus grande liberté pour nous quant aux sujets que nous pourrions couvrir dans nos projets.
De plus, tout au long de ces années, le directeur nous a donné une aide et des encouragements constants, attribuant effectivement plus de créneaux pour les projets de la communauté du Libre et prouvant que notre stratégie d’intégration était juste : établir de la confiance dès le début est la clé d’un partenariat entre la communauté du Libre et l’Université.
Durant ces années à tisser des liens entre la communauté KDE et la filière IUP ISI, nous nous sommes retrouvés en situation d’enseignement afin d’assister les étudiants dans des tâches liées à leurs projets. Quand vous n’avez jamais enseigné à une classe pleine d’étudiants, vous avez sans doute encore une image de vous, il y a quelques années, assis dans une classe. En effet, la plupart des enseignants ont un jour été étudiants… Parfois même, pas le genre d’étudiant très discipliné ni attentif. Vous aviez sans doute l’impression d’être submergé : l’enseignant entrait dans la salle, faisait face aux étudiants, et déversait sur vous ses connaissances.
Ce stéréotype est ce que la plupart gardent à l’esprit de leurs années d’études et la première fois qu’ils se retrouvent en situation d’enseigner, ils veulent reproduire ce stéréotype : arriver avec un savoir à transmettre.
La bonne nouvelle, c’est que rien n’est plus éloigné de la vérité que ce stéréotype. La mauvaise nouvelle, c’est que si vous essayez de reproduire ce stéréotype, vous allez très probablement faire fuir vos étudiants et ne ferez face qu’à un manque de motivation pour participer à la communauté. L’image que vous donnez de vous est la toute première chose dont ils vont se souvenir de la communauté : la première fois que vous entrez dans la salle de classe, vous êtes, pour eux, la communauté.
Pour éviter de tomber dans le piège de ce stéréotype, il vous faut prendre un peu de recul et réaliser ce que signifie réellement d’enseigner. Ce n’est pas un processus à sens unique où l’on livre la connaissance aux étudiants. Nous sommes arrivés à la conclusion que c’est en fait un processus à double sens : vous êtes amené à créer une relation symbiotique avec vos étudiants. Les étudiants et les enseignants doivent tous sortir de la salle de classe avec de nouvelles connaissances. Il vous faut livrer votre expertise, bien sûr, mais afin de le faire efficacement, vous devez en permanence vous adapter au cadre de référence de vos étudiants. C’est un travail qui rend très humble.
Cette prise de conscience génère pas mal de changements dans la manière d’entreprendre votre enseignement.
Ainsi, vous deviendrez un meilleur enseignant. De plus, vous remplirez mieux vos objectifs : des étudiants bien formés, dont certains s’engageront dans la communauté du Libre.
Au bout du compte, pourquoi feriez-vous tous ces efforts pour établir une relation de confiance avec une université et sortir de votre zone de confort en améliorant votre manière d’enseigner ? Eh bien, cela se résume vraiment à la question initiale à laquelle nous avons tenté de répondre :
Si les communautés du Libre ne réussissent pas à attirer de nouveaux contributeurs venus des universités, est-ce simplement dû à leur inaction ?
D’après notre expérience, la réponse est oui. Au cours de ces cinq années passées à bâtir un partenariat avec l’IUP ISI, nous avons attiré deux étudiants par année en moyenne. Certains d’entre eux nous ont quittés après quelque temps, mais certains sont devenus des contributeurs très actifs. Les autres gardent encore une certaine nostalgie de cette période de leur vie et continuent de nous soutenir même s’ils ne contribuent pas directement. En ce moment même, nous avons une équipe locale KDE qui a réussi à organiser efficacement une conférence de deux jours pour notre dernière « release party » (NdT : soirée de lancement).
Parmi ces anciens étudiants, pas un seul ne se serait impliqué dans le projet KDE sans ces projets universitaires. Nous serions passés complètement à côté de ces talents. Par chance, nous n’avons pas été inactifs.
Traduction Framalang :
par Felipe Ortega
Felipe Ortega est chercheur et chef de projet à Libresoft, un groupe de recherche de l’Université Rey Juan Carlos [1] en Espagne. Il développe de nouvelles méthodologies pour analyser les communautés collaboratives ouvertes (comme les projets de logiciels libres, Wikipédia et les réseaux sociaux). Il a mené des recherches approfondies sur le projet Wikipédia et sa communauté de contributeurs. Felipe participe activement à la recherche, la promotion et l’éducation/formation sur le logiciel libre, plus particulièrement dans le cadre du Master « Logiciel libre » de l’URJC [2]. C’est un fervent défenseur de l’ouverture des ressources éducatives, du libre accès aux publications scientifiques et de l’ouverture des données scientifiques.
Dans son célèbre essai La Cathédrale et le Bazar [1], Eric S. Raymond souligne l’une des plus importantes leçons que chaque développeur doit apprendre : « Un bon logiciel commence toujours par un développeur qui gratte là où ça le démange ». Vous ne pouvez comprendre à quel point cette phrase est vraie avant d’avoir vous-même vécu la situation. En fait, la majorité des programmeurs de logiciels libres et open source (si ce n’est tous) est certainement passée par cette étape où il faut mettre les mains dans le cambouis sur un tout nouveau projet, ou en rejoindre un, désireux d’aider à le rendre meilleur. Cependant, de nombreux développeurs et autres participants dans les communautés libres et open source (rédacteurs de documentation, traducteurs etc.) négligent généralement une autre importante leçon soulignée par Raymond plus loin dans son essai : « Quand un programme ne vous intéresse plus, votre dernier devoir à son égard est de le confier à un successeur compétent ». C’est le thème central que je veux traiter ici. Vous devez penser à l’avenir de votre projet, et aux nouveaux arrivants qui un jour prendront le relais et continueront de le faire avancer.
Tôt ou tard, de nombreux projets libres et open source devront faire face à un relais générationnel. Les anciens développeurs en charge de la maintenance du code et des améliorations finissent par quitter le projet et sa communauté pour des raisons diverses et variées. Il peut s’agir de problèmes personnels, d’un nouveau travail qui ne laisse pas assez de disponibilités, d’un nouveau projet qui démarre, ou du passage à un autre projet qui semble plus attirant… la liste peut être assez longue.
L’étude du relais générationnel (ou renouvellement des développeurs) dans les projets de logiciel libre et open source reste un domaine émergent qui nécessite davantage de recherches pour améliorer notre compréhension de ces situations. En dépit de cela, certains chercheurs ont déjà collecté des preuves objectives qui mettent en lumière certains processus. Pendant l’OSS 2006 (NdT : Conférence sur l’Open Source System [4]), mes collègues Jesús González-Barahona et Gregorio Robles présentèrent un travail intitulé « Le renouvellement des contributeurs dans les projets de logiciel libre ». Dans cette présentation, ils exposèrent une méthodologie pour identifier les développeurs les plus actifs – généralement connus comme les développeurs principaux – à différents moments, pendant toute la durée d’un projet donné. Ils appliquèrent ensuite cette méthode à l’étude de 21 gros projets, en particulier Gimp [5], Mozilla [6] et Evolution [7]. En bref, ils ont découvert qu’on peut distinguer trois types de projets en fonction du taux de renouvellement des développeurs.
Cette classification nous amène à une question évidente : quel est le modèle le plus fréquemment rencontré dans les projets de logiciels libre et open source ? Pour tout dire, les résultats de l’analyse menée sur l’échantillon de 21 projets lors de ces travaux établissent clairement cette conclusion : ce sont les projets à multiples générations, ainsi que les projets composites qui sont les plus communément rencontrés dans l’écosystème des projets libres et open source. Seuls Gnumeric et Mono ont montré un modèle distinct avec une forte rétention d’anciens développeurs, ceci indiquant que les personnes contribuant à ces projets auraient de plus fortes raisons de continuer leurs travaux sur le long terme.
Cependant ce n’est pas le cas le plus courant. Au contraire, cette étude donne plus de légitimité au conseil suivant : nous devons préparer, à plus ou moins long terme, le transfert de notre rôle et de nos connaissances au sein du projet vers les futurs contributeurs qui rejoignent notre communauté.
Toute personne faisant face à un changement significatif dans sa vie doit s’adapter à de nouvelles conditions. Par exemple, quand vous quittez votre emploi pour un autre, vous vous préparez à une période pendant laquelle il vous faudra vous intégrer dans un autre groupe de travail, dans un nouveau lieu. Heureusement, au bout d’un moment vous aurez pris vos marques dans ce nouvel emploi. Mais parfois vous aurez gardé de bons amis de votre ancien boulot, et vous vous reverrez après avoir bougé. Parfois alors, en discutant avec des anciens collègues, vous pourrez savoir ce qu’il est advenu avec la personne recrutée pour vous remplacer. Cela ne se produit que rarement dans les projets open source.
Le revers du relais générationnel dans un projet libre peut apparaitre sous une forme très concrète, à savoir un fossé de connaissances. Quand un ancien développeur quitte le projet, et particulièrement s’il avait une expérience approfondie dans cette communauté, il laisse derrière lui ses connaissances aussi bien concrètes qu’abstraites, qui ne sont pas forcément transmises aux nouveaux venus.
Un exemple évident, est le code source. Comme dans toute production intellectuelle bien faite – du moins, c’est ce à quoi on pourrait s’attendre, non ? – les développeurs laissent une marque personnelle chaque fois qu’ils écrivent du nouveau code. Parfois, vous avez l’impression d’avoir une dette éternelle envers le programmeur qui a écrit ce code élégant et soigné qui parle de lui-même et qui est facile à maintenir. D’autres fois, la situation est inverse et vous bataillez pour comprendre un code très obscur sans un seul commentaire ni indice pour vous aider.
C’est ce que l’on a essayé de mesurer en 2009, dans une recherche présentée à l’HICSS 2009 (NdT : Hawaii International Conference on System Sciences [8]). Le titre en est « Utiliser l’archéologie logicielle pour mesurer les pertes de connaissances provoquées par le départ d’un développeur ». Au cas où vous vous poseriez la question, cela n’a rien à voir avec des histoires de fouet, de trésors, de temples, et autres aventures palpitantes. Ce qui a été mesuré, entre autres choses, c’est le pourcentage de code orphelin laissé par les développeurs ayant quitté des projets libre et/ou open source, et qu’aucun des développeurs actuels n’a encore repris. Pour cette étude, nous avons choisi quatre projets (Evolution, GIMP, Evince et Nautilus) pour tester la méthode de recherche. Et nous sommes arrivés à des résultats assez intéressants.
Evolution présentait une tendance plutôt inquiétante car le taux de code orphelin augmentait au cours du temps. En 2006, près de 80 % de l’ensemble des lignes de code avaient été abandonnées par les précédents développeurs et étaient restées intouchées par le reste de l’équipe. À l’opposé, Gimp affichait un modèle tout à fait différent, avec une volonté claire et soutenue par l’équipe de développement de réduire le nombre de lignes orphelines. Souvenons-nous au passage que Gimp avait déjà été qualifié de projet des dieux du code et bénéficiait donc d’une équipe de développement bien plus stable pour surmonter cette tâche harassante.
Cela signifie-t-il que les développeurs de Gimp avaient une bien meilleure expérience que ceux d’Evolution ? Honnêtement, on n’en sait rien. Néanmoins, on peut prévoir un risque clair : plus le taux de code orphelin est élevé, plus l’effort à fournir pour maintenir le projet est important. Que ce soit pour corriger un bogue, développer une nouvelle fonctionnalité ou en étendre une préexistante, il faut faire face à du code que l’on n’a jamais vu auparavant. Bien sûr les programmeurs d’exception existent, mais peu importe à quel point l’on est merveilleux, les développeurs de Gimp ont un avantage certain ici, puisqu’ils ont quelqu’un dans l’équipe qui a une connaissance précise de la majorité du code à maintenir. De plus, ils travaillent à réduire la portion de code inconnu au cours du temps.
Ce qui est intéressant, c’est que certains projets parviennent à retenir les utilisateurs sur des périodes bien plus longues qu’on aurait pu s’y attendre. Là encore, nous pouvons trouver des preuves empiriques justifiant cette déclaration. Pendant l’OSS 2005 [9], Michlmayr, Robles et González-Barahona présentèrent des résultats pertinents concernant cet aspect. Ils étudièrent la persistance de la participation des responsables de logiciels sur Debian en calculant ce qu’on appelle la demi-vie. C’est le temps nécessaire à une population donnée de développeurs principaux pour perdre la moitié de sa taille initiale. Le résultat fut que la demi-vie estimée des responsables Debian était approximativement de 7 ans et demi. En d’autres termes, l’étude ayant été menée sur une période de six ans et demi (entre juillet 1998 et décembre 2004), donc depuis Debian 2.0 jusqu’à Debian 3.1 (versions stables uniquement), plus de 50 % des responsables de Debian 2.0 contribuaient encore à Debian 3.1.
Debian a créé une sorte de procédure très formelle pour accepter de nouveaux codeurs logiciels (aussi connus sous le nom de développeurs Debian) qui inclut l’acceptation du Contrat Social Debian et la démonstration d’une bonne connaissance de la Politique Debian. Résultat, on peut s’attendre à avoir des contributeurs très engagés. C’est en effet le cas, puisque les auteurs de l’étude ont constaté que les paquets délaissés par les anciens développeurs étaient généralement repris par d’autres développeurs de la communauté. C’est seulement dans le cas où le paquet n’était plus utile qu’il a été abandonné. Je pense que nous pouvons tirer quelques conclusions de ces travaux de recherche :
Je reconnais que ce n’est pas très facile de penser à ses successeurs lorsque vous programmez. La plupart du temps, vous ne vous rendez tout simplement pas compte que votre code pourrait à la fin être repris par un autre projet, réutilisé par d’autres personnes ou que vous pourriez éventuellement être remplacé par un autre, qui continuera votre travail après vous. Cependant, le plus remarquable atout des logiciels libres et open source est précisément celui-là : le code sera réutilisé, adapté, intégré ou exporté par quelqu’un d’autre. La maintenance est une composante essentielle de l’ingénierie logicielle. Mais cela devient primordial dans le cas des logiciels libres et open source. Ce n’est pas seulement une question de code source. Cela concerne aussi les relations humaines et la netiquette. C’est quelque chose qui va au-delà du bon goût. Quod severis metes (« On récolte ce que l’on a semé »). Souvenez-vous en. La prochaine fois, vous pourriez être le nouveau venu qui viendra combler le vide de connaissance laissé par un ancien développeur.
[2] http://www.urjc.es/estudios/masteres_universitarios/ingenieria/software_libre/index.htm
[3] http://www.linux-france.org/article/these/cathedrale-bazar/cathedrale-bazar.html
[5] logiciel de création graphique, http://www.gimp.org
[6] https://www.mozilla.org/fr/firefox/fx/
[7] logiciel de messagerie, http://projects.gnome.org/evolution
[8] archives de la conférence, http://www.informatik.uni-trier.de/~ley/db/conf/hicss/hicss2009.html
Conflit de génération sur le Web… Les pères fondateurs avaient imaginé un réseau ouvert, génératif, bidouillable. Ils sont aujourd’hui amers de constater que le Web est devenu un adolescent qui loin de chercher à émanciper ses utilisateurs, tente plutôt de … Lire la suite
Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même. Libres conseils (1/42) Traduction framalang peupleLa, tibs, Astalaseven, aKa, lerouge, Vilnus Atyx, liu qihao, Cyrille L., Khyvodul, jcr83, jcr83, Goofy, Gatien Bovyn, … Lire la suite
Les entreprises utilisant et fabriquant du logiciel libre à destination des écoles primaires sont rares. Il faut reconnaître que le marché est compliqué et beaucoup plus difficile à conquérir puisqu’il faut démarcher chaque mairie là où les conseils généraux suffisent … Lire la suite