La génération GitHub

GitHub a beau être une plateforme non libre de projets libres, force est de constater que cette « forge sociale » est devenue en quelques années l’un des centres névralgiques de la communauté.

Avec sa facilité d’usage, son appel permanent au fork et l’individuation des contributions, GitHub a permis a plus de monde de participer tout en ouvrant le Libre au delà du logiciel puisqu’il n’y a pas que du code proprement dit dedans (cf la liste de l’article traduit ci-dessous).

À tel point que certains n’hésitent pas à y voir un modèle pertinent pour toutes sorte de choses à commencer par la… démocratie !

Et si une génération toute entière était effectivement en train de naître sous nos yeux ?

GitHub

La génération Github : Pourquoi vous et moi pouvons désormais faire de l’Open Source

The GitHub Generation: Why We’re All in Open Source Now

Mikeal Rogers – 7 mars 2013 – Wired Opinion
(Traduction : Moosh, Sphinx, Peekmo, Chopin, goofy, misc, Uflex + anonymes)

GitHub a été conçu pour être une plate-forme de collaboration logicielle ouverte, mais c’est devenu une plate-forme pour déposer beaucoup plus de choses que du simple code. Elle est maintenant utilisée par des artistes, des créateurs, des propriétaires de maisons et des tas d’autres gens, par des entreprises entières… et même par des municipalités.

« N’importe qui peut maintenant changer les données quand de nouvelles pistes cyclables sont aménagées, quand de nouvelles routes sont construites ou quand de nouveaux immeubles sont construits » a annoncé récemment la ville de Chicago. Les gens planifient leurs projets de rénovation de maison sur GitHub. Un cabinet d’avocats a annoncé il y a quelques jours qu’il postait des documents juridiques pour des start-ups sur GitHub. Quelqu’un a même publié toutes les lois d’Allemagne sur GitHub l’année dernière (avec, s’il vous plaît, déjà 17 pull requests pour des modifications).

Bien sûr, GitHub reste majoritairement toujours utilisé par les programmeurs et développeurs qui font voler des AR.Drones avec Node.js ou construisent des sites web avec jQuery. Mais de plus en plus de gens passent de consommateurs à producteurs, et ils redéfinissent ainsi la culture de l’open source. Je crois que GitHub transforme l’open source comme l’internet a transformé l’industrie de la publication : un fossé culturel est en train de se creuser entre l’ancienne génération de gros projets libres et la nouvelle génération d’amateurs de projets libres d’aujourd’hui.

La révolution ne sera pas centralisée

Quand la plupart des gens entendent « open » source, ils pensent démocratie, distribution, égalité : tout le monde construit des choses pour que tout un chacun les utilise.

Mais cela n’a pas toujours été le cas. La plupart des logiciels open source ont été créés et maintenus par une classe privilégiée et protégée, les développeurs professionnels, qui interagissaient avec d’autre développeurs très semblables (ils sont pourtant suffisamment différents pour avoir de belles disputes).

Avant GitHub, je passais beaucoup de temps à penser et à discuter de la meilleure façon de gérer des projets open source parce que la coordination représentait un coût important d’un projet open source. Si important que lorsqu’un projet réussissait et développait une communauté assez grande, il était logique que le projet grandisse plutôt qu’il ne se fracture en projets plus petits. Mais plus le projet du logiciel devenait grand et complexe, plus il était difficile d’y contribuer. Ainsi, un choix de membres, les commiters – étaient assignés à la gestion et à la production du projet. Cela menait souvent à des ruptures séparant ceux qui produisaient le projet et ceux qui les utilisaient.

GitHub a comblé ce fossé en faisant de l’open source quelque chose de bien plus décentralisé. C’est devenu davantage centré sur les individus que sur le projet.

La façon d’utiliser GitHub est trés personnelle. Une personne (je suis github.com/mikeal) a un compte, et tout ce qu’elle publie existe à un niveau en dessous d’elle. Si quelqu’un veut corriger quelque chose, il suffit de « forker » le projet, ce qui place une copie sous son propre compte.

Cette façon de travailler est trés stimulante : elle encourage les individus à corriger les problèmes et à prendre possession des correctifs au même niveau que le projet de départ. Cela donne également à chacun une identité dans cette nouvelle culture du libre. GitHub est actuellement le premier fournisseur d’identité pour la production collaborative sur internet pour faire plus que du développement de code.

J’ai contribué à des projets libres depuis plus de 10 ans, mais ce qui est différent maintenant est que je ne suis pas un membre d’un de ces projets, je suis un simple utilisateur, et contribuer un peu est devenu une petite partie du rôle d’un utilisateur. Des petites interactions entre moi et les mainteneurs de projets arrivent plusieurs fois par semaine sur tout type de projet que j’utilise. Et ça arrive encore plus souvent dans l’autre sens : des gens dont je n”ai jamais entendu parler m’envoient des petits bouts de code sur les petits projets que j’ai publiés.

La décentralisation comme démocratie

Les premières versions de GitHub ont très bien fait une chose : rendre la publication de votre code beaucoup plus facile (que la non-publication). Ceci était suffisant pour que beaucoup de projets connus, notamment Ruby on Rails, migrent sur GitHub presque immédiatement.

Mais ce qui s’est passé après est encore plus intéressant : les gens ont commencé à tout publier sur GitHub. Pousser du code est presque devenu une habitude, comme tweeter. En abaissant la barrière pour entrer et rendant plus facile la contribution à l’open source, GitHub a élargi la production collaborative aux utilisateurs occasionnels.

Aujourd’hui un vaste choix de logiciels simples et compréhensibles est accessible à une catégorie de gens créatifs qui n’avaient jusqu’alors pas les compétences techniques requises pour participer à des projets open source par le passé.

Ce mélange des relations entre les producteurs, les contributeurs et les consommateurs valorise naturellement les projets plus petits et plus faciles à comprendre — et a conduit à de nombreuses contributions. Au cours du mois de septembre 2012 par exemple, la moitié des utilisateurs actifs de GitHub qui ont poussé au moins un changeset, l’ont fait moins de cinq fois, avec 22% (environ 44 000 personnes) qui ont poussé seulement un seul changeset ce mois-ci.

L’accès de l’open source aux amateurs présente certains avantages évidents.

Faciliter les usages

Un des problèmes récurrents, avec le logiciel open source, a été la qualité des finitions. La documentation, le design des sites web et l’ergonomie en général ont toujours été un problème — spécialement par rapport à de nombreux concurrents propriétaires.

