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.

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.

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

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

Prendre de la distance pour atteindre l’excellence

Jono Bacon

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

Jono Bacon au tableau blanc

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

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

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

… Toujours avec moi ? OK, allons-y.

La science contre l’art

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

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

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

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

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

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

Réfléchir

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

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

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

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

L’importance des convictions

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

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

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

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

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

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

Votre rôle

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

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

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

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

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

Écouter

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

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

Temps de travail contre temps libre

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

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

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

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

Ne voyagez pas trop

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

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

La planification

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

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

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

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

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

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

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

Perception et conflit

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

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

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

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

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

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

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

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

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

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

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

Maintenant, le problème. Je prends la liberté de l’expliquer dans les termes de l’article lui-même :

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

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

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

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

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

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

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

Pour conclure

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

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

1 http://artofcommunityonline.org

2 http://communityleadershipsummit.com

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

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

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

Comment ne pas lancer une communauté

Robert Kaye

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

L’armée d’Aaron

Aaron’s Army

Carl Malamud – 24 janvier 2013 – PublicRessource.org
(Traduction : brandelune, aKa, Lamessen, KoS, Pouhiou, Garburst, Luc, Tr4sK, Astalaseven)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

Quelques réflexions sur le logiciel open source

A few thoughts about Open Source Software

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

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

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

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

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

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

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

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

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

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

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

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

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

Un article fort intéressant de Benjamin Mako Hill (que nous traduisons souvent) qui apporte un éclairage nouveau à la différence importante entre « logiciel libre » et « open source ».

C’est bien la question de la liberté des utilisateurs qui est fondamentale ici. À mesure que la technologie avance et que de plus en plus de domaines expérimentent « le Libre », elle rejoint tout simplement la liberté des citoyens…

Remarque : C’est d’ailleurs pourquoi nous regrettons « l’abus d’open source » dans les premiers États Généraux de l’Open Source qui se déroulent actuellement à Paris (cf ce tweet ironique).

Liberté pour les utilisateurs, pas pour les logiciels

Freedom for Users, Not for Software

Benjamin Mako Hill – 23 octobre 2011 – Blog personnel
(Traduction : Munto, VifArgent, aKa, KarmaSama, Lycoris, aaron, PeupleLa, bruno + anonymous)

En 1985, Richard Stallman a fondé le mouvement du Logiciel Libre en publiant un manifeste qui proposait aux utilisateurs d’ordinateurs de le rejoindre pour défendre, développer et diffuser des logiciels qui garantissent aux utilisateurs certaines libertés. Stallman a publié la « Définition du Logiciel Libre » (Free Software Definition ou FSD) qui énumère les droits fondamentaux des utilisateurs concernant les logiciels.

• La liberté d’exécuter le programme, pour n’importe quel usage ;
• la liberté d’étudier le fonctionnement du programme et de l’adapter à ses besoins ;
• la liberté d’en redistribuer des copies pour aider les autres ;
• la liberté d’améliorer le programme et de rendre publiques les améliorations, afin que la communauté entière puisse en bénéficier.

Stallman est informaticien. Il avait compris que la manière dont les programmeurs concevaient les logiciels pouvait influer sur les possibilités des utilisateurs à interagir avec eux. Par exemple, des programmeurs pourraient concevoir des systèmes qui espionnent les utilisateurs, vont à leur encontre ou créent des dépendances. Dans la mesure où les ordinateurs occupent une place de plus en plus importante dans la communication des usagers, et dans leur vie toute entière, leur expérience est de plus en plus sous le contrôle de la technologie, et par conséquent de ceux qui la maîtrisent. Si le logiciel est libre, les utilisateurs peuvent désactiver les fonctionnalités cachées ou abusives et travailler ensemble à l’amélioration et au contrôle de leurs technologies. Pour Stallman, le logiciel libre est essentiel à une société libre.

Hélas, beaucoup de personnes qui entendent « logiciels libres » (NdT : free software en anglais) pensent que le mot libre (free) veut dire qu’il peut être distribué gratuitement – une confusion bien naturelle puisque les logiciels libres peuvent être, et sont le plus souvent, partagés sans permission expresse ni paiement. Dans des tentatives concertées pour démêler cette confusion, le slogan « free as in free speech not as in free beer » (free comme dans la liberté de parole et non comme une bière gratuite), et la référence à la distinction que l’on fait en français entre libre et gratuit, sont devenus des clichés dans la communauté du logiciel libre. Une biographie de Stallman est d’ailleurs intitulée « Free as in Freedom » (NdT : Libre comme dans Liberté, biographie traduite et publiée par Framasoft dans sa collection Framabook).

