Comment participer à des projets open source et s’y sentir légitime ? La réponse habituelle un peu désinvolte consiste à dire : « il suffit de commencer à proposer ne serait-ce qu’un signalement de bug ou une correction mineure dans la documentation et hop ». En commençant par une contribution minime, on peut donc trouver sa place dans une équipe. Théoriquement, c’est exact.

Mais quand on est une jeune femme à peine sortie de ses études d’informatique et qu’on éprouve un peu d’appréhension au contact des contributeurs supposés expérimentés, rien n’est tout à fait simple.

Comme on le lira dans le témoignage de Shubheksha, il faut non seulement parvenir à surmonter son manque de confiance en soi, mais aussi avoir la chance de rencontrer sur son chemin des mentors qui vous accueillent avec bienveillance, vous guident et vous invitent à contribuer davantage encore.

Le parcours cahoteux d’une débutante dans le monde de l’open source

Article original paru dans Medium : A Beginner’s Very Bumpy Journey Through The World of Open Source

Par Shubheksha

Traduction :  Lyn, audionuma, goofy, Lumibd, Manguito,et un anonyme

Avez-vous atterri ici en recherchant des conseils sur la meilleure manière de contribuer à l’open source ? Il y a des milliers d’histoires de ce genre sur Internet, n’est-ce pas ?
Je suis sûre que vous en avez lu beaucoup à présent, car vous essayez de contribuer depuis un bon moment. Et vous avez toujours l’impression de ne pas avoir progressé.
Je connais ce sentiment. J’étais exactement dans la même situation il y a quelques semaines. Laissez-moi vous conter mon histoire.

Voilà à peu près deux ans que j’essaie de contribuer à l’open source.

Oui. Deux ans.

Et il y a bien une chose que je peux affirmer : c’est intimidant. C’est dur de commencer. Vous devez apprendre comment travailler sur un long code source. Vous devez apprendre et adopter les règles de style de code d’un projet.

Tout paraît confus. L’ordre des instructions, comment les différents modules interagissent entre eux, comment et pourquoi le code est organisé de la manière dont il l’est : tout cela constitue un grand labyrinthe.

Je ressens cela en permanence car je ne suis, après tout, qu’une amatrice qui essaie d’en apprendre autant qu’elle le peut.

J’ai donc choisi de suivre la voie la plus facile : la correction de fautes dans la documentation ou les commentaires, et la résolution de bugs triviaux où il était évident de trouver ce qui devait être modifié. Je ne voulais pas poser trop de questions ni essayer de comprendre l’ensemble du code.

Chaque fois que je voulais contribuer, j’allais sur github — ou un autre gestionnaire de bugs – et j’essayais de rechercher des problèmes étiquetés « facile », « débutant », « premier bug facile ». Après en avoir consulté des centaines, je trouvais quelque chose de suffisamment simple à traiter sans beaucoup d’aide extérieure.

Alors, cela a bien fonctionné jusqu’au moment où j’ai pris conscience que je pourrais mieux utiliser les compétences que j’étais en train de développer. J’avais appris tant de nouvelles choses, mais je ne voyais pas à quoi j’aurais pu les utiliser. Apprendre sans mettre en application, c’est bien peu gratifiant. J’étais bloquée sur un palier et je n’avançais plus du tout.

Alors, il est arrivé quelque chose qui m’a terriblement effrayée en tant que nouvelle contributrice qui essaie de naviguer dans le monde de l’open source. J’avais trouvé un bug qui avait l’air assez facile dans un grand projet renommé.

J’ai pensé qu’il valait mieux demander quelques éclaircissements avant de procéder à la moindre modification car je craignais de tout bousiller. J’ai donc envoyé un commentaire indiquant que j’étais une nouvelle contributrice, et demandant quelle serait la meilleure manière de modifier un bout de texte pour corriger le bug.

La réponse que je reçus fut :

« Si tu n’arrives pas à déterminer comment effectuer cette modification, c’est que tu n’es pas qualifiée pour effectuer cette modification. »

Cette réponse me laissa complètement décontenancée, et m’effraya davantage encore à l’idée de poser des questions lorsque je ne comprenais pas quelque chose à propos d’un projet.

Peut-être étais-je indésirable parce que je n’en savais pas assez ? Peut-être devais-je travailler davantage pour acquérir des compétences au lieu de poser des questions stupides et maladroites à des personnes expérimentées beaucoup trop occupées pour me répondre ?

C’est aussi à cette époque que ma recherche d’un mentor a commencé. J’ai pensé que si je connaissais quelqu’un avec qui je serais plus à l’aise pour poser des questions, les choses se passeraient bien et je pourrais me rendre plus utile.

J’ai donc écrit à de nombreuses personnes en leur demandant de m’aider à débuter, vu que je me sentais particulièrement intimidée par mes précédentes expériences. J’ai reçu beaucoup de réponses positives, pleines d’encouragements, mais je n’ai jamais exactement trouvé ce que je cherchais.

J’avais l’impression de buter contre un environnement clos dans le monde ouvert de l’open source.

Tout semblait suggérer que je n’avais qu’à m’y mettre et à ne pas avoir peur. Mais je n’étais pas prête à ce moment là.

Ma découverte de Mozilla

Par une belle soirée, alors que je cherchais des bugs à corriger, j’ai atterri sur le projet de Mozilla qui vous aide à tester des extensions web. J’étais contente de voir qu’il y avait quelques problèmes étiquetés comme « premier bug facile » mais aucun d’entre eux n’était aussi simple que de corriger une petite coquille.

Bon sang, j’en suis tellement heureuse maintenant.

J’ai commencé à travailler sur l’un de ces bugs, mais j’ai vite compris qu’il me faudrait poser des questions si je voulais être capable de résoudre le problème. J’ai parcouru le code source. Après avoir compris les grandes lignes du problème, j’ai demandé plus d’informations. et voila ! J’ai été capable de résoudre le problème une fois que j’ai eu tous les détails nécessaires.

Maintenant que j’ai soumis trois pull requests [NDT : demandes de modification du code source] (l’une a été acceptée, les deux autres sont en passe de l’être), je suis heureuse d’avoir franchi le pas. Je suis contente de ne pas avoir hésité à poser des questions pertinentes, même si je risquais parfois d’avoir l’air de poser des questions stupides.

Ce n’est pas un problème de ne pas tout savoir et de progresser par étapes pour apprendre quelque chose de nouveau.

Les gens de Mozilla qui encadrent ces corrections m’ont beaucoup aidée et ont toujours été très positifs. Ils m’ont guidée du début à la fin, prenant le temps de m’expliquer les choses de façon à la fois simple et très détaillée. Et cela malgré le fait qu’ils n’auraient mis que quelques heures à corriger ces problèmes eux-mêmes au lieu de prendre le temps de me guider vers une solution de mon cru, dont la conception m’a pris plusieurs jours.

J’ai appris et découvert énormément de choses juste en travaillant sur ces trois problèmes basiques. Et je suis vraiment excitée à l’idée de travailler sur des problèmes encore plus difficiles et d’augmenter ma compréhension de ce sujet et mes connaissances.

Je ne peux pas les remercier assez pour cette expérience tellement positive et enrichissante, qui m’amène à installer Firefox localement et à parcourir les bugs sur Bugzilla un jour sur deux (je garde mes questions sur « Pourquoi » et « Comment » pour un billet plus long).

Je prévois de contribuer à Mozilla aussi régulièrement que possible. À chaque fois que j’ai posé une question pertinente, que ce soit sur IRC, Github ou Bugzilla, j’ai reçu des réponses très aimables.
Jusqu’à aujourd’hui, j’ai résolu trois problèmes dans web-ext, et j’ai eu un correctif accepté et intégré dans Firefox.

Mes contributions ont été remarquées par la communauté, et j’ai aussi été nommée dans le « Addons Contribution Recognition document » [NdT : la liste des contributeurs aux extensions de Mozilla].