Mais maintenant, avec les facilités de collaboration, des utilisateurs moins portés sur la technologie et la connaissance du code peuvent plus facilement participer à améliorer les logiciels sur lesquels ils travaillent (ce qui peut être des petites choses comme l’humanisation des messages d’erreur de codage ou de légers changements graphiques en une ligne de CSS qui optimisent le rendu des sites web des navigateurs, anciennes versions incluses, et sur les téléphones mobiles).

Dans le nouvel open source, les gens veulent utiliser la technologie sans avoir besoin de devenir des experts. La facilité d’utilisation est plus valorisée que jamais.

Éviter de réinventer la roue

Les développeurs aiment les défis et plus ils ont de chances de les relever, plus leurs solutions peuvent être astucieuses. C’était parfait lorsque les utilisateurs de ces solutions étaient eux aussi des gens très compétents techniquement comme ceux qui prenaient plaisir à résoudre astucieusement ces anciens problèmes.

Mais les amateurs préfèrent les solutions qu’ils peuvent tenir pour acquises : une fois qu’un problème est résolu, ils reviennent rarement en arrière pour le réexaminer. Et dans la mesure où les amateurs ne créeront qu’à partir des solutions les plus compréhensibles, cela contraint les développeurs à élaborer des solutions simples qui rendent les problèmes complexes plus faciles à appréhender.

Soutenir un écosystème plus vaste

Node.js, projet dans lequel je suis activement impliqué, définit des modèles suffisamment simples pour que les gens puissent écrire de petites bibliothèques indépendantes et les publier à leur gré. Tous ceux qui s’impliquent dans l’écosystème peuvent en tirer profit sans coordination. C’est le pôle inverse de l’énorme pile verticale qui accompagne des tas d’outils et fonctionnalités (tels que dans les systèmes intégrant des plugins, comme Ember, Dojo et YUI) qui sont nécessaires pour réussir à développer dans des environnement propriétaires (pensez à Cocoa et au développement pour iOS). Dans les environnements ouverts, tels que Node.js sur GitHub, nous constatons que des API bien plus légères peuvent facilement tirer parti du reste de l’écosystème sans coordination. Moins il y a de coordination entre les développeurs et les bibliothèques et plus nous pouvons créer de la valeur.

GitHub a donné les capacités à une nouvelle génération de collaborer, de créer, de produire. Beaucoup de développeurs regretteront l’abandon des normes culturelles précédentes, telles que le statut des commiters (ceux qui sont autorisés à envoyer le code sur le dépôt) ou la bonne vieille guerre pour le choix de la bonne licence — mais l’avenir est déjà entre les mains d’une nouvelle génération qui a évolué.

Ce n’est pas un simple outil : c’est à la naissance d’une nouvelle culture à laquelle nous assistons.




Un salon de beauté conçu avec Blender et Cycles (en lieu et place de 3ds Max)

Dans le milieu du design et de la CAO, la part belle est encore trop souvent faite aux logiciels propriétaires.

Mais il n’y pas que 3ds Max & co dans la vie logicielle. On peut faire tout aussi bien, voire mieux, avec le libre Blender et son moteur de rendu Cycles.

C’est que ne nous prouve par l’exemple cet entretien du talentueux ukrainien Igor Shevchenko.

Backstage - Blender

Un salon de beauté conçu et visualisé grâce à Blender et Cycles

Beauty salon designed and visualized with Blender and Cycles

Alexandre Prokoudine – 25 février 2013 – LibreGraphicsWorld.org
(Traduction : Alpha, Max, KoS + anonymes)

Parmi toutes les choses intéressantes qui sont réalisables à l’aide de logiciels libres, ce que LGW aime faire le plus, c’est produire un travail commandé qui soit reconnu. Parlons d’un cas particulier, celui de l’utilisation de Blender et Cycles pour la visualisation d’architectures commerciales.

Je suis récemment tombé sur ce travail sur Behance (NdT : une plateforme de partage de projets de design pour les professionnels) et je n’ai pas pu résister à l’envie de contacter Igor Shevchenko, son auteur.

Igor travaille pour une entreprise ukrainienne appelée « Magis ». Il s’occupe de la modélisation, du texturage et du rendu d’intérieur. « Backstage », le salon de beauté en question, est un véritable établissement qui a ouvert à Kiev en septembre 2012.

Igor, s’agit-il de ton premier projet sérieux réalisé à l’aide de Blender ? Le reste de ton album sur Behance semble porter les étiquettes de 3DS Max, Adobe Photoshop et d’autres logiciels du même genre.

Oui, c’est vrai, c’est le premier vrai projet que l’on m’a commandé et que j’ai réalisé avec Blender. J’étais vraiment curieux de savoir s’il allait être possible de réaliser un tel projet uniquement avec un logiciel libre et de voir les difficultés auxquelles on pouvait s’attendre. Lorsque j’ai commencé à travailler sur le projet, j’ai eu peur que ma connaissance de Blender ne soit pas suffisante pour le mener à bien et de devoir retourner sous 3DS Max. Ça ne s’est pas produit.

Combien de temps cela a-t-il pris ?

Le travail sur le design intérieur a été fait en 3 mois. Mais les rendus du portfolio pour Behance ont été une toute autre affaire. Je suis parti de rien, surtout pour Behance.

Vraiment ?

L’année dernière, en novembre, notre administrateur système m’a demandé de lui envoyer quelques rendus de ce que j’avais fait avec Blender. Il souhaitait les montrer à un ami qu’il tentait de convaincre que Blender était en fait un outil très correct. J’ai donc fouillé parmi mes fichiers et je fus horrifié de constater que je n’avais aucun rendu lissé. J’ai alors décidé de repartir de zéro pour refaire les rendus du projet « Backstage ».

Attends, donc tu n’as pas fait ces visualisations pour le client ?

Le client ne voulait pas des rendus de haute qualité dans un premier temps. Nous avons juste fait le design et décrit le reste avec des mots.

OK, donc de combien de temps as-tu eu besoin pour réaliser la version portfolio du projet ?

Je n’avais aucune date limite, ça ne pressait donc pas, je l’ai fait pendant mon temps libre. Je pense qu’en m’y mettant et en ne faisant rien d’autre, ça m’aurait pris une journée pour faire la modélisation, une autre pour peaufiner les détails et encore une autre pour effectuer le rendu global.

Backstage - Blender

D’où vient ton intérêt pour Blender ?

