Il y a quelques jours à peine nous annoncions la sortie de l’application Popcorn Time, mieux que Netflix pour voir des films en streaming via BitTorrent !

Popcorn Time y était qualifié de « pire cauchemar d’Hollywood ».

Hollywood s’est réveillé et a réagi…

L’équipe de développement nous annonce déjà le clap de fin, en restant évasif sur les explications. Mais nul doute qu’ils ont reçu des pressions. Ils disent avoir vérifié quatre fois que Popcorn Time était légal (puisqu’ils proposaient une technologie neutre, n’hébergeait rien sur leurs serveurs et ne faisant que combiner trois bases de données externes : pour les torrents, pour les informations des films et pour leurs affiches).

Cela n’a, semble-t-il, pas suffi.

Edit : il y a une suite heureuse à cette histoire !

Adieu Popcorn Time

Goodbye Popcorn Time

L’équipe de développement – 14 mars 2014

(Traduction : Piup, aKa, Kcchouette, loicwood, Noon, lumi, Amazigh + anonymes)

Au revoir

Nous avions commencé Popcorn Time comme un défi lancé à nous-mêmes. C’est notre devise… C’est ce à quoi nous aspirons.

Nous sommes très fiers de ce projet. C’est le plus important que nous ayons construit. Nous avons constitué une équipe géniale en le faisant, avec des gens avec qui nous adorons travailler. Et pour être honnête, au moment où je vous écrit, nous sommes tous un peu écœurés et abasourdis. Nous aimons Popcorn Time et ce qu’il défend, et nous avons l’impression de laisser tomber nos géniaux contributeurs chéris. Ceux qui ont traduit l’application en 32 langues, y compris certains dont nous ne connaissions même pas l’existence. Nous sommes en admiration devant ce que la communauté libre peut faire.

Nous sommes avant tout de jeunes entrepreneurs passionnés d’informatique. Nous lisons Techcrunch, Reddit et Hacker News dont nous avons fait deux fois la une. Dans le même temps, nous avons eu des articles dans Time Magazine, Fast Comany, TechCrunch, TUAW, Ars Technica, Washington Post, Huffington Post, Yahoo Finance, Gizmodo, PC Magazine et Torrent Freak, pour ne nommer que ceux-là. Et nous sommes intervenus à la télévision et dans des émissions de radio, sans parler des nombreuses interviews, et celles que nous avons aussi déclinées en raison de l’excès de sollicitation(s) de la part des médias.

Et aucun de ces médias ne nous blâmait. Non, ils nous soutenaient. Nous étions devenus les outsiders qui se battaient pour le public et les consommateurs. Des gens que nous respections, certains de nos héros, ont dit monts et merveilles à propos de Popcorn Time, ce qui a largement dépassé nos espérances pour un projet expérimental monté en seulement quelques semaines.

En tant que projet, Popcorn Time est légal. Nous avons vérifié. Quatre fois.

Mais comme vous vous en doutez, cela est rarement suffisant. Notre soudaine popularité nous a mis en contact avec des tas de gens, des journaux aux créateurs de nombreux sites et apps, qui étaient extrêmement populaires. Nous avons beaucoup appris à leur contact. En particulier que s’opposer à une industrie obsolète, arc-boutée sur son modèle économique, a un prix. Un prix que personne ne devrait payer en aucune manière.

Vous savez quelle est la meilleure chose à propos de Popcorn Time ? Que des tas de gens se sont accordés pour reconnaître que l’industrie du cinéma avait établi bien trop de barrières et de restrictions sur le marché. Prenons l’exemple de l’Argentine : les diffuseurs de streaming, là-bas, pensent que “There’s something about Mary” (Mary à tout prix) est un film récent. Ce film est ici, aux États-Unis, tellement vieux, qu’il aurait l’âge de voter !

La majorité de nos utilisateurs n’est pas localisée aux États-Unis. Ils sont de partout ailleurs. Popcorn Time s’est installé dans chaque pays sur Terre. Même dans les deux (pays) n’ayant pas accès à Internet.

Le piratage n’est pas un problème de personnes. C’est un problème de services. Un problème créé par une industrie qui voit l’innovation comme une menace à leur recette dépassée pour ramasser la monnaie. Un problème dont ils n’ont que faire.

Mais les gens si.

L’expérience montre que les gens risquent des amendes, des poursuites judiciaires ou toute autre conséquence possible uniquement pour pouvoir regarder un film récent chez eux. Juste pour avoir le type de partage qu’ils méritent.

Il se peut que demander gentiment quelques pièces par mois pour donner l’accès à n’importe quel film soit une bien meilleure solution.

Popcorn Time ferme aujourd’hui. Pas parce que nous n’avons plus ni énergie, ni motivation, ni détermination, ni même d’alliés. Juste parce que nous avons envie de poursuivre nos vies.

Notre expérimentation nous a amenés aux portes d’un débat sans fin entre piratage et copyright, menaces légales et machinerie douteuse qui nous donne l’impression d’être en danger à cause de ce que nous aimons faire. Et ce n’est pas une bataille à laquelle nous souhaitons prendre part.

Bises
Pochoclín

Vous participez ou administrez directement une école de musique ? Ou plus généralement vous vous occupez d’un lieu associatif qui doit organiser la gestion des plannings, des adhérents et des contacts, la réservation des salles, la planification des cours, le prêt du matériel… ?

Sachez qu’il existe une excellente application développée depuis plus de dix ans par deux passionnés de musique et d’informatique !

Le logiciel s’appelle ALGEM (le L c’est donc pour Libre) et il méritait assurément une petite mise en avant.

Rencontre avec Bruno Mauguil (au centre sur la photo) et Jean-Marc Gobat (à droite) qui travaillent tous deux à Musiques Tangentes (Malakoff) d’où l’aventure ALGEM a vu le jour.

Interview ALGEM

Bonjour Bruno et Jean-Marc, pouvez-vous vous présenter succinctement ?

Jean-Marc : agrégé d’éducation musicale et diplômé de l’école d’ingénieurs du CNAM de Paris, j’ai la chance de pouvoir pratiquer au sein de Musiques Tangentes mes deux passions que sont la musique et l’informatique. Je participe au développement d’ALGEM depuis quelques années déjà et intervient dans l’école en tant que professeur de M.A.O. Je suis aussi membre fondateur du groupe de fusion World « Transbohêm ».

Bruno : à l’origine musicien de Jazz, j’ai créé Musiques Tangentes à l’âge de 20 ans au milieu d’un grand vide intersidéral : pas de locaux de répétition, pas d’école de musiques actuelles… Après avoir fondé l’école, épaulé de quelques furieux musiciens, l’informatique nous a permis de structurer ce milieu embryonnaire. J’ai tout de suite compris l’immense intérêt de ce nouvel outil : création, gestion, bureautique, etc. Après m’être débattu sur Prologue (système d’exploitation français de Bull) puis fait un court et malheureux passage sur Windows, je participe aux balbutiements du Libre grâce à la rencontre providentielle d’Eric. C’est la révolution ! Bien que je ne sois pas du tout informaticien, je ne jure depuis que par l’Open Source. Cela fait maintenant 15 ans que nos outils bureautique sont sous Linux. La musique viendra plus tard sur ce système et en partie seulement. ALGEM est né du fait de l’absence totale d’outil de gestion pour notre activité. La suite reste à écrire….

Alors ALGEM c’est quoi ?

Jean-Marc : strictement parlant, ALGEM est l’acronyme d’Application Libre de Gestion d’Ecole de Musique. C’est au départ un logiciel de gestion dédié aux écoles de musiques actuelles. Axé sur la gestion de plannings et de contacts, il s’est enrichi au cours des années et peut très bien convenir aujourd’hui à d’autres types de structures.

Quelle est la répartition des rôles entre vous deux ?

Jean-Marc : je suis chargé du développement, de la maintenance chez nos partenaires et de tous les aspects techniques liés à l’installation, le fonctionnement et les rapports d’erreurs signalés par nos utilisateurs.

