On commence à connaître la chanson et elle est emblématique de l’époque actuelle : le privé qui s’alarme et demande au public de le soutenir sur le dos des biens communs.

Ici nous sommes dans le secteur sensible de l’éducation et pour refuser la priorité aux logiciels libres on est prêt à tout, comme sortir du chapeau la notion pour le moins vague et floue de « neutralité technologique » (sans oublier le FUD sur l’innovation, la croissance, la destruction d’emplois, toussa…)

Le Sénat a en effet examiné cette semaine le projet de loi sur la refondation de l’école de la République. Parmi les dispositions introduites par la commission de la culture, de l’éducation et de la communication, on trouve une modification apportée à l’article 101 qui donne la priorité au logiciel libre et aux formats ouverts dans le futur service public du numérique éducatif.

Pour ceux (comme l’April ou l’Aful) qui se battent depuis des années, voire des décennies, pour qu’il en soit ainsi, c’est déjà un grand pas en avant.

Un pas en avant clairement non partagé par le Syntec Numérique et l’AFINEF (Association Française des Industriels du Numérique dans l’Education et la Formation) qui ont publié dans la foulée un communiqué de presse que nous avons reproduit ci-dessous.

Dans la mesure où les communiqués de l’April, de l’Aful et du Syntec ne proposent pas d’espace de discussion sous article, nous invitons toutes celles et ceux que le sujet intéresse à intervenir dans les commentaires.

PS : Rappelons à l’occasion l’article de Richard Stallman : Pourquoi les écoles devraient utiliser le logiciel libre et l’enseigner.

Numérique éducatif et pédagogique : les professionnels du numérique interpellent le Gouvernement sur le respect de la neutralité technologique

CP du Syntec Numérique et l’AFINEF (22 mai 2013)

URL d’origine du document

Syntec Numérique et l’AFINEF interpellent le Gouvernement sur la mention favorisant de manière prioritaire l’utilisation de logiciels libres pour le service public du numérique éducatif, dans le projet de loi en débat ce mercredi 22 mai au Sénat sur la Refondation de l’Ecole de la République. Syntec Numérique, le syndicat professionnel des industries et métiers du numérique, et l’Association Française des Industriels de l’Education et de la Formation (AFINEF) interpellent le Gouvernement sur les dispositions modifiées du Projet de Loi de Refondation de l’Ecole de la République issues du travail en commission au Sénat, donnant la priorité à l’utilisation de logiciels libres pour le service public du numérique éducatif.

Malgré un avis défavorable du Gouvernement en commission, la rédaction retenue à l’alinéa 7 de l’article 10, « Ce service public utilise en priorité des logiciels libres et des formats ouverts de documents », porte atteinte au principe de neutralité technologique qui est la règle notamment pour la commande et l’achat publics.

Par ailleurs, le rapport annexé à la Loi à l’article 1er, définissant les moyens et les orientations de la refondation de l’école de la République mentionne que « L’incitation au développement de ressources numériques se fera notamment en faveur de contenus et de services numériques dits « libres » ».

Les professionnels du numérique regrettent que ces deux dispositions contredisent la circulaire du premier ministre du 19 septembre 2012 sur les modalités de l’utilisation des logiciels libres dans l’administration tout en portant atteinte au pluralisme des ressources informatiques.

En effet, au moment où le Gouvernement engage une politique d’aide à la création d’une filière d’acteurs français du numérique éducatif et pédagogique, ces dispositions, si elles sont définitivement adoptées, handicaperont gravement les efforts de développement de la plupart des entreprises déjà présentes sur cette filière qui n’a pas encore trouvé sa consolidation et dissuaderont de nouveaux acteurs innovants de s’y engager.

Pour les acteurs du numérique, le pluralisme et la neutralité technologique, adossés à l’interopérabilité, sont les conditions sine qua none afin de s’engager dans le développement des produits et supports technologiques pour répondre à l’enjeu essentiel de la modernisation du service public éducatif et à l’accompagnement des enseignants dans leur investissement pédagogique.