Il y a environ trois ans, j’ai fini par en avoir marre d’utiliser 3DS Max, j’ai donc commencé à chercher des alternatives. J’ai d’abord essayé Maya et Cinema 4D et j’ai opté pour Maya. Cependant, je me suis rendu compte que soit je n’arrivais pas à trouver le temps pour apprendre à l’utiliser, soit il ne me convenait pas. Peut-être un peu des deux.

J’ai fini par revenir à 3DS Max, faute d’autre chose. Notre administrateur système, qui est un grand adepte du logiciel libre m’a suggéré d’utiliser Blender, mais il s’agissait de la version 2.49 que je n’ai vraiment pas appréciée.

Fin 2011, j’ai lu un article sur « Sintel » le film libre, je l’ai alors regardé. J’ai adoré à la fois l’histoire et les visuels, j’ai donc donné une seconde chance à Blender : j’ai téléchargé une version plus récente et je me suis mis à lire les tutoriels d’Andrew Price, j’ai alors commencé à comprendre comment ce logiciel fonctionnait.

Puis, Cycles est arrivé, et ça a achevé de me convaincre. Mi-2012, j’étais déjà en train de réaliser des petits projets avec Blender, puis « Backstage » est devenu le premier grand projet pour lequel je m’en suis servi. Ça n’a pas été facile, mais je ne suis pas déçu. Avant je considérais que les logiciels libres performants ne pouvaient pas exister. Blender est une exception remarquable dans ce domaine.

L’un dans l’autre, une expérience positive ?

Oui. Mes collègues ont remarqué que je travaillais plus rapidement. Blender a une logique réellement différente, pas comme dans 3DS Max :

  • manipulation d’objets,
  • personnalisation facile de l’interface,
  • approche différente de la modélisation de polygone,
  • paramétrage nodal des matériaux,
  • traitement « post-processing » intégré,
  • modificateurs (il n’y en pas beaucoup, mais ils sont très efficaces pour accélérer le processus de modélisation),
  • raccourcis clavier (il y en a beaucoup et ils améliorent grandement mon efficacité).

Blender possède des fonctionnalités sans lesquelles je ne m’imagine pas travailler aujourd’hui. 3DS Max n’en possède pas autant.

Cette liste pourrait s’allonger mais le plus important est que Blender est tout simplement mon type d’application.

Et Cycles ?

Cycles est un formidable moteur de rendu. J’ai récemment implémenté le matériau caoutchouc dans 3DS Max pour les pneus, et c’était vraiment la misère : paramétrage, rendu, paramétrage, rendu ainsi de suite… Dans Cycles, j’ai juste ajusté les paramètres et vu le résultat immédiatement.

Vois-tu une utilité au moteur de rendu interne de Blender dans ton travail quotidien ?

Non, c’est plutôt inutile en ce qui me concerne.

Est-ce que l’aspect libre et gratuit, en plus de la faible taille du fichier à télécharger a joué un rôle ?

Tout à fait. À plusieurs reprises, j’ai eu besoin de télécharger Blender lors d’un rendez-vous avec un client sur son ordinateur (5 minutes), de le lancer (2 secondes) et de travailler sur un projet. Ça fait une grande différence.

Au vu de tout ça, est-ce que l’un de tes collègues a déjà eu envie d’utiliser Blender ?

Non, et je ne m’attends pas à ce qu’ils le fassent. Soyons réalistes, la seule façon pour que cela arrive, c’est de les forcer à l’utiliser, et rien de bon n’en sortira. En réalité, les gens n’ont soit pas le temps, soit pas l’envie d’apprendre de nouvelles choses, et certains ne savent même pas que des alternatives existent.

Quels types de difficultés as-tu rencontrés lorsque tu travaillais avec Blender sur le projet « Backstage » ?

Le principal défaut de Blender est que la phase de développement actif a commencé assez récemment et beaucoup de fonctionnalités de base ne sont pas encore présentes. Il y a aussi les problèmes de compatibilité avec les formats de fichiers : c’est difficile d’ouvrir des fichiers Blender dans AutoCAD et dans 3DS Max, c’est même quasiment impossible.

As-tu rencontré des problèmes purement techniques avec Cycles ? Quelque chose qui manque ?

J’ai un peu de mal à me rappeler ce qui manque. De manière générale, les fonctionnalités compatibles par défaut dans les autres moteurs de rendu. La gestion des fichiers IES (NdT : qui gèrent la répartition de la lumière) en faisait partie il y a peu, mais ça a été résolu.

D’un autre côté, j’ai trouvé des méthodes parfaitement fonctionnelles pour contourner la plupart — sinon toutes — des fonctionnalités manquantes. La seule chose que je n’arrive pas à contourner c’est que Cycles est plutôt inutile sans une carte graphique chère.

Penses-tu que la fréquence des mises à jour de versions interfère avec les méthodes de travail en entreprise ? Les studios seraient plus enclins à n’utiliser que des mises à jour importantes et à ne les mettre à jour que pour corriger les bugs, c’est assez connu.

La fréquence d’apparition des nouvelles versions semble être une des principales particularités des logiciels libres. Je pense qu’en réalité, Blender en tire profit, parce qu’il reste beaucoup de choses à faire.

En plus, Blender a une bonne compatbilité ascendante et, de cette manière, rien n’empêche un studio de se limiter à une version particulière et à l’utiliser pendant quelques années.

Backstage - Blender

La galerie complète du projet « Backstage » est disponible sur Behance.




Préparer un logiciel à sa diffusion (Libres conseils 29/42)

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

Traduction Framalang : merlin8282, Sphinx, Julius22, goofy, lerouge, lamessen, Asta, peupleLà, okram

Packager : la voie royale du logiciel libre

Thorn May

Thom May est développeur Debian et membre émérite de la fondation Apache. Il a été parmi les premiers à être engagés chez Canonical, l’entreprise mère d’Ubuntu. Il vit aujourd’hui à Londres et dirige l’unité de développement chez MacMillan Digital Science.

Introduction

Ça fait plus de dix ans que j’ai débuté dans le monde du logiciel libre. J’avais utilisé Debian pendant quelques années à l’université et décidé que je voulais donner quelque chose en retour. J’ai donc commencé un long voyage à travers les étapes permettant de devenir un « nouveau responsable Debian » sans avoir jamais vraiment contribué au logiciel libre auparavant et inquiet qu’un manque d’expérience en C pourrait se révéler être un gros problème.

