Le samedi 17 mai et le dimanche 18 mai à Gérardmer se déroulera un événement inédit dans la région Grand Est : Vosges Opération Libre. Il est ouvert à tous et orienté à la fois vers le grand public et les professionnels.

Cette opération libre est à l’initiative de Framasoft et d’autres d’associations d’envergure nationale ayant une grande expérience dans le Libre, l’ouverture des données, les licences libres et le libre accès.

Il s’agit de la seconde Opération Libre se déroulant sur le territoire français. La première ayant eu lieu à Brocas (Aquitaine) en 2013. Les Opérations Libres visent à rassembler, le temps d’un week-end, des acteurs du Libre en vue d’initier la démarche open data dans les petites villes et villages en présentant les outils disponibles, notamment des logiciels libres. Elles invitent les habitants à participer à l’ouverture et à la diffusion des données de leur territoire. Elles proposent aussi d’engager les citoyens dans un rapport différent avec leur territoire en montrant que le partage des connaissances leur permet d’être collectivement valorisées.

Cette initiative portera aussi sur les usages numériques, leur appropriation, leur potentiel de créativité et leur économie. Cette manifestation vise à promouvoir la culture libre et l’ouverture des données en organisant des actions thématiques formulées en stands, ateliers de formation, conférences, projection permanente de films libres, débats, etc.

Il s’agit d’un événement culturel et participatif où le logiciel libre et ses principes sont conçus comme autant de moyens au service des activités pratiques proposées à destination du grand public. Un travail préalable précédant la manifestation a été mené avec les acteurs de la vie culturelle locale, en particulier la médiathèque de Gérardmer (soirées Wikipédia, ateliers et conférence).

Le programme de la manifestation est disponible à l’adresse vosges.operation-libre.org. Il comprendra :

• 8 ateliers (4 permanents et 4 ponctuels) ;
• 9 conférences ;
• 1 conférence-débat le samedi soir
• 17 stands, des démonstrations ;
• une projection permanente de films libres…

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)

En mai prochain aura lieu la seconde édition du Festival des Commons à Héraklion sur l’île de Crète.

Nous avons choisi d’en traduire l‘à propos, pour illustrer cette dynamique des biens communs mentionnée dans un billet précédent. Et aussi pour parler un peu de la Grèce de manière positive 😉

Le Festival des Communs – à propos

The Festival of the Commons – About

(Traduction : Isammoc, GregR, Diin, Scailyna, goofy, KoS)

Le Festival des biens communs (CommonsFest) est une initiative pour promouvoir la connaissance libreet la collaboration peer-to-peer pour la création et la gestion des biens communs. Une philosophie qui s’est propagée à travers les communautés du logiciel libre et s’étend à de nombreux aspects de notre vie quotidienne, tels que les arts, la gouvernance, la construction de machines, d’outils et d’autres marchandises. À travers une exposition, des conférences, des projections et des ateliers, le but du festival est de promouvoir et faire connaître les réalisations de cette philosophie au public et de faire un premier pas vers de plus amples adoptions.

Aujourd’hui, il existe un monde où la liberté de la connaissance et de l’art est une réalité, et où les opinions sont exprimées et débattues librement afin que les décisions soient prisent collectivement. Un monde où le bien commun est plus important que le profit individuel, où il existe un respect des ressources naturelles et de la dignité humaine, un monde où l’argent n’est qu’un moyen de subvenir à nos besoins. Dans ce monde, vous pouvez librement faire pousser ce qui va vous nourrir, remixer une chanson, donner votre avis à propos d’un projet de film, améliorer les plans de conception d’un tracteur, écrire un article d’une encyclopédie, participer à une procédure de décision politique ou assister gratuitement à des cours à l’université. Un monde où vous pouvez construire une maison, subvenir à vos besoins en échangeant des biens et des services avec vos amis.

Au cours des dernières décennies, le développement des communautés du logiciel libre ont ont ouvert de nouvelles voies à la créativité, basées sur la collaboration et l’échange libre de connaissances. Ensuite sont arrivées des communautés ouvertes peer-to-peer qui ont donné l’impulsion pour que soient diffusées ces idées dans de nombreux aspects de la vie en dehors du spectre numérique. Elles témoignent au quotidien que le modèle peer-to-peer peut fournir une gestion plus équitable et plus efficace dans la vie quotidienne.