En définitive, mes expériences de ces dernières semaines ont été vraiment merveilleuses. J’ai appris tellement de choses, petites et grandes, qu’aucun manuel de programmation n’aurait pu m’apprendre.
Voici mes conseils pour les développeurs débutants qui veulent contribuer à un projet open source :

Conseil n°1 : n’ayez pas peur de poser des questions

Je ne saurais trop insister sur ce point. J’ai perdu beaucoup de temps parce que je ne cessais de me censurer, et c’était ma plus importante inhibition.

Tout le monde a peur de paraître stupide. Mais ne laissez pas cette peur paralysante devenir une entrave à votre progression.

Il est normal de demander si vous ne comprenez pas quelque chose qui est en rapport avec le projet. Les développeurs du projet sont devenus des experts au fil des années. Ils peuvent vous aider très rapidement. Sinon vous risquez de perdre des heures le nez dans le code source à essayer de deviner quelque chose que vous n’êtes même pas censés savoir au départ.

Mais quand vous demandez des informations, vérifiez si elles ne sont pas déjà disponibles dans une documentation ou une recherche Google. Ainsi, vous prendrez garde à respecter le temps libre des développeurs du projet.

Conseil n°2 : c’est normal d’avoir des lacunes

On ne s’attend pas à ce que vous sachiez tout de A à Z lorsque vous commencez à contribuer à un projet. Le processus, c’est plutôt que vous appreniez et gagniez en compétence en résolvant des problèmes de plus en plus difficiles, et en vous familiarisant avec le projet et les outils qu’il utilise. Le temps nécessaire pour cela varie d’un projet à l’autre et d’une personne à l’autre.

Conseil n°3 : lancez-vous !

Ne perdez pas un temps considérable à choisir le projet idéal. Si vous connaissez un projet ou une organisation dont la communauté accueille amicalement les débutants, faites-en votre point de départ.

Trouvez un problème avec lequel vous êtes à l’aise, de préférence dans un langage que vous pratiquez déjà depuis un moment, et essayez d’imaginer ce qui a besoin d’être fait. Demandez des informations pertinentes afin de combler vos lacunes, et après, lancez-vous ! N’attendez pas.

Merci à tous ceux qui travaillent dans l’open source

Une dédicace spéciale à tous les contributeurs aux projets open source qui sont super réactifs et qui encouragent les nouveaux. Vous aidez les nouveaux venus à se frayer un chemin au milieu d’interminables lignes de code et les faites contribuer de manière peut-être limitée mais néanmoins significative. Vos efforts sont nécessaires et sincèrement appréciés.

En tant que débutante et développeuse junior, j’essaie juste de trouver mon chemin dans le vaste et formidable monde de l’informatique. Quelques minutes de votre temps, que ce soit pour me présenter une simple technique de débogage ou pour me montrer comment écrire correctement des tests logiciels, m’aideront, au fil du temps, à devenir une meilleure développeuse.

Vous avez l’expérience et j’ai l’envie insatiable d’apprendre autant que je peux.

Un grand merci à Guido, Kumur McMillan et Luca qui ont été de fabuleux mentors tout au long de ce parcours, ils m’ont suivie à chaque instant et ont répondu à mes diverses questions. J’ai vraiment apprécié le temps et les efforts que vous m’avez consacrés 🙂

Si vous êtes un nouveau venu qui peine à entrer dans le monde de l’open source, j’aimerais que vous me parliez de votre histoire et de votre expérience. Si je peux vous aider de quelque façon que ce soit, surtout n’hésitez pas à me contacter.

J’envisage de rendre compte de mon parcours chez les contributeurs de l’open source, donc si vous désirez que j’aborde un sujet en particulier, merci de laisser un commentaire.
Merci à Pawan Dubey et Quincy Larson pour m’avoir aidée à peaufiner cet article.

Le groupe Framalang a traduit l’article de Julien, qui a listé tous les moyens de se tirer une balle dans le pied quand on coordonne un projet libre.

Apprenez à les éviter !

Conduite de projets Open Source : 10 erreurs à éviter

Article original : https://julien.danjou.info/blog/2016/foss-projects-management-bad-practice
Auteur : Julien Danjou(CC-BY-SA)
Traduction : lyn., KoS, AlienSpoon, David 5.1, Simon, goofy, Slimane Aguercif, Fred, galadas, terhemis, gégé

Il y a quelques semaines, lors de l’OpenStack Summit (réunion annuelle des contributeurs à OpenStack, NDT), j’ai eu l’occasion de discuter de mon expérience de la conduite de projets Open Source. Je me suis rendu compte qu’après avoir fait partie de plusieurs communautés et beaucoup contribué pendant des années, je pourrais faire profiter les nouveaux venus de conseils et d’avis expérimentés.

Il existe une foule de ressources disponibles expliquant comment conduire un projet Open Source. Mais aujourd’hui, je voudrais aborder ce sujet sous un angle différent, en insistant sur ce qu’il convient de ne pas faire avec les personnes qui y participent. Je tire cette expérience des nombreux projets Open Source auxquels j’ai participé ces dernières années. Je vais décrire, sans ordre particulier, quelques mauvaises pratiques que j’ai constatées, en les illustrant par des exemples concrets.

1. Considérer les contributeurs comme une nuisance

Quand les informaticiens sont au travail, qu’ils soient chargés du développement ou de la maintenance d’un logiciel, il est une chose dont ils n’ont pas besoin : du travail supplémentaire. Pour la plupart d’entre eux, la première réaction à toute contribution externe est : « Zut, du travail en plus ». Et c’est effectivement le cas.

Par conséquent, certains développeurs essayent d’éviter ce travail supplémentaire : ils déclarent ne pas vouloir de contributions, ou font en sorte que les contributeurs se sentent indésirables. Cela peut prendre de nombreuses formes, comme les ignorer ou être désagréable avec eux. Ainsi, les développeurs évitent d’avoir à traiter le surplus de travail qu’on leur met sur le dos.

C’est une des plus grandes erreurs que l’on peut commettre, et une vision fausse de l’Open Source. Si des gens vous apportent du travail supplémentaire, faites tout ce que vous pouvez pour bien les accueillir afin qu’ils continuent à travailler avec vous. Il s’agit peut-être de ceux qui prendront votre relève d’ici peu. Préparez votre future retraite.

Prenons le cas de mon ami Gordon, que j’ai vu démarrer en tant que contributeur sur Ceilometer en 2013. Il examinait très bien le code, si bien qu’il me donnait en fait davantage de travail : non seulement en détectant les anomalies dans mes contributions, mais aussi en me faisant vérifier les siennes. Au lieu de m’en prendre à lui pour qu’il arrête de me faire retravailler mon code et vérifier ses correctifs, j’ai proposé qu’on lui fasse davantage confiance en l’ajoutant officiellement à l’équipe des correcteurs sur un des projets.

Et s’ils ne font pas cette première contribution, ils ne feront pas non plus la seconde. En fait, ils n’en feront aucune ; et ces projets perdraient alors leurs futurs correcteurs.

2. Ne confier aux autres que le sale boulot

Lorsque de nouveaux contributeurs se présentent pour travailler sur un certain projet, leurs motivations peuvent être très diverses. Certains sont des utilisateurs, d’autres veulent simplement voir ce que c’est de contribuer. Ressentir le frisson de la participation, comme un simple exercice ou avec la volonté d’apprendre afin de contribuer en retour à l’écosystème qu’ils utilisent.

En général, les développeurs confient le sale boulot à ces personnes, c’est à dire des tâches sans intérêt, à faible valeur ajoutée, et qui n’auront sans doute aucun impact direct sur le projet.

Pour certains, ce n’est pas grave, pour d’autres, ça l’est. Certains seront vexés de se voir confier du travail sans grand intérêt, alors que d’autres seront heureux de le faire pourvu qu’on leur témoigne de la reconnaissance. Soyez sensible à cela, et félicitez ces personnes. C’est la seule manière de les garder dans le projet.

3. Mépriser les petites contributions