Il s’avéra que cette inquiétude était largement infondée. En commençant à travailler avec des paquets que j’utilisais régulièrement, j’ai pu contribuer efficacement. En même temps que mon expérience avec la myriade d’outils et de systèmes que Debian fournit à ses mainteneurs s’accroissait, je devenais plus efficace pour gérer mon temps et j’étais capable de travailler sur un ensemble de paquets plus étendu.

M’occuper de davantage de paquets m’amena à travailler avec un ensemble plus important de systèmes de compilation, de langages de programmation et de boîtes à outils. Cela m’aida également à m’intégrer à la communauté Debian. Aussi rugueuse et dogmatique soit-elle, le fait que la communauté Debian repose sur des mainteneurs doués et expérimentés est l’une des raisons principales pour lesquelles Debian a maintenu son excellence technique sur une si longue période.

À peu près à ce moment, le projet Apache httpd approchait enfin des premières versions bêta de httpd 2.0 qui était restée des années en chantier et était sur le point de subir une mise à jour majeure. L’équipe Apache de Debian avait été plutôt inactive depuis quelques temps — les paquets de la version 1.3 étaient stables et changeaient peu — et n’avait pas prévu d’empaqueter la version 2.0. J’avais un intérêt majeur à garantir que les paquets httpd étaient bien maintenus. Je travaillais comme administrateur système en charge de nombreux serveurs web Apache, il tombait donc sous le sens que je devais relever le défi de la production de paquets pour la nouvelle version.

Avec un ami, nous avons commencé le travail sur les paquets et nous avons rapidement découvert que, alors que le code approchait le niveau de qualité d’une bêta toute fraîche, l’outillage autour de la compilation et de la personnalisation de httpd était hélas manquants, ce qui est assez représentatif de bien des projets logiciels complexes.

Au cours de la majeure partie de l’année — alors que les développeurs en amont stabilisaient leur code et qu’un nombre croissant d’utilisateurs précoces commençaient à tester et à déployer la nouvelle version — nous avons travaillé dur pour garantir que le système de compilation soit suffisamment flexible et robuste pour satisfaire aux rigoureux prérequis de la politique de Debian. Nous devions non seulement garantir que nos paquets étaient techniquement corrects, mais également nous assurer que notre relation avec les développeurs en amont nous permettait de leur faire remonter des correctifs dès que possible, de les avertir dès que des problèmes de sécurité faisaient surface et de leur transmettre les tests préliminaires des versions candidates.

Mes interactions avec Apache pendant l’empaquetage et la maintenance de httpd 2.0 m’ont amené à m’engager en amont du projet, ce qui signifiait que je pouvais directement contribuer au code. C’est, en général, la dernière étape avant de passer de l’empaquetage d’un logiciel à son développement actif à destination d’un public plus large que celui de votre distribution. À titre personnel, cette reconnaissance m’a donné la confiance pour contribuer à bien plus de projets libres puisque je savais que mon code était de qualité suffisante pour être bien accueilli.

L’évolution, du packager au développeur

Comment est-ce arrivé ? La création de paquets, dans sa forme la plus simple, permet d’assurer qu’un projet logiciel donné se conforme à la politique de la distribution ; dans mon cas, Debian. De manière générale, cela signifie configurer le logiciel au moment de la compilation afin qu’il soit installé dans les répertoires idoines spécifiés par le Filesystem Hierarchy Standard, ou FHS (NdT : Norme de la hiérarchie des systèmes de fichiers), que les dépendances aux autres paquets soient correctement spécifiées et que les logiciels fonctionnent normalement sur la distribution.

La création de paquets complexes peut nécessiter la division d’un projet en amont en de multiples paquets. Par exemple, les bibliothèques et les fichiers d’en-tête permettant à l’utilisateur de compiler le logiciel avec leur bibliothèque sont fournis dans des paquets distincts, et des fichiers dépendant de la plate-forme peuvent être fournis séparément de ceux qui en sont indépendants. S’assurer que le logiciel en amont se déploie correctement dans ces situations nécessitera souvent des changements dans le code. Ces changements sont la première étape vers un travail actif sur un projet, plutôt que le travail parfois passif de création de paquet.

Une fois que votre paquet est disponible dans la distribution, il est exposé à des millions d’utilisateurs potentiels. Ces utilisateurs vont sans aucun doute exécuter votre logiciel selon des pratiques que ni vous, en tant que packager, ni vos développeurs en amont n’aviez prévues. Sans surprise, avoir de nombreux utilisateurs implique l’arrivée de nombreux rapports de bogue. Debian, comme la plupart des distributions, encourage ses utilisateurs à lui soumettre directement les rapports de bogue plutôt qu’à chacun des projets individuels en amont. Ceci permet aux mainteneurs de trier les rapports de bogue et d’assurer que les modifications effectuées lors du processus de création de paquet ne sont pas la cause du problème rapporté. Souvent, il peut y avoir un grand nombre d’interactions entre le rapporteur du problème et le mainteneur du paquet avant que les développeurs en amont ne soient impliqués.

Au fur et à mesure que le mainteneur du paquet accroît sa connaissance du projet, il sera en mesure de résoudre directement la plupart des problèmes. Le mainteneur publiera souvent des correctifs de bogue directement dans Debian tout en les faisant remonter en amont, permettant ainsi à la fois une résolution rapide des problèmes et de nombreux tests de correctifs. Une fois qu’un correctif est validé, le mainteneur travaillera alors avec le projet amont pour s’assurer que les changements requis y ont bien lieu, de manière à ce qu’ils soient disponibles aux autres utilisateurs du logiciel.

Fournir des correctifs de bogue réussis pour des distributions telles que Debian relève souvent d’une forme complexe d’art. Debian fonctionne sur de nombreuses plates-formes, allant des gros serveurs IBM aux smartphones, et la gamme ainsi que la largeur de ces plates-formes révèlent rapidement les approximations dans le code. L’empaqueteur a, la plupart du temps, un accès plus aisé à une gamme de plates-formes plus étendue que les développeurs en amont et constitue, de ce fait, le premier point d’appel quand un problème épineux de portage apparaît. On apprend rapidement à reconnaître les symptômes d’une approximation de la taille d’un pointeur, les problèmes avec les endianness et bien d’autres problèmes ésotériques ; cette expérience permet de devenir un programmeur à la fois plus polyvalent et plus prudent.

