Difficile de nos jours de faire nos achats sans être traçables ! Pourtant nos parents pouvaient effectuer leurs transactions en liquide sans laisser de traces inutiles. Que restera-t-il de cette liberté pour nos enfants ?
Voici déjà le 11e article de la série écrite par Rick Falkvinge. Le fondateur du Parti Pirate suédois s’inquiète aujourd’hui la fin de l’anonymat dans nos achats en raison des moyens électroniques de paiement.
Le fil directeur de la série de ces 21 articles, comme on peut le voir clairement dans les épisodes précédents que nous vous avons déjà livrés, c’est la perte de certaines libertés dont nous disposions encore assez récemment, avant que le passage au tout-numérique ne nous en prive.
L’argent « anonyme » de nos parents de l’ère analogique est en train de disparaître rapidement et dans la foulée s’imposent les cartes de crédit traçables et soumises à autorisation, pour nos enfants. Bien qu’elles soient pratiques, c’est un loup dans la bergerie.
Dans un article précédent, nous avons évoqué comment nos parents pouvaient acheter de façon anonyme un journal dans la rue en échange de quelques pièces et lire les actualités de leur choix sans que personne ne soit au courant. Cette observation s’applique bien au-delà des journaux, bien entendu.
Ce pouvoir qu’avaient nos parents, celui d’effectuer des transactions décentralisées, sécurisées et de façon anonyme, a été perdu dans un contexte qui pousse aux paiements par carte pour des raisons de facilité. La facilité de ne pas payer tout de suite avec les cartes de crédits à la consommation, la facilité de toujours payer une somme exacte avec les cartes de crédit, la facilité de ne pas avoir à transporter et trouver les sommes exactes en liquide à chaque achat. Certains pourraient même ajouter que tenir ses comptes est plus facile quand chaque transactions est listée dans un relevé bancaire.
Mais avec la tenue de comptes vient la traçabilité. Avec la traçabilité vient la prévisibilité et la possibilité peu désirable de devoir rendre des comptes.
On dit qu’un employé de VISA peut prévoir un divorce un an avant les parties concernées, en observant les changements dans les habitudes d’achat. Tristement célèbre, un magasin Target a ciblé une lycéenne avec des publicités pour des articles de maternité, ce qui a tout d’abord rendu son père furieux. Mais il s’est avéré que la jeune femme était effectivement enceinte. Target le savait, mais pas son propre père1.
Cela est dû au fait que lorsque nous n’utilisons plus d’argent liquide anonyme, chaque achat est tracé et enregistré dans l’intention expresse d’être utilisé contre nous, que ce soit pour nous influencer à faire le choix de nous vider de nos ressources (« acheter plus ») ou pour nous punir d’avoir acheté un article que nous n’aurions pas dû acheter, avec une grande diversité de moyens possibles.
La Chine pousse le concept encore plus loin comme on l’a déjà noté et, dans ce qui a dû inspirer un épisode de Black Mirror, évalue le Score d’Obéissance de ses citoyens selon qu’ils font des achats superflus ou utiles – utiles du point de vue du régime, bien sûr.
Ce n’est pas seulement le fait que les transactions de nos enfants de l’ère numérique sont enregistrées pour être utilisées contre eux ultérieurement, par des mécanismes que nos parents de l’ère analogique n’auraient jamais pu imaginer.
C’est aussi que les transactions de nos enfants sont soumises à autorisation. Quand nos enfants du numérique achètent une bouteille d’eau avec une carte de crédit, une transaction est autorisée quelque part en arrière-plan. Mais cela veut aussi dire que quelqu’un peut décider de ne pas autoriser la transaction. Quelqu’un a le droit de décider arbitrairement ce que les gens peuvent ou ne peuvent pas acheter, si cette tendance se confirme pour nos enfants. C’est une pensée qui fait froid dans le dos.
Nos parents utilisaient des transactions décentralisées, résistantes à la censure et anonymes grâce à l’argent liquide ordinaire. Aucune raison ne justifie que nos enfants aient à se contenter de moins. Il s’agit de liberté et d’autodétermination.
La vie privée demeure de votre responsabilité.
Des routes et des ponts (11) – Les défis de la maintenance
Dans ce onzième chapitre de son ouvrage Des routes et des ponts que l’équipe Framalang vous traduit semaine après semaine (si vous avez raté le début), Nadia Eghbal aborde le problème endémique des infrastructures numériques open source, leur manque de ressources humaines pérennes : entre ceux qui s’y consacrent à corps perdu et s’arrêtent au bord du burnout, les entreprises qui profitent des ressources sans jamais contribuer en retour, ceux qui se lancent ingénument dans le développement sans notion bien nette de sécurité, ceux qui ne peuvent contribuer que sur un temps libre limité… Des témoignages sur ces situations et d’autres encore ont été recueillis dans ce chapitre.
Comme le souligne l’autrice, cette situation bancale a pour conséquence un coût important en termes d’argent et de sécurité pour l’ensemble de l’industrie numérique qui puise abondamment dans l’infrastructure numérique open source.
Comme nous l’avons vu, l’infrastructure numérique est un constituant essentiel du monde actuel. Notre société repose sur les logiciels, et ces logiciels s’appuient de plus en plus sur une infrastructure qui utilise des méthodologies open source. Dans la mesure où nous prenons peu d’initiatives pour comprendre et pérenniser notre infrastructure numérique, que mettons-nous en péril ?
Ne pas réinvestir dans l’infrastructure numérique présente des dangers que l’on peut classer en deux catégories : les coûts directs et les coûts indirects.
Les coûts directs
Les coûts directs sont les bogues non détectés et les vulnérabilités de sécurité qui peuvent être exploitées à des fins malveillantes, ou qui mènent à des interruptions imprévues dans le fonctionnement des logiciels. Ces coûts sont fortement ressentis et causent des problèmes qui doivent être résolus immédiatement.
Les coûts indirects
Les coûts indirects se traduisent par exemple par la perte de main-d’œuvre qualifiée, ainsi qu’une croissance faible et peu d’innovation. Même si ces coûts ne sont pas immédiatement perceptibles, ils représentent une valeur sociale difficile à évaluer.
Bogues, failles de sécurité et interruptions du service
L’introduction de ce rapport relatait les détails de la faille de sécurité Heartbleed, qui a été découverte en avril 2014 dans une bibliothèque logicielle appelée OpenSSL. Du fait de son usage généralisé, notamment pour le fonctionnement de nombreux sites web majeurs, Heartbleed a largement attiré l’attention du public sur le problème des failles de sécurité des logiciels.
En septembre 2014, une autre faille majeure a été découverte dans un autre outil essentiel appelé Bash. Bash est inclus dans des systèmes d’exploitation populaires tels que Linux et Mac OS, ce qui fait qu’il est installé sur 70 % des machines connectées à internet.
L’ensemble de bugs de sécurité, surnommés « ShellShock », peuvent être exploités pour permettre un accès non autorisé à un système informatique. Les vulnérabilités étaient restées non-détectées pendant au moins une décennie. Bash a été créé à l’origine par un développeur appelé Brian Fox en 1987, mais depuis 1992 il est maintenu par un seul développeur, Chet Ramey, qui travaille comme architecte technique senior à la Case Western University dans l’Ohio.
Un autre projet, OpenSSH, fournit une suite d’outils de sécurité dont l’usage est largement répandu sur internet. Des développeurs ont trouvé de multiples failles dans son code qui ont pu être prises en charge et corrigées, y compris celle de juillet 2015, qui permettait aux attaquants de dépasser le nombre maximal d’essais sur les mots de passe, et celle de janvier 2016, qui laissait fuiter les clefs de sécurité privées.
L’un des aspects du problème est que beaucoup de projets sont des outils anciens, développés au départ par un ou plusieurs développeurs passionnés, qui ont par la suite manqué de ressources pour gérer le succès de leur projet. Avec le temps, les contributions diminuent et les acteurs restants se lassent et s’en vont, mais pour autant le projet est toujours activement utilisé, avec seulement une ou deux personnes tâchant de le maintenir en vie.
Un autre problème croissant dans le paysage des logiciels actuel, où l’on voit tant de jeunes développeurs inexpérimentés, c’est que les concepts de sécurisation ne sont pas enseignés ou pas considérés comme prioritaires. Les nouveaux développeurs veulent simplement écrire du code qui marche. Ils ne savent pas faire un logiciel sécurisé, ou pensent à tort que le code public qu’ils utilisent dans la sécurité de leurs programmes a été vérifiée. Même les bonnes pratiques de divulgation sécurisée ou de gestion des failles ne sont généralement pas enseignées ni comprises. La sécurité ne devient un enjeu que lorsque le code d’un développeur a été compromis.
Christopher Allen a coécrit la première version du protocole de transfert sécurisé TLS (Transport Layer Security), dont les versions successives sont devenues un standard utilisé quasiment universellement en ligne, y compris sur des sites comme Google, Facebook ou YouTube. Bien que le protocole soit devenu un standard, Christophe parle ainsi de ses origines :
« En tant que co-auteur de TLS, je n’aurais pas prédit que 15 ans plus tard la moitié d’Internet utiliserait une implémentation de TLS maintenue par un ingénieur à quart-temps. C’est ce manque de maintenance qui a conduit au bug tristement célèbre de Heartbleed. Je raconte aujourd’hui cette anecdote à mes collègues qui travaillent sur les crypto-monnaies pour les avertir que leur chiffrage, ultra moderne aujourd’hui, pourrait être ’dépassé’ dans 10 ans et subir le même sort, le projet n’étant plus aussi passionnant, et leur travail acharné risquerait d’être compromis. »
En définitive, la stabilité de nos logiciels repose sur la bonne volonté et la coopération de centaines de développeurs, ce qui représente un risque significatif. La fragilité de notre infrastructure numérique a récemment été démontrée par un développeur nommé Azer Koçulu.
Azer, un développeur Node.js, hébergeait un certain nombre de bibliothèques sur un gestionnaire de paquets nommé npm. Après un conflit avec npm sur la propriété intellectuelle d’un de ses projets, Azer, mécontent de l’issue du conflit, décida de supprimer toutes les publications qu’il avait pu faire sur npm.
L’une de ces bibliothèques, left-pad, avait été réutilisée dans des centaines d’autres projets. Même s’il ne s’agissait que de quelques lignes de code, en supprimant le projet left-pad, Azer a « cassé » les algorithmes d’innombrables protocoles logiciels développés par d’autres. La décision d’Azer a provoqué tant de problèmes que npm a pris la décision sans précédent de republier sa bibliothèque, contre la volonté d’Azer, afin de restaurer les fonctionnalités offertes par le reste de l’écosystème.
Npm a aussi revu sa politique pour qu’il soit plus difficile pour les développeurs de retirer leurs bibliothèques sans avertissement, reconnaissant ainsi que les actions d’un individu peuvent en affecter négativement beaucoup d’autres.
Les logiciels ne reçoivent pas la maintenance nécessaire dont ils ont besoin
Construire une infrastructure numérique de façon désorganisée implique que tout logiciel sera construit plus lentement et moins efficacement. L’histoire de l’infrastructure Python en fournit un bon exemple.
L’un des importants projets d’infrastructure pour les développeurs Python se nomme Setuptools. Setuptools fournit un ensemble d’outils qui rendent le développement en Python plus simple et plus standardisé.
Setuptools a été écrit en 2004, par le développeur PJ Eby. Pendant les quatre années qui ont suivi, l’outil a été largement adopté. Néanmoins, Setuptools était difficile à installer et à utiliser, et Eby était très peu réceptif aux contributions et aux corrections apportées par d’autres, car il voulait, en tant que concepteur, avoir le dernier mot sur Setuptools. En 2008, un groupe de développeurs conduits par Tarek Ziade a décidé de forker le projet pour obliger Eby à faire des améliorations. Ils ont appelé le nouveau projet « Distribute ». En 2013, les deux projets ont fusionné dans Setuptools.
Ce long désaccord a néanmoins souligné à la fois l’état douteux des outils de l’infrastructure de Python, et la difficulté de mettre en œuvre des améliorations, notamment parce que personne ne se consacrait aux problèmes de la communauté ni ne désirait s’en occuper.
Les outils de Python ont commencé à s’améliorer quand le groupe de travail Python Packaging Authority (PyPA) s’est formé pour se consacrer spécifiquement à définir de meilleurs standards pour le paquetage. Un développeur, Donald Stufft, fit des outils de paquetage Python le cœur de son travail et fut engagé par HP (devenu HPE) en mai 2015 pour poursuivre son travail (son parcours sera évoqué plus tard dans ce rapport).
Un autre exemple intéressant est celui de RubyGems.org, un site web utilisé par la plupart des développeurs Ruby pour héberger leurs bibliothèques Ruby. Ruby a été utilisé pour bâtir des sites web majeurs comme Twitter, AirBnB, YellowPages et GitHub lui-même. En 2013, une faille de sécurité de RubyGems.org a été découverte, mais elle ne fut pas réparée avant plusieurs jours, parce que RubyGems.org était entièrement maintenue par des bénévoles. Les bénévoles pensaient régler le problème le week-end, mais pendant ce temps, quelqu’un d’autre a découvert la faille et a piraté le serveur de RubyGems.org. Après l’attaque, les serveurs ont dû être entièrement reconfigurés. Plusieurs bénévoles ont pris sur leur temps de travail, et certains ont même pris des jours de congé, afin de remettre RubyGems.org en état de marche le plus vite possible.
Comme RubyGems.org est un élément d’infrastructure critique, la faille de sécurité affectait par rebond beaucoup de développeurs et d’entreprises. L’incident a mis en lumière le fait qu’un travail fondé uniquement sur la base du volontariat limitait les garanties de sécurité et de fiabilité que l’on pouvait offrir sur une infrastructure logicielle importante. Des dizaines de développeurs se mobilisèrent de façon « bénévole » pendant l’incident parce que le problème affectait directement leur emploi salarié.
Malheureusement, aucun d’entre eux n’avait l’expérience requise pour être utile, et aucun d’entre eux n’a continué à offrir son aide une fois les serveurs réparés. En 2015, une organisation nommée Ruby Together a été formée pour aider à financer la maintenance et le développement de l’infrastructure Ruby, entre autres RubyGems.org, en sollicitant des entreprises comme sponsors.
La perte de main-d’œuvre qualifiée
Comme dans beaucoup de communautés de bénévoles, le « burnout » est commun parmi les contributeurs open source, qui se retrouvent à répondre aux requêtes d’utilisateurs individuels ou d’entreprises, pour un travail sans compensation. Beaucoup de développeurs ont des anecdotes où des entreprises les sollicitaient pour du travail gratuit. Daniel Roy Greenfield, développeur Django et Python, a écrit :
« J’ai personnellement eu des demandes pour du travail non-payé (les discussions pour payer le travail n’aboutissent jamais) par des entreprises à haut profit, grandes ou petites, pour [mes projets]. Si je ne réponds pas dans les temps convenus, si je n’accepte pas une pull request merdique, on va me mettre une étiquette de connard. Il n’y a rien de pire que d’être face à des développeurs du noyau Python/PyPA travaillant pour Redhat [sic], qui exigent de toi un travail non payé tout en critiquant ce qu’ils considèrent comme les insuffisances de ton projet, pour te pourrir ta journée et plomber ta foi en l’open source. »
(Red Hat est une multinationale du logiciel avec un revenu annuel excédant les 2 milliards d’euros, qui vend des logiciels open source à des clients d’entreprise. Du fait de la nature de leur entreprise, les employés de Red Hat utilisent et contribuent à de nombreux projets open source : en un sens, Red Hat est devenu la tête d’affiche de l’open source dans le monde de l’entreprise. Nous reparlerons de son succès financier plus tard dans ce rapport).
Read the Docs, service d’hébergement de documentation technique précédemment mentionné, annonce explicitement sur son site qu’il ne s’occupe pas de l’installation personnalisée dans les entreprises ou chez les particuliers.
L’un des mainteneurs, Eric Holscher, va jusqu’à faire ce commentaire :
« Je suis à peu près sûr que Read the Docs n’a aucun intérêt à être open source, vu que les utilisateurs privés ne contribuent jamais en retour, et se contentent de demander une assistance gratuite. »
Maquess, le contributeur OpenSSL, a tenu un discours acerbe à propos des requêtes récurrentes sur ses posts qui parlent de financement :
« C’est à vous que je pense, entreprises du Fortune 1000. Vous qui incluez OpenSSL dans vos firewall/dispositifs/cloud/produits financiers ou de sécurité, tous ces produits que vous vendez à profit, ou que vous utilisez pour vos infrastructures et communications internes. Vous qui n’avez pas besoin de financer une équipe interne de programmeurs pour se débattre avec du code crypté, puis qui nous harcelez pour obtenir une assistance gratuite quand vous réalisez que vous êtes incapables de l’utiliser. Vous qui n’avez jamais levé le petit doigt pour contribuer à la communauté open source qui vous a fait ce cadeau. Les concernés se reconnaîtront. Certains développeurs choisissent d’arrêter de maintenir leurs projets parce qu’ils n’ont plus assez de temps à y consacrer, et espèrent que quelqu’un d’autre prendra le relais. Pendant ce temps, les entreprises, les gouvernements et les individus dépendent de ces bibliothèques pour leur bon fonctionnement, inconscients des enjeux sous-jacents. »
David Michael Ross, ingénieur manager dans une agence web, a écrit au sujet de son expérience :
« Pour moi, c’est là que le bât blesse. […] On sait qu’on a créé quelque chose gratuitement, par passion, et on voit ce flux infini de personnes qui crient « plus ! encore plus ! » et qui se mettent en colère quand on ne traite pas leur cas particulier. Il y avait mon numéro de téléphone sur l’un de mes sites personnels pour que mes amis puissent me joindre. Je l’ai enlevé au bout d’une semaine parce que des gens m’appelaient à toute heure de la journée pour de l’assistance sur les plugins, alors qu’il y a un forum consacré à ça. Il n’y a rien de fondamentalement méchant là-dedans, c’est juste que c’est usant. On se met à avoir peur de vérifier ses mails ou de répondre au téléphone. »
Ryan Bigg, qui écrit de la documentation technique pour le framework Ruby on Rails, a annoncé en novembre 2015 qu’il renonçait à tout travail open source :
« Je n’ai plus le temps ni l’énergie de m’investir dans l’open source. Je ne retire strictement aucun revenu de mon travail open source, ce qui veut dire que le travail que je fais là, c’est du temps que je pourrais consacrer à des activités perso, ou à écrire. Ce n’est pas justifié d’attendre de moi que je travaille encore, en dehors de mon emploi salarié, sans que je sois honnêtement rétribué pour ça (en temps ou en argent). C’est aussi une recette qui a de bonnes chances de me conduire au burnout ou de me rendre juste globalement aigri.
Par ailleurs, la perte de main-d’œuvre qualifiée dans l’open source, ce n’est pas seulement les contributeurs qui démissionnent, c’est aussi ceux qui n’ont jamais contribué du tout. »
Il existe très peu de statistiques sur la démographie des contributeurs open source, ce qui est déjà révélateur en soi. Une analyse récente de GitHub a révélé que seulement 5,4% des contributeurs open source étaient des femmes, qui occupent pourtant environ 15 à 20% des postes techniques dans l’ensemble des entreprises de logiciels.
L’une des raisons qui font que les contributeurs open source sont un groupe remarquablement plus homogène que le secteur de la technologie dans son ensemble, c’est qu’ils ont besoin de temps et d’argent pour apporter dans un premier temps des contributions significatives. Ces contraintes empêchent des contributeurs par ailleurs qualifiés d’entrer dans cet espace.
David Maclver, créateur de Hypothésis, une bibliothèque Python qui sert à tester des applications logicielles, explique pourquoi il a pu passer autant de temps sur le projet :
« J’ai pu le faire seulement parce que j’avais le temps et l’argent pour le faire. J’avais le temps parce que j’étais obsessionnel, je n’avais personne à charge, et je n’avais pas d’emploi. Je pouvais me permettre de ne pas avoir d’emploi parce que j’avais de l’argent. J’avais de l’argent parce que pendant la dernière moitié de l’année passée, je touchais un salaire deux fois plus élevé que d’habitude, en dépensant deux fois moins que d’habitude, et je traversais une dépression qui me rendait trop borderline pour avoir envie de dépenser mon argent dans quoi que ce soit d’intéressant. Ce ne sont pas des conditions qu’on peut raisonnablement exiger de quelqu’un. […] Est-ce qu’on pourrait produire un logiciel de qualité en moins de temps que ça, en ne travaillant que sur du temps libre ? J’en doute. »
Cory Benfield, un développeur pour les fonctions de base de Python, écrit :
« De manière générale, les personnes qui ne sont pas des hommes cisgenres, hétérosexuels, blancs, de classe moyenne, et anglophones sont moins susceptibles de pouvoir assumer les risques financiers accrus associés à l’absence d’emploi stable. Cela signifie que ces personnes ont vraiment besoin d’un salaire régulier pour pouvoir contribuer le plus efficacement possible. Et nous avons besoin de leur contribution : des équipes diversifiées font un meilleur travail que des équipes homogènes. »
Charlotte Spencer, qui contribue au framework logiciel Hoodie et au système de bases de données PouchDB, fait écho à cette opinion :
« Toutes mes contributions sont purement bénévoles. Je n’en retire pas d’argent, même si j’aimerais beaucoup pouvoir. J’ai demandé à des vétérans de l’open source s’ils étaient payés et ce n’est pas le cas, ce qui m’a découragé d’essayer quoi que ce soit (si ces gens-là ne sont pas payés, pourquoi le serais-je ?). J’y consacre la plus grande partie de mon temps libre, mais j’essaie d’en faire moins parce que ça envahissait trop ma vie. »
Jessica Lord, développeuse, a contribué activement à l’open source tout en travaillant à Code for America, une organisation à but non-lucratif qui soutient la technologie dans le secteur public. Urbaniste de formation, elle insiste sur le fait qu’elle n’avait « pas de diplôme en informatique, pas d’expérience formelle en programmation, mais un portfolio GitHub ».
Ses contributions régulières attirèrent l’attention de la plate-forme GitHub elle-même, pour qui elle travaille désormais. Cependant, Jessica note qu’elle a pu contribuer à l’open source grâce à un concours de circonstances « particulier » : elle a accepté une baisse de salaire pour travailler à Code for America, utilisé toutes ses économies, travaillé « presque non-stop » sur des projets open source, et bénéficié d’une communauté de soutiens.
À propos du manque de diversité dans l’open source, Jessica écrit:
« La valeur des savoirs communs ne peut être surestimée. Nous devons faire mieux. Nous avons besoin des idées de tout le monde. C’est le but que nous devrions chercher à atteindre. Il est nécessaire que l’open source soit ouvert à tous. Pas seulement aux privilégiés ou même aux seuls développeurs. »
Ce dernier point soulevé par Jessica Lord est révélateur : permettre à des profils plus divers de participer à l’open source peut aider à pérenniser l’open source en elle-même. D’un point de vue fonctionnel, la grande majorité des contributeurs open source sont des développeurs, mais beaucoup d’autres rôles sont nécessaires pour gérer les projets d’ampleur, comme la rédaction, la gestion de projet ou la communication. Les projets open source ne sont pas différents des autres types d’organisations, y compris les startups où l’on a besoin de personnes se chargeant de l’administration, du marketing, du design, etc., qui sont autant de fonctions nécessaires au fonctionnement de base d’une structure. C’est en partie parce que la culture open source repose principalement sur les développeurs que la pérennité financière est si rarement l’objet de discussions et d’actions concrètes.
Enfin, l’homogénéité des contributeurs open source impacte les efforts en faveur de la diversité dans le monde de la technologie au sens large, puisque l’open source est étroitement lié à l’embauche. En effet, comme nous l’avons remarqué plus haut, beaucoup d’employeurs utilisent les contributions open source, notamment les profils GitHub, pour découvrir leurs futurs employés potentiels ou pour vérifier les qualifications d’un candidat. Les employeurs qui se fient ainsi essentiellement aux preuves de contributions open source ne recrutent que parmi un vivier de candidats extrêmement restreint.
Ashe Dryden, dans un essai important intitulé L’Éthique du travail non payé et la Communauté OSS, expliquait :
« Juger que quelqu’un est un bon programmeur en se basant uniquement sur le code qu’il rend disponible publiquement, c’est exclure bien plus que les gens marginaux. C’est aussi exclure quiconque n’est pas autorisé à publier son code publiquement pour des raisons de licence ou de sécurité. Cela concerne également un grand nombre de travailleurs freelance ou de contractuels qui, pour des raisons légales, n’ont pas le droit de revendiquer publiquement leur participation à un projet (par exemple s’ils ont signé un accord de confidentialité). Dans une industrie où on lutte pour dénicher assez de talents, pourquoi limitons-nous artificiellement le spectre des candidats ? » (source)
Comment atténuer ou éviter certains des coûts qui s’imposent aux personnes qui participent à l’élaboration d’infrastructures numériques aujourd’hui ? Pour commencer, nous analyserons comment les projets d’infrastructure sont actuellement financés.
Mobilisons-nous le 11 février : The Day We Fight Back, contre la surveillance de masse
Comme nous l’avions annoncé il y a un mois ici, demain c’est la journée d’action The Day We Fight Back.
On peut toujours gloser sur la réelle portée d’un tel événement, mais il a le mérite de mettre le focus sur un sujet fondamental, pas assez relayé par les médias et peu pris à bras le corps par nos politiques. L’occasion justement d’en parler autour de nous et de faire avancer la sensibilisation.
Le jour de la contre-attaque : un appel à la communauté internationale pour lutter contre la surveillance de masse
Les révélations de Snowden ont confirmé nos pires craintes au sujet de l’espionnage en ligne. Elles montrent que la NSA et ses alliés ont construit une infrastructure de surveillance globale pour « contrôler Internet » et espionner les conversations mondiales. Ces groupes de l’ombre ont sapé les normes de chiffrement de base, et criblé la dorsale Internet avec des équipements de surveillance. Ils ont collecté des centaines de millions d’enregistrements téléphoniques de personnes qui n’étaient soupçonnées d’aucun crime. Ils ont écouté les communications électroniques de millions de personnes, chez elles et à l’extérieur, sans distinction aucune, en exploitant les technologies numériques que nous utilisons pour échanger et nous informer. Ils espionnent les populations alliées, et partagent ces informations avec d’autres organisations, au mépris le plus complet des lois.
Nous n’allons pas laisser la NSA et ses alliés détruire Internet. Inspirée par la mémoire d’Aaron Swartz, alimentée par la victoire contre SOPA et ACTA, la communauté numérique tout entière est unie pour retourner au combat.
Le 11 février, le jour de la contre-attaque (NdT : The Day We Fight Back), le monde va exiger la fin de la surveillance de masse dans tous les pays, tous les états, quels que soient les frontières et les régimes politiques. Les manifestations contre SOPA et ACTA ont été un succès car nous avons tous participé en tant que communauté. Comme le disait Aaron Swartz, tout le monde est devenu « le héros de sa propre histoire ». Nous pouvons choisir une date, mais nous avons besoin de tout le monde, de tous les utilisateurs de l’Internet, pour faire de ceci un mouvement.
Voici une partie de notre plan (mais ce n’est que le début). L’an dernier, avant qu’Ed Snowden ne fasse ses révélations au monde, les militants des droits numériques se sont entendus sur 13 Principes. Ces Principes expliquaient clairement en quoi la surveillance généralisée représente une violation des Droits de l’Homme, et donnaient aux législateurs et juges une liste de correctifs qu’ils pouvaient appliquer aux barbouzes de l’Internet. Ce jour de la contre-attaque, nous voulons que le monde adhère à ces principes. Nous voulons que les politiciens s’engagent à les respecter. Nous voulons que le monde voie que nous sommes concernés.
Voici comment vous pouvez rejoindre le mouvement :
1. Nous encourageons les sites web à faire un lien vers le site The Day We Fight Back. Cela permettra à des personnes du monde entier d’apposer leur signature sous nos 13 Principes, en riposte à la surveillance de masse de la NSA, du GCHQ et d’autres agences de renseignement. Si vous pouvez informer vos collègues sur cette campagne et le site avant la fin de la journée, nous pourrons envoyer de l’information à ce sujet dans chaque pays.
2. Dites à vos amis de signer les 13 Principes ! Nous (NdT : EFF) sommes en train de nous organiser pour nous associer à la journée d’action. Nous allons continuer à utiliser ces Principes pour montrer à ceux qui nous gouvernent que le respect de la vie privée est un droit pour chacun et doit être protégé sans tenir compte des frontières.
3. Courriels : Si vous avez besoin d’un prétexte pour en parler à vos collègues ou à vos proches à ce sujet, le 11 février est pile le bon moment pour leur dire de contacter les politiques locaux sur des sujets comme l’espionnage via Internet. Il faut les encourager à agir et à comprendre l’importance du combat contre la surveillance de masse.
4. Réseaux sociaux : touittez ! Postez sur Facebook et Google Plus ! Nous voulons faire autant de bruit que possible. Nous voulons vraiment une campagne à l’échelle du globe, où tous les pays sont impliqués. Plus nous serons nombreux à signer les Principes, plus ceux qui nous gouvernent entendront nos exigences visant à arrêter l’espionnage de masse chez nous et dans d’autres pays.
5. Outils : développez des mèmes, des outils, des sites web et tout ce que vous pouvez pour encourager d’autres personnes à participer.
6. Soyez créatifs (NdT : exemple) : préparez vos propres actions et vos propres engagements. Descendez dans la rue. Faites la promotion des Principes dans votre pays. Ensuite, dites-nous ce que vous comptez faire, de façon à ce qu’on fasse un lien vers vos efforts et qu’on leur donne de la visibilité.
Ce serait génial si vous participiez de ces six façons (ou plus encore !) mais franchement, tout ce que vous pourrez faire aidera le mouvement.
Les espions d’Internet ont passé trop de temps à écouter nos pensées et peurs les plus privées. Il est maintenant temps qu’ils nous entendent vraiment à leur tour. Si vous partagez notre colère, partagez aussi nos principes et contre-attaquez.
11 février 2014 « The Day We Fight Back » #Mobilisation #AaronSwarz #SOPA #NSA
En l’honneur d’Aaron Swarz et de la disparition de SOPA, une grande journée d’action est prévue le 11 février prochain contre la surveillance généralisée. Y participent déjà des organisations comme Mozilla, l’EFF, Reddit ou BoingBoing.
The Day We Fight Back – Janvier 2014 – Communiqué (Traduction : audionuma, baba, Asta, toufalk, KoS, Omegax)
À l’occasion de l’anniversaire de la disparition tragique d’Aaron Swartz, des grands groupes d’Internet et des plateformes en ligne annoncent le jour de l’activisme contre la surveillance de la NSA
Mobilisation nommée « The Day We Fight Back » en l’honneur de Swartz et pour célébrer l’anniversaire de la disparition de SOPA
Une large coalition de groupes activistes, entreprises, et plateformes en ligne tiendront une journée mondiale de l’activisme en opposition au régime d’espionnage de masse de la NSA, le 11 février. Nommée « Le Jour De La Contre-Attaque », la journée de l’activisme a été annoncée la veille de l’anniversaire de la disparition tragique de l’activiste Aaron Swartz. La manifestation est en son honneur et en célébration de la victoire contre SOPA deux ans plus tôt, qu’il a contribué à arrêter.
Parmi les participants, on compte Access, Demand Progress, l’Electronic Frontier Foundation, Fight for the Future, Free Press, BoingBoing, Reddit, Mozilla, ThoughtWorks, et plus encore à venir. Ils rejoindront potentiellement des millions d’internautes pour persuader les législateurs de mettre fin à la surveillance de masse, non seulement des Américains, mais aussi des citoyens du monde entier.
Le 11 janvier 2013, Aaron Swartz s’est suicidé. Aaron était doté d’un esprit brillant et intuitif, qu’il mettait au service de la technologie, de l’écriture, de la recherche, de l’art, et plus encore. Ses derniers jours furent consacrés à l’activisme politique, en soutien aux libertés civiles, à la démocratie et à la justice économique.
Aaron a déclenché, puis aidé à diriger le mouvement qui viendrait finalement à bout de SOPA en janvier 2012. Cette loi aurait détruit l’Internet tel que nous le connaissons, en bloquant l’accès aux sites qui proposent du contenu généré par les utilisateurs, ceux-là même qui rendent Internet si dynamique.
David Segal, directeur exécutif de Demand Progress, qu’il a co-fondé avec Swartz, a dit : « Aujourd’hui, la plus grande menace contre un Internet libre, et plus largement contre une société libre, est le système d’espionnage de masse de la NSA. Si Aaron était encore en vie, il serait sur le front, pour combattre des pratiques qui minent notre capacité à entreprendre tous ensemble, comme des êtres humains réellement libres. »
Selon Roy Singham, président de la compagnie de technologies globales ThoughtWorks, où Aaron a travaillé jusqu’à sa mort : « Aaron nous a montré qu’être technologue au 21e siècle signifiait prendre des mesures pour empêcher la technologie d’être retournée contre l’intérêt public. Le moment est venu pour la tribu mondiale des technologues de se lever d’un seul élan et de faire échouer la surveillance de masse. »
Selon Josh Levy, de Free Press : « Depuis les premières révélations l’été dernier, des centaines de milliers d’internautes se sont réunis en ligne et hors ligne pour protester contre le programme de surveillance de la NSA, contraire à la Constitution. Ces programmes attaquent notre droit fondamental à nous connecter et à communiquer de façon privée, et frappe au cœur des fondations de la démocratie elle-même. Seul un large mouvement d’activistes, d’organisations et d’entreprises, peut convaincre Washington de restaurer ces droits. »
Brett Solomon, directeur exécutif chez Access, ajoute : « Aaron pensait en termes de systèmes. Il savait qu’un Internet libre et ouvert est un prérequis vital pour préserver la liberté et l’ouverture des sociétés. Son esprit vit encore à travers notre conviction que là où des menaces pèsent sur cette liberté, nous nous lèverons pour les combattre. Le 11 février, nous nous battrons contre la surveillance de masse. »
Le jour J, le collectif et les activistes qu’ils représentent téléphoneront et enverront des mails aux députés. Les propriétaires de sites web mettront en place des bannières pour encourager leurs visiteurs à combattre la surveillance et les employés d’entreprises technologiques demanderont que leur organisation fasse de même. Il sera demandé aux usagers d’Internet de créer des ”mèmes’’ et de changer leurs avatars sur les médias sociaux pour refléter leur demande.
Les sites web et les usagers d’Internet qui veulent prendre part peuvent visiter TheDayWeFightBack.org pour s’inscrire et ainsi recevoir par mail les dernières nouvelles et indiquer que leur site participe à l’évènement. Des nouvelles seront régulièrement postées sur le site entre maintenant et le 11 février, date de la journée d’action.
QUI : Access, Demand Progress, Electronic Frontier Foundation, Fight for the Future, Free Press, The Other 98%, BoingBoing, Mozilla, Reddit, ThoughtWorks… et beaucoup d’autres à venir
QUOI : Journée d’action en opposition à la surveillance de masse, en l’honneur de Aaron Swartz et pour fêter l’anniversaire de l’abandon de SOPA
QUAND : 11 février 2014
CE QUE PEUVENT FAIRE LES UTILISATEURS D’INTERNET :
S’inscrire pour indiquer à quoi l’on participera et recevoir les dernières nouvelles.
S’inscrire pour installer des widgets à mettre sur les sites web pour encourager les visiteurs à combattre la surveillance. (Ils seront finalisés dans les jours à venir.)
Utiliser les outils des médias sociaux disponibles sur le site pour annoncer votre participation.
Développer des mèmes, des outils, des sites web et faire tout ce qui est possible pour participer et encourager les autres à faire de même.
Hackadon du 11/12/13 Donnez au Libre ! Entretien avec Bastien Guerry
Bastien Guerry co-organise l’événement « 111213 » qui aura lieu le 11 décembre 2013 à simplon.co à Montreuil, une soirée où les internautes sont invités à soutenir des logiciels libres avec des dons. Nous lui avons posé quelques questions pour comprendre le pourquoi et le comment.
Peux-tu te présenter en deux mots ?
Je m’appelle Bastien Guerry. J’ai découvert le libre en 2000 via Thierry Stoehr, alors vice-président de l’AFUL, et en lisant le recueil d’articles de Florent Latrive et Olivier Blondeau intitulé « Libres enfants du savoir numérique », paru aux éditions de l’Éclat en 2001. Depuis, je suis devenu contributeur de GNU Emacs.
La programmation, simple passe-temps, est peu à peu devenu une passion. Quand j’ai reçu des dons pour mon implication comme mainteneur d’un logiciel, ça a fait « tilt » : je me suis dit qu’il fallait que j’aide d’autres développeurs à recevoir plus de dons. C’est à ça que je consacre aujourd’hui mon énergie avec le projet http://kickhub.com
Tu lances avec d’autres un « hackadon » le 11 décembre. C’est quoi ?
C’est une soirée pour faire des dons à des projets libres, pour recenser les différentes façons de le faire et pour réfléchir ensemble au sens de ce geste.
Depuis quelques années, un bandeau s’affiche tous les ans sur les pages de Wikipédia pendant les campagnes de dons de la Wikimedia Foundation et de Wikimédia France. Cela a permis aux gens de se rendre compte que le sort de l’encyclopédie était entre leurs mains, et que même ceux qui ne contribuent pas directement peuvent jouer un rôle, celui de soutenir l’infrastructure technique et le mouvement Wikimédia.
Pour les logiciels libres, c’est différent. D’abord parce que bon nombre d’entre eux sont en partie financés par des entreprises ; ensuite parce qu’il n’y a pas de canal de communication unique pour solliciter des dons, les demandes avancent en ordre dispersé.
Mais imaginons une campagne qui rassemble des logiciels populaires comme Firefox, LibreOffice et VLC. Qui ne serait pas sensible à un message du genre : « Pour continuer de développer ces logiciels et pour rester indépendants, nous avons besoin de votre soutien ! » Je crois qu’une telle démarche aurait du succès et permettrait à chacun de comprendre qu’il peut être utile, non pas comme développeur, mais comme soutien ; qu’il y a encore plein de logiciels dont la survie dépend de la bonne volonté des contributeurs, et qu’en général, les entreprises ne devraient pas être seules à en assurer le financement.
Le Hackadon du 11 décembre est une première tentative de sensibilisation.
Pourquoi maintenant ?
Le déclic a été pour moi d’assister à la montée en volume du financement participatif ces deux dernières années. Ce que les gens ont l’air d’apprécier dans ces modes de financement (un contact direct avec le porteur de projet, des nouvelles régulières sur ses avancées, etc.) c’est ce qu’on fait dans les projets libres depuis toujours !
On voit de plus en plus de projets libres sur les plates-formes comme kickstarter.com, la dernière campagne pour le Ubuntu Edge a beaucoup fait parler d’elle — et pour cause : il y a une affinité naturelle entre ce mode de financement et le mode de développement du libre.
Mais le préalable est que chacun comprenne qu’en soutenant un projet libre, même modestement, il donne du temps et de l’indépendance à son développeur. Et je crois qu’aujourd’hui les mentalités sont mûres pour cette prise de conscience.
Cette soirée s’adresse à qui ?
À tous ! Nous aurons à manger et à boire pour tous les invités qui se déplaceront jusqu’à Montreuil (l’événement a lieu à Simplon.co, qui co-organise l’événement), et le message s’adresse à Monsieur et Madame Toutlemonde. Pour qu’ils comprennent la différence entre un logiciel gratuit et un logiciel libre. Et qu’ils se disent : « Mais bon sang mais c’est bien sûr, un freeware c’est juste de la publicité, alors qu’un logiciel libre c’est ma liberté ! »
Nous invitons aussi tous les développeurs qui souhaitent solliciter des dons — la soirée sera ponctuée de présentations de donateurs qui expliquent pourquoi ils donnent et de développeurs qui partagent leur passion.
Vous avez un objectif précis ?
Assez : atteindre un beau score final et passer une soirée riche de témoignages et d’échanges !
Est-ce qu’il y aura une suite ?
J’ai un peu cherché mais je n’ai pas vu d’événement du même type.
J’espère que ce hackadon donnera envie à d’autres d’en organiser. La formule est simple : se réunir pour donner à des logiciels libres. Un geste qu’on fait parfois dans son coin, mais qui prend encore plus de sens quand on explique à d’autres pourquoi on le fait.
Donc les suites possibles, ce sont d’autres hackadons ailleurs : croisons les doigts !
As-tu un rêve pour l’avenir du libre ?
Je ne veux plus voir de libriste faire du propriétaire le jour et du libre la nuit. Je ne veux plus voir de libriste dire qu’il abandonne la maintenance d’un projet parce qu’il vient d’avoir un enfant.
La main invisible du marché logiciel a tout intérêt à laisser les utilisateurs confondre le libre et le gratuit ; mais cette main, on risque à tout moment de se la prendre dans la figure tant qu’on ne donne pas plus d’indépendance aux développeurs.
C’est sûr, il y aura toujours plus de bénévoles que de donateurs, car donner de l’argent est rarement une passion. Mais Wikipédia montre l’exemple : on peut rétablir, peu à peu, la balance !
Henri Bergius est le fondateur de Midgard(1), un dépôt de contenu pour les logiciels libres. Il a aussi été longtemps impliqué dans la géolocalisation d’ordinateurs de bureaux sous Linux ainsi que dans les communautés Maemo et Meego. Il dirige un petit cabinet de conseil nommé Nemein, bidouille CoffeeScript et PHP et passe beaucoup de son temps à faire de la moto dans des régions reculées du continent Eurasien. Il vit dans la froide ville nordique d’Helsinki, en Finlande.
Il se peut qu’il existe un système complètement nouveau dans lequel vous pouvez être défini davantage par qui vous êtes plutôt que par ce que vous possédez, par ce que vous avez créé et partagé, parce que d’autres personnes ont ensuite construit sur cette base
Le monde du logiciel libre est pour l’essentiel divisé en tribus rassemblées autour de choses appelées projets. Il existe des projets majeurs tels que GNOME(2), KDE(3) ou Drupal(4) et il existe bien d’autres projets plus modestes tournant autour d’une seule application ou bibliothèque logicielle.
En fait, les qualifier de « projets » est un peu ridicule.
Selon moi, un projet est l’organisation d’un effort visant un but que l’on puisse atteindre et comprend un calendrier avec dates de début et de fin. Ainsi, GNOME 3.1 serait par exemple un projet tandis que GNOME, pris dans son ensemble, n’en est pas un. Il s’agit d’une communauté d’individus qui entretiennent et créent le corps d’un logiciel par de petits efforts variés ou des projets.
Assez de pédantisme. Le souci avec le concept de projet c’est qu’il finit par maintenir une séparation entre les personnes. Cela crée des communautés isolées souvent réticentes voire incapables de collaborer avec « la concurrence ». Mais en fin de compte, toutes ces communautés sont composées de personnes écrivant des logiciels libres. Et ce sont elles qui décident de l’utilisation possible ou non d’un logiciel dans différents environnements.
En fin de compte, nous voulons tous que le logiciel que nous avons créé soit utilisé par d’autres. Mieux encore : nous voulons que les autres joignent leurs efforts aux nôtres et créent des choses sympa à partir de ce que nous avons créé. Après tout, ceci constitue le cœur même des logiciels libres.
Alors pourquoi érigeons-nous ces murs autour de nous ? Garder une communauté isolée ne fait que favoriser une mentalité de type « nous contre eux ». Les incompatibilités des différents langages de programmation contribuent déjà fortement à notre division. Pourquoi en rajouter ?
La leçon de Midgard
Il est une chose que j’aurais voulu savoir quand j’ai démarré, dans cette période optimiste des « .com » de la fin des années 90 : c’est qu’en réalité le développement de logiciels ne gagne rien à s’isoler. Avec un peu d’efforts nous pouvons partager nos logiciels et nos idées par le biais de communautés, ce qui renforce et améliore à la fois les logiciels et les communautés.
Quand j’ai démarré ma carrière dans le logiciel libre, c’était l’époque des grands projets. Netscape ouvrait son code source, la fondation Apache prenait forme et des sociétés de capital-risque venaient de partout. Tenter de bâtir sa communauté devenait la norme. C’était le chemin assuré vers la gloire, la fortune et la réalisation de choses extraordinaires.
Alors nous avons construit nos propres infrastructures web. À ce moment-là il n’y en avait pas tant que cela, en particulier pour le tout jeune langage PHP. Le PHP n’était même pas notre premier choix. Nous l’avions seulement choisi au terme d’un long débat sur l’utilisation de Scheme(5) que notre développeur principal préférait. Mais le PHP gagnait alors en popularité, devenant le langage de programmation de la Toile. Et nous voulions construire la Toile.
Au début, les choses semblaient prometteuses. Beaucoup de développeurs rejoignaient notre communauté et commençaient à y contribuer. Il y a même eu des entreprises fondées autour de Midgard. Notre infrastructure gagnait en fonctionnalités et devenait de plus en plus liée à Midgard.
Avec le recul, c’est là que nous avons fait une erreur. Nous avons positionné Midgard pour être distinct du PHP lui-même. Quelque chose que vous installeriez séparément, et utiliseriez comme base pour y construire des sites entiers. Il fallait soit suivre notre voie, soit suivre celle de tout le monde.
Avec Midgard, vous deviez utiliser notre interface de dépôt de contenus pour tout, aussi bien pour notre gestion des utilisateurs que pour le modèle de permissions. Vous deviez utiliser notre système de modèles et stocker beaucoup de votre code dans le dépôt au lieu d’utiliser un système de fichiers.
Ceci ne passait évidemment pas très bien auprès de l’ensemble de la communauté PHP. Nos idées leur semblaient étranges, et Midgard, à ce moment-là, était même distribué en tant que gigantesque correctif à la base de code puisqu’on ne pouvait pas charger de modules avec PHP3.
Les années ont passé et la popularité de PHP a connu des hauts et des bas. Pendant ce temps, la communauté Midgard est restée relativement constante : un petit groupe soudé faisant des progrès sur le long terme mais séparé du monde plus large de PHP.
Nous nous sommes toujours demandé pourquoi il était si difficile d’interagir avec le monde PHP. Même d’autres communautés faisant des choses complètement différentes, comme l’environnement de bureau GNOME, semblaient plus faciles à approcher. Ce n’est que récemment, après des années d’isolement, que nous avons pris conscience du problème. En résumé : les infrastructures nous séparent alors que les bibliothèques nous permettent de partager notre code et nos expériences.
À propos des bibliothèques et des infrastructures
En définitive, les logiciels ont pour objectif l’automatisation, la construction d’outils que les autres peuvent utiliser pour résoudre des problèmes ou se connecter entre eux. Avec les logiciels, ces outils comportent plusieurs couches. Il existe des services de bas niveau comme les systèmes d’exploitation, puis les bibliothèques, les infrastructures, les boîtes à outils et enfin les applications elles-mêmes.
Les applications sont toujours écrites pour des usages spécifiques, donc entre elles il existe peu de possibilités de partage de code.
Les possibilités les plus séduisantes se situent au niveau des bibliothèques et infrastructures. Une infrastructure, si elle est suffisamment générique, peut généralement être utilisée pour construire différentes sortes de logiciels. Une bibliothèque, quant à elle, peut être utilisée pour apporter un élément particulier de logique ou de connectivité là où le besoin s’en fait sentir. De mon point de vue, c’est dans cette couche que le plus gros de la programmation devrait être fait, avec des applications spécifiques qui ne sont que des connexions entre diverses bibliothèques au sein d’une infrastructure qui s’occupe alors de faire tourner l’application en question.
Qu’est-ce qu’une bibliothèque et qu’est-ce qu’une infrastructure ? Les gens utilisent souvent ces termes indifféremment bien qu’il existe une règle grossière qui permet de les différencier : une bibliothèque est une ressource à laquelle votre code fait appel, alors qu’une infrastructure est une ressource qui fait appel à votre code.
Si vous voulez que votre code soit utilisé et amélioré, le meilleur moyen est de maximiser le nombre de ses utilisateurs et contributeurs potentiels. Avec le logiciel libre, cela fonctionne en s’assurant que votre code peut être adapté à de multiples situations et environnements.
En définitive, ce que vous voulez développer c’est une bibliothèque. Les bibliothèques c’est cool.
Comment faire en sorte que la collaboration fonctionne
Le plus difficile est de franchir la barrière du « eux-contre-nous ». Les développeurs de l’autre communauté sont des bidouilleurs concevant du logiciel libre, tout comme vous. Il suffit donc de franchir le pas et de commencer à leur parler.
Une fois le débat engagé, voici quelques points que j’ai trouvés importants quant à l’application effective des idées communes ou des bibliothèques au-delà des frontières du projet
Utilisez des licences permissives et essayez d’éviter les cessions de droits d’auteurs et autres exigences que les utilisateurs potentiels trouveraient onéreuses. Hébergez le projet en terrain neutre. Pour les projets web, Apache est un assez bon havre. Pour les projets bureautiques, Freedesktop est probablement le meilleur choix. Utilisez des technologies qui n’imposent pas trop de contraintes. Les bibliothèques doivent être de bas niveau, ou fournir des API (interfaces de programmation) D-Bus utilisables avec n’importe quel système.
Évitez les dépendances spécifiques à une infrastructure. KDE a, par exemple, trouvé GeoClue difficile à adopter parce qu’il utilise des paramètres spécifiques à l’interface GNOME. Rencontrez les autres. Si vous venez du projet GNOME, allez à l’aKademy et donnez-y une conférence. Si vous êtes développeur KDE, allez parler au GUADEC. Après avoir partagé une bière ou deux, la collaboration par IRC vient beaucoup plus naturellement.
Enfin, vous devez accepter que votre implémentation ne soit pas utilisée par tout le monde. Mais si, au moins, d’autres mettent en œuvre les mêmes idées, alors une collaboration reste possible.
Bonne chance pour abattre les frontières du projet ! Dans la plupart des cas, cela fonctionne si vos idées sont bonnes et présentées avec un esprit ouvert. Mais même si vous ne trouvez pas de terrain d’entente, tant que votre application remplit sa fonction pour vous, ça n’a pas été fait en vain. Après tout, ce qui compte c’est de proposer des logiciels et d’offrir la meilleure expérience utilisateur possible.
Mais cette année, dans un format de date à 6 chiffres, elle s’écrira… 11-11-11, à savoir une magnifique et parfaite date binaire[1] !
Sans avoir beaucoup plus d’informations sur l’initiative, des internautes hispanophones libristes se proposent malicieusement de marquer le coup comme il se doit (à 11h11 si possible).
Nous leur avons emboîté le pas en traduisant l’appel glané sur le Web grâce à notre petite mais active section espagnole de Framalang (merci à Thibz et TV).
« Un autre logiciel est possible et il se trouve être Libre »
Bonjour à toutes et à tous de la communauté du Logiciel Libre.
Un groupe de personnes et d’organisations de différents pays est en train de se former pour organiser une célébration le vendredi 11 novembre 2011.
En effet la date de ce jour (11/11/11) sera la dernière date binaire qu’il y aura avant longtemps, la prochaine date du même genre sera le 01/01/00 (ou 010100) en 2100.
Pour faire honneur à cette date clin d’œil du calendrier, nous avons décidé de nous réunir ce jour-là, non pas pour célébrer cette « dernière » date binaire, mais bien au contraire pour profiter de cette excuse numérique afin de célébrer « le début du siècle du Logiciel Libre ».
S’il s’agit bien d’une célébration symbolique, nous ne pouvons manquer cette occasion de partager ce moment sans doute unique dans nos vies. Un moment que l’on pourrait mettre à profit pour dynamiser le mouvement du Libre et chercher des points communs et d’appui entre les différentes communautés pour stimuler et développer les initiatives, diffuser les progrès et joindre nos efforts autour du Logiciel Libre, expression d’une culture solidaire, libératrice et engagée dans la défense des valeurs éthiques et des libertés fondamentales de la technologie, comme par exemple le droit pour toutes et tous à l’accès au savoir, la solidarité sociale et le principe fondamental de pouvoir partager.
Ce jour-là nous nous réunirons en groupes de personnes de différentes communautés dans différentes parties du monde pour célébrer le début du siècle du Logiciel Libre. Aujourd’hui (et depuis un certain temps déjà) on peut utiliser des distributions GNU/Linux sans composants privatifs pour nos tâches informatiques quotidiennes (à quelques exceptions près). Et avec l’aide de toutes et tous nous arriverons un jour à éliminer de notre société les systèmes de dépendance et de domination dont elle n’a pas besoin, et à créer des modèles novateurs de développement, de créativité et des opportunités pour stimuler les talents aux quatre coins de la planète.
Ce jour sera également l’occasion de persuader et convaincre beaucoup plus de personnes et de gouvernements de s’engager à adopter les technologies de l’information libres, et à offrir un plus grand soutien aux activistes, aux développeurs, aux associations, aux organisations et aux communautés du Logiciel Libre dans le monde, parce que « un autre logiciel est possible et il se trouve être Libre ».
Il y a plusieurs collectifs qui œuvrent pour le 11-11-11. Nous espérons être nombreux à accompagner cette célébration de forme libre et créative dans les réseaux sociaux, canaux IRC, listes de diffusion, radios et moyens alternatifs et communautaires, blogs et toute forme de communication.
Le 111111, vive la liberté d’être, de créer, connaître et partager… Ne manquez pas le rendez-vous… On vous attend !
Le 11 novembre nous est une date bien connue parce qu’elle marque la