Bruno : je suis responsable de l’Association et initiateur du projet. Je suis donc à la fois maître d’œuvre et maître d’ouvrage, responsable du cahier des charges, définissant les grandes lignes et les besoins, et de plus en plus concerné par les problèmes de déploiement. Je joue beaucoup aussi le rôle de bêta-testeur, avec l’ensemble de l’équipe, et suis bien sûr utilisateur au quotidien depuis maintenant plus de 10 ans.

C’est parti d’un besoin interne ? Il n’existait rien de similaire sur le marché ?

Jean-Marc : effectivement, il n’y avait rien de comparable sur le marché à l’époque de sa mise en chantier. Les quelques solutions existantes, très coûteuses de surcroît, étaient réservées aux utilisateurs de Windows et ne correspondaient pas aux besoins des écoles de musiques actuelles. Il fallait donc choisir entre une solution bancale ou le développement d’un logiciel en interne. C’est ce dernier choix qui a été fait, grâce à la participation d’Eric. Ses compétences en Java, langage à l’époque en pleine expansion, lui ont permis en quelques mois de fixer l’ossature du logiciel et de le rendre opérationnel dans nos locaux.

Quand avez-vous décidé d’en faire un logiciel libre et pourquoi ? Et avez-vous constaté une amélioration dans la diffusion et participation du projet ?

Jean-Marc : depuis les débuts, Musiques Tangentes s’investit dans le libre, en privilégiant les systèmes et logiciels Open Source et les applications sous Linux. Il était naturel avec ALGEM d’ajouter une pierre à l’édifice. Comme il a fallu pas mal de temps pour refaçonner l’application, réorganiser les sources et produire quelque chose de plus cohérent, ce passage n’a pu se faire qu’assez récemment, début 2012 (les sources sur GitHub). C’était aussi l’objectif/rêve de Bruno, celui de pouvoir partager un outil avec les confrères et de contribuer à la communauté du libre.
La diffusion du logiciel est encore assez réduite, mais de nombreuses demandes nous ont été faites depuis les derniers mois. Et nous avons constaté un regain d’intérêt depuis le début de l’année scolaire et la publication sur Framasoft.

Le logiciel évolue comme vous voulez ? Résistez-vous au « cloud » ?

Jean-Marc : beaucoup de projets en cours, oui. Des fonctionnalités en chantier : gestion de stages, importation de carnets d’adresse, pré-réservation en ligne, etc. Quant au « Cloud », s’il présente indéniablement des avantages, comme la simplification des procédures pour les novices, son adoption à grande échelle par les entreprises dominantes symbolise pour nous une certaine forme de retour au Minitel, comme l’avait remarqué à juste titre Benjamin Bayart dans sa fameuse conférence. S’en remettre à des entreprises comme Google, Facebook, Apple ou Microsoft, c’est un peu renier l’Internet des origines, décentralisé et pluriel. Afin de répondre aux besoins d’une certaine frange de nos utilisateurs, nous avons essayé néanmoins avec Algem Webstart de concilier les deux mondes : déployer localement l’application tout en profitant de l’hébergement en ligne.

Dans combien de structures ALGEM est-il déployé ? Elles s’occupent toutes de musique ?

Jean-Marc : Officiellement, une demi-douzaine de structures, dont deux à Toulouse et à Tours avec lesquelles nous sommes en relation très étroite. Cela va de la salle de répétition au salon de coiffure ! Donc, pas nécessairement ciblé école de musique. Officieusement, une trentaine de structures nous ont déjà demandé une version d’ALGEM pour leur usage personnel.

C’est dans le cadre de Musiques Tangentes que vous avez développé ALGEM. Pouvez-vous nous en dire plus sur ce lieu, son histoire, les services proposés ?

Bruno : Musiques Tangentes est un centre « musiques actuelles » : apprentissage de loisir, centre de formation professionnelle, studio de répétition (collectif et individuel), studio d’enregistrement, accompagnement de projet et un peu de diffusion (amateur et professionnel). C’est aussi un lieu de création et d’accueil de résidence ou d’insertion professionnelle. C’est une structure pionnière, née dans le squat de la rue des Caves à Sèvres. Nous fêtons cette année nos 35 ans d’existence et Musiques Tangentes est ouverte à tous (à partir de 3 ans), débutant ou confirmé, amateur ou professionnel. Un tiers de notre activité s’effectue aussi hors les murs (intervention en temps scolaire, en périscolaire, en centre spécialisé type IME, en colonie de vacance, en crèche, en entreprise…), partout ou l’on peut faire de la musique… « PLUS DE BRUIT », la Mano Negra est passée par chez nous, c’est un lieu d’apprentissage, de rencontres et d’échanges. Bref, un berceau d’utopies où l’on peut encore rêver et jouer sans contraintes !

Il me semble que vous y proposez un studio d’enregistrement « full libre » ?

Jean-Marc : nous utilisons depuis longtemps des distributions Linux spécialisées dans l’audio-numérique, comme 64Studio, Ubuntu Studio, ou plus récemment Tango Studio. Ardour est installé dans notre rack informatique et nous permet de réaliser des enregistrements sous ces systèmes, grâce à la compatibilité matérielle de notre carte RME MADI 64 canaux. Bien que nous fournissions aussi des prestations sur Pro Tools, le logiciel de référence dans de nombreux studios, nous ne pouvons qu’encourager l’usage de solutions libres. Musiques Tangentes est pratiquement la seule structure à proposer de tels services dans un environnement résolument professionnel : console numérique SONY DMX-R100, station de travail Intel i7 64 bits en dual boot, enceintes A2T. La demande est encore infime mais il n’est pas interdit de penser que l’utilisation d’un logiciel comme Ardour soit à l’avenir de plus en plus pertinente, face à une concurrence peu réactive et très coûteuse.

Est-ce que vous en profitez pour sensibiliser vos membres mélomanes aux licences libres ? Y en a-t-il qui ont fait le choix des licences Creative Commons pour leurs créations ?

Jean-Marc : j’ai moi-même édité l’album « Déserts » de Transbohêm sous licence Creative Commons. D’autres adhérents et membres de l’équipe administrative ont aussi choisi cette licence pour leurs réalisations. Pour un indépendant désireux aujourd’hui d’éditer sa musique, les licences libres présentent une belle alternative face aux fourches caudines de la SACEM.

Bruno : Musiques Tangentes est membre de « Libre Accès » et à ce titre nous avons vivement encouragé nos adhérents à utiliser des licences libres. Vous trouverez de nombreux articles à ce sujet sur notre blog. De plus, des ateliers découverte sont organisés régulièrement autour de ce thème.

Et pour finir, un appel à bonne volonté pour ALGEM ?

Jean-Marc : tout le monde est bienvenu : relecteurs de code, testeurs, spécialistes Java. Nous invitons d’autre part toutes les structures utilisant le logiciel à nous donner leur avis ou nous suggérer des améliorations possibles. Nos propositions de journées de formation restent d’ailleurs toujours d’actualité et nous encourageons tous les utilisateurs à les suivre afin de participer aux avancées d’ALGEM et de pérenniser son développement dans les années futures.

Bruno : nous en sommes encore à l’aube de l’engagement communautaire autour de ce projet et nous espérons que de nombreux utilisateurs et programmeurs nous rejoindrons prochainement . Une première rencontre entre tous les acteurs concernés sera d’ailleurs proposée très bientôt.

-> ALGEM – Pour tout contact : info@algem.net

L’équipe d’OpenHatch organise régulièrement des rencontres, ateliers, événements, sprints, hackathons, etc. invitant de nouveaux contributeurs à participer au développement de logiciels libres. Elle nous livre ici le fruit de son expérience.

L’enthousiasme et la motivation sont indispensables mais ne peuvent faire l’économie d’une solide organisation et réflexion en amont. Happy Hacking 🙂

Note : On remarquera que les deux livres cités en référence pour aller plus loin font partie de nos traduction Framabook : Libres conseils et Produire du logiciel libre.

 

 

Le guide de l’événement libre in situ

The In-Person Event Handbook

L’équipe OpenHatch – février 2014
(Traduction : Omegax, zak, François, Ju, MrTino, Wan, Asta, François, goofy, amha)

Faire en sorte que votre projet soit prêt pour de nouveaux contributeurs

