Une récente passe d’armes sur le bien fondé d’offrir des iPad à des collégiens en Corrèze avait fait couler beaucoup d’encre dans les commentaires du Framablog.

Nous récidivons aujourd’hui en laissant de côté les arguments du libre pour se concentrer uniquement sur la pertinence de la tablette en milieu scolaire.

Trop cool pour l’école : 7 raisons pour lesquelles les tablettes ne devraient PAS être utilisées dans l’enseignement

Too cool for school: 7 reasons why tablets should NOT be used in education

Donald Clark - 24 février - Blog perso
(Traduction : Moosh, Max, DansLeRuSH, CedricA, Sphinx, Mila Saint Anne, Catalaburro, VifArgent, goofy, @paul_playe, Miles, Alpha + anonymes)

Est-ce que les élèves en achètent ? NON

J’écris ceci sur un netbook. J’ai un iPad mais je ne rêve pas de m’en servir pour faire des recherches, prendre des notes, écrire ou pour mon travail. Je m’en sers à la maison comme une sorte de matériel de découverte, davantage pour « chercher, regarder et découvrir » que pour « écrire, créer et travailler ». Mes enfants ne s’en servent jamais. Quand je leur demande si certains de leurs camarades en ont acheté, ça les fait rire. De toute façon, « pour le même prix on a des ordinateurs portables ». Ils veulent un truc pour aller sur Facebook, lire leurs courriels, éditer du son ou de la vidéo, jouer, programmer et télécharger. Sur mes deux garçons, l’un a un MacBook, l’autre un PC survitaminé. Je ne m’en sers jamais dans la mesure où j’ai surtout besoin d’écrire et de communiquer — c’est simplement trop malcommode et limité.

Est-ce que les étudiants en achètent ? NON

Que ce soit à l’école, au lycée ou à l’université, il semble que les jeunes préfèrent les ordinateurs, que ce soit pour prendre des notes, écrire des devoirs ou autres choses. Ils veulent la souplesse d’un ordinateur complet, pas un appareil qui ait un look sympa. Les tablettes n’ont pas envahi nos bibliothèques. Les étudiants font des recherches, communiquent et, par-dessus tout, ont besoin d’écrire des quantités non négligeables de texte, voire de code. Les tablettes ne le font pas pour eux.

Est-ce que les employés s’en servent ? NON

Et puis il y a l’entreprise. Je n’ai pas encore vu une entreprise qui ait décidé de généraliser les iPad ou des tablettes si ce n’est pour des raisons ésotériques tournant autour de leur image de communicants. Encore une fois, les gens au travail veulent un ordinateur complet et connecté qui leur permet de faire des tâches fonctionnelles rapidement. Quand je vois des iPad sur un lieu de travail, ils sont généralement entre les mains de personnes d’un certain âge qui prennent des notes (lentement) avec un seul doigt, qui se débattent pour télécharger des documents et des feuilles de calcul et qui sont souvent les mêmes qui demandent une copie papier de tous les documents de travail avant la réunion. Un netbook à 299 £, pas de papier : ça me satisfait.

Alors pourquoi cet engouement pour les tablettes et les iPad dans les écoles ?

Mis à part ces motivations d’achat, pourquoi cette obsession des iPad ? Je n’ai pas été séduit et je n’achèterai pas le package. Si comme moi vous considérez que l’enseignement doit faire émerger des individus autonomes qui peuvent construire une vie dans laquelle ils se sentent en confiance avec la technologie, acquièrent des compétences grâce à elle et en retirent le maximum à la maison ou au boulot, alors un iPad ou une tablette est un mauvais choix et voici selon moi pourquoi…

1. L’écriture

La capacité à écrire se retrouve au cœur de l’éducation primaire, secondaire et supérieure. Les enfants ont besoin d’être encouragés à beaucoup écrire pour apprendre, que ce soit en prenant des notes, en rdigeant des devoirs, des rapports, des manipulations de données, des écrits d’invention ou des dissertations. Les claviers des écrans tactiles sont inconfortables avec des taux d’erreur élevés et la manière de sauvegarder, travailler en réseau, ou d’imprimer est tortueuse. On revient à l’ardoise victorienne, voire bien pire en fait. J’en possède une et je trouve qu’il est plus facile d’écrire sur cette ardoise plutôt que de taper sur un iPad. Fait intéressant, en leur fournissant un appareil si hostile à la création de l’écriture, vous pouvez faire passer l’envie d’écrire aux élèves débutants. Répondre à cela en disant qu’il est possible d’acheter des claviers pour les tablettes revient à admettre une défaite. C’est répondre que les tablettes ne fonctionnent que si vous les transformez en ordinateur. À quels coûts supplémentaires ?

2. La créativité

Les tablettes sont faites pour consommer du contenu, les ordinateurs (portables) permettent la création de contenus. Ce n’est pas parce que les choses sont belles sur un iPad qu’elles sont faciles à faire avec celui-lui. Les outils de création dans la plupart des domaines de l’art et du design sont très différents des outils de diffusion. Essayez d’utiliser Photoshop, Illustrator ou encore 3D Studio sur une tablette. Essayez de faire une sélection pixel par pixel, d’utiliser des calques, de faire des ajustements précis. L’écran n’est tout simplement pas assez grand pour ce genre de travail. C’est un appareil que l’on tient à la main, pas un outil de travail. Les tablettes sont rares dans le monde du travail où l’écriture demeure nécessaire. La maîtrise du clavier et les compétences sur d’autres appareils dont vous pouvez avoir besoin dans la vraie vie ont peu de chances d’être acquises grâce à l’iPad.

3. L’informatique, les TIC (Technologies de l’Information et de la Communication), la programmation

Peu importe le but de l’apprentissage de l’informatique, de la programmation ou des technologies de l’information à l’école, je ne pense pas que l’iPad ou les tablettes soient appropriés. Apprendre à manipuler un tableur sur un iPad est pénible. Vouloir apprendre à programmer avec, ridicule. Quelle personne sensée voudrait utiliser une interface tactile pour programmer, ce qui implique beaucoup d’écritures détaillées, supprimant, ajoutant des lignes, aussi bien que dans un environnement plus ouvert ?

4. Un appareil de consommation, pas d’apprentissage

Par dessus tout, un iPad est un outil de consommateur, fait pour lire et pas pour écrire. Il a un rôle à jouer dans les apprentissages, particulièrement au niveau pré-scolaire pour les tout-petits, mais au-delà, il n’y a pas d’argument sérieux pour justifier un investissement de grande ampleur dans ce genre de matériel. La meilleure preuve en est que quand les élèves ou les étudiants s’équipent en informatique, ils n’achètent pas de tablettes. Ils achètent des ordinateurs de bureau, des netbooks ou des ordinateurs portables.

5. Inadéquation avec les besoins des enseignants

Il y a l’exemple d’une école qui avait échangé ses ordinateurs portables contre des tablettes, et qui souhaite aujourd’hui faire machine arrière. « La salle des profs se lamente », car les problèmes pédagogiques sont évidents. D’un point de vue technique, les enseignants ont vécu cela comme un cauchemar. La plupart des enseignants et le matériel pédagogique qu’ils utilisent s’appuient sur Word et PowerPoint, et l’utilisation de tablettes a entraîné des problèmes d’incompatibilité. Certains professeurs ont dû faire héberger leur contenu à l’extérieur de l’établissement, ce qui a posé des problèmes d’accès aux ressources. Il y a également des problèmes d’affichage avec l’écran au format 4:3 des iPad, des problèmes d’accès à Internet au travers des proxy. Mais le principal problème reste la capacité de stockage et le manque de ports USB. Cela implique l’utilisation de procédures plus complexes, comme par exemple l’usage de DropBox et de tous les problèmes afférents. Les tablettes ne sont pas des outils adaptés aux enseignants. Sans une véritable connaissance des logiciels et des besoins des enseignants, il n’y a aucune plus-value pour les apprenants.

6. Le prix élevé

Les iPad sont chers à l’achat et à l’entretien, et sont compliqués à mettre en oeuvre en termes de réseau et de périphériques. Ils sont conçus pour être utilisés à la maison et non à l’école, dans les laboratoires ou les salles de classe. Ce constat a été dressé par l’Honnywood Community Science School, une école qui vient tout juste de se créer, qui a acheté 1200 iPad pour un montant de 500000€ , dont la moitié sont maintenant inutilisables. Il existe donc une réelle interrogation sur la solidité de la technologie à l’école et dans les sacs des élèves, où ces équipements sont malmenés, tombent et sont rayés. Pire encore, 20% de ceux qui ont été envoyés en réparation en sont à leur deuxième ou troisième retour au SAV. Bien qu’il ait été demandé 50€ aux parents par tablette, ces dernières coûtent en réalité 450€ et les élèves ne semblent pas prendre particulièrement soin de quelque chose qu’ils n’ont pas acheté. Le coût final, quand on ajoute les réparations, est encore plus élevé que prévu.

7. Des projets vaniteux

Un personne très bien informée, ayant participé à une réunion dans les hautes sphères du gouvernement qui a décidé d’introduire les tablettes à l’école, m’a dit que cela avait été pénible et bordélique. Les tablettes, données par une entreprise informatique, furent bien livrées à l’école, où le chef de l’établissement les dissimula aux autres enseignants. C’est exactement comme cela qu’il ne faut PAS introduire les nouvelles technologies dans les écoles : acheter des appareils à la mode en grande quantité, les distribuer dans de belles boites et espérer que tout ira bien. C’est le danger avec ces projets fondés sur des tablettes, nous nous basons rarement sur une analyse poussée pour choisir la technologie la plus appropriée, nous avons plutôt tendance à nous baser sur le fait qu’Apple est à la mode ou sur les conseils des fans de cette marque. Nous devons éviter de faire comme tout le monde et de mettre en place des projets prétentieux qui présupposent que ce qui est cool pour les consommateurs adultes sera cool pour l’école.

J’ai passé toute ma vie d’adulte à encourager l’utilisation des technologies dans l’enseignement mais je veux être sûr qu’on ne se tire pas une balle dans le pied avec des projets qui n’ont pas pris en compte les sept points ci-dessus. Pour être honnête, je ne suis pas du tout certain du bien-fondé d’une technologie imposée aux salles de classe. Laissons les enseignants enseigner et, si vous introduisez ce genre de choses, réservez plutôt une bonne part du budget à leur formation.

Conclusion

Une bonne technologie a toujours du style, et les iPad en ont à revendre, mais c’est un style qui attire les adultes, pas les enfants. Je peux comprendre l’utilité des tablettes pour des jeunes enfants, de 3 à 9 ans, et peut-être ayant des besoins spécifiques. Mais une fois acquis les rudiments, les iPad sont un luxe que les écoles ne peuvent pas se permettre. Ils ne sont pas non plus souhaitables, au regard de l’apprentissage que dispensent les écoles à grande échelle. Ces initiatives sont souvent menées avec un but technologique et non pédagogique.

Remarquez que cela ne constitue pas une attaque envers les iPad et les tablettes. J’en ai acheté une et je trouve ça bien. C’est un ensemble d’arguments contre leur utilisation dans l’enseignement. Les élèves à l’école, au lycée et à l’université ne les achètent pas avec leur argent. Pas plus qu’il ne les utilisent lorsqu’ils en ont le choix. Même s’ils étaient fournis, ces outils sont largement inadaptés à l’écriture, aux besoins de l’informatique, des technologies de l’information, de la programmation ou encore des autres tâches lors du cursus scolaire. Cela est principalement lié au fait que ce sont des appareils de consommation, passifs et non pas actifs, utilisés pour lire et non écrire, avec une mise en avant de la consommation et non de la création. Ils ne sont certainement pas adaptés à l’éducation.

P.S. : Je suis conscient que je passe peut-être à côté de quelque chose mais j’ai hâte de voir les recherches sur les améliorations effectives dans les acquisitions, par opposition aux enquêtes qualitatives et aux questionnaires.

Crédit photo : Urban Hippie Love (Creative Commons By-Sa)

Riposte graduée, sécurisation de son réseau, oubli systématique du copyleft, répression qui s’accompagne d’une prévention propagande… les Américains sont sur le point de lancer leur propre Hadopi, qui porte le nom chantant de Copyright Alert System.

Pourtant on ne peut pas dire que ce soit un franc succès chez nous, n’est-ce pas Monsieur Lescure ?

Ici comme ailleurs, de grands mais vains efforts pour transformer la « génération du partage » en une « génération pirate » !

La propagande du copyright s’offre un nouvel acteur : votre fournisseur d’accès à Internet (FAI)

The Copyright Propaganda Machine Gets a New Agent: Your ISP

Corynne McSherry - 25 février - EFF.org
(Traduction : Moosh, goofy, Alpha, LGT + anonymes)

Voilà un moment qu’on le redoutait, la machine de surveillance du copyright connue sous le nom de Copyright Alert System (CAS) est finalement en marche. Le CAS est un accord entre les plus grands fournisseurs de contenus et les principaux fournisseurs d’accès (FAI) qui vise à surveiller les réseaux de peer-to-peer pour détecter la violation de copyright et de sanctionner les abonnés supposés coupables par des rappels à l’ordre éducatifs voire une réduction importante de la vitesse de connexion.

Pour preuve de ce lancement, le centre d’information sur le copyright (Center for Copyright Information ou CCI), qui administre le programme, a refondu son site web. Ce site est censé contribuer à la sensibilisation des internautes sur le système et le copyright. Malheureusement, le site est rempli de signes qui indiquent que cette campagne va dériver.

Par exemple, concernant le processus de ciblage des utilisateurs, le site explique :

Avant d’envoyer une nouvelle alerte, un processus rigoureux permet de s’assurer que le contenu concerné est bel et bien protégé par un copyright et que la notification est envoyée au bon abonné.

Le simple fait que le contenu soit soumis à copyright ne signifie pas que son partage est illégal. Il serait préférable d’avoir un processus rigoureux afin de s’assurer que l’utilisation identifiée constitue bien une violation. Il serait encore mieux d’avoir un processus qui soit approuvé par une entité parfaitement indépendante, suivi d’un examen public du résultat global.

Et puis il y a ces quelques pépites :

La CCI encourage tous les utilisateurs à sécuriser leurs réseaux privés, mais c’est encore plus important pour ceux ayant reçu un avertissement à la violation de copyright (Copyright Alert).

En d’autres termes, si vous recevez un avertissement vous feriez mieux de verrouiller votre réseau, et vite. Comme nous (NdT : l’Electronic Frontier Foundation) l’avions expliqué, il semble que cela ait pour objectif de saper le mouvement pour un Wi-Fi ouvert, même si l’accès libre sans fil est largement reconnu comme bénéfique au public.

La responsabilité incombe aux abonnés de s’assurer que leur accès Internet n’est pas utilisé pour violer le copyright.

Pas tant que ça, au moins, pas d’après les lois pour le copyright, pas tant que des conditions supplémentaires ne sont pas remplies. Nous n’avons pas souhaité faire partie de la brigade de surveillance du copyright, mais si votre FAI a signé l’accord (AT&T, Cablevision, Comcast, Time Warner, and Verizon), vous avez souscrit à cette surveillance.

Et puis on retrouve les abus classiques et orientés de leur approche du copyright :

Quand vous créez un poème, une histoire ou une chanson, elle vous appartient, et personne d’autre ne peut s’en servir sans votre permission.

Non plus : grâce au principe de l’usage raisonnable (fair use) d’autres personnes peuvent utiliser les œuvres que vous créez de différentes façons. C’est grâce à cela que nous sommes assurés du bon usage du copyright, permettant ainsi la créativité et l’innovation plutôt qu’une entrave.

Tout aussi inquiétant : le site du CIC renvoie les utilisateurs vers la Copyright Alliance pour en apprendre plus sur l’histoire du copyright. La Copyright Alliance est loin d’être une “ressource” neutre - il s’agissait de l’un des principaux acteurs du combat pour faire voter SOPA et elle reste un fervent défenseur du copyright tout-puissant.

En conclusion, le CIC entrera probablement en partenariat avec iKeepSafe pour développer un cursus sur le copyright au sein des universités publiques de Californie. Qui pourrait s’appeler « Soit un créateur : la valeur ajoutée du copyright ». Basé sur ce que l’on voit venir depuis longtemps, ce cursus devrait pouvoir aider les plus jeunes à comprendre les enjeux des copyrights. Par ailleurs, cela apprendra aux plus jeunes comment les droits sur la création peuvent être acquis et les étapes de vérification avant l’utilisation de la création de l’oeuvre.

Loin de nous l’idée de faire notre propre publicité, mais l’EFF a développé un cours visant à expliquer ce que la loi sur le copyright permet et interdit, et qui, nous l’espérons, encourage les étudiants à réfléchir de manière critique sur la créativité, l’innovation et la culture. De plus, il est sous licence CC (Creative Commons), ainsi, le CIC ne devrait pas hésiter à s’en servir, ça lui économisera du temps et de l’argent.

Dans le même temps, nous sommes déçus, pour ne pas dire désagréablement surpris, de l’approche du CIC en matière de surveillance et d’éducation. Suivez-nous pour plus d’informations à venir sur le CAS et ce que vous pouvez faire pour vous y opposer.

Crédit photo : Martin Fisch (Creative Commons By-Sa)

Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framalang : satanas_g, Sphinx, Sky, Julius22, peupleLà, lamessen, goofy

Du débutant au professionnel

Jonathan Riddell

Jonathan Riddell est développeur KDE et Kubuntu, actuellement employé par Canonical. Quand il n’est pas devant un ordinateur, il fait du canoë sur les rivières d’Écosse.

Il y avait un bogue dans le code. Un bien méchant en plus : un plantage sans enregistrement des données. C’est bien là le problème dès qu’on regarde le code, on trouve des trucs à réparer. C’est facile de s’impliquer dans le logiciel libre ; le plus dur est d’en sortir. Après le premier bogue réparé, il y en a d’autres, et de plus en plus, tous à portée de main. Les corrections de bogues mènent à l’ajout de fonctionnalités, ce qui mène à la maintenance de projet, ce qui mène à faire fonctionner une communauté.

Tout a commencé en lisant Slashdot, cette masse d’actualité geek et technique peu filtrée avec des commentaires de quiconque peut recharger assez vite pour être en haut de liste. Chaque actualité était intéressante et excitante, apportait un éclairage nouveau sur le monde de la technologie qui finissait par me fasciner. Je n’avais plus à accepter ce qui m’était donné par de grandes entreprises de logiciels, je pouvais voir là, dans la communauté du logiciel libre, le code se développer devant moi.

En tant qu’étudiant, il était possible de finir les exercices donnés par les professeurs très rapidement. Mais les exercices ne sont pas des programmes terminés. Je voulais savoir comment appliquer les compétences basiques qu’ils m’avaient données dans le monde réel en écrivant des programmes résolvant des problème réels pour les gens. J’ai donc recherché du code, qui n’était pas difficile à trouver, il se trouvait là, sur Internet, en fait. En regardant le code des programmes que j’utilisais de plus près, j’y ai décelé de la beauté. Non pas parce que le code était parfaitement soigné ou bien structuré, mais parce que je pouvais le comprendre avec les concepts que j’avais déjà appris. Ces classes, méthodes et variables étaient bien en place, me permettant de résoudre les problèmes pertinents. Le logiciel libre est le meilleur moyen de franchir le pas entre savoir comment finir ses exercices de cours et comprendre comment de vrais programmes sont écrits.

Tous les étudiants en informatique devraient travailler sur du logiciel libre comme sujet de leur mémoire. Sinon, vous avez de grandes chances d’y passer six mois à un an pour qu’il finisse au sous-sol d’une bibliothèque sans être jamais plus consulté. Seul le logiciel libre permet d’exceller en faisant ce qui va de soi : vouloir apprendre comment résoudre des problèmes intéressants. À la fin de mon projet, des programmeurs de la NASA utilisaient mon outil de création de diagrammes en UML (NdT : langage de modélisation unifié) et il reçut des prix au cours de réceptions somptueuses. Avec le logiciel libre, on peut résoudre de vrais problèmes pour de vrais utilisateurs.

La communauté des développeurs est remplie de personnes formidables, passionnées et dévouées à leur travail, sans espoir de récompense qu’un programme d’ordinateur couronné de succès. La communauté des utilisateurs est également incroyable. Il est satisfaisant de savoir qu’on a aidé quelqu’un à résoudre un problème. Et j’apprécie les messages de remerciement que je reçois.

Après avoir écrit un logiciel utile, il faut le mettre à la disposition du plus grand nombre. Le code source ne va pas fonctionner pour la plupart des gens, il doit être compilé. Avant d’être impliqué, je trouvais que le fait de compiler était une manière un peu paresseuse de contribuer au logiciel libre. Vous vous attirez la plus grande partie de la reconnaissance sans rien avoir à coder. C’est, quelque part, quelque chose d’injuste. De même, la gestion de la communauté nécessaire pour porter un projet de logiciel libre peut aussi être vue comme une façon de s’attirer la reconnaissance sans faire de code.

Les utilisateurs dépendent beaucoup des packagers (NdT : les « empaqueteurs » qui préparent et maintiennent les paquets logiciels). Il est nécessaire que leur travail soit à la fois rapide, pour satisfaire ceux qui veulent la dernière version, et fiable, pour ceux qui veulent la stabilité (autant dire tout le monde). La partie la plus délicate, c’est que cela implique de travailler avec les logiciels des autres, qui sont toujours « cassés ». Une fois que le logiciel est lâché dans la nature, commencent à emerger des problèmes qui n’étaient pas repérables sur l’ordinateur de l’auteur. Il est possible que le code ne puisse pas être compilé avec une version de compilateur différente, peut-être que la licence n’est pas claire et ne permet pas de le copier, peut-être que la gestion des versions est incohérente et qu’une mise à jour mineure est incompatible, ou encore que la taille de l’écran est différente, les environnements de bureau peuvent aussi l’affecter, quelquefois, des bibliothèques tierces nécessaires ne sont pas encore à jour. De nos jours, le logiciel doit pouvoir tourner sur différentes architectures. Les processeurs 64 bits ont occasionné pas mal de problèmes quand ils sont devenus courants. Aujourd’hui, ce sont les processeurs ARM qui déjouent les calculs des codeurs. Les packagers doivent régler tous ces problèmes pour donner aux utilisateurs quelque chose qui fonctionne de façon fiable.

Nous avons une règle chez Ubuntu selon laquelle les paquets avec des tests unitaires doivent inclure ces mêmes tests dans le processus de la création des paquets. Souvent, ils échouent et l’auteur du logiciel nous dit que les tests sont uniquement à son usage. Malheureusement, quand il s’agit de logiciel, il n’est jamais assez fiable de le tester soi-même, il doit aussi être testé par d’autres. Un test unique est relativement suffisant, il faut une approche à plusieurs niveaux. Les tests unitaires du programme original devraient être le point de départ, ensuite, le packager les teste sur son propre ordinateur, il faut ensuite que d’autres personnes les testent aussi. L’installation automatique et les tests de mise à jour peuvent être scriptés assez correctement sur les services d’informatique dans le nuage. L’envoyer dans la branche de développement d’une distribution permet d’effectuer plus de tests avant de le voir distribué en masse quelques mois après. À chaque étape, des problèmes peuvent être et seront découverts, ils devront être corrigés, puis ces correctifs eux-mêmes devront être testés. Il n’y a donc pas forcément à écrire beaucoup de code, mais il y a pas mal de travail pour passer le logiciel de 95 % à 100 % prêt. Ces 5 % sont la partie la plus difficile, un lent et délicat processus qui demande une grande attention pendant tout son cours.

Vous ne pouvez pas faire de paquets sans une bonne communication avec les développeurs en amont. Quand des bogues se produisent, il est vital de pouvoir trouver la bonne personne à laquelle parler rapidement. Il est important d’apprendre à bien les connaître comme des amis et des collègues. Les conférences sont vitales pour cela, car rencontrer quelqu’un apporte beaucoup plus de contexte à un message sur une liste de diffusion qu’une année entière de messages.

Une des faces cachées du monde du logiciel libre réside dans la communication par les canaux IRC privés utilisés par les principaux membres d’un projet. Tous les grands projets en ont. Quelque part, Linus Torvalds a un moyen de discuter avec Andrew Morton et les autres sur ce qui est bon et sur ce qui est mauvais dans Linux. Ils sont plus sociaux que techniques et, quand on en abuse, ils peuvent être très antisociaux pour la communauté en général. Mais pour les moments où on a besoin d’un canal de communication rapide sans bruit parasite, ils fonctionnent bien.

Tenir un blog est un autre moyen de communication important dans la communauté du logiciel libre. C’est notre principale méthode pour promouvoir à la fois le logiciel que nous produisons et nous-mêmes. Non pas que ce soit utilisé éhontément pour de l’auto-promotion (il est inutile de prétendre que vous sauverez des vies avec votre blog…), mais parler de votre travail sur le logiciel libre aide à construire une communauté. Cela peut même vous valoir de trouver un travail ou d’être reconnu dans la rue.

Ces histoires venant de Slashdot, à propos de développements de nouvelles technologies, ne concernent pas des personnalités éloignées que vous ne rencontrerez jamais comme dans la presse people. Elles concernent des personnes qui ont trouvé un problème et qui l’ont résolu en utilisant l’ordinateur qu’elles avaient en face d’elles. Pendant quelques années, j’ai édité le site d’informations de KDE, trouvant les personnes qui résolvaient des problèmes, créaient des idées novatrices, s’acharnaient longuement à améliorer un logiciel jusqu’à ce qu’il soit d’une qualité suffisante, et j’en parlais au monde entier. Je n’ai jamais été à court d’histoires à raconter ni de personnes à présenter à tout le monde.

Mon dernier conseil est de conserver de la diversité. Il existe une telle richesse de projets intéressants à explorer, qui vous permettent d’apprendre et de progresser. Mais une fois que vous avez atteint une position de responsabilité, il peut être tentant d’y rester. Après avoir aidé à créer une communauté pour Kubuntu, je repars temporairement vers un travail sur Bazaar, un projet très différent, orienté sur les développeurs plutôt que sur des utilisateurs novices en technologies. Je peux à nouveau apprendre comment le code devient une réalité utile, comment une communauté communique, comment la qualité est maintenue. Ce sera un défi amusant et j’ai hâte de m’y attaquer.

Breaking news…nouvelles cassantes…molto straordinario…Donner und Blitzen…urbi et orbi

Nous vous avions pourtant mis en garde, mais rien n’y a fait : bien avant la date limite qu’il avait ululée, Pouhiou a récolté les 2200 € qui vont servir à rendre son premier tome du cycle des Noénautes non seulement libre (il est déjà en CC0) mais en plus gratuit !

Et ça continue… Plus on contribue et plus nombreux seront les livres libérés !

On attend dans les prochaines heures le témoignage d’une victime collatérale - restez tunés !

Google Glass c’est le projet Google de lunettes révolutionnaires à réalité augmentée. On nous promet leur commercialisation avant la fin de l’année. Une vidéo spectaculaire a été publiée récemment. Si vous ne l’avez pas encore vue, nous vous invitons à le faire car vous allez mieux comprendre la traduction qui suit.

Bientôt donc vous retrouverez quelque part avec des gens qui porteront ces lunettes. À tout moment, ceux-ci peuvent vous filmer à votre insu et mettre en ligne en temps réel la vidéo sur YouTube, non sans qu’un système automatisé de reconnaissance faciale et de tags vous ait peut-être identifié au passage !

Ce n’est plus de la science-fiction et comme Google n’est pas une entreprise philanthropique, on imagine sans peine l’impact majeur d’une telle innovation sur notre vie privée et le devenir de nos données personnelles.

Gare aux Google Glasses !

Watch Out for Google Glasses

Anton Wahlman - 25 février 2013 - TheStreet.com
(Traduction : jtanguy, 3wen, Benoît, Jeanba88, misterk, goofy + anonymes)

D’ici la fin de cette année, notre société va subir un changement très particulier, qui va susciter beaucoup de controverses. La cause ? Les Google Glasses.

Les Google Glasses vont impacter les comportements sociaux dès leur mise en circulation. Au moment où vous les apercevez, vous savez que vous pouvez être filmé. Et les gens n’aiment pas être filmés.

Bien sûr, tous les smartphones peuvent enregistrer des vidéos et prendre des photos. Mais vous savez quand ça arrive. Vous n’avez pas constamment l’impression que tout le monde autour de vous est en train de vous filmer sous tous les angles. Vous les voyez faire quand ils le font.

Les Google Glasses sont différentes. Au-delà des photos et des vidéos, qu’advient-il de ces données ?

Imaginons que je sois derrière le guichet d’une entreprise : banque, restauration rapide, guichet d’enregistrement à l’aéroport, peu importe. Mes Google Glasses pourraient afficher le numéro de sécurité sociale, le casier judiciaire, la présence sur les réseaux sociaux, etc. de la personne en face de moi.

C’est peut-être un progrès pour certains mais d’autres trouveront cela terrifiant. Pouvez-vous imaginer la scène dans un bar où les gens commencent à porter des Google Glasses ? En l’espace d’une seconde ou deux, vous aurez toutes les informations disponibles à propos de la personne en face de vous. Et certaines de ces informations pourraient ne pas être flatteuses.

Les lieux publics devront élaborer de nouvelles politiques. Hôtels, aéroports, restaurants, salles de sport et écoles voudront avoir leur mot à dire concernant le port des Google Glasses dans leurs locaux. Vous pourrez entendre les tollés dès que les premières images de gens trichant dans les écoles, ou filmant dans les vestiaires seront publiées sur YouTube. De futurs conflits vont certainement très mal tourner.

D’autre dimensions du problème apparaissent aussitôt. Que se passera-t-il si les versions futures des Google Glass deviennent très difficiles à distinguer des lunettes traditionnelles ?

Aujourd’hui, que se passe-il si vous pénétrez dans un établissement en tenant une caméra qui filme les visages des gens, dans un restaurant, une banque ou une salle de sport ? On vous demandera d’éteindre votre caméra, et si vous n’obéissez pas rapidement, on vous jettera dehors.

Les Google Glasses vont rendre les interactions publiques et sociales très délicates car vous prenez le risque potentiel d’être sur YouTube quel que soit l’endroit où vous allez. Quelques mois après leur arrivée sur le marché, les Google Glasses pourraient être déjà si répandues que vous serez filmé dès que vous pointerez le nez dehors.

Défenseurs de la vie privée, en avant !

Les données photos et vidéos des Google Glasses ne vont pas être utilisées seulement par la personne qui porte les lunettes. La personne qui prend ces images voudra peut-être « taguer automatiquement » ces médias avec l’identité des personnes dans la photo ou vidéo.

Il y a des gens qui préfèrent passer sous les radars. Ils payent en liquide, n’utilisent pas de GPS en voiture, n’ont pas de téléphone, et ne sont membres d’aucun réseau social en ligne. Ils ont réussi à rester en-dehors de la plupart des bases de données disponibles publiquement.

Une fois qu’une partie significative de la population aura commencé à déambuler dans les rues avec des Google Glasses, ils ne le pourront plus vraiment. Il n’y aura plus de place pour se cacher, à moins que les gouvernements ne légifèrent sur ces Google Glasses, ou que les établissements privés décident de les interdire.

Qu’en est-il de Google lui-même ?

Les Google Glasses deviendront une arme décisive dans la guerre imminente pour les données personnelles. Si d’autres personnes les utilisent, pourquoi pas moi ? Je prédis que toutes les personnes avec suffisamment de moyens vont se ruer pour en obtenir, surtout si le prix baisse de 1 500$ à 1 000$, puis à 500$ et finalement en-dessous, lors des deux premières années de commercialisation.

Si Google arrive à sortir ce genre de lunettes avant ses concurrents directs, non seulement Apple, mais aussi Microsoft, son avance pourrait bien être décisive. Google possède déjà 70% des parts de marché des smartphones avec Android, donc il est plutôt bien parti, mais n’oublions pas que la part de marché des PC de Microsoft atteignait 95% il y a seulement quelques années.

Comme Google va probablement inventer un lien fort entre les Google Glasses et les smartphones Android, les Google Glasses vont être une véritable aubaine pour Android. N’importe qui regardera son iPhone et devra sérieusement envisager de passer à Android.

Les Google Glasses risquent de causer un chaos social, mais elles vont être très bénéfiques pour les finances de Google.

Crédit photo : Max Braun (Creative Commons By-Sa)

Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framablog : Sphinx, purplepsycho, Cyrille L., lamessen

Ce que je suis contente de ne pas avoir su

Alexandra Leisse

Alexendra Leisse a quitté une scène pour en rejoindre une autre. Elle a transformé son autre passion (les logiciels et le Web) en un métier. Après une période de transition de douze mois en freelance dans le logiciel et l’opéra — et noyée par de nombreuses heures d’activités dédiées à KDE, elle a rejoint Nokia et le développement de la plateforme Qt en tant que gestionnaire de la communauté Web. C’est la femme derrière le réseau de développement Qt et les activités de sa communauté sur la toile. Bien qu’elle soit diplômée en art lyrique, elle refuse la plupart du temps de chanter en public.

Introduction

Quand Lydia m’a demandé de rejoindre son projet de livre sous-titré « les choses que j’aurais voulu savoir », mon esprit est resté vide. Les choses que j’aurais voulu savoir mais que je savais pas ? Rien ne me venait à l’esprit.

Je ne dis pas que je n’aie pas eu besoin de savoir quoi que ce soit, au contraire. J’ai eu beaucoup à apprendre et j’ai fait une nombre incalculable d’erreurs. Mais les situations ou les erreurs que j’aurais voulu éviter ? Je n’arrive pas à y penser.

Nous avons tous cette fâcheuse tendance à regarder les choses que nous pourrions mieux faire, les choses que nous ne savons pas, et nous les voyons comme des faiblesses. Mais que dire des faiblesses qui sont des atouts ?

Voici ma propre histoire sur l’ignorance, la naïveté, les mauvaises impressions et comme je suis heureuse de ne pas en avoir eu la moindre idée.

Les noms

Je n’avais aucune idée de qui était ce gars que j’avais rencontré lors de mon premier jour de travail. Il est entré dans la pièce, s’est présenté et a commencé à poser des questions me donnant l’impression que tout ce que je penserais serait insensé. Il était apparemment bien renseigné sur ce que je faisais sur KDE et les personnes que je côtoyais. Cependant, nos points de vue sur le sujet semblaient différents. À un moment, ses provocations ont fini par me fatiguer et j’ai perdu patience. Je lui ai alors dit qu’avec les personnes, ce n’était pas toujours aussi facile que les ingénieurs l’imaginent.

Juste après son départ après une heure de discussion, j’ai cherché son nom sur Google : Matthias Ettrich. Ce que j’ai lu m’a expliqué pourquoi il avait posé ces questions. Si j’avais su avant qu’il était un des fondateurs du projet KDE, j’aurais débattu avec lui d’une manière bien différente, voire pas du tout.

Ces dernières années, j’ai dû chercher quelques noms et à chaque fois, j’ai été heureuse de le faire après le premier contact.

C’est probablement mon idée la plus importante. Lorsque j’ai rencontré toutes ces personnalités du Libre et de l’open source pour la première fois, je n’avais jamais entendu leurs noms auparavant. Je ne savais rien de leurs histoires, mérites ou échecs. J’ai approché tout le monde de la même façon : le contact visuel. En étant ignorante (ou naïve selon certains), je ne me sentais pas inférieure par rapport aux personnes que je rencontrais lorsque j’ai commencé mon aventure au sein du Libre et de l’open source. Je savais que j’avais beaucoup à apprendre mais je n’ai jamais eu l’impression d’avoir un rang inférieur aux autres en tant qu’individu.

« Projet de grande envergure »

Je n’avais pas suivi religieusement dot.kde.org ni PlanetKDE et encore moins ces innombrables publications liées au Libre et à l’open source, avant de commencer à m’intéresser à ce qui se passait sur les listes de diffusion KDE. Je voyais ces canaux avant tout comme moyen de communiquer avec un public choisi, principalement des utilisateurs et des contributeurs du projet en tant que tel.

Pendant un certain temps, je n’avais pas conscience que les articles que je publiais sur The Dot pourraient être repris par des journalistes. Je m’appliquais à les écrire parce que je voulais faire du bon boulot et non pas parce que j’avais peur de passer pour folle auprès du reste du monde. La liste de presse était maintenue par d’autres personnes et ce que j’écrivais ne me paraissait pas important non plus. Je voulais toucher certaines personnes. Pour cela les canaux officiels et mon propre blog me semblaient être les moyens les plus efficaces.