Quand le premier patch d’un nouveau contributeur est une correction d’orthographe, qu’en pensent les développeurs ? Qu’ils s’en fichent, que vous gâchez de leur temps précieux avec votre petite contribution. Et personne ne s’intéresse à la perfection grammaticale d’une documentation, n’est-ce pas ?

C’est faux. Voyez mes premières contributions à home-assistant et Postmodern : j’ai corrigé des fautes d’orthographe dans la documentation.

J’ai contribué au projet Org-mode pendant quelques années. Mon premier patch corrigeait simplement une chaîne de caractères du code. Ensuite, j’ai envoyé 56 patchs, corrigeant des bogues et ajoutant de nouvelles fonctionnalités élégantes, et j’ai aussi codé quelques extensions. À ce jour, je suis toujours seizième dans la liste des plus gros contributeurs d’Org-mode, qui en contient 390. Certainement pas ce qu’on appellerait un petit contributeur, donc. Je suis sûr que la communauté est bien contente de n’avoir pas méprisé ma première correction dans la documentation.

4. Mettre la barre trop haut pour les nouveaux arrivants.

Quand de nouveaux contributeurs arrivent, leurs connaissances du projet, de son contexte, et des technologies sont très variables. L’une des erreurs que les gens font le plus souvent consiste à demander aux nouveaux contributeurs des choses trop compliquées, dont ils ne pourront pas venir à bout. Cela leur fait peur (surtout les timides ou les introvertis) et ils risquent de disparaître, se croyant trop stupides pour aider.

Avant de faire le moindre commentaire, vous ne devriez avoir strictement aucun a priori sur leur niveau. Cela permet d’éviter ce genre de situations. Il faut également mettre beaucoup de délicatesse quand vous estimez les compétences des nouveaux, car certains pourraient se vexer si vous les sous-estimez trop.

Quand son niveau est bien estimé (un petit nombre d’échanges devrait suffire), vous devez former votre contributeur en ne le guidant ni trop ni trop peu, afin qu’il puisse s’épanouir. Il faut du temps et de l’expérience pour y parvenir, et vous allez probablement perdre certains contributeurs avant de bien maîtriser ce processus, mais c’est un chemin que tous ceux qui gèrent des projets doivent suivre.

Façonner ainsi les nouveaux arrivants est au cœur de la gestion de vos contributeurs, et ce quel que soit votre projet. Et je suis quasiment sûr que cela s’applique à tout projet, même en dehors du logiciel libre.

5. Exiger des gens qu’ils fassent des sacrifices sur le plan personnel

C’est un point qui dépend beaucoup du projet et du contexte, mais il est très important. Dans le logiciel libre, où la plupart des gens vont contribuer par bonne volonté et parfois sur leur temps libre, vous ne devez surtout pas exiger d’eux qu’ils fassent des sacrifices personnels importants. Ça ne passera pas.

L’une des pires manières de faire cette erreur est de fixer un rendez-vous à l’autre bout du monde pour discuter du projet. Cela place les contributeurs qui vivent loin dans une situation injuste, car ils ne peuvent pas forcément quitter leur famille pour la semaine, prendre l’avion ou un autre moyen de transport, louer une chambre d’hôtel… Ce n’est pas bon : tout devrait être mis en œuvre pour que les contributeurs se sentent partie prenante du projet et intégrés à la communauté, sans que l’on exige cela de leur part. Entendons-nous bien, cela ne veut pas dire qu’il faut s’interdire toute rencontre ou activité sociale, au contraire. Pensez simplement à n’exclure personne lorsque vous discutez d’un projet.

Il en va de même pour les moyens de communication susceptibles de compliquer la vie des participants : se retrouver sur IRC (il est difficile pour certaines personnes de réserver une heure, surtout lorsqu’il faut tenir compte des différents fuseaux horaires), faire une visioconférence (en particulier quand on n’utilise pas de logiciel libre et gratuit), etc.

En gros, tout ce qui impose de se synchroniser en temps réel avec l’avancement du projet est contraignant pour certains contributeurs.

C’est pourquoi le meilleur moyen de communiquer reste le courriel, mais tous les outils de communication asynchrones (pisteurs de bogues, etc.) feront l’affaire dans la mesure où ils permettent à chacun de travailler à son rythme et à l’heure qui lui convient.

6. Ne pas avoir de code de conduite

À une époque où de plus en plus de communautés s’ouvrent à un public plus large que celui auquel elles étaient habituées (ce qui est fantastique), les codes de conduite semblent être un sujet à la mode, mais aussi délicat.

En réalité, toutes les communautés ont un code de conduite, qu’il soit inscrit noir sur blanc ou suivi inconsciemment par chacun. Sa forme dépend de la taille et de la culture de la communauté.

Cependant, en fonction de la taille de votre communauté et de la façon dont ce code s’applique, vous auriez peut-être intérêt à l’écrire dans un document, comme l’a par exemple fait Debian.

Ce n’est pas parce que vous aurez rédigé un code de conduite que tous les membres de votre communauté vont soudain se transformer en adorables Bisounours le suivant à la lettre, mais il fournit des règles que vous pouvez citer en cas de besoin. Il peut être utile de le transmettre à certains pour leur faire comprendre que leur comportement ne convient pas, et cela peut aider si une exclusion devient nécessaire, même s’il ne sert que rarement à cela, puisqu’en général personne ne veut aller aussi loin.

Je pense qu’on peut très bien se passer d’un tel document sur de petits projets. Mais vous devez garder à l’esprit qu’un code de conduite implicite découlera de votre comportement. La manière dont vos membres les plus influents communiqueront avec les autres installera l’ambiance à travers tout le réseau. Ne sous-estimez pas cela.

Quand nous avons commencé le projet Ceilometer, nous avons suivi le code de conduite du projet OpenStack avant même qu’il ait été écrit, et probablement avons-nous même placé la barre un peu plus haut. En étant agréables, accueillants et ouverts d’esprit, nous avons réussi à obtenir une certaine mixité, avec plus de 25% de femmes dans notre équipe permanente — bien au dessus de la moyenne actuelle d’OpenStack et de la plupart des projets de logiciel libre !

7. Mettre les non-anglophones à l’écart

Il est important d’être conscient que la grande majorité des projets de logiciel libre utilisent l’anglais en tant que langue de communication principale. C’est logique. C’est une langue répandue, et qui semble remplir ce rôle correctement.

Mais une grande partie des codeurs n’ont pas l’anglais pour langue maternelle. Beaucoup ne le parlent pas couramment. Cela signifie que le rythme auquel ils peuvent converser peut-être très lent, ce qui peut en frustrer certains, notamment ceux qui sont nés en terre anglophone.

On peut observer ce phénomène dans les rencontres de codeurs, lors de conférences par exemple. Quand les gens débattent, il peut être très difficile pour certains d’expliquer leurs pensées en anglais et de communiquer à un rythme correct, ce qui ralentit la conversation et la transmission des idées. La pire chose qu’un anglophone puisse faire dans ce cas est de leur couper la parole, ou de les ignorer, pour la seule raison qu’ils ne parlent pas assez vite. Je comprends que cela puisse être frustrant, mais le problème n’est pas la façon de parler des non-anglophones mais les outils de communication utilisés qui ne mettent pas tout le monde au même niveau en privilégiant des conversations orales.

La même chose s’applique, à un moindre degré, aux rencontres sur IRC, qui sont relativement synchrones. Les médias complètement asynchrones ne pâtissent pas de ce défaut, et c’est pourquoi ils faudrait, à mon avis, les privilégier.

8. Pas de vision, aucune délégation des tâches

C’est une autre grosse erreur de gestion si le responsable ne parvient pas à gérer la croissance du projet alors que des gens sont disponibles et prêts à aider.

Évidemment, lorsque le flux des contributeurs commence à grossir, ajoutant de nouvelles fonctionnalités, demandant des retours et des instructions à suivre, certains responsables se retrouvent la tête sous l’eau et ne savent pas comment répondre. Ce qui a pour conséquences de frustrer les contributeurs, qui vont simplement partir.