Il semble que chaque jour apparaisse un nouvel atelier, hackaton ou autre sprint, où des projets open source sont invités à travailler avec de nouveaux contributeurs. À OpenHatch, nous avons nous-mêmes souvent organisé ce genre d’événements ! Nous avons découvert que pour en tirer un profit maximal, il est important de planifier les choses en amont. Expliquer vos objectifs, identifier les tâches appropriées, et tester l’organisation de votre projet sont autant de points indispensables pour aboutir à de belles réalisations et passer un bon moment. Ce travail a grandement amélioré nos expériences, et nous pensons qu’il mérite l’effort significatif qu’il mplique.

Nous avons créé ce guide pour aider les projets open source à se préparer pour ces événements. Nous avons utilisé notre propre projet, l’application web OpenHatch.org, comme un exemple dans ce qui suit. Au bas de la page, vous trouverez des aide-mémoires. Elles contiennent en condensé les conseils dispensés dans ce guide, et peuvent vous aider à monitorer vos progrès durant la phase de préparation de votre projet.

Les sources de ce guide sont libres. Un tas de merci à nos contributeurs. (Vous pouvez contribuer, vous aussi !)

Définir des objectifs

Vous devez être capable de présenter clairement vos objectifs pour l’événement, car cela donne à votre groupe une ambition générale à atteindre. Vous pouvez donc commencer par vous demander :

Quel est l’objectif global de votre projet ?

Il vous faut une réponse courte (un paragraphe ou moins) à cette question que vous pourrez utiliser pour attirer les contributeurs potentiels vers votre projet. Les détails, c’est bien joli, mais vous ne devriez pas avoir besoin d’être trop technique à ce moment là. À de nombreux événements, comme les sprints PyCon, on vous demandera un court résumé à exposer devant tout le monde. Pourquoi ne pas vous y préparer ?

Exemple :

L’objectif de OpenHatch est de rendre les communautés de logiciels libres plus accueillantes pour les nouveaux venus. Pour ce faire, nous fournissons documents et support logistique pour animer des ateliers « Introduction à l’open source », un site web avec des ressources libres, des « missions d’entraînement », un découvreur de talents parmi les bénévoles, et plusieurs autres projets en cours de réalisation.

Que voulez-vous accomplir à cet événement ?

Réfléchissez à ce que vous souhaitez voir spécifiquement réalisé lors de cet événement. Vous pouvez catégoriser ces objectifs selon les différentes parties du projet, si vous en avez plusieurs. Il devrait être spécifié clairement de quelle manière ces actions contribueront au progrès général du projet. Toutefois, il ne s’agit pas de « tâches » — il devrait être toujours nécessaire de diviser ces objectifs pour mieux les atteindre.

Il est utile de les lister en termes d’objectifs « principaux » et « étendus ». Avoir des objectifs principaux réalistes et bien définis vous donne quelque chose à célébrer à la fin de l’événement, tandis que les objectifs étendus ou secondaires vous permettent de prévoir le cas excitant où vous vous retrouviez avec une équipe nombreuse et efficace, capable d’accomplir une tonne de travail.

En général, il vaut mieux avoir trop d’objectifs que pas assez, mais priorisez-les. Lorsque vous arriverez à l’étape du découpage en tâches, prenez le temps de traiter en détail chaque objectif avant de passer au suivant.

Exemple :

• Faire une nouvelle mission d’entraînement
  • Objectif principal : Choisir une compétence sur laquelle baser une nouvelle mission d’entraînement, et concevoir cette mission. En créer une maquette.
  • Objectif étendu : Implémenter la maquette et la faire tester par des volontaires de l’événement.
• Faire le ménage dans le suivi de tickets
  • Objectif principal : Passer en revue l’outil de suivi, et étiqueter les tickets selon le « ménage » à y faire. Un bug doit-il être vérifié ? Un patch doit-il être testé ? Une demande de fonctionnalité doit-elle être être rattachée à un jalon ?
  • Objectif étendu : Utiliser ces étiquettes comme guide pour « faire le ménage » . Vérifier les bugs, tester les patches, etc.

Installation du projet

Dans notre expérience, la phase d’installation du projet est l’obstacle majeur à la participation. Nous avons vu (et conduit !) des événements où les participants passaient le plus clair de leur temps à seulement mettre en place leur environnement de développement et faire connaissance avec le projet. Si notre objectif est de permettre à de nouveaux venus de contribuer, tâchez d’estimer le temps qu’il faut pour installer votre projet. Puis trouvez un ami qui n’est pas familier avec votre projet pour voir combien de temps il faut vraiment. Vous pouvez aussi trouver quelqu’un pour vous aider à faire cela dans #openhatch.

Documenter et améliorer le processus à l’avance peut faire économiser du temps et de l’énergie à tout le monde. Si vous savez qu’une partie de votre projet sera inévitablement dévoreuse de temps, assurez-vous que tous les participants savent exactement à quoi s’en tenir.

Toutes les informations ci-dessous devraient être documentées dans un fichier LISEZ-MOI placé à la racine de votre dépôt. Vous pouvez également placer cette information dans une section « Vous voulez participer ? » sur le site web de votre projet, et/ou vous pouvez inclure un lien vers le LISEZ-MOI dans la signature de votre liste de diffusion ou dans la barre de statut de votre canal IRC.

Comment trouver une communauté et des mainteneurs pour le projet

Les informations des contacts devraient être explicitement affichées, étant donné que vous pourriez avoir des contributeurs éloignés ou des contributeurs qui voudraient démarrer en amont de l’événement. Les types d’informations de contacts peuvent inclure :

• Un lien vers votre mailing-list ;
• Votre nom de canal et de serveur IRC (avec le lien vers le guide pour installer IRC et le lien vers sa version webchat) ;
• Les comptes de réseaux sociaux tels que Identi.ca, Twitter ou Facebook si votre projet en possède ;
• Le contact des mainteneurs du projet, si vous vous sentez à l’aise pour le mentionner.

Si vous avez une préférence pour le type de prise de contact, précisez-le.

Exemple:

OpenHatch laisse en deux endroits des informations de contact que nous essayons le plus possible de garder à jour et en cohérence l’un avec l’autre. Il y a nos informations de contacts dans la documentation, référencées principalement depuis notre répertoire où sont déposés les codes sources, et nos informations de contacts dans le wiki, référencées à partir de la page d’accueil du site web.

La structure du projet

Décrivez la structure de base de votre projet. Quels sont les plus gros composants et où sont-ils situés ? Comment ces composants interagissent-ils ? Puis décomposez chaque partie. Vous n’avez pas à parler de chaque fichier ou sous-dossier de votre projet, mais prenez soin de ne pas prendre pour acquis que chaque nouveau venu comprendra le sens de tel script, ou la manière dont interagissent tels fichiers, ou dans quel langage est programmée telle partie du projet.

Selon la taille et la complexité de votre projet, cela peut être une tâche particulièrement imposante. Chez OpenHatch, nous travaillons toujours à documenter la structure complète du projet. Nous recommandons de commencer par une explication « en vue d’ensemble » de la structure projet – juste assez de détails pour remplir d’une demi-page à une page. Quand vous aurez plus de temps, vous pourrez rentrer dans le détail, en commençant par les parties du projet sur lesquelles les gens travaillent le plus souvent (ou qui sont plus susceptibles de faire l’objet de sprints ou de hackatons). Si vous utilisez d’autres frameworks ou librairies, vous pouvez gagner du temps en mettant des liens vers leur documentation et leurs tutoriels.

Exemple :

Une description d’ensemble de la structure du projet OpenHatch peut être trouvée dans « Project Overview ». Une description de la structure de OH-Mainline (le dépôt derrière notre site web) y est présente.

Comment mettre en place un environnement (« de développement ») local

Pour contribuer à votre projet, les gens ont généralement besoin d’une version locale du projet où ils peuvent faire des modifications et les évaluer. Plus votre guide d’installation/développement est détaillé et clair, mieux c’est.

Voici quelques éléments pour la mise en place d’un environnement de développement à mettre dans votre guide :