Être citée sur ReadWriteWeb après avoir annoncé sur mon blog que je commencerai un nouveau boulot fut un choc pour moi. Non pas parce que j’ignorais que des gens lisaient ce que j’écrivais (j’espérais bien qu’ils le lisent !) mais je ne m’attendais pas à ce que ça soit un sujet d’une telle importance. Ce n’était même pas pendant les vacances d’été. Encore heureux que personne ne me l’ait dit, je n’aurais pas été capable de publier ne serait-ce qu’une seule ligne.

L’œil étranger

Il y a quelque temps, quand j’ai assisté à ma première conférence, j’avais la ferme conviction que j’étais différente des autres participants. je me voyais comme une étrangère parce que je n’avais pas grand-chose en commun avec qui que ce soit à part un vague intérêt pour la technologie : je travaillais en freelance depuis quelques années déjà, après mon diplôme universitaire ; je n’avais aucune éducation pertinente dans le domaine, et j’étais mère d’un enfant de 10 ans. Sur le papier en tout cas, il ne pouvait pas y avoir plus éloignée des suspects habituels qu’on rencontre dans les projets FOSS.

En 2008 j’ai assisté à un sprint (NdT : phase de développement, généralement perçue comme intense, aboutissant à un produit fonctionnel) KOffice au sein de l’équipe promotion et marketing de KDE pour préparer la sortie de la version 2.0. L’idée initiale était d’esquisser une série d’activités promotionnelles autour de cette sortie afin de développer à la fois le support développeur et utilisateur. Pour celui-ci, nous étions trois à suivre un chemin parallèle à celui concernant les développeurs.

Nous avons essayé de comprendre comment nous pourrions positionner KOffice et adapter la communication au public ciblé. Très tôt dans le processus, nous avons découvert que nous devions faire marche arrière : à ce stade, le manque de maturité de la suite rendait impossible son positionnement comme option pour les utilisateurs non avertis. Nous devions nous en tenir aux développeurs et aux précurseurs. C’était difficile à vendre à certains développeurs, mais en tant qu’étrangers nous avions la chance de regarder le logiciel sans penser à tout le sang, la sueur et les larmes versés dans le code.

Pour beaucoup de projets, de n’importe quelle sorte, jeter un œil objectif à la situation donne du fil à retordre aux contributeurs principaux. Nous avons tendance à ne pas voir les grands succès quand nous sommes très concentrés sur des problèmes de détails et réciproquement. Parfois, nous manquons une occasion parce que nous pensons que ça n’a rien à voir avec ce que nous faisons (ou, pour commencer, parce que personne ne voudrait que ça ait quelque chose à voir).

Dans tous ces cas, les contributeurs extérieurs au projet ont le potentiel pour apporter des points de vue différents à la discussion, particulièrement quand il s’agit de déterminer un ordre de priorité. C’est encore plus utile quand ce ne sont pas des développeurs : ils poseront différentes questions, sans ressentir de pression face à la connaissance et à la compréhension de tous les détails techniques ; ils peuvent aussi aider pour les décisions ou la communication sur un plan moins technique.

Conclusion

L’ignorance est une bénédiction. Ce n’est pas seulement vrai pour les individus qui profitent de l’insouciance qui en résulte mais aussi pour les projets que ces individus rejoignent. Ils apportent différents points de vues et expériences.

Et maintenant, filez et trouvez vous-même un projet qui vous intéresse, indépendamment de ce que vous pensez savoir.

Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framalang : Lycoris, grosfar, merlin8282, Sky, Julius22, _noskill, Nyx, lenod, KoS, lerouge, alexb, Ex0artefact, name?, SaSha_01, peupleLà, lamessen

Prendre de la distance pour atteindre l’excellence

Jono Bacon

Jono Bacon est gestionnaire de communauté, directeur technique, consultant et auteur. Il travaille actuellement comme gestionnaire de la communauté Ubuntu chez Canonical. Il dirige une équipe afin de faire croître, de stimuler et d’enthousiasmer l’ensemble de la communauté Ubuntu. Il est l’auteur d’Art of Community, le fondateur du Community Leadership Summit et le cofondateur du populaire podcast LugRadio.

Jono Bacon au tableau blanc

La première fois que j’ai entendu parler de Linux et d’open source remonte à 1998. La technologie était alors horriblement compliquée et il fallait fournir de gros efforts pour obtenir un système qui tourne correctement ; pourtant, le concept d’une communauté collaborative globale me subjugua. À l’époque, je ne possédais aucune connaissance, mes compétences techniques étaient limitées et j’avais des boutons.

J’étais un adolescent typique : tourmenté, cheveux longs, T-shirt Iron Maiden. Mon chemin était déjà tout tracé, au sens le plus traditionnel ; j’irais à l’école, puis au lycée, puis à l’université, puis je trouverais un travail.

Quatorze ans plus tard, le chemin que j’ai finalement suivi n’a rien de conventionnel. Cette fascination personnelle envers le communautaire m’a conduit partout dans le monde et m’a lancé des défis captivants. C’est intéressant de prendre du recul et d’analyser cette période. Enfin, ça pourrait être intéressant pour moi… Vous préférerez peut-être passer au chapitre suivant…

… Toujours avec moi ? OK, allons-y.

La science contre l’art

J’ai toujours cru que la gestion d’une communauté était moins une science qu’un art. Je définis la science comme l’exploration de méthodes permettant de reproduire des phénomènes à travers des étapes établies et clairement comprises. Dans le monde de la science, si vous connaissez la théorie et la recette pour un résultat donné, vous pouvez souvent reproduire ce résultat comme tout un chacun.

L’art est différent. Il n’y a pas de recette pour produire une chanson populaire, pour créer une peinture exceptionnelle ou pour sculpter une statue magnifique. De même, il n’y a pas vraiment d’ensemble d’étapes reproductibles pour créer une communauté prospère. Bien sûr, il y a des astuces et des techniques pour parvenir à réunir certaines composantes du succès, mais c’est la même chose pour les autres formes d’art : nous pouvons tous apprendre les notes et les accords d’une guitare, mais cela ne veut pas dire que nous allons écrire la prochaine Bohemian Rhapsody. La formule qui donne naissance à un titre comme Bohemian Rhapsody, c’est une dose de compétence acquise et une dose de magie.

Je ne suggère cependant pas que la gestion de communauté soit une forme d’art désespérément branchée et introvertie que seuls quelques bienheureux élus très talentueux peuvent accomplir. Ce dont je me plains est qu’il n’y ait pas de manuel sur la façon de créer une communauté magnifique et enthousiasmante ; il s’agit toujours d’une dose d’apprentissage et d’une dose de magie mais la part de magie ne vous sera pas insufflée par la grâce des dieux ; il vous faudra plutôt la chercher en essayant de nouvelles voies, en restant à l’écoute des retours et en évaluant ce qui fonctionne et ce qui ne fonctionne pas.

C’est plutôt frustrant car cela veut dire que cette « magie » ne s’obtient pas en suivant une recette unique. Mais il reste la possibilité de partager les compétences acquises, comme j’ai cherché à le faire avec The Art of Community 1 et la conférence annuelle Community Leadership Summit 2.  

Avant de commencer mon introspection, et pour ceux que ma carrière n’ennuie pas mortellement, je vais résumer rapidement les communautés avec lesquelles j’ai travaillé afin de poser le contexte. En bref, j’ai commencé dans mes jeunes années chevelues par la création de l’un des premiers sites web communautaires britanniques sur Linux, appellé Linux UK, et j’ai intégré la communauté des Groupes d’utilisateurs de Linux (Gul). Je me suis ensuite lancé dans la création de mon propre Gul à Wolverhampton, au Royaume-Uni, et j’ai fondé le projet Infopoint pour encourager les Gul à prêcher Linux sur les salons informatiques du Royaume-Uni. J’ai ensuite poursuivi en contribuant à la communauté KDE et en fondant le site KDE::Enterprise ; j’ai établi le KDE Usability Study et contribué de-ci, de-là à diverses petites applications. J’ai ensuite fondé le groupe d’utilisateurs PHP des West Midlands. J’ai aussi commencé à m’intéresser à GNOME. J’ai développé quelques applications (GNOME iRiver, XAMPP Control panel, Lernid, Acire) et également participé à la conception et un peu au code d’une nouvelle application audio simplifiée appelée Jokosher. C’est à peu près à cette époque que j’ai co-fondé le podcast LugRadio qui fonctionna pendant quatre ans avec plus de deux millions de téléchargements, ce qui a entraîné la mise en place de cinq événements en direct au Royaume-Uni et aux États-Unis. À cette époque, j’ai également commencé à travailler comme consultant open source pour l’initiative publique OpenAdvantage. Là, j’ai vraiment eu l’occasion de me faire les dents sur le communautaire en aidant des organisations à travers tout les West Midlands à passer à l’open source. Après quelques années passées chez OpenAdvantage, je suis parti rejoindre Canonical comme gestionnaire de la communauté Ubuntu où j’ai mis en place une équipe de quatre personnes. Ensemble, nous nous investissons dans des projets très variés chez Ubuntu et Canonical. Vous êtes toujours là ?

Ouah, vous êtes tenace. Ou assommé d’ennui. Probablement assommé. Il y aura interro à la fin, ça vous apprendra…

Réfléchir

Ceci m’amène donc à l’objet de cet article : la curieuse question de savoir ce que je me dirais si je savais ce que je sais aujourd’hui. À ce jour, je pense que ce que j’ai appris au cours de ma carrière peut se diviser en deux grosses catégories :

Pratique — les trucs et astuces du métier, par exemple, les différentes approches des moyens de communication, les différentes façons d’utiliser la technologie, la gestion du temps, les différentes approches de la gestion de projet, etc.

Personnel — les leçons de vie et apprentissages qui modifient l’approche que nous avons de notre monde.

Je ne vais pas m’étendre sur la catégorie pratique — vous devriez lire mon livre si vous souhaitez en savoir plus sur ce sujet (le livre couvre aussi l’aspect personnel). Aujourd’hui, je vais plutôt m’intéresser aux leçons de vie. Les approches et les pratiques changeront toujours, mais les leçons que l’on en tire ne changent pas tant que ça : elles évoluent plutôt au fur et à mesure que votre sagesse grandit.

L’importance des convictions

Les communautés sont fondamentalement des réseaux de personnes poussées par leurs convictions. Chaque communauté possède son propre état d’esprit et un domaine d’expertise propre. Cela peut être une idée aussi grandiose que de rassembler l’intégralité des savoirs de l’humanité, changer la face du monde avec le logiciel libre ou, plus simplement, animer un « club » pour que les gens puissent échanger autour de leurs livres préférés. Que ce soit pour changer le monde ou simplement pour s’amuser, chaque communauté fait valoir son propre système de valeurs ; l’humble club de lecture accorde beaucoup de valeur au fait de fournir un environnement amusant, sécurisé et libre afin de pouvoir partager des avis et des conseils de lecture. Cela ne change pas le monde, mais cela reste toujours une bonne chose à laquelle n’importe qui peut se rallier.

La règle, souvent tacite, d’une communauté est que chaque contribution d’un membre de la communauté doit bénéficier à l’ensemble de celle-ci. C’est pourquoi il est amusant d’écrire un correctif pour un bogue d’un logiciel libre, de contribuer à la documentation ou d’organiser un événement gratuit. Mais il est rare que quiconque veuille contribuer de façon bénévole si sa contribution ne bénéficie qu’à une seule personne ou entreprise.

Bien sûr, je suis certain que vous tous, enfoirés cyniques que vous êtes, allez chercher et trouver une exception. Mais souvenez-vous que cette décision est profondément personnelle : les membres de la communauté décident par eux-mêmes si leur contribution doit bénéficier à tous. Par exemple, certains vont arguer que n’importe quelle contribution à Mono va seulement bénéficier à Microsoft et à l’ubiquité de leur infrastructure .NET. Mais des centaines de contributeurs participent à Mono parce qu’ils ne le voient pas de cette manière : ils voient leurs contributions comme un moyen utile et amusant de permettre aux développeurs d’écrire des logiciels libres plus facilement.

Si je devais parler au Jono de 1998, j’insisterais sur l’importance de cette conviction. J’avais alors une intuition à ce propos, mais je ne compte plus les exemples qui m’ont prouvé depuis que cette conviction incite réellement les gens à participer. J’ai souvent parlé de l’histoire du gamin d’Afrique qui m’a envoyé un courriel pour me dire qu’il devait marcher trois heures aller-retour jusqu’au cybercafé le plus proche pour contribuer à Ubuntu. Il le faisait car il était convaincu par notre mission d’apporter le logiciel libre aux masses. On pourrait aussi citer l’énorme croissance de Wikipédia, l’incroyable réunion de la communauté GNOME autour de GNOME 3, le succès d’OpenStreetMap et bien d’autres exemples.

Ceci dit, la conviction n’est pas juste un artifice pour les relations publiques. Il faut qu’elle soit réelle. Bien que nous ayons tous des convictions différentes — certains ont des convictions sur le logiciel, sur l’éducation, sur le savoir, sur la transparence ou sur n’importe quoi d’autre — vous ne pouvez pas fabriquer un système de convictions à moins qu’il n’ait un but valide, auquel un groupe puisse s’intéresser. Certes, il peut être obscur, mais il doit être réel. Avec le succès du mouvement open source, nous avons vu des exemples d’entreprises qui tentaient de jouer cette approche et ce registre sémantique autour de la conviction, mais dans le but de servir leurs propres besoins. Je pourrais essayer de vous faire adhérer à cette idée : « Travaillons tous ensemble pour aider Jono à devenir riche » et fabriquer de toutes pièces quelques sophismes pour justifier de cette acte de foi (par exemple, si j’étais riche, je pourrais me concentrer sur d’autres travaux, au bénéfice d’autres communautés ; mes enfants seraient élevés et éduqués dans de bien meilleures conditions, ce qui profiterait à tout le monde), mais ce serait n’importe quoi.

En tant que telle, la conviction est un puissant moteur pour la contribution comme pour la collaboration, mais il est important de l’utiliser de manière équilibrée et de l’associer au respect. Alors qu’elle peut déclencher d’incroyables changements, elle peut être terriblement dévastatrice (comme c’est le cas avec certains prédicateurs à la TV qui utilisent la religion comme un moyen de vous soustraire de l’argent, ou encore les faux médiums qui utilisent la lecture à froid et s’accrochent à votre besoin désespéré de croire que vous pouvez à nouveau vous connecter à un être cher disparu.

Votre rôle

Aujourd’hui, les gestionnaires de communauté ont un rôle intéressant. Par le passé, j’avais parlé de deux types de gestionnaires de communauté ; ceux qui sortent, font des conférences et s’agitent en parlant d’un produit ou d’un service et ceux qui travaillent avec une communauté de volontaires pour les aider à connaître une expérience collaborative, productive et amusante. Le second type m’intéresse plus — je pense que c’est ce que fait un vrai gestionnaire de communauté. Le premier de ces positionnements est tout à fait sympa et respectable mais cela convient mieux dans le domaine de la promotion et des relations publiques et cela nécessite d’autres compétences. J’ai quelques conseils que je pense être assez intéressants pour être partagés.

La première et probablement la plus importante des leçons est d’accepter que vous pouvez et allez parfois avoir tort. Jusqu’ici, dans ma carrière, j’ai fait certaines choses correctement et j’ai commis des erreurs. Bien que je croie être généralement sur le bon chemin et que l’essentiel de mon travail soit couronné de succès, il y a eu quelques flops ici ou là. Ces loupés, accidents et faux pas n’ont jamais été dus à de la malveillance ou de la négligence ; ils ont plutôt été causés par une sous-estimation de la difficulté de mon objectif.

Ça a l’air assez évident, mais ça l’est moins quand vous avez une fonction relativement publique. En gros, les gestionnaires de communautés sont souvents vus comme les représentants d’une communauté donnée. Par exemple, je sais qu’à titre personnel, on me considère comme l’une des figures publiques d’Ubuntu et cette responsabilité, s’accompagne d’une certaine pression publique quant à la manière dont les gens vous perçoivent.

Avoir les projecteurs braqués sur soi en se retrouvant à la tête d’une communauté déclenche chez certains un mécanisme défensif. Ils reculent à l’idée de faire des erreurs en public, comme si les masses dans leurs bavardages s’attendaient à une prestation parfaite. C’est dangereux, et on a déjà vu, par le passé, des personnages publics qui ne reconnaissent jamais avoir fait une erreur par crainte d’être ridicules en public. Non seulement, c’est une idée fausse (nous faisons tous des erreurs), mais cela ne donne pas non plus à la communauté un bon exemple de chef de file honnête et transparent tant dans les choses qu’ils font bien que dans celles qu’ils font moins bien. Il est important de se rappeler que nous gagnons souvent le respect d’autrui par leur acceptation de nos erreurs : c’est la caractéristique d’un individu honnête et accompli.

Je me rappelle mes débuts en tant que responsable chez Canonical. À l’époque, Colin Watson et Scott James Remnant, deux vieux briscards des tous débuts de Canonical et d’Ubuntu, faisaient aussi partie des responsables de l’équipe d’ingénierie d’Ubuntu. Nous avions des réunions hebdomadaires avec notre directeur technique, Matt Zimmerman, et j’y entendais régulièrement Colin et Scott avouer ouvertement qu’ils étaient mauvais dans ceci ou avaient fait une erreur dans cela ; ils étaient étonnamment humbles et acceptaient leurs forces et leurs faiblesses. En tant que responsable débutant, je l’ouvrais moins souvent, mais cela m’a appris que ce genre d’ouverture d’esprit et d’honnêteté est important non seulement en tant que responsable, mais en tant que leader d’une communauté. Depuis, je n’hésite plus à admettre publiquement mes erreurs ou à m’excuser si je foire quelque chose.

Écouter

De même qu’être ouvert aux erreurs est primordial, il est tout aussi important d’être à l’écoute et d’apprendre de ses pairs. Dans de nombreux cas, nos communautés perçoivent les responsables et les leaders de communauté comme des personnes qui devraient toujours fournir des orientations et des directions, mener activement le projet et réaliser ses objectifs. C’est sans aucun doute une responsabilité. Mais tout autant qu’être la voix qui montre la voie, il est important de prêter l’oreille pour écouter, guider quand c’est opportun et apprendre de nouvelles leçons et idées.

Les membres de nos communautés ne sont pas juste des mécaniques froides et insensibles qui font leur travail. Ce sont des humains qui vivent, respirent, ont des opinions, des sentiments et des idées. J’ai vu de nombreux exemples — et j’en ai déjà moi-même provoqué —, de ces situations où quelqu’un est tellement habitué à donner des instructions et des conseils qu’il oublie parfois de simplement s’asseoir, écouter et apprendre de l’expérience de quelqu’un d’autre. Toute industrie possède ses maîtres-à-penser et ses experts… des gens célèbres et reconnus pour leur sagesse. Mais, d’après mon expérience, certaines des leçons de vie les plus révolutionnaires que j’ai apprises sont venues de membres tout à fait anonymes, ordinaires. Savoir écouter les gens n’est pas seulement important pour nous aider à apprendre et à nous améliorer dans ce que nous faisons, c’est également essentiel pour gagner le respect et avoir de bonnes relations avec sa communauté.

Temps de travail contre temps libre

Pendant que je parle de la façon dont nous collaborons avec notre communité, il y a un autre résultat de mon expérience que je n’ai vraiment assimilé qu’assez récemment. Comme beaucoup de gens, de nombreux centres d’intérêts remplissent mes journées. À part être marié et essayer d’être le meilleur mari possible, et à part mon travail quotidien en tant que gestionnaire de la communauté d’Ubuntu, je participe aussi à des projets tels que Severed Fifth, le Community Leadership Summit et quelques autres choses. Comme on pourrait s’y attendre, je consacre mes journées à mon travail rémunéré : au boulot, je ne passe pas de temps à travailler sur ces autres projets. Et, comme on pourrait s’y attendre, lorsque ma journée de travail se termine, je me mets à travailler sur ces autres projets. La leçon qu’il faut retenir ici, c’est qu’il n’est pas toujours clair pour votre communauté de savoir où tracer les limites.

Au fil des années, j’ai développé toute une série de services en ligne que j’utilise tant dans mon travail qu’à titre personnel. Mes comptes Twitter, identi.ca et Facebook, mon blog et d’autres ressources sont les endroits où je parle de ce que je fais. Le problème est que si l’on tient compte de leur caractère public, du fait que je suis un représentant officiel du projet Ubuntu et de tous les fuseaux horaires autour du globe, même Einstein aurait du mal à faire la différence entre ce que j’écris en tant que Jono et ce que j’écris pour le compte de Canonical.

Ce qui a pu causer de la confusion. Par exemple, malgré mes clarifications répétées, OpenRespect n’est pas et n’a jamais été une initiative de Canonical. Bien sûr, quelques idiots ont choisi d’ignorer mes explications à ce sujet mais je comprends néanmoins comment la confusion a pu arriver. La même chose s’est produite pour d’autres projets tels que Severed Fifth, The Art of Community et le Community Leadership Summit, qui ne font pas et n’ont jamais fait partie de mon travail chez Canonical.

C’est une leçon pour moi car j’ai moi-même partagé un moment, cette vision des choses et disais : « Évidemment que c’est activité de loisirs, j’ai posté ça à 20 h. » tout en haussant les épaules à propos de la confusion entre travail et projets personnels. Quand votre travail vous met dans une position relativement publique, vous ne pouvez pas vous offrir le luxe de voir les choses comme ça. Au contraire, vous devez considérer que les gens vont avoir tendance à faire la confusion et que vous allez devoir travailler plus dur pour bien clarifier les choses.

Ne voyagez pas trop

À propos du travail pour une société qui vous a recruté pour être à la tête d’une communauté, vous devriez toujours avoir conscience des risques comme des bénéfices des voyages. C’est une chose que j’ai apprise assez tôt dans ma carrière chez Canonical. Je voyais toujours les mêmes têtes dans les conférences, et il était évident que ces personnes avaient très bien communiqué sur les bénéfices des voyages auprès de leurs employeurs, tout comme je l’avais fait, sauf que j’en ai aussi appris les dangers.

Je voyageais et ce n’était pas seulement un travail fatigant et épuisant psychologiquement, mais j’étais aussi plus loin de mes courriels, moins présent sur IRC, j’étais dans l’impossibilité d’assister à de nombreuses réunions et j’avais moins de temps à consacrer à mes engagements professionnels. Ainsi, mon rôle était principalement devenu de sortir et d’aller assister à des événements et, même si c’était amusant, cela ne rendait pas autant service à ma communauté qu’il l’aurait fallu. Aussi ai-je drastiquement réduit mes déplacements — pour tout dire, je suis allé au Linux Collab Summit il y a quelques jours, et hormis quelques événements d’Ubuntu auxquels je devais assister, je n’ai assisté à aucune conférence depuis près d’un an. J’ai l’impression à présent d’être allé un peu trop loin dans l’autre direction. Tout est donc une question d’équilibre. Mais j’ai aussi le sentiment de mieux servir ma communauté quand je peux prendre le temps d’être au bureau et d’être en ligne et disponible.

La planification

Pour certains, être à la tête d’une communauté, ou simplement l’animer, est un rôle qui tient moins de la structure pré-établie que du fait d’être réactif. À mes débuts, c’est également ce que je pensais. Bien qu’il n’y ait absolument aucun doute sur la nécessité de se montrer réactif et de pouvoir répondre aux choses qui se présentent, il est également essentiel de planifier suffisamment son travail sur une période donnée.

Cette planification devrait être effectuée de manière ouverte quand c’est possible et remplit plusieurs objectifs :

Partager la feuille de route : ça aide la communauté à comprendre sur quoi vous travaillez et lui offre souvent des opportunités de vous aider.

Apporter des garanties — ça prouve qu’un responsable de communauté fait quelque chose. Votre communauté peut constater votre travail effectif à l’oeuvre. C’est très important puisque la majeure partie du travail d’un responsable de communauté s’effectue souvent sans que la communauté au sens large en ait connaissance (par exemple, avoir une conversation en tête à tête avec un des membres de la communauté). Et ce manque de visibilité peut parfois générer des inquiétudes sur le fait que peu de choses se produisent dans des domaines-clé alors qu’en fait, beaucoup de choses se produisent en coulisses.

Communiquer les progrès vers le haut et vers le bas de l’organisation — c’est pertinent si vous travaillez dans une entreprise. Avoir établi de bons processus de planification montre votre travail effectif à votre hiérarchie ; ça rassure votre équipe sur le fait que vous saurez toujours sur quoi travailler et ça donne beaucoup de valeur ajoutée à la communauté.

Au fil des années, j’ai attaché de plus en plus d’importance à la planification. Mais je garde suffisamment de temps et de flexibilité pour rester réactif. Quand j’ai débuté comme gestionnaire de la communauté Ubuntu, mon planning était plutôt personnel et je le gérais au coup par coup : je prenais le pouls de la communauté et je consacrais temps et moyens à m’occuper des domaines que je jugeais adéquats.

À présent, je répartis les objectifs dans un ensemble de projets qui couvrent chacun un cycle d’Ubuntu, je rassemble des informations avec les parties prenantes, je compose une feuille de route, je fais le suivi du travail dans des schémas directeurs. J’estime également les progrès effectués en utilisant toute une gamme d’outils et de processus tels que mon diagramme des tâches réalisées, des réunions régulières et d’autres encore. Bien que la méthode actuelle nécessite plus de planification, elle est d’une aide significative en termes de bénéfices sur les points cités ci-dessus.

Perception et conflit

Dans le monde de la gestion et de la gouvernance de communautés, j’entends souvent s’exprimer l’avis selon lequel tout serait affaire de perception. En règle générale, quand j’entends ça, c’est en réponse à quelqu’un qui se trouve du mauvais côté du bâton, le plus souvent au cours d’une période de conflit.

Bien sûr, la perception joue un rôle important dans nos vies, c’est vrai ; mais ce qui peut alimenter des perceptions erronées ou inadéquates, c’est le manque d’information, de mauvaises informations et, dans certains cas, des tensions et des tempéraments échauffés. Cela peut être une des tâches les plus complexes pour celui qui est à la tête de la communauté. Et j’en suis ressorti en tirant quelques leçons dans ce domaine également.

Les communautés sont des groupes de personnes et, dans chaque groupe, on trouve souvent des rôles stéréotypés dans lesquels les gens se glissent. On y trouve, en général, quelqu’un que l’on considère comme une rockstar ou un héros, quelqu’un de compréhensif pour les préoccupations et les soucis et qui prêtera son épaule pour pleurer, quelqu’un qui a son franc-parler et souvent quelqu’un qui est… disons… intentionnellement pénible. Les héros, les oreilles compatissantes et les grandes gueules ne posent pas particulièrement de problèmes, mais les personnes qui créent délibérément des difficultés peuvent être pénibles ; lorsqu’il devient carrément difficile de gérer une personne, cela peut provoquer des tensions avec les autres membres et amener du conflit dans une communauté qui, sinon, est heureuse. Il faut étouffer ce genre de problèmes dans l’œuf.

Une partie du défi, ici, c’est que les gens sont des gens, que les groupes sont des groupes et qu’il n’est pas rare qu’une personne (ou un petit nombre de personnes) se fasse connaître et soit critiquée derrière son dos et passer pour quelqu’un avec qui il est difficile de travailler. En plus de cela, la plupart des gens n’ont pas envie d’être impliqués dans un quelconque conflit et, du coup, la personne dont on se plaint ne peut pas toujours se rendre compte de la façon dont les gens la perçoivent, étant donné que personne ne veut la confronter à ce sujet. Il en résulte une des situations les plus dangereuses pour les membres d’une communauté — une réputation se propage, sans même que la personne concernée ne s’en rende compte. Et du coup, puisqu’elle ne le sait pas, elle n’a jamais l’occasion de changer de comportement. C’est une situation plutôt inconfortable.

Une réponse habituelle à cette conclusion consiste à dire : « ils sont si difficiles à gérer qu’essayer de les raisonner c’est peine perdue, de toute façon ». Même si cela se produit certainement de temps à autres, ne supposez pas trop vite que ce sera l’issue ; j’ai quelquefois eu la désagréable expérience de sentir que je devais faire savoir à certaines personnes, la réputation qu’elles avaient développée. Et, dans la plupart des cas, cela a été une réelle surprise pour elles. Et elles ont quasiment toutes modifié leur comportement après ce retour.

Sur un sujet lié, bien que ça n’est pas si courant dans la routine quotidienne d’un leader de communauté, un conflit va souvent se pointer ici ou là. Je voudrais juste partager deux éléments à ce propos.

La première chose, c’est de comprendre comment les conflits naissent. Pour expliquer cela, permettez-moi de vous raconter une anecdote. La semaine dernière, un de mes amis est venu en avion dans la baie de San Fransisco pour une conférence. Il est arrivé le soir, je suis donc allé le chercher à l’aéroport et nous sommes allés au pub pour discuter des dernières nouvelles. Là-bas, il commença à me raconter à quel point il était déçu d’Obama et de son administration. Il a cité des exemples : la réforme de la sécurité sociale, la réforme de Wall Street, les droits du numérique et d’autres choses. Ce qui l’embêtait n’était pas la politique menée en elle-même, mais il trouvait qu’Obama n’en faisait pas assez. Ma vision des choses était légèrement différente.

Je ne suis ni Démocrate, ni Républicain ; je prends ma décision sur chaque problème, sans m’aligner sur l’une ou l’autre des parties. Là où je diffère de mes mon amis, cependant, c’est que je suis un peu plus favorable à Obiwan Ken Obama et son travail quotidien. C’est parce que je crois que lui, et qui que ce soit d’autre dans un poste auprès en relation avec le public — qu’il soit internationalement reconnu comme le président ou qu’il soit obscur et spécifique comme un gestionnaire de communauté — réalise que l’histoire lue et comprise par le public est souvent un simple fragment de l’histoire complète. Il y a eu des cas, par le passé, où quelque chose de controversé a démarré dans les communautés auxquelles j’appartenais. De nombreux commentateurs et spectateurs n’avaient pas l’entière connaissance des faits, soit parce qu’ils n’avaient pas compris les nuances et les détails du sujet, soit parce que certains éléments de l’histoire n’avaient pas été partagés.

Bon, je sais ce que vous allez dire — , quoi, certains éléments n’avaient pas été partagés !? Il vaudrait mieux être transparent, n’est-ce pas ? Bien sûr que c’est nécessaire. Et nous devrions toujours nous attacher à être ouverts et honnêtes. Mais il y a des cas où il serait inapproprié de partager certaines parties de l’histoire. Cela pourrait être en raison de fragments de conversations privées avec des gens qui ne souhaitent pas partager leurs commentaires ou tout simplement faire son boulot bien comme il faut sans éclabousser les réputations. Par exemple, j’ai toujours eu comme pratique de ne pas faire de coups bas à des concurrents, peu importe la situation. Par le passé, il y a eu des comportements critiquables de la part de certains concurrents dans les coulisses. Mais je ne vais pas me mettre à salir leurs réputations car cela n’aurait pas vraiment d’intérêt. Je dois cependant accepter que des critiques de la communauté peuvent ne pas connaître toute la situation avec toutes les magouilles ayant eu lieu dans les coulisses.

Enfin, à propos de conflits, je crois que j’ai appris une vraie leçon de vie au sujet de l’approche idéale à propos des critiques et des issues heureuses. Bien que les billets de blogs aient eu un impact très positif sur la manière dont les gens peuvent exposer leur pensée et partager leurs opinions et visions des choses, ils présentent une facette bien plus sombre. Les blogs sont aussi devenus un moyen d’exprimer parfois un peu trop rapidement des opinions excessivement zélées. Malheureusement, j’ai un exemple plutôt embarrassant de quelqu’un qui est tombé dans ce piège : c’est votre serviteur.

Pour commencer, quelques éléments de contexte. Il existait une entreprise appelée Lindows qui distribuait une version de Linux qui présentait beaucoup de similarités visuelles et fonctionnelles avec Windows. Microsoft voulout interdire l’emploi du nom « Lindows » et une bataille s’engagea pour changer le nom. D’abord, Lindows résista. Mais après que la pression eut monté, l’entreprise se rebaptisa Linspire.

Il y a peu de temps, un type nommé Andrew Betts a décidé de retirer les éléments non-libres de Linspire et de publier les parties libres dans une distribution dérivée de Linspire qu’il a appelée Freespire. Le fait de rediffuser des distributions ou du code n’a certainement rien de nouveau et s’inscrit parfaitement dans la culture de l’open source. À vrai dire, bien des distributions que nous utilisons aujourd’hui ont été dérivées d’outils existants.

Malheureusement, Linspire a considéré que c’était un problème et a demandé à Freespire de changer de nom. En lisant l’annonce du changement, son langage et son style, j’ai l’impression que tout ça pue le pur marketing. Loin de moi l’idée d’insinuer que Betts a été contraint d’écrire cette page ou que les drones marketing de Linspire l’ont écrit et annexé en son nom, mais cela ne me semble pas sonner très juste. Je me serais attendu à trouver des lignes du style « Le nom de Freespire a été changé pour Squiggle afin d’éviter toute confusion avec le produit Linspire. », mais ce n’est pas le cas. Au lieu de cela, on a droit à des morceaux choisis de marketing comme « Afin de prévenir toute confusion, j’ai contacté Linspire qui m’a fait une offre extrêmement généreuse pour nous tous. » La vache ! Quelle peut bien être cette offre-exclusive-qu’on-ne-rencontre-qu’une-fois-dans-sa-vie-et-qu’on-ne-trouve-pas-dans-les-magasins ? Fort heureusement, il poursuit : « Ils souhaitent que tous ceux qui ont suivi mon projet puissent faire l’expérience du vrai Linspire, ET GRATUITEMENT !!! ». Maintenant, dites-nous, je vous prie, comment nous pouvons obtenir cette vraie version du logiciel « ET GRATUITEMENT » ?

« Pour une période limitée de temps, ils mettent à disposition un code de réduction dénommé FREESPIRE qui vous donnera une copie numérique gratuite de Linspire ! Veuillez visiter http://linspire.com/ pour les détails. » Ho… merci.

Dans un billet de mon blog, J’ai décoché à Linspire un bon coup de genou dans les bijoux de famille. J’ai raconté l’histoire, protesté contre ce que je considérais comme de l’hypocrisie considérant leur propre bataille dans des histoires similaires de marques déposées, et j’ai fulminé. J’aurais aimé que Guitar Hero existe à cette époque, cela aurait été un bien meilleur moyen d’utiliser mon temps.

Je me suis trompé. Mon article n’allait jamais servir à quoi que ce soit. Peu de temps après la publication de l’article, le PDG d’alors, Kevin Carmony, m’envoya un courriel. Il n’avait pas l’air satisfait de ma prestation. Son objection, et elle était valable, visait l’absence de concertation mutuelle préalable. Ma première réaction fut de répondre sur mon blog. La réalité de l’histoire était beaucoup moins noire. Et les gens de Linspire n’était pas les ogres que j’avais dépeints. J’ai présenté mes excuses à Kevin et me suis senti idiot.

Beaucoup de conflits sont résolus par des discussions privées où les gens peuvent être ouverts et concentrés sur les solutions sans être dérangés. Au fil des années, j’ai vu beaucoup d’exemples d’une guerre publique houleuse par blogs interposés continuant, alors que, dans les coulisses, il y avait un échange calme et une recherche de solutions.

Jono Bacon a appris à communiquer avec toutes les communautés

Pour conclure

Lorsque j’ai commencé à écrire cet article, il était bien plus court. Mais j’ai continué à ajouter des éléments un par un. Il est sûrement déjà assez long pour que je puisse compter le nombre de personnes lisant cette partie sur les doigts d’une main. Je vais donc l’arrêter ici. Je pourrais continuer éternellement avec des anecdotes croustillantes et des expériences dans lesquelles j’ai été suffisamment chanceux pour être impliqué et pour étendre mes horizons. Mais je finirais par écrire L’art de la communauté II : cette fois-ci, c’est personnel.

La vie est une expérimentation permanente. Et j’espère que votre investissement dans la lecture de cet article vous a apporté un peu d’expérience.

1 http://artofcommunityonline.org

2 http://communityleadershipsummit.com

Crédit photos : gidgetkitchen  (CC-BY-SA) et Ubuntu-news.ru

Sources :

• Le gouvernement compte revoir le cadre de la liberté d’expression (Numerama)
• Vu du Sénat # 23: La liberté sur internet, c’est quoi au juste ? (Le Huffington Post)

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

Une douzaine de villes danoises se sont mises d’accord pour développer ensemble des solutions libres en partenariat avec des sociétés de services locales.

Un exemple à suivre…

Les municipalités danoises utilisent l’open source pour innover et collaborer

Danish municipalities using open source to innovate and collaborate

Gijs Hillenius - 1er février 2013 - OpenSource.com
(Traduction : Moosh, Sphinx, lgodard, Doh-a + anonymes)

Les municipalités danoises utilisent de plus en plus les logiciels libres et open source pour apporter des solutions innovantes et collaboratives dans leurs missions d’information et de communication (ICT). L’année dernière, plus de 10% des municipalités du pays ont rejoint la communauté nouvellement créée Open Website Community OS2. Le groupe possède déjà à son actif un système de gestion municipal de contenu basé sur Drupal (appelé OS2Web) ainsi qu’une application de gestion des réunions sans papier (intitulée OS2dagsorden, NdT : littéralement OS2-ordre du jour).

Les 12 municipalités du consortium OS2 sont soutenues par 19 fournisseurs de services open source danois. En Décembre dernier, le groupe a commencé le développement des deux prochaines applications, OS2kontactcenter et OS2kle, déclare JonBadstue Perdersen, responsable de la section à la municipalité de Syddjurs.

« Comme OS2 le fait habituellement, nous avons commencé à travailler sur OS2kontaktcenter dans un hackerspace en impliquant vingt participants provenant des municipalités et des fournisseurs », indique Badstue. « Et en seulement deux jours nous avons prouvé que nous pouvions proposer des solutions de centres de contacts pour les municipalités, qui combinent et présentent aux visiteurs sur le site web des informations qui sont déjà disponibles sur certains sites et bases de données. » Cette solution utilise efficacement deux taxonomies prédéfinies de l’information, appelées KLE et FORM, rendues disponibles par les administrations publiques.

Marquage du contenu

La seconde et nouvelle solution, OS2kle a pour but de fournir une interprétation automatique du texte. Elle utilise Taxon, un logiciel open source, pour ajouter automatiquement des balises aux documents électroniques.

« Le balisage est devenu un moyen fréquent de structurer de grandes quantités de contenu sur un site web, » explique Badstue. « Mais le procédé consistant à baliser les contenus avec des méta-données utilise beaucoup de ressources. Nous améliorons ce procédé, soit en ajoutant automatiquement des balises, soit en suggérant à l’utilisateur certaines balises à utiliser. »

Le consortium OS2 a débuté en avril de l’année dernière avec les cinq villes de Copenhague, Ballerup, Sønderborg, Syddjurs et Ishøj. Morsø, Jammerbugt, Ringsted, Kolding, Odsherred, Favrskov et Skanderborg les ont rejointes peu après. Selon Badstue : « OS2 a pour objectif de contribuer à l‘open source dans le secteur public. Nous voulons faire du Danemark un pionnier à la fois international et innovant dans ce domaine. »

« Notre communauté montre que les administrations publiques danoises adoptent de plus en plus l‘open source avec le soutien de leurs politiciens locaux. Ce type de logiciels offre les meilleurs outils pour créer une société numérique, ouverte et innovante, nous permettant de collaborer et partager notre travail tout en évitant le blocage dû aux logiciels propriétaires. »

Crédit photo : Angel Torres (Creative Commons By)

Libre ou propriétaire, open source ou sources closes, voilà des lignes de fracture radicales qui sont familières dans le monde du logiciel. Les choses sont moins tranchées peut-être du côté des entreprises qui se définissent non sans arrière-pensées comme plus ou moins « ouvertes ».

Tim Wu nous invite à prendre un peu de recul par rapport à notre conception commune suivant laquelle les modèles ouverts sont destinés à l’emporter. La réussite ou non des grandes entreprises de technologies informatiques ces dernières années montre que la question n’est pas si simple et la partition pas si flagrante.

En adoptant une perspective bien étatsunienne, celle du pragmatisme qui consiste à comparer les résultats, l’auteur tend à évaluer l’ouverture en termes de degrés. À vous de dire si les valeurs du libre ne sont pas écornées au passage.

Une entreprise fermée comme Apple peut-elle réussir sans le talent d’un Steve Jobs ?

par Tim Wu dans cet article du New Yorker

Traduction Framasoft : Texmix, Sphinx, Garburst, Husi10, lamessen, Paul-Arthur, ehsavoie, goofy

On dit depuis un bon moment dans le milieu techno que « le modèle ouvert l’emporte sur le modèle fermé ». En d’autres termes, les systèmes technologiques ouverts, ou bien ceux qui permettent l’interopérabilité, finissent toujours par surpasser leurs concurrents fermés. C’est une véritable profession de foi chez certains ingénieurs. C’est aussi la leçon qu’on peut tirer de l’échec de MacIntosh face à Windows dans les années 90, du triomphe de Google au début des années 2000 et plus largement, de la victoire d’Internet sur ses rivaux au modèle fermé (vous souvenez-vous d’AOL ?). Mais est-ce encore justifié ?

Depuis quelques années, cet adage a été remis en question, principalement à cause d’Apple. Cette entreprise, ignorant les idéaux des ingénieurs et les prêches des experts techno, s’est rapidement cloisonnée dans une une stratégie semi-fermée — ou « intégrée » comme elle aime à le dire — et a défié la règle. Sur le plan structurel, Apple pratique l’intégration bien mieux que ses rivales. Elle possède le matériel, le logiciel et le circuit de distribution. Elle bloque et dessert également beaucoup plus ses concurrents. Eh oui, de cette manière, elle est devenue l’entreprise la plus rentable la planète. Au dernier trimestre, Apple a enregistré plus de bénéfices qu’Amazon n’en a réalisé depuis sa création.

Mais maintenant, depuis les six derniers mois, de manière plus ou moins flagrante, Apple a commencé à trébucher. Vous allez dire que j’exagère, mais je propose une révision du vieil adage « le modèle fermé peut l’emporter, mais vous devez être un génie ». Dans des conditions normales, dans une industrie imprévisible, et étant donné le niveau normal d’erreurs humaines, le libre continue à surpasser le fermé. Pour le dire autrement, une entreprise doit être fermée dans l’exacte proportion de ses talents de visionnaire et de conception.

Pour m’expliquer, je vais d’abord devoir soigneusement exposer ce que j’entends par « ouvert » et « fermé », des mots qui sont largement employés dans le monde de l’informatique, mais avec de multiples sens. La vérité c’est qu’aucune des entreprises n’est complètement ouverte ou fermée ; elles se répartissent sur un spectre, un peu comme celui qu’utilisait Alfred Kinsey pour décrire la sexualité humaine. Pour moi, ici, cela signifie la combinaison de trois éléments.

Tout d’abord, « ouvert » et « fermé » peuvent faire référence à la permissivité de l’entreprise technologique vis-à-vis des partenariats et des interconnexions qu’elle peut créer pour que ses produits arrivent jusqu’aux utilisateurs. Nous disons qu’un système d’exploitation comme GNU/Linux est « ouvert » parce que n’importe qui peut concevoir un produit sur lequel faire tourner GNU/Linux. En revanche, Apple est très exclusif : il ne laissera jamais iOS s’exécuter sur un téléphone Samsung ni vendre des Kindle dans un Apple store.

En second lieu, l’ouverture peut décrire l’impartialité avec laquelle une entreprise technologique traite les autres entreprises par rapport la manière dont elle se traite elle-même. Firefox, le navigateur, traite tous les sites internet de la même manière. En revanche, Apple se traite mieux que les autres (essayez donc de désinstaller iTunes de votre iPhone).

Troisièmement, et pour conclure, cela décrit le niveau de transparence et d’ouverture d’une entreprise selon la manière dont ses produits fonctionnent et peuvent être employés. Les produits open source, ou ceux qui dépendent de standards ouverts, rendent leur code largement accessible. En attendant, une compagnie comme Google peut être ouverte sur bien des points mais garder jalousement le secret sur certaines choses, comme le code de son moteur de recherche. Dans le monde des technologies, la métaphore classique utilisée pour décrire cette dernière différence est la cathédrale contre le bazar.

Aucune entreprise privée n’est entièrement ouverte, bien que quelques fondations à but non-lucratif, comme Mozilla, s’en approchent. De la même manière, aucune entreprise ne peut se permettre d’être entièrement fermée. Un exploitant de plateforme gagne à avoir de bonnes applications disponibles (pensons à ce que serait, hum, l’iPhone sans Google Maps), et trop bloquer détruira ce qui donne sa valeur au produit. Même Apple a besoin d’être assez ouvert pour ne pas trop déranger les consommateurs. Vous ne pouvez pas lancer le Flash d’Adobe sur un IPad, mais vous pouvez brancher presque n’importe quel type d’écouteur dessus.

L’idée que « le modèle ouvert l’emporte sur le modèle fermé » est historiquement assez récente. Dans la majeure partie du XX^e siècle, l’intégration était considérée comme la forme d’organisation commerciale supérieure. Les modèles fermés ou intégrés arrivent avec des avantages reconnus depuis longtemps et même proclamés haut et fort par les économistes. La coordination est un avantage-clé : en théorie, avec une entreprise qui coordonne tous les aspects et caractéristiques d’un produit donné, le résultat peut mieux fonctionner que celui d’un rival non-coordonné. L’économiste Joseph Farell a appelé ceci « internalisation des économies complémentaires ». Si cela ne vous dit rien, considérez l’effet Disneyland. Disney contrôle tout avec une poigne de fer ou presque, et le parc d’attractions fonctionne sans anicroches, avec une réussite impressionnante bien supérieure par exemple à une fête foraine classique.

Andrew Carnegie s’est appuyé sur une logique similaire à celle d’Apple lorsqu’il a intégré l’extraction minière avec la production d’acier au sein de U.S. Steel. Les vieux studios Hollywood des années trente et quarante ont intégré le jeu, les scénarios, la production et les cinémas dans une seule et même entreprise. Elle a ainsi chassé tous les autres de son industrie. I.B.M. avait un modèle fermé et le vieux monopole de A.T. & T. était le système fermé par excellence : vous n’aviez pas le droit de posséder votre propre téléphone mais seulement d’en utiliser un produit par quelqu’un d’autre.

La sagesse populaire commença à changer dans les années soixante-dix. Sur le marché des technologies, des années quatre-vingt au milieu des années deux mille, les systèmes ouverts ont vaincu à plusieurs reprises leurs concurrents fermés. Windows de Microsoft a battu ses rivaux en adoptant un modèle plus ouvert. À la différence du système d’exploitation d’Apple qui était supérieur sur le plan technique, Windows fonctionnait sur n’importe quel matériel et faisait marcher presque tous les logiciels. Au même moment, Microsoft surpassa I.B.M. et son modèle intégré verticalement (qui se souvient de Warp O.S. ?), Google était audacieusement ouvert dès sa conception originale et passa devant Yahoo et son système sélectif de publicité au placement. La plupart des vainqueurs, entre quatre-vingt et deux mille, tels que Microsoft, Dell, Palm, Google et Netscape, suivaient un modèle ouvert. Internet même, basé sur un projet financé par le gouvernement, était à la fois incroyablement ouvert et incroyablement réussi. Un mouvement était né et avec lui la règle selon laquelle : « le modèle ouvert l’emporte sur le modèle fermé ».

Le triomphe des systèmes ouverts a révélé un défaut majeur dans les conceptions fermées. Selon la théorie économique, dans un état d’information parfaite, un concepteur central devrait être capable de produire un meilleur produit. Mais c’est seulement vrai si le futur est prévisible, et si on ignore la tendance des êtres humains à commettre des erreurs bêtes. Dans un système fermé, avec un seul décideur, les erreurs coûtent très cher. Les décisions stupides, ou qui compromettent le produit pour des profits à court terme, ne vont pas rendre les produits seulement un peu moins bons mais vraiment pires que ceux du concurrent direct. Par exemple, la politique de chasse gardée d’AOL des années 90 consistait à essayer de deviner ce que les utilisateurs allaient vouloir, mais AOL a fait un tas d’erreurs, et finalement ça ne correspondait pas à un Web ouvert.

En revanche, un produit ouvert est mieux protégé des erreurs humaines car ce n’est pas une unique entité qui prend une décision susceptible de détruire le produit. Les économistes Tim Bresnahan et Shane Greenstein, dans les années 90, ont décrit ce phénomène sous le terme « direction technique partagée », et ils lui donnaient un sens mélioratif. Le produit est le résultat collectif de plusieurs, voire parfois de milliers de décideurs. Un produit ouvert peut aussi profiter des contributions volontaires et collectives des masses, un point mis en avant par Yochai Benkler. Ainsi, une entrée sur Wikipédia peut être vague et contenir des erreurs, mais le corpus dans son ensemble restera impressionnant. Au milieu des années 90, Windows n’était pas aussi intuitif que Macintosh, mais tous les accessoires et les applications en firent collectivement un produit supérieur.

Ce qui nous amène aux années 2000 et au magnifique parcours d’Apple. Pendant presque douze années, Apple a battu la mesure avec succès. Mais c’est parce qu’il avait le meilleur des systèmes possibles, à savoir, un dictateur disposant d’un contrôle absolu, qui était aussi un génie. Steve Jobs était la version entreprise de l’idéal de Platon : le roi-philosophe nettement plus efficace que toute forme de démocratie. L’entreprise dépendait d’un unique esprit central, mais il a fait très peu d’erreurs. Dans un monde sans erreurs, le fermé bat l’ouvert. En conséquence, pour un temps, Apple triompha de ses rivaux.

Alors que doit faire une entreprise technologique ?

Chacun est confronté à cette question du modèle ouvert ou fermé, et voici comment y répondre. Premièrement, il existera toujours un compromis difficile entre systèmes ouverts et fermés, et il est donc inutile de trop s’enfermer dans l’une ou l’autre des options. Il est facile de sous-estimer les projets ouverts (personne ne pensait que Wikipédia fonctionnerait), mais même les projets ouverts ont besoin de contrôle à certains niveaux. Finalement, plus votre vision et vos compétences de créateur sont bonnes, plus vous pouvez essayer d’être fermé. Si vous pensez que vos concepteurs de produits peuvent égaler le quasi sans-faute de Jobs ces vingt dernières années, allez-y. Mais si de simples mortels font tourner votre entreprise, ou si vous êtes face à un futur très imprévisible, les analyses économiques suggèrent qu’un système ouvert est plus sûr. Vous pourriez peut-être vous fier à ce test : en vous levant le matin, regardez dans le miroir et demandez-vous : suis-je Steve Jobs ?

Comme le soulignait PCInpact récemment Microsoft interdit le transfert de la licence Office 2013 vers un autre PC.

L’arrivée de la nouvelle version de la célèbre suite bureautique s’accompagne en effet d’un contrat de licence encore plus restrictif qu’auparavant, ce qui revient bien moins à acheter un logiciel qu’à le louer sur un seul et unique ordinateur en priant pour que ce dernier n’expire pas tout de suite (malgré son obsolescence programmée, ce qui est un autre sujet).

Du coup, certains utilisateurs, même parmi les plus fidèles, réalisent (enfin) qu’on les prend vraiment pour des vaches à lait et lorgnent (enfin) du côté de GNU/Linux et LibreOffice.

Microsoft perd un fanboy de plus

Microsoft loses yet another fanboy

Jack Wallen - 19 février 2013 - TechRepublic.com
(Traduction : jay91, lukkas35, Goodbox, aKa, nepski, VIGNERON, RavageJo, goguette, Texmix, Kyriog, Penguin, QC, chdorb, Norore, maxlath + anonymes)

Un autre mord la poussière pendant que Microsoft (et son utilisation déplaisante des licences) fait fuir un fan de longue date. Jack Wallen jette un œil à ce qui attend Microsoft.

Non, ce n’est pas quelqu’un de connu. Ce n’est même pas quelqu’un qui soit déjà apparu dans les médias, dans un mème, ou qui aurait participé à un hashtag ou une flashmob. Microsoft a perdu un des fanboys avec lesquels je travaille. Cette personne est un de ces types qui comprennent les choses à plusieurs niveaux. Non seulement il est incroyablement intelligent, mais c’est aussi un brillant électronicien.

Mais lorsque Microsoft a commencé à annoncer leurs termes de licence pour Office 2013 — il a commencé à me poser des questions. Elles commençaient toutes par « Au fait Jack, parle moi de Linux ». Et c’est ce que j’ai fait. Il n’a pas fallu longtemps pour qu’il installe Ubuntu 12.10 à la place de Windows 7 et qu’il soit heureux de travailler, sans Microsoft, et ce sans perdre le rythme.

Vous devez vous demander en quoi exactement les nouveaux termes du contrat de licence d’Office 2013 peuvent faire changer d’avis un fan Microsoft de longue date ? Laissez-moi vous lister les points les plus importants :

• Chaque licence est liée à un compte Microsoft Live (qu’il vous faut posséder) ;
• Seules cinq licences peuvent être liées à un même compte (nous avons des clients qui en passent par une dizaine de versions d’Office par semaine — ça pourrait causer quelques problèmes) ;
• Chaque licence sera définitivement assignée à une seule machine.

Ces points sont seulement les plus néfastes, des points qui vont faire mal aux utilisateurs à différents niveaux. Ces conditions de licence partent du principe que les machines ne tombent jamais en panne - et que si elles le font, les utilisateurs ne verront pas d’inconvénient à sortir à nouveau la liasse de billets pour racheter la licence.

Faux et archi faux.

Les ordinateurs tombent en panne, certains sont parfois d’emblée défectueux avec des défauts qui ne seront parfois visibles qu’après plusieurs jours (ou semaines) d’utilisation. Que vont faire ces utilisateurs là ? Acheter Office 2013 deux fois en l’espace de quelques semaines ?

À cela, Microsoft va répondre, « Vous pouvez souscrire à Office 365 ». À ça, je répondrai d’utiliser gratuitement Google Docs pour n’avoir plus aucun problème.

Au cours de l’année dernière, Microsoft en a fait plus pour pousser les gens vers des solutions alternatives qu’il ne l’avait fait pendant très longtemps. D’abord, il a mis sur le marché l’une des interfaces graphiques les moins intuitives qui soit. Aujourd’hui, c’est la licence de Microsoft Office qui change. En bref, Microsoft est en train de perdre des fans et des utilisateurs. Vers quoi se tournent-t-il ? Linux. De plus en plus de gens se rendent finalement compte qu’il y a une alternative et que cette alternative est en fait MEILLEURE !

« Toutes ces années gâchées. » disais-je, secouant ma tête, tentant de cacher ma joie.

Les entreprises et les consommateurs ont beaucoup dépensé dans les produits Microsoft. Comment sont-ils remerciés de leur fidélité ? Une baffe en plein visage, et un trou dans le porte-monnaie ! Cette pagaille ne va pas bien se finir pour Microsoft. En revanche, cela va dans le bon sens pour les systèmes d’exploitation et logiciels comme Ubuntu et LibreOffice.

Beaucoup d’entre nous ont dit qu’il serait inévitable d’en arriver là. À un moment, on a vu venir le côté binaire — Microsoft allait brûler le seul pont qu’il ne pouvait se permettre de brûler — celui qui se trouvait entre Redmond et ses légions de fanboys. Cela ne se fera sans doute pas en une nuit, mais les aficionados d’une des plus grosses entreprises à avoir jamais honoré les bits et les octets vont lui tourner le dos et chercher de plus (ou)vertes pâtures. Quand cela va se produire, Linux aura enfin ce qui lui est dû. L’effet cascade forcera Microsoft à re-calibrer ses pratiques commerciales dans l’urgence.

Bien sûr, on a déjà entendu cet air-là avant. Microsoft va probablement tenter de mener le combat devant les tribunaux, mais pas là où il devrait : dans les cœurs et les esprits de ses consommateurs.

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

Il fut un temps ou débuter dans « le Libre » se résumait avant tout à coder ou plus modestement installer une distribution GNU/Linux. Aujourd’hui les choses ont bien changé et il existe de multiples autres façons d’y entrer. Framasoft est d’ailleurs là pour en témoigner ;)