Il est important d’avoir une vision de votre projet et de la communiquer. Dites clairement à vos contributeurs ce que vous voulez, et ne voulez pas, dans votre projet. Exprimer ces informations de manière claire (et non-agressive !) permet de minimiser les frictions entre vos contributeurs. Ils vont vite savoir s’ils veulent rejoindre ou non votre navire et quoi en attendre. Donc, soyez un bon capitaine.

S’ils choisissent de travailler avec vous et de contribuer, vous devez rapidement commencer à croire en eux et à leur déléguer certaines de vos responsabilités. Cela peut être n’importe quelle tâche que vous faites d’habitude vous-même : vérifier les patchs de certains sous-systèmes, traquer les bogues, écrire la documentation… Laissez les gens s’approprier entièrement une partie du projet car ils se sentiront responsables et ils y mettront autant de soin que vous. Faire le contraire en voulant tout contrôler vous-même est la meilleure façon de vous retrouver seul avec votre logiciel open source.

Aucun projet ne va gagner en taille et en popularité de cette manière.

En 2009, quand Uli Schlachter a envoyé son premier patch à awesome, cela m’a donné plus de travail. J’ai du vérifier son patch, et j’étais déjà bien occupé pour sortir la nouvelle version d’awesome sur mon temps libre en dehors de mon travail ! Le travail d’Uli n’était pas parfait, et j’ai eu à gérer les bogues moi-même. Plus de travail. Alors qu’ai-je fait ? Quelques minutes plus tard, je lui ai répondu en lui envoyant un plan de ce qu’il devait faire et de ce que je pensais de son travail.

En retour, Uli envoya d’autres patchs et améliora le projet. Savez-vous ce que fait Uli aujourd’hui ? Il est responsable du gestionnaire des fenêtres awesome à ma place depuis 2010. J’ai réussi à transmettre ma vision, déléguer, puis à quitter le projet en le laissant dans de bonnes mains !

9. Ignorer certains types de contributions

Les gens contribuent de différentes manières, et pas toujours en codant. Il y a beaucoup de choses autour d’un projet de logiciel libre : la documentation, le tri de bogues, le support, la gestion de l’expérience utilisateur, la communication, les traductions…

Par exemple, il a fallu du temps pour que Debian songe à donner le statut de Développeur Debian à leurs traducteurs. OpenStack prend la même direction en essayant de reconnaître les contributions autres que techniques.

Dès lors que votre projet commence à récompenser certaines personnes et à créer différents statuts dans la communauté, vous devez faire très attention à n’oublier personne, car c’est le meilleur moyen de perdre des contributeurs en chemin.

10. Oublier d’être reconnaissant

Cette liste est le fruit de nombreuses années de bidouillages open source et de contributions à des logiciels libres. L’expérience et le ressenti de chacun sont différents, et les mauvaises pratiques peuvent prendre différentes formes : si vous connaissez ou si vous avez vous-même rencontré d’autres obstacles dans vos contributions à des projets open-source, n’hésitez pas à compléter la liste dans les commentaires. C’est une forme de contribution.

Lorsque l’on veut créer sa première page web, on se heurte très vite à la problématique de l’apprentissage du code. Si l’on n’est pas développeur, on cherchera donc à avoir une solution permettant de créer sa première page via des menus et des clics au sein d’une interface graphique. Les plus anciens d’entre nous se rappelleront feu Frontpage, la solution propriétaire de Microsoft incluse dans Office dans les années 2000. Les libristes eux se rappelleront Nvu… Ces solutions visuelles sont souvent maladroites et limitées, mais voici le logiciel en ligne Silex, qui vous permettra de vous initier au web design mais aussi d’aller jusqu’au code CSS quand vous aurez progressé, grâce à l’éditeur avec visualisation instantanée.

À savoir : Silex est issu du monde associatif, Silex Labs est une association à but non lucratif, qui organise régulièrement des ateliers sur des langages et des logiciels libres, luttant contre la fracture numérique. L’association maintient le logiciel libre Silex pour permettre à ses membres d’initier des novices au web design, afin qu’ils puissent réaliser des sites internet sans savoir coder et aussi pour qu’ils s’initient aux langages du Web (HTML5, CSS3, Javascript). Des vidéos et des tutoriels sont disponibles gratuitement sur le blog de l’association et sur la chaîne YouTube de l’association.

À l’occasion de leur campagne de financement participatif, nous avons interviewé le président de l’association, Alex, pour en savoir un peu plus sur Silex Labs l’association, sur Silex le logiciel et ses évolutions à venir.

Q : Bonjour Alex, peux-tu nous présenter l’association Silex Labs?

Silex Labs est née en 2009 en banlieue parisienne, nous étions un groupe informel d’indépendants, professionnels du web. Nous avions créé Silex ensemble pour nos activités de designer, développeurs et chefs de projet. L’outil s’est avéré tellement efficace que nous avons décidé d’en faire quelque chose d’utile pour d’autres professionnels, mais aussi pour la communauté. Nous avons commencé par organiser des ateliers pour former les gens à Silex et au fur et à mesure une communauté de professionnels s’est formée, ça nous a donné envie d’organiser davantage d’ateliers pour initier le plus grand nombre aux logiciels et langages libres.

Q : Le tour du Web en 50 ateliers, c’est quoi tout ça ?

C’est un programme de 50 ateliers organisés dans toute l’île de France que nous avons mis en place en 2015, pour permettre à tous de comprendre ce que sont les métiers et les technologies du web, les communautés qui font un web libre, et découvrir les nombreuses opportunités professionnelles qui existent dans ce domaine. Nous souhaitons donner des perspectives professionnelles à des personnes qui pensent que c’est un secteur inaccessible. Le réseau et la collaboration sont au centre du programme, autant que le bien commun et la vie privée.

Q : Et sinon Silex, c’est quoi? En quoi ça consiste?

Silex c’est un logiciel libre, gratuit et accessible en ligne pour permettre au plus grand nombre de réaliser des sites internet en fonction des niveaux de chacun. Les débutants pourront réaliser leur site sans faire une ligne de code mais ceux qui connaissent déjà un peu de HTML de CSS ou de JS pourront aussi utiliser leurs connaissances pour améliorer le design ou l’interactivité de leur site.

Tu n’as qu’à aller sur silex.me et tu peux insérer, modifier, déplacer des textes, des images et des vidéos, tu crées des liens et BIM : tu as ton site !

C’est un bon outil pour faire un site vitrine, c’est-à-dire un site visuellement attractif, qui n’a pas un contenu énorme et changeant tous les jours. Tout est fait pour aider les gens à s’initier au web design mais ça peut aussi être un bon choix pour un pro qui veut un moyen efficace de créer puis de maintenir des sites pour des clients.

Bon c’est aussi un logiciel qui respecte ta vie privée, tes données et une communauté internationale qui grandit.

Q : C’est tout en logiciel libre?

Oui, la licence est GPL, les contributions sont les bienvenues et la gouvernance se fait en discutant sur Github et Gitlab

Toutes les contributions sont les bienvenues même si tu n’as jamais codé tu peux contribuer à ton niveau par exemple en faisant un rapport de bug, ou en proposant des templates quand tu auras utilisé un peu plus Silex !

Q : Donc la famille Dupuis-Morizeau va pouvoir créer son site web en ligne? Et le mettre où elle veut?

Eh oui mon bon Monsieur, on ne fait pas payer, on n’utilise pas vos données à votre insu, et en plus on vous laisse aller où vous voulez avec, vous restez propriétaire de vos données ! Un site fait avec Silex c’est une simple page HTML et quelques fichiers CSS et Javascript. Il suffit de le coller sur un hébergement et c’est en ligne. On peut aussi s’auto-héberger, utiliser un hébergement à la netlify (simple glissé / déposé de vos fichiers sur leur site pour mettre en ligne) ou encore faire appel à des gens sympas et militants comme les Indiehosters pour vous garantir un service rapide et toujours disponible.