• Préparer leur ordinateur
  • Assurez vous qu’ils connaissent bien les outils de leurs systèmes d’exploitation, comme le terminal / la ligne de commande. Vous pouvez le faire en donnant un lien vers un didacticiel et en demandant aux utilisateurs s’ils le comprennent bien. Souvent, de très bons didacticiels existent déjà, celui d’OpenHatch sur la ligne de commande est disponible ici.
  • Si les contributeurs doivent mettre en place un environnement virtualisé, accéder à une machine virtuelle ou installer un kit de développement en particulier, expliquez-leur comment faire.
  • Donnez la liste de toutes les dépendances nécessaires pour faire tourner le projet, et une explication pour les installer. Fournissez un lien vers de bons guides d’installation, s’il en existe.
• Téléchargement du code source
  • Donnez des instructions détaillées sur comment télécharger le code source du projet, dont les obstacles et problèmes fréquemment rencontrés.
  • S’il existe plusieurs versions du projet, dites clairement quelle version ils doivent télécharger.
• Comment voir / tester les changements
  • Expliquer aux contributeurs comment voir et tester les changements qu’ils ont effectués. Ceci peut varier selon ce qu’ils ont changé, mais faites votre possible pour couvrir les changements les plus fréquents. Cela peut être, tout simplement, afficher un document html dans un navigateur, mais ce peut aussi être plus compliqué.

L’installation pourra différer pour chaque contributeur en fonction de leur système d’exploitation. Vous aurez probablement besoin de créer des instructions séparées pour les utilisateurs de Windows, Mac et Linux, dans différentes parties de votre guide. Si vous entendez ne supporter le développement que pour un seul système d’exploitation, assurez-vous que cela soit dit clairement pour les utilisateurs,

Exemple:

Vous pouvez voir comment OpenHatch annonce cela dans son guide d’installation. Les instructions pour tester des changements peuvent être trouvées là. Des tâches plus spécifiques peuvent avoir leur documentation additionnelle (par exemple la documentation concernant les différents changements du code).

Contributions et retours

Comment les contributeurs doivent-ils procéder pour amener leurs modifications au projet ? Est-ce qu’ils soumettent une pull request sur Github ? Doivent-ils générer un patch et l’attacher à un ticket sur le système de tickets ? Assurez-vous que cette information est explicitement fournie.

Example :

Le guide d’OpenHatch pour soumettre des changements peut être trouvé ici.

Il est aussi utile d’indiquer aux gens comment ils peuvent faire des retours/signaler des bugs sur le projet. Si votre projet n’a pas de système de suivi de tickets, envisagez d’en créer un. Sur Github, tous les dépôts disposent du système de tickets (bien que vous ayez à l’activer en allant dans Settings puis Features). Il y a beaucoup d’autres systèmes de suivi de tickets.

Si votre projet est de petite taille, vous pouvez ne pas avoir besoin ou ne pas vouloir de systèmes de suivi de tickets. Aucun problème. Le principal est que les contributeurs sachent comment vous remonter des informations.

Example :

Les problèmes avec le projet « Open Source Comes to Campus » peuvent être signalés ici. La plupart des autres problèmes liés à OpenHatch peuvent être signalés là.

Les outils tels que le suivi de tickets sont très utiles pour communiquer de manière asynchrone. Ce n’est peut-être pas la solution la plus appropriée lors d’un événement physique. Si vous voulez changer les choses pour l’occasion – comme demander aux participants de vous notifier par IRC les liens vers les nouveaux tickets, pour éviter qu’ils ne passent entre les mailles du filet – assurez-vous de leur en parler !

Vérifiez votre documentation

Vérifiez que cette documentation est complète et effective en la testant auprès de personnes qui n’ont pas participé à votre projet auparavant. Pour chaque sytème d’esploitation, trouvez au moins une personne pour lire votre documentation, tenter d’installer, faire et tester des modifications et participer aux différentes modifications du projet (au choix de votre testeur, ces modifications peuvent être des faux changements ou des vraies tâches). Vérifiez que vos testeurs ont des compétences et/ou une expérience similaire à celle des nouveaux arrivants à votre évènement.

Si vous rencontrez des difficultés pour trouver des personnes pour vous aider, essayez la chaine #openhatch sur IRC.

Assurez-vous que tous les problèmes qui surviennent lors de ce processus de vérification soient intégrés à la documentation. Une fois que la documentation a été vérifiée, ajoutez une ligne au début de votre guide pour annoncer ce qui a été vérifié et quand.

Par exemple :

Instructions de l’environnement de développement testées avec succès sur Ubuntu 12.04 (le 03/10/2013), Mac OS X 10.8 (le 01/10/2013) et Windows XP (en janv. 2005). Vous pouvez consulter cette démarche à OpenHatch ici.

Idéalement, vous devriez vérifer que tout fonctionne : installer, faire des modifications, les tester et les intégrer. Si vous n’avez le temps que pour une seule de ces tâches, nous vous recommandons de vérifier l’intallation. Notre expérience nous a appris que c’est sur ce point qu’émergent la plupart des problèmes.

Définir les tâches des participants

Retournons aux objectifs de l’événement dont nous avons parlé dans la première section. Chaque objectif devrait être décomposé en étapes distinctes qui permettront de l’atteindre. Ces étapes sont les tâches à confier aux participants.

Ces tâches devraient inclure un résumé en anglais simple aussi bien que les informations sur la localisation des modifications (par exemple, quels fichiers ou fonctions sont altérés). Nous recommendons d’inclure une liste des compétences nécessaires (par exemple : compétences en design, Python basique) et des outils (par exemple: Développement sur environnement Mac). Il est aussi utile d’inclure le nombre estimé d’heures que la tâche va prendre, d’étiqueter certaines tâches comme plus ou moins importantes, et de marquer où quelle tâche est dépendante d’une autre.

Cela semble représenter beaucoup de travail mais cela devrait aider vos participants à trouver rapidement et facilement les tâches appropriées pour eux. Etant donné que l’un des objectifs principaux d’un événement en personne est de donner une expérience positive aux participants, nous pensons que cela en vaut la peine.

Créer un système pour suivre les tâches

Nous recommandons l’utilisation d’un wiki ou un document de planification similaire pour garder une trace des tâches. OpenHatch dispose d’un navigateur pour suivre les tâches que nous utilisons pour nos événements. Vous pouvez, si vous le souhaitez, faire un fork et l’adapter à votre projet ou événement ; cependant, nous vous recommandons d’attendre un peu, car nous allons bientôt faire de grosses améliorations. Quelque chose de très simple, comme un etherpad (NdT : ou Framapad), peut également faire l’affaire (ici, un cadre et un service exemple que vous pouvez utiliser).

Préparer les tâches

Pour vous rendre compte du nombre de tâches à préparer, nous vous recommandons de vous baser sur la durée de l’événement et le nombre de participants attendus pour prédire la charge en temps/homme de votre projet. Vous pouvez utiliser les estimations de temps que vous avez faites pour évaluer chaque tâche. Nous suggérons que vous prévoyiez 30% de plus que ce dont vous pensez que vous aurez besoin : il vaut mieux avoir trop que pas assez.

Exemple :

• Objectif de base : parcourir l’interface et étiqueter les tickets selon le type de résolution nécessaire. Est-ce qu’un bug doit être vérifié ? Est-ce qu’un patch doit être testé ? Une fonctionnalité doit-elle être rattachée à un jalon ?
  • Tâche 1 : étiqueter les problèmes
    • Compétences et outils nécessaires : compétences de base en anglais, connaissance des concepts de vérification, tests, jalons…
    • Temps estimé : ~20 minutes par problème
    • Pour démarrer : prenez connaissance du suiveur de tickets, et comment il affiche les informations. (Voyez cette documentation.) Demandez un accès Administrateur pour pouvoir ajouter des étiquettes au suiveur.
    • Pour chaque problème : lisez la discussion relative à chaque problème, et identifiez où la communauté intervient dans le signalement de ce problème. Si c’est un bug non vérifié, ajoutez le label non vérifié. Si c’est un patch non testé, ajoutez l’étiquette patch non testé, etc. Si c’est une fonctionnalité qui n’est rattaché à aucun jalon, ajoutez l’étiquette jalon nécessaire.