Ce modèle repose sur un certain nombre de caractéristiques essentielles de ces communautés. Les plus importantes sont le partage et la collaboration autour d’un cadre où chaque participant contribue selon ses capacités et reçoit selon ses besoins, ce qui aboutit à rendre la connaissance disponible à tous pour le bien commun. Une autre caractéristique importante, pour laquelle la création et le développement d’Internet ont joué un rôle clé, c’est que les communautés n’ont pas besoin d’un lieu commun mais peuvent être dispersées aux quatre coins du globe. Ainsi, des personnes de divers endroits peuvent collaborer à un projet commun en communicant par des moyens numériques les uns avec le autres. Travailler dans un processus de prise de décision non hiérarchique s’oppose à la concentration du pouvoir entre les mains de quelques individus avec tous les problèmes que cela implique. Cette méthode d’organisation peer-to-peer (p2p) a créé de nombreux produits caractérisées par le fait de n’être ni privés ni étatiques. On appelle ces productions des « biens communs ». Ces biens communs sont librement accessibles à tous, fondée sur la base d’un ensemble d’autorisations qui régissent leur utilisation, comme les Creative Commons (CC) ou la Licence Publique Générale (GPL).

Il existe de bons exemples de production open source et pair-à-pair au-delà du champ des biens digitaux numériques. comme les machines-outils qui sont proposées par le projet Open-Source Ecology (NdT : Écologie open-source) ou les imprimantes 3D comme Rep-Rap. Des plans libres pour fabriquer son logement tels que WikiHouse ou la prometteuse voiture Wikispeed sont d’autres exemples, de même que les recettes sans brevet pour des boissons comme Free beer (NdT : Bière libre) et OpenCola (NdT : cola-ouvert).

Les efforts pour sauver les semences traditionnelle et pour dépolluer les terrains saturés d’engrais et pesticides chimiques ont développé un réseau de connaissances que tout le monde peut suivre pour satisfaire ses besoins nutritionnels, en respectant l’environnement naturel et le travail humain. Le retour à des manières plus naturelles de construire, couplé à la recherche sur les sources d’énergies renouvelables, a ouvert de nouveaux horizons à la construction de maisons écologiques et en autonomie énergétique,ce qui constitue un pas de plus vers la gestion communautaire équitable et durable. Si on ajoute le mouvement DIY (Do-It-Yourself, Faites-le vous-même NdT) à tout cela, alors on se rend compte de la quantité impressionnante de connaissances accessibles qui peut couvrir une grande part, si ce n’est la totalité, de nos besoins quotidiens.

Tout cela pourrait en fait devenir une proposition d’organisation alternative de la société (finances comprises) car nous pouvons nous rendre compte que l’actuel système de recherche du profit ne satisfait pas les besoins de base de la majorité de la population mondiale. D’autres communautés pourraient nous apporter leur expérience de plusieurs années dans l’élaboration d’un modèle différent et plus performant pour satisfaire leurs besoins. Dans le même temps, nous constatons l’impact des groupes collaboratifs tout autour de cette mouvance qui pourrait définir en quelques mots l’économie sociale et solidaire. Ce sont pour l’essentiel et pour le moment des tentatives expérimentales qui s’accumulent avec le temps, mais qui sont des expériences précieuses de collaboration et de solidarité.

Il est évident que le passage d’une société conduite par le profit vers un système de gestion peer-to-peer ouvert ne peut pas être réalisé en un jour. Mais créons des petites structures de production pour les biens communs, là où les conditions le permettent, afin que les petits ruisseaux deviennent grandes rivières. Nous voulons que le « Festival des biens communs » soit un pas de plus dans cette direction.

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

The Day We Fight Back (press release)

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 :

• Visiter TheDayWeFightBack.org
• 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.

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.

Nous lançons ça avec Sylvain Le Bon, de http://openinitiative.com, et Frédéric Bardeau, de http://simplon.co.

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 !

-> Hackadon du 11/12/13 : donnez au libre !

Framasoft présent au JM2L 2013 grâce à Gee 😉

Crédit : Simon Gee Giraudot (Creative Commons By-Sa)

Dans le cadre de notre participation à Villes en Biens Communs nous ajoutons un double événement lié aux métiers du livre et organisé par Chloé Girard, membre de Framasoft, le 23 octobre à Paris et le 24 octobre à Lyon.