Q : On approche des 8 ans des toutes premières lignes de code du logiciel. Comment le logiciel a-t-il évolué au cours du temps?

Beaucoup de choses ont changé depuis la première version qui était un logiciel qu’il fallait installer et qui était plus complexe à prendre en main et avec un code source beaucoup plus lourd et surtout basé sur des vieilles technos. Nous avons décidé pour cette nouvelle version d’utiliser des technos innovantes pour gagner en performance et surtout de simplifier au maximum l’interface pour permettre au plus grand nombre de réaliser son site internet et de laisser beaucoup de liberté aux utilisateurs pour décider d’utiliser les éditeurs de code ou non.

Q : Pourquoi lancer une campagne de Crowdfunding, à quoi va servir l’argent?

Un sondage récent a montré que les utilisateurs attendent un éditeur de version mobile (responsive), pour offrir une expérience personnalisée aux visiteurs sur téléphone ou tablette.

Ils attendent aussi et surtout plus de docs, plus de « templates » – des sites prêts à l’emploi pour ne pas démarrer d’une page vide. Il y en a déjà mais pas suffisamment.

L’éditeur de version mobile (responsive) est déjà en route et même si un peu d’argent nous permettrait d’accélérer le mouvement, c’est une certitude on y va ! Par contre les templates / sites prêts à l’emploi, il va nous falloir un budget pour nous payer les services de designers. Et la doc aussi, un budget nous permettra de mobiliser quelqu’un dessus à plein temps pour mettre en place les bases que la communauté maintiendra ensuite.

Une partie de la somme récoltée sera dédiée à la réalisation d’ateliers dans des banlieues parisiennes défavorisées pour accompagner des jeunes déscolarisés et des chômeurs à réaliser leurs sites internet CV avec Silex.

Q : Le mot de la fin?

Venez nous rencontrer aux apéros de l’asso chaque mois à Paris, dans un bar pour discuter ou dans une salle pour contribuer.

Merci à Alexandre d’avoir bien voulu se prêter au jeu de l’interview et souhaitons à leur campagne de financement participatif de réussir.

Pour aller plus loin :

• Faire son site web avec Silex.me
• Le site de l’association SilexLabs
• Participer au financement collaboratif

Dans le mode du logiciel libre, et contrairement à ce que le nom laisse suggérer, ce n’est pas le logiciel qui est libre, mais bien l’utilisateur du logiciel.

Le logiciel propriétaire, c’est-à-dire l’opposé du logiciel libre, est alors parfois appelé « logiciel privateur », car il prive l’utilisateur de certaines libertés fondamentales (étudier, exécuter, etc. le code source du programme).

Rebecca Wexler, étudiante dans l’école de droit de Yale (Yale Law School) nous montre ici qu’en plus ne nous priver de ces libertés qui peuvent parfois sembler bien futiles pour tout un chacun, ces logiciels peuvent compromettre le système judiciaire et nous priver ainsi de nos libertés fondamentales.

Condamnés par le code

par Rebecca Wexler

Source : Convicted by code (Slate)

Traduction :Vincent,  McGregor, roptat, oS,Diane, CLC, touriste, teromene, Piup, Obny et anonymes.

Le code « secret » est partout : dans les ascenseurs, les avions, les appareils médicaux.

En refusant de publier le code source de leurs logiciels, les entreprises rendent impossible son inspection par des tiers, et ce même si le code a un impact énorme sur la société et la politique. Verrouiller l’accès au code empêche de connaître les failles de sécurité qui peuvent nous rendre vulnérables au piratage et à la fuite de données. Cela peut menacer notre vie privée en accumulant de l’information sur nous à notre insu. Cela peut interférer avec le principe d’égalité devant la loi si le gouvernement s’en sert pour vérifier notre éligibilité à une allocation, ou nous inscrire sur une liste d’interdiction de vol. De plus, le code gardé secret permet le trucage des données et occulte les erreurs, comme dans l’affaire Volkswagen : l’entreprise a récemment avoué avoir utilisé un logiciel caché pour truquer les tests d’émission menés sur 11 millions de voitures, qui rejetaient l’équivalent de 40 fois la limite légale.

Mais aussi choquante que la fraude de Volkswagen puisse être, elle ne fait qu’en annoncer bien d’autres du même genre. Il est temps de s’occuper de l’un des problèmes de transparence technologique les plus urgents et les plus négligés : les programmes secrets dans le système judiciaire. Aujourd’hui, des logiciels fermés, propriétaires, peuvent vous envoyer en prison et même dans le couloir de la mort. Et dans la plupart des juridictions des États-Unis, vous n’avez pourtant pas le droit de les inspecter. Pour faire court, les procureurs ont le même problème que Volkswagen.

Prenons la Californie. Martell Chubbs est actuellement accusé de meurtre pour des faits remontant à 1977, dans lesquels la seule preuve contre lui est une analyse ADN effectuée par un logiciel propriétaire. Chubbs, qui dirigeait une petite entreprise de dépannage à domicile à l’époque de son arrestation, a demandé à inspecter le code source du logiciel afin de pouvoir contester la précision de ses résultats. Il cherchait à déterminer si le code implémente correctement les procédures scientifiques établies pour l’analyse ADN et s’il fonctionne comme son fabriquant le prétend. Mais ce dernier a affirmé que l’avocat de la défense pourrait voler ou dupliquer le code et causer des pertes financières à l’entreprise. Le tribunal a rejeté la requête de Chubbs, lui autorisant l’examen du rapport de l’expert de l’état, mais pas l’outil qu’il a utilisé. Des tribunaux de Pennsylvanie, Caroline du Nord, Floride et d’autres ont rendu des décisions similaires.

Nous devons faire confiance aux nouvelles technologies pour nous aider à trouver et condamner les criminels, mais aussi pour disculper les innocents. Les logiciels propriétaires interfèrent avec cette confiance dans de plus en plus d’outils d’investigation, des tests ADN aux logiciels de reconnaissance faciale et aux algorithmes qui indiquent à la police où chercher les futurs crimes. Inspecter les logiciels n’est cependant pas seulement bon pour les accusés : divulguer le code à des experts de la défense a permis à la Cour suprême du New Jersey de confirmer la fiabilité scientifique d’un éthylotest.

Non seulement il est injuste de court-circuiter la possibilité pour la défense de contre-expertiser les preuves médico-légales, mais cela ouvre la voie à de mauvaises pratiques scientifiques. Les experts décrivent la contre-expertise comme « le meilleur instrument légal jamais inventé pour la recherche de la vérité ». Mais des révélations récentes ont révélé une épidémie de mauvaises pratiques scientifiques qui sapent la justice criminelle. Des études ont contesté la validité scientifique des recherche de similitudes sur les marques de morsure, les cheveux et les fibres, des diagnostics du syndrome du bébé secoué, de techniques balistiques, des séances d’identifications olfactives par des chiens, des preuves issues de l’interprétation de taches de sang, et des correspondances d’empreintes digitales. Le Massachusetts se démène pour gérer les retombées des falsifications de résultats par un technicien d’un laboratoire criminel qui a contaminé les preuves de dizaines de milliers d’affaires criminelles. Et le Projet Innocence rapporte que de mauvaises analyses légales ont contribué à l’incrimination injustifiée de 47% des prévenus. L’Académie Nationale des Sciences (National Academy of Sciences) accuse entre autres le manque de processus d’évaluation par les pairs dans les disciplines liées à l’analyse légale d’être responsable de cette crise.

Les logiciels ne sont pas non plus infaillibles. On a découvert des erreurs de programmation qui changent les ratios de probabilité des tests ADN d’un facteur 10, amenant des procureurs australiens à remplacer 24 avis d’experts dans des affaires criminelles. Quand les experts de la défense ont identifié une erreur dans le logiciel de l’éthylotest, la Cour suprême du Minnesota a invalidé le test en tant que preuve pour tous les futurs jugements. Trois des plus hautes cours de l’état (américain, NdT) ont encouragé à accepter davantage de preuves de failles dans des programmes, de manière à ce que les accusés puissent mettre en cause la crédibilité de futurs tests.