• Objectif étendu : utilisez les étiquettes comme un guide pour résoudre chaque ticket. Vérifiez les bugs, testez les patch, etc.
  • Tâche 1 : Vérifier les bugs
    • Compétences et outils nécessaires : compétences de base en anglais, et dans l’idéal connaître les machines virtuelles pour effectuer des tests sur plusieurs OS.
    • Temps estimé : 20 minutes par bug (variance élevée).
    • Pour démarrer : téléchargez l’environnement de développement et assurez vous que vous pouvez lancer le projet. Assurez vous que vous avez un compte sur Le suiveur de tickets et que vous savez ajouter des commentaires ou changer les étiquettes.
    • Pour chaque bug : essayez de reproduire le bug. Enregistrez les résultats dans un commentaire, avec des informations concernant le type de l’OS et sa version. Si possible, effectuez le test sur plusieurs navigateurs. S’il y a plusieurs commentaires récents sur les trois OS majoritaires, ajoutez l’étiquette prêt pour test par le mainteneur (NdT : ready_for_maintainer_review).

Quoi qu’il en soit, les participants doivent être rattachés à une tâche correspondant à leurs compétences et à leurs intérêts. Effectuer ce travail préparatoire fera démarrer les participants immédiatement plutôt que de les faire attendre que vous leur suggériez une tâche adéquate. Dans l’idéal, les organisateurs d’événements auront collecté des informations sur les compétences et intérêts des participants bien en amont, donc vous pourrez adapter la liste à votre groupe de contributeurs.

Rendre explicites les étapes de chaque tâche facilite l’entraide entre les participants. En identifiant clairement les compétences et concepts nécessaires, il devient plus facile pour les gens de dire : « Oh, je comprends comment faire ça ! Attends, je vais te montrer ».

Suite

Il est possible que les contributeurs ne puissent pas finir les tâches sur lesquelles ils travaillent pendant l’événement, ou qu’ils veuillent continuer à participer au projet en travaillant sur d’autres tâches. Penser en amont de l’événement à comment vous allez organiser sa suite rend plus facile l’échange d’informations avec les participants et la planification de la direction de votre projet.

Nous recommandons de demander à chaque participant de répondre aux questions suivantes à propos des tâches sur lesquelles ils ont travaillé. Donnez leur cette liste au début de l’événement : cela les aidera à documenter ce qu’ils font. Vous pouvez imprimer cette liste, l’envoyer par mail aux participants, faire un formulaire web, comme vous préférez.

Par exemple :

• Pour chaque tâche sur laquelle vous avez travaillé, veuillez répondre aux questions suivantes :
  • Sur quelle tâche avez-vous travaillé ?
  • Veuillez documenter brièvement votre workflow. Quelles étapes, dans quel ordre, pourquoi ?
  • Où puis-je trouver le travail que vous avez réalisé pendant l’événement ? Ceci inclut le code, la documentation, les maquettes, et autres choses.
  • Si vous avez créé des comptes pour le projet, veuillez lister les sites et les noms des comptes. Enregistrez le mot de passe dans votre gestionnaire de mot de passes préféré, ou assurez vous que moi ou un autre mainteneur y aie accès.
  • Quels obstacles avez-vous rencontré en travaillant sur cette tâche ? Avez-vous des retours à me faire pour améliorer le processus pour les futurs contributeurs ?
  • Voudriez-vous rester impliqué dans ce projet ? Si oui, dans quelle mesure ?

S’il y a suffisamment d’enthousiasme pour continuer le travail, assurez-vous de rester en contact ! Nous suggérons que vous rassembliez les emails des participants intéressés et que vous les contactiez dans les 48 heures suivant l’événement. Dans votre email, remerciez-les pour leur aide et fournissez des informations sur comment rester dans la communauté par, par exemple, IRC ou des listes de diffusion.

Nous recommendons aussi de prévoir un rendez-vous suite à l’événement. Si vous êtes tous originaires de la même région, essayez de fixer une date après l’événement pour vous et votre équipe au café du coin, à l’espace de coworking, ou à une soirée-projet. Si vous êtes éloignés géographiquement, fixez une date pour vous rencontrer sur IRC ou sur Google Hangout. 2-3 semaines après l’événement est un bon créneau, toutefois cela dépend si vous et vous nouveaux contributeurs êtes très occupés.

Checklists

Merci de votre attention ! Pour vous aider à garder un oeil sur chaque étape, nous avons créé deux checklists pour vous. La version détaillée inclut tous les conseils ci-dessus. La checklist la plus courte inclut les conseils que nous pensons les plus importants. Nous vous recommandons de démarrer avec la cheklist la plus courte. Une fois que vous avez accompli correctement cette checklist, vous pouvez revenir et faire les étapes supplémentaires si vous avez le temps et l’énergie.

Pour voir et/ou imprimer les checklists, se rendre ici.

Remerciements

Merci à tous ceux qui ont contribué ou aidé au projet.

Contributeurs

• Shauna Gordon-McKeon : maintenance, contenu
• Ni Mu : design
• Sheila Miguez : testeuse
• Asheesh Laroia : testeuse

Pour aller plus loin

• Open Advice (NdT : entièrement traduit par nos soins)
• Producing Open Source Software (NdT : entièrement traduit par nos soins)

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

The Day We Fight Back: A Call To the International Community to Fight Against Mass Surveillance

Katitza Rodriguez – 27 janvier 2014 – EFF.org
(Traduction : nitot, Asta, amha, piero, GregR, maxauvy)

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.

Crédit photo : Greenoid (Creative Commons By-SA)

Blog vraiment anonyme : mode d’emploi !

« Et si vous me trouvez, je serai vraiment très impressionné. »

Comment créer un blog anonyme

How to Start an Anonymous Blog

Anonyme (évidemment) – 26 janvier 2014 – Untraceable
(Traduction : crendipt, aKa, Diab, Penguin, Omegax, amha, nanoPlink, Paul, Scailyna, Scailyna, Asta, Unnamed, goofy, lamessen)

Introduction

Je crois qu’en suivant les étapes que j’expose dans ce billet, personne ne sera capable de dévoiler mon identité. Mon domaine peut être saisi et mon blog peut être fermé, mais je reste persuadé que mon identité restera un mystère.

Si je dis cela, c’est principalement parce que j’ai confiance dans un outil très important appelé Tor. Les développeurs et administrateurs des nœuds de Tor travaillent pour que chacun puisse être anonyme sur Internet. Tor est une sérieuse épine dans le pied pour la NSA et pour les autres organisations et pays qui font de l’espionnage sur Internet.

Vu que le réseau Tor rend très difficile l’identification des adresses IP et que l’enregistrement de domaines est désormais possible via Bitcoin, je n’ai à aucun moment besoin de fournir une quelconque information personnelle pour la mise en place de ce blog.

Outils et ressources

• Clé USB
• Système d’exploitation Tails
• Réseau Tor
• Bitcoins locaux – Acheter des bitcoins en espèces
• Comptes mail gratuits chez outlook.com et anonymousspeech.com
• Nom de domaine acheté chez IT Itch
• Site statique hébergé sur des pages GitHub

Tails / Tor

Tails est lancé depuis une clé USB qui inclut une partition chiffrée. Cette partition contient un porte-monnaie Bitcoin, le code source du blog et une base de données Keepass. Mes mots de passe pour des services tiers sont des mots de passe très forts générés aléatoirement. Avec Tails, il est difficile de se tromper, car toutes les connexions doivent obligatoirement passer par Tor. Par exemple, pour développer ce blog en local, je dois ajuster les règles du pare-feu pour autoriser les connexions locales au port 4000, télécharger un navigateur différent (Midori) et régler celui-ci pour qu’il n’utilise pas de serveur proxy. Le pare-feu bloque toutes les requêtes externes de Midori, mais je peux accéder à http://localhost:4000.

Donc, à moins d’agir de manière insensée, par exemple me connecter à StackOverflow au moyen de mon vrai compte Google et utiliser l’identifiant de « untraceableblog », je pense qu’il est quasiment impossible de me pister.

