Source : Impression 3D : une Américaine conçoit son propre disque vinyle (Numerama)

Crédit : Simon Gee Giraudot (Creative Commons By-Sa)

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 ?

Sources :

• le pape twitte son premier message (Numérama)
• Fier d’échapper au fisc (Numérama)

Crédit : Simon Gee Giraudot (Creative Commons By-Sa)

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

Matériels incompatibles, absence d’interopérabilité, formats fermés, logiciels propriétaires… des motifs de colère et de combats familiers de la communauté libriste. Ces problématiques sont cependant un peu désincarnées aux yeux de la majeure partie de nos concitoyens du Net tant qu’ils n’ont pas été personnellement confrontés à des blocages fort irritants.

Une situation concrète est le point de départ du coup de gueule de Terence Eden. Quant à la véhémence de ses propos, elle est à la mesure de l’urgence. Car dans la guerre en cours, celle de notre liberté de choix, Apple, Amazon, Google et quelques autres ont plusieurs longueurs d’avance : des millions d’utilisateurs sont déjà entrés de leur plein gré dans des prisons numériques dorées.

Dans cet environnement, nous ne sommes plus propriétaires des fichiers médias que nous avons pourtant achetés, nous n’en sommes que les usagers à titre révocable et temporaire ! Autant dire que nous perdons la possibilité de réutiliser nos biens dès lors que nous changeons de support matériel. Du disque vinyle au CD-ROM et du DVD au fichier numérique, nous avons déjà vu comment un saut technologique nous contraint à acheter de nouveau. Eh bien cette farce au goût amer se joue maintenant sur la scène des médias numériques.

Parviendrons-nous à libérer nos médias captifs du matériel ? Il faudra certes bien plus qu’un coup de gueule comme celui qui suit, mais il n’est pas mauvais qu’un cri de colère agite un peu nos esprits de consommateurs endormis.

Je ne veux pas faire partie de votre putain d’écosystème

I Don’t Want To Be Part of Your Fucking Ecosystem

Terence Eden – 23 novembre 2012 – Blog personnel
(Traduction framalang & les twittos : Gatitac, Zii, ga3lig, Stan, Isdf, Slystone, Quartz, Coyau, Goofy, Exirel, greygjhart)

Je discutais avec un ami qui exprimait une opinion que je trouve assez répandue :

— Alors oui, j’aimerais bien passer à Android, mais tous mes données sont dans iTunes.

J’ai découvert que le problème, ce ne sont pas les applications : les racheter est pénible, mais la plupart sont gratuites. Le problème, ce sont les données qui emprisonnent les utilisateurs avec des services dont ils ne veulent plus.

Les musiques, les films, les séries TV, les abonnements et les podcasts. Tout est fermé à double tour dans l’étroit écosystème d’Apple. C’est une façon bien pensée d’enchaîner les gens à leur matériel.

Imaginez, ne serait-ce qu’un instant, que votre lecteur de DVD Sony ne puisse lire que des films de chez Sony. Si vous décidiez d’acheter un nouveau lecteur de marque Samsung par exemple, aucun de ces contenus ne serait lisible sur votre nouvel appareil sans un sérieux bidouillage.

Voilà les hauts murs derrière lesquels tant de grandes entreprises voudraient bien nous enfermer. Et je trouve que ça pue.

Sur un réseau de téléphonie mobile au Royaume-Uni, on peut utiliser le téléphone de son choix. Le matériel et les services sont complètement indépendants les uns des autres. Cela suscite de la concurrence parce que les consommateurs savent que s’ils sont mécontents de HTC, ils peuvent passer à Nokia et que tout fonctionnera comme avant.

Mais si tous vos contacts, vos services de divertissement et sauvegardes sont enchaînés à HTC, eh bien, vous êtes juste dans la merde si vous voulez changer.

Je veux assister à une séparation complète de l’Église et de l’État. Le matériel devrait être séparé du logiciel. Le logiciel devrait être séparé des services. Je veux pouvoir regarder des films achetés chez Nokia sur un système Google Android tournant sur un appareil Samsung, et ensuite sauvegarder le tout sur Dropbox.

C’est comme cela que ça fonctionne, plus ou moins, dans le monde du PC. Je ne comprends pas pourquoi cela n’est pas pareil dans le monde des tablettes et des smartphones. Pourquoi est-ce que j’achèterais une tablette qui ne fonctionnerait qu’avec le contenu d’un seul fournisseur ? Que ce soit Amazon, Microsoft ou Apple, ils constituent un dangereux petit monopole qui fera augmenter les prix et diminuer la qualité.

Bon, je sais. Le mantra du « It just works » (« Ça marche, tout simplement » ). Je suis légèrement dégoûté de devoir configurer ma tablette pour qu’elle parle à mon NAS, puis de faire en sorte que mon téléviseur fonctionne avec les deux à la fois. Cette situation n’est pas due à mes équipements multimédias qui viennent de différents fabricants, elle est plutôt due à ces différents fabricants qui n’utilisent pas de standards ouverts.