Lorsqu’un paquet reçoit des corrections de bogues et des améliorations, il est essentiel que ces changements remontent en amont. Trop souvent, la différence entre un paquet et le logiciel définitif en amont peut s’accroître énormément, avec pour conséquence que les deux bases de code deviennent presque entièrement distinctes. Non seulement, cela alourdit la tâche de la maintenance des deux côtés, mais cela peut aussi créer une immense frustration et faire perdre beaucoup de temps en amont dans le cas où un utilisateur de votre paquet rapporte un bogue lié à l’un des changements dans la version empaquetée en amont. Il est en conséquence vital que s’établissent une relation de travail étroite avec la branche amont et une compréhension de la meilleure façon de collaborer entre les deux parties.

La collaboration entre les développeurs et le packager peut prendre bien des formes. Que ce soit trouver la bonne voie pour communiquer les rapports de bogue, s’assurer de l’utilisation du bon style de codage, du même usage du système de contrôle de version ou des interactions qui provoquent le moins de frictions possible. Tout ceci amène une bien meilleure relation avec l’amont et accroît grandement la probabilité que ceux qui y travaillent prendront le temps de vous aider quand vous en aurez besoin.

Une fois que la relation de travail entre l’amont et vous est établie, il devient facile de contribuer plus directement en amont. Ceci peut également se faire de bien des façons différentes. Les premières étapes, simples, peuvent impliquer la synchronisation de n’importe quel rapport de bogue en amont avec ceux de votre distribution, afin d’être sûr que ce double effort impacte la cause primaire et résolve des bogues. Une implication plus directe consiste à développer des fonctionnalités et à changer plus largement que ce qui serait acceptable dans le cadre d’une version empaquetée.

Conclusion

Je pense que les deux choses essentielles que j’aurais aimé connaître lorsque j’ai commencé sont le sens de la communauté que le logiciel libre fait naître et la merveilleuse voie que le packaging de logiciel libre ouvre vers le plus vaste monde du logiciel libre

La communauté est essentielle au succès du logiciel libre. Elle se présente sous différentes formes, de la multitude d’utilisateurs souhaitant investir du temps dans l’amélioration de votre logiciel, jusqu’aux pairs d’une distribution ou d’un projet logiciel, qui investissent leur temps et leur énergie à affûter vos compétences et à s’assurer que vos contributions sont aussi bonnes que possible.

La voie qui part du packaging pour aller vers le développement est l’une des plus empruntées. Elle présente une courbe d’apprentissage moins raide qu’aborder directement le développement et permet d’acquérir des compétences à un rythme moins soutenu qu’en suivant d’autres chemins.




Dialogue Pouhiou Calimaq sur le domaine public et plus parce qu’affinités

Pouhiou est notre joyeux et émérite premier romancier chez Framabook. À l’occasion de la sortie prochaine du livre II du cycle des NoéNautes, il a lancé une originale campagne de crowdfunding sur Ulule qui a fait réagir le blogueur influent (parce que brillant) Calimaq.

Ce dernier s’est en effet aventuré à parier que si cette campagne aboutissait alors il élèverait lui aussi son blog dans le domaine public via la licence Creative Commons CC-0. Bien mal lui en a pris puisque la campagne vient déjà de dépasser la barre escomptée (Pouhiou vous en remercie en vidéo ici) et se poursuit d’ailleurs…

Chose promise, chose due donc, et prétexte surtout à un passionnant entretien dialogue entre deux personnalités fortes du « Libre » francophone.

Je cède la parole à Pouhiou, et ça tombe bien car il adore la prendre 😉

monorchide-chaton02-ulule.jpg

En lançant le blog de mon roman feuilleton, j’ai eu d’instinct l’envie que cette histoire appartienne à ses lecteurs. Qu’ils s’en emparent. C’était une certitude que je ne savais pas comment appliquer dans les faits. M’intéressant au livre et au droit d’auteur, je suivais déjà le blog S.I.Lex écrit par un certain Calimaq. Ce mec, passionné et passionnant, arrive à transformer un sujet à priori lourd et chiant (la propriété intellectuelle) en une épopée rocambolesque. A force d’exemples, de décryptages, de coups de sang et de coup de cœur, il nous plonge dans les eaux du copy-right-left-up&down, on baigne en Absurdie et l’on ressort de son blog plus juriste qu’on y est rentré… sans même s’en apercevoir.

Un de ses billets m’a fait prendre conscience que la place de mes œuvres était dans le domaine public. J’ai donc passé tous mes écrits sous la licence CC0 et l’ai chaudement remercié dans cet article.

Il est né de cet échange une amitié intellectuelle. Calimaq s’est mis à défendre et mon œuvre, et la démarche qui l’accompagnait. Je me suis engagé dans SavoirsCom1, un collectif qu’il a co-fondé pour la défense des biens communs informationnels. Je ne compte plus les fois où l’on s’est dit « merci », tant chacun semble admirer et être complice de ce que fait l’autre. C’est ce genre d’émulation où la réflexion de l’autre nourrit la tienne, et te mène un poil plus vite, un poil plus loin que là où tu te serais rendu tout seul.

Quand, avec Framasoft, on a initié ce crowdfunding fou (toujours en cours sur Ulule) pour que le lancement de #MonOrchide (livre II des NoéNautes) puisse financer la distribution gratuite d’exemplaires de #Smartarded (le livre I), Calimaq a répondu présent. Il a fait un bel article pour promouvoir cette expérience . Mais, chose inattendue, il a ajouté ce post-scriptum explosif :

PS : allez, moi aussi, je mets quelque chose dans la balance. Si Pouhiou réussit son pari, je passe S.I.lex en CC0. Ceci n’est pas une parole en l’air !

Le pari est réussi. En 22 jours, on a atteint les 2200 € qui nous permettront de distribuer au moins 32 exemplaires de #Smartarded. Grâce à une mobilisation peu commune il ne nous a fallu que la moitié des 45 jours prévus (ce qui veut dire qu’il reste trois semaines pour battre tous les records et accroître le nombre de livres à distribuer !)

Le pari est réussi, et S.I.Lex devient un dommage collatéral : Calimaq tient sa part du contrat, élevant son blog dans le Domaine Public Vivant. Je sais que, le connaissant, ce n’est pas un geste anodin. Une belle occasion de discuter avec lui de licences, d’écriture, et de qu’est-ce que ça veut bien dire, toutes ces choses-là…

2012-12-08_19.23.44.JPG

Pouhiou : Tu m’as fait un super article sur ton blog S.I.Lex, qui a été repris par ActuaLitté. Cela m’a beaucoup aidé à faire connaitre le projet. C’était déjà énorme (merci ^^). Pourquoi avoir en plus ajouté la licence de ton blog dans la balance ?