La contre-expertise peut aider à protéger contre les erreurs – et même les fraudes – dans la science et la technique de l’analyse légale. Mais pour que cet appareil judiciaire puisse fonctionner, l’accusé doit connaître les fondements des accusations de l’état. En effet, lorsque le juge fédéral de Manhattan, Jed S. Rakoff, a démissionné en signe de protestation contre la commission sur les sciences légales du président Obama, il a prévenu que si l’accusé n’a pas accès à toutes les informations pour effectuer une contre-expertise, alors le témoignage d’un expert judiciaire n’est « rien d’autre qu’un procès par embuscade » (c.-à-d. sans accès préalable aux éléments  de preuve, NdT).

La mise en garde de Rakoff est particulièrement pertinente pour les logiciels des outils d’analyse légale. Puisque éliminer les erreurs d’un code est très difficile, les experts ont adopté l’ouverture à l’analyse publique comme le moyen le plus sûr de garder un logiciel sécurisé. De manière identique, demander au gouvernement d’utiliser exclusivement des outils d’analyse légale ouverts permettrait leur contre-expertise participative. Les fabricants d’outils d’analyse légale, qui vendent exclusivement aux laboratoires d’expertise criminelle du gouvernement, peuvent manquer de motivations pour conduire les tests de qualité minutieux requis.

Pour en être certains, les régulateurs du gouvernement conduisent actuellement des tests de validation pour au moins quelques outils d’analyse légale numériques. Mais même les régulateurs peuvent être incapables d’auditer le code des appareils qu’ils testent, se contentant à la place d’évaluer comment ces technologies se comportent dans un environnement contrôlé en laboratoire. De tels tests « en boite noire » n’ont pas été suffisants à l’Agence de Protection de l’Environnement (Environmental Protection Agency) pour repérer la fraude de Volkswagen et ce ne sera pas non plus assez pour garantir la qualité des technologies numériques d’analyse légale.

La Cour suprême a depuis longtemps reconnu que rendre les procès transparents aide à s’assurer de la confiance du public dans leur équité et leur légitimité. Le secret de ce qu’il y a sous le capot des appareils d’informatique légale jette un doute sur ce processus. Les accusés qui risquent l’incarcération ou la peine de mort devraient avoir le droit d’inspecter les codes secrets des appareils utilisés pour les condamner.

Warning : cet article parle de forge logicielle qui sert à développer collaborativement du code. Il est donc un peu velu et technique, mais il fera plaisir aux plus « barbu-e-s » d’entre vous !

Préviousselaid, chez Framasoft : nous avions besoin d’une forge logicielle comme outil interne à l’asso… parce que même si nous ne développons pas (ou exceptionnellement) de logiciel libre ; les mettre en avant, les améliorer (parfois), les promouvoir et ouvrir des services au monde, ben ça demande de créer, maintenir, échanger et améliorer du code !

Nous nous étions donc installé Gitlab à la main, sur un coin de serveur, juste pour nous…  Étant les seuls utilisateurs, on s’est dit que ce ne serait pas grave s’il n’était pas toujours à jour, à traquer la dernière version… (oui : nous sommes moins exigeants sur nos outils internes que pour les services que nous ouvrons au grand public ^^).

Franchement, merci Google !

Merci, parce qu’à chaque fois que vous prenez des décisions unilatérales aux dépens de vos utilisateurs-produits, vous nous offrez l’occasion de prouver que le Libre offre des alternatives bien plus respectueuses des personnes qui vous ont confié leur vie numérique (et leur code).

Le jour où nous avons appris que Google Code fermait ses portes, nous avons donc décidé d’ouvrir les nôtres. Cela nous a aussi permis de sensibiliser au fait que, dans le mode des codeurs et développeuses, GitHub est devenu un point central et monopolistique assez inquiétant.

Forcément, l’ouverture à tous de notre git et les nouvelles fonctionnalités des nouvelles versions de Gitlab (une nouvelle version tous les 22 du mois) nous ont incités à mettre à jour plus régulièrement, ce qui prend plusieurs heures à chaque fois… et plusieurs fois par mois, car des versions correctives sont régulièrement publiées.

Améliorer le Framagit… une priorité

Ceci, ajouté à l’utilisation grandissante de notre forge qui allait bientôt poser des problèmes de taille de disques, nous a amenés à migrer (le 17 mars dernier) notre Gitlab vers une machine avec plus de disque et surtout avec une installation utilisant les paquets dits « omnibus ».

Ces paquets omnibus nous ont permis d’installer Gitlab à l’aide d’un simple apt-get install gitlab-ce plutôt que de suivre la longue procédure d’installation manuelle. Non seulement l’installation est simplifiée, mais — et c’est surtout là la plus-value que nous en attendions — mettre à jour Gitlab devient tout aussi simple avec une seule commande apt-get dist-upgrade.

Résultat : notre Gitlab suit scrupuleusement la publication des nouvelles versions, avec leur lot de nouvelles fonctionnalités !

Pour fêter cela, nous avons étrenné un nouveau nom de domaine… inspiré par vous ! Avouons-le, «Git point Framasoft point orrrrrrrgueh », ça accroche un peu en bouche. De partout, nous avons entendu parler du « Framagit » : alors tant qu’à faire, autant l’appeler comme vous le faites déjà. Bien entendu, il n’est nul besoin de modifier vos URL, elles restent valides… mais la nouvelle est à votre disposition !

Et si on ajoutait de l’intégration continue ?

Derrière ce terme barbare se cache une fonctionnalité très pratique : on crée une « recette » qui sera exécutée dans une machine virtuelle à chaque push. Cela peut par exemple permettre de lancer une suite de tests pour vérifier que l’on n’a rien cassé. 🙂

Pour utiliser cette fonctionnalité, il faut disposer de ce que l’on appelle un runner, c’est à dire un logiciel qui va récupérer la recette et l’exécuter. Il est possible d’installer un runner sur n’importe quel ordinateur, même votre ordinateur de bureau.

Pour ceux qui ne souhaitent pas gérer leur runner eux-mêmes, Framasoft met à disposition deux runners partagés entre tous les utilisateurs de Framagit, que vous pouvez utiliser comme bon vous semble. Notez toutefois que Gitlab indique que quiconque utilise un runner partagé peut accéder aux informations des projets utilisant ce runner : il vaut mieux monter votre propre runner pour vos projets sensibles.

De plus, en utilisant les runners partagés de Framasoft, il est possible que votre projet soit mis en file d’attente, en attendant que les recettes précédentes aient fini de s’exécuter… à vous de voir !

Vous voulez des pages Gitlab ? Nous aussi !

Github permet à tout un chacun d’héberger un site statique. Gitlab propose une fonctionnalité similaire mais hélas, uniquement dans sa version entreprise… Nous utilisons pour notre part la version communautaire qui est la version libre de Gitlab… donc sans les pages Gitlab.

Nous avons donc ouvert un ticket pour demander que cette fonctionnalité soit incluse dans la version communautaire. Si vous aussi vous aimeriez voir cela arriver, aidez-nous tout simplement en votant sur https://gitlab.com/gitlab-org/gitlab-ce/issues/14605.

En attendant, profitez d’une forge logicielle à jour et libre sur Framagit.org !

Comme nous le disions dans un article précurseur de notre projet de Degooglisation d’Internet : « nous n’avons pas peur, nous ne sommes pas résignés, et nous avons nous aussi une vision à long terme pour changer le monde. »

Libérer votre porte d’entrée au Web.