À la fin des années 90, un groupe de passionnés de logiciels libres a suggéré un nouveau terme : « open source ». À l’instar de Stallman, ce groupe était agacé par l’ambiguïté autour du mot « free ». Cependant, la principale préoccupation du groupe open source était l’utilité du logiciel libre pour les entreprises.

Plutôt que de mettre en avant la « liberté », qui pouvait, selon eux, rebuter des entreprises commerciales, les promoteurs de l’open source décrivaient les bénéfices techniques que l’« ouverture » du développement de logiciels libres pourrait apporter, grâce à la collaboration de nombreux utilisateurs mis en réseau. Ces appels ont trouvé un écho au sein des entreprises high-tech à la fin du millénaire au moment où le système d’exploitation libre GNU/Linux gagnait en popularité et où le serveur web Apache dominait un marché bondé de concurrents propriétaires. Le concept « open source » prit un nouvel élan en 1998 quand Netscape rendit public le code source de son navigateur web Navigator.

Malgré des différences rhétoriques et philosophiques, les logiciels libres et les logiciels open source font référence aux mêmes programmes, aux mêmes communautés, aux mêmes licences et aux mêmes pratiques. La définition de l‘open source est presque une copie conforme des directives du logiciel libre publiées par la communauté Debian qui sont elles-mêmes une tentative de redéfinir la déclaration de Stallman sur la Définition du Logiciel Libre. Stallman a décrit cette distinction entre « logiciel libre » et « logiciel open source » comme étant le contraire d’un schisme. Dans un schisme, deux groupes religieux auront des cultes séparés, souvent à cause de désaccords mineurs sur des points de liturgie ou de doctrine. Dans le logiciel libre et l‘open source, les deux groupes se sont articulés autour de philosophies, de principes politiques et de motivations qui sont fondamentalement différentes. Et pourtant les deux parties continuent de travailler en étroite collaboration au sein des mêmes organisations.

Les conversations autour du libre et du gratuit dans les communautés du logiciel libre et de l‘open source ont occulté un second niveau d’ambiguïté dans le terme « logiciel libre », bien moins discuté : le terme a conduit à croire qu’il fallait interpréter les quatre libertés comme des déclarations sur les qualités que les programmes eux-mêmes devraient posséder. Stallman se fiche du logiciel libre en tant que tel, ce qui lui importe c’est la liberté des utilisateurs. Les slogans « free as in freedom » et « free speech not free beer » n’aident en rien à résoudre ce second type d’ambiguïté, et créent même de la confusion. « Free as in freedom » ne dit rien sur ce qui devrait être libre, tandis que « free speech not free beer », reproduit un problème similaire : les défenseurs de la liberté de parole ne défendent pas tant la liberté d’expression en tant que telle que la liberté des individus dans leur parole. Quand pour l’essentiel le discours des promoteurs du logiciel libre insiste sur les caractéristiques des programmes, certains en viennent à considérer la liberté de l’utilisateur comme un problème de second ordre – c’est tout simplement ce qui se produit lorsque le logiciel est libre.

Quand le logiciel est libre, mais pas les utilisateurs

La liberté de l’utilisateur ne découle pas toujours de la liberté du logiciel. En effet, le logiciel libre a pris de l’importance dans les domaines économique et politique : cela a suscité l’intérêt de certaines personnes qui souhaitaient en récolter les bénéfices tout en maintenant l’action et l’indépendance des utilisateurs dans des limites.

Google, Facebook, et autres titans de l’économie du Web ont bâti leur entreprise sur les logiciels libres. En les utilisant ils n’agissent pas seulement en passagers clandestins, dans de nombreux cas ces firmes partagent gratuitement, au minimum, une partie du code qui fait fonctionner leurs services et investissent des ressources conséquentes dans la création ou l’amélioration de ce code. Chaque utilisateur d’un réseau basé sur des logiciels libres peut posséder une copie du logiciel qui respecte les quatre libertés de la FSD. Mais à moins que ces utilisateurs n’exécutent le service web eux-mêmes- ce qui peut s’avérer techniquement ou économiquement infaisable – ils restent sous la coupe des firmes qui, elles, font bel et bien fonctionner leurs copies. Le « Logiciel en tant que Service » (Software as a Service, ou SaaS) – ou logiciel fourni via « le cloud » – est à priori entièrement compatible avec le principe d’un logiciel libre. Toutefois, du fait que les utilisateurs du service ne peuvent pas changer le logiciel ou l’utiliser comme ils le souhaitent sans l’autorisation et la surveillance de leur fournisseur de service, les utilisateurs de SaaS sont au moins aussi dépendants et vulnérables qu’ils le seraient si le code était fermé.