J’ai peur de ce qui arrivera lorsqu’un fournisseur mettra fin à un service. Je rigole à l’idée d’une éventuelle faillite d’Apple : même s’ils restent solvables, qu’est-ce qui les empêchera de supprimer tous vos achats de films et de musiques ? Après tout, ils ont fermé leur service Mobile Me quasiment sans avertissement et détruit toutes les données que leurs clients payants hébergeaient chez eux.

Adobe a fermé ses serveurs de DRM après un court préavis de 9 mois, en empêchant de fait quiconque de lire les livres pourtant achetés (Amazon peut vider votre Kindle).

Google a emmené Google Video au bûcher et lui a tiré une balle dans la tête — tout comme Buzz, Wave et qui sait combien d’autres produits.

Microsoft a mis en place PlaysForSure, puis l’a laissé mourir, piégeant ainsi des millions de fichiers musicaux sur des appareils qui ne sont plus pris en charge.

Donc peut-être vais-je m’en tenir à Google et espérer que mon téléviseur Google communiquera avec mon téléphone Google pendant que je regarderai des vidéos Google Play et que j’écouterai des musiques Google Play sur mon ChromeBook Google que je partagerai sur Google+ et que j’achèterai avec Google Wallet. Et je leur enverrai la prière du geek : « S’il vous plaît, ne décidez pas que ce service bien pratique n’est pas rentable ».

Je veux simplement que l’on s’entende tous. Je veux que mes équipements disparates se parlent. Je ne veux pas vivre dans une maison où chaque composant doit être fabriqué par une unique entreprise sous peine de ne rien voir marcher correctement. Je ne veux pas être bloqué ni devoir utiliser un mauvais produit parce que c’est le seul à offrir un certain service.

Je ne veux pas de vos jouets qui ne fonctionnent qu’avec les piles de votre marque.

Je ne veux pas faire partie de votre putain d’écosystème.

Crédit photo : Luke Addison (Creative Commons By-Sa)

Source : DRM espion : Microsoft veut compter les spectateurs chez vous ! (Numerama)

Crédit : Simon Gee Giraudot (Creative Commons By-Sa)

Nous imaginant technophiles béats, les gens sont souvent surpris de la prise de position de la grande majorité des partisans du logiciel libre en défaveur du vote électronique (quand bien même on ait accès au code source qui pilote la machine et le processus, ce qui semble être du bon sens mais non partagé).

Ce n’est pas l’expérience ci-dessous, au moment même où se déroulent les élections présidentielles américaines, qui risque de nous faire changer d’avis.

Comment j’ai hacké une machine de vote électronique

Roger Johnston (raconté par Suzanne LaBarre) – 5 novembre 2012 – PopSci.com
(Traduction : Zii, ehsavoie, plink, KoS, aKa, lgodard, MF, Ag3m, greygjhart)

How I Hacked An Electronic Voting Machine

De quoi avez-vous besoin pour truquer une élection ? Des connaissances basiques en électronique et 30 dollars d’équipement de RadioShack suffisent, révèle le hackeur professionnel Roger Johnston. La bonne nouvelle : nous pouvons empêcher cela.

Roger Johnston est à la tête de la « Vulnerability Assessment Team » au Laboratoire National d’Argonne. Récemment, lui et ses collègues ont lancé une attaque de sécurité sur des machines de vote électronique pour montrer la facilité déconcertante avec laquelle quelqu’un peut trafiquer les votes. Encore plus surprenant : les versions de ces ordinateurs seront présentes dans les bureaux de vote de toute l’Amérique ce mardi. Le magazine Harper a rapporté recemment que l’écran tactile Diebold Accuvote-TSX va être utilisé par plus de vingt-six millions de votants dans ving États et que l’ordinateur de vote à bouton pressoirs Sequoia AVC va être utilisée par presque neuf millions de votants dans quatre États. Dans cet article, Johnston révèle comment il a hacké ces machines — et que c’est à la portée du premier venu, du lycéen à la grand-mère de 80 ans.

La Vulnerability Assessment Team du Laboratoire National d’Argonne scrute une large variété d’équipements électroniques — serrures, sceaux, tags, contrôle d’accès, biometrie, sécurité des cargaisons, sécurité nucléaire — pour tenter de trouver des vulnérabilités et repérer des solutions potentielles. Malheureusement, on n’alloue pas assez de budget à l’analyse de la sécurité des élections dans ce pays. Alors nous nous sommes penchés dessus, histoire de nous occuper, un samedi après-midi.

On appelle cela une attaque de l’homme du milieu. C’est une attaque classique sur les appareils de sécurité. On implante un microprocesseur ou un autre appareil électronique dans la machine de vote, et cela vous permet de contrôler le vote et de tricher ou non. Basiquement, on interfère avec la transmission de l’intention du votant.