Ils souhaitent par ailleurs alerter les pouvoirs publics sur les conséquences que ces dispositions auraient sur la lisibilité de l’offre e-éducative française à l’international, notamment en direction de continents où le pluralisme et la neutralité technologique conditionnent la pénétration des marchés.

Ils soulignent enfin que ces dispositions évidement inconstitutionnelles, augmenteront le risque de recours contentieux entre les opérateurs privés du secteur et les administrations. En effet, ces dispositions rentrent en contradiction avec les principes d’égalité de traitement et de liberté d’accès à la commande publique, rappelés à l’article 1er du Code des marchés publics et qui ont acquis valeur constitutionnelle (Cons. Const. 26 juin 2003) : « Les marchés publics et les accords-cadres soumis au présent code respectent les principes de liberté d’accès à la commande publique, d’égalité de traitement des candidats et de transparence des procédures. Ces principes permettent d’assurer l’efficacité de la commande publique et la bonne utilisation des deniers publics. Ces obligations sont mises en œuvre conformément aux règles fixées par le présent code ».

Force est de constater que ces dispositions vont en effet à l’encontre du principe de neutralité du droit des marchés publics, qui ne permet aucunement de favoriser des opérateurs économiques au détriment d’autres. Au contraire, les règles de la commande publique ont pour objet de permettre au pouvoir adjudicateur de sélectionner l’offre économiquement la plus avantageuse, correspondant à ses besoins, après une mise en concurrence. Ainsi, écarter la fourniture de certaines solutions, en imposant un type de logiciels, violerait les principes fondamentaux de la commande publique consacrés tant au niveau français qu’européen et jamais démentis.

Syntec Numérique et l’AFINEV en appellent ainsi à la sagesse de la Haute Assemblée et au respect de la feuille de route numérique du Gouvernement, afin de soutenir une filière qui a besoin d’être stimulée par un environnement législatif et juridique stable, et non par des mesures discriminatoires infondées, pour donner la mesure de tout son potentiel, en termes d’innovation, de croissance et de création d’emplois.

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

Comment des hackers adultes peuvent-ils s’assurer de faire émerger une nouvelle génération de hackers libres ?

La réponse d’un père de famille dynamique et avisé 😉

Former la prochaine génération de bidouilleurs open source

Growing the next generation of open source hackers

Dave Neary (Red Hat) – 26 février 2013 – OpenSource.com
(Traduction Framalang : Antoine, cherry, psychoslave, Jeff_, Eijebong, biglittledragoon, goofy, Vero, mathilde, tcit, Quentin, Metal-Mighty, jtanguy, Penguin, Pat, Asta, arnaudbey + anonymes)

En tant que père de trois enfants de 5, 7 et 10 ans, j’ai hâte de partager avec eux les valeurs qui m’ont attiré vers l’open source : partager et créer ensemble des choses géniales, prendre le contrôle de son environnement numérique, adopter la technologie comme moyen de communication plutôt qu’un média de consommation de masse. En d’autres termes :

Comment des bidouilleurs adultes peuvent-ils s’assurer de faire émerger une nouvelle génération de bidouilleurs open source ?

Une des choses que j’ai apprise est qu’il ne faut pas aller trop vite. J’ai mis mes enfants devant Scratch et Sugar à l’âge de 5 et 8 ans, et, bien qu’ils se soient amusés à changer les nombres sur un petit programme que je leur ai montré et aient aimé dessiner leurs propres voitures pour ensuite les diriger sur l’écran, ils étaient trop petits pour comprendre le concept de lier des fonctions entres elles pour arriver à obtenir des comportements plus sophistiqués.

Voici quelques-unes des leçons que j’ai apprises en tant que parent qui, je crois, peuvent être adaptées selon l’âge et les centres d’intérêt de vos enfants.

Un espace à vivre bidouillable