Parmi les plus importants outils qu’il faut libérer au plus vite : les moteurs de recherche. La dépendance du Web envers Google, fait de ce dernier un acteur monopolistique tout-puissant dont le moindre frémissement des algorithmes fait pâlir d’effroi les webmestres les plus endurcis, et peut faire perdre beaucoup d’argent à plus d’un acteur économique. L’autre aspect du moteur de la Firme réside dans la gigantesque base de données qu’elle contribue à alimenter, avec le consentement plus ou moins conscient des internautes eux-mêmes, en enregistrant nos recherches… c’est à dire aussi nos envies, nos souhaits, nos rêves.

Devrions-nous pour autant réinventer la roue ? Nul besoin de dénigrer le moteur de Google qui, qu’on le veuille ou non, constitue un outil formidablement efficace pour effectuer des recherches sur Internet. Si de surcroît on combine ces recherches avec celles d’autres moteurs, moins puissants mais plus spécialisés, le résultat s’avère apporter une plus-value objective.

Il n’est plus guère nécessaire aujourd’hui de vous rappeler quelle importance a la sécurité des données. Tel est pourtant bien le cœur du problème et d’autres que nous l’ont compris depuis longtemps. Ils proposent des solutions très confortables, certaines encore à l’état de projet. Ils mutualisent les puissances des moteurs de recherches dont celui de Google (on les appelle des métamoteurs) tout en garantissant la sécurité de nos identités, ou bien encore en passant par d’autres protocoles comme le P2P :

• Duck Duck Go,
• ixquick,
• Searx,
• Yacy,
• Nutch,
• Seeks.

Et Framasoft envoie : Framabee !

Le modèle de Dégooglisation d’Internet que nous proposons depuis octobre 2014 ne pouvait pas faire l’économie d’un moteur de recherche digne de ce nom. Nous avons donc choisi de lancer un métamoteur de recherche à la « sauce » Framasoft. Or, comme vous le savez, nos intentions ne se limitent pas à mettre en place des services.

Nous offrons un métamoteur de recherche aux visiteurs, au même titre que les autres services que nous proposons ou allons proposer, grâce à vos dons, dans le panier de services de notre projet Dégooglisons Internet. À terme, l’ensemble vise à faire la démonstration des alternatives aux services privateurs, de manière libre, éthique, décentralisée et solidaire.

Libre

Nous avons choisi d’utiliser Searx parce qu’avant tout, il s’agit d’un logiciel libre. Ensuite, pour son développement actif et, bien entendu, parce que les résultats retournés sont tout aussi pertinents, voire plus que ceux des moteurs de recherche classiques (bien entendu, puisqu’il vous propose un mix de tous les résultats).

Seeks est un vrai moteur de recherche qui va indexer le web et les différents nœuds communiquent en peer-to-peer. C’est quand même mieux, non ? Eh bien, il a fallu faire un choix, et si nous pouvons installer et customiser Searx (qui est écrit en Python), modifier Seeks qui, lui, est en C++… disons que la tâche est plus ardue. Framasoft n’est pas une association de développeurs (loin s’en faut) et nos bénévoles sont déjà bien surchargés, sans leur demander d’apprendre un nouveau langage. 😛

De plus Seeks n’a plus l’air en développement actif (le dernier commit date de plus de 6 mois), alors que son site indique qu’il s’agit d’une early release, c’est à dire un logiciel pas forcément tout à fait au point.

Éthique

Comme nous l’annonçons dans notre charte : nous ne vous suivons pas, nous ne vous traquons pas, et nous n’avons que faire de vos données personnelles, si ce n’est de vous aider à les protéger !

Décentralisé

Chacun est libre d’installer sa propre instance de Searx sur son propre serveur : vous ne dépendez nullement de Framasoft pour utiliser Searx. Vous pouvez même choisir votre instance préférée parmi toutes celles déjà ouvertes au public. 🙂

Solidaire

Nous voulons aussi montrer qu’il est possible d’installer un métamoteur sur son propre serveur, pour le compte de votre asso, de vos voisins, de votre famille… La facilité (relative) de son installation vous sera très prochainement expliquée sur Framacloud.

Les capacités de Searx :

• différentes catégories de recherche ;
• export des recherches : en json, pour en faire ce que vous voulez, en csv, pour l’utiliser dans un tableur et même sous forme de flux RSS pour surveiller les résultats de votre recherche ;
• configuration : choisir un autre thème, utiliser une autre catégorie de recherche par défaut, (dés)activer des moteurs de recherche… Searx est configurable à loisir ! (les préférences sont enregistrées dans un cookie) ;
• réponses rapides : par l’usage de l’API de Duckduckgo, vous aurez des encarts, des réponses rapides de ce moteur ;
• intégration à votre navigateur : utilisez Searx directement depuis la barre de recherche de votre navigateur préféré.

Et Searx n’est pas Google…

Jouons-la franc-jeu : tester Framabee, ce n’est pas nécessairement l’adopter !

En effet, vous pourriez trouver que les résultats de Framabee sont moins pertinents que ceux de Google (mais plus que ceux de Bing!, quand même 😛 ). Cela est dû à un phénomène très simple : la « bulle de filtre ». Ainsi, comme Google sait beaucoup sur vous (votre géolocalisation, votre âge, votre sexe, vos précédentes recherches, qui sont vos amis, etc), il peut vous proposer des résultats adaptés à votre profil. L’expert en sécurité informatique Bruce Schneier vient d’ailleurs de publier un ouvrage fort intéressant intitulé « Data and Goliath » qui traite largement de ce sujet. Vous pouvez aussi en apprendre plus sur le sujet en regardant la conférence TED donnée par Eli Pariser.

Autrement dit : Google vous enferme dans une « bulle » et traite vos recherches en fonction de ce qu’il pense que vous cherchez. Cela pose d’énormes problèmes culturels et éthiques.

• Comment découvrir de nouvelles choses si mon moteur m’enferme dans des territoires connus ?
• Un logiciel peut-il décider ce qui est bon pour un être humain, d’autant plus si on n’a pas la « recette » de ce logiciel ?
• Comment s’assurer que le filtre de Google n’agit pas comme une forme de censure ?
• Qui décide de ce qui doit apparaître ou pas dans les résultats, et comment s’assurer que quelqu’un n’a pas payé Google pour « remonter » un résultat ?
• etc.

Or, Framabee ne conserve — volontairement, c’est une fonctionnalité, pas un bug ! — aucun historique de vos recherches. Par conséquent, vous n’êtes dans aucune « bulle », sauf éventuellement celle de la langue des résultats, et encore cela peut se désactiver. Mais la contrepartie de cette liberté, c’est que vous pouvez perdre en confort (c’est à dire des résultats adaptés à ce que la machine pense que vous cherchez).

Par ailleurs, Framabee ne résout pas le problème de l’index des moteurs de recherche. Comme nous l’avons dit plus haut, Framabee est un méta-moteur, c’est-à-dire qu’il interroge (de façon anonyme) différents moteurs, et récupère puis vous affiche les résultats qui lui sont transmis. Cela pose donc la question de la taille des bases de données (ou « index ») des moteurs. Le site worldwidewebsize.com estime la « taille » du web indexé par Google (et donc du web visible par le moteur googlebot) à 45 milliards de pages web. Avoir un moteur capable d’indexer autant de pages, et une infrastructure en mesure d’exploiter cette base de données colossale de façon efficace coûte une fortune (plusieurs dizaines de millions d’euros au bas mot). Il est donc totalement impossible à Framasoft, association loi 1901, de proposer un moteur « 100% indépendant ». Wikipédia nous apprend d’ailleurs qu’il ne reste que très peu de « vrais » moteurs de recherche.

La solution à ce problème viendra — espérons-le — peut-être de logiciels libres en pair-à-pair comme Yacy. Mais les ressources de Yacy (communauté de quelques bénévoles) sont sans commune mesure avec celles de Google (55 000 employés et 66 milliards de dollars de chiffres d’affaires).

Mais Google est mon ami… non ? (non).

Ah ! Ces amis qui sous prétexte de t’aider à retrouver tes clés s’incrustent chez toi, fouillent dans ta garde-robe, tapent dans ton frigo et en profitent pour dépiauter ton courrier…

