Traduction Framalang : ga3lig, Coco, Aa, Lignusta, goofy, jcr83, peupleLa (relectures), Sylvain, CoudCoud, lamessen + Julius22

Préparez-vous pour le futur : l’évolution des équipes dans le logiciel libre et open source

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.

Le relais entre les générations

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.

• Les projets avec des dieux du code : ces projets reposent en grande partie sur le travail de leurs fondateurs et le relais générationnel est très faible, voire nul. Gimp se classe dans cette catégorie.

• Les projets avec de multiples générations de codeurs : des projets comme Mozilla montrent clairement un modèle de renouvellement des développeurs, avec de nouveaux groupes actifs qui prennent en main la gestion du développement et de la maintenance du code des mains mêmes du noyau des anciens contributeurs.

• Les projets composites : Evolution appartient à une troisième catégorie de projets ; il connaît un certain taux de renouvellement, mais celui-ci n’est toutefois pas aussi marqué que pour les projets de la catégorie précédente, parce qu’atténué par la rétention de certains des principaux contributeurs au cours de l’histoire du projet.

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é.

Le fossé de connaissances

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.

C’est comme à la maison

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 :

1. Passez du temps à développer les principales lignes directrices de votre projet. Cela peut commencer par un seul et court document, qui détaille simplement des recommandations et des bonnes pratiques. Cela peut évoluer à mesure que le projet grandit, et permettre aux nouveaux arrivants tant de saisir rapidement les valeurs principales de votre équipe, qu’à comprendre les traits principaux de votre méthodologie.
2. Forcez-vous à suivre des standards de codage, des bonnes pratiques et un style élégant. Documentez votre code. Insérez des commentaires pour décrire les sections qui seraient particulièrement difficiles à comprendre. Ne pensez pas que c’est du temps perdu. En fait, vous faites preuve de pragmatisme en investissant du temps dans l’avenir de votre projet.
3. Dans la mesure du possible, lorsque le moment vient pour vous de quitter le projet, essayez d’avertir les autres de cette décision longtemps à l’avance. Assurez-vous qu’ils comprennent quelles parties essentielles du code nécessiteront un nouveau développeur pour le maintenir. Idéalement, si vous formez une communauté, préparez au moins une procédure simple afin d’automatiser la transition, et assurez-vous de n’oublier aucun point important avant que la personne ne quitte le projet (particulièrement si celle-ci est un développeur clé).
4. Gardez un œil sur la quantité de code orphelin. Si celle-ci augmente trop rapidement, ou si elle atteint une trop grande proportion de votre projet, cela indique clairement que vous allez avoir des problèmes dans peu de temps, en particulier si le nombre de rapports de bogues augmente ou si vous envisagez une nouvelle implémentation de votre code avec de fortes modifications.
5. Assurez-vous de toujours laisser assez d’astuces et de commentaires pour qu’à l’avenir un nouvel arrivant puisse s’approprier votre travail.

J’aurais voulu savoir que vous arriviez (avant de partir)

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.

[1] http://www.urjc.es