Nous avons encouragé nos garçons à décorer leur chambre, à organiser leurs meubles comme ils voulaient et à avoir leurs propres petits fiefs. Parfois cela nous rend complètement dingues en tant que parents, et, régulièrement, nous devons les aider à ranger, mais leur espace leur appartient.

De même, chaque enfant de plus de 7 ans peut avoir un vrai couteau qu’il peut utiliser pour tailler du bois et couper de la ficelle.

Ingénierie préscolaire

J’adore les jouets qui permettent aux enfants de donner libre cours à leur imagination. En plus c’est génial, parce qu’en tant qu’adulte, je prends autant de plaisir qu’eux à jouer ensemble ! Mes jeux de construction préférés (achetés à peu près au moment où les enfants ont l’habileté nécessaire pour les manipuler) sont les Kapla, les trains en bois, les lots de Duplo, Playmobil, Lego et les voitures Meccano.

Lego et Meccano notamment font un super boulot pour faire des kits adaptés aux enfants de tout âge. Une autre petite astuce est d’encourager le mélange et d’assembler différentes marques de jouets. Nous avons des ponts Kapla passant par-dessus des trains Ikea et des camions Lego qui transportent des personnages Playmobil.

Les Kapla aussi sont très intéressants. Ce sont des planchettes en bois découpées selon des proportions très précises ; elles sont trois fois plus larges qu’épaisses, et cinq fois plus longues que larges. Avec ces simples proportions et la précision des découpes, il est possible de construire des objets très complexes, comme la Tour Eiffel ou une maison Kapla.

Se lancer dans l’électronique

Nous avons un kit Arduino, et mon aîné commence à avoir le niveau pour comprendre comment câbler un circuit, mais il n’a pas encore découvert comment programmer dans le dialecte C propre à Arduino.

Mais même avant quelque chose de ce genre, les arts et les activités artisanales sont un excellent entraînement pour le DIY (NdT : Do It Yourself, c’est-à-dire « Faites-le vous-même »), et nous avons toujours quelques bâtonnets de glaces ou des pinces à linge et un pistolet à colle pour des cadeaux « faits main ».

Puis vous pouvez laisser traîner des tournevis, pinces, multimètres et autres fers à souder, pour que les enfants puissent désosser leurs vieux jouets, ou des appareils électroniques cassés, réparer les choses par eux-mêmes avec de simples circuits électriques, lorsque que quelque chose ne marche pas, et récupérer des pièces détachées pour les intégrer dans leurs futurs projets. Une supervision parentale est recommandée avec le fer à souder jusqu’à ce qu’ils maîtrisent son utilisation.

Apprendre aux enfants à bidouiller

J’adorerais entendre parler de ressources pour que les enfants apprennent à maîtriser la programmation ! Je connais l’existence de la Code Academy et la Khan Academy qui apprennent aux enfants à coder ; et Scratch and Sugar, que j’ai déjà mentionné.

Merci de partager vos propres conseils sur la manière d’endoctriner la prochaine génération de bidouilleurs open source !

Crédit photo : See-Ming Lee (Creative Commons By-Sa)

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 ?

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.

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)

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)

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.

Une vague d’émotion sans précédente s’est emparée du Web (que j’ai l’habitude de lire) après la récente tragique disparition d’Aaron Swartz à l’âge de 26 ans. Il faut dire qu’il en avait fait des choses en une pourtant si courte période !

Nous avons décidé de lui rendre hommage en traduisant collectivement l’un des articles de son blog où il évoque son parcours et ses nombreux projets.

Cet article a été initialement écrit en 2007. Aaron avait alors à peine 20 ans…

Comment dégoter un boulot comme le mien

How to Get a Job Like Mine

Aaron Swartz – 18 août 2008 – Blog personnel
(Traduction : ga3lig, clementd, Amic, tth, bld, KoS, Havok Novak, a_r_n_a_u_d_b, jpcw + anonymous)