Framabee permet de virer du moteur de Google toutes les cochoncetés qui y ont été mises… par Google ! Et ce, tout en invitant d’autres moteurs de recherche à affiner les résultats. Pour reprendre l’analogie, c’est dire à notre pique-assiette : « tu ne rentreras chez moi qu’à mes conditions, avec respect… et accompagné d’autres potes. »

Framabee (ou votre propre instance de Searx en suivant notre tutoriel d’installation) est un outil de plus pour vous aider à reprendre les clés… de vos Internets. À vous de l’utiliser (et de le faire connaître). Rendez-vous dès maintenant sur :

• Framabee.org, l’abeille qui vous butine le web ;
• Trouvons.org, la version sérieuse pour le boulot ;
• et si vous avez un doute, vous n’avez qu’à demander à Tonton Roger 😉

Enfin, si vous souhaitez (comme nous : promis ça marche très bien !) utiliser Framabee comme moteur de recherche, il vous suffit, lorsque vous êtes sur la page d’accueil du moteur, de cliquer sur l’icône de préférences et de choisir « Ajouter Searx à votre moteur de recherche », puis de l’ajouter comme moteur par défaut.

Vous pouvez aussi suivre les instructions de l’animation ci-dessous.

PS : toute la FramaTeam tient à remercier Asciimoo et toute l’équipe de contribution de Searx pour leur boulot, Framasky pour avoir mené à bien le projet… Et surtout nos donateurs et donatrices qui, par leur soutien, nous donnent les moyens de continuer à Dégoogliser Internet. Voici une nouvelle étape de franchie grâce à vos dons.

Après un mois de janvier si mouvementé qu’il nous a donné du travail jusqu’en février, nous avons pu reprendre le cap fixé par notre (modeste) Plan de Libération du Monde : Dégoogliser Internet.

À notre sens, il faut reconquérir les Internets service après service, afin de proposer au plus grand nombre des applications Libres, Ethiques, Décentralisées et Solidaires. C’est ce que nous avons fait vendredi en ouvrant notre GitLab alors que Google code ferme ses portes. C’est ce que nous poursuivons aujourd’hui en vous proposant trois services simples, efficaces, mais qui (nous l’espérons) faciliteront la vie d’un grand nombre d’internautes dans le plus grand respect de leurs libertés.

Huit.re, la perle des raccourcisseurs d’URL

Enfin un service qui ne s’appelle pas frama-machin !! (bon, OK, on y accède aussi sur frama.link :p ). Huit.re vous permettra de raccourcir vos URLs en huit petits caractères… et sera donc le mollusque qui cache la forêt de caractères qui forme souvent une troooop loooooongue adreeeeessse weeeeb.

À l’instar de bit.ly ou de goo.gl, vous pourrez l’utiliser pour gazouiller sans craindre de perdre trop des précieux 140 caractères auxquels vous avez droit. Vous pourrez enfin transmettre une adresse web par sms ou téléphone sans y passer trois heures…

Mais à la différence de ces géants du web centralisé, huit.re est basé sur LSTU (Let’s Shorten That URL), un logiciel libre que les barbu-e-s de tout poil peuvent s’empresser d’étudier, améliorer, bidouiller… Donc non seulement on sait ce qui se trouve derrière, mais en plus il est placé sur les serveurs de Framasoft. Et l’on vous rappelle qu’on s’est engagés sur une Charte respectueuse de vos libertés et vos données, ainsi que sur des conditions générales d’utilisations claires et précises.

Bref : on a enfin de quoi faire taire Pouhiou quand il clame à qui veut l’entendre que : « Les huîtres, c’est le mal » ! [1]

Framapic, le lutin qui héberge vos images les yeux fermés

Basé sur le logiciel libre LUTIm (Let’s Upload This Image), un projet perso du bouillant framasoftien Luc Didry, Framapic est un moyen simple et sécurisé de partager et publier vos images en ligne. Attention, il ne s’agit pas d’un gestionnaire de collection de photos à la Picasa… Simplement d’un hébergement d’images comme Imgur ou hostingpic, qui supporte tous les formats (même le GIF !)

Sauf qu’en plus d’être un logiciel libre, LUTIm est un logiciel qui offre bien des avantages :

• Possibilité d’autodestruction de l’image après la première vue (avec le petit lien « corbeille ») ;
• Possibilité d’effacer l’image de nos serveurs au bout d’un jour, une semaine, un mois, un an… (au choix) ;
• Intégration facilitée (et jolie) à Twitter, Facebook, etc. pour vos images (et même vos GIFs !) ;
• Téléchargement facilité (par une URL spécifique) ;
• Code ouvert et disponible sur notre GitLab pour tous ceux qui veulent y contribuer voire se l’installer sur leur serveur. ;
• Chiffrement des images sur nos serveurs.

Et le chiffrement, ça change tout. Cela signifie que nous n’avons pas la possibilité de voir vos images (pas sans la clé que vous détenez dans votre URL, et pour la récupérer il faudrait qu’on active les journaux (logs) du reverse proxy qui est devant Framapic, et ça c’est pas dans notre charte…)

Cela signifie que vos images vous appartiennent, et qu’on n’a pas à mettre nos nez dedans. Attention ! Notez bien les URL des images envoyées sur Framapic : sans elles et la clé de chiffrement qui y est, vous ne pourrez plus y accéder.

Framabin, pour partager vos secrets en mode mission impossible

Nous avons pimpé le très célèbre (et très libre) Zérobin de SebSauvage afin de le rendre assez beau pour que votre grand-père vous partage en toute sérénité le secret si bien gardé de son coin à champignons.

Framabin est un rêve de gosse nourri aux Missions Impossibles, Alias et autres James Bond : partagez un message qui s’autodétruira dès le premier accès. Ou au bout de 5, 10 minutes. Ou d’un jour, une semaine, un mois, un an…

Bien entendu, le message est chiffré, ce qui fait que nous ne pouvons pas (à aucun moment) consulter le code de la carte bleue de votre maman quand elle le partagera avec vous sur Framabin pour que vous lui achetiez un superbe T-Shirt sur EnVenteLibre…

Et le top, c’est que vous pouvez carrément utiliser Framabin comme un lieu de conversations secrètes, où chaque personne possédant le lien peut commenter ce qu’a écrit l’autre. Cela sert bien entendu pour ce bout de code qui va révolutionner les Interwebs (même qu’il y a de la coloration syntaxique), mais aussi pour bien comprendre et discuter le secret du tajine aux olives que votre cousin garde jalousement.

Libérez vous ! (même de Framasoft :p )

Tous ces services sont là pour vous (et aussi pour les Dupuis-Morizeau notre fameuse famille-témoin résidant en Normandie). Mais ils sont aussi et surtout là pour démontrer que lorsqu’on veut faire un Web et des applications respectueuses de… de nous, en fait : ben c’est possible. Le chiffrement, le logiciel libre et la confiance en l’hébergeur du service sont des piliers indispensables à ce respect.

Mais plus que tout, nous ne voulons pas devenir le « Google du libre ». C’est bien pour cela que vous retrouverez, sur notre blog Framacloud, tous les tutoriels nécessaires pour « cultiver votre jardin », c’est-à-dire pour installer vous-même ces applications sur votre propre serveur (ou celui de votre famille, votre asso, votre collectivité, votre entreprise…)

• Installer LSTU
• Installer Lutim
• Installer Zérobin

C’est en se rendant indépendants, en s’apportant nos expériences les uns aux autres et en disséminant du Libre un peu partout que nous arriverons ensemble à vraiment Dégoogliser Internet.

À vous de partager, désormais.

[1] cf. #Smartarded, p. 172.

Aujourd’hui, c’est la Saint Valentin, et l’occasion de déclarer son amour des logiciels libres !

Framasoft vous a déjà proposé son adaptation délirante de poèmes pour l’occasion, et voici une petite bande-dessinée qui synthétise l’événement :

Cette bande-dessinée est extraite du nouveau blog Grise Bouille hébergé par Framasoft.

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