• Site officiel
• Paris 23 octobre
• Lyon 24 octobre
• Twitter : @OperateurLL
• « Inscription » aux réunions (maximum 30 personnes) sur Framadate

Présentation de La_Forge par Chloé Girard

Quelques années après avoir commencé à réfléchir à la transposition du modèle de l’Adullact vers les métiers du libre, l’Enssib, où je suis maître de conférences associé en édition numérique, a accepté de soutenir ce « projet de recherche ». J’organise donc deux réunions de présentation et de travail, l’une à Paris, l’autre à Lyon, afin de pousser la modélisation de cette Forge.

Il s’agit d’une structure accompagnant les éditeurs, libraires, diffuseurs, dans la mutualisation des fonds, la réalisation et la maintenance de logiciels métier communs et, par extension, experts, pérennes et évolutifs. Elle est gouvernée par et pour les professionnels du livre et constitue une interface « chargée de projet » côté « clients » avec les entreprises de service informatique.

De nombreux éditeurs expriment des besoins communs (de la gestion d’entreprise à la diffusion en passant par la fabrication) ou spécifiques (selon le genre éditorial par exemple, ou le modèle économique). Or aucun ou presque n’a de « département informatique » et beaucoup investissent des fonds, subventionnés ou non, sans prendre la mesure de la complexité de ces outils et de leur maintenance.

Ces deux réunions ont donc pour objectif de présenter le fonctionnement d’une telle, de réfléchir à sa gouvernance (très probablement associative), à son économie (mutualisation), et au logiciel libre (quelques a priori perdurent…).

De nombreux écueils se profilent dans ce contexte de petites entreprises privées, aux finances souvent fragiles. Du coté des développeurs (qui sont parfois les éditeurs eux-mêmes), la libération du code est souvent perçue comme l’abandon d’une potentielle manne financière, souvent en réalité plus coûteuse que rentable. Les acteurs métier espèrent aussi souvent, et nous les comprenons, se « débarrasser » de ces encombrantes questions techniques en choisissant des services en ligne, sans se soucier de la pérennité de ces services, de l’outil ou de l’entreprise qui les sous-tend.

En réponse la forge peut offrir par exemple de développer du coté « clients » les outils sur lesquels baser ce type de services de façon à ce qu’en cas de sortie d’une plateforme tout éditeur ou libraire puisse retrouver le même outil libre et le déployer, ou le voir déployer, ailleurs : expertise, qualité, indépendance et pérennité !

J’invite donc chacun à venir exprimer ses besoins en logiciels ou extensions métier, à discuter des tenants et aboutissants d’un tel projet et à y verser des logiciels développés en interne et complexes à maintenir seul.

Nous espérons au cours de ces deux réunions pouvoir identifier un besoin phare à lancer comme projet pilote.

Déroulement :

• présentation de l’Opérateur du logiciel libre pour les métiers du livre, une association à vocation d’expert informatique coté « clients » : recension de logiciels, appels à projets, rédaction de cahiers des charges, mutualisation des fonds, suivi de projet, mise en production, assistance ;
• présentation de projets : outils de gestion d’entreprise (droits d’auteur, abonnements revues, facturation, workflow de fabrication), outils de fabrication (édition de ePUB, passage ePUB to Web, mise en page PDF en ligne, annotation, lien POD), diffusion (gestion et publication de métadonnées, mesure d’usages, gestion des URL, protocoles de gestion d’accès, connexion aux réseaux sociaux, flux de catalogage, alertes, outils de librairie…) ;
• consultation autour de la gouvernance de la structure : offrir une souplesse d’adhésion et de retrait des entreprises au gré de l’ouverture et de l’aboutissement d’un projet ;
• les besoins logiciels identifiés : exprimez vos propres besoins ;
• dépôt logiciel de la Forge : être informé et avoir accès en amont aux outils existants ;
• reverser ses propres développements sous licences libres ?
• le financement des projets.

Un mois de festival pour explorer, créer et faire connaître les biens communs^[1] au quatre coins de la francophonie, ça vous dit ?

Plus de 200 événements sont organisés à partir d’aujourd’hui et durant tout le mois d’octobre dans une quarantaine de villes francophones à travers le monde pour explorer et faire connaître toute la diversité des biens communs.

Pendant ce « Mois des Communs », à Brest, Lyon, Montréal, Ouagadougou, Paris, Rennes, Lausanne, Bamako…, des visites, conférences, ateliers pratiques, et initiations en tous genres permettront aux citoyens de tous les âges de découvrir des initiatives pour créer, gérer et partager des ressources collectives.