L’écrivain américain Kurt Vonnegut avait l’habitude de toujours nommer ses interventions « Comment obtenir un travail comme le mien » pour parler ensuite de ce que bon lui semblait. Je suis plutôt dans la situation inverse. On m’a informé que je pouvais parler de n’importe quel sujet qui m’intéressait et j’ai donc décidé, plutôt que de pontifier sur l’avenir d’Internet ou de la puissance de la collaboration massive, que la discussion la plus intéressante était probablement celle-ci : « Comment bénéficier d’un travail comme le mien » (NdT : ce texte a été rédigé en préparation d’une conférence donnée au congrès informatique Tathva à NIT Calicut en 2007).

Comment ai-je réussi à dégotter ce job ? Sans aucun doute, la première étape a été de faire le bon choix, c’est-à-dire les bons gènes : à la naissance, j’étais un garçon, blanc, et américain. Ma famille était relativement aisée et mon père travaillait dans l’industrie informatique. Hélas, il n’existe à ce jour aucun moyen d’influer sur ce genre de choses donc je ne vous serai probablement d’aucune utilité sur ce point.

En revanche, quand j’ai débuté, j’étais un très jeune gamin coincé dans une petite ville au milieu de la campagne. J’ai donc dû trouver quelques astuces pour m’en sortir. En espérant rendre la vie un peu moins injuste, je me suis dit que je pourrais les partager avec vous.

Étape 1 : apprendre

La première chose que j’ai faite, et qu’a priori vous avez tous déjà faite, c’était d’apprendre des choses à propos des ordinateurs, d’Internet et de la culture Internet. J’ai lu un paquet de livres, j’ai lu une quantité énorme de pages Web et j’ai essayé des trucs. J’ai commencé par rejoindre des listes de diffusion et j’ai essayé de comprendre les discussions jusqu’à ce que je me sente assez à l’aise pour me lancer et y participer à mon tour. Ensuite, j’ai regardé des sites Web et j’ai essayé de construire le mien. À la fin, j’ai appris à construire des applications Web et j’ai commencé à le faire. J’avais treize ans.

Étape 2 : expérimenter

Le premier site que j’ai réalisé s’appelait get.info. L’idée était d’avoir une encyclopédie en ligne gratuite, que chacun pourrait éditer, ou compléter, ou réorganiser à travers son navigateur. J’ai tout développé, ajouté un tas d’options sympas, testé ça sur tous les types de navigateurs et j’en étais très fier. J’ai même remporté un prix pour la meilleure application Web de cette année-là. Malheureusement, les seules personnes que je connaissais à cette époque étaient d’autres jeunes de mon école, donc je n’avais pas grand monde pour écrire des articles d’encyclopédie. (Heureusement, quelques années plus tard, ma mère m’a montré ce nouveau site appelé « Wikipédia » qui faisait la même chose.)

Le second site s’appellait my.info. L’idée était qu’au lieu d’aller à la recherche d’informations sur toutes sortes de pages Web différentes, il suffisait d’avoir un programme qui allait chercher les nouveautés dans toutes ces pages Web et qui les regrouperait à un seul endroit. Je l’ai construit et je l’ai fait marcher, mais il se trouve qu’à l’époque, je n’étais pas le seul à avoir eu ce genre d’idée. Beaucoup de gens travaillaient sur cette nouvelle technique, appelée alors « syndication ». Un groupe d’entre eux s’est mis à part et a décidé de travailler sur une spécification appelée RSS 1.0, et je les ai rejoints.

Étape 3 : échanger

C’était l’été, je n’étais pas à l’école et je n’avais pas de boulot, j’avais donc beaucoup de temps libre à disposition. Et je l’ai entièrement consacré à lire la liste de diffusion de RSS 1.0 et à faire toutes sortes de travaux bizarres et tout ce qu’il y avait d’autre à faire. Assez rapidement, on m’a demandé si je voulais devenir membre du groupe, et je me suis retrouvé être co-auteur, puis co-éditeur de la spécification RSS 1.0.