Calimaq : Cela fait un moment que je m’intéresse à ce que tu fais autour du cycle des Noenautes et d’après ce que tu as écrit sur ton blog, un des billets que j’avais écrit sur S.I.Lex t’avait influencé dans ta décision d’adopter la licence CC0 pour ton premier roman #Smartarded.

Quand j’ai vu que tu lançais cette opération de crowdfunding, j’ai voulu la soutenir et la faire connaître, parce que je trouve qu’elle bouscule la manière dont nous avons l’habitude d’appréhender des notions fondamentales, comme celles du gratuit et du payant. Avec la licence CC0, tu as renoncé à tes droits d’auteur pour que tes œuvres soient complètement libres, tout en réussissant à faire paraître ton roman chez Framabook. C’est déjà en soi assez perturbant pour les schémas habituels. Mais tu ne t’es pas arrêté là et par le financement collaboratif, tu as cherché à faire en sorte qu’un maximum de livres en papier deviennent gratuits afin de pouvoir les offrir.

Le plus intéressant dans ta démarche, je trouve, c’est que derrière ces décisions, il y a un modèle économique bien pensé, qui utilise le crowdfunding pour raccourcir la chaîne de l’auteur au lecteur, dans le but de diminuer les coûts. Tu démontres de manière paradoxale que la gratuité a toujours un coût. C’est typiquement le genre d’approches alternatives qui retiennent mon attention, parce que je trouve qu’elles font avancer la réflexion. Dans le contexte actuel de crispations autour des questions de droit d’auteur, qui sont particulièrement vives dans le secteur du livre, je pense que des initiatives comme les tiennes sont importantes. J’ai aussi beaucoup apprécié la lecture de ton premier roman #Smartarded et j’ai commencé à lire la suite #MonOrchide par petites touches sur ton blog. Tout cela a fait que j’ai voulu te soutenir en écrivant un billet sur S.I.lex et je me réjouis de ta réussite.


Merci ! Mais là tu parles plus de moi que de toi, hein… J’ai bien saisi que ce billet a été un élément déclencheur, mais est-ce qu’il s’agit d’un coup de tête ou est-ce que ça fait partie d’une réflexion personnelle plus… ancienne ?


Au-delà du billet, pourquoi avoir promis de changer la licence de mon blog si ton pari réussissait ? Peut-être d’abord un peu par superstition, pour porter chance à ton projet, en engageant quelque chose qui me tenait vraiment à cœur. Par ailleurs, je me posais des questions à propos de la licence de S.I.Lex depuis un certain temps. À vrai dire depuis le moment où j’ai écrit le billet Rien n’est à nous : grandeur et misère du domaine public volontaire. J’y montrais comment un certain nombre de créateurs dans le passé avaient choisi pour diverses raisons de renoncer aux droits sur leurs œuvres pour se placer en dehors de la logique de la propriété intellectuelle : Léon Tolstoï, Romain Rolland, Jean Giono, les affichistes de mai 68, les situationnistes, le musicien folk Woodie Guthrie.

Le domaine public est une notion qui a un grande importance pour moi et pour laquelle j’essaie de me battre. Il m’a semblé que le moment était venu de franchir le pas et de placer ma propre création, S.I.Lex, dans le domaine public volontaire.

Ton blog était en licence CC-BY (la seule condition de partage est de citer l’auteur). Là tu le passes en CC0. C’est quoi, au fond, la différence ?