Une invitation à venir nous rejoindre en somme…

Remarque : Il s’agit d’une traduction et donc les liens renvoient vers des ressources anglophones. Si vous avez des liens plus locaux à proposer, surtout ne pas hésiter.

10 façons de commencer dans l’open source

10 ways to get started with open source

Jason Hibbets - 29 janvier 2013 - OpenSource.com
(Traduction : goofy, Tibo_R, XeO2, Steph, Alpha, Sylvie, jtanguy, aKa, Liaz, Norore + anonymes)

Par expérience, je sais qu’un grand nombre de personnes veulent découvrire et participer à l’open source, mais ne savent pas par où commencer ; et l’idée que l’on est obligé d’écrire du code pour contribuer à un projet open source constitue une véritable barrière. J’ai donc esquissé 10 façons de commencer avec l’open source et ce sans jamais écrire une seule ligne de code.

Je suis ouvert à toutes idées et ajouts ; il y a sans doute beaucoup plus que 10 façons de contribuer.

10 façons de commencer à utiliser l’open source

1. Utiliser de l’open source dans votre travail quotidien. Téléchargez et installez un navigateur web, un client de messagerie, ou une suite bureautique libres — peu importe le système que vous utilisez. C’est l’une des façons les plus simples de commencer à utiliser des logiciels libres. Je conseillerai Firefox pour la navigation internet et Thunderbird pour les emails. Utilisez LibreOffice pour votre traitement de texte, vos tableurs et vos diaporamas, vous aurez un équivalent de Microsoft Office gratuit ! J’appelle ces logiciels des applications porte d’entrée, parce qu’une fois que vous commencez à les utiliser, vous allez découvrir d’autres outils open source (et vous n’aurez pas envie de revenir en arrière !)

2. Rejoindre un projet open source. Je sais que rejoindre un projet open source peut faire peur, mais les contributeurs de tous niveaux sont les bienvenus. Les communautés open source utilisent des chefs de projets, des graphistes, des communicants, des commerciaux et beaucoup d’autres compétences dans leurs travaux. Si vous souhaitez présenter l’open source aux étudiants, voilà une très bonne façon de commencer. On ne sait jamais, s’impliquer et participer activement à un projet open source peut améliorer un CV et mener à un emploi.

3. Lire un livre à propos de l’open source. Voici un choix de quelques titres auxquels vous pouvez jeter un coup d’oeil : Open Advice, Coding Freedom, The Power of Open, ou l’un de nos livres numériques. (NdT : En français il y a évidemment tous les titres de la collection Framabook)

4. Apprendre à créer et nourrir des communautés de contributeurs. Parcourez le livre en ligne The Open Source Way, et partagez vos nouvelles connaissances en créant une communauté ou en en rejoignant une existante.

5. Commencer à utiliser les licences Creative Commons. Avant de créer votre nouvelle œuvre d’art, photographie, écrit ou musique, utilisez un copyleft au lieu d’un copyright. En utilisant des licences Creative Commons, vous pouvez partager votre travail avec le monde entier. Vous devrez d’abord choisir celle qui vous correspond, vous pourrez ensuite trouver intéressant de découvrir comment les Creative Commons sont utilisées dans des environnements aussi variés que les gouvernements, les entreprises ou le journalisme. (NdT : Voir aussi L’éducation utilise une licence Creative Commons défectueuse, par R. Stallman sur le Framablog)

6. Commencer l’exploration. Regardez le projet OpenROV et explorez l’océan ou un lac local. Si vous ne voulez pas être mouillé, enfilez une combinaison spatiale et regardez ce que ça fait d’explorer Mars.

7. Bricoler par soi-même et créer quelque chose. Les petites cartes Linux, comme la Raspberry Pi, font des choses incroyables. Découvrez les autres cartes électroniques de création comme les « Makey Makey » (cf cette vidéo) ou une variété de produits électroniques de « SparkFUN ». Si vous êtes dans l’impression 3D, assurez-vous de savoir comment vous pourriez utiliser Inkscape.

8. Devenir créatif. Remplacez Photoshop par GNU Image Manipulation Program (GIMP), InDesign par Scribus, ou utilisez d’autres outils comme MyPaint, Inskape, Audacity et Blender. Si cela vous intéresse, regardez notre présentation en 7 minutes des Outils créatifs Open source. Puis découvrez l’étendue des outils de design en 2012. Assurez-vous d’avoir pris connaissance de nos autres outils tels que Dream Studio, TuxPaint et KDEnlive pour vos besoins créatifs.

9. Apprendre la programmation. Remarquez que je n’ai pas dit « Apprendre à coder ». Différents outils sont préinstallés sur certains Raspberry Pi et sont utilisés pour apprendre aux enfants à programmer. J’aurais aimé avoir ce genre de choses quand j’ai appris la programmation au lycée.

10. Suivre un cours en ligne. Le mouvement OpenCourseWare, mené par MITOCW, est en train de changer notre mode d’apprentissage. Commencez par regarder ce Webcast sur le MIT OpenCourseWare. Il y a tellement d’événements open source dans le champ éducatif: « Moodle » et « School management software for teachers and students » sont deux de ces nombreuses ressources fantastiques. (NdT : Exemple en France la présentation du MOOC ITyPA)

Le fait est qu’il y a énormément de manières de commencer dans l’open source. Vous souvenez-vous de la façon dont vous avez débuté ? Partagez l’histoire de votre première expérience avec l’open source ou comment vous l’avez présentée à quelqu’un d’autre.

Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framasoft : Miki, Vilnus Atyx, Sphinx, peupleLà, Goofy, tcit, Julius22, Garburst, Cyrille L., lerouge, Lycoris, vvision, lamessen

Comment ne pas lancer une communauté

Robert Kaye

Robert Kaye associe son amour de la musique et de l’open source dans l’encyclopédie de musique ouverte MusicBrainz. Robert a créé et dirige la MetaBrainz Foundation, une organisation à but non-lucratif basée en Californie, dans la continuité d’un travail de longue haleine pour améliorer l’expérience de la musique numérique. Au-delà du hack pour MusicBrainz, Robert recherche des festivals intéressants comme le Burning Man et des projets périphériques tels que bidouiller des robots pour préparer des cocktails. Comme il est invariablement couronné d’une chevelure aux vives couleurs, vous n’aurez aucun mal à le reconnaître dans une foule.

En 1998, je travaillais pour Xing Technology à San Luis Obispo et j’étais à fond sur notre nouveau projet AudioCatalyst. C’était l’un des premiers programmes d’extraction de MP3 intégré utilisant la base de données CDDB. Il s’agit de la base de données de CD qui permet à chaque lecteur de trouver le titre et la composition de tout CD. Si le CD n’est pas enregistré, on peut saisir les données afin que la prochaine personne qui en a besoin puisse s’en servir. J’adorais ce projet collaboratif en ligne et j’y ai enregistré des centaines de CD en quelques années.

Un jour, il nous a été annoncé que CDDB avait été achetée par Escient, une société qui deviendrait GraceNote par la suite. La base de données CDDB avait été privatisée, de sorte que plus personne ne pouvait la télécharger dans son intégralité ! Pour parachever le tout, Escient ne dédommagea aucun des contributeurs pour leurs efforts. En manœuvrant ainsi, ils arnaquaient le grand public. J’étais plutôt furieux de cette décision et je le suis encore aujourd’hui.

Plus tard dans la semaine, lors d’une fête avec des amis, je me plaignais de ce qui était en train de se passer et expliquais à quel point j’étais mécontent. Mon ami Kevin Murphy me dit : « Pourquoi tu ne démarrerais pas ton propre projet open source pour faire concurrence à ces enfoirés ? »

Quelques semaines plus tard, je finissais de travailler pour Xing et j’avais quelques semaines de temps libre avant de commencer chez EMusic. Je décidai d’apprendre le Perl et la programmation web en autodidacte et de démarrer la création de CD Index, un projet sans compatibilité et sans infraction avec CDDB. J’ai bidouillé le projet pendant cette pause mais l’ai rapidement oublié lorsque je suis devenu membre du projet FreeAmp chez EMusic.

C’est alors que Slashdot demanda, en mars 1999, quelle solution open source allait remplacer CDDB. J’ai passé le reste de la journée et la majeure partie de la nuit à finir CD Index et à le déployer. J’ai soumis un billet sur Slashdot parlant de mon projet (1) et il fut mis en ligne rapidement. Comme prévu, des centaines de geeks se manifestèrent en quelques minutes si bien que mon serveur tomba et rendit l’âme.

Les masses de gens qui arrivèrent commencèrent immédiatement à gueuler pour que les choses se fassent. Il n’y avait même pas encore de liste de diffusion ou de logiciel de suivi de problèmes ; ils insistèrent pour en avoir tout de suite. Comme j’étais novice dans l’open source, je ne savais pas vraiment ce qui était nécessaire ou non pour lancer un tel projet, j’ai fait comme les gens le demandaient. Les protestations reprirent de plus belle et davantage de gens encore insistèrent pour que je ferme le service étant donné qu’il n’était pas parfait. Mais même au milieu de ce vaste bazar, nous avons reçu plus de 3 000 soumissions de CD au cours des premières 24 heures.

Une fois que les choses furent calmées, il y avait encore beaucoup de gens qui rouspétaient. Greg Stein déclara qu’il allait écrire une meilleure version immédiatement. Mike Oliphant, l’auteur de Grip, annonça qu’il allait également travailler à une nouvelle version. Alan Cox vint et proclama que les bases de données SQL n’y suffiraient pas et que je devais utiliser DNS pour créer un meilleur service de recherche de CD. — Hein, quoi ? J’étais très mécontent de la communauté qui grandissait autour du billet publié sur Slashdot. Je ne voulais pas d’un lieu où les gens se manquent de respect et où certains se croient permis de gueuler encore plus fort pour obtenir ce qu’ils veulent. Je perdis rapidement tout intérêt pour le projet et CD Index déclina. Les autres projets que des personnes avaient promis de commencer (à l’exception de FreeDB) ne prirent jamais forme.

Alors, quand la bulle du point com a éclaté, j’ai eu besoin de réfléchir à ce que j’allais faire ensuite. Il était clair que mon boulot chez EMusic n’avait rien de sûr ; je continuais à conduire un roadster Honda S2000, ma voiture trophée de l’époque point com. Avec les traites de la voiture qui doublaient mon loyer, je devais décider : soit mener ma propre entreprise et vendre ma voiture de rêve, soit déménager à Bay Area (San Francisco) et travailler sur le rêve de quelqu’un d’autre, si jamais je parvenais à y trouver un travail. Je décidai que le plus intéressant serait de travailler sur une encyclopédie musicale complète construite par les utilisateurs. Je vendis la S2000 et me concentrai pour commencer à travailler sur une nouvelle mouture de CD Index.

Au cours d’une autre soirée, le nom MusicBrainz me vint et j’enregistrai le nom de domaine pendant la fête. Le jour suivant, motivé par le nouveau nom du projet, je commençai à bidouiller sérieusement et, à l’automne 2000, je lançai musicbrainz.org. Lancer n’est pas le bon mot, ici — je mis le site en place et me demandai alors comment éviter une nouvelle communauté de gosses hystériques venant de Slashdot. Je n’importai jamais de données depuis CD Index, ni ne mentionnai MusicBrainz sur les listes de diffusion de CD Index. Je me suis simplement éloigné du projet CD Index ; je ne voulais plus rien avoir à faire avec celui-ci. À la fin, j’ai décidé d’ajouter un simple bouton à la page web de FreeAmp qui mentionnait MusicBrainz.

Et une chose très étonnante s’est produite : des gens sont venus jeter un coup d’œil au projet. C’était seulement quelques personnes au début, mais quand quelqu’un me signalait quelque chose, je commençais une conversation et recueillais autant de retours d’informations que possible. J’améliorais le logiciel grâce à ces retours. J’ai aussi imposé un ton de respect sur les listes de discussion et, à chaque fois que quelqu’un était irrespectueux, j’intervenais et haussais le ton.

Mes efforts concentrèrent le projet vers son amélioration. Je l’ai fait pendant trois ans avant qu’il ne devienne clair que cette approche était efficace. La base de données croissait régulièrement et la qualité des données passa d’exécrable à bonne en quelques années.

Les bénévoles, ça va ça vient, mais je suis la colonne vertébrale du projet, c’est toujours moi qui donne le la et sa direction à l’ensemble. Aujourd’hui, nous avons une association à but non-lucratif avec 325 employés dans quatre pays, Google, la BBC et Amazon comme clients et notre bilan financier est bon. Je ne pense pas que cela aurait pu se produire avec la communauté CD Index.

Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framasoft :peupleLà, elquan, tcit, Julius22, Garburst, okram, Jej, Cyrille L., lerouge, Lycoris, Goofy, CoudCoud, vvision, lamessen

Du bon usage de la couleur et des images dans le design

Eugene Trounev

Membre actif du logiciel libre et de KDE depuis près de six ans, Eugene Trounev a commencé chez KDEGames et a poursuivi pendant l’ensemble de la transition de KDE3 à KDE4. Il a participé à toute la transition de KDE3 vers KDE4. Actuellement, il s’occupe principalement de la présence de KDE sur le Web et de l’apparence du bureau principal.

Depuis la nuit des temps, les hommes ont utilisé la puissance des images et de la couleur pour transmettre des informations, attirer l’attention ou la détourner. Un célèbre dicton dit « une image vaut mille mots » et on ne saurait mieux dire. Depuis la façon dont nous nous habillons jusqu’aux néons criards des magasins de centre-ville dans le monde entier, chaque couleur, chaque forme et chaque courbe joue un rôle.

Connaître ce rôle n’est cependant pas si difficile, puisque toutes ces variations de teintes et de lignes sont assemblées pour être lues et ressenties par chacun de nous. Il est donc vrai qu’un design génial doit venir droit du cœur, étant donné qu’il est censé parler d’abord au cœur. Néanmoins, le cœur seul ne pourrait pas produire un design génial si quelques règles n’étaient pas d’abord définies et respectées.

Il existe plusieurs façons de classer les couleurs, mais la plupart mettent en avant les propriétés physiques ou chimiques de la lumière ou de l’encre. Bien que cela soit important pour le résultat final, ces propriétés ne vous aideront pas à faire un design attrayant. Ce qui fonctionne le mieux, selon moi, est de séparer entre couleurs chaudes et couleurs froides. Pour faire simple, les couleurs chaudes sont celles qui sont les plus proches de la teinte rouge : le rouge, l’orange et le jaune. Les couleurs froides, à l’opposée du spectre, sont celles qui se rapprochent du bleu : le vert, le bleu et, dans une moindre mesure, le violet. Il est important de se rappeler que « froid » représente aussi le calme et la respiration, tandis que « chaud » est impulsif et dangereux. Ainsi, en fonction des sentiments que vous souhaitez éveiller au sein de votre public, vous devriez utiliser des couleurs plus chaudes ou plus froides. Des couleurs chaudes pour attirer l’attention ; des couleurs froides pour informer. Une utilisation excessive de l’une ou de l’autre aboutira soit à une surchauffe — provoquant des sentiments négatifs chez votre public — soit à un refroidissement — ce qui causera son indifférence.

Il est important de se souvenir que le noir, le blanc et les nuances de gris sont aussi des couleurs. Celles-ci, toutefois, sont neutres. Elles ne provoquent aucun sentiment mais établissent plutôt une atmosphère. Leurs propriétés seront discutées plus loin.

Chaque image est d’abord et avant tout une collection de couleurs et, en tant que telle, suivra les règles de la gestion des couleurs. Déterminer la couleur dominante de votre image est la clé du succès. Essayez d’avoir une vue d’ensemble, sans vous concentrer sur les détails. Une bonne manière de le faire consiste à placer une image sur un fond sombre, puis à se reculer de quelques pas et de l’observer de loin. Quelle couleur percevez-vous le plus ?