RSS 1.0 était construit au-dessus d’une technologie appelée RDF, source de débats agités sur les listes de diffusion de RSS. J’ai donc commencé à m’intéresser à RDF, j’ai rejoint les listes de diffusion autour de RDF, lu des choses, posé des questions idiotes pour lentement commencer à comprendre comment ça marchait. Assez rapidement, je devenais connu dans le petit monde du RDF et quand ils ont annoncé la création d’un nouveau groupe de travail destiné à créer la prochaine spécification RDF, j’ai décidé de m’y glisser.

Premièrement, j’ai demandé aux membres du groupe de travail si je pouvais m’y joindre. Ils m’ont répondu négativement. Mais je voulais vraiment faire partie de ce groupe de travail, alors j’ai décidé de trouver un autre moyen. J’ai lu le règlement du W3C, qui expliquait le fonctionnement d’un groupe de travail. Les règles indiquaient que, bien que se réservant le droit de rejeter toute demande d’adhésion individuelle, il suffisait que l’une des organisations faisant partie des membres officiels du W3C sollicite la participation d’un candidat pour qu’elle soit acceptée d’emblée. Ainsi, j’ai examiné en détail la liste des organisations membres du W3C, découvert celle qui me paraissait la plus accessible et lui ai demandé de m’inclure dans ce groupe de travail. Et c’est ce qu’ils ont fait !

Faire partie d’un groupe de travail impliquait des communications téléphoniques hebdomadaires avec les autres membres, un tas de discussions sur des listes de diffusion et sur IRC, de temps à autre de voyager vers d’étranges villes pour des rencontres réelles et une quantité de prises de contact avec des personnes à connaître partout.

J’étais aussi un chaud partisan de RDF, j’ai ainsi œuvré ardemment à convaincre d’autres de l’adopter. Quand j’ai découvert que le professeur Lawrence Lessig lançait une nouvelle organisation appelée Creative Commons, je lui ai transmis un courriel lui conseillant d’adopter RDF pour son projet et lui ai expliqué pourquoi. Quelques jours après, il me répondit : « Bonne idée. Pourquoi ne le ferais-tu pas pour nous ? »

Donc, j’ai fini par rejoindre les Creative Commons, qui m’ont fait m’envoler vers toutes sortes de conférences et de réunions, et je me suis retrouvé en train de rencontrer encore plus de gens. Parmi tous ces gens qui commençaient à savoir qui j’étais, j’en suis arrivé à me faire des amis dans un paquet d’endroits et de domaines différents.

Étape 4 : construire

Puis j’ai laissé tout ça de côté et je suis allé à l’université pour un an. Je suis allé a l’université de Stanford, une petite école idyllique en Californie où le soleil brille toujours, où l’herbe est toujours verte et où les jeunes sont toujours dehors à se faire bronzer. Il y a des enseignants excellents et j’ai sans aucun doute beaucoup appris, mais je n’y ai pas trouvé une atmosphère très intellectuelle étant donné que la plupart des autres jeunes se fichaient apparemment profondément de leurs études.

Mais vers la fin de l’année, j’ai reçu un courriel d’un écrivain nommé Paul Graham qui disait démarrer un nouveau projet, Y Combinator. L’idée derrière Y Combinator était de trouver un groupe de développeurs vraiment talentueux, les faire venir à Boston pour l’été, leur donner un peu d’argent et la base administrative pour lancer une société. Ils travaillent alors très, très dur pour apprendre tout ce dont ils ont besoin de savoir sur le monde des affaires, en les mettant en contact avec des investisseurs, des clients, etc. Et Paul suggéra que je m’inscrive.