Je fais une sauvegarde de la clé USB sur mon ordinateur principal, sur un volume caché TrueCrypt. J’aime le concept des volumes cachés, j’ai l’impression d’être un putain d’espion. L’idée, c’est d’avoir un mot de passe factice qui déverrouille un faux dossier chiffré et un mot de passe réel pour déverrouiller le vrai dossier chiffré, sans qu’il y ait aucun moyen pour les autres de savoir lequel vous déverrouillez. Dans mon faux dossier chiffré, je garde ma base personnelle de Keypass, de cartes de crédit, et des scans de mon passeport et permis de conduire. Donc si quelqu’un me force à entrer mon mot de passe pour déverrouiller mon ordinateur et découvre que j’ai un volume TrueCrypt, il n’aura aucun moyen de savoir si j’ai entré le mot de passe réel ou bidon.

Cette fonctionnalité autorise une légère protection contre les tentatives d’extorsion de votre mot de passe par la force.

La plupart du temps, je cache la clé dans un endroit secret de la maison. Quand je dois aller quelque part et que je veux pouvoir mettre à jour ce blog, je le sauvegarde sur le volume caché, puis j’efface la clé de manière sécurisée et je peux l’emporter avec moi sans aucune crainte. C’est ce que je devrai faire jusqu’à ce que Tails intègre sa propre fonction pour les « volumes cachés ».

Messagerie électronique

J’ai créé un compte de messagerie gratuit sur Outlook.com et j’utilise anonymousspeech.com pour la vérification et la sauvegarde.

J’ai d’abord essayé Gmail, mais Google rend la création de compte très difficile quand on utilise Tor, à cause de la vérification par téléphone. C’est compréhensible, à cause des gens qui aiment créer un grand nombre de faux comptes pour envoyer du spam.

Blog

Ce blog est libre sur les pages GitHub, il utilise Octopress pour créer un site statique et j’ai installé le thème Page Turner. J’ai envoyé le contenu sur GitHub avec une clé SSH, bien entendu chiffrée et stockée sur ma clé USB.

Il me vient à l’esprit deux vecteurs susceptibles de vous donner des informations sur mon identité :

L’horodatage des messages

Le système d’exploitation Tails dispose d’une bonne stratégie pour forcer l’heure du système à être systématiquement en UTC. Mais si j’écris une série de billets dans les années à venir, vous pourriez en analyser l’horodatage pour déterminer mon fuseau horaire. Cependant, le site compilé indique uniquement la date. Par ailleurs, je voyage beaucoup (ou pas ?) 😉

Analyse de la fréquence des mots et caractères

Vous pourriez être capables de déterminer mon pays d’origine ou mon identité grâce à mes mots et mes phrases. Vous pourriez même trouver une corrélation avec les autres contenus que j’ai publiés en ligne sous ma véritable identité. Je contre cette possibilité en passant tous mes billets dans Google Translate. Je traduis dans une autre langue, puis en anglais et je corrige ensuite les erreurs. C’est parfait pour diversifier mon vocabulaire, mais j’aurais aimé que ça ne casse pas autant le Markdown et le HTML. Jusqu’ici vous pourriez croire que l’anglais est ma seconde langue. Mais laissez-moi vous assurer d’une chose : je n’ai jamais affirmé ni infirmé ce point.

Un des problèmes, c’est que Google peut voir mes messages originaux et probablement aussi la NSA. Si je voulais l’éviter, je pourrais poster des demandes de traductions anonymes et payer les traducteurs en bitcoins.

Statistiques

Les raisons de l’indisponibilité de Google Analytics vous sont données sous « Messagerie électronique ». À la place, j’ai choisi StatCounter.

Mais même si Google Analytics avait été disponible, je n’aurais pas utilisé une ID de suivi liée à mon identité réelle. Beaucoup de blogueurs anonymes ont été trahis par l’annuaire d’ID inversé proposé par Google.

Acheter des bitcoins avec le maximum d’anonymat

J’ai acheté les bitcoins en utilisant un compte anonyme créé via Tor. J’ai trouvé un vendeur qui souhaitait me rencontrer en personne et nous avons convenu d’un rendez-vous. Nous nous sommes rencontrés, je lui ai donné l’argent et il m’a transféré les bitcoins en utilisant son téléphone.

Acheter un nom de domaine avec des bitcoins

IT Itch est un registrar qui accepte les paiements via BitPay. Leurs noms de domaine sont assez chers,15 USD chacun, mais permettent un enregistrement totalement anonyme. Ce fut une démarche facile, mais il a fallu du temps pour que le domaine devienne actif (plus d’une heure). Une fois activé, j’ai configuré les enregistrements DNS pour GitHub Pages, et ensuite mon blog était accessible sur http://untraceableblog.com.

IT Itch a fait la grosse erreur de m’envoyer mon mot de passe en texte clair après la création du compte. PAS BIEN ! Si quelqu’un parvient à accéder à mon compte Outlook, il peut se connecter et détruire mon site. Donc j’ai effacé le message et changé mon mot de passe, et heureusement ils ne l’ont pas renvoyé par e-mail.

Comment je pourrais être découvert, 1ère partie

Pister les Bitcoins

En théorie, vous pouvez suivre la trace des transactions Bitcoins et découvrir mon identité. Toutefois, dans ce cas, il est très peu probable que même l’organisation la plus sophistiquée et la mieux financée puisse me découvrir.

Voyez-vous, j’ai acheté ces Bitcoins en utilisant un compte anonyme sur localbitcoins.com (créé en utilisant Tor). Nous avons convenu, le vendeur et moi, de nous rencontrer en personne, et j’ai payé en liquide. Pour dévoiler mon identité, il faudrait que vous puissiez casser les défenses de tous les services que j’ai utilisés ou bien travailler chez eux. Il faudrait par exemple :

1. Accéder à la base de données de ititch.com et trouver l’identifieur de la transaction BitPay pour untraceableblog.com
2. Accéder à la base de données de BitPay et trouver l’adresse Bitcoin qui a envoyé les Bitcoins pour cette transaction
3. Accéder à la base de données de localbitcoins.com. Trouver l’adresse Bitcoin qui a envoyé les Bitcoins à BitPay, retracer la transaction jusqu’à ce que vous trouviez l’adresse localbitcoins du dépôt fiduciaire.
4. À partir de l’adresse du dépôt fiduciaire, vous pourrez trouver le compte localbitcoins, et retrouver les messages que nous avons échangés pour nous rencontrer.
5. Vous devrez vous rendre au point de rendez-vous et espérer qu’il existe des caméras de surveillance qui auraient pu nous enregistrer ce jour-là.
6. Vous aurez enfin besoin d’accéder à la société de sécurité qui possède les enregistrements des caméras de surveillance, obtenir une bonne image de mon visage et faire tourner d’une façon ou d’une autre un logiciel de reconnaissance faciale pour découvrir mon identité. Travailler pour Facebook ou la NSA pourrait aider si vous avez réussi à parvenir à ce point.

Comment je pourrais être découvert, 2ème partie

Tout est hacké. Absolument tout.

Internet est une machine basée sur la confiance et il existe de nombreuses manières de briser cette confiance. Quelqu’un peut générer des certificats SSL de confiance pour n’importe quel domaine, exiger que son FAI route l’intégralité du trafic au travers de ces certificats, ou contrôler un grand nombre de nœuds Tor et réaliser des attaques par analyse de trafic. Je n’entrerai pas dans les détails mais si vous êtes intéressés, vous pouvez en apprendre davantage sur les attaques Tor :

• Comment la NSA attaque les utilisateurs de Tor / Firefox avec quantum et FOXACID
• Articles concernant les attaques sur le blog de Tor

Conclusion

Je n’ai fait ce blog que comme un exercice amusant d’anonymat, même si j’y posterai probablement des choses dans le futur. J’ai simplement utilisé des outils créés par des gens bien plus intelligents que moi et je ne suis sûrement pas le premier blogueur anonyme, mais j’espère vous avoir appris quelque chose.