Juridiquement dans le cadre du droit français, il n’y a pas tellement de différences. En effet, le Code de Propriété Intellectuelle ne permet pas dans notre pays de renoncer valablement à son droit moral, ce qui signifie qu’on doit théoriquement interpréter la CC0 comme une CC-BY. Je n’ai pas la possibilité légale de renoncer à mon droit à la paternité. Ce caractère inaliénable du droit moral a été voulu pour protéger l’auteur dans le cadre des contrats d’édition. Même dans le cas des « nègres » (ou, plus joliment dit, Ghostwriters en anglais), il reste possible pour eux de réclamer devant un juge la paternité d’un texte écrit pour quelqu’un d’autre, quand bien même ils se seraient engagés par contrat à ne pas révéler leur identité (on a des jurisprudences intéressantes à ce sujet dès le 19ème siècle, notamment dans l’affaire qui opposa Alexandre Dumas à l’un de ses collaborateurs, Auguste Maquet.

Le problème, c’est que l’application trop rigide de ce principe aujourd’hui peut conduire à « protéger » l’auteur contre lui-même, alors qu’il manifeste clairement la volonté de renoncer à ses droits. La licence CC0 a d’ailleurs été obligée de prendre en compte cet état de fait, en précisant que l’auteur renonce à ces droits « dans la mesure permise par la loi ». Cela veut dire que l’effet de la CC0 varie selon les pays : aux États-Unis, où le droit moral n’existe pas vraiment, il est total ; en France, il reste juridiquement incomplet, puisque le droit moral persiste. Le seul pays à l’heure actuelle qui reconnaisse explicitement la possibilité de verser ses œuvres dans le domaine public volontaire, c’est le Chili.

Donc passer de CC-BY (licence déjà très ouverte) à CC0 n’a pas beaucoup d’effets pratiques… tant que la propriété intellectuelle n’est pas réformée en France. Malgré tout, je ne t’imagine pas homme à manier ces licences à la légère. Si passer de la CC-BY au Domaine Public Vivant n’est pas un choix pratique, il est de quel ordre ?

Cette décision revêt à mes yeux une valeur symbolique et psychologique importante, en tant qu’auteur. Je ne suis pas comme toi auteur de littérature ou de théâtre, mais j’ai un rapport profond avec l’écriture. J’écris sur S.I.Lex par besoin viscéral d’écrire et quand je décroche de l’écriture, je périclite littéralement. Pour moi, l’écriture a aussi une importance comme trace que l’on laisse de soi au-delà de son existence. Du coup, le BY – la paternité – gardait une vraie importance à mes yeux, comme une sorte de « cordon ombilical » ou de minimum minimorum du droit d’auteur, dont il était difficile de se détourner. Couper ce cordon en adoptant la CC0 n’était pas anodin et il m’a fallu un certain temps – et un coup de pouce de ta part – pour lâcher prise !


Quel est l’intérêt, pour toi, de mettre de son vivant des textes dans le domaine public ?

Pour moi, l’intérêt principal, c’est de sortir en dehors du cadre du droit d’auteur. Avec les licences libres, on passe de la logique du copyright à celle du copyleft, mais on reste encore dans le système du droit d’auteur. Les licences libres ne sont pas une négation du droit d’auteur, mais une autre manière de le faire fonctionner. Avec la licence CC0, on n’est plus dans le copyright, ni même dans le copyleft, mais littéralement dans le copy-out. On décide sciemment que son œuvre n’est plus saisie par le droit d’auteur et ne doit plus être comprise à travers ce filtre. Je ne prétends pas que cette voie doive être suivie par tous les auteurs. Mais au stade où j’en suis, c’est cohérent avec ma démarche.

Tu dis de ton côté que tu n’as pas l’impression que tes textes ne t’appartiennent pas, mais que tu “digères” des éléments extérieurs que tu restitues par tes écrits. De mon côté, j’ai très tôt été sensible aux effets d’intelligence collective sur la Toile, avec le sentiment que je me devais de rendre à l’intelligence collective ce qu’elle me donne. Il n’y a pas un seul de mes billets qui n’ait été déclenché par les conversations et les échanges dans les flux. Dès lors, le meilleur moyen d’être cohérent avec moi-même, c’est d’opter pour le domaine public volontaire.

Par ailleurs, je pense important de montrer que le domaine public n’est pas seulement une chose du passé, mais qu’il peut être vivant aujourd’hui. En tant qu’auteur de son vivant, contribuer à alimenter le domaine public, c’est la meilleure manière de s’en faire l’ambassadeur et d’agrandir le cercle des biens communs de la connaissance.

OK : on a tous les deux ce souci de cohérence. C’est bien beau d’utiliser une licence parce qu’elle te met en adéquation avec ce que tu ressens de ta production intellectuelle… Mais il y a forcément des pragmatiques qui vont nous traiter d’utopistes ! Ils vont nous rappeler qu’on vit dans un monde où les enjeux commerciaux prévalent et où — selon eux — les circonstances font qu’il vaudrait mieux armer et protéger ses œuvres… D’un point de vue pratique, la clause non commerciale (NC) est un outil redoutable quand la CC0 est une passoire ! Du coup, une licence, c’est la conséquence d’un ressenti théorique ou la résultante d’un besoin pratique d’outil légal ?

C’est sans doute assez souvent le résultat d’un compromis entre les deux. Il faut considérer la situation des auteurs dans leur diversité et de multiples stratégies sont envisageables avec les licences. Les choses peuvent varier également selon les domaines de la création. Quand on voit un Cory Doctorow ou un Lawrence Lessig publier leurs ouvrages chez des éditeurs traditionnels et placer les versions numériques sous CC-BY-NC, je trouve que c’est une stratégie compréhensible et qu’ils ont par ce biais contribué à faire avancer la cause, en diffusant leurs idées dans un large cercle.

Beaucoup de créateurs en revanche ne cherchent pas un retour financier pour les œuvres qu’ils produisent. C’est le cas pour la plupart des amateurs qui créent des contenus sur Internet. Dans ce genre de situation, la réservation de l’usage commercial n’est généralement pas justifiée et choisir cette clause impose des contraintes sans réelle nécessité. Mais dans certaines situations, la clause NC peut constituer un élément intéressant pour permettre la circulation des œuvres tout en mettant en place un modèle économique. Il y a un débat assez vif en ce moment sur la légitimité de la clause NC, notamment telle qu’elle figure dans les licences Creative Commons. Je ne fais pas partie de ceux qui condamnent cette clause de manière systématique et j’ai déjà essayé de montrer que ce serait une erreur selon moi de la supprimer.

Malgré cela, tu n’as jamais mis de clause NC sur ton blog S.I.Lex...

Dans mon propre cas, je n’en vois absolument pas l’intérêt… Mon objectif en écrivant de cette manière est d’être lu par un maximum de personnes. Si certains de mes billets sont repris sur d’autres sites, y compris des sites se livrant à des activités commerciales, cela ne peut qu’augmenter l’exposition de mes écrits. J’ai d’ailleurs toujours fonctionné depuis le lancement de S.I.Lex dans un « écosystème » de sites. Très vite, j’ai eu la chance de voir certains de mes billets repris par le regretté OWNI. Cela a grandement contribué à faire connaître S.I.Lex et à développer mon lectorat. D’autres sites me reprennent régulièrement, comme Actualitté ou plus récemment Slate.fr. J’ai toujours considéré que S.I.lex était une sorte de plateforme de tir, où je posais des écrits qui pouvaient ensuite aller faire leur vie ailleurs. Avec une licence NC, les choses auraient été beaucoup plus compliquées.

La licence CC0 est peut-être une passoire, mais dans les conditions particulières qui sont les miennes comme auteur, elle conviendra parfaitement à ce que je veux faire de mes créations. Même si un éditeur vient publier certains de mes billets sous forme de livre dans un recueil, cela ne fera que contribuer encore à leur diffusion.

Du coup, tu n’exiges plus que l’on te cite comme source de tes écrits… de manière légale, c’est ça ? C’est un peu comme moi en fait : tu ne brandis pas d’arme juridique. Plutôt que de les craindre, tu donnes ta confiance aux personnes qui s’inspireront de (ou diffuseront) tes écrits. Confiance en le fait qu’elles soient assez respectueuses pour citer leur source.

La question qui peut se poser est celle du plagiat, quelqu’un qui viendrait s’approprier certains de mes textes en les publiant sous son nom. C’est une chose qui m’est déjà arrivée une fois et j’avoue que cela m’avait laissé une sensation assez désagréable.

Mais une personne comme l’artiste Nina Paley dit des choses très intéressantes sur les rapports entre le copyright et le plagiat. Elle considère en effet que le droit d’auteur paradoxalement favorise davantage le plagiat qu’il ne l’empêche. Elle explique également que le fait de créditer l’auteur relève en fait d’un système de régulation sociale qui n’a pas nécessairement besoin du droit pour fonctionner. Il s’agit en fait davantage de règles éthiques que des communautés se donnent. Nina Paley place d’ailleurs ses créations dans le domaine public volontaire en utilisant la non-licence Copyheart ou la CC0. Elle dit vouloir en cela faire œuvre de « non-violence légale » et je trouve que c’est un discours inspirant.

Un des pivots du libre, c’est sa viralité. On m’affirme que des processus du type la clause SA ont permis au libre de se développer tel qu’il est aujourd’hui. Pour mon compte, la SA est trop paradoxale. Je dis toujours que la première des libertés c’est de ne pas me lire. Dans la même veine, obliger les gens qui adapteront/traduiront/réécriront/diffuseront mes romans à mettre leur production sous licence libre, ça me semble créer de l’enclosure. Ce serait un peu comme forcer les gens à se vacciner au lieu de leur montrer comme on est mieux une fois bien portant… Et du coup j’aperçois que ton blog S.I.Lex n’était même pas sous clause SA ? Pourquoi ?

C’est une question intéressante et là aussi, je m’étais longuement posé la question lorsque j’avais choisi ma licence.

La clause de partage à l’identique est très importante dans beaucoup de domaines, comme celui du logiciel libre qui est fondé sur cette idée qu’il ne doit pas y avoir de possibilité de supprimer les libertés conférées à tous par la licence. Contrairement à ce que tu dis, je soutiendrais que le SA garantit au contraire qu’il ne puisse jamais y avoir d’enclosure sur une œuvre. Personne ne peut plus s’approprier de manière définitive un contenu placé sous Share-Alike. C’est pourquoi il me semble que c’est un type de licence adapté pour les biens communs que des communautés veulent protéger des risques d’enclosure. Si l’on prend le cas de Wikipédia, la licence CC-BY-SA est parfaitement adaptée, à la fois au travail collaboratif et aux réutilisations des contenus. Elle garantit que cela puisse se faire, même à titre commercial, mais sans réappropriation.

Cependant, je peux comprendre que tu ne veuilles pas placer tes écrits sous le régime du partage à l’identique, et c’est aussi la conclusion à laquelle j’étais arrivé pour S.I.Lex. Si je prends le cas des billets que reprenait OWNI par exemple, les choses auraient été trop compliquées avec une CC-BY-SA. En effet, OWNI reprenait mes billets, mais en les modifiant légèrement. Les journalistes de la plate-forme changeaient généralement le titre, ajoutaient des intertitres, inséraient des illustrations, des vidéos et parfois même des infographies. Il arrivait également que certains de mes billets soient traduits en anglais pour alimenter OWNI.eu. Tout cet apport éditorial était à mes yeux excellents, mais d’un point de vue juridique, il s’agissait d’adaptations de mes créations, ce qui aurait déclenché la clause de partage à l’identique, si j’avais choisi une CC-BY-SA. Or OWNI était sous CC-BY-NC-SA et il n’aurait pas été simple pour eux d’intégrer mes billets si je n’avais pas laissé une grande ouverture avec la CC-BY.

De plus, la CC-BY-SA n’est pas toujours simple à appliquer, comme l’avait prouvé l’affaire qui avait opposé Michel Houellebecq à Wikimedia, lorsque qu’il avait intégré dans son roman La Carte et le Territoire des extraits d’articles de Wikipédia sans mention de la source, ni crédits des auteurs.

Le domaine public et le libre ne sont pas exactement superposables. Le propre du domaine public, c’est de constituer un réservoir complètement ouvert dans lequel on peut venir puiser pour alimenter sa création sans contraintes. Les deux approches sont importantes et complémentaires.

Mais attends, de nous jours, entre les CopyrightMadness, les guerres de brevets, ceux qui s’approprient mon grain de maïs ou ton rectangle à bords arrondis… Avec tous ces abus du côté de la propriété intellectuelle et des biens communs… Y’a pas plus important ou plus urgent que de s’occuper du domaine public ?

Oui, c’est certain qu’il existe des sujets alarmants sur lesquels il devient urgent d’agir. Je ne suis pas seulement engagé pour la défense du domaine public, mais plus globalement pour la promotion des biens communs de la connaissance, ce que je fais au sein du collectif SavoirsCom1. Je milite également aux côtés de la Quadrature du Net pour la légalisation des échanges non-marchands et la mise en place de solutions de financement mutualisées pour la création, comme la contribution créative ou le revenu de base.

Néanmoins, je pense que le domaine public peut constituer un bon angle d’attaque pour s’engager dans une réforme positive de la propriété intellectuelle. On a un peu l’impression d’être aujourd’hui face à une forteresse imprenable et on n’arrive pas à sortir des débats autour de la répression du partage des œuvres, qui continuent à monopoliser l’attention du législateur comme on le voit bien avec les travaux de la mission Lescure. C’est pourquoi il me paraît intéressant d’ouvrir de nouveaux fronts qui permettront de défendre l’idée que nous possédons des droits positifs sur la culture. Le domaine public peut être une piste en ce sens et j’ai fait des propositions de réforme législative pour consacrer et renforcer cette notion dans le Code de Propriété Intellectuelle.

Par ailleurs, tu évoques le Copyright Madness, mais le domaine public pourrait aussi être un moyen de lutter contre les pires dérapages de la propriété intellectuelle. On a vu par exemple récemment des laboratoires pharmaceutiques déposer valablement des brevets en Australie sur les gènes responsables du cancer du sein, ce qui est absolument terrifiant puisque cela signifie que tout chercheur qui voudra mettre au point un remède devra leur verser des royalties. Aux États-Unis, Monsanto a relancé une offensive en justice pour empêcher des agriculteurs de replanter des semences de variétés brevetées et l’entreprise semble en passe de l’emporter. Cela peut avoir des conséquences dramatiques au niveau mondial.

Ces dérives ont un lien avec le domaine public, parce que celui-ci ne contient pas seulement les œuvres anciennes, mais aussi tout ce qui ne devrait pas pouvoir faire l’objet d’une appropriation exclusive. Cela vaut pour certains éléments de la Culture, mais aussi pour des choses aussi essentielles que le génome humain ou les semences.

Le domaine public devrait être le bouclier qui protège tous ces éléments fondamentaux de la folie de l’appropriation, mais c’est à nous de le promouvoir et de le faire vivre pour qu’il puisse remplir ce rôle.

Je crois qu’on ne peut pas trouver de meilleure conclusion ! Merci à toi, Calimaq.

2012-12-08_19.24.39.JPG




7 raisons pour ne pas utiliser les tablettes dans l’éducation

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.

Urban Hippie Love - CC by-sa

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 rédigeant 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 programmatue je passe ion

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 œuvre 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

Une 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’adoption 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 tout cela ne constitue pas une attaque contre 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 de passer 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)




Pas de bol : quand les Américains nous copient c’est pour notre Hadopi !

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 » !

Martin Fisch - CC by-sa

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 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 soit 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 qui ont 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.

Encore raté : 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 « Sois 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 du copyright. 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’œuvre.

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)




Passer de l’exercice scolaire à la maintenance des paquets (Libres conseils 28/42)

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èmes 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 autre 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 rarement 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.




Et si l’ignorance était enrichissante ? (Libres conseils 27/42)

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 ne 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 un 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.