Donc je l’ai fait, et après beaucoup de peine et d’efforts, je me suis retrouvé à travailler sur un petit site appelé Reddit.com. La première chose à savoir à propos de Reddit était que nous n’avions aucune idée de ce que nous étions en train de faire. Nous n’avions pas d’expérience dans les affaires, nous n’avions pratiquement pas d’expérience en création de logiciels au niveau qualité d’un produit fini. Et nous n’avions aucune idée si, ou pourquoi, ce que nous faisions fonctionnait. Chaque matin, nous nous levions et nous vérifiions que le serveur n’était pas tombé en panne et que le site ne croulait pas sous les messages indésirables, et que nos utilisateurs étaient toujours présents.

Lorsque j’ai commencé à Reddit, la croissance était lente. Le site avait été mis en ligne très tôt, quelques semaines après avoir commencé à travailler dessus, mais pendant les trois premiers mois, il a difficilement atteint trois mille visiteurs par jour, ce qui représente un minimum pour un flux RSS utilisable. Nous avons ensuite, lors d’une session marathon de codage de quelques semaines, transféré le site de Lisp à Python et j’ai écrit un article sur mon blog au sujet de cet exploit. Il a beaucoup attiré l’attention (même l’enfer ne peut déclencher autant de colère que celle d’un fan de Lisp mécontent) et encore aujourd’hui les gens que je rencontre en soirée, lorsque que je mentionne que j’ai travaillé à Reddit, disent : « Oh, le site qui a migré depuis Lisp. »

C’est à ce moment-là que le trafic a vraiment commencé à décoller. Dans les trois mois qui ont suivi, le trafic a doublé à deux reprises. Chaque matin, nous nous levions pour vérifier les statistiques et voir comment nous nous en sortions, vérifier si une nouvelle fonctionnalité que nous avions lancée nous avait attiré plus de monde, ou si le bouche à oreille continuait de faire parler de notre site, ou encore si tous nos utilisateurs nous avaient abandonnés. Et, chaque jour, le nombre de visiteurs progressait. Mais nous ne pouvions nous empêcher d’avoir l’impression que la croissance du trafic était encore plus rapide lorsque nous arrêtions de travailler sur le site.

Nous n’avions toujours pas d’idée sur la façon de gagner de l’argent. Nous avons vendu des t-shirts sur le site, mais, chaque fois, l’argent récupéré sur la vente servait à racheter encore plus de t-shirts. Nous avons signé avec un acteur majeur de la publicité en ligne pour vendre de la publicité sur notre site, mais cela n’a guère fonctionné, en tout cas pas pour nous, et il était rare que nous touchions, en réalité, plus de deux dollars par mois. Une autre idée était de commercialiser, sous licence, le savoir-faire « Reddit » pour permettre à d’autres de monter des sites sur le modèle Reddit. Mais nous n’avons trouvé personne d’intéressé pour acquérir notre licence.

Rapidement, Reddit a acquis des millions d’utilisateurs chaque mois, un chiffre qui dépasse de loin le magazine américain moyen. Je le sais, car j’ai discuté, à cette période, avec de nombreuses maisons d’édition. Ils se sont tous demandés comment le charme de Reddit pourrait opérer pour eux.

De plus, les sites d’actualités en ligne ont commencé à voir que Reddit pourrait leur envoyer un énorme trafic. Ils ont pensé, d’une certaine manière, encourager cela en ajoutant un lien « reddit this » à tous leurs articles. Pour autant que je sache, ajouter ces liens n’améliore pas vraiment votre chance de devenir populaire sur Reddit (bien que cela rende votre site plus moche), mais cela nous a offert beaucoup de publicité gratuite.

Assez rapidement, la discussion avec nos partenaires se dirigeait vers une négociation d’acquisition. L’acquisition : la chose dont nous avions toujours rêvé ! Il n’y aurait plus à s’inquiéter de faire du profit. Des entreprises externes se chargeaient de cette responsabilité en contrepartie de faire notre fortune. Nous avons tout laissé tomber pour négocier avec nos acheteurs. Et ensuite, cela est resté à l’abandon.