Nous avons utilisé un analyseur logique. La communication digitale est une série de zéros et de uns. Le voltage augmente, diminue. Un analyseur logique rassemble les voltages oscillants entre haut et bas et vous présentera ensuite les données digitales dans une variété de formats. Mais il y a plein de manières de faire. Vous pouvez utiliser un analyseur logique, un microprocesseur, un ordinateur — en gros, n’importe quoi qui vous permette de voir l’information qui est échangée et ensuite vous laisse comprendre ce qu’il faut faire pour imiter l’information.

Nous avons donc espionné les communications entre le votant et la machine. Dans un cas, le votant appuie sur des boutons (c’est une machine à voter avec des boutons poussoirs) et dans l’autre, il interagit avec un écran tactile. Puis, nous avons écouté les communications entre le logiciel de la machine et le votant. Disons que je veux que Jones gagne l’élection, et que vous votez pour Smith. Alors, mon microprocesseur va dire à la machine de voter pour Jones si vous essayez de voter pour Smith. Mais si vous votez pour Jones, je n’interviendrai pas dans les communications. Parfois on bloque les communications, parfois on les déforme, parfois on ne fait que les regarder et les laisser passer. C’est ça l’idée. Deviner quels sont les échanges en cours, puis les modifier si besoin est, y compris ce qui sera présenté au votant.

Nous pouvons faire ceci car la plupart des machines, autant que je sache, ne sont pas chiffrées. C’est simplement un format de communication standard. Il est donc très simple de deviner les informations échangées. N’importe quelle personne qui fait de l’électronique numérique — un amateur ou un fan d’électronique — peut le deviner.

Le dispositif que nous avons intégré dans la machine à écran tactile valait en gros 10 $. Si vous voulez une version de luxe où vous pouvez le contrôler à distance jusqu’à environ 800 mètres, il vous en coutera 26 $. Ce n’est pas très cher. Vous pouvez trouver ça chez RadioShack. Je suis allé à des salons scientifiques dans des lycées où les gosses avait des projets avec des processeurs plus sophistiqués que ceux nécessaires pour truquer ces machines.

Parce qu’il n’y a pas de financements pour ce genre de tests de sécurité, il faut compter sur des gens qui achètent des machines d’occasion sur eBay (dans ce cas l’écran tactile Diebold Accuvote TS Electronic Voting Machine et la machine à boutons Sequoia AVC Advantage Voting Machine). Ces deux machines étaient un peu vieilles, et nous n’avions pas de manuel ou de schéma de circuits. Mais, dans le cas du Sequoia AVC, nous avons deviné comment elle marchait en moins de deux heures. En deux heures nous avions une attaque viable. L’autre machine nous a pris un peu plus de temps car nous ne comprenions pas comment l’affichage sur un écran tactile fonctionnait. Nous avons dû donc apprendre, mais ce n’était qu’une question de jours. C’est un peu comme un tour de magie, vous devez le pratiquer beaucoup. Si nous avions pratiqué longtemps, voir mieux, si quelqu’un de très bon avait pratiqué pendant deux semaines, nous aurions mis 15 à 60 secondes pour exécuter ces attaques.

Les attaques nécessitent un accès physique à la machine. C’est facile pour les personnes en interne qui les programment pour une election ou les installent. Et nous pouvons supposer que ce n’est pas si difficile pour des personnes extérieures. Beaucoup de machines à voter gisent dans la cave de l’église, le gymnase ou le préau de l’école élémentaire, sans surveillance pendant une semaine ou deux avant l’election. Généralement elles ont des serrures très bon marché que n’importe qui peut ouvrir ; quelquefois elles n’en ont même aucune. Personne ne s’identifie auprès des machines quand il prend son poste. Personne n’est chargé de les surveiller. Leurs scellés ne sont pas si différents des dispositifs anti-fraude sur les paquets de nourriture et les médicaments en libre service. Falsifier un produit alimentaire ou un médicament, vous pensez que c’est difficile ? Ça ne l’est vraiment pas. Et un grand nombre de nos juges d’élections sont de petites vieilles à la retraite, et, Dieu les garde, c’est grâce à elles que les élections marchent, mais elles ne sont pas forcement fabuleusement efficaces pour détecter des attaques subtiles de sécurité.

Formez les personnels chargés de la vérification des scellés, et ils auront une chance de détecter une attaque raisonnablement sophistiquée. Faites des vérifications sur les personnes en interne et cette menace sera bien moins sérieuse. Dans l’ensemble il manque une bonne culture de la sécurité. Nous avons beau avoir des machines de vote avec des défauts, avec une bonne culture de la sécurité nous pouvons avoir des élections sans fraude. D’un autre côté, on peut avoir des machines fabuleuses, mais sans une culture de la sécurité à la hauteur, cela ne servira à rien. Il faut vraiment prendre du recul. Notre point de vue est qu’il sera toujours difficile d’arrêter un James Bond. Mais je veux faire avancer les choses jusqu’à un niveau où au moins ma grand-mère ne puisse pas truquer les élections, et nous en sommes encore loin.

Crédit photo : Steve Jurvetson (Creative Commons By)