Toutefois, toutes les images n’ont pas une couleur dominante. Quelquefois, vous rencontrez un amas de couleurs dont vous ne pouvez déterminer la teinte dominante, quelle que soit l’intensité avec laquelle vous le regardez. Essayez d’éviter de telles illustrations car elles vont inévitablement déconcerter vos utilisateurs. Confrontés à des images de ce type, les gens auront tendance à rapidement regarder ailleurs et cela ne leur laissera pas bonne impression, quel que soit le sujet abordé.

Au delà de la couleur, les images ont aussi une texture car, en fin de compte, elles ne sont rien de plus qu’un ensemble de couleurs texturées. Identifier la texture dominante d’une image n’est pas aussi simple que de percevoir sa couleur car les textures sont rarement évidentes, particulièrement dans les photographies. Il existe néanmoins quelques indicateurs pouvant vous aider. La nature humaine fait que nous sommes attirés par les formes incurvées (aussi appelées formes « naturelles ») tandis que les formes anguleuses et effilées sont considérées comme moins attirantes. C’est pour cela que l’image d’une feuille verte et incurvée sera plus attirante que celle d’un pic en métal. Pour résumer : la clé d’un design réussi et séduisant est une bonne combinaison, correctement équilibrée, entre couleurs et textures au sein des images utilisées.

Un autre aspect aussi important de tout design réussi est la mise en forme du texte et la disposition des espaces autour de celui-ci. Tout comme pour les textures et les couleurs, vous devriez toujours garder à l’esprit que les gens aiment respirer. Cela signifie qu’il devrait y avoir suffisamment d’espace dans et autour du texte pour le rendre plus facilement repérable, lisible et compréhensible.

Imaginez un exemple constitué de deux pages — l’une venant d’un roman d’amour tandis que l’autre est tirée d’un document légal. Vous préféreriez très probablement le roman d’amour par rapport à un document légal quel que soit le moment. Mais savez-vous pourquoi ? La réponse est simplement que vous aimez respirer. Une page de roman d’amour contient vraisemblablement trois éléments importants : des dialogues, des paragraphes et des marges extra-larges, tandis que la plupart des documents légaux ne comportent d’ordinaire aucun des trois. Tous les éléments mentionnés ci-dessus font vivre la page et la rendent dynamique, tandis qu’en leur absence, la page ressemble à un gros pavé de texte. L’œil humain, étant plus habitué à un certain degré de variation de formes, se sent plus à l’aise lorsque les pages bénéficient d’une mise en page aérée et fluide.

Toutefois, cela n’implique pas que chaque texte doive avoir ces trois éléments pour avoir l’air plus attrayant, loin de là. Tout texte peut être rendu facile et agréable à lire en l’aérant suffisamment.

Un peu de respiration ou d’espace peut être injecté au texte de plusieurs manières, telles que l’espacement des lettres, des lignes et des paragraphes ; les marges du contenu, de la section et de la page ; et pour finir, la taille de la police. Essayez de garder une espace d’au moins un caractère de haut entre vos paragraphes et vos lignes ainsi que des espaces de deux caractères de haut entre vos sections. Autorisez-vous des espaces généreux autour du texte sur une page en cadrant assez largement vos marges. Essayez de ne jamais avoir une taille de police inférieure à 10 points pour vos paragraphes tout en gardant les titres assez gros pour les faire ressortir.

Tout comme les animaux, les êtres humains sont souvent attirés par les éclats de couleurs brillantes et les textures inhabituelles. Plus le regard est attiré, plus les personnes ignoreront d’autres points d’intérêt potentiels. Cette simple règle de l’attraction est utilisée indifféremment par les hommes et les femmes pour canaliser l’attention des autres loin de certains éléments qui doivent selon eux passer inaperçus. Le meilleur exemple d’une telle supercherie est celui d’un magicien de rue qui distrait souvent l’attention des spectateurs par l’utilisation de fumée, de flammes ou de tenues tape-à-l’œil.

Il est important, ici, de se rappeler que les mots sont aussi visuels puisqu’ils créent des images et des associations spécifiques. La supercherie qui peut être réalisée avec de la fumée et du feu peut également être accomplie par le biais d’une utilisation créative des mots. Le meilleur exemple de supercherie quotidiennement réalisée grâce aux mots est, de loin, celle des étiquettes de prix. Vous êtes-vous déjà demandé pourquoi les commerçants aimaient autant les 99 et les 95 centimes ? C’est parce que les 9,95€, ou même les 9,99€, semblent plus attractifs que 10€, même si, dans la réalité, ils ont le même impact sur votre porte-monnaie. Ajoutez-y une « vieille » étiquette de prix à 10€ ostensiblement barrée d’une épaisse ligne rouge et vous aurez un bon aimant à clients.

Conclusion

L’obtention d’un design à la fois beau et attractif passe par ces règles de base : soyez judicieux dans vos choix iconographiques ; faites un bon usage des couleurs et des textures pour créer une atmosphère ; donnez à votre lecteur des espaces pour respirer ; détournez l’attention des parties qui comptent le moins pour l’amener sur celles qui sont importantes.

Ce court article n’entend pas couvrir toute l’étendue du spectre des différents styles et techniques de design. Il s’agit plutôt de vous donner à vous lecteur une base sur laquelle vous pourrez vous appuyer pour construire.

Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framasoft : Miki, peupleLà, dabou, Asta, elquan, Goofy, Julius22, okram, lamessen, Jej, lerouge, SaSha_01, Lycoris, meumeul, vvision

Ne soyez pas timide

Máirín Duffy Strode

Máirín Duffy Strode utilise des logiciels libres et open source depuis le lycée et y contribue depuis huit ans. Elle contribue aux communautés Fedora et GNOME et a travaillé sur l’identité visuelle des interactions, l’image de marque ou l’iconographie de plusieurs applications libres et open source importantes telles que Spacewalk, Anaconda, virt-manager, SELinux et SSSD. Elle s’est également engagée dans des activités de sensibilisation en enseignant les techniques de design à des enfants à l’aide d’outils libres et open source tels que GIMP et Inkscape qu’elle défend ardemment. Elle est à la tête de l’équipe de conception graphique de Fedora et designer d’interaction senior chez Red Hat, Inc.

Je connaissais et utilisais des logiciels libres et open source bien avant de devenir contributrice. Ce n’est pas faute d’avoir essayé — il y a eu quelques faux départs auxquels je n’ai pas donné suite principalement parce que j’étais trop timide et que j’ai eu peur d’aller plus loin. Sur la base de ces tentatives avortées et de ce que m’ont rapporté d’autres designers qui se sont embarqués dans des projets libres et open source, j’ai cinq astuces à vous offrir si vous êtes un designer aspirant au statut de contributeur au logiciel libre et open source.

1. Sachez que l’on a besoin de vous et qu’on vous veut (très fort !)

Mon premier faux départ s’est produit alors que j’étais étudiante en première année d’informatique au Rensselaer Polytechnic Institute. Il y avait un projet particulier que j’utilisais beaucoup et auquel je voulais participer. Je ne connaissais personne au sein du projet (ni qui que ce soit investi dans le logiciel libre). J’ai donc fait une tentative à froid. Le site web du projet signalait que les contributeurs voulaient de l’aide et qu’ils avaient un canal IRC. J’y ai alors traîné pendant une semaine ou deux. Un jour, après une pause dans la conversation, j’ai osé élever la voix. J’ai dit que j’étais une étudiante en informatique intéressée par l’ergonomie et que j’adorerais participer.

On m’a répondu : « Dégage ! ». Qui plus est, on m’a fait comprendre que mon aide n’était ni nécessaire ni désirée.

Cela a retardé mon engagement de quelques années — il avait suffi de quelques mots un peu rudes sur IRC pour me dissuader de réessayer pendant près de cinq ans. Je ne découvris que bien plus tard que la personne qui m’avait plus ou moins expulsée du canal IRC de ce projet était en marge du projet, qu’elle avait un lourd passif de ce genre et que je n’avais vraiment rien fait de mal. Si seulement j’avais persévéré dans mes tentatives d’approche et conversé avec d’autres personnes, j’aurais pu commencer à ce moment-là.

Si vous souhaitez contribuer au logiciel libre et open source, je vous garantis qu’il y a un projet quelque part qui a vraiment besoin de votre aide, en particulier si vous êtes orienté design ! Faites-vous du design web ? De l’iconographie ? De l’ergonomie ? De l’habillage ? Des maquettes d’interface utilisateur ? J’ai parlé à de nombreux développeurs de logiciels libres et open source qui non seulement sont désespérément à la recherche d’aide dans ce domaine, mais qui en plus l’apprécieraient vraiment et vous vénéreraient pour l’avoir apportée.

Si vous rencontrez des résistances la première fois que vous essayez de participer dans un projet, apprenez de mon expérience et n’abandonnez pas tout de suite. Si, en définitive, le projet n’est pas fait pour vous, ne vous inquiétez pas et passez votre chemin. Il y a des chances pour que vous trouviez un projet que vous adorerez et qui vous adorera en retour.

2. Aidez le projet pour qu’il vous aide à aider les autres

Bien des projets libres et open source sont aujourd’hui dominés par les programmeurs et les ingénieurs. Et si certains ont la chance qu’une ou deux personnes créatives s’investissent, dans la plupart des projets, un designer, un artiste ou une autre présence créative représente un rêve souvent-caressé-mais-jamais-réalisé. En d’autres termes, même s’ils comprennent qu’ils ont besoin de vos compétences, ils peuvent ne pas savoir quelle sorte d’aide ils peuvent vous demander, quelle information ils doivent vous donner pour que vous puissiez être productif ni même les bases pour travailler avec vous efficacement.

Quand j’ai commencé à m’investir dans différents projets libres et open source, j’ai rencontré beaucoup de développeurs qui n’avaient jamais travaillé directement avec un designer auparavant. Au début, je me suis sentie un peu inutile. Je ne pouvais pas suivre toutes leurs conversations sur IRC parce qu’ils parlaient de leur cuisine interne et de détails techniques qui ne m’étaient pas familiers. Quand ils se sont donné la peine de me prêter attention, ils m’ont posé des questions comme « Quelle couleur dois-je mettre ici ? » ou « Quelle police dois-je utiliser ?  ». Ce que je voulais vraiment en tant que designer d’interactions, c’était d’être associée à la prise de décision lorsqu’on abordait les contraintes spécifiques du projet. Si un utilisateur voulait une fonctionnalité particulière, je voulais avoir mon mot à dire sur le design — mais je ne savais pas où ni quand ces décisions se prenaient et je me sentais exclue.

Le design couvre une gamme assez large de compétences : l’illustration, la typographie, la conception des interactions, la conception visuelle, la conception d’icônes, la conception graphique, la rédaction, etc. et il y a peu de chances qu’un seul concepteur les possède toutes. Il est alors compréhensible qu’un développeur ne soit pas sûr de ce qu’il peut vous demander. Ce n’est pas qu’ils essaient de vous faire obstacle — c’est seulement qu’ils ne savent pas dans quelle mesure vous avez besoin de vous investir ou le désirez.

Aidez-les à vous aider. Montrez-leur clairement le type de contributions que vous pouvez apporter en fournissant des exemples de contributions antérieures. Faites-leur comprendre vos besoins de sorte qu’ils comprennent mieux comment vous aider à vous engager dans leur projet. Par exemple, lorsque vous vous impliquez pour la première fois dans une initiative spécifique pour le projet, prenez le temps de présenter les grandes lignes de son processus de conception et postez cela dans la liste de développement principale afin que les autres contributeurs puissent vous accompagner. Si vous avez besoin d’idées sur des points particuliers, soulignez-les dans votre présentation. Si vous n’êtes pas certain de la façon dont certaines choses se produisent — comme le processus de développement d’une nouvelle fonctionnalité — entrez en contact avec quelqu’un en parallèle et demandez-lui de vous l’expliquer pas à pas. Si quelqu’un vous demande de faire quelque chose au-delà de vos capacités techniques — travailler sur de la gestion de versions, par exemple — et que vous n’êtes pas à l’aise avec ça, dites-le.

Communiquer sur votre processus et vos besoins vous évitera de jouer aux devinettes dans le projet et ses membres seront au contraire capables d’utiliser au mieux vos talents.

3. Posez des questions, beaucoup de questions ; il n’y a pas de question idiote

Nous avons parfois remarqué chez Fedora que, lorsque de nouveaux designers arrivaient à bord, ils avaient peur de poser des questions techniques, par crainte de paraître stupides.

Ce qu’on ne vous dit pas, c’est que les développeurs peuvent être tellement spécialisés qu’il y a beaucoup de détails techniques qui sortent de leur domaine de compétence et qu’ils ne comprennent pas non plus — cela se produit même au sein du même projet. La différence, c’est qu’ils n’ont pas peur de demander — donc vous ne devriez pas avoir peur non plus ! Dans mon travail de design des interactions, par exemple, j’ai dû contacter de nombreuses personnes du même projet pour comprendre comment un processus se déroulait dans leur logiciel, car ce dernier comportait plusieurs sous-systèmes et tous les participants du projet ne comprenaient pas forcément comment chaque sous-système fonctionnait.

Si vous ne savez pas sur quoi travailler, que vous ne savez pas par quoi commencer ou que vous ne comprenez pas pourquoi ce que quelqu’un a dit sur le chat est si drôle — demandez. Vous avez des chances que quelqu’un vous réponde qu’il ne sait pas non plus et peu de risques de passer pour stupide. Dans la plupart des cas, vous allez apprendre quelque chose de nouveau qui vous aidera à devenir un meilleur contributeur. Il peut être particulièrement efficace de chercher un tuteur — certains projets ont même un programme de tutorat — et de lui demander s’il veut bien être votre référent quand vous avez des questions.

4. Partagez et partagez souvent, même si ce n’est pas encore prêt, surtout si ce n’est pas encore prêt

Nous avons aussi remarqué que de nouveaux designers pour Fedora et d’autres projets libres et open source sont un peu timides lorsqu’il est question de montrer leur travail. Je comprends qu’on ne veuille pas ruiner sa réputation en publiant quelque chose qui n’est pas ce qu’on peut faire de mieux ni même fini ; mais une grande partie du travail sur des projets libres et open source est de partager souvent et ouvertement.

Plus vous aurez avancé sur un élément avant de le partager, plus il sera difficile à d’autres de vous apporter un retour utilisable, de se lancer et de s’investir. Il est aussi plus difficile pour autrui de collaborer à votre travail et d’avoir un sentiment d’appartenance au projet, de le soutenir et de le pousser jusqu’à l’implémentation. Dans certains projets libres et open source, ne pas être communicatif avec vos ébauches, compositions et idées est même considéré comme offensant !

Publiez vos idées, maquettes ou compositions sur le Web plutôt que par courriel, afin qu’il soit plus aisé pour les autres collaborateurs de faire référence à votre contribution en faisant un copier-coller de l’URL — c’est particulièrement pratique au cours d’une discussion. Plus vos éléments de design seront faciles à trouver, plus il est probable qu’ils seront utilisés.

Essayez ce conseil et gardez l’esprit ouvert. Partagez votre travail tôt et souvent. Rendez disponibles vos fichiers sources. Vous serez peut-être agréablement surpris par ce qui va se passer !

5. Soyez aussi visible que possible au sein de la communauté du projet

Un outil qui — de manière totalement involontaire — a fini par m’aider énormément à démarrer en tant que contributeur de logiciels libres et open source a été mon blog. J’avais commencé à entretenir un blog, simplement pour moi, à l’image d’un portfolio grossier des choses sur lesquelles j’avais travaillé par le passé. Mon blog est un énorme atout pour moi, parce que :

En tant qu’enregistrement de l’historique des décisions de projet, il représente un moyen pratique pour rechercher d’anciennes décisions de design — comprendre pourquoi nous avons décidé de laisser tomber tel ou tel visuel à nouveau ou pourquoi une approche particulière, précédemment essayée, n’a pas fonctionné, par exemple ;

En tant que dispositif de communication, il aide les autres contributeurs associés à votre projet et même les utilisateurs à être au courant des travaux en cours et des changements à venir pour le projet. De nombreuses fois, j’ai omis quelque chose d’essentiel dans un design et ces personnes ont très rapidement posté un commentaire pour m’en informer !

Il m’a aidé à construire ma réputation en tant que designer de logiciels libres et open source, ce qui m’a aidé à gagner la confiance des autres envers mes choix de design avec le temps.

Vous bloguez ? Trouvez quels agrégateurs de blogs lisent les membres du projet auquel vous participez et demandez à ce que votre blog y soit ajouté (il y a en général un lien pour cela dans la barre latérale). Par exemple, l’agrégateur de blogs que vous devrez rejoindre pour faire partie de la communauté Fedora se nomme Planet Fedora. Écrivez un premier billet pour vous présenter aux autres et leur faire savoir ce que vous aimez une fois que vous y aurez été ajouté — des informations du genre de celles listées dans la première astuce.

Le projet aura certainement une liste de diffusion ou un forum où les discussions ont lieu. Rejoignez-les et présentez-vous là aussi. Quand vous apportez une contribution au projet — peu importe qu’elle soit petite ou loin d’être aboutie — postez des billets sur ce que vous faites, téléchargez-le vers le wiki du projet, tweetez à ce sujet et envoyez des liens aux membres importants de la communauté via IRC afin d’avoir leur retour.

Rendez votre travail visible et les gens commenceront à vous associer à votre travail et à vous proposer des projets sympas ou d’autres opportunités, simplement grâce à ça. C’est tout ce que j’aurais aimé savoir quand j’ai essayé de m’investir pour la première fois dans le logiciel libre et open source comme designer. Si vous ne deviez retenir qu’un message de tout cela, c’est que vous ne devriez pas être timide — faites-vous entendre haut et fort, faites connaître vos besoins, faites savoir aux autres quels sont vos capacités et ils vous aideront à les utiliser pour que le logiciel libre envoie du lourd.

Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framalang : peupleLà, lerouge, goofy, alpha, Sky, Julius22, vvision, okram, lamessen

Les transformations qui préservent la structure

Le deuxième tome de The Nature of Order décrit comment chacune de ces propriétés définit également une transformation. En voici des exemples.

• Des frontières solides. Vous pouvez parfois transformer quelque chose positivement en lui adjoignant une frontière. Vous installez une palissade autour d’un jardin qui sert alors d’ornement, de coupe-vent afin que des vents forts ne viennent pas endommager le jardin, mais elle existe aussi comme structure en soi. Dans une interface graphique utilisateur, des boîtes à ascenseurs sans cadre sont difficiles à distinguer de l’arrière-plan de la fenêtre (pensez à toutes ces pages web blanches dont les formulaires d’entrée de texte n’ont pas de cadre). Vous placez une corniche sur le toit d’un immeuble afin que la transition entre l’immeuble et le ciel ne soit pas abrupte.
• Des symétries locales. Il est plus facile de construire de petites parties de manière symétrique : parce qu’elles sont fabriquées sur un tour, parce qu’on doit y accéder des deux côtés, parce qu’elles se plient comme un livre. Faire des choses asymétriques, seulement pour l’intérêt de la chose, demande un travail supplémentaire et il est plus difficile d’obtenir quelque chose qui fonctionne bien.
• Un espace positif. Vous vous sentez trop exposé quand vous êtes au bureau ? Ajoutez une étagère à mi-hauteur à côté de vous pour délimiter votre espace mais ne vous enfermez pas complètement. Est-ce que votre interface utilisateur donne l’impression qu’il y a beaucoup d’espace restant une fois que vous avez mis les contrôles en place ? Faites plutôt en sorte que les contrôles entourent l’espace utilisable.

Chacun des points qui précèdent est une transformation qui préserve la structure. Vous effectuez un changement dans la structure existante non pas en la démolissant et en la refaisant, mais en ajustant une chose après l’autre selon ces propriétés comme transformations.

En termes de logiciel, il s’avère que c’est ce en quoi le « Refactoring » consiste surtout, quand vous traduisez les concepts en code. Réorganiser, c’est seulement appliquer des transformations qui préservent la structure ou, comme Martin Fowler — l’auteur de Refactoring — l’aurait présenté, des transformations qui préservent le comportement. Vous ne changez pas ce que fait le programme ; vous changez seulement la manière dont il est construit à l’intérieur, morceau par morceau.

En extrayant un morceau de code et en l’insérant dans une fonction nommée, vous ajoutez essentiellement une frontière solide autour du code et créez un noyau robuste. En enlevant une variable globale et en ajoutant des variables de classe, vous permettez la robustesse, car chaque instance peut maintenant avoir une valeur différente dans cette variable, comme nécessaire. En ayant un producteur/consommateur, ou un émetteur/récepteur, vous avez des symétries locales, des imbrications fortes et ambiguës, et une bonne forme.

Richard Gabriel, l’une des principales personnalités du Common Lisp , a étudié comment appliquer les théories d’Alexander au logiciel (et aussi à la poésie ; le code n’est-il pas similaire à la poésie après tout ?). Il donne l’exemple suivant :

1. Imaginez que vous créez la classe AppelTelephonique. C’est un objet central implicite, qui pourrait être beaucoup plus puissant.



2. Gerard Meszaros dans le modèle DemiObjet + Protocole suggérait de séparer l’objet en deux demi-appels, liés par un protocole. On obtient ainsi une symétrie locale, un centre fort et un effet d’échelle.
3. Maintenant, dessinons cela sous forme de diagramme. On obtient alors de la symétrie locale, de l’effet

   

   

   d’échelle, des frontières, une imbrication forte et de l’ambiguïté. C’est ici que Meszaros a arrêté sa démarche.
4. Richard Gabriel suggère alors de renforcer les centres existants en appliquant d’autres transformations qui préservent la structure. Que faire de l’objet central implicite au milieu ? Vous lui ajoutez une frontière explicite (Appel) qui lie les demiAppels entre eux. Cela améliore les symétries locales, maintient l’imbrication forte et l’ambiguïté, et c’est composable.
   

   

5. Oui, c’est composable. Des appels multidirectionnels, des conférences téléphoniques, tout cela s’effectue 

   

   grâce à la mise en œuvre de transformations qui préservent la structure.

Chaque développeur garde probablement une image mentale du programme qu’il est en train de créer ou de modifier. La partie la plus difficile dans la modification d’un code que vous n’avez pas écrit est de commencer par visualiser cette image mentale. Quand vous travaillez pour que le code affiche une image plus jolie, il s’améliore — et Alexander nous propose une bonne façon de le faire.

Le processus fondamental

Alexander argumente longuement pour expliquer l’intérêt de suivre ce processus : appliquer des transformations qui préservent la structure est la seule manière de réussir une conception de qualité et fonctionnelle. Cela ne vaut pas seulement pour les immeubles, mais pour tout ce que nous construisons. Peu importe que vous partiez de l’existant — un programme, un bâtiment ou une ville — ou que vous partiez de zéro. Nous imitons la nature dans ses processus d’évolution et de régénération, mais nous allons plus vite.

1. Commencez avec ce que vous avez : un espace vide, un immeuble déjà construit ou bien un programme qui ne ressemble à rien et difficile à utiliser.
2. Identifiez les centres existant dans cet espace. Trouvez le centre le plus faible ou le moins cohérent.
3. Voyez comment appliquer l’une au moins des quinze transformations qui préservent la structure afin de renforcer ce centre faible. A-t-il besoin d’être délimité ? A-t-il besoin de se confondre avec son entourage ? A-t-il besoin de plus de détails ? A-t-il besoin d’être dégagé ?
4. Trouvez les nouveaux centres qui sont apparus quand vous avez appliqué les transformations à l’ancien centre. Cette nouvelle combinaison rend-elle les choses plus fortes ? Les rend-elle plus jolies ? Les rend-elle plus fonctionnelles ?
5. Assurez-vous que vous avez fait la chose la plus simple possible.
6. Retournez au début pour l’étape suivante.

Un résumé extrêmement simple pourrait être : trouvez les mauvaises parties, améliorez-les de la façon la plus simple possible, testez les résultats, réitérez.

Alexander ne tient pas à détruire les choses juste pour les reconstruire de façon différente. Il ne s’agit pas de pas démolir des quartiers d’une ville pour les reconstruire mais de les améliorer progressivement. Pour les logiciels, il est bien connu que vous n’allez pas réécrire quelque chose juste parce que vous ne le comprenez plus. Démolir quelque chose, c’est perdre toutes les connaissances qui avaient été incorporées à cette chose en train d’être détruite, même si elle semble étrange dans son état actuel.

De même, Alexander s’oppose à la création de modèles détaillés au préalable. Il donne un bon argument montrant pourquoi les modèles pré-établis ne peuvent pas fonctionner en fin de compte : parce qu’on ne peut pas prévoir de manière absolue tout ce qui va se passer lors de la construction et de l’implémentation ; parce qu’on oubliera forcément une partie des détails de l’environnement au sein duquel notre création évoluera ; parce que la nature en elle-même n’est pas pré-ordonnée et croît plutôt de manière libre et pousse sans pitié à l’évolution jusqu’à ce que les éléments qui la constituent survivent d’eux-mêmes.

De cette façon, vous ne concevez pas l’interface utilisateur en entier ou la structure complète, pour un grand programme, en une seule étape. Vous allez du grand au petit ou du petit au grand (niveaux d’échelle) ; vous testez chaque partie individuellement jusqu’à ce que ce soit bon (des centres solides) ; vous vous assurez que les parties ne sont pas trop déconnectées les unes des autres (interdépendance). Vous déplacez quelques widgets là où ils sont plus accessibles ou plus proches des données auxquelles ils se réfèrent. Vous enlevez quelques cadres et séparateurs pour réduire le désordre. Par dessus tout, vous évaluez continuellement ce que vous avez créé avec de vrais utilisateurs et des cas d’usage réels pour confronter les choses à la réalité, et non à votre imagination.

Un nom pour la qualité

Tout au long de The Nature of Order, Alexander parvient à montrer que les environnements ou les structures construites selon cette méthode finissent toutes par avoir la Qualité sans Nom. Il appelle cela une structure vivante. Cela peut être mesuré et comparé. Ce n’est plus sans nom ; on peut parler d’environnements ou de programmes qui ont une structure plus ou moins vivante par rapport à d’autres — et nous tendons à développer et à obtenir toujours plus de cette propriété.

Je ne peux prétendre connaître la façon parfaite de concevoir et écrire des logiciels. Mais au moins, j’ai une bonne méthode basée sur ce qui produit de bonnes choses ailleurs. Cela a fonctionné pour ma maison et, jusqu’à présent, ça a très bien marché pour mes logiciels. J’espère que ça fonctionnera bien pour vous aussi !

Références

• Christopher Alexander, A Pattern Language. Version en ligne : http://bit.ly/8n6igg (NdÉ : lien invalide, le 1er février 2013).
• Christopher Alexander, The Nature of Order. Une page web très moche http://www.natureoforder.com (NdÉ : visité le 1er février 2013).
• Photos et dessins des 15 propriétés - http://bit.ly/b82Dxu (NdÉ : visité le 1er février 2013).
• Richard Gabriel, Patterns of Software. Un superbe libre qui traite d’un grand nombre d’aspects du développement des logiciels, en transposant les idées de Christopher Alexander pour atteindre les meilleures techniques possibles en développement de logiciel. Version en ligne : http://bit.ly/dqGUp4 (NdÉ : visité le 1er février 2013).
• Richard Gabriel, Christopher Alexander, the search for beauty. Une excellente présentation des idées de Christopher Alexander et une galerie de modèles dans le domaine du logiciel. http://bit.ly/ztE6cp (NdÉ : visité le 1er février 2013).
• Richard Gabriel, The Nature of Order. Le monde post-modèles. Une autre très bonne présentation, qui fait suite à la précédente, explique les 15 propriétés, le processus fondamental et comment cela peut s’appliquer au logiciel. http://dreamsongs.com/Files/NatureOfOrder.pdf (NdÉ : visité le 1er février 2013).
• Federico Mena Quintero, Software that has the Quality Without A Name. Présentation Desktop Summit de Berlin en 2011. http://bit.ly/oYgJUf (NdÉ : visité le 1er février 2013).

Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framalang : Sphinx, peupleLà, lerouge, goofy, alpha, Sky, Julius22, lamessen, vvision, Garburst, okram

Le guichet de billetterie

La thèse de doctorat d’Alexander a servi de base à son livre Notes on the Synthesis of Form (NdT : Remarques sur la synthèse de la forme), paru en 1964. Il essayait de rationaliser le processus de conception en le définissant comme une progression depuis une série de conditions préalables jusqu’à un résultat final, grâce à une analyse des forces qui déterminent le design.

Permettez-moi citer Richard Gabriel, dont je parlerai plus tard, quand il décrit l’époque où Alexander essayait de concevoir un guichet de billetterie en prenant appui sur ses idées mathématiques :

Alexander dit (à propos de la qualité sans nom) :

Il s’agit d’un type subtil de liberté issu de contradictions internes. (Alexander, 1979)

Cette assertion fait écho aux origines de sa recherche sur la qualité. Elle commença en 1964 alors qu’il était en train de réaliser une étude pour le San Francisco Bay Area Rapid Transit District (BART) basée sur le travail rapporté dans Notes on the Synthesis of Form (Alexander 1964), lui-même basé sur sa thèse de doctorat. L’une des idées-clés de ce livre était qu’avec une bonne conception, il doit y avoir une relation sous-jacente entre la structure du problème et la structure de la solution — les bonnes conceptions passent par la rédaction d’une analyse des besoins, l’analyse de leurs interactions sur les bases d’incompatibilités potentielles, produisant ainsi une décomposition hiérarchisée des différentes parties, et la reconstitution d’une structure dont

la hiérarchie structurelle est l’exact complémentaire de la hiérarchie fonctionnelle établie durant l’analyse du programme. (Alexander, 1964)

Alexander a analysé le système de forces mises en jeu dans la conception d’un guichet. Lui et son groupe avaient rédigé un cahier des charges en 390 points pour couvrir tous les cas de figure d’usage de l’édicule. Certaines spécifications concernaient des choses telles qu’être là pour obtenir des billets, pouvoir faire de la monnaie, pouvoir déplacer les personnes qui font la queue, réduire la durée d’attente pour obtenir des billets. Il a toutefois remarqué que certaines parties du système n’étaient pas concernées par ces spécifications et que le système lui-même pouvait s’enliser parce que ces autres forces — celles qui ne faisaient pas l’objet d’une spécification — agissaient pour arriver à leur propre équilibre au sein du système. Par exemple, si une personne s’arrêtait et qu’une autre s’arrêtait également pour parler avec la première, cela pouvait créer un embouteillage susceptible de mettre en échec les mécanismes mis au point pour maintenir une circulation fluide. Bien sûr, l’absence d’embouteillage faisait partie des spécification. Mais il n’y avait rien que les concepteurs puissent faire pour l’empêcher par le biais d’un mécanisme adapté.

En tant que programmeur, ça doit vous rappeler quelque chose ? Vous pouvez élaborer une conception magnifique et parfaitement rigoureuse, mais qui s’effondrera quand vous la construirez effectivement parce que des éléments que vous n’aviez pas anticipés apparaitront alors. Ce n’est pas un échec de votre conception, mais de quelque chose d’autre ! Richard Gabriel poursuit :

Alexander disait ceci :

Il devint alors clair que le bon fonctionnement d’un système ne dépendait pas uniquement de la satisfaction d’une série de conditions préalables. il s’agissait plutôt d’un système qui trouve sa cohérence en lui-même et en équilibre avec les forces internes générées par ledit système que de l’accord avec une série quelconque de conditions préalables que nous aurions arbitrairement définie. Cela m’intriguait beaucoup car l’idée qui prévalait en général à l’époque (en 1964) était que, pour l’essentiel, tout était fondé sur des objectifs. Toute mon analyse des conditions préalables tendait à converger avec le point de vue de la recherche opérationnelle qui pose qu’il faut établir des objectifs, etc. Ce qui m’ennuyait, c’est qu’une analyse correcte du guichet ne pouvait se baser uniquement sur des objectifs quelconques ; il y avait des réalités qui émergeaient du centre du système lui-même et qui, peu importe votre degré de réussite, avaient un rapport avec le fait que vous ayez créé une configuration stable au regard de ces réalités.

Et c’est le cœur du problème : comment créer une configuration stable avec les réalités qui en émergent au fur et à mesure que vous la construisez ?

La nature de l’ordre

Bien que Christopher Alexander ait eu conscience d’avoir produit quelque chose de précieux avec ses recherches et catalogues de modèles, il n’était pas complètement satisfait. D’où venaient les modèles ? Pouvait-on les créer à partir de rien ou devait-on se satisfaire de ce qu’avait produit jusque là l’architecture traditionnelle ? D’ailleurs, les modèles étaient-ils réellement nécessaires ? Comment pouvait-on mieux définir et évaluer ou mesurer cette « Qualité sans nom » ?

Alexander passa les vingt années suivantes à tenter de répondre à ces questions. En étudiant le processus réel de création par lequel des environnements bien construits avaient vu le jour, il découvrit que certains processus sont indispensables pour créer des villes ou des édifices agréables — ou toute création humaine en fait. Il arriva aux conclusions suivantes :

• La nature crée des choses qui ont toutes une quinzaine de propriétés en commun (je vous expliquerai plus tard). Cela se produit uniquement par des processus naturels — physique et chimie de base — bien que nous ne sachions pas clairement pourquoi des procédés très différents produisent des résultats similaires ;

• On retrouve ces propriétés dans les architectures traditionnelles ou les villes qui ont simplement évolué au cours du temps. Tous les modèles décrits dans A Pattern Language peuvent être obtenus en suivant une méthode fondée sur ces propriétés ;

• Chaque propriété peut également décrire une transformation de l’espace existant ;

• La seule façon de réussir une bonne conception consiste à utiliser ces transformations, une à la fois.

Ceci a été publié en 2003 - 2004 en quatre tomes intitulés The Nature of Order (NdT : « La nature de l’ordre »).

Les quinze propriétés

Le premier tome de La nature de l’ordre traite de quinze propriétés qui apparaissent dans tous les systèmes naturels. Je les résumerai très brièvement (voir les références pour des illustrations et de plus amples explications).

• Des niveaux d’échelle : La gamme de tailles est équilibrée, sans changement brutal dans la taille d’objets adjacents. Les éléments ont une échelle fractale ;
• Des centres forts : Les différentes parties de l’espace ou de la structure sont clairement identifiables ;
• Des frontières solides : les lignes délimitent les choses. Dans les systèmes vivants, les bords sont les environnements les plus productifs (par exemple, toutes les créatures qui vivent au bord de l’eau) ;
• Des répétitions alternées : haut/bas, épais/fin, forme A et forme B. Les objets oscillent et alternent afin de créer un bon équilibre ;
• Un espace positif : l’espace adopte une belle forme convexe et close. Ce n’est pas de l’espace excédentaire. Pensez à la manière dont les cellules d’un diagramme de Voronoï grandissent vers l’extérieur à partir d’un ensemble de points ou à la manière dont les grains d’un épi de maïs se développent à partir de petits points jusqu’à ce qu’ils touchent les grains adjacents ;
• Une bonne forme : les voiles d’un bateau, la coquille d’un escargot, le bec d’un oiseau. Ils parviennent à la forme optimale qui sert leur fonction, ce qui est magnifique ;
• Des symétries locales : le monde n’est pas symétrique dans son ensemble. Cependant, les petites choses tendent à être symétriques parce que, de cette manière, c’est plus facile. Votre maison n’est pas symétrique, mais chaque fenêtre l’est ;
• Une profonde imbrication et de l’ambiguïté : les rues sinueuses des vieilles villes. Les axones des neurones. Il est difficile de séparer la forme du fond, ou l’avant-plan de l’arrière-plan. Deux centres forts sont renforcés si un troisième est placé entre eux de manière à ce qu’il appartienne aux deux ;
• Du contraste : vous pouvez distinguer où une chose se termine et où la suivante commence parce qu’elles ne se fondent pas l’une dans l’autre ;
• Des degrés : les choses se confondent les unes les autres là où c’est nécessaire. Les concentrations dans des solutions, les congères ou les talus, les câbles supportant un pont. La manière dont la bande passante décroît alors que vous vous éloignez de l’antenne ;
• Des aspérités : le monde n’est ni exempt de frottement, ni doux. Les irrégularités sont bénéfiques car elles permettent à chaque élément de s’adapter à son environnement, plutôt que d’être une copie conforme qui n’irait pas aussi bien ;
• Des échos : les choses se répètent et se font écho. Elles sont uniques dans la précision de leur forme mais leurs contours généraux se répètent à l’infini ;
• Du vide : parfois, vous avez un grand espace vide pour la tranquillité de la forme. Un lac, une cour, le cadre d’une image ;
• De la simplicité et du calme intrinsèque : les choses sont aussi simples que possible, sans être simplistes ;
• De l’interdépendance : chaque chose est dépendante de tout le reste. On ne peut pas séparer un poisson du bassin et des plantes aquatiques. On ne peut pas séparer une colonne de la base du bâtiments.;