Nous avons négocié pendant des mois. Au début, nous débattions sur le prix. Nous préparions des « business plans » et des feuilles de calcul, puis allions au siège social pour faire des présentations et affronter des réunions et des appels téléphoniques sans fin. Finalement, ils refusèrent notre prix et nous sommes donc repartis. Plus tard, ils changèrent d’attitude, nous nous sommes serrés la main et nous étions d’accord sur la transaction pour finalement commencer à renégocier sur certains autres points cruciaux, et nous éloigner à nouveau. Nous avons dû nous retirer trois ou quatre fois avant d’obtenir un contrat acceptable. Au final, nous avons dû arrêter de travailler efficacement pendant six mois.

Je commençais à devenir malade d’avoir à consacrer autant de temps à l’argent. Nous commencions tous à être affectés par le stress et le manque de travail productif. Nous avons commencé à nous disputer et ensuite à ne plus nous parler, avant de redoubler d’efforts pour retravailler ensemble, pour retomber finalement dans nos errements. L’entreprise a failli se désintégrer avant que la transaction ne se concrétise.

Mais finalement, nous sommes allés chez nos avocats pour signer tous les documents et le lendemain matin, l’argent était sur nos comptes. C’était terminé.

Nous nous sommes tous envolés pour San Francisco et avons commencé à travailler dans les bureaux de Wired News (nous avions été rachetés par Condé Nast, une grande entreprise de publication qui possède Wired et de nombreux autres magazines).

J’étais malheureux. Je ne pouvais pas supporter San Francisco. Je ne pouvais pas supporter une vie de bureau. Je ne pouvais pas supporter Wired. J’ai pris de longues vacances de Noël. Je suis tombé malade. J’ai pensé à me suicider. J’ai fui la police. Et quand je suis revenu le lundi matin, on m’a demandé de démissionner.

Étape 5 : liberté

Les quelques premiers jours sans travail ont été bizarres. Je tournais en rond chez moi. Je profitais du soleil de San Francisco. Je lisais quelques livres. Mais rapidement, j’ai senti que j’avais besoin, à nouveau, d’un projet. J’ai commencé à écrire un livre. Je désirais collecter toutes les bonnes études dans le domaine de la psychologie pour les raconter, non pas comme des analyses, mais comme des histoires. Chaque jour, je descendais à la bibliothèque de Stanford pour y faire des recherches. (Stanford est une école réputée en psychologie.)

Mais un jour, Brewster Kahle m’a appelé. Brewster est le fondateur de The Internet Archive, une organisation formidable qui essaye de numériser tout ce qu’elle trouve pour le publier sur le Web. Il m’a dit qu’il voulait démarrer un projet dont nous avions parlé à l’époque. L’idée serait de rassembler l’information de tous les livres du monde dans un lieu unique, un wiki libre. Je me suis mis immédiatement au travail, et dans les quelques mois qui ont suivi, j’ai commencé à contacter les bibliothèques, mettre à contribution des programmeurs, cogiter avec un designer et faire plein d’autres trucs pour mettre ce site en ligne. Ce projet a fini par devenir Open Library. Il a été développé en grande partie par un talentueux programmeur indien : Anand Chitipothu.

Un autre ami, Seth Roberts, a suggéré que nous devrions trouver le moyen de réformer le système des études supérieures. Nous n’arrivions pas à nous mettre d’accord sur une solution satisfaisante, mais nous avons eu une autre bonne idée : un wiki qui explique aux étudiants à quoi ressemblent les différents métiers. Ce site va être bientôt lancé…

Ensuite, un autre ancien ami, Simon Carstensen, m’a envoyé un e-mail disant qu’il avait obtenu son diplôme universitaire et qu’il cherchait à monter une entreprise avec moi. En fait, j’avais gardé une liste d’entreprises qui pourraient être d’excellentes idées et j’ai pris la première de la liste. L’idée était de créer un site Web aussi simple à remplir qu’un champ texte. Pendant les mois suivants, nous avons travaillé d’arrache-pied à rendre les choses de plus en plus simples (et un peu plus complexes aussi). Le résultat, avec le lancement il y a quelques semaines, est le site : Jottit.com.