Bien évidemment, on peut aller beaucoup plus loin que ça. J’aurais pu héberger ce blog sur un VPS que j’aurais loué avec des Bitcoins et installer le serveur comme un service Tor masqué. L’adresse IP du serveur aurait été totalement protégée mais, de ce fait, vous n’auriez pu consulter ce blog qu’au travers du réseau Tor, et les liens de nœud Tor (TBR) ça ne fait pas très chouette en page d’accueil. J’aurais également pu faire toutes mes actions depuis un cybercafé, juste au cas où Tor serait compromis, mais je n’aurais pas été découvert. Enfin, j’aurais pu choisir un domaine en « .se » si j’avais eu peur de l’intervention du gouvernement américain. C’est ce qui est actuellement utilisé par The Pirate Bay, et les Suédois leur laissent toute liberté d’action.

N’hésitez pas à m’envoyer quelques Satoshis (fractions de Bitcoins) si vous aimez ce billet : 146g3vSB64KxxnjWbb2vnjeaom6WYevcQb.

Et si vous me trouvez, je serai vraiment très impressionné.

Crédit illustrations : AndyRobertsPhotos (Creative Commons By) et XKCD

Yann Houry est professeur de lettres. Il place ses supports de cours depuis 2007 sur le site Ralentir Travaux, bien connu de ses collègues. Il y propose notamment des manuels complets pour les classes de Sixième et de Quatrième.

Nous lui avions ouvert nos colonnes en septembre 2012 parce que, contrairement aux maths où l’on a Sésamath, il est rare de trouver des ressources pédagogiques en libre diffusion en français. Nous souhaitions également pouvoir discuter avec lui de son choix du support iPad et de la licence Creative Commons By-NC-SA pour le contenu de son site et ses manuels.

Or justement, il souhaite abandonner aujourd’hui cette clause NC, qui pose selon nous problème dans l’éducation, et s’en explique ci-dessous. Nous en sommes ravis (d’autant que cela ouvre la voie à une possibilité d’édition Framabook). Et il n’est pas anodin que le titre de son annonce s’intitule Unchain my site !

« J’ai fait mes calculs. J’aurais besoin de 2000 à 2500 € pour acheter diverses choses (nouvel ordinateur, un micro, quelques logiciels, etc.). Une telle somme est donc la condition du changement de licence. Cela en vaut-il la peine ? J’avoue que je suis assez curieux de le découvrir. Peut-être cette demande fera-t-elle un joli flop. En ce cas, la question de la licence ne taraude que moi. »

Nous appuyons sans réserve la démarche en invitant nos visiteurs à participer à la collecte, histoire de montrer que nous sommes nombreux à être taraudés par le bon choix d’une licence 😉

Pour cela, se rendre sur le site Ralentir Travaux et cliquer sur la bandeau du haut.

Unchain my site

URL d’origine du document

Depuis sa création, Ralentir travaux a eu vocation à être diffusé le plus largement possible. Le site n’est-il pas né du désir d’offrir à tous – surtout aux élèves ne bénéficiant d’aucun soutien scolaire – la possibilité de trouver une aide sans inscription, sans mot de passe ou sans contrepartie quelconque ? Il s’agissait aussi de proposer, à l’enseignant désireux de trouver un peu d’inspiration, des ressources qu’il pourrait adapter à sa guise.

Dès lors la liberté était inscrite dans les gènes du site. J’avais d’ailleurs repris à mon compte ces mots de Condorcet afin de montrer que la notion de propriété intellectuelle était un abus qu’il fallait dénoncer^[1].

Par le passé, j’usais du mot «libre» sans trop savoir quelle notion il recouvrait. Plus tard, je découvrais les licences Creative Commons et m’emparait de celle-ci. Cela signifiait : fais ce que tu veux, mais ne vends pas. Or cette clause non commerciale (et cela a été dit de nombreuses fois) est un frein à la diffusion du savoir. Et Ralentir travaux n’a pas vocation à se recroqueviller sur lui-même dans la crainte d’une exploitation commerciale. Ce serait un non-sens. Au reste, nombreuses sont les personnes requérant l’autorisation d’utiliser telle ou telle partie du site, et invariablement la réponse est affirmative. Seule une demande était restée sans suite en raison de cette fameuse clause NC…

Il est donc nécessaire de recourir à une nouvelle licence. Seuls le partage à l’identique et la reconnaissance de la paternité de l’œuvre seront exigés. Que l’on me pardonne ce dernier sursaut d’orgueil (que m’accorde le droit), mais je tiens encore un peu à ma progéniture ! J’ai juste envie de lui donner un peu le large, et d’observer de loin ce qu’elle devient entre les mains de ceux qui voudront bien s’en emparer, et, je l’espère, la diffuser plus largement encore.

Mais, avant d’adopter une telle licence, je voudrais poser une condition. Il y a quelque temps j’affichais un bandeau afin de susciter les dons. Je paie les frais d’hébergement et ceux liés à l’achat du nom de domaine, les logiciels ou leurs mises à jour. Que dire de mon Mac acheté en 2008, si ce n’est qu’il est vieillissant^[2] ? Je ne demande pas de salaire pour les années passées à bâtir Ralentir travaux, mais je veux bien un peu d’aide pour continuer l’œuvre. Or ces dons, malgré la promesse que pouvaient constituer les milliers de visites quotidiennes^[3], se sont montrés largement insuffisants^[4]. En un an, à peine de quoi acheter InDesign ou un logiciel de ce type…

J’ai fait mes calculs. J’aurais besoin de 2000 à 2500 € pour acheter diverses choses (nouvel ordinateur, un micro, quelques logiciels, etc.). Une telle somme est donc la condition du changement de licence. Cela en vaut-il la peine ? J’avoue que je suis assez curieux de le découvrir. Peut-être cette demande fera-t-elle un joli flop. En ce cas, la question de la licence ne taraude que moi.

Toujours est-il que nombre de sites recourent annuellement aux dons. Je m’en remets donc à ce principe. Et encore ! je n’attends même pas une cotisation annuelle, mais celle de sept ans passés à construire le site et plus encore, puisque je n’entends pas m’arrêter là (le manuel de 5e est déjà en chantier).

Bref, il ne reste plus qu’à organiser ce financement, mais vous pouvez d’ores et déjà faire un don sur Ralentir travaux en cliquant sur la bannière du haut de chaque page.

Passé le seuil financier susmentionné, Ralentir travaux (tout : le site, les manuels) devient libre.

Si les abeilles disparaissaient de la surface du globe, l’homme n’aurait plus que quatre années à vivre, estiment certains apiculteurs.

Or on assiste depuis une décennie à un phénomène inquiétant en Europe : le syndrome d’effondrement des colonies d’abeilles.

Et si le Libre permettait d’améliorer la situation en rendant plus accessible la création de ruches ?

Tel est, en gros résumé, l’objectif principal du projet Open Source Beehives qui propose, entre autres choses, des plans de ruches à monter soi-même sous licence libre (CC By-SA).

Un réseau intelligent de ruches open source peut-il stopper l’apocalypse chez les abeilles ?

Can A Smart Beehive Network Of Open-Source Hives Help Stop The Bee Apocalypse?

Ben Schiller – 18 novembre 2013 – FastCoExist.com
(Traduction : goofy, ardeur, Llu, KoS, Asta, Penguin, Llu + anonymes)

Le projet Open Source Beehives (NdT : Ruches Open Source) vise à ouvrir la voie à l’apiculture à la maison, avec des plans de ruche simples et bon marché. Les abeilles mourant par millions, il faut propager l’information.

Des millions d’abeilles sont mortes — et c’est un vrai problème car nous en avons vraiment besoin. Une centaine de cultures agricoles (d’une valeur estimée à 30 milliards de dollars) dépendent des abeilles pour la pollinisation, sans compter qu’en bénéficient également toutes sortes d’animaux et de plantes. Nous ne pouvons pas vivre sans abeilles.