Conférence, table ronde, expo photo, atelier d’écriture et de traduction, dédicace, musique du domaine pubic… Framasoft participera à une bonne douzaine d’événements divers et variés à Paris, Lyon, Toulouse, Rennes, Bolbec et à… l’Assemblée nationale (voir le détail ci-dessous).

-> http://villes.bienscommuns.org/

Les biens communs sont des ressources créées, gérées et partagées collectivement par une communauté de citoyens : zones urbaines transformées en jardins partagés, informations ajoutées dans l’encyclopédie Wikipédia, cartographies OpenStreet Map nourries par les utilisateurs, savoirs traditionnels, logiciels libres, science ouverte, publications en libre accès, pédibus scolaires, fours à pains mutualisés, systèmes d’irrigation agricole partagés, semences libres, contenus éducatifs ouverts, échanges de savoirs, justice participative, données ouvertes collectées par les personnes…

Quelles que soit leur échelle – de l’immeuble à la planète –, les approches par les biens communs apportent des réponses inédites et robustes, là où la puissance publique et le marché sont souvent absents ou inefficaces. Les événements de « Villes en Biens communs » cherchent à donner une visibilité à ces innovations sociales et citoyennes. Les communs ouvrent de nouvelles voies pour répondre aux différentes crises que traversent nos sociétés (écologique, économique, sociale…)

Nous en profitons pour remercier tout particulièrement l’association Vecam sans qui rien n’aurait pu se faire.

Où retrouver Framasoft

• Samedi 5 Octobre 2013 de 17h00 à 18h00 – Rennes – Pourquoi j’ai publié mes romans sous licence libre (une conférence de Pouhiou)

• Samedi 5 Octobre 2013 de 15h00 à 16h30 – Rennes – Atelier d’écriture collaborative (animé par Pouhiou)

• Mercredi 9 Octobre 2013 de 14h00 à 22h00 – Lyon – La Guillotière en biens communs (chez Locaux Motiv’ qui accueille Framasoft, avec lancement exceptionnel de «No es una crisis» le webdoc qui donne un visage à la crise espagnole)

• Samedi 12 Octobre 2013 de 13h30 à 19h00 – Toulouse – Journée « Cultures Libres » à la Novela (Pouhiou y animera un atelier d’écriture et Alexis Kauffmann une conférence ainsi qu’une participation à une expo photo, plus de détails ici)

• Mercredi 16 Octobre 2013 de 16h00 à 18h00 – Paris – Atelier de traduction collaborative à la BPI de Beaubourg (animé par Alexis Kauffmann, en direct live sur Framapad, dans la salle et sur Internet)

• Jeudi 17 Octobre 2013 de 19h30 à 21h00 – Lyon – Table ronde « Internet et Biens Communs » (avec Pierre-Yves Gosset)

• Jeudi 17 Octobre 2013 de 20h00 à 21h00 – Paris – Un peu de domaine public tout en musique ! (avec Véronique Boukali de Romaine Lubrique)

• Vendredi 18 Octobre 2013 de 09h30 à 16h30 – Bolbec – Ecriture collective d’une nouvelle policière (qui sera mise sous licence libre et surtout rédigée par des élèves de CM1 sous leur regard de leurs professeurs et de Pouhiou)

• Vendredi 18 Octobre 2013 de 20h00 à 22h30 – Bolbec – To be or not to be free! (rencontre grand public en présence de Pouhiou)

• Samedi 19 Octobre 2013 de 10h00 à 19h30 – Paris – Partagez vos œuvres ! (avec Parinux et l’April)

• Samedi 19 Octobre 2013 de 17h00 à 19h00 – Paris – Dédicace Framabook à la librairie « A Livr’Ouvert » (avec plusieurs auteurs dont Pouhiou et Simon Gee Giraudot)

• Jeudi 31 Octobre 2013 de 09h30 à 16h30 – Paris – Journée d’étude à l’Assemblée nationale sur le domaine public (Framasoft présents avec Benjamin Jean, Pouhiou et Alexis Kauffmann qui y représentera également le projet Romaine Lubrique)

• Mardi 19 Novembre 2013 de 19h00 à 22h00 – Paris – Rencontre avec Robert Douglass du projet Open Goldberg Variations (pour en savoir plus sur le projet)