Le célèbre (et libre) langage de programmation Python est en danger en Europe pour une sombre histoire de droit des marques.

Nous avons traduit ci-dessous l’appel à soutien de Van Lindberg, président de la Python Software Foundation.

La marque Python en péril en Europe : Nous avons besoin de votre aide !

Python trademark at risk in Europe: We need your help!

Van Lindberg - 14 février 2013 - Python Software Foundation
(Traduction : Moosh, lgodard, Alpha, QuébecTroll, jtanguy, Penguin, Uflex, ProgVal, goofy, maz, Nodel, Norore + anonymes)

Vous qui travaillez dans une entreprise qui a un bureau dans un pays membre de l’Union Européenne, nous avons besoin de votre aide.

Une entreprise au Royaume-Uni essaye de faire reconnaître le terme « Python » comme marque commerciale pour tout logiciel, service ou serveur, à peu près tout ce qui a quelque chose à voir avec un ordinateur. Plus précisément, c’est l’entreprise qui a acquis le domaine python.co.uk il y a treize ans. À cette époque, nous nous souciions peu des problèmes de marque et nous n’avions pas acquis ce domaine.

Ce n’était pas un problème jusqu’à présent car le domaine python.co.uk, la plupart du temps, se contentait de transférer son trafic vers les sociétés-mères, veber.co.uk et pobox.co.uk. Malheureusement, Veber a décidé qu’ils voulaient commencer à utiliser le nom « Python » pour leurs logiciels serveurs.

Nous avons contacté les propriétaires de python.co.uk à plusieurs reprises et essayé d’en discuter avec eux. Leur seule réponse a été de déposer une demande de marque communautaire réclamant les droits exclusifs d’utiliser le terme « Python » pour des logiciels, serveurs, et services web – et ce partout en Europe.

Nous avons fait appel à un conseiller juridique au Royaume Uni et nous, la Python Software Foundation (NdT :. la Fondation Python), opposons à cette demande une demande de dépôt de marque communautaire, mais notre propre demande n’est pas suffisamment mûre. Dans cette dernière, nous exposons les droits de propriété de la marque résultants de l’utilisation de “Python” au cours de ces 20 dernières années.

D’après notre avocat londonien, les meilleures preuves que nous puissions transmettre au bureau européen des marques déposées sont les lettres d’entreprises connues « utilisant le logiciel de marque PYTHON dans divers pays de l’Union Européenne » de telle sorte que nous puissions « obtenir des témoignages indépendants de leur part, prouvant l’origine de la signification de la marque PYTHON, en relation avec le logiciel et les produits/services associés ». Nous avons aussi besoin de preuves d’utilisation de Python à travers toute l’Union Européenne.

Que pouvez-vous faire ?

1- Vous travaillez pour une entreprise qui utilise Python ? Vous êtes basés en Europe, vous y embauchez ou vous y possédez un bureau ? Pourriez-vous écrire une lettre avec l’en-tête de votre entreprise que nous pourrions réutiliser par la suite ?

Nous aurions besoin des élements suivants :

1. Une brève description de l’utilisation de Python dans votre entreprise :
2. Comment votre entreprise associe le terme Python uniquement à la PSF ;
3. Votre opinion sur le fait qu’une autre entreprise utilisant le terme Python dans ses services, logiciels et serveurs pourrait âtre source de confusion.

La lettre n’a pas besoin d’être très longue —- quelques paragraphes suffisent, mais nous apprécierions toute forme de description de votre utilisation de Python dans vos logiciels, votre hébergement internet, vos serveurs, vos VPN, dans le développement de logiciel ou de matériel ou encore dans l’utilisation de services de sauvegarde. Pour ceux qui sont intéressés par les classes descriptives légales, elles figurent au bas de ce message^[1][2].

Vous pouvez envoyer une copie PDF de votre lettre à psf-trademarks@python.org

2. Connaissez-vous ou possédez-vous quoi que ce soit qui ait été publié au sein de l’UE et qui utilise “Python” pour faire référence au langage Python? Pouvez-vous nous transmettre des numérisations, photos ou copies? Cela comprend :

• Des livres ;
• Des brochures ;
• Des programmes de conférences ou présentations ;
• Des offres d’emploi ;
• Des magazines ou autres publications ;
• Des prospectus.

Vous pouvez envoyer un scan PDF de ces documents à psf-trademarks@python.org.

3. Vous pouvez également aider à protéger la propriété intellectuelle de Python en nous soutenant financièrement.

Comme le coût d’opposition d’une marque commerciale est de l’ordre de dizaines de milliers de dollars, nous aurons besoin de trouver un moyen de financer les coûts de procédure de l’opposition.

Merci d’envisager une donation à la Python Software Foundation ou de me contacter.

C’est la première fois que la PSF doit prendre des mesures juridiques pour protéger la propriété intellectuelle de Python. S’il vous plait, aidez Python comme vous le pouvez. La menace est réelle et elle est susceptible de nuire à votre entreprise en Europe, surtout si vous êtes dans le domaine de l’hébergement et que Python fait partie de l’offre que vous proposez.

S’il vous plaît, faites-moi savoir si vous avez des questions auxquelles je peux répondre. Si vous connaissez quelqu’un qui devrait avoir l’information, libre à vous de la partager.

Thanks, Merci,

Van Lindberg, Président
van@python.org
Python Software Foundation

« Googlelisez-moi, Googlelisez-moi. Oui, mais pas tout de suite, pas trop vite. Sachez me convoiter, me désirer, me captiver. » (Juliette Gréco)

Sources :

• L’accord Google-presse ou l’arnaque intellectuelle du Gouvernement (Numerama)
• Aurélie Filippetti rappelle à Google ses obligations fiscales (Numerama)
• Qwant : un concurrent de Google « made in France » (Numerama)

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

Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framalang : Sphinx, peupleLà, lerouge, goofy, alpha, Julius22, SaSha_01, vvision, lamessen, Bob, lamessen, Garburst, okram

Le logiciel comme Qualité sans Nom

Federico Mena Quintero

Federico Mena Quintero est l’un des pères fondateurs du projet GNOME et fut auparavant le mainteneur de GIMP. Il travaillait aux Red Hat Advanced Development Labs durant les débuts de GNOME puis fut l’un des premiers à être recruté chez Ximian où il a principalement travaillé sur le calendrier d’Evolution. Il travaille toujours autour de GNOME pour Novell/Suse et vit au Mexique.

Lorsque j’apprenais la programmation, j’ai remarqué que je rencontrais souvent le même problème, encore et encore. J’écrivais souvent un programme qui fonctionnait relativement bien et était même bien structuré. Mais après quelques modifications et améliorations, je ne pouvais plus l’améliorer davantage. Soit sa complexité me surpassait, soit il était écrit de telle manière qu’il ne permettait pas d’évolution, comme une maison que vous ne pouvez pas agrandir à cause d’un toit pentu ou que vous ne pouvez pas étendre sur les côtés à cause des murs qui l’entourent.

À mesure que je progressais, j’ai appris à gérer cette complexité. Nous apprenons tous à le faire avec différents outils et techniques : l’abstraction, l’encapsulation, l’orientation objet, les techniques fonctionnelles, etc. Nous apprenons comment diverses techniques nous permettent d’écrire des programmes plus complexes.

Cependant, le problème d’un programme trop optimisé ou bien trop intimement enchevêtré pour être modifié a persisté. Parfois, je pensais tenir une superbe conception. Mais la modifier d’une façon quelconque l’aurait « amochée » et je ne le souhaitais pas. D’autres fois, j’avais quelque chose avec tellement de parties imbriquées que je ne pouvais plus y connecter quoi que ce soit sans que tout s’effondre sous son propre poids.

Il y a quelques années, la manie de la réécriture a débuté sans que j’y prête trop attention. Je me disais que c’était une façon de nettoyer le code, mais après ? Je sais déjà comment prendre un morceau de code et le transformer en fonction ; je sais déjà comment prendre des morceaux de code similaires et les transformer en classes dérivées. Je sais déjà écrire du code presque entièrement propre. Quel est donc le problème ?

J’ai écarté la refactorisation(1) en la considérant comme destinée aux programmeurs les moins expérimentés ; comme de jolies recettes de nettoyage de code mais rien qui ne puisse être découvert par soi-même.

La même chose s’est produite avec les canevas de conception. Je pensais qu’ils donnaient simplement des noms pompeux tels que Singleton et Strategy à des types de structures de tous les jours qu’on utiliserait naturellement dans un programme. Peut-être mon ego de programmeur était-il trop démesuré pour considérer ces travaux avec sérieux. C’est alors que quelque chose s’est produit.

Le travail de Christopher Alexander

Il y a quelques années, mon épouse et moi avons acheté une petite maison de plain-pied et nous souhaitions l’agrandir. Nous envisagions avoir un enfant et avions, par conséquent, besoin de plus d’espace. J’avais besoin d’un vrai bureau à domicile, pas une simple niche inoccupée dans laquelle mon bureau et mes étagères de livres tiendraient à peine. En tant que cuisiniers avides, nous avions tous les deux besoin d’une cuisine plus spacieuse et confortable que celle de notre maison. Mon épouse avait besoin d’une pièce bien à elle.

Nous ne voulions pas payer pour un architecte coûteux et aucun de nous deux n’avait la moindre connaissance en matière de construction. Comment allions-nous concevoir notre maison ?

Par moments, en naviguant sur le Web, je me rappelais que j’avais déjà vu le nom d’un auteur, le titre d’un livre ou quelque chose comme ça. Il se peut que je n’y aie pas vraiment porté attention par le passé mais, d’une manière ou d’une autre, plus je vois la même chose mentionnée, plus il est probable que je finirai par m’y intéresser suffisamment pour aller voir de quoi il s’agissait. « Oh, plusieurs personnes ont déjà mentionné ce nom ou ce livre ; je devrais peut-être y jeter un coup d’œil  »

C’est exactement ce qui s’est passé avec le nom de Christopher Alexander. J’avais lu que c’était un architecte assez spécial (de vrais bâtiments, pas de logiciels), connecté en quelque sorte au monde du logiciel par le biais de techniques orientées objet. J’ai été passionné par son travail dès que j’ai commencé à le découvrir par mes lectures.

Dans les années 1970, Christopher Alexander était un mathématicien et professeur d’architecture à l’université de Californie, Berkeley. Lui et un groupe d’architectes de la même mouvance que lui ont parcouru le monde, essayant de comprendre pourquoi il existait des endroits construits par des humains (cités, villes, parcs, immeubles, maisons) où il était très agréable de vivre, confortables, conviviaux et jolis, tandis que dans d’autres endoits ne l’étaient pas. Les endroits agréables était présents dans toutes les architectures traditionnelles du monde — européennes, africaines, asiatiques et américaines — amenant à l’idée que des facteurs communs étaient sans doutes extractables.

Alexander et son équipe ont réparti leurs découvertes au sein d’une liste de motifs architecturaux cohérents et publié trois livres : The Timeless Way of Building (NdT « L’art de la construction intemporelle » en français), où sont décrites la philosophie et la méthode nécessaires à une bonne construction ; A Pattern Language (NdT : « Un langage de schémas » en français), que je décris ci-après et The Oregon Experiment (NdT « L’expérience de L’Oregon » en français) où sont détaillés la conception et la construction d’un campus universitaire grâce à leur méthode.

Un langage de modèles

Un modèle (ou schéma) est un problème récurrent lors de la conception et de la construction d’objets, en lien avec les contraintes qui modèlent le problème et avec une solution connectée, quasi-récursivement à d’autres modèles-pères ou modèles-fils. Par exemple, considérons le GRADIENT D’INTIMITÉ, un modèle important dans le livre (le modèles étant épelés en lettres capitales au sein de ce livre pour en faciliter l’identification, je ferai donc de même) :

GRADIENT d’INTIMITÉ

Énoncé du problème : à moins que les volumes d’un édifice ne soient disposés dans un ordre correspondant à leur degré d’intimité, les visites des étrangers, amis, invités, clients, famille seront toujours un peu gênantes.

Explication : je ne vais pas tout citer. Prenez, par exemple, un appartement où la seule façon d’atteindre la salle de bain est de passer d’abord par la chambre à coucher. Les visites sont toujours gênantes car vous avez l’impression de devoir d’abord ranger votre chambre si vous voulez que vos visiteurs puissent utiliser les toilettes  Ou bien considérez des bureaux dans lesquels vous ne voulez pas qu’un espace de travail calme soit à côté de la réception, car alors celui-ci ne sera pas calme du tout — vous voulez qu’il soit plus privé, à l’arrière.

Résumé de la solution : disposez les espaces de l’édifice de façon à ce qu’ils créent une suite qui commence avec l’entrée et la partie du bâtiment ouverte au public, puis conduit aux zones un peu plus privées pour finir avec les domaines les plus intimes.

Modèles-fils à consulter : ZONES COMMUNES AU CENTRE. HALL D’ENTRÉE pour les maisons ; UNE PIÈCE PROPRE À CHACUN pour les particuliers. UNE RÉCEPTION VOUS SOUHAITE LA BIENVENUE dans les bureaux avec, BUREAU SEMI-PRIVÉ à l’arrière.

Les modèles deviennent plutôt précis, ils n’imposent cependant jamais un style ou une forme déterminée au résultat. Par exemple, il existe un modèle qui s’appelle « ÉTAGÈRES OUVERTES ». Des placards profonds vous incitent à mettre les choses les unes derrière les autres, ainsi, vous ne pouvez plus voir ni attraper les objets qui sont au fond. Ils prennent aussi beaucoup de place. Les étagères dont la profondeur permet de ne mettre qu’un seul objet restent rangées et vous savez toujours, en un seul coup d’œil, où se trouve chaque chose. Les objets que vous utilisez fréquemment ne devraient pas être derrière une porte.

Vous pouvez ainsi entrevoir l’essence même des modèles de conceptions : de bonnes recettes éprouvées qui n’imposent pas de contraintes inutiles à votre implémentation

Les modèles ne demandent pas un style particulier ou des décorations superflues : le livre ne vous dit pas : « appliquez ces motifs floraux sur les rampes », mais plutôt : « les pièces d’une maison devraient être orientées de telle sorte que le soleil les éclaire harmonieusement, au moment de la journée où elles sont le plus utilisées — à l’est pour les chambres le matin, à l’ouest pour le salon l’après-midi ».

J’avais acquis un exemplaire de A Pattern Language peu avant de commencer à agrandir notre maison. Le livre fut une révélation : c’était le moyen d’aborder la conception de notre maison et nous pouvions alors la réaliser par nous-mêmes au lieu de payer très cher une solution inadaptée. Nous étions capables de faire un plan sommaire de notre maison et ensuite d’imaginer des détails plus fins au fur et à mesure de la construction. C’est le genre de livres qui, pendant que vous le lisez, parvient à confirmer les intuitions que vous éprouviez confusément — le genre de livres qui vous fait dire en permanence : « Bien sûr, c’est exactement à ça que je pensais  »

Design Patterns, le fameux livre publié par Gamma et autres, puise directement son inspiration dans les schémas architecturaux d’Alexander. Ils voulaient faire la même chose : dresser une liste de problèmes apparaissant fréquemment lorsque l’on programme et présenter de bonnes solutions qui n’imposeront pas de contraintes inutiles à votre implémentation.

Une chose dont j’ai pris conscience en lisant A Pattern Language, c’est une chose importante que l’on retrouve à la fois dans les modèles architecturaux et logiciels) : ils nous fournissent un vocabulaire pour discuter de la façon dont les objets sont construits. Il est beaucoup plus pratique de dire : « Les propriétés de cet objet ont des observateurs » plutôt que : « il est possible de lui attribuer des fonctions de rappel qui sont appelées lorsque ses propriétés changent ». Ce que je pensais être uniquement des termes pompeux ne sont, en fait, qu’une manière d’exprimer la connaissance de manière compacte.

La Qualité Sans Nom

La plus grande partie de l’explication d’Alexander sur les modèles de conception et leur philosophie se rapporte à quelque chose qu’il appelle « La qualité sans nom ». Vous connaissez des endroits qui ont cette qualité sans nom. Elle est présente dans le café où vous aimez aller lire car la lumière de l’après-midi entre avec exactement la bonne intensité. Et il y a là-bas des chaises et des tables, c’est toujours plus ou moins rempli de gens sans pour autant que vous vous sentiez oppressé. Elle est présente au coin d’un parc où un arbre ombrage un banc. Il y a peut-être un peu d’eau vive, et il importe peu qu’il pleuve ou bien que le temps soit ensoleillé, cela semble toujours être un plaisir d’y être. Pensez à une maison de hobbit où tout est à portée de main, où tout est confortable et où tout est fait élégamment.

Un objet ou un endroit possède la qualité sans nom s’il est convivial, s’il a évolué dans le temps selon sa logique propre, s’il ne recèle pas de contradiction interne, n’essaie pas d’attirer l’attention et semble réunir toutes les qualités archétypales — comme s’il avait suivi tout naturellement la voie optimale pour aboutir à sa conception. Plus important, Alexander affirme que c’est une qualité objective et non subjective, et qu’elle peut être mesurée et comparée. Bien que cela semble être une définition floue, c’est l’état le plus abouti dans lequel Alexander a pu l’amener lors de la première phase de son travail. La vraie révélation n’apparaitrait que plus tard.

En tant que développeurs, nous avons tous vu de beaux programmes à un moment donné. Ce sont peut-être les exemples de Programming Pearls, un beau livre que tout hacker devrait lire. Peut-être avez-vous vu un algorithme bien implémenté qui regorge de justesse. Vous vous souvenez peut-être d’un morceau de code très compact, très lisible, très fonctionnel et très correct. Ce logiciel possède la qualité sans nom. Il était devenu évident pour moi que je devais apprendre à écrire des logiciels qui atteignent le niveau de la qualité sans nom et que la méthode d’Alexander était le bon point de départ pour y parvenir.

(à suivre…)

(1) Refactorisation : bien que critiqué, cet anglicisme (voir http://fr.wikipedia.org/wiki/Refactorisation) semble d’un emploi courant chez les développeurs. On pourrait parler plus simplement de remaniement

Les lobbys ont toujours tenté d’influencer les politiques. Mais lorsqu’il s’agit de lobbyistes américains qui arrivent à faire passer mot pour mot certains textes de loi en Europe avec la complicité de nos députés, il y a d’autant plus de quoi s’interroger que cela va dans le sens des entreprises US et non du citoyen européen.

Un article traduit du chroniqueur anglais Glyn Moody, souvent traduit sur le Framablog)

Heureusement que nous avons désormais des sites qui permettent de mieux connaître le comportement individuel des députés et leurs éventuelles « sources d’inspiration ». Heureusement aussi que nous avons des structures comme la Quadrature du Net qui tente tant bien que mal d’agir et veiller au grain. Mais la vigilance reste de mise.

Protection des données dans l’Union Européenne : Les amendements proposés, écrits par des lobbyistes américains

EU Data Protection: Proposed Amendments Written by US Lobbyists

Glyn Moody - 11 février 2013 - ComputerWorld.uk
(Traduction : Fly, Alpha + anonymes)

Il devient évident que le lobby autour des directives européennes sur la protection des données est l’un des plus intenses lobbys jamais rencontrés, certains activistes ont déclaré que le phénomène était même pire que durant le projet de loi ACTA, alors que du côté des États-Unis, le bruit court qu’une guerre commerciale est sur le point d’être lancée si la loi est voté sous sa forme actuelle.

Etant donné la pression exercée pour affaiblir la protection de notre vie privée, une question-clé est : qui défend nos intérêts ?. La réponse évidente serait les députés européens, puisqu’il s’agit de nos représentants élus au Parlement Européen. Leur travail consiste précisément à nous représenter et dans ces circonstances particulières et à nous défendre. Et certains, tel le député européen Vert, Jan Albrecht, font probablement de leur mieux, comme j’ai pu l’écrire dans un billet précédent. Mais qu’en est-il du reste ? Que font-ils exactement ?

Dans le passé il était impossible de répondre à cette question, mais grâce aux miracles de la technologie moderne, et à l’avènement de l’ouverture des données qui permettent l’accès à toutes sortes d’informations. Il est désormais possible d’obtenir une vision claire de ce que font nos représentants européens.

Un nouveau site a été créé, il porte le nom plutôt lourd de LobbyPlag (NdT : Association des mots lobby et plagiat). Aussi disgracieux, que son nom puisse être, ce site ne décrit pas moins une vérité choquante : les députés européens proposent des amendements sur le projet de loi sur la protection des données qui reprennent mot pour mot les propositions des lobbyistes. En tout état de cause, ce qui est inquiétant ici n’est pas le plagiat, mais plutôt le fait que les mesures destinées à protéger les populations européennes soient supprimées ou altérées par les mêmes personnes que nous avons élues pour nous défendre.

Voici par exemple, un paragraphe important sur le fichage. On peut lire, sur la version originale :

Chaque personne physique (NdT : every natural person) doit avoir le droit de ne pas être soumis à une mesure entraînant des effets juridiques relatifs à cette personne physique particulière ou l’atteignant de manière significative, dès lors qu’elle se base uniquement sur un traitement automatisé ayant pour but l’analyse ou la prédiction de certains aspects personnels en lien avec cette personne physique, en particulier, l’efficacité au travail, la situation financière, la localisation, la santé, les préférences personnelles, la fiabilité, ou le comportement de cette personne physique.

Mais la Chambre de Commerce américaine, cette célèbre organisation européenne, n’aimait pas cette version et a souhaité la changer en :

Une personne concernée par la collecte des données (NdT : a data subject) ne doit pas faire l’objet d’une décision injuste ou discriminatoire uniquement basée sur le traitement automatisé ayant pour but l’évaluation de certains aspects personnels liés à cette personne.

Ce qui est sensiblement différent car on supprime ici un droit important.

Or quel texte a été proposé par des députés européens dans pas moins de trois commissions ? Le voici :

Une personne concernée par la collecte des données ne doit pas faire l’objet d’une décision injuste ou discriminatoire uniquement basée sur le traitement automatisé ayant pour but l’évaluation de certains aspects personnels liés à cette personne.

Ce qui correspond donc mot pour mot à la demande de la Chambre de Commerce américaine.

Voici un exemple explicite, issu d’une section extrêmement récente, rédigée par des députés européens, on peut y lire ce qui suit :

La personne responsable est supposée avoir accompli les obligations en exergue dans le paragraphe 1,lorsqu’il s’agit de choisir un organisme certifié de manière autonome ou ayant obtenu une certification, un sceau ou marqué comme étant conforme aux articles 38 ou 39 de ce Réglement, démontrant l’implémentation de normes techniques et de mesures organisationnelles appropriées en réponse aux exigences mises en exergue dans ce Règlement.

Ce qui rend la certification autonome quasiment suffisante pour les services de cloud computing. Alors, d’où vient ce texte sinon d’une modification précise suggérée par Amazon ?

La personne responsable est supposée avoir accompli les obligations en exergue dans le paragraphe 1,lorsqu’il s’agît de choisir un organisme certifié de manière autonome ou ayant obtenu une certification, un sceau ou marqué, démontrant l’implémentation de normes techniques et de mesures organisationnelles appropriées en réponse aux exigences mises en exergue dans ce Règlement.

Ce qui donc, par une autre extraordinaire coïncidence, est quasiment identique à ce que des députés européens ont choisi comme une très bonne idée.

LobbyPlag fournit une analyse intéressante sur le pourcentage d’amendements proposés avec du contenu repris des lobbyistes. Ci-dessous les chiffres pour les députés anglais calculés par le site :

• Giles Chichester (giles.chichester@europarl.europa.eu): amendements repris des lobbys : 10 sur 44 (22.73%)
• Malcolm Harbour (malcolm.harbour@europarl.europa.eu): amendements repris des lobbys : 14 sur 55 (25.45%)
• Sajjid Karim (sajjad.karim@europarl.europa.eu): amendements repris des lobbys : 13 sur 55 (23.64%)
• Emma McClarkin (emma.mcclarkin@europarl.europa.eu): amendements repris des lobbys : 1 sur 8 (12.50%)

Malheureusement, à l’heure actuelle, aucun de ces députés européens ne me représente donc je ne pourrais pas les contacter. Mais si l’un de vos députés apparaît, ils ont le devoir de vous répondre donc peut-être que vous devriez leur envoyer un courriel et leur demander pourquoi ils ont proposé ces amendements qui sont repris mot-à-mot ou presque d’entreprises américaines et de lobbyistes et que cela nuira à la population européenne tout en bénéficient à ces mêmes entreprises américaines.

Vous pourriez leur demander qui ils pensent représenter réellement : vous et 500 millions citoyens européens dont les impôts paient leurs salaire, qui s’élève actuellement à 80.000 £ par an (NdT : 93 000 € environ) ou alors, une poignée d’entreprises américaines ayant pour but de nous spolier notre vie privée pour pouvoir devenir encore plus riche ?

Si jamais vous recevez un réponse intéressante, merci de me l’envoyer à glyn.moody(AT)gmail.com que je puisse la partager avec mes lecteurs. Je suis certain que les explications seront passionnantes.

Crédit photo : European People’s Party (Creative Commons By)

Nous ne pouvons plus vous le cacher. Nous vous devons la vérité.

Le romancier Pouhiou, de sinistre mémoire, ne laissera aucun droit d’auteur à sa succession ! Ses petits-petits-enfants maudiront cet arrière-arrière-grand-père qui ne leur aura pas laissé son œuvre en lucratif héritage, et ils baisseront la tête, honteux de revenir à pied de l’école virtuelle quand ils croiseront les petits-petits-enfants de Marc Levy en limousine holodynamique…

Pourquoi ? Parce que cet iconoclaste a décidé de directement placer ses livres dans le domaine public grâce à la licence CC-0. Il pousse d’ailleurs l’effronterie jusqu’à nous demander notre soutien pour accompagner la sortie du livre II du cycle des NoéNautes.

Ne répondez surtout pas à sa pernicieuse invitation, vous risqueriez d’être complice de dangereux criminels de la trempe d’Aaron Swartz !

Voyez dans cette interview de quelles fallacieuses diaprures il revêt ses noirs desseins… On vous aura prévenus.

Alors ça y est, tu as déjà fini un deuxième tome ? C’est un vrai roman-feuilleton ton truc, et tu comptes aller jusqu’où au juste ? Une comédie musicale à Bercy ?

Quand comme moi on télécharge chaque année les Tommy awards, c’est Broadway sinon rien ! Pour les NoéNautes, j’ai été clair dès le début : Huit livres sont prévus. Huit livres de huit chapitres, chacun correspondant à un des 64 hexagrammes du yi-king (un des plus vieux livres au monde). Mais je t’avoue qu’après deux romans en un an, je crois que je vais me faire une pause… et écrire les trois pièces de théâtre qui me trottent dans la tête !

C’est bien joli tes histoires de noétie mais moi ce qui m’intéresse c’est qu’il y ait là-dedans un peu de sexe, de drogue et de rock’n roll. Est-ce qu’on en trouve dans MonOrchide(1) ?’

Tu sais que je ne l’avais pas envisagé comme ça ? Mais nom de Zeus, c’est vrai ! Ce sont même des éléments essentiels de #MonOrchide. Le sexe, débridé, pluriel, polyamoureux, va être un levier important dans la narration… comme il peut l’être dans l’histoire de nos vies, note bien ! Quant à la drogue et au Rock’N’Roll, ils apparaissent avec de nouveaux personnages… Donc je garde le secret. Disons que qui a lu mes pièces de théâtre risque d’avoir de belles surprises !

C’est quoi cette histoire de souscription ? J’y comprends rien. Tu veux qu’on envoie des sous pour que d’autres n’aient pas à payer pour le bouquin ? Donc faut que je paie pour que les autres aient un livre gratuit, j’ai bon ?

Tu as tout bon. Il y a un adage qui dit « si c’est gratuit, c’est toi le produit ». La croyance générale est qu’il faut se méfier du gratuit. Que cela dévalorise l’art, la culture. Alors que ça ne fait que déprécier les marchandises, et pleurer les commerçants… L’idée, c’est de s’amuser autour de la « loi prisunic », imposant un prix unique au livre en France. Le prix des framabooks tient compte de toute une chaîne de distribution (stockage, distribution, librairie, etc.) Pour la souscription, on est en circuit court. Les livres iront directement de moi à toi, sans avoir à payer d’intermédiaires. Mais on est légalement tenus de conserver ce tarif de 22 €… Alors au lieu de s’en mettre plein les poches, on va prendre tous ces bénéfices, faire de jolis livres du tome 1, et les offrir à des curieux, des intéressées et autres bouquinovores. On aime tous partager un bon bouquin. L’emprunter gratuitement dans une bibliothèque, ou sur l’étagère d’un ami. Ce roman est d’autant plus précieux qu’il nous a été donné. Le principe de cette souscription est le même. Nos efforts collectifs ajoutent de la valeur à ce geste gratuit.

Ils sont marrants tes personnages (enfin certains font un peu peur hein). Mais bon, dans quel volume tu vas introduire (hum en tout bien tout honneur) un épicier tunisien, un cheminot à la retraite, une opératrice de centre d’appel, un lycéen rimbaudmane (oui je sais les rimbaudlogues disent rimbaldien), une chasseuse de palourdes… ?

On a déjà une concierge geekette et une jeune fille élevée dans une ferme ostréicole, je te ferais dire ! Alors bien entendu, les héros des deux premiers tomes tiennent plus du cadre que du prolo… Mais ça n’augure rien quant à la suite ! Je t’avoue que ces personnages sont en train de prendre un relief et une vie toute particulière. Je pense que les histoires et les personnalités vont s’étoffer et se multiplier au fil des volumes. À ce titre, le livre III en surprendra plus d’un !

Tu assures vachement bien la comm et la promo tes bouquins, mais l’énergie et le temps que tu y passes ne nuisent pas au temps d’écriture ?

Merci, et : OUI. Là, je devrais être en train de corriger et d’annoter les épisodes du chapitre 8 pour que l’équipe Framabook puisse travailler dessus. Mais non, je communique. Cela fait partie du travail. J’ai appris ça quand je faisais le comédien. Pour jouer mes pièces, j’ai téléphoné, tracté, fait des sites web, harcelé, pondu des dossiers, couru premières et vernissages, affiché… La plupart de mes amis artistes (chansonniers, comédiennes, auteurs, metteuses en scène, etc.) font ça, peu ont les moyens de déléguer ce genre de choses… Ce n’est pas plus mal. D’une part cela entraîne à parler de ce que l’on fait, à le défendre et à le diffuser… Et d’autre part ça ancre dans la réalité. Sauf dans mon cas, où si je ne trouve pas de boulot très vite, la réalité va venir me faire payer l’ardoise avec ses intérêts ;p !

Est-ce que tu vas bientôt arrêter de te prétendre « déjanté » ? C’est devenu une vraie tarte à la crème. Tu devrais demander à tes fidèles habitués du blog quels adjectifs correspondent le mieux à ta saga. Je propose une première série :

• capricant
• invertébré
• supraconducteur
• callipyge
• caustique
• métadiabolique
• orchifrage

Tiens, un sondage pour voir

Je supprime invertébré (les huîtres c’est le mâââl !) et j’ajoute chalambré, parce que ce mot n’existe pas et qu’il devrait exister. Et OK : chiche ! Tu lances le sondage sur le framablog ? Si une solution remporte plus de 88 votes, quelle qu’elle soit, je l’utiliserai. Foi de Pouhiou !

— merci Pouhiou à la prochaine !

Pour s’y retrouver :

• Le site du roman-feuilleton métadiabolique et térébrant les NoéNautes
• Soutenir la publication du volume II de la saga contrapuntique : ululez que ça vous amuse de bousculer le prix du livre en le rendant gratuit.
• Acheter ou télécharger librement le premier Framabook des NoéNautes, qui narre les soubresauts picaresques d’Enguerrand.

(1) Un titre vaguement graveleux, voyez l’étymologie. Ce Pouhiou ne recule devant rien. Mais il se ferme les portes du vertueux Appstore, le bougre.

La promesse de système d’exploitation mobile libre Firefox OS réside moins dans Firefox OS lui-même que dans le parti pris Web (et ouvert) de ses applications.

C’est d’ailleurs plus qu’une promesse : c’est un défi et une nécessité si l’on souhaite conserver ici comme ailleurs l’ouverture et la liberté.

Un billet un peu technique, mais s’il peut contribuer à ce que les développeurs (et utilisateurs) d’applications mobiles se posent de bonnes questions…

La promesse de Firefox OS

The promise of Firefox OS

Sergi Mansilla - 9 février - Blog personnel
(Traduction : + anonymes)

« Mais comment va t-il faire pour battre Android ou iOS ? »

C’est la réaction qu’ont beaucoup de personnes quand je leur dit que je travaille sur Firefox OS, le nouveau système d’exploitation mobile de Mozilla. C’est une réaction logique. Après tout, nous vivons une période où toutes les grandes entreprises informatiques n’ont qu’un mot à la bouche : sortir un système mobile tout en s’efforçant d’attirer les développeurs pour qu’ils utilisent leur nouvel écosystème propriétaire, les APIS, les bibliothèques, etc. Et en effet, bon nombre de ces entreprises réussissent un peu, voire pas du tout.

Mais Firefox ne se battra pas directement contre les autres plateformes mobiles. Son objectif principal est de modifier la manière dont sont développées les applications mobiles, et même dans la triste éventualité où Firefox OS disparaissait durant le processus, si les web-apps devenaient dominantes sur le marché, ça sera un succès.