Les causes de ce syndrome d’effondrement des colonies d’abeilles (appelé Colony Collapse Disorder en anglais, ou CCD) n’ont pas encore été clairement établies, bien qu’il existe deux suspects principaux, selon une étude récente de l’USDA (NdT : United States Department of Agriculture, le Département de l’Agriculture des États-Unis). Un coupable potentiel est un acarien parasite appelé Varroa destructor, qui suce un fluide du système circulatoire des abeilles et qui porte un virus. L’autre suspect est l’augmentation de l’utilisation d’une classe de pesticide appelée néonicotinoïde. Depuis 2006, époque où les néonicotinoïdes ont commencé à être utilisés largement, les apiculteurs ont signalé qu’ils avaient perdu de 30 % à 90 % de leurs ruches.

Quelle que soit la cause, les agriculteurs vont devoir reconstituer la population d’abeilles, ce qui implique plus de ruches et davantage d’apiculteurs. Le projet Open Source Beehives espère y parvenir en diffusant des plans de ruches simples et bon marché pour qu’il soit facile à n’importe qui de fabriquer la sienne, et encourager la collaboration entre les concepteurs, les techniciens, les chercheurs et les amoureux des abeilles. Pour l’instant, il existe deux modèles : le Colorado Top Bar (dépôt sur GitHub) et le Warré (dépôt sur GitHub). Les équipes à l’origine de ces plans travaillent constamment sur des améliorations.

« Ce plan, facilement transportable, peut être réalisé à partir d’une simple planche de contre-plaqué et s’assemble en quelques minutes sans vis ni colle, comme une Wikihouse pour abeilles » déclare Tristan Copley Smith, de Open Tech Forever, un groupe qui diffuse la technologie open source. Open Tech Forever a imaginé le concept de ruche open source à peu près au même moment qu’un autre groupe, le Fab Lab de Barcelone, l’un et l’autre espèrent désormais impliquer d’autres personnes.

Outre la propagation de ruches bon marché, leur but est d’améliorer la surveillance des abeillles. Ils appellent tous les deux à la conception de capteurs bon marché, pour mesurer l’humidité, la température et d’autres paramètres. Cela aidera les apiculteurs à suivre la santé des colonies et les chercheurs à en apprendre davantage sur ce qui se passe réellement à l’intérieur de la ruche. La version Warré est déjà installée à différents endroits, les capteurs ont été testés à Barcelone, Paris et Bruxelles. Vous pouvez en découvrir davantage sur cette technologie ici :

« Notre objectif est de créer un réseau maillé de colonies intelligentes, qui crée des données ouvertes, partagées sur la plateforme Smart Citizen pour étudier le syndrome d’effondrement et ses causes », explique Colpey Smith. « Nous voulons encourager et faciliter l’apiculture à la maison, tout en éduquant les apiculteurs aux bonnes pratiques et à la création de systèmes d’alerte automatisés ».

Dans cette lettre ouverte du projet Open Source Beehives, vous trouverez plus d’informations sur leurs plans et comment vous investir. « Nous sommes à la recherche de collaborateurs intéressés pour tester nos ruches et nos capteurs avec des colonies actives, si possible dans l’hémisphère sud où c’est actuellement le printemps » dit Copley Smith. « Nous aimerions faire un maximum de tests avant de lancer une campagne Kickstarter en janvier. »

Il y a vingt ans, Daniel Ichbiah écrivait :

La connaissance planétaire est à la portée de votre micro-ordinateur. Des bibliothèques bourrées à craquer de littérature, images et sons. Des plus beaux tableaux du musée du Louvre jusqu’à la plastique de Cindy Crawford en passant par des mélopées new age inédites, des extraits de Thelonious Monk ou l’intégrale des Fables d’Ésope. Un geyser d’informations indescriptible. Avec la possibilité de communiquer avec des milliers de passionnés du même sujet, d’échanger idées, documents, clips vidéo… Il ne s’agit pas d’un rêve éveillé. Cela ne se passe pas en 2020, ni même en 2010 ! Vous pouvez l’avoir chez vous en 1994. Il s’agit d’Internet, le réseau qui regroupe déjà trente millions de branchés du monde entier.

Aujourd’hui… le même enthousiaste d’alors publie un pamphlet pour dénoncer la confiscation de nos biens culturels par les nouvelles superpuissances.

Aujourd’hui… ou plutôt non, c’est déjà hier que pour une poignée de dollars Google s’est approprié la culture mondiale. C’est hier que nous avons vu le mouvement inéluctable par lequel les éditeurs finissent par passer des accords de numérisation des imprimés avec Google. Et c’est bien cette année qu’a éclaté le scandale de la numérisation concédée par la BNF (oui, la Bibliothèque Nationale de France !) à des opérateurs privés qui mettent ainsi la main sur le domaine public.

Dans ce contexte, la décision de la Bibliothèque Nationale norvégienne semble d’une audace inouïe, alors qu’on devrait la considérer comme allant de soi : donner l’accès numérique à leur culture à tous les citoyens devrait être un principe partagé. Même en France.

Lire une page à la plage… (Photo mikemol– CC BY 2.0)

La Norvège s’apprête à numériser tous les livres en norvégien, et autorisera les adresses IP norvégiennes à les lire tous, quel que soit le copyright

Article original du magazine Techdirt

Traduction Framalang : audionuma, sinma, goofy, KoS, Penguin, peupleLà, Sky, lamessen

Voici une nouvelle plutôt étonnante qui nous vient de Norvège :

La Bibliothèque Nationale de Norvège prévoit la numérisation de tous les livres d’ici le milieu des années 2020. Oui, tous. Tous les livres. Du moins les livres en norvégien. Des centaines de milliers de livres. Chacun des livres du fonds de la Bibliothèque Nationale.

Bon, dans n’importe quel pays normal — appelons « normal » un pays où le copyright a atteint des sommets de démence monopolistique —, si lesdits livres étaient encore sous copyright, et à supposer que leurs éditeurs en aient au préalable autorisé une version numérique, on ne pourrait probablement y avoir accès que dans un réduit spécialement conçu à cet usage au troisième sous-sol de la Bibliothèque Nationale, et les lire sur un (petit) écran, sous le regard de gardiens placés de chaque côté, chargés de vérifier qu’aucune copie illégale n’est effectuée.

Voici tout au contraire ce qui va se passer avec la collection numérisée de la Bibliothèque Nationale norvégienne :

Si, selon l’adresse IP de votre machine, vous résidez en Norvège, vous aurez la possibilité d’accéder à tous les ouvrages du XX^e siècle, y compris ceux qui sont encore sous copyright. Les œuvres hors copyright, quelle que soit la période, seront accessibles en téléchargement.

Comme le souligne avec humour Alexis C. Madrigal dans son article du magazine The Atlantic, il peut y avoir des conséquences plutôt intéressantes à ces approches de la numérisation si différentes entre la Norvège et les USA :

Imaginez les archéologues numériques du futur tombant sur les vestiges d’une civilisation datant du début du XXI^e siècle, dans un antique data center au fin fond de la toundra en plein réchauffement climatique. Ils fouillent tout cela, trouvent quelques débris de Buzzfeed et de The Atlantic, peut-être un fragment de l’Encyclopaedia Britannica, et puis soudain, brillant comme une pépite au milieu des résidus numériques : une collection complète de littérature norvégienne.

Tout à coup, les Norvégiens deviennent pour les humains du XXVII^e siècle ce que les Grecs de l’Antiquité ont été pour notre Renaissance. Tous les couples des colonies spatiales se mettent à donner à leurs enfants des prénoms comme Per ou Henrik, Amalie ou Sigrid. La capitale de notre nouvelle planète d’accueil sera baptisée Oslo.

Voilà ce qui arrive aux pays qui imposent des lois abusives en matière de copyright. Non seulement elles empêchent les artistes d’aujourd’hui de créer leurs œuvres en s’appuyant sur celles de leurs prédécesseurs — une pratique qui était habituelle pendant des siècles avant que n’apparaissent récemment les monopoles intellectuels — mais ces lois vont jusqu’à mettre en péril la conservation et la transmission de cultures entières, tout cela en raison du refus des éditeurs d’adapter la règlementation du copyright à notre temps, c’est-à-dire d’autoriser la numérisation à grande échelle et la diffusion à la façon dont la Norvège l’envisage.

 – – –
En savoir plus : La page de présentation de la politique de numérisation sur le site de la National Library of Norway