Je me suis aussi engagé en tant que conseiller pour deux projets du Summer of Code, les deux étant étonnamment ambitieux et avec un peu de chances, ils devraient être lancés bientôt.

J’ai décidé également alors de m’impliquer dans le journalisme. Mon premier article papier vient d’être publié.

J’ai aussi lancé quelques blogs sur la science et j’ai commencé à travailler à rédiger un article académique moi-même. Il se base sur une étude que j’avais conduite il y a quelques temps sur les rédacteurs effectifs de Wikipédia. Quelques personnes, y compris Jimmy Wales, qui est en quelque sorte le porte-parole de Wikipédia, affirmait que Wikipédia n’était pas, tout compte fait, un projet massivement collaboratif, mais était plutôt rédigé par une équipe d’à peu près 500 auteurs, qu’il connaissait pour la plupart. Il avait fait quelques analyses simples pour le mettre en évidence, mais j’ai vérifié attentivement les chiffres et j’arrive à la conclusion inverse : la grande majorité de Wikipédia a été écrite par de nouveaux rédacteurs, la plupart ne s’étant pas donné la peine de créer un compte, ajoutant quelques phrases de ci de là. Comment Wales a-t-il pu commettre une telle erreur ? Il a analysé le nombre de modifications effectuées par chaque auteur sans vérifier la nature de ces modifications. Or la grande majorité de leurs modifications sont tout à fait mineures : ils font des choses comme des corrections orthographiques ou des remises en forme. Il semble plus raisonnable de croire que ces 500 personnes se comportent plus comme des inspecteurs que comme des producteurs de contenu.

Derniers conseils

Quel est le secret ? Comment pourrais-je condenser les choses que je fais dans des phrases concises qui me correspondent le plus ? Allons-y :

1. Soyez curieux. Élargissez vos lectures. Essayez de nouvelles choses. Je pense que ce que beaucoup de gens appellent intelligence n’est rien d’autre que de la curiosité ;
2. Dites oui à tout. J’ai quelques difficultés à dire non, à un niveau pathologique, quels que soient les projets, les interviews ou les amis. Du coup, j’essaie beaucoup et même si ça se solde souvent par un échec, j’ai toujours fait quelque chose ;
3. Faites comme si les autres n’avaient pas la moindre idée de ce qu’ils sont en train de faire. Une foule de gens hésite à tenter une action pour la simple raison qu’ils pensent qu’ils n’en savent pas suffisamment sur le sujet ou parce qu’ils supposent que d’autres l’ont fait avant eux. Eh bien, peu de gens ont la moindre idée de la manière de mener une action et ils sont même encore moins nombreux à expérimenter de nouvelles méthodes, donc en général si vous faites de votre mieux sur quelque chose, vous le ferez plutôt bien.

J’ai suivi cette ligne de conduite. Et voilà où j’en suis aujourd’hui, avec une douzaine de projets en tête et mon niveau de stress toujours au plus haut.

Chaque matin, je me lève et vérifie mes courriels pour savoir lequel de mes projets a implosé aujourd’hui, quelle date limite a été dépassée, quels discours je dois préparer et quels articles doivent être rédigés.

Un jour, peut-être, vous aussi serez dans la même situation. Si tel est le cas, j’espère que j’y aurai modestement contribué.

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

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

Libres conseils (1/42)

Traduction framalang peupleLa, tibs, Astalaseven, aKa, lerouge, Vilnus Atyx, liu qihao, Cyrille L., Khyvodul, jcr83, jcr83, Goofy, Gatien Bovyn, Antoine, lamessen, AlBahtaar + 2 anonymes

Première Partie, Idées et innovations

1. Du code avant toute chose

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

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

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

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

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

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

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

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

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