Le fait que n’importe quel site web puisse devenir une application ne doit pas être sous-estimé. En utilisant des technologies flexibles et populaires comme HTML5, CSS3 et javascript, Firefox OS a promu instantanément des millions de développeurs web et javascript en développeurs d’applications. Tout ce qu’ils ont à faire est de télécharger un module complémentaire de simulation gratuit (et ce n’est même pas nécessaire si votre application n’utilise pas les () APIs des téléphones (). Les développeurs connaissent déjà l’environnement du navigateur et ses outils, et il ne leur est pas nécessaire d’apprendre une nouveau langage ou une nouvelle architecture.

Je vous entends déjà. Juste quand vous veniez d’en finir avec le bazar que suppose la manipulation de DOM et de ce sournois de JavaScript. Juste quand vous aviez appris à aimer les classes et managers d’Android tellement hiérarchisés ou la magnifique méthode de nommage d’iOS, pourquoi retourneriez-vous au désordre qu’est l’écriture des applications web ? N’étions-nous pas d’accord /*pour dire*/que l’HTML n’était pas, après tout, assez bien pour faire de vraies applications performantes ?

Bon, ça a peut-être été vrai il y a quelques temps, mais nous vivons désormais dans un monde meilleur. Pour que les développeurs conçoivent des applications web robustes et réellement fonctionnelles, plusieurs approches sont possibles, via des architectures de grande qualité. Chez Telenor/Comoyo, où je travaille, nous nous penchons sur l’utilisation de l’architecture AngularJS pour construire nos applications, néanmoins il existe de multiples architectures fiables et bien conçues qui s’appuient sur des années d’expérience dans le domaine du développement d’applications. Et si vous considérez que vous avez un problème avec JavaScript en tant que langage, vous pouvez d’ores et déjà utiliser une myriade de langages qui le compilent de manière fiable. Vous avez l’habitude de travailler avec Java ? Vous allez probablement apprécier Dart, de Google. Vous avez un style plus “fonctionnel” ? Pourquoi ne pas essayer ClojureScript qui est une implémentation de Clojure s’appuyant sur du JavaScript, qui est impressionnante, vraiment bien documentée et vraiment bien maintenue. Vous utilisez Ruby ? Vous vous sentirez comme à la maison avec CoffeeScript. Vous voyez ce que je veux dire^[1].

Alors que d’autres constructeurs comme Blackberry fournissent eux aussi des moyens de développer des applications en HTML5 pour leurs systèmes, Mozilla va plus loin en encourageant la standardisation de la WebAPI par le W3C, garantissant ainsi que votre application fonctionnera sur n’importe quel appareil respectant le standard WebAPI.

À mon humble avis, cela rend les choses plus claires dans ce casse-tête qu’est devenu le développement pour appareils mobiles, pour lequel le développeur doit connaître plusieurs langages, architectures et APIs, sans oublier de payer des frais, dans certains cas, pour construire des applis. Cela ressemble à un grand pas en arrière de la philosophie actuelle de l’open web vers les années 90 infestés de verrous payants mais avec la bonne musique en moins.

Mozilla a fait ses preuves en tant que protecteur du web, et ses utilisateurs lui font confiance. Par le passé, elle a joué un rôle important dans l’initiation d’un mouvement pour de meilleurs standards webs auquel se sont rattachés des navigateurs comme Chrome, contribuant à un web meilleur, plus rapide et plus accessible pour chacun. Nous devrions nous efforcer d’en faire de même pour ce qui est des environnements mobiles. Moins de remparts, plus de standards et d’ouverture.

Telle est la promesse faite par Firefox OS.

Crédit photo : Rob Hawkes (Creative Commons By-Sa)

Nous ne sommes pas des criminels et nous sommes de plus en plus nombreux à rejoindre les rangs de l’armée d’Aaron Swartz.

Le 24 janvier dernier s’est déroulée une émouvante cérémonie à la mémoire d’Aaron Swartz, dans ce lieu hautement symbolique qu’est l’église de San Francisco qui abrite l’Internet Archive.

Parmi les personnalités qui se sont succédées, il y eut ainsi sa fiancée Taren Stinebrickner-Kauffman, le fondateur d’Internet Archive Brewster Kahle ( allocution remarquée par Calimaq qui en a fait un billet dédié) et son ami Carl_Malamud, fondateur de Public.Resource.org.

C’est cette dernière intervention que nous vous proposons traduite ci-dessous (disponible ici en vidéo).

« J’aimerais que nous puissions changer le passé, mais c’est impossible. Par contre, nous pouvons changer le futur, et nous le devons. »

L’armée d’Aaron

Aaron’s Army

Carl Malamud - 24 janvier 2013 - PublicRessource.org
(Traduction : brandelune, Lamessen, KoS, Garburst, Tr4sK, Astalaseven)

Ne croyez pas un instant que le travail d’Aaron sur JSTOR était l’acte incohérent d’un hacker solitaire, un peu fou, un téléchargement massif un peu dingue décidé sur un coup de tête.

Depuis longtemps, JSTOR a fait l’objet de critiques cinglantes de la part du net. Dans une conférence, Larry Lessig a qualifié JSTOR d’outrage à la morale et je dois vous avouer qu’il me citait. Nous n’étions pas les seuls à attiser ces flammes.

Emprisonner la connaissance derrière des péages, en rendant les journaux scientifiques accessibles uniquement à quelques gamins suffisamment fortunés pour aller dans des universités de luxe et en demandant vingt dollars par article pour le reste d’entre nous, était une plaie purulente qui choquait beaucoup de gens.

De nombreux auteurs de ces articles furent gênés que leur travail soit devenu la marge de profit de quelqu’un, un club privé du savoir réservé à ses adhérents.

Beaucoup d’entre nous ont aidé à attiser ce feu. Beaucoup d’entre nous s’en sentent coupables, aujourd’hui.

Mais JSTOR n’était qu’une des nombreuses batailles. On a essayé de dépeindre Aaron comme un hacker solitaire, un jeune terroriste à l’origine d’un carnage numérique qui fit 92 millions de dollars de dégâts.

Aaron n’était pas un loup solitaire, il faisait partie d’une armée, et j’ai eu l’honneur de m’engager à ses côtés pendant une décennie. De nombreuses choses ont été dites sur sa vie hors du commun, mais ce soir je ne parlerai que d’un aspect de celle-ci.

Aaron faisait partie d’une armée de citoyens qui pensent que la démocratie ne fonctionne que si les citoyens sont informés, s’ils connaissent leurs droits et leurs devoirs. Une armée qui estime que nous devons rendre la justice et le savoir accessibles à tous, et pas uniquement à ceux qui sont bien nés ou qui ont saisi les rênes du pouvoir, afin que nous puissions nous gouverner de manière plus éclairée.

Aaron faisait partie d’une armée de citoyens qui rejette les rois et les généraux et qui croit au consensus général et à son application pratique immédiate.

Nous avons travaillé ensemble sur une douzaine de bases de données gouvernementales. Lorsque nous travaillions sur quelque chose, les décisions n’étaient pas irréfléchies. Notre travail prenait souvent des mois, parfois des années, parfois même une décennie, mais Aaron Swartz n’a pas eu droit à sa part de décennies.

Longtemps, nous avons observé et bidouillé la base de donnée du droit d’auteur américain, un système si vieux qu’il utilisait encore WAIS. Le gouvernement , croyez-le ou non, avait revendiqué le droit d’auteur sur cette base de données du droit d’auteur. Il m’est impossible de concevoir qu’il puisse y avoir des droits d’auteur sur une base de données qui découle directement de la constitution des États-Unis, mais nous savions que nous jouions avec le feu en enfreignant les clauses d’utilisations. Nous étions donc très attentifs.

Nous avons récupéré ces données. Elles ont été utilisées pour alimenter l’Open Library d’Internet Archive ainsi que Google Books. Puis, nous avons reçu une lettre du Bureau du droit d’auteur indiquant qu’il abandonnait son droit d’auteur sur cette base de données. Mais avant cela, nous avons dû consulter de nombreux avocats par crainte que le gouvernement nous traîne devant les tribunaux pour téléchargement massif, malveillant et prémédité.

Ce n’était pas une agression irréfléchie. Nous travaillions sur les bases de données pour les améliorer, pour aider au fonctionnement de notre démocratie, pour aider notre gouvernement. Nous n’étions pas des criminels.

Lorsque nous avons libéré 20 millions de pages de documents de l’U.S District Court de leur péage à 8 cents par page, nous avons découvert que ces fichiers publics étaient infestés d’atteintes à la vie privée : noms de mineurs, noms d’informateurs, dossiers médicaux, dossiers psychiatriques, rapports financiers, des dizaines de milliers de numéros de sécurité sociale.

Nous étions des lanceurs d’alerte et nous avons transmis nos résultats aux juges en chef de 31 cours de justice de district et ces juges ont été choqués, consternés. Ils ont modifié ces documents puis ont incendié les avocats qui les avaient remplis. Finalement, la Conférence judiciaire a changé ses règles de respect de la vie privée.

Mais savez-vous ce qu’ont fait les bureaucrates qui dirigent le Bureau Administratif de la Cour des États-Unis ? Pour eux, nous n’étions pas des citoyens ayant amélioré les données publiques, nous étions des voleurs qui les privions d’1,6 millions de dollars.

Ils ont donc appelé le FBI et ont dit qu’ils avaient été hackés par des criminels, une bande organisée qui mettait en péril leur revenu de 120 millions de dollars provenant de la vente de documents publics du gouvernement.

Le FBI s’est installé devant la maison d’Aaron. Il l’ont appelé et ont essayé de le piéger pour qu’il les rencontre sans son avocat. Le FBI a installé deux agents armés dans une salle d’interrogatoire avec moi pour nous faire avouer les dessous de cette conspiration présumée.

Mais nous n’étions pas des criminels, nous étions seulement des citoyens.

Nous n’avons rien fait de mal. Ils n’ont rien trouvé. Nous avions fait notre devoir de citoyen et l’enquête du gouvernement n’a rien trouvé de répréhensible mais ce fut une perte de temps et d’argent.

Si vous voulez faire peur, faites asseoir quelqu’un avec deux agents fédéraux pendant un moment et vous verrez la vitesse à laquelle son sang se glace.

Il y a des gens qui affrontent le danger tous les jours pour nous protéger — les policiers, les pompiers et les services d’urgence — je leur en suis reconnaissant et je suis ébahi par ce qu’ils font. Mais le travail des gens comme Aaron et moi, faire des DVD et faire tourner des scripts shell sur des documents publics, ne devrait pas être une profession dangereuse.

Nous n’étions pas des criminels, mais des crimes furent commis, des crimes contre l’idée même de la justice.

Quand la procureure fédérale a dit à Aaron qu’il devrait plaider coupable de treize crimes pour avoir tenté de propager le savoir avant qu’elle ne puisse envisager de négocier sa peine, c’était un abus de pouvoir, une utilisation frauduleuse du système de justice criminelle, un crime contre la justice.

Et la procureure fédérale n’a pas agi seule. Elle fait partie d’un groupe dont l’intention est de protéger la propriété, pas les gens. Tous les jours, partout aux États-Unis, des démunis n’ont pas accès à la justice et sont confrontés à ces abus de pouvoir.

C’était un crime contre le savoir qu’une organisation à but non lucratif telle que JSTOR transforme un téléchargement qui n’a causé aucun préjudice ni dommage, en une procédure fédérale de 92 millions de dollars.

Et le monopole de JSTOR sur la connaissance n’est pas unique. Partout aux États-Unis, des sociétés ont planté leurs griffes sur les champs de l’éducation : universités privées qui volent nos vétérans, organismes de normalisation à but non lucratif qui rationnent les codes de sécurité publique alors qu’ils payent des salaires d’un million de dollars, et les conglomérats multinationaux qui évaluent la valeur des articles scientifiques et des documents juridiques à l’aune de leur marge brute.

Dans le procès JSTOR, la position plus qu’agressive des procureurs du Département de la Justice et des agents de la force publique était-elle une vengeance lié à l’embarras de nous avoir vu nous tirer à bon compte, en tout cas à leur yeux, de l’affaire du PACER ? Est-ce que la poursuite sans merci de JSTOR était la revanche de bureaucrates embarrassés d’avoir été ridiculisés dans le New York Times, d’avoir reçu un blâme du Sénat ?

Nous n’aurons probablement jamais la réponse à cette question, mais il semble certain qu’ils ont détruit la vie d’un jeune homme par simple abus de pouvoir. Ce n’était pas une question criminelle, Aaron n’était pas un criminel.

Si vous pensez posséder quelque chose et si je pense que ce bien est public, il me semble juste de vous voir au tribunal. Si vous avez raison et que je vous ai fait du tort, je prendrais mes responsabilités. Mais quand nous retournons le bras armé de la Loi contre les citoyens qui contribuent à accroître l’accès à la connaissance, nous brisons l’esprit de la loi, nous profanons le temple de la justice.

Aaron Schwartz n’était pas un criminel. C’était un citoyen et un soldat courageux dans une guerre qui continue aujourd’hui, une guerre dans laquelle des profiteurs corrompus et vénaux essayent de voler, de profiter, d’assécher notre domaine public au profit de leurs gains privés.

Quand des gens essaient de restreindre l’accès à la loi, ou qu’ils essaient de collecter des droits de péage sur les routes du savoir, ou refusent l’éducation à ceux qui n’ont pas de moyens, c’est eux qui devraient subir le regard sévère d’un procureur outragé.

Ce que le Département de la justice a fait endurer à Aaron pour avoir essayé de rendre notre monde meilleur, ils peuvent vous l’infliger. Notre armée n’est pas réduite à un loup solitaire, elle est forte de milliers de citoyens, beaucoup d’entre vous dans cette pièce, qui se battent pour la justice et le savoir.

J’affirme que nous sommes une armée, et je mesure bien l’usage de ce mot car nous affrontons des personnes qui veulent nous emprisonner pour avoir téléchargé une base de données afin de l’examiner de plus près, nous affrontons des personnes qui croient qu’ils peuvent nous dire ce que nous pouvons lire et ce que nous pouvons dire.

Mais quand je vois notre armée, je vois une armée qui crée au lieu de détruire. Je vois l’armée du Mahatma Gandhi marchant pacifiquement vers la mer pour récolter du sel pour les gens. Je vois l’armée de Martin Luther King marchant pacifiquement mais avec détermination sur Washington pour réclamer ses droits, car le changement ne coule pas de source, il provient de luttes continues.

Quand je vois notre armée, je vois l’armée qui crée de nouvelles opportunités pour les pauvres, une armée qui rend notre société plus juste et plus égalitaire, un armée qui rend le savoir universel.

Quand je vois notre armée, je vois les gens qui ont créé Wikipedia et l’Internet Archive. Je vois ceux qui ont programmé GNU, Apache, BIND et Linux. Je vois ceux qui ont fait l’EFF et les Creative Commons. Je vois les gens qui ont créé notre internet en tant que cadeau au monde.

Quand je vois notre armée, je vois Aaron Schwartz et j’ai le cœur brisé. Nous avons vraiment perdu l’un de nos anges gardiens.

J’aimerais que nous puissions changer le passé, mais c’est impossible. Par contre, nous pouvons changer le futur, et nous le devons.

Nous le devons à Aaron, nous nous le devons à nous-même, nous le devons pour rendre notre monde meilleur, en faire un lieu plus humain, un endroit où la justice fonctionne et où l’accès à la connaissance est un droit de l’Homme.

Crédit photo : Open Knowledge Foundation (Creative Commons By)

Nous traduisons souvent Bruce Byfield, libre penseur du logiciel libre, sur le Framablog.

A-t-il raison d’affirmer qu’il est des sujets pour ainsi dire tabous dans la communauté et surtout que la situation a évolué, n’en déplaise à certains ?

Neuf choses dont on ne discute jamais sur l’open source

9 Things That Are Never Admitted About Open Source

Bruce Byfield - 22 janvier 2013 - Datamation
(Traduction : Moosh, brandelune, Sky, ehsavoie, Astalaseven, petit bonhomme noir en haut à droite, mike, goofy, KoS, Mowee, arcady, maxlath, Astalaseven, mariek, VifArgent, Rudloff, VIfArgent, Penguin, peupleLa, Vilrax, lamessen + anonymous)

Quels sont les sujets tabous dans l‘open source de nos jours ? Certains peuvent se deviner mais d’autres pourraient bien vous surprendre.

On pourrait penser qu’un groupe de personnes intelligentes comme les membres de la communauté des logiciels libres et open source (NdT : FOSS pour Free and Open Source Software) seraient sans tabous. On pourrait s’attendre à ce qu’un tel groupe d’intellectuels juge qu’aucune idée n’est interdite ou gênante – mais ce serait une erreur.

Comme toute sous-culture, la communauté FOSS est cimentée par des croyances. Ces croyances contribuent à bâtir une identité commune : par conséquent, les remettre en cause revient à remettre en cause cette identité.

Certains de ces sujets tabous peuvent saper des évidences admises depuis vingt ans ou plus. D’autres sont nouveaux et contestent des vérités communément acceptées. Quand on les examine, on s’aperçoit que chacun d’entre eux peut être aussi menaçant que la déclaration de valeurs communes peut être rassurante.

Pourtant, même s’il est inconfortable d’interroger ces tabous, il est souvent nécessaire de le faire. Les croyances peuvent perdurer longtemps après le temps où elles s’appliquaient, ou après avoir dégénéré en semi-vérités. Il est utile de temps en temps de penser l’impensable, ne serait-ce que pour mettre ces croyances en phase avec la réalité.

Suivant cette logique, voici neuf observations sur l‘open source qui nécessitent selon moi un nouvel examen.

1. Ubuntu n’est plus le dernier grand espoir de l’open source

Quand Ubuntu est apparue il y a neuf ans, nombreux sont ceux qui l’ont considérée comme la distribution qui mènerait la communauté à dominer le monde. Débarquant de nulle part, Ubuntu s’est immédiatement concentrée sur le bureau comme aucune autre distribution avant elle. Des outils et des utilitaires furent ajoutés. De nombreux développeurs Debian trouvèrent un travail chez Canonical, la branche commerciale d’Ubuntu. Des développeurs virent leurs frais payés pour des conférences auxquelles ils n’auraient pas pu se rendre autrement.

Au fil du temps, une bonne partie de l’enthousiasme initial est retombée. Personne ne semble s’être intéressé à la demande de Mark Shuttleworth, le fondateur d’Ubuntu, à ce que les principaux projets coordonnent leurs cycles de livraison ; ils l’ont tout simplement ignorée. Mais on a vu des sourcils se froncer lorsqu’Ubuntu a commencé à développer sa propre interface plutôt que de contribuer à GNOME. Canonical a commencé à contrôler ce qui se passait dans Ubuntu, apparemment pas pour l’intérêt général mais surtout pour la recherche de profits. Nombreux, aussi, furent ceux qui n’apprécièrent pas l’interface d’Ubuntu, Unity, à sa sortie.

Pourtant, à écouter les employés de Canonical, ou les bénévoles Ubuntu, on aurait presque l’impression qu’il ne s’est rien passé pendant ces neuf dernières années. Lisez notamment le blog de Shuttleworth ou ses déclarations publiques : il se donne le rôle de figure de proue de la communauté et déclare que les « hurlements des idéologues » finiront par cesser devant son succès.

2. Le « cloud computing » sape les licences libres

Il y a sept ans, Tim O’Reilly affirmait que les licences libres étaient devenues obsolètes. C’était sa manière un peu dramatique de nous prévenir que les services en ligne mettent à mal les objectifs du logiciel libre. Comme le logiciel, le cloud computing offre aux utilisateurs l’usage gracieux des applications et du stockage, mais sans aucune garantie ou contrôle quant à la vie privée.

La Free Software Foundation (NdT : Fondation pour le Logiciel Libre) répondit à la popularité grandissante du cloud computing en dépoussiérant la GNU Affero General Public License, qui étend les idéaux du FOSS au cloud computing.

Après cela, pourtant, les inquiétudes à propos de la liberté logicielle au sein du cloud ont faibli. Identi.ca fut créé comme une réponse libre à Twitter, et MediaGoblin développé comme l’équivalent libre d’Instagram ou de Flickr, mais ce genre d’efforts est occulté par la compétition. On n’a pas mis l’accent sur l’importance des licences libres ou du respect de la vie privée dans le cloud.

Par conséquent, les avertissements de O’Reilly sont toujours aussi pertinents de nos jours.

3. Richard Stallman est devenu un atout contestable

Le fondateur de la Free Software Foundation et le moteur derrière la licence GNU GPL, Richard M. Stallman, est une des légendes des logiciels libres et open source. Pendant des années, il a été l’un des plus ardents défenseurs de la liberté du logiciel et la communauté n’existerait probablement pas sans lui.

Ce que ses supporters rechignent à admettre, c’est que la stratégie de Stallman a ses limites. Nombreux sont ceux qui disent que c’est un handicapé social, et que ses arguments se basent sur la sémantique — sur les mots choisis et comment ils influencent le débat.

Cette approche peut être éclairante. Par exemple, lorsque Stallman s’interroge sur l’analogie entre le partage de fichiers et les pillages perpétrés par les pirates, il révèle en fait le parti-pris que l’industrie du disque et du cinéma tente d’imposer.

Mais, malheureusement, c’est à peu près la seule stratégie de Stallman. Il dépasse rarement ce raisonnement qu’il utilise pour fustiger les gens, et il se répète même davantage que des personnes qui passent leur temps à faire des discours. Il est perçu de plus en plus, par une partie de la communauté, comme quelqu’un hors de propos voire même embarrassant. Comme quelqu’un qui fut efficace… mais ne l’est plus. Il semble que la communauté a du mal à admettre l’idée que Stallman a eu un impact certain pendant des années, mais qu’il est moins utile aujourd’hui. Soit il est défendu férocement pour son passé glorieux, soit il est attaqué comme un usurpateur parasite. Je crois que les affirmations concernant ce qu’il a accompli et son manque d’efficacité actuel sont vraies toutes les deux.

4. L’open source n’est pas une méritocratie

L’une des légendes que les développeurs de logiciels libres aiment à se raconter est que la communauté est une méritocratie. Votre statut dans la communauté est censément basé sur vos dernières contributions, que ce soit en code ou en temps.

L’idée d’une méritocratie est très attirante, en cela qu’elle forme l’identité du groupe et assure la motivation. Elle encourage les individus à travailler de longues heures et donne aux membres de la communauté un sentiment d’identification et de supériorité.

Dans sa forme la plus pure, comme par exemple au sein d’un petit projet où les contributeurs ont travaillé ensemble pendant de nombreuses années, la méritocratie peut exister.

Mais le plus souvent, d’autres règles s’appliquent. Dans de nombreux projets, ceux qui se chargent de la documentation ou bien les graphistes sont moins influents que les programmeurs. Bien souvent, vos relations peuvent influencer la validation de votre contribution au moins autant que la qualité de votre travail.

De même, la notoriété est plus susceptible d’influencer les décisions prises que le grade et les (surtout si elles sont récentes) contributions. Des personnes comme Mark Shuttleworth ou des sociétés comme Google peuvent acheter leur influence sur le cours des choses. Des projets communautaires peuvent voir leurs instances dirigeantes dominées par les sponsors privés, comme c’est de fait le cas avec Fedora. Bien que la méritocratie soit l’idéal, ce n’est presque jamais la seule pratique.

5. L’open source est gangrené par un sexisme systémique

Une autre tendance qui plombe l’idéal méritocratique est le sexisme (parfois sour la forme de la misogynie la plus imbécile) que l’on trouve dans quelques recoins de la communauté. Au cours des dernières années, les porte-parole du FOSS ont dénoncé ce sexisme et mis en place des règles officielles pour décourager quelques uns de ses pires aspects, comme le harcèlement pendant les conférences. Mais le problème demeure profondément ancré à d’autres niveaux.

Le nombre de femmes varie selon les projets, mais 15 à 20 pour cent peut être considéré comme un chiffre élevé pour un projet open source. Dans de nombreux cas, ce nombre est en dessous des cinq pour cent, même en comptabilisant les non-programmeurs.

De plus les femmes sont sous-représentées lors des conférences, à l’exception de celles où les femmes sont activement encouragées à faire part de leurs propositions (ces efforts entraînent, inévitablement, leur lot d’accusations quant à des traitements spéciaux et des quotas, quand bien même aucune preuve ne peut être avancée).

La plus grande évidence de sexisme se produit quotidiennement. Par exemple, Slashdot a récemment publié un entretien avec Rikki Ensley, membre de la communauté USENIX. Parmi les premiers commentaires, certains se référaient à une chanson populaire dont le refrain mentionne le prénom Rikki. D’autres discutent de son apparence et lui donnent des conseils pour avoir l’air plus « glamour ».

On assiste à des réactions du même ordre, et bien d’autres pires encore sur de nombreux sites dédiés au monde du libre ou sur IRC, dès qu’une femme apparaît, surtout s’il s’agit d’une nouvelle venue. Voilà qui dément les affirmations d’une communauté qui prétend ne s’intéresser qu’aux seules contributions, ou encore l’illusion que la sous-représentation des femmes serait simplement une question de choix individuels.

6. Microsoft n’est plus l’ennemi irréductible du logiciel libre

Il y a à peine plus d’une dizaine d’années, vous pouviez compter sur Microsoft pour traiter le monde du Logiciel Libre de « communiste » ou « anti-Américain », ou sur leurs intentions parfois divulguées dans la presse de vouloir détruire la communauté.

Une grande partie de la communauté s’accroche encore à ces souvenirs. Après tout, rien ne rassemble plus les gens qu’un ennemi commun, puissant et inépuisable.

Mais ce dont la communauté ne se rend pas compte, c’est que la réaction de Microsoft est devenue plus nuancée, et qu’elle varie d’un service à l’autre au sein de l’entreprise.

Nul doute que les dirigeants de Microsoft continuent de voir le logiciel libre comme un concurrent, bien que les dénonciations hautes en couleur aient cessé.

Cependant, Microsoft a pris conscience que, compte-tenu de la popularité du logiciel libre, les intérêts à court terme de l’entreprise seraient mieux servis si elle s’assurait que les outils libres (en particulier les langages de programmation les plus populaires) fonctionnent correctement avec ses propres produits. C’est d’ailleurs la mission principale du projet Microsoft Open Technologies. Récemment, Microsoft est même allé jusqu’à publier une courte déclaration faisant l’éloge de la dernière version de Samba, qui permet l’administration des serveurs Microsoft depuis Linux et les systèmes Unix (NdT : Voir aussi cette FAQ en français publiée par Microsoft).

Bien sûr, il ne faut pas non plus s’attendre à voir Microsoft devenir une entreprise open source ou faire des dons désintéressés d’argent ou de code à la communauté. Mais, si vous faites abstraction des vieux antagonismes, l’approche égoïste de Microsoft à l’égard du logiciel libre n’est pas très différente de nos jours de celle de Google, HP, ou n’importe quelle autre entreprise.

7. L’innovation des interfaces stagne

En 2012, nombreux furent ceux qui n’ont pas adopté GNOME 3 et Unity, les deux dernières interfaces graphiques majeures. Cet abandon fut largement lié à l’impression que GNOME et Ubuntu ignoraient les préoccupations des utilisateurs et qu’ils imposaient leur propre vision, sans concertation.

À court terme, cela a mené à la résurrection de GNOME 2 sous des formes variées.

En tant que prédécesseur de GNOME 3 et de Unity, GNOME 2 fut un choix évident. C’est une interface populaire qui n’impose que peu de restrictions aux utilisateurs.

Quoi qu’il en soit, cela risque d’être, à long terme, étouffant pour l’innovation. Non seulement parce que le temps passé à ressuciter GNOME 2 n’est pas mis à profit pour explorer de nouvelles voies, mais parce que cela semble être une réaction à l’idée même d’innovation.

Peu sont ceux, par exemple, qui sont prêts à reconnaître que GNOME 3 ou Unity ont des fonctionnalités intéressantes. Au contraire, les deux sont condamnés dans leur ensemble. Et les développements futurs, tels l’intention de GNOME de rendre la sécurisation et la confidentialité plus simples, n’ont pas reçu l’attention qu’ils méritaient.

Au final, au cours des prochaines années, l’innovation en sera probablement réduite à une série de changements ponctuels, avec peu d’efforts pour améliorer l’ergonomie dans son ensemble. Même les développeurs hésiteront à tenter quoi que ce soit de trop différent, afin d’éviter le rejet de leurs projets.

Je me dois d’applaudir le fait que les diverses résurrections de GNOME 2 marquent le triomphe des requêtes des utilisateurs. Mais le conservatisme qui semble accompagner ces aboutissements m’inquiète : j’ai bien peur que cette victoire n’engendre d’autres problèmes tout aussi importants.

8. L’open source est en train de devenir une monoculture

Ses partisans aiment à revendiquer que l’un des avantages du logiciel libre et open source, c’est d’encourager la diversité. À la différence de Windows, les logiciels libres sont supposés être plus accueillants pour les idées nouvelles et moins vulnérables aux virus, la plupart des catégories de logiciels incluant plusieurs applications.

La réalité est quelque peu différente. À la lecture d’une étude utilisateurs vous remarquerez un modèle plutôt constant : une application ou technologie recueille 50 à 65% des votes, et la suivante 15 à 30%.

Par exemple, parmi les distributions, Debian, Linux Mint et Ubuntu, qui utilisent toutes le format de packet en .DEB, recueillent 58% du choix des lecteurs 2012 du Linux Journal, que l’on peut comparer aux 16% recueillis par Fedora, openSUSE, et CentOS, qui utilisent quant à elles le format .RPM.

De même, Virtualbox atteint 56% dans la catégorie « Meilleure solution de virtualisation », et VMWare 18%. Dans la catégorie « Meilleure gestion de versions », Git recueille 56% et Subversion 18%. La catégorie la plus asymétrique est celle des « Suites bureautiques » dans laquelle LibreOffice recueille 73% et (sic) Google Docs 12%.

Il n’y avait que deux exceptions à cette configuration. La première était la catégorie « Meilleur environnement de bureau », dans laquelle la diversification des dernières années était illustrée par les scores de 26% pour KDE, 22% pour GNOME 3, 15% pour GNOME 2 et 12% pour Xfce. La deuxième catégorie était celle de « Meilleur navigateur web »dans laquelle Mozilla Firefox recueillait 50% et Chromium 40%.

De manière générale, les chiffres ne rendent pas compte d’un monopole, mais dans la plupart des catégories, la tendance est là. Au mieux, on pourrait dire que, si la motivation n’est pas le profit, le fait d’être moins populaire n’implique pas que l’application va disparaître. Mais si la concurrence est saine, comme tout le monde aime à le dire, il y a tout de même des raisons de s’inquiéter. Quand on y regarde de près, les logiciels libres sont loin d’être aussi diversifiés que ce que l’on croit.

9. Le logiciel libre est bloqué si près de ses objectifs

En 2004, les logiciels libres et open source en étaient au stade où ils couvraient la plupart des usages de base des utilisateurs : envoi de courriels, navigation sur internet et la plupart des activités productives sur ordinateur. En dehors des espoirs de disposer un jour d’un BIOS libre, il ne manquait plus que les pilotes pour les imprimantes 3D et les cartes WiFi pour atteindre l’utopie d’un système informatique entièrement libre et open source.

Neuf ans plus tard, de nombreux pilotes libres de carte WiFi et quelques pilotes libres de cartes graphiques sont disponibles - mais nous sommes loin du compte. Pourtant la Free Software Foundation ne mentionne que rarement ce qui reste à faire, et la Linux Foundation ne le fait pratiquement jamais, alors même qu’elle sponsorise l’OpenPrinting database, qui liste les imprimantes ayant des pilotes libres. Si l’on combinait les ressources des utilisateurs de Linux en entreprise, on pourrait atteindre ces objectifs en quelques mois, pourtant personne n’en fait une priorité.

Admettons que certaines entreprises se préoccupent de leur soi-disant propriété intellectuelle sur le matériel qu’elles fabriquent. Il est possible également que personne ne veuille courir le risque de fâcher leurs partenaires commerciaux en pratiquant la rétroingénierie. Pourtant, on a bien l’impression que l’état actuel de statu quo persiste parce que c’est déjà bien assez, et que trop peu de personnes ont à cœur d’atteindre des objectifs dont des milliers ont fait le travail de leur vie.

Des discussions, non des disputes

Certains ont peut-être déjà conscience de ces sujets tabous. Cependant, il est probable que chacun trouvera dans cette liste au moins un sujet pour se mettre en rogne.

Par ailleurs, mon intention n’est pas de mettre en place neuf aimants à trolls. Même si je le voulais, je n’en aurais pas le temps.

Ces lignes sont plutôt le résultat de mes efforts pour identifier en quoi des évidences largement admises dans la communauté devraient être remises en question. Je peux me tromper. Après tout, je parle de ce que j’ai pris pour habitude de penser, moi aussi. Mais au pire, cette liste est un bon début.

Si vous pensez qu’il y a d’autres sujets tabous à aborder et à reconsidérer au sein de la communauté des logiciels libres et open source, laissez un commentaire. Cela m’intéresse de voir ce que je pourrais avoir oublié.

Crédit photo : Laëtitia Dulac (Creative Commons By)

Bienvenue LibreOffice 4.0 !

-> Nouveautés et correctifs de la version 4.0

• Source : LibreOffice 4 est disponible au téléchargement ? (Numerama)

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

Et si le navigateur disparaissait ?

Par Tristan Nitot, Mozilla Principal Evangelist

(Adaptation d’un article en anglais publié sur le blog officiel Mozilla, Beyond the Code, sous le titre What if the browser disappeared?. Sky, Slystone, goofy pour la traduction).

L’autre jour, je lisais un article provocateur intitulé The end of the browser? (NDT : « La fin du navigateur ? »). Cet article soutient fondamentalement que tout le monde utilisant de plus en plus d’appareils nomades, les applications mobiles remplacent les navigateurs Web pour diverses raisons, la principale étant qu’elles sont plus pratiques que les pages Web affichées dans les navigateurs.

Bien qu’en désaccord avec l’auteur, je pense qu’il s’agît d’une question très intéressante qui soulève deux problèmes :

1. Et si le Web était remplacé par les applications mobiles ? En quoi serait-il dommageable de perdre les navigateurs Web en tant que canal principal d’accès à l’information et aux services ?
2. Que pouvons-nous faire pour nous assurer que le navigateur Web ne devienne pas une relique du passé pendant que le monde devient mobile ?

Et si le Web était remplacé par les applications mobiles ?

— Je pense que le monde y perdrait énormément. Il y perdrait tellement que je ne sais même pas par où commencer…

Liberté d’expression

Le Web n’est pas seulement fait de contenu commercial. Avoir la possibilité de s’exprimer est fondamental. Le Web permet cela, et avoir une structure décentralisée sur laquelle publier des trucs est nécessaire. Les magasins d’applications centralisés, comme les Appstores, ont montré une certaine tendance à censurer agressivement les contenus pour éviter les litiges, qu’il s’agisse d’art, de politique, de liberté de la presse ou simplement de mauvais goût.

Liberté de façonner mon expérience

Les navigateurs Web modernes sont équipés d’un système d’extensions qui permet aux utilisateurs de personnaliser leur expérience. Mais même avant que Firefox ne rende les extensions si populaires, il était possible d’utiliser des feuilles de styles alternatives ou même les feuilles de style de l’utilisateur pour modifier la présentation du contenu d’un site. Il ne s’agît pas seulement des goûts et des couleurs, mais également de l’importance pour le contenu du Web d’être accessible par aux personnes handicapées..

N’oublions pas que chaque plateforme majeure propose un navigateur Web, de Windows à MacOS en passant par GNU/Linux et tous les smartphones : les utilisateurs n’ont pas à acheter un matériel ou un logiciel spécifique pour accéder au Web. Tout ce dont ils ont besoin c’est un ordinateur qui puisse faire tourner un navigateur Web.

Liberté d’apprendre, de bricoler et de créer

Ce qui rend le Web différent des autres médias est la possibilité pour chacun de participer. Contrairement à la télévision, vous n’avez pas besoin de posséder une chaîne de télé pour partager votre point de vue avec un public. Tout le monde peut publier un billet de blog qui renvoie vers d’autres pages, partager des photos ou des vidéos, et c’est un progrès fantastique pour la démocratie, comparé aux temps de la télé, de la radio et des journaux.

Mais l’Internet et le Web ne sont pas seulement des médias. Ce sont des plateformes d’innovation. Comme tout le monde peut apprendre comment le Web fonctionne en regardant le code source, le Web permet à chacun de créer une application Web, ce qui conduit à plus d’innovations, provenant d’encore plus de gens.

Que pouvons-nous faire pour nous assurer que le navigateur Web ne devienne pas une relique du passé pendant que le monde devient mobile ?

La réponse à cette question est plus courte que la précédente, je vais vous présenter ce que fait Mozilla à ce sujet :

1. Continuer de faire un super navigateur pour le bureau : Firefox ;
2. Continuer de faire un super navigateur pour les mobiles : Firefox pour Android ;
3. Travailler sur un système d’exploitation mobile ouvert pour faire du Web la plateforme mobile de choix : Firefox OS (bientôt sur les téléphones portables près de chez vous !).

La nature ouverte du Web donne à chacun toutes sortes de libertés, et c’est pourquoi Mozilla s’investit dans Firefox OS : c’est le meilleur moyen de s’assurer que le Web a un futur dans un monde où la plupart des gens utilisent Internet sur leur téléphone portable.

Que pensez-vous que le monde perdrait si le navigateur Web disparaissait ? Vous pouvez nous le dire dans les commentaires là-dessous.

21/42 ! Tiens, nous voilà déjà à mi-chemin de la traduction d’Open Advice.

Deux ou trois articles petits ou grands chaque jeudi, traduits en un temps record par une bande de furieux, ceux qui sont là depuis le début et ceux qui débarquent et demandent s’ils peuvent participer, ceux qui travaillent d’arrache-clavier et ceux qui en profitent pour déconner échanger des propos sur le chat du pad, ceux qui choisissent un pseudo et ceux qui restent anonymous, ceux qui négligent tranquillement l’orthographe et les grammar nazis qui rectifient, ceux qui traduisent avec Google translate et ceux qui se battraient pour une majuscule à Libre… on rencontre tout un peuple là, et jusqu’à présent tout se passe dans l’enthousiasme et la bonne humeur, l’échange et l’entraide devant un passage un peu ardu sur lequel on s’amuse à chinoiser…

Mais cette fois-ci c’est l’auteur de l’article lui-même qui nous a fait le plaisir de nous rejoindre pour contribuer à la traduction, ce qui est tout de même assez confortable. Merci Guillaume !

Malgré nos relectures croisées, nul doute que des coquilles auront échappé à notre vigilance et que nous trouverons des lecteurs pour les signaler, ce qui nous est précieux car la révision avant l’édition du framabook en sera d’autant facilitée.

D’ici là, en avant pour la deuxième moitié : chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framalang : Nyx, Sphinx, peupleLà, Kalupa, Guillaume Paumier, Husi10, lenod, Sky, Julius22, Alpha, RavageJo, KoS, Sputnik, goofy, lamessen

Apprenez de vos utilisateurs

Guillaume Paumier

Guillaume Paumier est photographe et physicien, il habite à Toulouse. Wikipédien depuis longtemps, il travaille actuellement pour la Wikimedia Foundation, l’organisation à but non lucratif qui héberge Wikipédia. En tant que responsable de l’ergonomie multimédia, il a notamment étudié le comportement des utilisateurs afin de créer un nouveau système d’import de fichiers pour Wikimedia Commons, la médiathèque libre associée à Wikipédia.

Vous connaissez Wikipédia, l’encyclopédie libre et gratuite que tout le monde peut modifier ? Elle a été créée en 2001 et a récemment fêté son dixième anniversaire. Bien qu’elle soit l’un des dix sites les plus visités au monde, son interface reste très « 1.0 » quand on la compare aux possibilités qu’offrent les technologies web modernes. Certains peuvent trouver ça bien : Wikipédia est un « truc sérieux » et les utilisateurs n’ont pas à être distraits par des « paillettes » dans l’interface. Pourtant, si Wikipédia a eu du mal à recruter de nouveaux contributeurs ces dernières années, c’est en partie à cause de son interface que certains considèrent comme archaïque. Ceci explique peut-être pourquoi les enquêtes sur les participants à Wikipédia ont montré à maintes reprises qu’il s’agit principalement d’une population d’hommes jeunes, attirés par la technologie, la plupart ayant une formation en informatique et en ingénierie. En dehors du fait que la connaissance libre et les licences libres sont issues du terreau fertile du logiciel libre et open source, l’interface compliquée a découragé beaucoup de contributeurs éventuels.

En 2011, alors que la majorité des plates-formes de publication collaboratives en ligne (comme WordPress, Etherpad et Google Documents) offrent un éditeur graphique, même rudimentaire, Wikipédia utilise toujours, par défaut, un ancien éditeur de texte wiki qui utilise des guillemets (“”) et des crochets ([[]]) pour la mise en forme. Des efforts sont en cours afin de passer à un éditeur graphique par défaut en 2012, mais ce n’est pas un défi facile à relever.

Mais laissons l’éditeur de côté un moment. L’interface de Wikipédia demeure assez compliquée. Et de nombreuses fonctionnalités utiles sont difficiles à découvrir. Savez-vous que Wikipédia possède un système de contrôle de versions intégré ? Et que vous pouvez voir toutes les anciennes versions d’une page ? Savez-vous que vous pouvez voir la liste de toutes les modifications effectuées par un contributeur ? Savez-vous que vous pouvez créer un lien vers une version donnée d’une page ? Savez-vous que vous pouvez exporter une page en PDF ? Savez-vous que vous pouvez créer un vrai livre personnalisé à partir du contenu de Wikipédia ? Et que vous pouvez le faire livrer chez vous ?

Le modèle d’implémentation

La plupart des lecteurs de Wikipédia y arrivent via des moteurs de recherche. Les statistiques montrent qu’ils passent peu de temps sur Wikipédia une fois qu’ils ont trouvé l’information qu’ils cherchaient. Un petit nombre seulement s’attarde et explore les outils que propose l’interface. Par exemple, on critique régulièrement Wikipédia sur sa qualité et sur sa fiabilité. Nombre de ces outils rarement explorés et presque cachés pourraient s’avérer bien utiles aux lecteurs pour les aider à vérifier la fiabilité de l’information, telles que les « pages de discussion » qui témoignent des discussions (passées et en cours) entre les différents contributeurs de chaque article ayant abouti à son contenu actuel.

Wikipédia et ses projets frères (tels que Wikisource et Wikimedia Commons) sont propulsés par le moteur de wiki MediaWiki — et sont soutenus par la Wikimedia Foundation ; rien que ces noms, dans leur confusion, sont un péché contre l’ergonomie. Pendant longtemps, le développement de MediaWiki a été conduit par des développeurs de logiciels. La communauté MediaWiki est forte de nombreux développeurs ; à vrai dire, la communauté est presque exclusivement composée de développeurs. Ce n’est que récemment que des designers ont rejoint la communauté, et ils ont été recrutés par la Wikimedia Foundation pour ce rôle. Il n’y a quasiment aucun designer bénévole dans la communauté. De ce fait, l’application a été construite et « maquettée » exclusivement par des développeurs. Par conséquent, la forme de l’interface a naturellement suivi de très près le « modèle d’implémentation », c’est-à-dire la manière dont le logiciel est implémenté dans le code et les structures de données. Le modèle d’implémentation ne correspond que rarement au « modèle utilisateur », c’est-à-dire à la manière dont l’utilisateur imagine que le logiciel fonctionne.

Il serait injuste de dire que les développeurs ne se soucient pas des utilisateurs. Quand on crée un logiciel, le but — outre le plaisir d’apprendre des choses, d’écrire du code et de résoudre des problèmes — c’est de le publier afin qu’il puisse être utilisé. Ceci est particulièrement vrai dans le monde du logiciel libre et open source, où la plupart des développeurs donnent bénévolement de leur temps et de leurs connaissances. On pourrait avancer que les développeurs sont, de fait, des utilisateurs de leurs propres produits, notamment dans le monde du logiciel libre et open source. Après tout, ils les ont créés ou ont rejoint leurs équipes pour une bonne raison, et c’est rarement l’argent. Par conséquent, les développeurs de ce type de logiciels devraient être dans une position idéale pour savoir ce que veulent leurs utilisateurs.

Mais soyons honnêtes : si vous êtes en train de lire ceci, c’est que vous n’êtes pas votre utilisateur lambda.

Le point de vue du développeur

Si vous êtes développeur, il vous est particulièrement difficile de vous mettre à la place de l’utilisateur. Tout d’abord, votre connaissance du code et de l’implémentation du logiciel vous force à observer ses fonctionnalités et son interface à travers un prisme très particulier. Vous connaissez chacune des fonctionnalités de l’application que vous avez créée. Vous savez où trouver chaque menu. Si quelque chose paraît légèrement bizarre dans l’interface, il est possible que vous l’ignoriez sans le vouloir, parce que vous savez inconsciemment que c’est lié à la façon dont la fonctionnalité est implémentée.

Imaginons que vous soyez en train de créer une application qui enregistre des données sous forme de tableau (par exemple, dans une base de données). Quand vous devrez ensuite afficher ces données pour les montrer à l’utilisateur, il est très probable que vous les représentiez comme un tableau, car c’est la façon dont vous avez implémenté leur stockage. Il vous paraîtra logique d’afficher les données dans un format qui est cohérent avec le format de stockage. Vous aurez probablement le même réflexe pour tout autre type de structure de données séquentielles : vous aurez tendance à l’afficher sous forme de séquence dans l’interface, peut-être comme une liste. Et pourtant, un autre format d’affichage aurait peut-être été plus pertinent et facile d’utilisation pour les utilisateurs, par exemple sous forme d’une série de phrases, d’un graphique ou d’une autre représentation visuelle.

Un autre défi est votre niveau d’expertise. Comme vous souhaitez que votre application soit extraordinaire, vous allez probablement vous documenter sur le sujet pour la concevoir. En fin de compte, vous n’allez pas seulement connaître votre application sur le bout des doigts, vous allez également devenir un expert dans le domaine lui-même. Un grand nombre de vos utilisateurs n’auront pas ce niveau d’expertise — ou n’en auront pas besoin. Ils pourraient être perdus par le niveau de détail de certaines fonctionnalités ou ne pas être familiers avec des termes inconnus des profanes.

Alors, que pouvez-vous faire pour arranger cela ?

Observez les utilisateurs. Vraiment

Bon, pour observer comment les gens utilisent votre application, vous pouvez faire appel à une société de conseil en ergonomie ; cette société va alors recruter des volontaires avec des profils différents au sein d’un vivier de plusieurs milliers de testeurs, elle va mettre au point une grille d’entretien, louer une salle dédiée aux tests d’ergonomie qui comprendra un dispositif pour enregistrer ce qui se passe sur l’écran et une caméra pointée vers le testeur, et vous serez derrière une vitre sans tain, dans une salle d’observation, à vous taper la tête contre les murs et à jurer à chaque fois que l’utilisateur fait quelque chose qui, selon vous, n’a aucun sens. Si vous avez les moyens de le faire, alors n’hésitez pas, foncez. Ce que vous y apprendrez vous permettra de complètement changer votre point de vue. Si vous n’avez pas les moyens de recourir à une procédure de test professionnelle, tout n’est pas perdu ; vous allez juste devoir le faire par vous-même. Asseyez-vous derrière un utilisateur pendant qu’il vous montre comment il effectue ses tâches et les intègre à son mode de travail. Soyez un observateur silencieux : votre but est d’observer et de noter tout ce qui se passe. Beaucoup de choses vont vous surprendre. Une fois que l’utilisateur a terminé, vous pouvez relire vos notes et lui poser des questions afin de mieux comprendre comment il fonctionne.

Pour vous aider à conduire ces tests vous-même, il existe d’excellents ouvrages : Don’t Make Me Think: A Common Sense Approach to Web Usability [NdT: Traduit en français : Je ne veux pas chercher: Optimisez la navigation de vos sites et menez vos internautes à bon port, écrit par Steve Krug, About Face 3: The Essentials of Interaction Design, d’Alan Cooper, Robert Reimann et David Cronin, et le projet OpenUsability. Être observé peut être un peu intimidant pour les utilisateurs, mais je parie qu’ils seront nombreux à se porter volontaires pour vous aider à améliorer votre application. Les utilisateurs qui ne peuvent pas contribuer au code sont généralement heureux de trouver d’autres façons de contribuer au logiciel libre : vous montrer comment ils utilisent le logiciel est une manière simple de le faire. Les utilisateurs sont reconnaissants du temps que vous avez donné pour développer le logiciel et veulent vous rendre la pareille.

Vous devrez garder un esprit critique et ne pas forcément accepter toutes les modifications demandées par vos utilisateurs. Écoutez attentivement leurs histoires : elles vous donneront l’occasion d’identifier des problèmes. Mais ce n’est pas parce qu’un utilisateur réclame une fonctionnalité qu’il en a absolument besoin ; peut-être que le meilleur moyen de résoudre le problème sous-jacent est de mettre en place une fonctionnalité complètement différente. Gardez du recul par rapport aux commentaires de vos utilisateurs. Mais cela, vous le saviez probablement déjà.

Et au passage, ne faites pas non plus appel à votre famille.

Je ne dis pas ça méchamment, je suis sûr que vos parents, frères et sœurs sont des gens très bien. Mais si vous créez une application comptable et que votre sœur n’a jamais tenu la moindre comptabilité, elle sera sans doute perdue. Vous perdrez plus de temps à lui expliquer ce qu’est la comptabilité en partie double qu’à tester votre logiciel. Par contre, votre mère, qui s’est acheté un appareil photo numérique l’année dernière, pourrait être un cobaye idéal si vous travaillez sur une application de gestion de photos numériques ou d’envoi sur un site de partage en ligne populaire. Pour votre application de comptabilité, il vaut mieux demander à l’un de vos collègues ou amis qui a déjà quelques notions de comptabilité.

Variez vos cobayes

Pour des raisons qui resteront éternellement mystérieuses, les gens trouveront toujours d’innombrables façons d’utiliser et de maltraiter votre application. Ils trouveront des manières de la casser que vous n’auriez même pas imaginées dans vos pires cauchemars. Certains mettront en place des processus et des méthodes de travail avec votre application qui n’ont absolument aucun sens à vos yeux. Et, de désespoir, vous vous cognerez la tête contre les murs. D’autres utiliseront votre application avec tellement d’intelligence que vous vous en sentirez idiot. Essayez de rencontrer des gens qui utilisent votre application avec des objectifs différents.

Les utilisateurs sont de drôles d’oiseaux. Mais ils sont de votre côté. Apprenez d’eux.

Si vous ne retenez rien d’autre…

… alors retenez ceci :

• Vous serez tenté de modeler l’apparence et le comportement de votre interface sur la façon dont le logiciel fonctionne en coulisses. Vos utilisateurs peuvent vous aider à éviter ce piège.
• Les utilisateurs sont des oiseaux capricieux. Ils vont casser, maltraiter et optimiser votre application à un point que vous ne pouvez pas même pas imaginer.
• Apprenez de vos utilisateurs. Améliorez votre application en fonction de ce que vous avez appris. Vous avez tout à y gagner.

Gabriella Coleman est une anthropologiste spécialisée dans la « culture hacker ». Elle a ainsi récemment publié le très remarqué livre Coding Freedom: The Ethics and Aesthetics of Hacking (PDF intégral Creative Commons Ny-Nc-Nd).

Elle nous livre ici le fruit de sa réflexion suite à la triste disparition d’Aaron Swartz.

Puisque le code devient pouvoir et que les geeks maîtrisent le code, on assiste en effet à l’émergence d’un nouveau mouvement…

Les geeks sont les nouveaux défenseurs des libertés publiques

Geeks are the New Guardians of Our Civil Liberties

Gabriella Coleman - 4 février 2013 - MIT Technology Review
(Traduction : Moosh, lamessen, heapoverflow, Sky, Pouhiou, KoS, monsieurab, Slystone, goofy, yazid, isinocin, axellemag1, zak, Penguin, Nodel, Vilrax + anonymes)

Les Geeks sont les nouveaux défenseurs des libertés publiques (NdT : « Civil Liberties », que l’on pourrait aussi traduire par libertés individuelles voire citoyenneté).

Des évènements récents ont mis en évidence le fait que les hackers, les développeurs et les geeks sont porteurs d’une culture politique dynamique.

Plus d’une décennie d’étude anthropologique dans leur milieu, a forgé ma conviction, que les hackers ont construit un très dynamique mouvement de défense des libertés individuelles et publiques. C’est une culture engagée à libérer l’information, sans contrôle excessif et sans surveillance par les gouvernements et les partenaires privés, à insister sur le droit au respect de la vie privée, et à combattre la censure, produisant un effet d’entraînement sans précédent pour la vie politique. Et 2012 a été à ce sujet une année faste.

Avant que je ne développe, il serait bon d’expliquer brièvement le mot « hacker ». C’est une source de débats, même parmi les hackers. Par exemple d’un point de vue technique : un hacker peut programmer, administrer un réseau, bidouiller, réparer et améliorer du matériel et logiciel. D’un point de vue éthique et politique, cette diversité est tout aussi grande. Certains hackers font partie d’une tradition de la transgression et du non respect des lois ; leurs activités sont opaques et indétectables. D’autres hackers sont fiers d’écrire des logiciels open source, libre d’accès et transparents. Alors que certains restent loin de toute activité politique, un nombre croissant d’entre eux se lève pour défendre leur autonomie productive ; ou s’engage plus largement dans des luttes pour la justice sociale et les Droits de l’Homme.

Malgré leurs différences, certains sites web et certaines conférences rassemblent les divers clans de hackers. Comme tout mouvement politique, il y a des divergences internes mais, si les bonnes conditions sont réunies, des individus aux aptitudes distinctes travailleront à l’unisson pour une même cause.

Prenons par exemple la réaction à l’encontre de la loi Stop Online Piracy Act (SOPA), un projet de loi de grand envergure sur le droit d’auteur visant à réduire le piratage en ligne. SOPA a été stoppée avant qu’elle ne puisse être adoptée, et cela, grâce à une réaction massive et élaborée de la dissidence, menée par le mouvement des hackers.

L’élément central a été une journée de boycott dite « Blackout Day », sans précédent à l’échelle du web. Pour exprimer leur opposition à la loi, le 17 janvier 2012, des organisations à but non-lucratifs, quelques grandes entreprises du web, des groupes d’intérêts publics et des milliers d’individus ont décidé de rendre momentanément leurs sites non accessibles ; des centaines d’autres citoyens ont appelé ou envoyé des courriels aux représentants politiques. Les journalistes ont par la suite beaucoup écrit sur le sujet. Moins d’une semaine plus tard, après ces évènements spectaculaires, le projet SOPA et le projet PIPA, son pendant au Sénat, ont été suspendus.

La victoire repose sur le soutien très large des hackers et des geeks. La participation de très grandes entreprises, comme Google, de personnalités reconnues du monde numérique, comme Jimmy Wales, et de l’organisation de défense des libertés individuelles Electronic Frontier Foundation (EFF) ont été cruciales au succès de l’action. Toutefois, la présence et le soutien constant et indéfectible des hackers et des geeks, fut palpable, y incluant bien sûr Anonymous. Depuis 2008 les activistes se sont ralliés sous cette bannière pour organiser des manifestations ciblées, faire connaître diverses malversations, organiser des fuites de données sensibles, s’engager dans l’action-directe numérique et fournir une assistance technique pour les mouvements révolutionnaires.

Durant la protestation contre SOPA, les Anonymous ont publié des vidéos et des posters de propagande, tout en faisant régulièrement le point de la situation sur plusieurs comptes Twitter, dont Anonymous News, qui dispose d’un contingent important de followers. À la fin du blackout, les compagnies s’éloignèrent naturellement du feu des projecteurs, et se remirent au travail. La lutte pour les droits numériques continua, cependant, avec les Anonymous et les autres activistes.

En réalité , le jour suivant, le 18 janvier 2012, les autorités fédérales orchestrèrent le démantèlement du populaire site de partage de fichiers Megaupload. Kim Dotcom, le sympathique et controversé fondateur de la compagnie fut aussi arrêté dans un spectaculaire raid matinal en Nouvelle Zélande. Le retrait de ce site populaire ne présageait rien de bon pour les Anonymous : il semblait confirmer que si les décrets tels que SOPA devenaient des lois, la censure deviendrait inévitable et commune sur Internet. Bien qu’aucune cour n’ait jugé Kim Dotcom coupable de « piratage», ses possessions sont toujours confisquées et son site web banni d’Internet.

Dès que la nouvelle fut connue, les Anonymous coordonnèrent leur plus grande campagne d’attaques par déni de service (DDOS) à ce jour. Elle mit à mal de nombreux sites web, incluant la page d’accueil d’Universal Music, le FBI, le bureau américain des copyrights (U.S Copyright Office), l’association américaine de l’industrie du disque (Recording Industry Association of America, RIAA) et l’association américaine du cinéma (Motion Picture Association of America, MPAA).

Quelques semaine plus tard, en Europe, les Anonymous firent encore parler d’eux, à l’occasion de mouvements de protestation massifs en-ligne et hors-ligne contre ACTA, autre accord international sur le copyright, particulièrement au Danemark et en Pologne (voir Europeans Protest Anti-Piracy Treaty). Après que le gouvernement Polonais fut d’avis de ratifier ACTA, les Anonymous mirent hors-service quelques uns de ses sites officiels, et médiatisèrent les manifestations publiques à Cracovie notamment. Peu de temps après, les députés du parti polonais de gauche, le mouvement Palikot, siégèrent en portant le masque de Guy Fawkes, symbole des Anonymous, en signe de protestation contre ACTA. L’Union européenne a abandonné la proposition de loi en juillet 2012.

Anonymous s’est révélé être un acteur si important durant ces événements que quelque temps après, j’ai reçu un coup de téléphone d’un investisseur en capital-risque impliqué dans l’organisation des protestations anti-SOPA. Il voulait savoir comment Anonymous opérait et si ses membres pouvaient être mis à contribution de façon plus directe. Ce qui est beau et frustrant à la fois dans le fonctionnement d’Anonymous est l’absence d’organisation et le caractère imprévisible des actions de ses membres. Comme ils aiment à le dire, « Nous ne sommes pas votre armée personnelle ». Mais son intuition qu’ils ont joué un rôle important dans cette histoire était bonne.

L’une des clés du succès de Anonymous réside dans sa nature participative, surtout quand on le compare au monde des hackers où agir demande des compétences techniques (et souvent une réputation). Des hackers doués sont en effet indispensables pour le réseau des Anonymous, ils mettent en place l’infrastructure de communication et décrochent la plupart des gros titres, par exemple quand ils s’introduisent dans des serveurs pour chercher des informations sur la corruption publique ou dans des entreprises. Mais le hacking n’en reste pas moins un outil parmi d’autres (et certains sous-groupes des Anonymous s’opposent au hacking et au défacement). Il y a d’autres choses à faire : des communiqués de presse percutants, des posters à dessiner, des vidéos à éditer. Les geeks et les hackers ont peut-être des compétences différentes, mais ils sont souvent compagnons de voyage sur internet, ils dévorent les mêmes journaux, ils suivent les mêmes cultures geek et ils défendent les libertés numériques même s’ils utilisent des méthodes et des organisations différentes.

L’importance, l’influence, et surtout la diversité de ce mouvement politique geek m’est apparu très récemment. Non pas à l’occasion d’un évènement politique officiel, mais au moment d’une commémoration doublé d’une réunion politique informelle. Plus d’un millier de personnes se sont rassemblées dans le majestueux Cooper Union Hall à New York pour honorer la mémoire d’Aaron Swartz, un hacker et activiste autoproclamé qui s’est suicidé récemment, en raison, selon certains, d’une ingérence du gouvernement dans son procès en rapport avec le téléchargement illégal de millions d’articles universitaires depuis le site de la bibliothèque du MIT (voir l’article « Why Aaron Swartz’s Ideas Matter »).

Ils parlèrent de la vie d’Aaron, de sa forte personnalité, et surtout de ses succès politiques et de ses désirs. Tout comme ses semblables, il détestait la censure, et avait donc naturellement rejoint le combat contre SOPA. Pendant la commémoration, on put entendre des extraits de son célèbre discours à la conférence Freedom to Connect en 2012, quand Swartz affirma que « SOPA a vraiment été stoppé par les gens eux-mêmes ». Il avait joué un rôle clé pour plusieurs raisons notamment en fondant l’association Demand Progress, une association à but non lucratif qui a participé à canaliser le mécontentement des citoyens à travers des pétitions et des campagnes contre SOPA.

Contrairement aux Anonymous qui n’ont pas de mission unique, d’adresse physique, ou de porte-parole officiel, Demand Progress est un organisme ayant un bureau de direction au cœur du pouvoir politique, à Washington. Néanmoins il canalise, de manière assez efficace, des initiatives de la base en faveur de la protection des libertés civiles, un groupe modéré qui peut coordonner des actions avec patience et précision.

De toute évidence, les geeks et les hackers en tout genre font usage d’une large variété de tactiques et de moyens d’expression politique. Demand Progress, ainsi que l’émergence du Parti Pirate en Europe, montrent la volonté des geeks et des hackers de s’exprimer et de travailler au sein des institutions en place. Tous les signes montrent qu’ils ont de plus en plus souvent recours à des modes d’expression politique plus traditionnels. Cependant cela va probablement coexister avec des actes plus ou moins organisés de désobéissance, de défi et de protestations qui sont également devenus plus fréquents et visibles ces dernières années, en grande partie grâce à Anonymous.

Mais en ce samedi après-midi, les différences ont été mises de côté au profit d’une posture unitaire, en commémoration, et avec la conviction que la bataille pour la préservation des libertés publiques individuelles n’en était qu’à ses débuts.

Crédit photo : Frédéric Bisson (Creative Commons By)

Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framalang : peupleLà, SaSha_01, lerouge, Kalupa, lenod, michel, KoS, michel, goofy, HanX, Asta, lamessenJulius22

Mon projet m’a appris à grandir

Runa Bhattacharjee

Depuis 10 ans, Runa Bhattacharjee a traduit et travaillé à la localisation(1) de nombreux projets open source — des interfaces de bureau aux outils de systèmes d’exploitation en passant par beaucoup de choses entre les deux. Elle croit fermement que les dépôts de codes en amont sont les meilleurs endroits pour soumettre toutes les modifications possibles. Elle gère également un portefeuille professionnel spécialisé dans la localisation chez RedHat. Runa traduit et maintient des traductions en Bengali (version indienne) mais est toujours heureuse d’aider quiconque débute dans la localisation.

Introduction

Carburer tard dans la nuit est l’une des formes de rébellion préférée des jeunes partout dans le monde. Que ce soit pour lire un livre avec une lampe de poche sous les couvertures, regarder les rediffusions TV ou (entre autres choses) traîner sur un canal IRC et s’acharner sur un problème agaçant dans son projet open source favori.

Comment tout a commencé

Voici comment tout a commencé pour moi. Permettez-moi d’abord d’écrire quelques lignes sur ma personne. Lorsque j’ai été présentée au groupe d’utilisateurs de Linux de ma ville, je partageais ma vie entre des emplois et mes études de master. Très vite, j’étais devenue contributrice sur quelques projets de localisation et j’avais commencé à traduire des interfaces de bureau (principalement). Nous utilisions des éditeurs de texte personnalisés avec des systèmes intégrés pour l’écriture et les polices. Les moteurs de rendu n’étaient pas assez matures pour afficher le scénario sans erreur sur les interfaces. Mais, malgré tout, nous continuions à traduire. Je me concentrais sur la méthode de travail que j’avais créée pour mon usage. Je récupérais le contenu à traduire des personnes qui savaient comment les choses fonctionnaient, je le traduisais du mieux que je pouvais, j’ajoutais des commentaires pour aider les réviseurs à comprendre comment j’avais appréhendé le texte, je renseignais les informations requises pour les copyrights et les crédits, puis je renvoyais tout ça aux coordinateurs.

Comment je faisais

C’était avant tout une manière simple de faire les choses. Mais, surtout, c’était ma manière à moi de les faire. Je prenais le temps de planifier mon travail sur les traductions. Celles-ci étaient ensuite révisées avant de m’être retournées pour modification. De nouveau, je planifiais quand je pourrais les reprendre en fonction de mon temps libre disponible entre les études et le travail. Lorsque je me mettais finalement au boulot, je m’asseyais pour neuf à dix heures d’un coup, en général jusqu’à l’heure où blanchit la campagne, ressentant alors un grand sentiment d’accomplissement, jusqu’à la fois suivante.

Ce qui comptait

Ce que je ne savais pas, c’est que je jouais un rôle crucial sur un plan plus global. À savoir, la planification des releases(2). Donc, quand j’achevais mes modestes contributions et les envoyais aux autres, je ne prenais pas en compte leur possible inutilité du fait qu’elles arrivaient trop tard pour la version en cours et trop tôt pour la suivante (qui inclurait forcément de nombreux changements qui obligeraient à se remettre au travail). Au-delà de ça, je n’avais aucune idée de l’importance que ça prenait dans le processus de release : intégration, création de paquetages, tests de l’interface, suivi et résolution des bogues.

Comment cela m’a fait grandir

Tout cela a changé radicalement quand je me suis tournée vers un rôle plus professionnel. Subitement, je faisais la même chose mais d’une manière plus structurée. J’ai appris que faire cavalier seul comme j’en avais pris l’habitude n’était pas adapté quand on devait jongler avec deux ou trois versions planifiées. Il fallait être méticuleusement synchronisé avec les feuilles de route des projets. En travaillant sur une traduction d’interface de bureau, je devais aussi vérifier que le calendrier de traduction concordait avec celui du projet principal.

Les travaux devaient idéalement commencer immédiatement après le gel de tous les messages d’origine de l’interface. Les traducteurs pouvaient alors travailler librement jusqu’à l’échéance de la période de traduction, après quoi ils pouvaient marquer la traduction comme stable dans le dépôt principal et, finalement, les paquetages pouvaient être générés. De plus, quelques distributions de systèmes d’exploitation se synchronisaient sur ce calendrier. Les traducteurs avaient donc la responsabilité supplémentaire de s’assurer que les pré-versions des systèmes d’exploitation embarquant ce bureau seraient un minimum testées afin de s’assurer que les traductions de l’interface avaient du sens et ne contenaient pas d’erreur.

Ce que j’aurais dû savoir

La transition ne fut pas aisée. Je fus soudain inondée par un flot d’informations que je devais gérer et par des tâches supplémentaires que je devais réaliser. Ce qui était au départ un passe-temps et plus important encore un anti-stress est devenu tout à coup une affaire sérieuse. En y repensant, je peux dire que cela m’a probablement aidée à comprendre le processus dans son intégralité étant donné que j’ai dû tout apprendre depuis le début. Ainsi armée de cette connaissance, je peux analyser des situations avec une meilleure compréhension de toutes leurs dimensions. Au moment où j’ai commencé à travailler sur les projets open source qui m’intéressaient, il y avait beaucoup moins de professionnels qui travaillaient à plein temps dans ce domaine. La plupart des contributeurs bénévoles travaillaient ailleurs la journée et voyaient ces projets comme un moyen d’alimenter les idées créatives qui s’étiolaient dans leurs tâches quotidiennes. Donc, beaucoup de nouveaux arrivants n’étaient jamais guidés vers une manière plus professionnelle d’organiser leurs projets. Ils ont grandi pour devenir merveilleusement doués dans ce qu’ils faisaient et ont finalement compris comment ils aimeraient équilibrer leur travail avec le reste de leurs activités.

Conclusion

Aujourd’hui, j’encadre les nouveaux arrivants et l’une des premières choses que je leur fais comprendre est comment et dans quelle partie du projet leur travail aura un impact. Élaborer un modèle de travail personnel est essentiel car cela permet de se construire un environnement où il est agréable de travailler. Cependant, avoir conscience de la structure qui est affectée par le travail inculque la discipline nécessaire pour pouvoir tenir bon face aux caprices.

(1) La localisation englobe tout le processus d’adaptation d’un produit logiciel ou documentaire à une région donnée. Cela comprend la traduction dans la langue de la région mais aussi l’adaptation aux normes, à la culture et aux besoins spécifiques de cette région du monde.

(2) Il s’agit de la publication d’un logiciel, sa mise à la disposition du public.

C’était mieux avant ?

Tom Morris souhaite juste lire un article de presse. Sauf que la procédure pour y arriver n’est pas la même selon qu’il se trouve sur bon vieil ordinateur ou sur son clinquant smartphone (ici un iPhone).

Alors Tom Morris en a marre et nous le dit sur son blog dans un style qui ne fait pas dans la dentelle !

Non, je ne vais pas télécharger ton appli de merde

No, I’m not going to download your bullshit app

Tom Morris - 2 février 2013 - Blog personnel
(Traduction : Pouhiou, ehsavoie, Lapinosor + anonymes)

Comment lisions-nous les informations à l’époque du Web :

1. Aller sur le site du journal.
2. Cliquer sur l’article.
3. Lire.

Voici comment nous lisons les informations à l’ère des saloperies d’applications iPhones inutiles :

1. Aller sur le site web.
2. Être informé que vous n’êtes pas autorisé à lire le site web.
3. Être redirigé vers un App Store.
4. Télécharger l’application.
5. Attendre tandis qu’un fichier de plusieurs megaoctets se télécharge sur votre capricieuse et onéreuse connexion 3G.
6. Ouvrir l’application.
7. Se familiariser avec une interface dont les touches sont d’une intuitivité obscure qui ne nous a pas été dévoilée et d’une utilisation subtilement différente des autres applications similaires.
8. Lutter contre l’indicateur d’état mal implémenté d’une roue dentée de chargement (sur iOS) ou une barre de progression clignotante (sur Android) parce que vous avez eu l’audace d’utiliser votre appareil mobile sur une connexion lente ou incertaine.
9. Tenter de trouver l’article que vous souhaitiez lire dans une mise en page et une architecture informationnelle qui sont totalement différentes de la mise en page et de l’architecture informationnelle du site web auquel vous vous êtes habitué, parce qu’un enfoiré a décidé que lire l’équivalent électronique d’un journal doit être une « rupture technologique » (car il a lu bien trop de Seth Godin^[1] et autres foutaises).
10. Réaliser que l’application ne vous montre pas la même chose en mode paysage ou portrait. À vous les joies de passer pour un gros obsédé dans le métro en tournant votre iPad dans tous les sens pour mieux zoomer sur la pin-up de la page 3.
11. Ne pas être capable de partager avec vos amis parce que ce n est pas une page web avec une URI. Parce que pourquoi avoir besoin d’URI quand vous avez de beaux et brillants boutons sur votre téléphone?
12. Perdre du temps pour télécharger les fichiers binaires à la prochaine mise a jour (automatique) de l’application sur l’App Store, afin que vous ayez cette « nouvelle fonctionnalité », même s’il n’y a aucune putain de fonctionnalité qui vous intéresse, si ce n’est de pouvoir (enfin) lire ces putains d’articles.
13. Si vous utilisez Android, installez d’abord un logiciel anti pub au cas où l’application s’installerait avec quelques délicieuses pubs qui s’introduisent dans vos données personnelles.
14. Abandonner, aller au kiosque le plus proche, acheter la version papier, balancer son smartphone depuis la falaise la plus proche et démarrer une campagne de dénigrement contre tous les idiots qui pensent que mettre l’info dans une application mobile est une bonne idée.

Dans la guerre « Web contre Applications mobiles » (NdT : web vs. apps), je pense que vous pouvez aisément deviner de quel côté je suis.

Je ne voudrais pas télécharger une application de la BBC ou de la NPR (National Public Radio) pour mon ordinateur. Pourquoi en voudrais-je une sur mon téléphone ? Dois-je acheter un nouveau poste de radio à chaque fois que je veux écouter une nouvelle station ? Non. La fonctionnalité est la même, la seule chose qui diffère, c’est le contenu.

Les applications mobiles doivent fournir une fonctionnalité réelle, et pas seulement des bouts de contenu encapsulés dans des fichiers binaires.

Crédit photo : Daniel Hennemand (Creative Commons By)

Cette décennie est et sera marquée par le développement tous azimut du matériel libre.

Sera-t-on à terme capable de réellement modifier la donne dans le secteur industriel ?

Difficile à dire aujourd’hui mais rien n’empêche d’essayer, d’explorer, de bidouiller, même dans les secteurs les plus fous comme l’aviation…

MakerPlane : L’open source prend son envol dans l’aviation

MakerPlane: Open source takes flight in aviation

Ted Brunell - 7 janvier 2013 - OpenSourceWay
(Traduction : tibs, Kenoris, RavageJo, KoS, ehsavoie, goofy, lamessen + anonymous)

J’ai parlé avec John Nicol du projet MakerPlane à propos de leur équipe passionnée de contributeurs des quatres coins du monde qui conçoivent et construisent un ULM biplace complet. Leur objectif est de « créer des avions innovants et de changer la donne dans l’avionique et ses systèmes connexes ainsi que dans les procédés de fabrication ».

Quand avez vous entendu parler de l’open source pour la première fois, et qu’est-ce qui vous a le plus impressionné à propos de celui-ci ?

J’ai évolué dans l’industrie de haute technologie depuis plus de 20 ans, à des postes différents, comme vice-président de la branche ingénierie d’une entreprise cotée au NASDAQ à Fremont (Californie), et PDG de mes propres entreprises en Nouvelle-Zélande et au Canada. J’ai donc été confronté à l’open source depuis un certain temps. J’ai utilisé et développé des logiciels et ressources open source tout au long de ma carrière et je continue à le faire pour un autre projet que je mène actuellement (je ne veux pas vendre la mèche, mais j’espère pouvoir publier des logiciels de modélisation 3D open source l’année prochaine).

Ce qui m’impressionne le plus, c’est qu’une communauté intéressée peut grandir et stimuler l’innovation de manière exponentielle. Elle peut devenir autonome et, dans de bonnes conditions, peut être très prolifique. Ce que je veux dire, c’est que de nouveaux développeurs motivés peuvent toujours prendre le relais et apporter de la fraîcheur au logiciel ou au système en cours de développement. Bien sûr, la communauté est la clé de ce genre de projet et c’est là que tout se joue : l’open source peut survivre en dehors des entreprises et sans la présence de personnalités.

Les principes de l’open source sont désormais tout aussi bien ancrés dans le domaine matériel, et j’ai récemment présenté MakerPlane à l’Open Source Hardware Summit (NdT : Sommet du matériel libre) à New York.

Comment est utilisé l’open source dans le projet MakerPlane ?

Pour résumer, nous fournissons du matériel open source et le logiciel dirigeant l’avion « fait maison ». Ce logiciel est toujours en cours de développement, mais il contiendra un système de visualisation électronique (EFIS), qui est une sorte d’ordinateur de bord qui affiche des informations sur le vol et les moteurs. Il contient également des micrologiciels pour des périphériques comme Android et Arduino.

Le matériel se trouve dans deux domaines principaux : l’avionique et l’avion. Les instruments de bord et l’électronique à l’intérieur de l’avion constituent l’avionique. A ce jour, nous avons 24 plans de matériel avionique open source disponibles en téléchargement dans nos dépôts, pour que tout le monde puisse les construire. La gamme de projets s’élargit en permanence. Pour ce qui est des avions, nous sommes en train de concevoir et de construire notre premier ULM open source (un ULM biplace grandeur nature). Nous cherchons à améliorer le design pour qu’il puisse être construit à la maison, grâce à des machines à commande numérique ou des imprimantes 3D. Avec la démocratisation de celles-ci, et la vague du « fait maison », on profite à la fois de la technologie et du matériel de construction à bas prix, indispensables à ceux qui veulent construire leur propre avion.

Les chiffres que nous avons indiquent que 75% des projets de construction d’avion en kit ou à partir de plans sont abandonnés avant d’être terminés. Les entreprises aéronautiques qui fournissent des kits ou des plans font faillite, laissant à l’abandon de nombreux projets. Notre but est de rassembler le plus possible de plans d’avions open source, avec des notices semblables à celles d’IKEA pour les assembler (enfin, en espérant qu’elles soient plus facile à comprendre que celles d’IKEA !). Ces plans, étant open source, seraient disponibles pour quiconque voudrait y accéder, et pourraient survivre aux fondateurs de MakerPlane.

Les gens ont tendance à s’inquiéter quand je parle d’avion open source. Leur principale préoccupation est le fait que n’importe qui peut venir modifier les plans, les rendant du même coup dangereux. Mais un ingénieur en aéronautique est responsable des plans. Comme pour un logiciel open source, il surveille les modifications et aucune ne sera appliquée sans son accord. Bien sûr, tout le monde peut modifier et personnaliser l’avion à sa convenance, et c’est une des principales qualités de l’open source. Cependant, dans 99% des pays, tout avion doit normalement être inspecté par les autorités aériennes ou leurs représentants, avant de recevoir l’autorisation de décoller. Aux Etats-Unis, c’est le rôle de la Federal Aviation Administration (FAA) (Administration Fédérale de l’Aviation). Ces règles sont élaborées pour assurer la sécurité des pilotes, des passagers, et des populations au sol. Vous devez aussi avoir un brevet de pilote, particulièrement pour la catégorie des avions que nous concevons et fabriquons.

Quels sont les défis avec le projet ?

Le financement est le plus gros défi, comme pour la plupart des sociétés à initiatives open source ! De nombreuses personnes n’imaginent sans doute pas qu’un nombre important de projets open source sont financés par des grosses sociétés. La base des mouvements open source semble être toujours sous-financée et nous ne faisons pas exception. La dimension supplémentaire avec nous, c’est que nous avons besoin d’acheter beaucoup de matériel et d’équipements pour arriver à construire un avion. Nous sommes conscients que pour demander des dons et continuer, nous devons faire des progrès et faire voler l’avion. Or nous ne pouvons pas l’envoyer dans les airs sans argent pour acheter les fournitures, c’est donc en quelque sorte un cercle vicieux.

Les modèles commerciaux pour soutenir les initiatives open source sont de fournir des produits et/ou services qui gravitent autour du produit open source libre. Pour aider à financer notre projet nous avons donc ouvert une boutique en ligne et nous y vendons des pièces et des kits pour l’avionique et finalement pour l’avion. Pour le moment l’ensemble de l’entreprise est financé par mes propres économies et cartes de crédits, c’est comme ça. Cela signifie que la progression est plus lente que je le voudrais étant donné que je ne peux malheureusement pas sortir et acheter les pièces quand je le veux. Je voudrais plus que tout avoir une plus grosse machine à commande numérique et une imprimante 3D, mais nous faisons avec ce que j’ai actuellement. Si nous avions le financement, nous aurions sans doute beaucoup plus avancé.

Quel sera selon vous l’impact de MakerPlane sur le monde ?

L’utilisation de technologies de fabrication à domicile change la façon dont les gens font des choses et la vitesse à laquelle ils le font. Une bonne machine-outil à commande numérique peut être faite ou assemblée à partir de kit pour quelques milliers de dollars et une personne peu qualifiée peut utiliser une machine à commande numérique ou une imprimante 3D pour produire quelques objets très précis et le faire de nombreuses fois. Au lieu de prendre une paire d’années pour faire des pièces d’avion, je devrais être capable de découper les pièces en quelques jours, les assembler et terminer avec un avion complet. Je ne veux plus avoir à faire expédier des pièces par un fabriquant ou un distributeur. Je veux pouvoir faire mes propres kits comme j’en ai besoin. J’aurais juste besoin de télécharger un fichier, charger les matériaux dans la machine et les couper. Les méthodes que nous explorons pour assembler l’avion comprennent des fentes et des languettes, ce qui permet aux pièces de ne se monter que dans un sens et sont auto-équerrés. Il est à espérer que de nombreuses techniques permettant de gagner du temps que nous avons appris grâce à MakerPlane trouveront leur place chez les grands constructeurs d’avions en kit.

Comment peut-on s’impliquer dans MakerPlane ?

Il y a plusieurs manière pour les gens de contribuer à notre ambition de changer le monde de l’aviation ! Voici quelques idées :

• Rejoignez le forum MakerPlane et participez aux discussions. Dites-nous quelles sont vos compétences et même si vous ne pouvez pas contribuer directement de façon technique, dites simplement « Salut » et dites nous ce que vous aimez ou n’aimez pas sur les designs.

• Reprenez un projet open source déjà disponible dans le dépôt. De très bons projets ont déjà été envoyés, mais beaucoup ont encore besoin de TLC, de mises à jour, et d’une documentation plus aboutie.

• Commencez un nouveau projet ! Si vous avez une idée géniale pour quelque chose en rapport avec l’aviation open source et quelques compétences pour l’implémenter, ouvrez un nouveau projet sur le dépôt et allez-y ! Si vous avez déjà du code, ou du matériel que vous avez conçu et construit, alors nous serions ravis de le voir dans le dépôt également.

• Parlez de MakerPlane à vos amis, qu’ils soient pilotes ou pas. Aimez notre page Facebook, suivez-nous sur Twitter, partagez, envoyez des courriels, ou des vraies lettres ! Faites passer le mot, pour que nous puissions vraiment construire notre communauté.

• Nous acceptons avec gratitude des dons de pièces détachées, de ressources, et/ou d’argent. Et nous sommes toujours à la recherche de sponsors. Merci beaucoup pour votre aide !

Quel est votre utilisation de l’open source en dehors de votre projet ?

J’utilise quotidiennement OpenOffice pour le travail et Inkscape, Gimp, et Blender de façon plus occasionnelle. J’ai de l’expérience en électronique, donc je m’amuse avec du matériel Arduino open source, et mon téléphone et ma tablette sont bien entendus sous Android. L’open source est partout dans ma vie !

Voir cette vidéo illustrant les étapes de la création d’un prototype de MakerPlane.

En novembre dernier, Richard Stallman faisait paraître dans le magazine Wired un article important sur l’épineuse et dangereuse question des brevets logiciels (ou plutôt « brevets sur des idées informatiques » comme nous le verrons ci-après).

Un article que nous nous sommes empressés de traduire via notre circuit, désormais classique, compte Twitter + Framapad, et qui a été relu et corrigé par la liste « trad-gnu » de l’April.

Protéger le secteur du logiciel des brevets

Giving the Software Field Protection from Patents

Richard Stallman - version du 02 février 2013 - Gnu.org (CC BY-ND)
(Traduction Framalang : satbadkd, Thérèse, DarthMickey, geecko, Marc, igor, EEva, greygjhart)

Une première version de cet article a été publiée sur Wired en novembre 2012.

Les brevets menacent chaque concepteur de logiciel, et les guerres de brevet que nous avons longtemps craintes ont éclaté. Les développeurs et les utilisateurs – soit, dans notre société, la plupart des gens – ont besoin de logiciels libres de tout brevet.

Les brevets qui nous menacent sont souvent appelés « brevets logiciels », mais ce terme est trompeur. Ces brevets ne concernent aucun programme en particulier. En fait, chaque brevet décrit une idée applicable en pratique, et affirme que quiconque utilise cette idée peut être poursuivi en justice. Il est donc plus clair de les appeler « brevets sur des idées informatiques », ou « brevets sur des algorithmes ».

Le système de brevets américain ne différencie pas les « brevets logiciels » des autres. Seuls les développeurs font la distinction entre les brevets qui nous menacent – ceux qui concernent des idées pouvant être implémentées dans des logiciels – et les autres. Par exemple : si l’idée brevetée est la forme d’une structure physique ou une réaction chimique, aucun programme ne peut implémenter cette idée ; ce brevet ne menace pas le secteur du logiciel. Si par contre l’idée qui est brevetée est un algorithme, alors le canon de ce brevet est braqué sur les développeurs et les utilisateurs.

Cela ne veut pas dire que les brevets couvrant des algorithmes concernent seulement les logiciels. Ces idées peuvent être aussi implémentées dans du matériel… et beaucoup d’entre elles l’ont été. Chaque brevet couvre typiquement les implémentations matérielles et logicielles de l’idée.

Le problème particulier du logiciel

Toujours est-il que c’est dans le domaine du logiciel que les brevets sur des algorithmes posent un problème particulier. Il est facile de combiner des milliers d’idées dans un seul programme. Si 10% de ces idées sont brevetées, cela signifie que des centaines de brevets le menacent.

Quand Dan Ravicher, de la Public Patent Foundation (Fondation publique des brevets) a étudié en 2004 un programme de taille importante (Linux, qui est le noyau du système d’exploitation GNU/Linux), il a trouvé 283 brevets américains qui semblaient couvrir des algorithmes implémentés dans son code source. Cette année-là, on estimait la part de Linux dans le système GNU/Linux complet à 0,25%. En multipliant 300 par 400, on peut estimer que le nombre de brevets qui menacent le système dans son ensemble est de l’ordre de 100 000.

Si la moitié de ces brevets était supprimée pour cause de « mauvaise qualité » – c’est-à-dire pour cause de ratés du système de brevets – cela ne changerait pas grand chose. Que ce soit 100 000 ou 50 000 brevets, la catastrophe est la même. C’est pourquoi c’est une erreur de limiter nos critiques des brevets logiciels aux seuls patent trolls ou aux brevets de « mauvaise qualité ». En ce sens Apple, qui n’est pas un « troll » selon la définition habituelle, est actuellement l’entreprise la plus dangereuse quand elle se sert de ses brevets pour attaquer les autres. Je ne sais pas si les brevets d’Apple sont de « bonne qualité », mais plus la « qualité » du brevet est élevée, plus la menace est grande.

Nous devons corriger l’ensemble du problème, pas seulement une partie.

Pour corriger le problème sur le plan législatif, on suggère habituellement de changer les critères d’octroi des brevets – par exemple, d’interdire la délivrance de brevets sur les pratiques algorithmiques et les systèmes nécessaires à leur mise en œuvre. Mais cette approche a deux inconvénients.

Premièrement, les avocats reformulent les brevets de manière astucieuse pour qu’ils correspondent à toute règle applicable ; ils transforment toute tentative de limiter un brevet sur le fond en une simple exigence de forme. Par exemple, de nombreux brevets américains sur des algorithmes décrivent un système qui comprend une unité de traitement arithmétique, un séquenceur d’instruction, une mémoire ainsi que des contrôles pour mener à bien un calcul précis. C’est une manière assez particulière de décrire un programme tournant sur un ordinateur pour effectuer un certain calcul ; elle a été élaborée pour que la demande de brevet se conforme aux critères que, pendant quelques temps, l’on a cru être ceux du système américain de brevets.

Deuxièmement, les États-Unis ont déjà plusieurs milliers de brevets sur des algorithmes, et changer les critères pour empêcher d’en créer d’autres ne permettrait pas de se débarrasser de ceux qui existent. Il faudrait attendre pratiquement 20 ans avant que le problème ne soit entièrement résolu du fait de l’expiration des brevets. Et abolir les brevets existants par la loi est probablement anticonstitutionnel (de manière assez perverse, la Cour suprême a insisté pour que le Congrès puisse étendre les privilèges privés au détriment des droits du public mais ne puisse pas aller dans l’autre direction).

Une approche différente : limiter l’effet des brevets, pas la brevetabilité

Ma proposition est de changer l‘effet des brevets. Il faut inscrire dans la loi que développer, distribuer ou exécuter un programme sur des systèmes informatiques polyvalents ne constitue pas une violation de brevet. Cette approche a plusieurs avantages :

• elle n’impose pas de classer les brevets selon qu’ils sont logiciels ou non ;
• elle apporte aux développeurs ainsi qu’aux utilisateurs une protection contre les brevets sur des algorithmes, existants ou futurs ;
• les avocats spécialistes des brevets ne peuvent plus trouver d’échappatoire en changeant la formulation de leurs demandes.

Cette approche n’invalide pas entièrement les brevets existants sur des algorithmes, parce qu’ils continueront à s’appliquer aux implémentations utilisant du matériel dédié. C’est un avantage dans le sens que cela supprime un argument mettant en question la validité de cette proposition du point de vue législatif. Les États-Unis ont légiféré il y a quelques années afin d’immuniser les chirurgiens contre les procès en contrefaçon de brevet, de sorte que même si des procédures chirurgicales sont brevetées, les chirurgiens sont protégés. Cela fournit un précédent pour ce type de solution.

Les développeurs et les utilisateurs de logiciels ont besoin de protection contre les brevets. Cette proposition est la seule solution législative qui apporte une protection totale à tous. Nous pourrions ensuite retourner à notre monde de concurrence ou de coopération… sans craindre qu’un inconnu ne vienne balayer notre travail.

Voir également : Une réforme des brevets n’est pas suffisante

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

Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framalang : Nyx, lamessen, Sphinx, peupleLà, lerouge, Sky, Julius22, Astalaseven, Alpha, HgO, michel, Sputnik, goofy, HanX, KoS

Ne vous inquiétez pas, faites confiance

Shaun McCance

Shaun McCance est impliqué dans la documentation de GNOME depuis 2003 en tant que rédacteur, chef de la communauté et développeur d’outils. Il a passé la plupart de ce temps à se demander comment inciter davantage de personnes à écrire une documentation de meilleure qualité, avec un certain succès à long terme. Il propose son expérience de la documentation communautaire à travers sa société de conseil, Syllogist.

Alors que je m’apprêtais à écrire cet article, il s’est passé quelque chose d’énorme : GNOME 3 est sorti. C’était la première version majeure de GNOME depuis neuf ans. Tout était différent et toute la documentation existante devait être réécrite. Au même moment, nous changions notre façon de l’écrire. Nous avions jeté nos vieux manuels et étions repartis sur une nouvelle base, avec un système d’aide dynamique par sujet, en utilisant Mallard.

Quelques semaines avant la sortie, une partie d’entre nous s’est réunie pour élaborer la documentation. Nous passions nos journées à travailler, à planifier, à écrire et à réviser. Nous avons écrit des centaines de pages malgré les changements incessants liés aux ultimes modifications du logiciel. Nous avions des contributeurs en ligne qui proposaient de nouvelles pages et corrigeaient ce qui existait déjà. Je n’avais jamais vu notre équipe de documentation aussi productive.

À quoi avons-nous finalement abouti ? Beaucoup de facteurs sont entrés en jeu, et je pourrais écrire un livre entier sur les nuances de la documentation open source. Mais ce que j’ai fait de plus important a été de m’effacer et de laisser les autres faire le travail. J’ai appris à déléguer ; et à déléguer dans les règles de l’art.

Revenons huit ans en arrière. J’ai commencé à m’impliquer dans la documentation de GNOME en 2003. Je n’avais pas vraiment d’expérience en tant que rédacteur technique à cette époque. Mon emploi m’amenait à travailler sur des outils de publication et j’ai commencé à travailler sur les outils et sur le visualiseur d’aide utilisés par la documentation de GNOME. Peu de temps après, je me suis retrouvé à la rédaction de la documentation.

En ce temps-là, la majeure partie de notre documentation était entre les mains de rédacteurs techniques professionnels de chez Sun. Ils s’occupaient d’un manuel, l’écrivaient, le relisaient et l’envoyaient sur notre dépôt CVS. Après quoi nous pouvions tous le regarder, y apprendre quelque chose et lui apporter des corrections. Mais il n’existait pas d’efforts concertés pour impliquer les gens dans le processus d’écriture.

Ce n’est pas que les rédacteurs de Sun essayaient de protéger ou de cacher quoi que ce soit. Ils étaient avant tout rédacteurs techniques. Ils connaissaient leur travail et le faisaient bien. D’autres personnes auraient pu les remplacer pour d’autres manuels mais ils auraient écrit leur travaux d’une manière habituelle. Utiliser un groupe de collaborateurs novices, aussi enthousiastes soient-ils, pour chaque page, revient à perdre un temps inimaginable sur des détails. C’est tout simplement contre-productif.

De manière inévitable, le vent a tourné chez Sun et leurs rédacteurs techniques ont été affectés à d’autres projets. Cela nous a laissés sans nos rédacteurs les plus prolifiques, ceux qui disposaient des meilleures connaissances. Pire que cela, nous étions laissés sans communauté et personne n’était là pour ramasser les morceaux.

Il y a des idées et des processus standards dans le monde de l’entreprise. J’ai travaillé dans le monde de l’entreprise. Je ne crois pas que quiconque remette ces idées en cause. Les gens font leur travail. Ils choisissent des missions et les terminent. Ils demandent aux autres de faire une relecture, mais ils n’ouvrent pas leur travail aux nouveaux venus et aux rédacteurs moins expérimentés. Les meilleurs rédacteurs écriront sans doute le plus.

Ces idées sont d’une plate évidence, mais elles échouent lamentablement dans un projet communautaire. Vous ne développerez jamais une communauté de contributeurs si vous faites tout vous-même. Dans un projet de logiciel, vous pouvez avoir des contributeurs compétents et suffisamment impliqués pour contribuer régulièrement. Dans la documentation, cela n’arrive presque jamais.

La plupart des gens qui s’essayent à la documentation ne le font pas parce qu’ils veulent être rédacteur technique ni même parce qu’ils aiment écrire. Ils le font parce qu’ils veulent contribuer. Et la documentation est la seule manière qu’ils trouvent accessible. Ils ne savent pas coder. Ils ne sont artistiquement pas doués. Ils ne maîtrisent pas assez une autre langue pour faire de la traduction. Mais ils savent écrire.

C’est là que les rédacteurs professionnels lèvent les yeux au ciel. Le fait que vous soyez instruit ne signifie pas que vous puissiez écrire une bonne documentation pour l’utilisateur. Il ne s’agit pas simplement de poser des mots sur le papier. Vous devez comprendre vos utilisateurs, ce qu’ils savent, ce qu’ils veulent, les endroits où ils cherchent. Vous avez besoin de savoir comment présenter l’information de façon compréhensible et savoir où la mettre pour qu’ils puissent la trouver.

Les rédacteurs techniques vous diront que la rédaction technique n’est pas à la portée de tous. Ils ont raison. Et c’est exactement pourquoi la chose la plus importante que les rédacteurs professionnels puissent faire pour la communauté est de ne pas écrire.

La clé pour construire une communauté efficace autour de la documentation, c’est de laisser les autres prendre les décisions, faire le travail et en récolter eux-mêmes les fruits. Il ne suffit pas de leur donner du travail en continu. La seule solution pour qu’ils s’intéressent suffisamment et s’accrochent au projet, c’est qu’ils se sentent investis personnellement. Le sentiment de faire partie intégrante d’un projet est une source puissante de motivation.

Mais si vous ne travaillez qu’avec des rédacteurs débutants et que vous leur donnez tout le travail à faire, comment pouvez-vous avoir l’assurance que la documentation ainsi créée sera de qualité ? Une participation massive mais incontrôlée n’aboutit pas à de bons résultats. Le rôle d’un rédacteur expérimenté au sein de la communauté est d’être un professeur et un mentor. Vous devez leur apprendre comment rédiger.

Commencez par impliquer les gens tôt dans le planning. Planifiez toujours du bas vers le haut. La planification du haut vers le bas n’incite pas à la collaboration. Il est difficile d’impliquer les gens dans la réalisation d’une vue d’ensemble de haut niveau si tous n’ont pas la même perception de cette vue d’ensemble. Mais les gens sont capables de travailler sur des segments. Ils peuvent réfléchir à des sujets particuliers d’écriture, à des tâches que les gens réalisent, à des questions que les gens peuvent se poser. Ils peuvent regarder les forums de discussion et les listes de diffusion afin de voir ce que les utilisateurs demandent.

Écrivez vous-même quelques pages. Cela donne un exemple à imiter. Il faut ensuite répartir tout le reste du travail. Laissez à d’autres la responsabilité de rubriques ou de chapitres entiers. Précisez-leur clairement quelles informations ils doivent fournir, mais laissez-les écrire. C’est en forgeant qu’on devient forgeron.

Soyez constamment disponible pour les aider ou répondre aux questions. Au moins la moitié de mon temps consacré à la documentation est passée à répondre à des questions afin que les autres puissent effectuer leur travail. Quand des brouillons sont soumis, relisez-les et discutez des critiques et des corrections avec leurs auteurs. Ne vous contentez pas de corriger vous-même.

Cela vous laisse tout de même le gros du travail à faire. Les gens complètent les pièces du puzzle, mais c’est toujours vous qui les assemblez. Au fur et à mesure qu’ils acquièrent de l’expérience, les gens s’occuperont de pièces de plus en plus grandes. Encouragez-les à s’impliquer davantage. Donnez-leur davantage de travail. Faites en sorte qu’ils vous aident à aider plus de rédacteurs. La communauté fonctionnera toute seule.

Huit ans plus tard, GNOME a réussi à créer une équipe de documentation qui se gère elle-même, résout les problèmes, prend des décisions, produit une bonne documentation et accueille constamment de nouveaux contributeurs. N’importe qui peut la rejoindre et y jouer un rôle. Telle est la clé du succès pour une communauté open source.

Antirez est un développeur de logiciel libre… ou plutôt open source, car c’est l’expression qu’il semble privilégier.

Il nous livre ici le fruit de sa petit réflexion.

Ainsi il préfère les licences permissives à celles copyleft. Ce qu’il ne l’empêche pas de souhaiter voir plus de rétribution dans le domaine, parce que si l’on est obligé de payer sa facture autrement alors il y aura moins de code utile à disposition de tous.

Quelques réflexions sur le logiciel open source

A few thoughts about Open Source Software

Antirez - janvier 2013 - Blog personnel
(Traduction : FanGio, peupleLà, ehsavoie, Tibo, Sphinx, Penguin + anonymes)

Voilà plus de quinze ans que je contribue régulièrement à l‘open source, et cependant je m’arrête assez rarement pour réfléchir à ce que cela représente pour moi. C’est probablement parce que j’aime écrire du code et que c’est ainsi que je passe mon temps : écrire du code plutôt que réfléchir à ce que cela signifie… Cependant ces derniers temps, je commence à avoir des idées récurrentes sur l‘open source, ses relations avec l’industrie informatique et mon interprétation de ce qu’est le logiciel open source pour moi, en tant que développeur.

Tout d’abord, l‘open source n’est pas pour moi une manière de contribuer au mouvement du logiciel libre, mais de contribuer à l’humanité. Cela veut dire beaucoup de choses, par exemple peu m’importe ce que les autres font avec mon code ou qu’ils ne reversent pas leurs modifications. Je veux tout simplement que des personnes utilisent mon code d’une manière ou d’une autre.

En particulier, je veux que les gens s’amusent, apprennent de nouvelles chose et se « fassent de l’argent » avec mon code. Pour moi, que d’autres se fassent de l’argent avec le code que j’ai écrit n’est pas une perte mais un gain.

1. J’ai beaucoup plus d’impact sur le monde si quelqu’un peut payer ses factures en utilisant mon code.
2. Si N personnes gagnent de l’argent avec mon code, peut-être qu’ils seront heureux de m’en faire profiter ou plus disposé à m’engager.
3. Je peux être moi-même l’une de ces personnes qui gagnent de l’argent avec mon code, et avec celui d’autres logiciels open source.

Pour toutes ces raisons, mon choix se porte sur la licence BSD qui est en ces termes l’incarnation parfaite de la licence « faites ce que vous voulez ».

Cependant, il est clair que tout le monde ne pense pas de même, et nombreux sont les développeurs contribuant à l‘open source qui n’aiment pas l’idée que d’autres puissent prendre le code source et créer une entreprise qui ferait un logiciel commercial sous une autre licence.

Pour moi, les règles que vous devez suivre pour utiliser une licence GPL représentent une barrière qui réduit la liberté de ce que les personnes peuvent faire avec le code source. De plus, j’ai le sentiment qu’obtenir des contributions n’est pas tellement lié à la licence : si quelque chose est utile, des personnes vont contribuer en retour d’une manière ou d’une autre, car maintenir un fork n’est pas simple. La véritable valeur se trouve là où le développement se produit. Du code non corrigé, qui n’évolue pas, ne vaut rien. Si, en tant que développeur open source, vous pouvez apporter de la valeur, des parties tierces seront encouragées à faire intégrer leurs modifications.

Cependant, je suis beaucoup plus heureux quand il y a moins de correctifs à fusionner et plus de liberté du point de vue des utilisateurs, plutôt que l’inverse, il n’y a donc pas grand chose à discuter pour moi.

De mon point de vue, ce que l‘open source ne reçoit pas suffisamment en retour, ce ne sont pas les correctifs mais plutôt l’argent. Le nouveau mouvement des startups, et les faibles coûts opérationnels de nombreuses entreprises IT viennent de l’existence même de tout ce code open source qui fonctionne bien. Les entreprises devraient essayer de partager une petite partie de l’argent qu’elles gagnent avec les personnes qui écrivent les logiciels open source qui sont un facteur clé de leur réussite, et je pense qu’une manière saine de redistribuer cet argent est d’embaucher ces développeurs pour qu’ils écrivent du logiciel open source (comme VMware l’a fait pour moi), ou de faire des dons.

Beaucoup de développeurs travaillent pendant leur temps libre par passion, seul un petit pourcentage parvient à être payé pour leur contribution à l‘open source. Une éventuelle redistribution peut permettre à plus de gens de se concentrer sur le code qu’ils écrivent par passion et qui a peut être « un impact plus important » sur l’économie que le travail qu’ils font pour obtenir leur salaire chaque mois. Et malheureusement, il est impossible de payer les factures avec des PULL REQUESTS, c’est pourquoi je pense qu’apporter de l’aide à un projet sous forme de code est une bonne chose, mais ce n’est pas suffisant.

Vous pouvez avoir un point de vue différent sur tout cela, mais ce que j’observe, c’est que le logiciel open source produit beaucoup de valeur dans l’industrie informatique actuelle, et qu’il est souvent écrit sur son temps libre ou en jonglant entre les différentes tâches pendant son temps de travail, si votre employeur est assez souple pour vous permettre de le faire.

Ce que je pense, c’est que cela est économiquement sous-optimal, beaucoup de codeurs intelligents pourraient donner une impulsion à l’économie s’ils étaient plus libres d’écrire du code qu’ils aiment et que beaucoup de gens utilisent sans doute déjà pour faire de l’argent.

• Source : Hadopi : vers une amende systématique de 140 euros ? (Numerama)

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

Et si nous faisions en sorte qu’Internet nous permette de payer en toute liberté ?

Que nous sortions du double carcan de la somme fixe et unique pour tout le monde et du poids moral négatif induit par l’usage (de la copie) sans rétribution ?

Si c’est possible de le copier, alors vous le trouverez gratuitement sur Internet. Ceci n’est pas un slogan publicitaire mais une constatation. Nous vivons dans un monde où le contenu s’est affranchi de son support matériel et des limites inhérentes. Dans ce monde, les barrières de l’accès à la connaissance sont tombées. Tout le monde peut partager une réflexion philosophique, une analyse d’une œuvre de Monet. Ou une vidéo de chatons et le dernier clip d’un chanteur à la mode.

Au fond, c’est merveilleux. Cela devrait nous émerveiller tous les matins. Aucun auteur de Science-Fiction n’avait osé en rêver. C’est génial ! Sauf si on gagne sa vie à vendre du contenu sur un support physique. Auquel cas, la perspective est un peu inquiétante.

Alors que le support physique n’était jamais qu’un moyen comme un autre de diffuser de l’information, les vendeurs ont tout d’abord tenté de lier irrémédiablement le contenu avec son contenant. Voire de distribuer le contenu de manière virtuelle mais en ajoutant artificiellement les contraintes du matériel, quand bien même ce matériel n’existait plus.

Après cet échec prévisible, les industries du contenu cherchèrent d’autres méthodes de rentabilisation. Après tout, il existe des journaux gratuits, des chaînes de télévision gratuites. Le dénominateur commun étant le financement par l’ajout de publicité.

Outre les questions qu’elle pose, la publicité a le problème de dégrader l’expérience du contenu. Apprécierez-vous d’être interrompu au milieu d’une fugue de Bach par un slogan ventant des croquettes pour chat ? Pire : tout comme il est possible de tout trouver gratuitement, il est également possible de bloquer la publicité.

Un monde virtuel qui ne vivrait que de la publicité serait fortement limité. En effet, la publicité devrait forcément faire référence aux produits du monde réel, celui au grand plafond bleu, produits limités en quantité par le monde réel lui-même. À l’heure où l’on parle de décroissance, on ne peut imaginer augmenter à l’infini les publicités.

Lorsqu’il n’est physiquement plus possible de forcer quelqu’un à vous donner de l’argent, la seule solution est de faire appel à son sens moral. De le convaincre. Deux choix s’offrent au vendeur : la voie positive « C’est bien de donner » et celle négative « Ne pas donner, c’est mal ! ».

Devinez laquelle a été choisie ? Nous vivons dans un monde merveilleux où le partage est possible instantanément à travers la planète et nous avons réussi à transformer cette utopie futuriste, cette réalisation extraordinaire en un péché moral : « Ne pas payer, c’est mal ! », « Ne pas payer est illégal », « Si vous ne payez pas, vous serez poursuivi en justice », « Si vous ne payez pas, vos artistes préférés vont mourir de faim ».

Mais toute cette rhétorique négative se fonde sur une série de postulats.

1. Un artiste doit être payé pour ses réalisations.

FAUX. Cette vision se base sur une séparation nette entre les artistes d’un côté et les consommateurs de l’autre. Internet a démontré que nous sommes tous, à différents degrés, des artistes. Comme le dit Rick Falkvinge, un artiste c’est quelqu’un qui produit de l’art. À partir du moment où cette personne cherche à en tirer du profit, elle devient un entrepreneur. Et, à ce titre, c’est à elle de mettre en place un business model. On pourrait également appliquer cet argument au logiciel libre et dire que tout codeur doit être payé pour ses contributions. Pourtant, le logiciel libre prouve que c’est loin d’être le cas.

2. Tout travail mérite salaire.

FAUX. Le client paie généralement le produit d’un travail, pas le travail lui-même. Creuser un trou dans votre jardin est un travail dur. Le reboucher l’est tout autant. Pourtant, personne ne vous paiera pour cela. Le travail n’est donc rémunéré que lorsque quelqu’un estime intéressant de le faire, quelle que soit sa raison.

3. Il faut payer avant de consommer.

FAUX. Imaginez que vous puissiez entrer dans un restaurant, manger et que le prix soit laissé à votre appréciation. Si vous avez aimé, vous payez beaucoup. Sinon, vous payez moins ou juste assez pour couvrir le prix des produits. Utopiques ? C’est pourtant dans ce monde que nous vivons de plus en plus. La musique en est l’exemple le plus marquant : il n’est pas rare de rencontrer des audiophiles qui achètent un album qu’ils ont téléchargé depuis six mois sous prétexte : « C’est vraiment un bon CD, je l’adore, je l’écoute en boucle. Du coup, je l’achète pour soutenir l’artiste. ».

4. Il est obligatoire de payer.

FAUX. Contrairement à l’exemple du restaurant, la reproduction de l’information à un coût tout à fait nul. Il n’y a donc aucune raison particulière de payer pour consommer du contenu. Nous écoutons de la musique chez des amis, nous lisons un livre trouvé sur un banc, nous entendons un voisin expliquer le sens de la vie par dessus sa haie : nous consommons en permanence du contenu sans le payer. Pire, un même contenu peut être consommé gratuitement à titre promotionnel puis rendu payant par après. Les distributeurs de contenu sont donc dans la position schizophrénique de devoir diffuser le contenu autant que possible tout en empêchant… qu’il soit trop diffusé.

Pourtant, cet argument de l’obligation de payer est tellement tenace qu’il en est devenu « Si c’est gratuit, c’est nul » jusqu’à un extrème « Si c’est cher, c’est bien » exploité par les grandes marques.

5. Chacun doit payer le même prix pour accéder au même contenu.

FAUX. De nouveau, aucune loi naturelle n’oblige à ce que chacun paie la même chose pour le même service. Nous sommes pourtant habitués à ce genre de choses : les militaires, les jeunes et les pensionnés ont des réductions dans les transports en commun. Les journalistes et les professeurs ont des entrées gratuites dans certains musées.

Quand on y pense, payer le même prix est foncièrement injuste. Une personne qui adore un contenu paiera autant que quelqu’un qui n’a agit que par réflexe suite à une publicité et ne le consommera qu’une ou deux fois.

Si nous arrivons à remettre en question ces postulats, alors peut-être arriverons-nous à sortir de cette pernicieuse morale négative. Peut-être pourrons-nous enfin être fiers de cet accomplissement humain : le partage du savoir à tous les niveaux.

Et des solutions commencent à se mettre en place. Ma préférée étant Flattr qui, justement, permet de donner une petite somme d’argent aux contenus que l’on apprécie et ce parfois automatiquement. Avec la subtilité que la somme donnée par mois est fixe, quelque soit la quantité de contenu consommé. Framasoft est sur Flattr et je milite activement pour qu’on puisse Flattrer les billets individuels ! Certes, Flattr est centralisé mais tout service gérant des transferts d’argent le restera tant que Bitcoin ne sera pas généralisé !

Les artistes eux-mêmes commencent à bouger. Après l’expérience de Radiohead en 2007, c’est au tour d’Amanda Palmer de voir dans le « Payez ce que vous voulez » l’avenir des artistes. Et pour ceux qui souhaitent vraiment s’investir dans la réussite d’un artiste, les plateformes de « crowdsourcing » comme Kickstarter sont en train de contourner de plus en plus le rôle des gros producteurs, de décentraliser les industries du contenu.

À ce genre de discours, il est courant d’objecter que, si ils ont le choix, les consommateurs vont éviter de payer. Pourtant, le choix est déjà là. La majorité des consommateurs choisit de payer pour des raisons morales le plus souvent négatives. Il existe également des domaines où le fait de donner volontairement est considéré comme normal : c’est le principe du pourboire. Je vous propose de tester le web payant pour vous faire votre propre idée.

Transformer Internet en une économie du « Payez ce que vous voulez » ne serait donc que transformer les raisons morales afin de les rendre positives. Et, à ce titre, rendre complètement obsolètes tous les fichages, les surveillances et autre HADOPI. Un retour à la liberté.

Flattr ne différencie pas les consommateurs des producteurs de contenu. Nous sommes tous des producteurs de contenu, nous somme tous des artistes. Et nous sommes tous également avides de nouveautés, d’art et d’idées. Finalement, n’est-ce pas un des fondement de l’égalité ?

Contrairement à un achat, où je me sens toujours extorqué de mon argent durement gagné, faire un micro don me réchauffe le cœur, me donne le sentiment d’être, à mon échelle, un contributeur. Un sentiment de fraternité.

Liberté, égalité, fraternité. C’est peut-être la définition du web et de l’art de demain.

Crédit photo : Flattr (Creative Commons By)

Flux (rss): http://www.framablog.org/index.php/feed/atom