[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

[4] http://oss2006.org

[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

[9] http://oss2005.case.unibz.it

Traduction Framalang : ga3lig, Coco, Aa, Lignusta, goofy, jcr83, peupleLa (relectures), Sylvain, CoudCoud, lamessen + Julius22

Préparez-vous pour le futur : l’évolution des équipes dans le logiciel libre et open source

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.

Le relais entre les générations

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.

• Les projets avec des dieux du code : ces projets reposent en grande partie sur le travail de leurs fondateurs et le relais générationnel est très faible, voire nul. Gimp se classe dans cette catégorie.

• Les projets avec de multiples générations de codeurs : des projets comme Mozilla montrent clairement un modèle de renouvellement des développeurs, avec de nouveaux groupes actifs qui prennent en main la gestion du développement et de la maintenance du code des mains mêmes du noyau des anciens contributeurs.

• Les projets composites : Evolution appartient à une troisième catégorie de projets ; il connaît un certain taux de renouvellement, mais celui-ci n’est toutefois pas aussi marqué que pour les projets de la catégorie précédente, parce qu’atténué par la rétention de certains des principaux contributeurs au cours de l’histoire du projet.

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é.

Le fossé de connaissances

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.

C’est comme à la maison

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 :

1. Passez du temps à développer les principales lignes directrices de votre projet. Cela peut commencer par un seul et court document, qui détaille simplement des recommandations et des bonnes pratiques. Cela peut évoluer à mesure que le projet grandit, et permettre aux nouveaux arrivants tant de saisir rapidement les valeurs principales de votre équipe, qu’à comprendre les traits principaux de votre méthodologie.
2. Forcez-vous à suivre des standards de codage, des bonnes pratiques et un style élégant. Documentez votre code. Insérez des commentaires pour décrire les sections qui seraient particulièrement difficiles à comprendre. Ne pensez pas que c’est du temps perdu. En fait, vous faites preuve de pragmatisme en investissant du temps dans l’avenir de votre projet.
3. Dans la mesure du possible, lorsque le moment vient pour vous de quitter le projet, essayez d’avertir les autres de cette décision longtemps à l’avance. Assurez-vous qu’ils comprennent quelles parties essentielles du code nécessiteront un nouveau développeur pour le maintenir. Idéalement, si vous formez une communauté, préparez au moins une procédure simple afin d’automatiser la transition, et assurez-vous de n’oublier aucun point important avant que la personne ne quitte le projet (particulièrement si celle-ci est un développeur clé).
4. Gardez un œil sur la quantité de code orphelin. Si celle-ci augmente trop rapidement, ou si elle atteint une trop grande proportion de votre projet, cela indique clairement que vous allez avoir des problèmes dans peu de temps, en particulier si le nombre de rapports de bogues augmente ou si vous envisagez une nouvelle implémentation de votre code avec de fortes modifications.
5. Assurez-vous de toujours laisser assez d’astuces et de commentaires pour qu’à l’avenir un nouvel arrivant puisse s’approprier votre travail.

J’aurais voulu savoir que vous arriviez (avant de partir)

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.

[1] http://www.urjc.es

[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

[4] http://oss2006.org

[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

[9] http://oss2005.case.unibz.it

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 les forcer dans des cases, de les infantiliser, de ne leur laisser aucun contrôle.

Le constat dressé la semaine dernière par Anil Dash a depuis été largement partagé par les vétérans du Web. Comme l’impression d’un paradis perdu.

Mais la roue tourne et les utopistes des débuts rêvent d’un retour aux sources, d’éduquer les milliards de nouveaux internautes, de leur faire partager leur rêve. Est-ce envisageable ? Surtout, même s’ils prenaient conscience des valeurs que portait le Web à ses débuts, la majorité des utilisateurs serait-elle prête à abandonner ses usages confortables actuels pour reprendre le flambeau des fondateurs et à explorer de nouvelles voies respectueuses de ces valeurs ?

Le retour au bricolage high-tech avec un fer à souder allié au code (Ardhuino, imprimantes 3D, FabLabs…), les initiatives comme celles du projet Webmakers qui vise à éduquer au Web toute une génération pour qu’elle s’en empare au lieu de le consommer, autant de signes d’une prise de conscience qui pourrait modifier la donne. Cet article qui lance un coup d’œil dans le rétroviseur n’est pas un moment de simple nostalgie mais une invitation au renouvellement des idéaux fondateurs.

Le Web que nous avons perdu

article original The Web We Lost par Anil Dash, proposé et présenté par Clochix

Traduction framalang Zii, KoS, Goofy, Garburst, lamessen

L’industrie technologique et sa presse ont traité l’explosion des réseaux sociaux et l’omniprésence des applications pour smartphone comme une victoire sans appel pour Monsieur Tout-le-monde, un triomphe de la convivialité et de l’autonomisation. On a moins parlé de ce que nous avons perdu tout au long de cette transition, et je trouve que les jeunes générations ne savent même pas comment était le Web autrefois.
Alors voici quelques aperçus d’un Web qui pour l’essentiel a disparu :

• Il y a 5 ans, la plupart des photos qu’on voulait partager étaient chargées sur Flickr, où elles pouvaient être taguées par les humains ou même par les applications et services, en utilisant un système de balises. Les images étaient facilement accessibles sur le Web, en utilisant de simples flux RSS. Et les photos chargées pouvaient facilement l’être sous des licences permissives comme celles fournies par Creative Commons, autorisant la modifications et la réutilisation de n’importe quelle façon par des artistes, des entreprises ou des particuliers.

• Il y a une dizaine d’années, Technorati vous laissait chercher sur la majeure partie du Web social en temps réel (cependant la recherche avait tendance à être horriblement longue pour l’affichage des résultats), avec des tags qui marchaient comment le font les hashtags sur Twitter aujourd’hui. Vous pouviez trouver des sites en relation avec votre contenu avec une simple recherche, et savoir qui s’exprimait dans un fil de discussion, indépendamment des outils ou plateformes utilisés pour exposer des idées. À l’époque, c’était tellement excitant que lorsque Technorati ne put faire face au volume croissant de la blogosphère, les utilisateurs furent très déçus. Au point que même quelqu’un d’aussi habituellement circonspect que Jason Kottke se mit à descendre le service en flammes pour l’avoir laissé tomber. Dès l’instant de ses premiers succès pourtant, Technorati avait suscité les louanges de gens comme John Gruber :

Vous pouviez, en théorie, écrire un logiciel pour examiner le code source des quelques centaines de milliers de blogs, et créer une base de données des liens entre ces blogs. Si votre logiciel était assez efficace, il devait pouvoir rafraîchir ses informations d’heure en heure, ajoutant de nouveaux liens à sa base de données en quasi-temps réel. En fait, c’est exactement ce qu’a créé Dave Sifry avec son incroyable Technorati. À ce jour, Technorati surveille 375 000 blogs et a référencé plus de 38 millions de liens. Si vous n’avez jamais joué avec Technorati, vous manquez quelque chose.

• Il y a dix ans, vous pouviez laisser les gens poster des liens sur votre site ou montrer des listes de liens qui pointaient vers votre site. Car Google n’avait pas encore introduit AdWords et AdSense, les liens ne généraient pas de revenus, c’était juste un moyen d’expression ou un outil éditorial. Le Web était un endroit intéressant et différent avant la monétisation des liens, mais en 2007 il devint clair que Google avait changé le Web pour toujours, et pour le pire, en corrompant les liens.

• En 2003, si vous aviez introduit un service d’authentification individuelle opéré par une société, même en documentant le protocole et encourageant les autres à cloner le service, vous auriez été décrit comme quelqu’un qui introduisait un système de surveillance relevant du « Patriot Act ». Il y avait une telle méfiance à l’égard services d’authentification que même Microsoft abandonna ses tentatives de créer un tel système d’inscription. Même si leur expérience utilisateur n’était pas aussi simple que la possibilité omniprésente de s’identifier avec Facebook ou Twitter, le service TypeKey introduit alors avait des conditions légales de partage des données bien plus restrictives. Et pratiquement tous les systèmes qui fournissaient une identité aux utilisateurs autorisaient l’usage de pseudonymes, respectant le besoin qu’ont les gens de ne pas toujours se servir de leur identité légale.

• Au début de ce siècle, si vous aviez créé un service qui permettait aux utilisateurs de créer ou partager du contenu, ils s’attendaient à pouvoir facilement télécharger une copie fidèle de leurs données, ou importer leurs données vers d’autres services compétitifs, sans la moindre restriction. Les entreprises commerciales passaient des années à travailler sur l’interopérabilité autour des échanges de données simplement pour le bénéfice de leurs utilisateurs, quitte à lever théoriquement les barrières pour l’entrée de la concurrence.

• Aux premiers temps du Web social, il était largement admis que de simples gens pourraient être propriétaires de leur identité en ayant leurs propres sites, plutôt que d’être dépendants de quelques gros sites pour héberger leur identité numérique. Dans cette vision, vous possédez votre nom de domaine et contrôlez complètement son contenu, plutôt que d’avoir les mains liées sur un site géré par une grande entreprise. C’était une réaction sensée lorsqu’on prenait conscience que la popularité des gros sites croît et chute, mais que les gens ont besoin d’une identité plus persistante que ces sites.

• Il y a cinq ans, si vous vouliez publier sur votre site du contenu d’un autre site ou d’une application, vous pouviez le faire en utilisant un format simple et documenté, sans avoir besoin de négocier un partenariat ou un accord contractuel entre les sites. L’expérience des utilisateurs n’était donc pas soumise aux caprices des luttes politiques entre les sociétés, mais basée sur l’architecture extensible du Web lui-même.

• Il y a une douzaine d’années, lorsque les gens voulaient soutenir les outils de publication qui symbolisaient cet état d’esprit, ils mutualisaient le coût des serveurs et des technologies nécessaires à ces outils, même si cela coûtait bien plus cher avant l’avènement de l’informatique dans le nuage et la baisse du prix de la bande passante. Leurs pairs de l’univers des technologies, même s’ils étaient concurrents, participaient même à cet effort.

Ce n’est pas notre Web aujourd’hui. Nous avons perdu les éléments-clés auxquels nous faisions confiance et pire encore, nous avons abandonné les valeurs initiales qui étaient le fondement du monde du Web. Au crédit des réseaux sociaux actuels, ils ont apporté des centaines de millions de nouveaux participants sur ces réseaux, et ils ont sans doute rendu riche une poignée de personnes. Mais ils n’ont pas montré le Web lui-même, le respect et l’attention qu’il mérite comme le support qui leur a permis de réussir. Et ils sont maintenant en train de réduire les possibilité du Web pour une génération entière d’utilisateurs qui ne comprennent pas à quel point leur expérience pourrait être beaucoup plus innovante et significative.

Retour vers le futur

Aujourd’hui, lorsque vous voyez des compilations intéressantes d’informations, elles utilisent encore souvent des photos de Flickr, parce qu’il n’y a pas grand-chose à faire avec les maigres métadonnées d’Instagram, et qu’Instagram n’utilise le Web qu’à contre-cœur. Lorsque nous ne pouvons pas retrouver d’anciens messages sur Twitter ou nos propres publications sur Facebook, nous trouvons des excuses aux sites alors que nous avions de meilleurs résultats avec une recherche sur Technorati, qui n’avait portant à sa disposition que de piètres logiciels de son époque. Nous assistons à de stupides combats de coqs avec Tumblr qui ne peut pas récupérer la liste de vos contacts sur Twitter, ou Facebook qui refuse que les photos d’Instagram s’affichent sur Twitter, tout cela parce que des entreprises géantes suivent chacune leur propre programme de développement au lieu de collaborer pour être utiles aux utilisateurs. Et nous nous coltinons une génération de patrons qui sont incités à créer des produits toujours plus bornés et hostiles au Web, tout cela pour permettre à un petit nombre de nantis de devenir toujours plus riches, au lieu de laisser les gens se créer de nouveaux possibles innovantes au dessus du Web lui-même.

Je ne m’inquiète pas, nous allons corriger tout cela. L’industrie technologique, comme toutes les industries, suit des cycles, et le pendule est en train de revenir vers les philosophies globales et émancipatrices sur lesquelles le Web social s’est bâti au début. Mais nous allons devoir affronter un gros défi, ré-éduquer un milliard d’utilisateurs pour leur apprendre ce qu’est le Web, comme nous l’avons fait pendant des années il y a dix ans quand tout le monde a quitté AOL, leur apprendre qu’il y a bien plus à expérimenter sur Internet que ce qu’ils connaissent.

Ce n’est pas ici la polémique habituelle à base de : « ces réseaux verrouillés sont mauvais ». Je sais que Facebook, Twitter, Pinterest, LinkedIn et tous les autres sont de super-sites, qui apportent beaucoup à leurs utilisateurs. D’un point de vue purement logiciel, ce sont de magnifiques réussites. Mais ils sont basés sur quelques hypothèses qui ne sont pas forcément exactes. La première idée fausse d’où découlent beaucoup de leurs erreurs est que donner aux utilisateurs de la flexibilité et du contrôle crée forcément une expérience utilisateur complexe qui empêche leur croissance. La seconde hypothèse erronée, plus grave encore, est de penser qu’exercer un contrôle total sur les utilisateurs est le meilleur moyen de maximiser les profits et la rentabilité de leur réseau.

La première étape pour les détromper, c’est que les gens qui sont en train de créer la prochaine génération d’applications sociales apprennent un peu d’histoire, pour savoir de quoi ils parlent, qu’il s’agisse du modèle économique de Twitter, des fonctions sociales de Google ou de n’importe quoi d’autre. Nous devons savoir ce qui a été essayé et a échoué, quelles bonnes idées étaient tout simplement en avance sur leur temps, et quelles occasions ont été gâchées par la génération actuelle de réseaux sociaux dominants.

Qu’est-ce que j’oublie ? Qu’avons-nous perdu d’autre sur le Web social ?

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, Antoine, lamessen, AlBahtaar + 2 anonymes

Première Partie, Idées et innovations

1. Du code avant toute chose

Armijn Hemel a utilisé des logiciels libres depuis 1994, lorsque son frère est revenu à la maison avec une pile de disquettes contenant l’une des premières versions de FreeBSD. Un an après, il migrait vers GNU/Linux, et depuis il n’utilise plus que des systèmes de type Unix, que ce soit chez lui, pour ses études à l’université d’Utrecht ou au travail. Depuis 2005, Armijn est membre du noyau dur de l’équipe de gpl-violations.org tout en possédant son propre cabinet de conseil (Tjaldur Software Governance Solutions) spécialisé dans la détection et la résolution de litiges nés de violations de licences GPL.

En 1999, je faisais tout juste mes premiers pas dans l’activisme du logiciel libre et Open Source. J’utilisais déjà Linux et FreeBSD depuis un certain nombre d’années, mais je n’étais encore qu’un simple utilisateur et je souhaitais apporter une contribution en retour. De mon point de vue, la meilleure manière de le faire était d’écrire du code. Étant donné que je ne trouvais aucun projet existant dans lequel j’aurais été à l’aise pour travailler, j’ai décidé de commencer mon propre projet. Avec le recul, je constate que plusieurs raisons m’ont poussé à débuter ce projet. L’une tenait à mes doutes sur le fait que mon code était d’une qualité suffisante pour être accepté dans un projet existant (je n’étais pas un programmeur brillant et d’ailleurs je ne le suis toujours pas), alors que pour un projet personnel, la question ne se pose pas. La seconde raison est certainement l’arrogance de la jeunesse.

Mon idée était de créer un logiciel de présentation, qui pourrait imiter la plupart des fonctionnalités les plus avancées (ou si vous préférez, les plus pénibles) de PowerPoint. À ce moment-là, OpenOffice.org n’existait pas et le choix était relativement limité : LaTeX et MagicPoint, qui sont davantage orientés vers le contenu textuel que sur les effets d’animation. Je voulais créer un logiciel multi-plateforme, et j’ai pensé que pour remplir cet objectif Java serait le meilleur choix.

Le concept était de faire un logiciel de présentation, écrit en Java, qui aurait intégré tous ces effets animés. Je me suis décidé et j’ai commencé le projet.

Toute l’infrastructure nécessaire était déjà disponible : une liste de diffusion, un site web, un système de gestion de versions (CVS). Mais il n’existait aucun code source qui aurait permis à des contributeurs potentiels de travailler directement . La seule chose en ma possession, c’était quelques idées de ce que je voulais faire, une démangeaison à soulager, et des slogans publicitaires séduisants. Je voulais en fait que beaucoup de gens rejoignent le projet pour que celui-ci devienne réellement un projet collaboratif.

J’ai commencé par faire des plans (avec mes nouvelles connaissances en UML) et à les faire circuler. Rien ne s’est passé. J’ai essayé d’impliquer des contributeurs, mais créer une architecture de manière collaborative est très difficile (sans compter qu’a priori, ce n’est sûrement pas le meilleur moyen de créer un logiciel). Après un certain temps, j’ai laissé tomber et le projet est mort en silence, sans qu’une seule ligne de code ait été écrite. Chaque mois je recevais des messages par la liste de diffusion qui me rappelaient que ce projet avait un jour existé, j’ai donc demandé sa mise hors-ligne.

J’en ai tiré une leçon précieuse, quoiqu’un peu douloureuse : dès lors que vous annoncez quelque chose et que vous souhaitez que les gens s’impliquent dans votre projet, assurez-vous au moins qu’il y ait un minimum de code disponible. Peu importe qu’il ne soit pas complètement terminé ; il est acceptable même s’il est mal dégrossi (au début en tout cas). Mais au moins cela démontre l’existence d’une base sur laquelle des contributeurs peuvent travailler et ainsi l’améliorer. Dans le cas contraire, votre projet finira de la même manière que tant d’autres, dont le mien : aux oubliettes.

Finalement, j’ai trouvé mon créneau pour contribuer au progrès du logiciel libre et open source, en m’assurant que les fondements légaux de ceux-ci restent protégés par l’intermédiaire du projet gpl-violations.org. Rétrospectivement, je n’ai jamais utilisé — sans en éprouver de frustration d’ailleurs — les effets animés dans les logiciels de présentation. En fait, je les trouve de plus en plus irritants, ils nous distraient trop du contenu. Pour faire mes présentations, je suis un utilisateur heureux de LaTeX Beamer et occasionnellement — mais avec moins de plaisir — d’OpenOffice.org/LibreOffice.

Crédit photo vampir 42 (CC-BY-SA)

Qui n’a pas son projet libre ?

Plus qu’une mode ou un engouement passager, c’est un véritable mouvement de fond depuis quelques années : toute une communauté qui crée, échange, élabore, donne et reçoit des contributions, enfourche de nouveaux projets…

Fort bien, mais…

SourceForge récemment et Github aujourd’hui sont de véritables cimetières de projets libres et open source qui n’ont jamais trouvé d’audience, d’équipe de développement, de communauté active. Rien de bien tragique là-dedans. On peut estimer que ces plateformes sont pour beaucoup de libristes une sorte de terrain de jeu, de laboratoire, d’incubateur où le code et sa documentation s’expérimentent par à-coups, avec l’enthousiasme et l’énergie de ceux qui s’emparent d’un outil pour le mettre au service de leur créativité. Un excellent moyen d’apprendre en faisant finalement, à code ouvert. Et qu’importe alors l’absence d’aboutissement dans 80% des cas puisque c’est la démarche qui a été formatrice.

Cependant vous pouvez avoir envie de dépasser le stade du hobbyiste sympathique qui va bricoler son génial projet dans son coin. Vous pouvez avoir le désir de mettre toutes le chances de votre côté pour que le projet libre aboutisse vraiment, gagne en notoriété, entre dans une logique commerciale, vous procure amour, gloire et beauté.

C’est précisément l’intérêt du feuilleton dont vous allez déguster les épisodes semaine après semaine.

42 auteurs vous feront partager leur expérience, avec sérieux et humour, vous raconteront leurs ratages et leurs succès, vous diront comment éviter les uns et atteindre les autres. Des principes, des recommandations mais aussi des trucs et des ficelles, bref une ribambelle chatoyante de libres conseils.

Chaque semaine ou presque, l’équipe framalang vous proposera un nouvel épisode traduit du livre électronique en anglais Open Advice.

Chaque semaine — top départ chaque jeudi soir à 21h — une ou deux tranches du gâteau seront proposées à la traduction collaborative sur un framapad, donc en libre accès pour tous ceux qui souhaitent y contribuer. Participez à l’aventure !

La version que nous publierons ensuite ici même, comme dans le premier échantillon ci-dessous qui est une sorte de préambule, est un premier état de la traduction (donc évidemment perfectible), l’étape suivante sera une révision générale de tous les articles pour les joindre en un Framabook à venir.

Eh oui ça se passe comme ça chez Frama !

Les traducteurs de ce premier round d’échauffement :

peupleLa, Astalaseven, Hideki, Vilnus Atyx, liu qihao, Cyrille L., Khyvodul, jcr83, Slystone, schap2, 4nti7rust, Goofy, Antoine, lamessen + 4 anonymes

Libres Conseils

Logiciels libres et open source : ce que nous aurions aimé savoir avant de commencer

Open Advice est une base de connaissances provenant d’une grande variété de projets de logiciels libres. Elle répond à des questions dont 42 contributeurs majeurs auraient aimé connaître les réponses lorsqu’ils ont débuté. Vous aurez ainsi une longueur d’avance quelle que soit la façon dont vous contribuez et quel que soit le projet que vous avez choisi.

Les projets de logiciels libres modifient le paysage du logiciel de façon impressionnante grâce à des utilisateurs dévoués et une gestion innovante. Chacun apporte quelque chose au mouvement à sa façon, avec ses capacités et ses connaissances. Cet engagement personnel et la puissance du travail collaboratif sur Internet donnent toute leur force aux logiciels libres et c’est ce qui a rassemblé les auteurs de ce livre.

Ce livre est la réponse à la question « Qu’auriez-vous aimé savoir avant de commencer à contribuer ? » Les auteurs offrent un aperçu de la grande variété de talents qu’il faut rassembler pour réussir un projet de logiciel : le codage bien sûr, mais aussi le design, la traduction, le marketing et bien d’autres compétences. Nous sommes là pour vous donner une longueur d’avance si vous êtes nouveau. Et si ça fait déjà un moment que vous contribuez, nous sommes là pour vous donner un aperçu d’autres domaines et projets.

pour les géants et ceux qui se tiendront sur leurs épaules [1] 

Avant-propos

Ce livre parle de communauté et de technologies. Il est le fruit d’un travail collectif, un peu comme la technologie que nous construisons ensemble. Si c’est votre première rencontre avec notre communauté, vous pourrez trouver étrange de penser qu’une communauté puisse être le moteur qui propulse la technologie. La technologie n’est-elle pas l’œuvre des grands groupes industriels ? En fait, pour nous c’est presque l’inverse. Les auteurs de ce livre sont tous membres de ce que vous pourriez appeler la communauté du logiciel libre. Un groupe de personnes qui partagent l’idée fondatrice que les logiciels sont plus puissants, plus utiles, plus flexibles, mieux contrôlables, plus justes, plus englobants, plus durables, plus efficaces, plus sûrs et finalement simplement meilleurs quand ils sont fournis avec les quatre libertés fondamentales : la liberté d’utiliser, la liberté d’étudier, la liberté de partager et la liberté d’améliorer le logiciel.

Et bien qu’il y ait maintenant un nombre croissant de communautés qui ont appris à se passer de la proximité géographique grâce aux moyens de communication virtuels, c’est cette communauté qui en a été le précurseur.

En fait, Internet et la communauté du logiciel libre[2] suivaient des développements mutuellement dépendants. Au fur et à mesure qu’Internet grandissait, notre communauté pouvait grandir en même temps. Mais sans les valeurs ni la technologie qu’apportait notre communauté, il ne fait aucun doute à mes yeux que jamais Internet n’aurait pu devenir ce réseau global reliant les personnes et les groupes du monde entier.

À ce jour, nos logiciels font fonctionner la majeure partie d’Internet, et vous devez en connaitre au moins quelques-uns, comme Mozilla Firefox, OpenOffice.org, Linux, et peut-être même Gnome ou KDE. Mais notre technologie peut aussi se cacher dans votre téléviseur, votre routeur sans fil, votre distributeur automatique de billets, et même votre radio, système de sécurité ou bataille navale. Elle est littéralement omniprésente.

Ils ont été essentiels dans l’émergence de quelques-unes des plus grandes sociétés que vous connaissez, comme Google, Facebook, Twitter et bien d’autres. Aucune d’entre elles n’aurait pu accomplir autant en si peu de temps sans le pouvoir du logiciel libre qui leur a permis de monter sur les épaules de ceux qui étaient là avant eux. Mais il existe également de nombreuses petites entreprises qui vivent de, avec, et pour le logiciel libre, dont la mienne, Kolab Systems. Le fait d’agir activement avec la communauté et dans un bon esprit est devenu un élément de succès essentiel pour nous tous. Et c’est aussi vrai pour les plus grosses, comme Oracle nous l’a involontairement démontré durant et après sa prise de contrôle de Sun Microsystems. Il est important de comprendre que notre communauté n’est pas opposée au commerce. Nous aimons notre travail, et beaucoup d’entre nous en ont fait leur métier pour gagner leur vie et rembourser leurs crédits. Donc quand nous parlons de communauté, nous voulons dire des étudiants, des entrepreneurs, des développeurs, des artistes, des documentalistes, des professeurs, des bricoleurs, des hommes d’affaires, des commerciaux, des bénévoles et des utilisateurs. Oui, des utilisateurs. Même si vous ne vous en êtes pas encore rendu compte ou n’avez jamais appartenu à une communauté, vous faites en réalité déjà partie de la nôtre. La question est de savoir si vous allez y participer activement. Et c’est cela qui nous différencie des poids lourds de la monoculture, des communautés fermées, des jardins clôturés de sociétés telles qu’Apple, Microsoft et d’autres. Nos portes sont ouvertes. Tout comme nos conseils. Et également notre potentiel. Il n’y a pas de limite à ce que vous pouvez devenir — cela dépend uniquement de votre choix personnel comme cela a été le cas pour chacun d’entre nous.

Donc si vous ne faites pas encore partie de notre communauté, ou si vous êtes simplement curieux, ce livre offre un bon point de départ. Et si vous êtes déjà un participant actif, ce livre pourrait vous offrir un aperçu de quelques facettes et de quelques perspectives qui seront nouvelles pour vous.

En effet, ce livre contient d’importantes graines de ce savoir implicite que nous avons l’habitude de construire et de transférer à l’intérieur de nos sous-communautés qui travaillent sur diverses technologies. Ce savoir circule généralement des contributeurs les plus expérimentés vers les moins expérimentés. C’est pourquoi il semble tellement évident et naturel à ceux qui fréquentent notre communauté. Ce savoir et cette culture de la collaboration nous permettent de créer d’extraordinaires technologies avec de petites équipes du monde entier au-delà des différences culturelles, linguistiques et de nationalité. Cette manière de fonctionner permet de surpasser des équipes de développement bien plus grandes de certaines des plus grosses sociétés au monde. Tous les contributeurs de ce livre ont une expérience solide dans au moins un domaine, parfois plusieurs. Ils sont devenus des enseignants et des mentors. Au cours des quinze dernières années, j’ai eu le plaisir d’apprendre à connaître la plupart d’entre eux, de travailler avec beaucoup, et j’ai le privilège de compter certains parmi mes amis.

Comme l’a dit judicieusement Kévin Ottens pendant le Desktop Summit 2011 à Berlin, « construire une communauté, c’est construire de la famille et de l’amitié ».

C’est donc en réalité avec un profond sentiment de gratitude que je peux dire qu’il n’y a aucune autre communauté dont je préférerais faire partie, et je suis impatient de vous rencontrer à l’une ou l’autre des conférences à venir.

— Georg Greve

Zürich, Suisse, le 20 août 2011

Georg Greve a fondé la Free Software Foundation Europe (FSFE) en 2000 et en a été le président fondateur jusqu’en 2009. Durant cette période, il a été responsable du lancement et du développement de nombreuses activités de la FSFE, telles que les alliances, la politique ou les travaux juridiques. Il a intensivement travaillé avec de nombreuses communautés. Aujourd’hui, il poursuit ce travail en tant qu’actionnaire et PDG de Kolab Systems AG, une société qui se consacre entièrement aux logiciels libres. Pour ses actions en faveur du logiciel libre et des standards ouverts, Georg Greve a été décoré de la croix fédérale du mérite (Bundesverdienstkreuz am Bande) par la République Fédérale d’Allemagne le 18 décembre 2009. Thank You! Merci !

Ce livre n’aurait pu voir le jour sans la participation de chaque auteur et des personnes suivantes, qui ont aidé à sa réalisation :

Anne Gentle (relecture)

Bernhard Reiter (relecture)

Celeste Lyn Paul (relecture)

Daniel Molkentin (mise en page)

Debajyoti Datta (site internet)

Irina Rempt (relecture)

Jeff Mitchell (relecture)

Mans Rullgard (relecture)

Noirin Plunkett (relecture)

Oregon State University Open Source Lab (hébergement du site internet)

Stuart Jarvis (relecture)

Supet Pal Singh (site internet)

Saransh Sinha (site internet)

Vivek Prakash (site internet)

Will Kahn-Greene (relecture)

* * * * * *

[1] Note des traducteurs : dédicace par allusion à « Nous sommes des nains juchés sur les épaules de géants. » Bernard de Chartres, XIIe siècle

[2] Note de l’auteur : pour moi, l’Open Source n’est que l’un des aspects de cette communauté. Cet aspect particulier a trouvé son articulation en 1998, c’est-à-dire quelque temps après l’arrivée d’Internet. Mais n’hésitez pas à dire « Open Source » au lieu de « logiciel libre » si vous préférez ce terme.

Crédits photo hellojenuine (CC-BY-SA)

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 pour les collèges. C’est donc un travail de fourmi que doivent fournir ces sociétés pour exister. Nous avions rencontré en mars dernier les co-présidents d’iMaugis. Aujourd’hui, c’est Éric Seigne, que nous avons le plaisir d’interviewer. Il en profite pour nous annoncer une nouvelle qui devrait, nous l’espérons, faire beaucoup de bruit 😉

Bonjour Éric. Pour ceux qui ne te connaissent pas, peux-tu te présenter ?

Éric Seigne, 34 ans , directeur de la société RyXéo, éditeur de AbulÉdu, ensemble de logiciels libres multidisciplinaires à destination des établissements scolaires. Je suis un des membres fondateurs de l’ABUL, Association Bordelaise des Utilisateurs de Logiciels Libres, ainsi que d’autres associations libres.

Comment as-tu découvert le libre ?

Pendant mes années de lycée, dans le journal local (Sud Ouest) on pouvait lire que se tenaient à Bordeaux des repas entre Experts Linux… À cette époque, j’avais la chance de pouvoir bidouiller l’ordinateur de ma sœur aînée, alors équipée de DOS, tandis que mes amis disposaient d’ Amiga et Amstrad (avec écran couleur, son, jeux…) … Je me contentais du prompt A:>_ …

J’ai ensuite installé un OS/2 puis ai enfin eu mon propre ordinateur, pc offert par mon grand-père.

J’ai trouvé le moyen d’installer une slackware sans en connaître les commandes rudimentaires… J’ai persévéré et ai, comme beaucoup d’autres, apprécié. Après mon bac, je me suis installé à Bordeaux et y ai effectué mes études. J’ai enfin pu participer à ces fameux repas de linuxiens bordelais où la constitution d’une association locale (ABUL) a été décidée. À cette époque, des personnes telles que Pierre Ficheux ont suscité chez moi une réelle admiration ! À tel point qu’une Redhat a remplacé la slackware sur ma machine. La découverte de l’interface graphique n’a finalement pas changé grand-chose… si ce n’est de pouvoir lancer un Netscape… les habitudes étaient déjà trop grandes… j’appréciais les fameuses lignes de commande et ne comptais plus les abandonner.

J’ai également participé à quelques demo-parties et ai pu admirer les prouesses des démos 4k, des équipes dev-gfx-zique… la créativité de ces gens est tout simplement incroyable.

Je savais que je n’aurais pas dû jouer autant avec mon Amstrad 6128 😉
Tu es à l’initiative de nombreux projets ou tu y participes : RyXéo, AbulÉdu, AbulÉdu-fr, AbulÉdu ENT, Le Terrier, Pédagosite, Scideralle…
Vu de l’extérieur, cela commence à ressembler à l’anarchie des projets Framasoft 😉
Tu peux nous les présenter pour y voir plus clair ?

Connais-tu “la cathédrale et le bazar“ ? Ce livre fait partie de mes lectures qui ont eu une grosse influence sur ma trajectoire, au même titre que l’incroyable “hold up planétaire” de Roberto di Cosmo). Je suis un créateur sur le mode « bazar » qui, de temps en temps, essaye de remettre un peu d’organisation « cathédrale » pour repartir sur un cycle bazar et ainsi de suite :

• 1998 création de l’Abul et définition de nos prérogatives à savoir l’éducation, la création du groupe Abul-edu, qui donnera naissance au projet Abuledu

• 1998 l’AFUL signe une convention avec le Ministère de l’Éducation Nationale (Stéphane F., Thierry S., Bernard L., Nat M. Jean-Pierre L. et toute l’équipe de l’AFUL que je ne remercierai jamais assez pour ce coup d’éclat) qui nous ouvre les portes et définit le cadre de travail dont nous bénéficions dans ce secteur

• 1998 Jean Peyratout, instituteur à Gradignan (à 200 m de chez moi), fondateur de l’ABUL nous fait vibrer au son de « je suis instituteur laïc, républicain, gratuit … et néanmoins obligatoire et à ce titre j’ai du mal à mettre mes élèves devant des ordinateurs Microsoft Windows pour leur faire utiliser Microsoft Word (ou Write), Microsoft Excel, Microsoft Encarta, Microsoft truc et ainsi de suite, il y a la une entorse à mon éthique (et mon devoir de neutralité) que j’ai du mal à avaler, j’aimerais savoir si “linux” pourrait pas nous offrir un choix ».

• 1999/2000 le groupe Abul-edu (une trentaine de bénévoles de l’association) installe “des ordinateurs en réseau” dans l’école primaire de Jean Peyratout. On va du recyclage de vieux pc à l’installation d’un “serveur” (de mémoire un P3 avec 128 ou peut-être 256 Mo de RAM) … Camille C. nous amène une techno: “LTSP“… on essaie également XTermKit de Jacques Gélinas… Pour faire simple on pourrait dire que les enfants utilisent AbulÉdu en semaine et des adultes barbus s’adonnent à leur hobby le week end…

• 2000 premières RMLL, le cycle éducation présente des projets extrêmement ingénieux, dont celui de Jacques Gélinas (Hacker kernel, papa de linuxconf) qui enivre la foule… en fin de journée, nous faisons des démonstrations autour d’AbulÉdu. À la fin de la conférence, plus d’une dizaine d’enseignants viennent nous voir et nous disent qu’ils veulent faire la même chose dans leur école. Dans l’euphorie de l’événement on leur lâche un « chiche, revenez dans un an on vous donnera un cd d’installation »

• Cette même année 2000, je crée l’entreprise individuelle Rycks

• Un an plus tard, lors des RMLL 2001, on lance le CDROM AbulÉdu 1.0 basé sur Mandrake 7.2 (je salue et remercie encore les hackers de Mandrake qui nous ont aidés et soutenus)… La communauté s’élargit alors jusqu’en Afrique de l’Ouest, au Burkina Faso, en Côte d’Ivoire et bien naturellement partout en France. Des enseignants comprenant notre démarche vis à vis des enjeux du libre dans le milieu scolaire veulent créer des logiciels pour aider leurs enfants à apprendre à lire, compter… un coup de pouce technique plus tard Le Terrier d’AbulÉdu est né.

• Dans notre approche constructiviste, suite à des retours utilisateurs, nous créons Pédagosite, une nouvelle fois, dans notre bazar. L’idée est de mettre en commun les fiches pratiques et pédagogiques des enseignants contributeurs.

• 2003 l’association ABUL, le groupe abul-edu et AbulÉdu décident de structurer. L’ABUL a pour mission de s’occuper de Linux sur Bordeaux (je schématise) et AbulÉdu prend alors son envol. Le groupe Abul-edu se réunit et créé l’association SCIDERALLE.

• 2003 Rycks devient RyXéo, quittant le statut d’entreprise individuelle pour celui de SARL. Le changement n’intervient pas de façon isolée et AbulÉdu passe alors sur Debian. Nous proposons une solution clé en main de serveurs pré-installés accompagnés de maintenance. Le succès est mitigé : des clients qui nous rapportent de l’argent mais un malaise naît au sein de la communauté qui a du mal à comprendre qu’on puisse vendre du logiciel libre. 5 années plus tard, en 2008, nous relançons « AbulÉdu gratuit », version 8.08. Porteuse d’espoirs, elle nous apporte très rapidement son lot de désillusions, des donneurs d’ordre téléchargent la version gratuite, l’installent dans des écoles mais ne contractent ni support, ni expertise, ni formation auprès de RyXéo, même à 30 euros par mois !

Et la naissance d’AbulÉdu-fr ?

L’association a été constituée en 2010 et regroupe les utilisateurs d’AbulÉdu. Depuis 2011 nous essayons de resserrer les liens entre la communauté et RyXéo, l’association AbulÉdu-fr est la bonne interface pour ça.

Le bilan de l’association est présenté sur le site de l’association. toute aide est la bienvenue, en particulier d’un point de vue financier : l’association a du mal à payer les frais de déplacement pour les développeurs bénévoles lorsqu’ils viennent chez nous (RyXéo) une fois par mois.

RyXéo a toujours eu des liens avec l’éducation, notamment avec les écoles. Sauf erreur de ma part, c’est la seule entreprise, qui, en 2009, répondait intégralement au cahier des charges du ministère lors du Plan École Numérique Rurale. Pourtant de nombreuses autres entreprises ont finalement été retenues lors de ce plan (dont certaines se sont d’ailleurs mystérieusement volatilisées depuis). Comment l’expliques-tu ? Penses-tu que le fait de proposer des solutions libres a été, à ce moment là, un inconvénient ?

Je suis mal placé pour dire si on était les seuls à être compatibles avec le cahier des charges, je dirais juste qu’on a essayé d’apporter la réponse la plus claire possible.

Concernant les truands qui se sont placés sur ce marché pour voler de l’argent public et disparaître après avoir livré partiellement des écoles oui, ça m’a rendu assez malheureux.

Ensuite, ce plan était dans le « plan de relance de l’économie », j’ai observé qu’on a surtout relancé les importations de matériels produits à l’étranger. J’aurais préféré qu’on inverse le ratio matériel-service en s’appuyant par exemple sur du recyclage d’ordinateurs et en mettant beaucoup de ressources humaines en jeu en incluant des heures de passage dans les écoles pour que les entreprises fassent réellement du boulot d’accompagnement technique. Voire qu’on injecte des moyens financiers sous forme de création de postes d’animateurs TICE (ou dans les CDDP ou dans les équipes des Inspections Académiques ou autres structures existantes) pour que les enseignants puissent réellement mettre en pratique des usages avec des professionnels de la pédagogie…

Depuis 2010, de nouveaux logiciels du Terrier ont été développés et certains réécrits. Cela marque une réelle rupture aussi bien au niveau visuel que technologique par rapport aux premiers logiciels. Comment se font ces nouveaux développements ?

• En 2009, nous (RyXéo) avons fait un bilan à la fois fonctionnel et technique des logiciels du Terrier d’AbulÉdu. Nous en avons tiré les 3 principales conclusions:

1. logiciels pertinents et reconnus sur les aspects métier
2. graphismes et ergonomie à repenser
3. améliorations techniques du code applicatif à mettre en œuvre

Je tiens à signaler au passage que les logiciels en question sont vraiment conséquents, par exemple Association nécessite 1500 dessins et près d’un millier de mots (sous forme de sons) enregistrés ! À de nombreuses reprises la communauté des développeurs a lancé des appels à contribution pour avoir des dessins et des ressources libres réutilisables… sans grand succès.

• Ryxéo engage un graphiste (en fait il s’agit d’un dessinateur de BD et illustrateur). En parallèle nous testons différents langages pour nos futurs logiciels (python, pygame, etc) sans en être vraiment convaincus. Puis sur le test du logiciel Raconte-moi, nous tentons l’aventure Qt/C++.
• Au même moment, nous accueillons en stage, un enseignant avec qui nous avons l’habitude de travailler. Avec notre équipe technique, il développe le logiciel Calcul-Mental et travaille en forte collaboration avec le graphiste.

Le résultat est évident : nous sommes séduits… et l’équipe s’étoffe en l’embauchant à l’issue de son stage.

Parlons de choses qui fâchent 😉

Parmi les nouveaux logiciels, certains sont téléchargeables directement, d’autres accessibles uniquement après un achat en boutique. Pourquoi ce changement de politique ? Pourquoi cette différence de traitement entre les logiciels ?

Comme évoqué un peu plus tôt, Ryxéo est une équipe qui regroupe des développeurs, graphistes et pédagogues qui œuvrent à l’essor et au maintien de la solution AbulÉdu. Les salariés de l’entreprise reçoivent un salaire à la fin du mois. Le modèle économique Ryxéo, tel un éditeur, est basé sur le support, la maintenance et les formations autour des solutions proposées à nos clients.

À côté de ça, il faut savoir que l’estimation des dépenses globales au niveau national en logiciels pour les écoles en 2011 est de plusieurs millions d’euros (exemple 500.000 euros pour l’académie de Toulouse, sources : http://tice.ac-toulouse.fr/web/635-cheque-ressources.php) … Ne serait il pas pertinent que les ressources libres en bénéficient ?

Il n’en demeure pas moins que, nous sommes tous très impliqués, individuellement comme collectivement, et ce depuis de nombreuses années, à titre bénévoles dans des associations et des communautés. .

Cela dit, j’avoue qu’un de mes rêves serait de lancer une opération “logiciel libre à prix libre”… Peut être encore trop tôt… Mais un jour viendra, je l’espère.

Pour moi la réussite d’un projet libre n’est pas tant qu’il soit utilisé par des milliers d’utilisateurs que de créer des emplois et de la richesse. La FSF a eu l’intelligence de ne pas mettre de conditions « non commercial » dans la GPL et c’est vraiment important.

Puisque tu parles de “logiciel libre à prix libre”, RyXéo a lancé un Pedagogic Bundle permettant aux utilisateurs d’acheter un pack de logiciels du Terrier. SI je ne me trompe pas, cette opération en anglais a permis de récolter 800 $. Quel bilan en tires-tu ? Pourquoi ce choix d’une opération en anglais ?

C’est un test à plusieurs niveaux: je pense que l’aspect international est compliqué à aborder pour des logiciels pédagogiques, je ne pense pas que les enseignements soient les mêmes partout. Néanmoins je cherche pour voir s’il existerait un « écho » dans la communauté internationale qui gravite autour des logiciels libres et de l’éducation.

800€ c’est très peu et beaucoup : très peu compte tenu de l’exemple qu’on a pris pour s’en inspirer (humble bundle) et beaucoup parce que vu le peu de publicité qu’on a faite on a tout de même des retours.

Ensuite ce sont des personnes plutôt militantes qui nous ont pris ce bundle et nous ont spontanément proposé de participer aux traductions et prochaines offres…

Où en est le projet de micro-blogue pour les écoles primaires porté par l’association AbulÉdu-fr ?

Il s’agit d’un projet porté par l’association. Un projet véritablement important, à faire vivre, demandant du temps. Je profite donc de la tribune offerte pour demander à tout contributeur potentiel de ne pas hésiter à proposer son temps et son aide en remplissant ce formulaire de contact : http://www.abuledu-fr.org/Contacter-l-association.html

Passons à l’actualité chaude de RyXéo. Tu viens, ce samedi de présenter un produit qui devrait faire beaucoup de bruit, la TEDI. C’est quoi ?

Depuis deux ans, le phénomène « tablettes » envahit notre quotidien. Les écoles ne sont pas en reste et certaines, se sont lancées très tôt dans les démarches d’acquisition de ces nouveaux matériels.

La tablette est vue comme un gros téléphone, multi-tâche, à la frontière entre le matériel de productivité et le gadget. À ce titre je me dis que le combat de “détaxe” ou de “vente liée” est perdu ou tout au moins mal embarqué sur ces plates-formes …

Android prend de plus en plus de part de marchés et souffle le chaud et le froid (libre, pas libre, par exemple une version d’Android n’a jamais été publiée) … je fais de la veille technologique active et envisage un éventuel avenir libre aux tablettes scolaires.

RyXéo achète quelques tablettes pour découvrir que l’univers ARM (les puces qui équipent l’écrasante majorité des tablettes pour ne pas dire la totalité) est structuré d’une manière bien différente de la plateforme “pc/intel” que je connais bien. Il est par exemple très compliqué de choisir le périphérique d’amorçage et d’envisager de démarrer sur une clé usb, le réseau ou une carte SD … allons-nous être obligés de développer pour iOS ou Android ?

RyXéo développe cependant une « solution tablettes pour développeurs » sur une plate-forme intel tout en synthétisant notre cahier des charges « école primaire »  :

• Matériel aussi ouvert que possible
• Système d’exploitation libre et logiciels libres
• Assez robuste pour être confié à des enfants
• Léger
• d’un look “sympa” ou tout au moins, sortant de l’ordinaire

J’estime qu’en tant que développeurs nous avons des responsabilités. Je m’explique: si je développe une application pour iOS ou Android je ne peux pas ignorer que l’identité numérique des futurs utilisateurs de mon logiciel sera gérée par un de ces deux géants. Il en va de même pour les données qui seront forcément indexées voire stockées sur le cloud de ces mastodontes, probablement hors du territoire national et donc soumis à une loi qui n’est même pas la nôtre. De ce fait il est de notre responsabilité de proposer des alternatives durables, ouvertes, libres et pérennes. D’autant plus qu’on est dans un domaine ou nos utilisateurs (les enfants) n’ont pas encore construit leur esprit critique et qu’ils font confiance aux adultes que nous sommes pour avoir fait les bons choix !

Comment est né ce partenariat avec Unowhy ?

Après quelques recherches et échanges avec nos clients et partenaires, la tablette qooq/unowhy est identifiée. Contact est pris avec l’industriel, nous achetons une tablette « développeur » et installons un hack d’AbulÉdu en test.

Ensuite tout s’enchaîne, nous rencontrons l’équipe dirigeante de Unowhy, effectuons une démonstration de la tablette « AbulÉdu », et nous voici, samedi 8 décembre 2012, pour l’annonce officielle de cette Tablette.

J’apprécie en particulier sur leur tablette et avec leur approche qu’il n’y a ait aucun connecteur propriétaire: rien que du standard ! (usb, ethernet, sdcard, jack pour le casque) … c’est suffisamment rare pour le signaler !

Présent à Éducatice Unowhy présentait justement son projet de tablette scolaire et parlait d’une expérimentation en collège. Est-ce un projet différent ou bien est-ce également un partenariat avec RyXéo ?

Ce sont deux projets différents qui pourraient paraître complémentaires. Je précise néanmoins que TEDI AbulÉdu a aussi été présentée le 22 sur le stand de Unowhy à Éducatice.

Je ne savais pas. Je n’ai pas eu l’occasion d’aller à Éducatice cette année.

Au niveau du système d’exploitation, je suppose que ce n’est pas iOS. Est-ce Android ou un développement maison ? Une adaptation d’AbulÉdu ?

C’est un vrai GNU/Linux, fondé sur l’excellent boulot de linaro. Et sur lequel nous avons réalisé le même travail que pour AbulÉdu « Live » ou « Serveur ».

Puisqu’on parle de partenariat, il y au final peu d’acteurs dans l’univers du libre au niveau de l’école primaire (ASRI Édu, Beneyluschool, OLPC, OOo4kids, Sankoré, GCompris …). As-tu des échanges, liens avec eux ?

C’est juste de le dire, on est peu nombreux et la quantité baisse avec les années (par exemple cette année nous perdons l’excellente équipe de PingOO). Le grand absent de cette liste est edubuntu, qui, pour moi, est un exemple intéressant : AbulÉdu serveur étant fondé sur ubuntu, j’ai souhaité leur offrir l’interface d’administration d’AbulÉdu il y a quelques années. Tous les paquets .deb existent et marchent dans plusieurs centaines d’école tous les jours en France … Le retour que j’ai eu a été … étonnant : notre interface d’administration étant en PHP le responsable du projet edubuntu n’a même pas daigné le regarder. Aujourd’hui nous faisons et refaisons tous la même chose (des interfaces d’administration) au lieu d’utiliser des forces à la création de ressources pédagogiques, de logiciels d’apprentissages, de retours utilisateurs etc.

Beneyluschool est exemple également intéressant. En 2010 quand on a voulu proposer un ENT à nos clients, on a cherché les sources de la Beneyluschool… introuvables ou alors une version vieille comme Hérode. D’autre part, le site faisant appel à du flash de manière importante, nous avons décidé de créer notre ENT. Cependant, en 2012, Beneyluschool libère le code de sa version 3.0 qui n’utilise à priori plus de flash… Je suis heureux de voir cette nouvelle orientation et le contact est en cours pour voir comment intégrer l’accès à l’ENT depuis les tablettes pour les clients que nous avons en commun.

De même, nous avons intégré OOo4Kids dans AbulÉdu mais quelques ajustements sont encore nécessaires, notamment entre OOo et OOo4Kids (quel logiciel a la priorité sur l’association des fichiers dans le navigateur de fichiers par exemple).

Concernant GCompris la cible et l’approche sont différentes : GCompris est un moteur d’activités ludo-éducatives, Bruno a même ajouté l’interprétation de script python dans GCompris pour simplifier l’ajout de nouveaux modules par des développeurs tiers. Notre approche est différente : nous avons préféré avoir un exécutable indépendant pour chaque logiciel. Par contre au niveau de la distribution AbulÉdu, GCompris fait partie des logiciels que nous diffusons systématiquement.

Avec OLPC et ASRI Édu, nous n’avons pas encore de réels liens mais l’occasion se présentera peut être un jour.

Ryxeo fêtera ses 10 ans l’année prochaine, c’est un véritable succès ! Si tu devais choisir parmi ces propositions laquelle définirait le mieux la situation actuelle ?

* Grâce au choix du logiciel libre, RyXéo est prospère et je suis un patron très riche. * L’équilibre est précaire mais sans le logiciel libre l’aventure n’aurait pas été possible. * RyXéo aurait sûrement été plus prospère en choisissant le logiciel privatif.

À vrai dire, je ne sais pas trop commenter ces aspects. Je dirais que depuis 10 ans, l’aventure est belle, soumise à des moments heureux comme des périodes délicates. Si je devais tirer un bilan, il serait très positif. La prospérité est plus celle du cœur et de la connaissance que du compte en banque mais je ne regrette pas mes choix !

Pour finir, si des lecteurs du blog sont intéressés par un des projets, peux-tu nous dire de quoi vous avez besoin actuellement ?

Le projet AbulÉdu recherche des contributeurs pour collecter des ressources libres sur internet et les ajouter dans l’entrepôt de données data.abuledu.org En trois mois nous avons déjà collecté plus de 5000 ressources libres… aidez-nous pour arriver à 50 000 pour les RMLL 2013 !

Ensuite si nous voulons que notre plate-forme soit remplie de ressources libres, il faut les produire. Nous lançons donc un appel à tous les enseignants créateurs de ressources à les mettre sous licence libre (compatible avec cc-by-sa) et nous les envoyer (ou les envoyer eux même sur l’entrepôt) pour qu’elles soient mises à disposition de tous et indexées selon les normes en vigueur, (LOM, SCOLOM etc.) dans l’entrepôt de données pédagogiques .

Enfin, nous sommes à la recherche de donneurs de voix pour enregistrer des histoires pour les enfants, ou lire des textes.

Sur les aspects techniques, si des développeurs souhaitent rejoindre la communauté AbulÉdu, ils et elles seront chaleureusement accueillis (voir la liste de diffusion dev@abuledu.org) et notamment lors de nos week-ends abuledu@ryxeo.

Merci Éric !

Il est rare que Framasoft s’évade d’Internet et encore plus rare qu’il organise lui-même des évènements sur le terrain de la vraie vie. Alors autant que ça sorte un peu de l’ordinaire, comme ce fut le cas vendredi 7 décembre à la Rockette Libre et samedi 8 décembre à la librairie « À Livr’Ouvert ».

Framathon à la Rockette Libre

C’est temps libre chaque vendredi soir à la Petite Rockette. Et c’était au tour de Framasoft d’investir le lieu le 7 décembre dernier.

Il s’agissait de lancer le top départ d’un ambitieux projet en partenariat avec LinuxFr : traduire dans son intégralité le livre Open Advice: what we wish we had known when we started (avec le recul, qu’auriez-vous voulu savoir quand vous avez commencé à contribuer à la communauté du libre ?)

Or nous manquions d’ordinateurs, nous étions un peu fatigués en cette fin de semaine, et nous avions plein de choses à nous dire car certains ne s’étaient pas vus depuis bien longtemps (parfois depuis leur naissance). Donc rares étaient ceux qui travaillaient effectivement sur la traduction : trois, quatre personnes tout au plus au maximum de l’activité. Il faut aussi vous avouer que le slogan détourné par Pouhiou à cette occasion ne nous a pas vraiment motivés : « Boire ou traduire, il faut choisir ! » 😉

Et pourtant le travail proposé fut réalisé « vite fait bien fait » ! Pourquoi ? Parce que nous avions déposé les deux premiers articles du livre sur Framapad et sollicité dans le même temps la participation d’Internet. Pour ce qui nous concerne, nous avions projeté sur le mur les pads en question et jetions un oeil de temps en temps sur le texte et les couleurs qui défilaient à l’écran.

L’originalité est là.

La majorité des lecteurs de ce blog est désormais habituée à un tel l’outil et une telle manière de procéder ensemble. Mais pour quelqu’un qui découvre, cela a quelques chose de magique ! Et il n’est pas au bout de sa surprise car quand il arrive (enfin) à comprendre que derrière chaque couleur en mouvement se cache quelque part une personne connectée, il lui est tout aussi suprenant d’apprendre que tout ce petit monde n’a pas été « sélectionné » et surtout travaille « pour rien ». Pour la beauté du geste, pour la beauté du Libre…

Cette dernière phrase valait bien une danse 😉

Framabook chez « À Livr’Ouvert »

Comment donc ? Tous les livres de notre libre collection Framabook dans une librairie parisienne ! En vitrine même !

Il fallait marquer le coup en invitant les lecteurs à rencontrer les auteurs.

C’est ainsi que fut organisée une très conviviale mais somme toute classique séance de dédicaces avec trois de nos auteurs : le gendre idéal Benjamin Jean, le plus célèbre auteur vivant du domaine public Pouhiou et l’homme qui gratte plus vite son ukulélé que son ombre Simon Gee Giraudot.

Un petit ordinateur se trouvait au milieu d’eux. Il contenait les versions numériques intégrales de toute la collection.

L’originalité est là.

Les gens étaient évidemment cordialement invités à acheter et repartir avec des livres, c’est normal nous sommes dans une librairie. Mais ils pouvaient aussi sortir leur clé USB que nous nous faisions un plaisir de remplir avec la version numérique du ou des livre(s) de leur choix.

C’est gratuit, mais c’est surtout libre. C’est à notre connaissance une grande première que de proposer, dans un tel lieu, un tel service libre en libre service. Et c’est tout à l’honneur de l’audacieuse librairie qui porte décidément bien son nom. Nous sommes tout d’un coup très loin d’Hadopi.

Ah, et sinon nous avons vendu une trentaine de livres papiers Framabook ce jour-là.

Nous remercions toutes celles et ceux qui sont venus et ont participé à ces deux singuliers évènements et plus particulièrement Olive (Rockette Libre) et Bookynette (À Livr’Ouvert) pour leur invitation, accueil, disponibilité et bonne humeur.

C’est quand vous voulez pour recommencer 😉

Crédit photo : aKa (Creative Commons By)

Le jeune blogueur roumain qui témoigne ci-dessous de façon courageuse et provocatrice écrit également sur son blog : « Le Lumia 920 est en ce moment mon smartphone favori et Microsoft est l’entreprise high-tech la plus excitante… du moins cette semaine ». Ce qui convenons-en n’est guère conforme ni au cliché du pirate anti-monopole propriétaire, ni à celui du casseur de code qui monnaye au prix fort des données captées par effraction.

En jetant un coup d’œil rétrospectif sur ses années de formation et à la manière dont il a appris les logiciels et l’informatique, il constate que par nécessité le plus souvent — et non dans le seul but d’économiser le prix d’une licence — il a utilisé des logiciels piratés.

Que ceux qui n’en ont jamais fait autant lui jettent la première pierre.

Ce qui est original en revanche, c’est l’effet formateur du piratage selon lui : en ayant un accès, certes illégal, à de puissants logiciels coûteux, les adolescents de pays longtemps négligés par les campagnes marketing de Microsoft ont pu apprendre, comprendre et maîtriser leurs usages. Au point qu’une génération entière peut accéder avec des compétences sérieuses à une activité professionnelle dans le domaine de l’informatique.

La trajectoire de Vlad Dudau est pleine d’enseignements pour la communauté libriste : n’ayant manifestement jamais été en contact avec les logiciels libres (manqueraient-ils de visibilité en Roumanie comme ailleurs ? — oui bien sûr !), c’est très logiquement qu’après avoir été formé par les logiciels propriétaires, il les célèbre maintenant et les chronique aujourd’hui dans son travail de journaliste du Net. Imaginez maintenant comment la mise à disposition de logiciels libres dès les années de formation scolaire pourrait inversement former toute une génération. Pas besoin de transgresser la loi ni de pirater pour cela. Nous savons que de nombreux enseignants agissent déjà en employant les outils et les valeurs du Libre. Mais la force du logiciel libre reste à déployer bien plus largement, sans doute. Après la circulaire recommandant l’usage du logiciel libre dans l’administration, aurons-nous bientôt son équivalent pour préconiser le logiciel libre dans l’éducation ?

Comment le piratage a changé ma vie

How piracy changed my life

Vlad Dudau – 1er décembre 2012 – Blog Neowin.net

(Traduction framalang : peupleLa, Yoha, Kiwileaks, Robin Dupret, LeCoyote, GPif, goofy, Cyb)

De nombreuses discussions récentes ont porté sur le piratage et les moyens de le combattre, y compris par certaines mesures assez radicales. Mais je pense que la plupart des gens négligent certains des aspects positifs du piratage. Comprenez-moi bien : je n’encourage pas le piratage et je ne dis pas que c’est bien ; je dis juste que ça n’est ni tout noir ni tout blanc. Le piratage n’est qu’un symptôme de quelque chose de plus global, que ce soit les mauvais modèles économiques, les marchés restrictifs ou les problèmes financiers. Et je pense que mon histoire personnelle le prouve.

Je suis né en Roumanie, un pays qui venait de traverser une révolution et redevenait une démocratie. En tant que société, nous étions en train de nous souvenir de ce qu’était la démocratie et du fonctionnement du libre échange. Nous découvrions les avancées technologiques majeures réalisées à l’Ouest ces 30 dernières années alors que notre propre pays et notre peuple étaient restés coupés de l’information et technologiquement dépassés.

Mon premier PC était un impressionnant Pentium MMX cadencé à 166 MHz, avec un disque dur de 2Go et 64Mo de RAM si je me souviens bien. À cette époque les gens avaient des 386 et 486 sous DOS ; donc le fond bleuté de Windows 95, c’était quand même quelque chose. Mais voilà le problème : la copie de Windows 95 que j’utilisais était piratée. Elle venait d’un ami de la famille qui l’avait sur quelques disquettes. Ce n’est pas parce que ma famille était chiche ou qu’elle voulait commettre un crime, c’était simplement parce qu’il n’y avait pas d’autre solution. Windows n’était vendu nulle part dans le pays — en tout cas pas légalement.

Quelques années plus tard, lors de la sortie de Windows 98, la même chose se reproduisit. Cet ami de la famille est venu avec un tas de disquettes et a installé l’OS sur notre PC.

Quand XP est sorti, Microsoft avait enfin commencé à s’intéresser à notre pays, sans parler du fait que que le libre-échange était enfin en pleine expansion ; il y avait donc plein de moyens légaux d’ acheter ce nouvel OS. Le problème, c’est que l’OS était souvent au moins aussi cher que l’ordinateur lui-même, donc l’acheter doublait littéralement les coûts. Oh, et au cas où vous vous poseriez la question cela représentait l’équivalent d’environ 3 mois de salaire. Pour vous donner une meilleure idée, imaginez que Windows coûte dans les 2 000 dollars.

J’ai eu la chance d’avoir une copie originale de XP livrée avec le nouveau PC que ma famille venait d’acheter. Cependant, un an après, quand la carte mère a brûlé et que nous avons dû acheter du nouveau matériel, nous nous sommes de nouveau tournés vers l’ami de la famille.

Durant les 5 à 6 années suivantes, j’ai utilisé ce PC avec cette version piratée de Windows pour télécharger une quantité infinie de jeux et de logiciels — toujours illégalement. Des plus basiques Half-Life et Warcraft jusqu’à l’intégrale de la Creative Suite d’Adobe. Encore une fois ce n’était pas à cause du prix, encore que dépenser quelques milliers de dollars pour Adobe CS aurait été complètement insensé et aurait précipité n’importe quelle famille dans la pauvreté, mais surtout parce que la plupart de ces logiciels n’étaient même pas disponibles sur le marché.

C’est grâce au piratage que j’ai eu accès à une quantité d’informations qu’il aurait été impossible de trouver autrement. C’est grâce au piratage que j’ai appris à utiliser Photoshop, à faire du montage vidéo, à installer un système d’exploitation.

Et je ne suis pas le seul. Parmi mes amis, tous ceux qui ont fini par travailler dans l’informatique ont commencé en utilisant des logiciels piratés. Comment un jeune de 15 ans pourrait-il sinon apprendre à se servir d’un logiciel qui coûte des milliers de dollars, quand le revenu mensuel moyen tourne autour de $200 ? Comment dans ce pays un gamin normal aurait-il pu apprendre avec des trucs dont le prix est prohibitif même aux États-Unis ou au Royaume-Uni ?

Donc voilà : c’est grâce au piratage que beaucoup d’entre nous ont un emploi aujourd’hui. Sans toutes ces heures passées à comprendre les logiciels, mes amis et moi ne serions jamais devenus graphistes, ou développeurs de jeux vidéos, ou journalistes en informatique. J’ose dire que nous aurions été des membres de la société beaucoup moins productifs.

Je sais que je viens de dire des choses plutôt compromettantes, mais le truc, c’est qu’aucun de nous ne pirate plus aujourd’hui. Pourquoi ? Parce que nous avons toujours su que ce n’était pas bien de pirater, bien que nous n’ayons jamais vraiment eu le choix. Maintenant que nous avons tous du boulot, que le contenu est enfin disponible, et que les entreprises ont changé leur modèle économique pour offrir un accès bon marché aux étudiants et aux écoles (une licence Windows à $39 , qui en veut ?), nous faisons tous le choix de payer pour les logiciels, la musique et les films. Ah oui ! Cet ami de la famille qui piratait systématiquement les OS pour nous ? Il est maintenant manager chez IBM.

La plupart des gens piratent par besoin, pas par appât du gain. Et les logiciels piratés peuvent être d’une importance vitale pour le développement d’une génération dans les régions défavorisées. Bien sûr, des logiciels accessibles et bon marché seraient largement préférables, mais il y en a si peu qui circulent.

Quant à ceux qui piratent par cupidité, eh bien ce ne sont que des trous du cul ; mais heureusement pour nous il n’y en a pas tant que ça. Je suis vraiment curieux de savoir ce que vous en pensez, et j’espère que nous pourrons lancer une conversation vraiment constructive.

Crédit photo : oakleyoriginals licence Creative Commons Attribution 2.0

Au fait, les libristes ont aussi un corps.

Et ils apprennent parfois à leurs dépens que dans le monde médical, le code propriétaire et les formats fermés peuvent empêcher d’avoir de meilleures chances de se soigner. Souvenez-vous de Salvatore Iaconesi, dont nous avions traduit les déclarations, qui voulait avoir accès à ses données médicales dans un format ouvert.

C’est une histoire personnelle comparable que raconte Karen Sandler au cours d’une conférence que nous vous proposons ici. Karen Sandler est loin d’être une inconnue dans le monde du Libre notamment par son militantisme et ses responsabilités au sein de la Gnome Foundation.

Découvrir qu’un problème cardiaque menace d’un jour à l’autre votre vie même est une épreuve que vous pouvez surmonter en faisant appel à un appareillage de haute technologie (pacemaker, défibrillateur…). Mais découvrir que cette technologie repose sur un code auquel on n’a pas accès, c’est comme le fait Karen prendre conscience que sa vie est à la merci d’un bug dans un code inaccessible…

Non seulement Karen livre ici avec humour le récit de ses déboires, mais elle évoque également d’autres domaines de la vie quotidienne où l’accès au code est désormais crucial. La vidéo qui suit, dont la transcription, la traduction et le sous-titrage ont été assurés par : FredB, Pandark, peupleLa, ga3lig, KoS, Mnyo, Lamessen, goofy, est relativement longue (54 minutes). Ceux qui ne disposent pas d’un long temps de lecture pourront découvrir de larges extraits de la conférence dans le texte sous la vidéo.

Note : je vois d’ici venir dans les commentaires tous ceux qui ne pourront résister au plaisir de faire un jeu de mots recyclant une des deux cent cinquante expressions comprenant le mot cœur. Eh bien, ils auront un gage ! À chaque astuce publiée en commentaire ils devront faire un petit don à Framasoft qui ne vit que de etc. voir le mantra automnal de notre campagne en cours.

La liberté dans mon cœur et partout ailleurs

Cliquer sur l’image pour accéder à la vidéo de la conférence

Je suis vraiment, vraiment contente d’être ici. Ma conférence s’appelle La liberté dans mon cœur et partout ailleurs. Comme dit précédemment, je fais partie de la communauté Libre et Open Source depuis un moment. Je suis directrice exécutive de la fondation GNOME. Nous en reparlerons un peu plus tard, c’est vraiment cool. Et j’ai longtemps été avocate au Software Freedom Law Center, pour finir par en devenir la directrice juridique. Donc j’ai eu l’occasion de faire la connaissance de plein de gens dans la communauté du logiciel Libre et Open Source en les aidant avec tous les emmerdements dont ils ne voulaient pas s’occuper. Vraiment, vraiment amusant ! Je suis une passionnée du Libre et de l’Open Source, je dirais, depuis les années quatre-vingt-dix.
Et je suis aussi une patiente.

Un très gros risque de mourir subitement

J’ai un cœur vraiment, vraiment très grand. En fait, j’ai un cœur énorme.
Vous pensez sûrement à mon travail pour des associations, mais en fait, j’ai une hypertrophie du cœur. J’ai une maladie appelée cardiomyopathie hypertrophique. Je suis toujours un peu nerveuse quand je parle de ça parce que ça revient à dire que mon cœur est un petit peu cassé. Ce n’est pas vraiment ça. Mon cœur est très épais et ça veut dire qu’il a du mal à battre. Il est un peu raide. Mais au final, tout va bien. Pour l’instant, je n’ai aucun symptôme. J’ai seulement un très gros risque de mourir subitement. Le terme est littéralement mort subite. C’est ce que les docteurs vous expliquent quand vous avez cette maladie et que vous devez suivre un traitement à vie. Ils disent que vous avez un risque élevé de mort subite.
Ce qui, en tant que patiente, est vraiment terrifiant. Deux ou trois fois par an je risque de mourir subitement. Et ça se cumule, donc j’ai découvert ça à 31 ans, soit de 20% à 30% environ de risque de mort subite pour la décennie suivante. C’est vraiment, vraiment une chose terrible à entendre… mais il existe maintenant une solution ! C’est de se faire poser un défibrillateur.
Le principe d’un défibrillateur, c’est qu’il est installé dans votre cœur. D’ailleurs j’en ai un, il est juste ici. Il a l’air vraiment énorme là mais c’est environ gros comme ça et c’est juste ici. Il a des câbles qui se glissent dans mes vaisseaux sanguins et qui s’enfoncent dans mon cœur, et en gros, il me surveille constamment.
C’est comme avoir des gens qui vous suivent partout avec un défibrillateur électrique et si je tombe raide morte tout à coup, il m’enverra une décharge et je serai remise sur pieds — Et je ne mourrai pas ! C’est formidable.

Qu’est-ce qui tourne dessus ?

Donc, tout ça est merveilleux, parfait. L’électrophysiologiste que j’ai rencontré et qui m’a expliqué ça en avait quelques-uns dans le tiroir de son bureau afin de pouvoir les montrer à tous ses patients parce qu’en voyant à quel point cet appareil est petit, ça parait nettement moins inquiétant. Il l’a poussé vers moi sur le bureau, j’étais assise là, avec ma mère. Je l’ai pris…
Et il disait : « Prenez-le, voyez comme c’est léger… » Alors je l’ai pris et j’ai demandé : « Cool ! Qu’est-ce qui tourne dessus ? ». En réponse, j’ai eu droit à un regard médusé. Ma mère semblait elle aussi perplexe.
Le chirurgien m’a demandé « Mais de quoi parlez-vous ? » et j’ai répondu « Eh bien, de toute évidence cet appareil ne vaut que ce que vaut son logiciel, c’est-à-dire qu’il se base sur le logiciel pour savoir quand je risque une mort subite, que ce soit quand je traverse une rue alors que je n’aurais pas dû, ou que je décide de courir un marathon, ou pour n’importe quelle autre raison. Je suis dépendante de ce logiciel pour savoir quand il est approprié de m’envoyer une décharge et quand ça ne l’est pas. Quand mon cœur a besoin d’être stimulé ou pas. Et l’électrophysiologiste, bien sûr, n’avait pas de réponse à me donner. Il m’a dit « Personne ne m’a jamais demandé ça. Je n’avais jamais pensé au logiciel sur cet appareil. Ne bougez pas, il y a un représentant de Medtronic dans nos bureaux aujourd’hui. Je vais aller lui demander, c’est lui le fabricant, et ils auront sûrement déjà pensé à ça ».
Donc, le représentant arrive et j’essaie de lui expliquer « Je suis avocate au Software Freedom Law Center. Je m’intéresse au logiciel sur mon appareil. Je veux juste savoir comment ça marche, sous quoi ça tourne ? Est-ce que vous pouvez me le dire ? ». Il a répondu : « Personne ne m’a jamais demandé ça auparavant ». Donc, on a eu une conversation très intéressante, et il a conclu par :
« Je comprends, c’est une question très importante, voici mon numéro, appelez moi, et je vous mettrai en contact avec des gens qui pourront vous parler de ça ». Enhardie par cet échange, je l’ai appelé à Medtronic. Il m’a passé le service technique et j’ai commencé à laisser des messages… Mais au final, je me faisais continuellement refouler. Personne ne voulait me parler de ça.

Vous devez nous faire confiance…

J’ai appelé les deux autres principaux fabricants d’appareil médicaux, Boston Scientific et St Jude, et aucun n’a su me donner une vraie réponse non plus. À la fin, j’ai commencé à appeler en disant : « Écoutez, si quelqu’un me laissait voir le logiciel… Je signerai un accord de confidentialité », C’est contre mes principes en tant que militante d’un organisme à but non-lucratif dans un domaine technique. Je n’ai pas envie de signer un contrat qui m’empêcherait de partager ce que je découvre avec le reste du monde. Mais j’ai pensé :
« Au moins, moi, je pourrai voir le code source et j’aurai davantage confiance dans ce qu’on installe dans mon corps ». Mais, malheureusement, on m’a envoyé balader. On m’a dit non. J’ai parlé avec des gens très compréhensifs à Medtronic. J’ai rencontré d’excellents docteurs. Et ces gens me disaient « Oh, vous savez, nous sommes Medtronic, nous avons à cœur de nous assurer de l’absence de bogue dans les logiciels que nous installons sur ces appareils. Évidement, nous ne le vendrions pas si nous ne pensions pas qu’il est sûr. Pour toutes ces raisons, vous devez nous faire confiance».
Le docteur a ajouté que la FDA, l’Agence fédérale américaine des produits alimentaires et médicamenteux, approuve ces appareils. Donc votre réaction est clairement disproportionnée ». Et quand j’en parlais avec mon électrophysiologiste au téléphone, je disais que j’étais vraiment gênée par tout ça, parce que je pensais à tous ces gens qui portent ces appareils. Certains sont relativement puissants, Dick Cheney en avait un à l’époque. Il en a un encore plus impressionnant aujourd’hui, qui fait continuellement circuler son sang alors techniquement, il n’a pas de pouls. C’est un appareil vraiment fascinant !

Est-ce que je vais vraiment avoir un logiciel propriétaire à l’intérieur de mon corps ?

Les populations qui bénéficient de ces appareils sont souvent dans des positions de pouvoir. Donc on peut facilement imaginer une situation où quelqu’un voudrait éteindre ces appareils. Et l’électrophysiologiste à qui je parlais au téléphone était tellement contrarié, tellement contrarié…qu’il m’a raccroché au nez. Il m’a dit « Je pense que vous préparez quelque chose… je ne comprends pas.. ; je ne sais pas pourquoi ça vous dérange tellement. Si vous voulez un appareil, je vous aiderai mais je ne… Je pense que vous êtes… vous… »
Et il a raccroché.
C’est vraiment terrifiant parce qu’il m’avait précisé au début de la conversation qu’il installait ces appareils tout le temps. Il en installe parfois plusieurs par jour. Alors l’idée qu’il ait pu ne même pas s’être posé de question à propos du logiciel installé sur ces appareils le terrifiait. J’ai donc remis à plus tard et je me suis dit, il faut que j’arrête de penser à ça. C’est trop terrifiant.
Est-ce que je vais vraiment avoir un logiciel propriétaire à l’intérieur de mon corps ? Je ne sais pas. Ajoutez à ça cette histoire de « mort subite » et le fait d’avoir un équipement cousu à l’intérieur de mon corps. Ça fait beaucoup à gérer. Alors j’ai continué à remettre ça à plus tard jusqu’à ce que je ne puisse plus différer parce que mes amis et ma famille continuaient à m’en parler et à me dire « Nous nous inquiétons tellement pour toi, nous savons que tu peux mourir à tout instant » Ma mère… vous savez, évidemment je n’ai pas de ligne fixe et mon mobile ne capte pas bien dans mon appartement Et ma mère, si je ne la rappelais pas dans l’heure commençait à appeler tous mes amis en demandant « Vous avez parlé à Karen aujourd’hui ? Vous savez si elle va bien ? » Je suis allée déjeuner avec une amie, et elle m’a demandé où en était cette histoire. Et j’ai répondu « Eh bien, les compagnies médicales ne me rappellent pas. Et tu sais, je suis sûre que je vais me débrouiller. Et elle a fondu en larmes et dit :
« Tu sais, tu pourrais mourir. Aujourd’hui. Et je ne peux pas le supporter. Si tu ne règles pas cette histoire, je ne sais pas si je peux encore être ton amie. C’est une chose très grave et tu l’ignores juste pour… » ce qu’elle considérait comme un problème ésotérique.
J’ai vraiment compris ça et j’ai compris que je n’avais pas le choix. Alors j’ai eu un appareil. Je me le suis fait implanter et ça a pris un peu de temps pour me remettre de l’opération et aussi pour réfléchir à propos de ma propre situation, prendre un peu de recul, faire quelques recherches. Mais je me suis juré que si j’acceptais cet appareil, j’allais faire des recherches, écrire un article et parler des problèmes que j’avais rencontrés et auxquels la profession médicale, ou du moins, les professionnels de la médecine que j’avais interrogés n’avaient pas de réponse.

Un bogue pour cent lignes de code

Donc, j’ai découvert des choses en écrivant cet article, certaines peuvent sembler normales, mais d’autres vous surprendront. Les logiciels ont des bogues. (…) Et les appareils médicaux, comme l’a dit Matthew Garret, auront des bogues, parce que l’institut d’ingénierie logicielle estime qu’il y a environ un bogue pour chaque centaine de lignes de code. Donc même si la majorité des bogues était interceptés par les tests, même si les trois quarts des bogues étaient interceptés lors des tests, ça fait toujours un sacré nombre de bogues.
J’ai lu une étude qui observait les rappels d’appareils publiés par la FDA. Fondamentalement, l’étude portait sur l’ensemble des rappels et a déterminé ceux qui venaient vraisemblablement de pannes logicielles puis ils les ont évalués. Parmi ceux qu’ils ont pu étudier suffisamment et dont ils ont pu déterminer précisément les failles logicielles : 98% d’entre elles auraient pu être détectées de simples tests par paires.
Donc, pour les tests basiques que vous êtes en droit d’attendre sur n’importe équipement technologique — oui, la FDA les soumet à quelques tests. Mais si les entreprises ne font pas de tests basiques qu’est ce qu’on peut faire ?
Donc, les logiciels ont des bogues. Ici dans cette pièce, tout le monde le sait. Une autre chose que la plupart d’entre nous savons c’est que la sécurité par l’obscurité ça ne marche pas. Même si ça peut sembler contre-intuitif pour ceux qui ne sont pas dans cette pièce. Toutes les personnes à qui j’ai expliqué cette idée dans le corps médical m’ont répondu : « Mais je ne comprends pas… pourquoi voulez vous que les gens puissent voir le logiciel ? Si tout le monde peut voir le code source, il sera beaucoup plus facile de le pirater ! ».
Mais nous savons tous que ce n’est pas le cas. En fait, en publiant le code source, tout le monde peut le voir, et il est plus sûr. Mais c’est une question capitale en réalité. J’en parle dans mon article : Tués par le code qui cite un certain nombre d’études montrant que les professionnels de la sécurité approuvent cette idée.
Donc pour le moment, on a le pire des deux mondes : un code fermé qui ne profite pas d’une relecture et d’une correction par le plus grand nombre. Mais on manque également de sécurité sur ces appareils. Beaucoup d’entre eux émettent des informations en sans fil. C’est le standard aujourd’hui. Quand j’ai découvert cela, j’étais choquée. Vous êtes en train de me dire que mon appareil cardiaque va émettre en continu ? Considérant les conférences auxquelles j’assiste, les gens que je fréquente, je n’ai vraiment pas envie de voir mes informations diffusées.

algorithmes

Donc c’est une des choses que j’ai abordées avec les différents docteurs que j’ai pu rencontrer. Comme vous l’imaginez, j’ai abandonné cet électrophysiologiste qui m’avait raccroché au nez. Et je suis allée de cardiologue en cardiologue pour trouver quelqu’un qui puisse comprendre ces problèmes ou qui puisse au moins comprendre pourquoi cela m’inquiétait. Et j’ai fini par trouver un excellent cardiologue et excellent électrophysiologiste qui m’a dit « Je n’avais jamais pensé à cette question, mais je comprends que ça puisse poser problème. Vous avez besoin de cet appareil, vous ne pouvez plus attendre. Mais je vais travailler avec vous, et on va trouver un moyen de résoudre au moins certains des problèmes qui vous inquiètent ».
Donc, l’une des choses que mon électrophysiologiste a faites c’est qu’il a appelé les hôpitaux, l’un après l’autre jusqu’à ce qu’il trouve un ancien pacemaker.
Il m’a expliqué que, ma défaillance cardiaque étant simple, j’avais seulement besoin d’un appareil qui surveillait les rythmes dangereux et qui m’enverrait une décharge en cas d’alerte. C’est un algorithme bien plus simple que celui des nouveaux appareils. Beaucoup des nouveaux appareils ont un algorithme complexe de stimulation pour des patients ayant une grande variété de problèmes. On peut tout à fait comprendre les raisons des compagnies médicales. Ces appareils sont très difficiles à faire. Ils fabriquent des produits de haute précision. Et s’ils peuvent utiliser ces appareils dans des cas plus variés alors tout est pour le mieux.
De plus vous ne pouvez pas savoir quels genres de complications les patients vont éventuellement développer. Donc, pour le moment, je n’ai aucun symptôme mais je pourrais en développer et c’est génial d’avoir cette technologie de stimulation. Mais mon cardiologue électrophysiologiste m’a dit : « Bon maintenant on voit que vous avez besoin de quelque chose de simple. Alors pourquoi ne pas vous trouver un ancien modèle d’appareil ? »
Donc j’ai actuellement un ancien appareil qui communique par couplage magnétique et non par technologie sans fil. Mais mon père a ce type de pacemaker et quand il entre dans une pièce du bureau des techniciens ils changent son pouls. Donc, avant même qu’il ne soit assis ils savent énormément de choses sur lui et ils ont la capacité de vraiment l’affecter. C’est incroyable. Mais comme vous pouvez le voir sur le dernier point de cette diapo ces appareils ont été hackés. En fait, un groupe de réflexion de plusieurs universités travaillant ensemble a montré qu’en utilisant du matériel disponible dans le commerce vous pouvez hacker ces appareils et en prendre le contrôle. Non seulement, Ils sont parvenus à déclencher des décharges ce qui est déjà terrifiant en soi…
— Une fois, mon pacemaker s’est déclenché par erreur et je peux vous dire, que c’est comparable à un coup de pied dans la poitrine. Ça vous met au tapis au moins pour quelques minutes. J’ai été forcée de m’asseoir, c’était si épuisant, la surprise et l’inquiétude m’ont forcée à dormir quelques heures pour m’en remettre. C’est très éprouvant.
… donc non seulement ils sont parvenus à envoyer une décharge mais ils ont également pu arrêter le traitement. Si l’appareil stimulait le pouls, ils pouvaient l’arrêter et beaucoup de gens ont besoin de stimulation pour rester en vie. Beaucoup de gens ne peuvent monter les escaliers sans cette stimulation. Mon père en fait partie. Ils ont également pu récupérer des informations clefs à partir de ces appareils comme les numéros d’identifications médicaux, les noms des médecins, les numéros de série… Beaucoup d’informations personnelles sont diffusées et il n’y a aucun chiffrement sur ces appareils. C’est plutôt inquiétant. Ils sont également parvenus à mettre les appareils en mode test ce qui a pour effet de consommer la batterie. Euh, la batterie s’épuise à un rythme bien plus rapide que dans des circonstances normales et ces appareils n’ont d’intérêt que s’ils ont de la batterie. Donc si la batterie lâche sur mon pacemaker il me faudra un nouvel appareil, ce qui signifie une opération.

…au bout du compte, personne à la FDA n’a vu le code source.

Donc ces appareils ont été hackés. Ces conclusions sont arrivées bien après mon diagnostic. Les médecins s’appuient beaucoup sur le fait que ces appareils ont l’agrément de la FDA aux États-Unis, et d’institutions similaires dans d’autres pays. En bonne avocate, j’ai fait des recherches sur la FDA et leur processus d’approbation des logiciels. Ce que j’ai découvert, c’est que la FDA ne vérifie pas systématiquement le code source des appareils sauf en cas d’erreur particulièrement visible en lien avec le logiciel, ils ne demandent généralement pas à le vérifier.
Il n’y a même pas de cahier des charges clair pour le logiciel et il y a des raisons pour ces décisions de la FDA, mais nous croyons que celle-ci devrait faire beaucoup plus qu’elle ne fait en réalité. L’absence de cahier des charges clair est lié au fait, d’après eux, que ces sociétés conçoivent des appareils très spécialisés avec des particularités propres à chaque fabricant. Il y a donc probablement des tests spécifiques à ces appareils et les mieux placés pour les réaliser sont ceux qui connaissent le mieux ces machines, c’est à dire leurs fabricants. Et il y a des allers-retours pour savoir s’ils ont fait les bons tests ou non, mais en vérité, au bout du compte, personne à la FDA n’a vu le code source.
Puisqu’ils ne le demandent pas, ils n’en ont même pas de dépôt. Donc si une panne catastrophique se produit chez Medtronic, par exemple, je ne sais pas s’il y a un dépôt canonique pour le logiciel auquel je pourrais avoir accès… et sans possibilité de mise à jour du logiciel sur mon appareil, je devrais être opérée pour en avoir un nouveau.

Pas de liberté vis-à-vis de mon propre corps

J’ai parlé lors d’un débat, avec un type dans la cyber-sécurité à la FDA et j’étais vraiment, vraiment nerveuse parce que j’ai fait tout ce que je pouvais en tant qu’avocate, j’ai fait toutes les recherches que j’ai pu sur la FDA mais je n’étais pas sûre que c’était vraiment le cas en pratique, donc j’ai projeté mes diapos et dit :
« John, dis-moi si je me trompe, mais voilà ce que je pense. Je pense que ça se passe comme ça… » Et j’ai continué avec une diapo sur le logiciel Libre et Open Source et pourquoi c’est tellement mieux et plus sûr. Dès qu’il a eu la parole, il a dit :
« Tout le monde pense que la FDA devrait faire comme ci, comme ça, mais nous n’avons pas les ressources et la FDA n’est pas là pour ça ».
Puis il a fait une pause, m’a regardée et juste quand j’allais… vous savez. Et il a dit: « Mais vous parlez d’autre chose. Vous parlez de laisser tous les autres passer en revue le code source, c’est quelque chose de très intéressant. Donc, s’assurer que les logiciels de nos appareils seront publiés revient à dire que tout le monde pourrait les relire. Mon père, qui a un pacemaker, est également ingénieur et un heureux programmeur. Il l’aurait probablement examiné.
Beaucoup ici connaissent des gens avec des pacemakers nous aurions fouillé dans ce code, assurément ! Une autre chose que j’ai découverte qui est un peu étrange c’est qu’aux États-Unis, comme ces appareils ont l’agrément d’une agence fédérale, les patients ne peuvent pas recourir à la State True Law. Il y a donc tout un éventail de recours auxquels ont normalement accès les patients, dont les fabricants n’ont même pas à s’inquiéter. Bon maintenant je ne dirais pas que les entreprises de matériel médical se moquent de savoir si les malades meurent, évidemment que non. Mais il y a toute une série de recours légaux qui ne sont pas disponibles. Vraiment étonnante cette étude, et j’ai tout résumé dans l’article que j’ai écrit : il est disponible sur le site web du centre juridique pour le logiciel libre.
Au bout du compte je n’ai pas de liberté vis-à-vis de mon propre corps. Je n’ai pas l’autorisation d’analyser le logiciel qui est implanté en moi. Il est littéralement connecté et vissé à mon cœur et je ne peux pas l’examiner. Ça me semble incroyable. Je n’en reviens toujours pas du fait que ça me soit arrivé. C’est un peu bizarre que moi, avocate au Software Freedom Law Center j’aie cette maladie cardiaque étrange, je l’admets. Mais c’est toujours hallucinant que je n’aie pas eu le choix. Le seul choix était entre une grande probabilité de mourir, ou se faire implanter cet appareil à l’intérieur du corps. J’espère que personne ici n’aura à faire ce choix, mais c’était vraiment, vraiment effrayant.

Voitures

Puis j’ai commencé à y réfléchir, et vous voyez, ce n’est pas seulement une question d’appareils cardiaques. Ça concerne tout ce dont dépendent nos vies dans notre société. Alors que j’y réfléchissais, j’ai pris conscience que cela concernait beaucoup plus de domaines de nos vies que je ne le pensais. Par exemple, les voitures. Comme ce groupe de réflexion universitaire qui a travaillé sur les appareils médicaux, soit dit en passant, si vous avez du temps, vous devriez lire cette étude. C’est fascinant, ils ont implanté cet appareil dans un sac de bacon ou de viande quelconque pour le stimuler et ils ont montré tout l’équipement facilement trouvable qu’ils ont utilisé pour modifier l’appareil.
Et la même procédure à été appliquée aux voitures. Et un autre groupe a montré qu’ils sont parvenus à pirater deux marques différentes, deux fabricants différents de voitures. Donc l’IEEE affirme qu’une voiture haut de gamme compte près de 100 millions de lignes de code. Donc si on revient à ce que le Software Engineering Institute a dit : « environ un bogue toutes les 100 lignes de code » ça fait un paquet de bogues, juste dans votre voiture. Et ce ce groupe a réussi à faire, tout ce que vous pouvez imaginer. Ils sont capable de faire accélérer, freiner la voiture. Ils ont réussi à contrôler chaque roue individuellement. Et ma partie préférée, juste pour s’amuser, je ne sais pas si vous pouvez voir, mais ils peuvent mettre des messages sur le tableau de bord et ils ont écrit pwnd et mis une petite émoticône avec un X pour les yeux. L’idée qu’ils aient pu prendre contrôle de deux marques différentes de voitures haut de gamme est vraiment incroyable pour moi.

La sécurité par l’obscurité ne fonctionne pas

Les machines à voter sont un autre domaine très sensible et nous en avons déjà parlé.
Beaucoup d’experts en sécurité ont parlé des problèmes avec leurs machines à voter. Aux États-Unis, nous comptons sur Diebold et beaucoup de fabricants privés. Nous avons eu des problèmes avec l’étalonnage. Je ne sais pas si vous avez vu ce dessin animé hilarant dans lequel des gens essayent de voter pour le bon candidat et le nom du candidat pour qui ils veulent voter se dérobe sur l’écran tandis que vous essayez d’appuyer dessus et à la fin, quel que soit votre choix, ça dit : « Vous vouliez voter pour l’autre candidat, n’est-ce pas ? N’est-ce pas ? »
Il est très difficile de le savoir parce que parfois nous n’avons pas de reçu pour vérifier, on ne sait même pas si notre vote a bien été enregistré et si on a pu voter pour notre candidat au final.
Vraiment bizarre car c’est la base de notre société et le pilier de notre démocratie. J’adore ce qu’ils ont fait au Brésil. Je ne sais pas si vous en avez entendu parler, mais le Brésil a dit : « On sait que ces logiciels ont des failles et des bogues ; alors on invite les équipes de hackers à venir, on vous donnera le code source et on donnera un prix à quiconque trouvera un moyen de trouver une faille pour s’introduire dans le système ». Sur toutes ces équipes, deux ont trouvé des bogues. Aucun d’eux ne pouvait affecter une élection, mais ils ont pu les corriger. Et ces hackers ont reçu une récompense. La démocratie est plus sûre. La sécurité par l’obscurité ne fonctionne pas. Je ne sais pas quand nous allons enfin le comprendre mais le Brésil a su le faire. Donc c’est possible.
Nos institutions financières, ouais c’est passionnant, les institutions financières sont un autre domaine dont nous avons récemment pu observer les déboires quand elles déclinent. De nombreuses institutions utilisent des logiciels et les marchés boursiers et le fonctionnement de nos banques. Toutes ces choses sont critiques vis-à-vis de la manière dont nous vivons. C’est plus sociétal, mais nous avons déjà vu qu’il y a des vulnérabilités de ce côté. Tout cela pour dire, et j’insiste : mon appareillage médical peut être contrôlé !

Nous avons atteint le point où le logiciel doit être utilisable par tous.

Nos voitures peuvent être contrôlées et détraquées et nos institutions financières compromises. Nous sommes tous d’accord, les logiciels socialement et vitalement critiques doivent être sûrs. Mais nous sommes à une période très intéressante. Car comment savoir quel logiciel est d’un intérêt vital ou socialement critique ? La manière d’utiliser les ordinateurs a changé si rapidement et récemment… Je suis ébahie par la quantité de gens qui se sont mis à utiliser des ordinateurs comme ils ne l’avaient jamais fait.
Ce ne sont plus seulement des personnes à l’aise avec la technologie. C’est tout le monde, nos grands-parents, tout le monde. Et nous utilisons les logiciels pour tout, c’est devenu notre manière de tout faire. Comment nous communiquons. Comment nous parlons au téléphone. Comment nous écrivons, faisons de l’art. Comment nous gérons les institutions scolaires et comment nous gérons nos vies. Nous construisons cette infrastructure et nous n’y réfléchissons même pas.
Beaucoup de personnes utilisent leurs téléphones pour suivre des choses comme leur entraînement ou leur régime. C’est très pratique parce qu’on peut suivre ce qu’on a mangé au fur et à mesure, ce qu’on a fait. Certains téléphones ont des podomètres, et c’est assez basique mais il existe déjà un logiciel pour l’iPhone qui peut communiquer avec une pompe à insuline et évaluer l’exercice et le régime en fonction du niveau de sucres dans le sang.
Et nous voilà revenus à l’appareillage médical. Vous avez un iPhone sur lequel vous comptez pour votre vie. Nous créons tout cette infrastructure, et nous avons envie d’y réfléchir voilà pourquoi l’ordinateur personnel est si important. C’est en quelque sorte là où tout prend son sens dans mon histoire personnelle et les raisons pour lesquelles j’ai quitté le Software Freedom Law Center que j’aimais et me rendait très heureuse d’y être avocate pour pouvoir travailler et être à la Fondation Gnome que j’ai également quittée.
Et je parle d’ordinateur entre guillemets parce que ça va des manières d’interagir avec nos ordinateurs à la façon dont nous gérons nos vies à travers des logiciels. Nous avons atteint le point où le logiciel doit être utilisable par tous. Je pense que tout le monde ici doit connaître une personne plus âgée qui, il y a quelque années, n’avait probablement jamais rien fait avec son ordinateur.
Ma mère était l’une de ces personnes. Je me rappelle qu’étant enfant, je lui répétais :
« Mais maman, regarde ces super jeux ! — m’intéressent pas »
Et je me rappelle qu’au collège, je lui disais :
« Maman, si nous pouvions parler par courriel, ça serait tellement mieux ! — (Rien)…
Je me rappelle à l’école de droit, je disais :
« Maman, je peux effectuer toutes ces recherches sur mon ordinateur, sans avoir à rester toute la journée à la bibliothèque, c’est génial ! — (Rien)…
Plus tard, j’ai essayé de lui dire « Maman, j’organise mon voyage avec mon ordinateur ». Soudain, elle était un peu intéressée et maintenant, avec tout ce qui est arrivé elle ne peut plus rien faire sans son ordinateur. Maintenant, son ordinateur est devenu… Premièrement, elle envoie des courriels et des messages à ses amis, elle gère ses voyages et ses finances. C’est spectaculaire pour moi parce que je n’ai pas utilisé ici mon père qui est ingénieur, mais ma mère était vraiment un peu technophobe. Et maintenant, elle aime Apple. ELLE AIME APPLE. Elle peut utiliser son ordinateur pour… elle n’a pas à y penser.
C’est super, et c’est très frustrant pour moi. Mais je suis contente qu’elle puisse maintenant utiliser un ordinateur et c’est quelque chose qu’elle possède maintenant. Elle ne me pose pas de questions, enfin si, elle le fait… Mais elle ne voit pas de raison pour laquelle ces appareils ne lui seraient pas destinés et elle est très représentative de la majorité de notre société. Et ces gens n’auraient pas été aussi capables il y a quelques années, de faire autant avec leurs ordinateurs. Nous devons séduire des gens parce que ce sont ceux qui choisissent d’adopter l’iPhone pour mettre en relation leur exercice et leur régime avec leur pompe à insuline.
C’est le genre de chose dont nous devons nous préoccuper parce que si nous ne rendons pas nos logiciels simple pour tout le monde, personne ne voudra les utiliser. Et nous avons aujourd’hui une opportunité, une fenêtre qui se referme lentement parce que nous faisons maintenant des choix avec lesquels nous allons devoir vivre longtemps. Nous créons des habitudes, nous créons des attentes et nous établissons la mesure de notre société concernant ce qui est ou non acceptable pour un logiciel.
Vous êtes ici, à LinuxConfAu, vous connaissez les raisons pour lesquelles vous devriez utiliser des logiciels Libres et Open Source. Vous êtes ici pour toutes ces raisons y compris parce que c’est vraiment amusant. Nous avons passé un bon moment ici, et appris toutes sortes de choses vraiment cool mais derrière tout ça, la source d’où proviennent toutes ces raisons, c’est la Liberté.
Le logiciel Libre et Open Source n’est pas juste un marché profitable c’est aussi la bonne chose à faire. Donc lorsque nous parlons de nos appareils cardiaques, nous parlons de nos machines à voter et ensuite de la manière de vivre nos vies et de l’infrastructure par laquelle nous communiquons.
Nous voyons que le logiciel Libre et Open Source est exactement ce qu’il faut à notre société et pour l’apporter aux autres gens nous devons nous assurer que c’est facile et simple à utiliser pour eux.
(…)
Nous devons franchir la barrière, nous devons fournir des logiciels utilisables par des gens qui sinon ne pourraient pas s’en servir. Nous devons nous assurer que nos ordinateurs sont accessibles à tous parce que nous ne pourrons pas créer la bonne infrastructure pour toute la société si nous n’embarquons pas ces gens avec nous. (…)
Vous savez, nous avons la technologie, c’est bien agréable. Je n’ai plus vraiment besoin de bidouiller mon bureau. Je suis passée sur Gnome-Shell, et c’est brillant et très bien fait, j’ai à peine besoin de lignes de commande pour les choses en lien avec mon environnement de travail et uniquement quand je me sens bloquée. Ce n’est pas pour tout le monde, mais nous devons faire le choix du libre et des plateformes ouvertes, nous avons besoin de développer là-dessus parce que c’est le seul moyen que nous ayons de créer des sociétés meilleures et plus sûres. C’est le seul moyen de créer un monde où nous saurons que nos logiciels seront revus et qu’ils auront leur intégrité. Nous devons construire nos communautés dans l’espace non lucratif car nous devons établir ce très haut degré de confiance. Nous devons réinvestir notre idéologie dans le logiciel libre. Pour aller un peu plus loin je dirais : il ne s’agit pas de terminologie, mais d’idéologie. Nous devons vraiment penser à rendre le monde meilleur car nous le pouvons et nous le devons. Choisissons les logiciels libres et ouverts pour nous-mêmes et pour notre société.