Chrome OS de Google est une tentative pour construire un système d’exploitation qui pousse les utilisateurs à être constamment en ligne et à utiliser des services comme Google Docs pour réaliser la plupart de leurs tâches informatiques. Quand Google a annoncé Chrome OS, nombreux étaient ceux qui ont applaudi dans la communauté du logiciel libre ; Chrome OS est en effet basé sur GNU/Linux, il s’agit presque entièrement de logiciel libre, et il avait l’appui de Google. Mais le but réel de Chrome OS est de changer l’endroit où les utilisateurs réalisent leurs tâches informatiques, en remplaçant les applications que l’utilisateur aurait fait tourner sur sa machine par des SaaS sur Internet. Chaque fois qu’on remplace un logiciel libre du bureau par un SaaS, on passe d’une situation où l’utilisateur avait le contrôle sur ses logiciels à une situation où il n’a pratiquement plus aucun contrôle. Par exemple, l’utilisation que fait Google des logiciels libre dans les services SaaS lui permet de surveiller tous les usages et d’ajouter ou retirer des fonctionnalités selon son bon vouloir. Ainsi, en se concentrant sur la liberté des logiciels et non sur celle des utilisateurs, bien des partisans du logiciel libre n’ont pas su anticiper cette inquiétante dynamique.

TiVo – le pionnier des magnétoscopes numériques – présentait un défi différent. Son système se basait sur GNU/Linux et, conformément à la licence « copyleft » sous laquelle sont distribués la plupart des logiciels libres, la société TiVo autorisait l’accès complet à son code source. Mais TiVo utilisait le chiffrage pour verrouiller son système afin qu’il ne s’exécute que sur des versions approuvées de Linux. Les utilisateurs de TiVo pouvaient étudier et modifier le logiciel TiVo, mais ils ne pouvaient pas utiliser ce logiciel modifié sur leur TiVo. Le logiciel était libre, les utilisateurs ne l’étaient pas.

Les SaaS, Chrome OS et la Tivoisation sont des sujets qui continuent de remuer le milieu des logiciels libres et open source et mettent à jour des lignes de fracture. Il n’est guère surprenant que les partisans de l‘open source ne voient aucun problème avec les SaaS, Chrome OS et la Tivoisation ; ils ne sont pas engagés dans la liberté des utilisateurs ou du logiciel. Toutefois chacun de ces exemples a été facteur de division, y compris parmi les personnes qui pensaient que le logiciel devrait être libre. La Fondation du Logiciel Libre (Free Software Foundation, FSF) a pris explicitement position contre chacun des sujets ci-dessus. Mais il a fallu du temps avant d’identifier chacune de ces menaces et ce fut laborieux de réussir à faire passer le message aux sympathisants. Aujourd’hui, il semble probable que Google et son modèle d’entreprise orienté service représentent une plus grande menace pour la liberté des futurs utilisateurs d’ordinateur que ne l’a été Microsoft. Mais comme Google se conforme scrupuleusement aux termes de la licence du logiciel libre et contribue aux projets de logiciels libres par une grande quantité de code et d’argent, les partisans du logiciel libre ont mis du temps à l’identifier comme une menace et à réagir.

Même la Free Software Foundation continue à se battre avec sa propre mission axée sur le logiciel. Stallman et la FSF ont travaillé ces dernières années pour déplacer du code non-libre qui s’exécute sur les périphériques internes des ordinateurs (par exemple, une carte wifi ou une carte graphique intégrée à l’intérieur d’un portable) depuis le disque dur principal de l’ordinateur vers les sous-processeurs eux-mêmes. L’idée derrière ces efforts est d’éliminer le code non-libre en le basculant vers les composants matériels. Mais les utilisateurs des logiciels sont-ils plus libres si les technologies propriétaires, qu’ils ne peuvent changer, existent dans leur ordinateur sous une forme plutôt qu’une autre ?

La clé pour répondre à cette question – et à d’autres -, c’est de rester concentré sur ce qui distingue libre et ouvert. Les promoteurs du logiciel libre doivent revenir à leur objectif premier : la liberté des personnes, et non celle des logiciels. L’apport fondamental de Stallman et du mouvement libre a été de relier les questions de la liberté et de l’autonomie personnelle à d’autres considérations, quoique ce lien ne soit pas évident pour beaucoup. La manière dont les utilisateurs resteront libres évoluera avec les changements de nature de la technologie. Et alors que certains adaptent les principes du logiciel libre à de nouveaux domaines, ils vont se retrouver confrontés à des problèmes de traduction comparables. Selon le soin que portera notre communauté à distinguer entre les différents mode d’ouverture et à mettre en évidence les questions de contrôle, de politique et de pouvoir, la philosophie du logiciel libre restera pertinente dans toutes ces discussions plus générales autour des nouveaux et différents biens communs – dans les logiciels et au delà.

Crédit photo : David Shankbone (Creative Commons By)