1) Tu ne consultes pas une page Internet, tu la copies

Un site web, c’est pas une espèce de journal qu’on aurait mis dans le pays magique d’internet pour que ton navigateur aille le consulter comme tu consulterais le quotidien de ton jour de naissance à la médiathèque du coin.

Pour voir une page web, ton navigateur la copie sur ton ordi. Les textes, les images, les sons : tout ce que tu vois ou entends sur ton écran a été copié sur ton ordinateur (vilain pirate !)

Un ordinateur est un photocopieur dont la trieuse serait une méga fourmilière qui peut faire plein de trucs. La bonne nouvelle, c’est que copier permet de multiplier, que ça ne vole rien à personne, parce que si je te copie un fichier tu l’as toujours.

• La BD « Les Ordinateurs sont des cons » sur GriseBouille
• La chanson « Copier n’est pas voler » sur YouTube

2) Mon navigateur web ne cuisine pas la même page web que le tien.

Sérieux, imagine qu’une page web, c’est une recette de cuisine :

Mettez un titre en gros, en gris et en gras.

Réduisez l’image afin qu’elle fasse un quart de la colonne d’affichage, réservez.

Placez le texte, agrémenté d’une jolie police, aligné à gauche, puis l’image à droite.

Servez chaud.

Le navigateur web (Firefox, Chrome, Safari, Internet Explorer…), c’est le cuisinier. Il va télécharger les ingrédients, et suivre la recette. T’as déjà vu quand on donne la même recette avec les mêmes ingrédients à 4 cuisiniers différents ? Ben ouais, c’est comme dans Top Chef, ça fait 4 plats qui sont pas vraiment pareils.

Surtout quand les assiettes ne sont pas de la même taille (genre l’écran de ton téléphone et celui de ton ordi…) et que pour cuire l’un utilise le four et l’autre un micro-ondes (je te laisse trouver une correspondance métaphorique dans ton esprit, tu peux y arriver, je crois en toi :p !).

Bref : l’article que tu lis aura peu de chance d’avoir la même gueule pour toi et la personne à qui tu le feras passer 😉

• Préfère Firefox si t’as pas envie de filer tes données à Google-Chrome, Apple-Safari ou Microsoft-Edge
• Ou sinon Chromium c’est Chrome sans du Google dedans 😉

3) Le streaming n’existe pas

Nope. Le streaming, c’est du téléchargement qui s’efface au fur et à mesure. Parce qu’un ordinateur est une machine à copier.

Le streaming, c’est du téléchargement que tu ne peux (ou ne sais) pas récupérer, donc tu downloades une vidéo ou un son mais juste pour une seule fois, et si tu veux en profiter à nouveau, il faut encore les télécharger et donc encombrer les tuyaux d’internet.

Tu vois les précieux mégas du forfait data de ton téléphone qui te ruinent chaque mois ? Ce sont des textes, images sons, vidéos et informations qui viennent jusqu’à ton ordi (ordinateur ou ordiphone, hein, c’est pareil). La taille de ces mégas, c’est un peu les litres d’eau que tu récupères au robinet d’internet.

Regarder ou écouter deux fois le même truc en streaming, sur YouTube ou Soundcloud par exemple, c’est comme si tu prenais deux fois le même verre d’eau au robinet.

• Les meilleurs logiciels pour télécharger en pair-à-pair (et décongestionner les tuyaux d’internet)
• 30 sites de torrents aux contenus libres et légaux (en anglais)

4) Quand tu regardes une page web, elle te regarde aussi.

Mon livre ne me dit pas de le sortir du tiroir de la table de nuit. Il ne sait pas où je suis lorsque je le lis, quand je m’arrête, quand je saute des pages ni vers quel chapitre, quand je le quitte et si c’est pour aller lire un autre livre.

Sur Internet, les tuyaux vont dans les deux sens. Une page web sait déjà plein de choses sur toi juste lorsque tu cliques dessus et la vois s’afficher. Elle sait où tu te trouves, parce qu’elle connaît l’adresse de la box internet à laquelle tu t’es connecté. Elle sait combien de temps tu restes. Quand est-ce que tu cliques sur une autre page du même site. Quand et où tu t’en vas.

Netflix, par exemple, est une application web, donc un site web hyper complexe, genre QI d’intello plus plus plus. Netflix sait quel type de film tu préfères voir lors de tes soirées d’insomnie. À partir de quel épisode tu accroches vraiment à la saison d’une série. Ils doivent même pouvoir déterminer quand tu fais ta pause pipi !

Ouaip : Internet te regarde juste pour pouvoir fonctionner, et souvent plus. Ne t’y trompe pas : il prend des notes sur toi.

• Pour équiper ton cuisinier-navigateur d’outils contre l’espionnage publicitaire, suis le guide !
• Surfe anonyme avec le navigateur Tor

5) Pas besoin d’un compte Facebook/Google/etc pour qu’ils aient un dossier sur toi.

Si Internet peut te regarder, ceux qui y gagnent le plus d’argent ont les moyens d’en profiter (logique : ils peuvent se payer les meilleurs spécialistes !)

Tu vois le petit bouton « like » (ou « tweet » ou « +1 » ou…) sur tous les articles web que tu lis ? Ces petits boutons sont des espions, des trous de serrures. Ils donnent à Facebook (ou Twitter ou Google ou…) toutes les infos sur toi dont on parlait juste au dessus. Si tu n’as pas de compte, qu’ils n’ont pas ton nom, ils mettront cela sur l’adresse de ta machine. Le pire, c’est que cela fonctionne aussi avec des choses que tu vois moins (les polices d’écriture fournies par Google et très utilisées par les sites, les framework javascript, les vidéos YouTube incrustées sur un blog…)

Une immense majorité de sites utilisent aussi « Google Analytics » pour analyser tes comportements et mieux savoir quelles pages web marchent bien et comment. Mais du coup, ces infos ne sont pas données qu’à la personne qui a fait le site web : Google les récupère au passage. Là où ça devient marrant, c’est quand on se demande qui décide qu’un site marche « bien » ? C’est quoi ce « bien » ? C’est bien pour qui…?

Oui : avec le blog rank comme avec la YouTube money, Google décide souvent de comment nous devons créer nos contenus.

• Voici 98 choses que Facebook sait sur toi par Anguille sous Roche.
• Découvre les infos que Google a sur toi (compte Google nécessaire -_-…)

6) Un email est une carte postale

On a tendance à comparer les emails (et les SMS) à des lettres, le truc sous enveloppe. Sauf que non : c’est une carte postale. Tout le monde (la poste, le centre de tri, ceux qui gèrent le train ou l’avion, l’autre centre de tri, le facteur…), tous ces gens peuvent lire ton message. J’ai même des pros qui me disent que c’est carrément un poster affiché sur tous les murs de ces intermédiaires, puisque pour transiter par leurs ordis, ton email se… copie. Oui, même si c’est une photo de tes parties intimes…

Si tu veux une enveloppe, il faut chiffrer tes emails (ou tes sms).

Gamin, j’adorais déchiffrer les messages codés dans la page jeux du journal de Mickey. Y’avait une phrase faite d’étoiles, carrés, et autre symboles, et je devais deviner que l’étoile c’est la lettre A, le cœur la lettre B, etc. Lorsque j’avais trouvé toutes les correspondances c’était le sésame magique : j’avais trouvé la clé pour déchiffrer la phrase dans la mystérieuse bulle de Mickey.

Imagine la même chose version calculatrice boostée aux amphètes. C’est ça, le chiffrement. Une petit logiciel prend ton email/SMS, applique la clé des correspondances bizarres pour le chiffrer en un brouillard de symboles, et l’envoie à ton pote. Comme vos logiciels se sont déjà échangé les clés, ton pote peut le déchiffrer. Mais comme il est le seul à avoir la clé, lui seul peut le déchiffrer.

Ben ça, ça te fait une enveloppe en plomb que même le regard laser de Superman il peut pas passer au travers pour lire ta lettre.

• Comment chiffrer ses e-mails avec Open-PGP
• Comment chiffrer très simplement ses appels et SMS avec Signal

7) Le cloud, c’est l’ordinateur d’un autre.

Mettre sur le cloud ses fichiers (icloud), ses emails (gmail), ses outils (Office365)… c’est les mettre sur l’ordinateur d’Apple, de Google, de Microsoft.

Alors OK, on parle pas d’un petit PC qui prend la poussière, hein. On parle d’une grosse ferme de serveurs, de milliers d’ordinateurs qui chauffent tellement que des climatiseurs tournent à fond.

Mais c’est le même principe : un serveur, c’est un ordinateur-serviteur en mode Igor, qui est tout le temps allumé, qu’on a enchaîné au plus gros tuyau internet possible. Dès qu’on lui demande une page web, un fichier, un email, une application… on le fouette et il doit répondre au plus vite « Ouiiiiii, Mestre ! »

Tout le truc est de savoir si tu fais confiance aux Igors de savants fous dont le but est de devenir les plus riches et les maîtres du monde, ou au petit Igor du gentil nerd du coin… Voire si tu te paierais pas le luxe d’avoir ton propre Igor, ton propre serveur à la maison.

• Utilise les services de Dégooglisons Internet, les Igors de Framasoft…
• …encore mieux : trouve un gentil Igor près de chez toi avec les CHATONS…
• …encore plus mieux : crée ton propre Igor avec Yunohost / La Brique Internet !

8) Facebook est plus fort que ma volonté.

Ouais, je suis faible. J’ai, encore aujourd’hui, le réflexe « je clique sur facebook entre deux trucs à faire ». Ou Twitter. Ou Tumblr. Ou l’autre truc à la con, OSEF, c’est pareil.

Cinq minutes plus tard, je finis dans état de semi zombie, à scroller de la mollette en voyant mon mur défiler des informations devant mes yeux hypnotisés. Je finis par faire ce qu’on attend de moi : cliquer sur un titre putassier, liker, retwetter une notification et répondre à des trucs dont je n’aurais rien à foutre si une vague connaissance venait m’en parler dans un bar.

Ce n’est pas que je manque de volonté : c’est juste que Facebook (et ses collègues de bureau) m’ont bien étudié. Enfin, ils ont plus étudié l’humain que moi, mais pas de bol : j’en fais partie. Du coup ils ont construit leurs sites, leurs applications, etc. de façon à me piéger, à ce que je reste là (afin de bouffer leur pub), et à ce que j’y retourne.

Ces techniques de design qui hackent notre esprit (genre le « scroll infini », le « bandit manchot des notifications » et les « titres clickbait » dont je parle juste au dessus) sont volontaires, étudiées et documentées. Elles utilisent simplement des failles de notre esprit (subconscient, inconscient, biais cognitifs… je laisse les scientifiques définir tout cela) qui court-circuitent nos volontés. Ce n’est pas en croyant qu’on est maître de soi-même qu’on l’est vraiment. C’est souvent le contraire : le code fait la loi jusque dans nos esprits.

Bref, je suis faible, parce que je suis humain, et donc je suis pas le seul. Et ça, les géants du web l’ont bien compris.

• Comment est-ce que le code, c’est la loi.
• Un ex « Philosophe-produit » de chez Google explique comment des millions d’heures de nos vies nous sont volées
• Comment la technologie pirate l’esprit des gens, l’article originel en Anglais de Tristan Harris

9) Internet est ce que j’en ferai

Si je veux voir d’autres choses dans ma vie numérique, j’ai le choix : attendre que les autres le fassent jusqu’à ce que des toiles d’araignées collent mes phalanges aux touches de mon clavier, en mode squelette… ou bien je peux bouger mes doigts.

Alors ouais, j’ai pas appris à conduire en vingt heures de cours, j’ai raté plein de gâteaux avant de m’acheter les bons ustensiles et la première écharpe que j’ai faite avait pleins de trous. Mais aujourd’hui, je sais conduire, faire des pâtisseries pas dégueu et même me tricoter un pull.

Ben créer et diffuser des contenus sur Internet, c’est pareil, ça s’apprend. On trouve même facilement les infos et les outils sur Internet (dont des cours de tricot !).

Une fois qu’on sait, on peut proposer autre chose : c’est la mode des articles courts, creux et aux titres putassiers ? Tiens, et si je gardais le coup du titre pour faire un top, mais cette fois-ci dans un article blog long, dense, et condensant une tonne de sujets épars…?

Oh, wait.

• Zeste de savoir, un site pour apprendre et partager de tout.
• OpenClassrooms, un site pour se former au numérique

10) C’est pas la fin du monde, juste le début.

Quand on voit à quel point on a perdu la maîtrise de l’informatique, de nos vies numériques, de notre capacité à simplement imaginer comment on pourrait faire autrement… y’a de quoi déprimer.

Mais avant que tu demandes à ce qu’on t’apporte une corde, une pierre et une rivière, regarde juste un truc : le numérique est une révolution toute jeune dans notre Histoire. C’est comme quand tu découvres le chocolat, le maquillage, ou une fucking nouvelle série qui déboîte : tu t’en fous plein la gueule.

Sociétalement, on vient de se gaver d’ordinateurs (jusqu’à en mettre dans nos poches, ouais, de vrais ordis avec option téléphone !) et de numérique, et là les plus gros marchands de chocolat/maquillage/séries se sont gavés sur notre dos en nous fourguant un truc sucré, gras et qui nous laisse parfois l’estomac au bord des lèvres.

Mais on commence tout juste, et il est encore temps d’apprendre à devenir gourmet, à savoir se maquiller avec finesse, et même à écrire une fan fiction autour de cette nouvelle série.

Il est temps de revenir vers une informatique-amie, à échelle humaine, vers un outil que l’on maîtrise nous ! (et pas l’inverse, parce que moi j’aime pas que mon lave-linge me donne des ordres, nanmého !)

Des gens plus intelligents et spécialistes que moi m’ont dit qu’avec le trio « logiciel libres + chiffrement + services décentralisés », on tenait une bonne piste. J’ai tendance à les croire, et si ça te botte, tu peux venir explorer cette voie avec nous. Cela ne nous empêchera pas d’en cheminer d’autres, ensemble et en même temps, car nous avons un vaste territoire à découvrir.

Alors, t’es prêt pour la terra incognita ?

• Lire Surveillance:// de Tristan Nitot
• Lire Numérique, reprendre le contrôle, ouvrage collectif chez Framabook

L’open source est de plus en plus populaire et répandu parmi les développeurs. Grâce à des plate-formes comme GitHub, qui ont standardisé la manière de contribuer à un projet, l’open source est devenu plus accessible, au point de devenir une norme. Mais cette nouvelle configuration n’est pas sans poser certains problèmes.

Dans ce nouveau chapitre de son ouvrage Des Routes et des ponts (traduit chapitre après chapitre par l’équipe Framalang), Nadia Eghbal s’intéresse aux enjeux de la standardisation et de la démocratisation de l’open source – notamment à l’inflation parfois anarchique du nombre de projets et de contributeurs : pour elle, l’enjeu est d’éviter que l’écosystème numérique ne se transforme en un fragile château de cartes.

Pourquoi les problèmes de support des infrastructures numériques sont de plus en plus pressants

Traduction Framalang : goudron, Penguin, serici, goofy, Rozmador, xi, Lumibd, teromene, xi, Opsylac, et 3 anonymes.

L’open source, grâce à ses points forts cités plus tôt dans ce rapport, est rapidement en train de devenir un standard pour les projets d’infrastructure numérique et dans le développement logiciel en général. Black Duck, une entreprise qui aide ses clients à gérer des programmes open source, dirige une enquête annuelle qui interroge les entreprises sur leur utilisation de l’open source. (Cette enquête est l’un des rares projets de banque de données qui existe sur le sujet.) Dans leur étude de 2015, 78% des 1300 entreprises interrogées déclarent que les logiciels qu’elles ont créés pour leurs clients sont construits grâce à l’open source, soit presque le double du chiffre de 2010.

L’open source a vu sa popularité s’accroître de manière impressionnante ces cinq dernières années, pas seulement grâce à ses avantages évidents pour les développeurs et les consommateurs, mais également grâce à de nouveaux outils qui rendent la collaboration plus facile. Pour comprendre pourquoi les infrastructures numériques rencontrent des problèmes de support grandissants, nous devons comprendre la manière dont le développement de logiciels open source prolifère.

Github, un espace standardisé pour collaborer sur du code

On n’insistera jamais trop sur le rôle clé de GitHub dans la diffusion de l’open source auprès d’une audience grand public. L’open source a beau exister depuis près de 30 ans, jusqu’en 2008, contribuer à des projets open source n’était pas si facile. Le développeur motivé devait d’abord découvrir qui était le mainteneur du projet, trouver une manière de le contacter, puis proposer ses changements en utilisant le format choisi par le mainteneur (par exemple une liste courriel ou un forum). GitHub a standardisé ces méthodes de communication : les mainteneurs sont listés de façon transparente sur la page du projet, et les discussions sur les changements proposés ont lieu sur la plate-forme GitHub.

GitHub a aussi créé un vocabulaire qui est désormais standard parmi les contributeurs à l’open source, tels que la « pull request » (où un développeur soumet à l’examen de ses pairs une modification à un projet), et changé le sens du terme « fork » (historiquement, créer une copie d’un projet et le modifier pour le transformer en un nouveau projet) [littéralement « fork » signifie « bifurcation », Ndt.]. Avant GitHub, forker un projet revenait à dire qu’il y avait un différend irréconciliable au sujet de la direction qu’un projet devrait prendre. Forker était considéré comme une action grave : si un groupe de développeurs décidait de forker un projet, cela signifiait qu’il se scindait en deux factions idéologiques. Forker était aussi utilisé pour développer un nouveau projet qui pouvait avoir une utilisation radicalement différente du projet initial.

Ce type de « fork de projet » existe toujours, mais GitHub a décidé d’utiliser le terme « fork » pour encourager à davantage d’activité sur sa plate-forme. Un fork GitHub, contrairement à un fork de projet, est une copie temporaire d’un projet sur laquelle on effectue des modifications, et qui est généralement re-fusionnée au projet. Le fork en tant que pratique quotidienne sur GitHub a ajouté une connotation positive, légère au terme : c’est l’idée de prendre l’idée de quelqu’un et de l’améliorer.

GitHub a aussi aidé à standardiser l’utilisation d’un système de contrôle de version appelé Git. Les systèmes de contrôle de versions sont un outil qui permet de garder une trace de chaque contribution apportée sur un morceau de code précis. Par exemple, si le Développeur 1 et le Développeur 2 corrigent différentes parties du même code en même temps, enregistrer chaque changement dans un système de contrôle de version permet de faire en sorte que leurs changements n’entrent pas en conflit. Il existe plusieurs systèmes de contrôle de versions, par exemple Apache Subversion et Concurrent Versions System (CVS). Avant GitHub, Git était un système de contrôle de version assez méconnu. En 2010, Subversion était utilisé dans 60% des projets logiciels, contre 11%pour Git.

C’est Linus Torvalds, le créateur de Linux, qui a conçu Git en 2005. Son intention était de mettre à disposition un outil à la fois plus efficace et plus rapide, qui permette de gérer de multiples contributions apportées par de nombreux participants. Git était vraiment différent des systèmes de contrôle de version précédents, et donc pas forcément facile à adopter, mais son workflow décentralisé a résolu un vrai problème pour les développeurs.

GitHub a fourni une interface utilisateur intuitive pour les projets open source qui utilisent Git, ce qui rend l’apprentissage plus facile pour les développeurs. Plus les développeurs utilisent GitHub, plus cela les incite à continuer d’utiliser Git. Aujourd’hui, en 2016, Git est utilisé par 38% des projets de logiciels, tandis que la part de Subversion est tombée à 47%. Bien que Subversion soit encore le système de contrôle de version le plus populaire, son usage décline. L’adoption généralisée de Git rend plus facile pour un développeur la démarche de se joindre à un projet sur GitHub, car la méthode pour faire des modifications et pour les communiquer est la même sur tous les projets. Apprendre à contribuer sur un seul des projets vous permet d’acquérir les compétences pour contribuer à des centaines d’autres. Ce n’était pas le cas avant GitHub, où des systèmes de contrôle de versions différents étaient utilisés pour chaque projet.

Enfin, GitHub a créé un espace sociabilité, qui permet de discuter et de tisser des liens au-delà de la stricte collaboration sur du code. La plate-forme est devenue de facto une sorte de communauté pour les développeurs, qui l’utilisent pour communiquer ensemble et exposer leur travail. Ils peuvent y démontrer leur influence et présenter un portfolio de leur travail comme jamais auparavant.

Les usages de GitHub sont un reflet de son ascension vertigineuse. En 2011 il n’y avait que 2 millions de dépôts (« repository »). Aujourd’hui, GitHub a 14 millions d’utilisateurs et plus de 35 millions de dépôts (ce qui inclut aussi les dépôts forkés, le compte des dépôts uniques est plutôt aux environs de 17 millions.) Brian Doll, de chez GitHub, a noté qu’il a fallu 4 ans pour atteindre le million de dépôts, mais que passer de neuf millions à dix millions n’a pris que 48 jours.

En comparaison, SourceForge, la plate-forme qui était la plus populaire pour héberger du code open source avant l’apparition de GitHub, avait 150 000 projets en 2008. Environ 18 000 projets étaient actifs.

Stack Overflow, un espace standard pour s’entraider sur du code

L’une des autres plate-formes importantes de l’open source est Stack Overflow, un site de question/réponse populaire parmi les développeurs, créé en 2008 par Jeff Atwood (développeur déjà mentionné précédemment) et par le blogueur Joel Spolsky. En Avril 2014, Stack Overflow avait plus de 4 millions d’utilisateurs enregistrés et plus de 11 millions de questions résolues (à noter qu’il n’est pas nécessaire de s’enregistrer pour voir les questions ou leurs réponses).

Stack Overflow est devenu de facto une plate-forme d’entraide pour les développeurs, qui peuvent poser des questions de programmation, trouver des réponses à des problèmes de code spécifiques, ou juste échanger des conseils sur la meilleure façon de créer un aspect précis d’un logiciel. On pourrait définir la plate-forme comme un « support client » participatif pour les développeurs à travers le monde. Même si Stack Overflow n’est pas un endroit où l’on écrit directement du code, c’est un outil de collaboration essentiel pour les développeurs individuels, qui facilite grandement la résolution de problèmes et permet de coder plus efficacement. Cela signifie qu’un développeur individuel est capable de produire plus, en moins de temps, ce qui améliore le rendement global. Stack Overflow a également permis à certains utilisateurs d’apprendre de nouveaux concepts de développement (ou même de s’initier au code tout court), et a rendu le codage plus facile et plus accessible à tous.

Tendances macro dans un paysage en mutation constante

La popularité hors-normes de l’open source a amené à des changements significatifs dans la manière dont les développeurs d’aujourd’hui parlent, pensent et collaborent sur des logiciels.

Premièrement, les attentes et exigences en termes de licences ont changé, reflétant un monde qui considère désormais l’open source comme une norme, et pas l’exception : un triomphe sur l’univers propriétaire des années 1980. Les politiques de GitHub et de Stack Overflow reflètent toutes deux cette réalité.

Dès le départ, Stack Overflow a choisi d’utiliser une licence Creative Commons appelée CC-BY-SA pour tous les contenus postés sur son site. La licence était cependant limitante, car elle requérait des utilisateurs qu’ils mentionnent l’auteur de chaque morceau de code qu’ils utilisaient, et qu’ils placent leurs propres contributions sous la même licence.

Beaucoup d’utilisateurs choisissaient d’ignorer la licence ou n’étaient même pas au courant de ses restrictions, mais pour les développeurs travaillant avec des contraintes plus strictes (par exemple dans le cadre d’une entreprise), elle rendait Stack Overflow compliqué à utiliser. S’ils postaient une question demandant de l’aide sur leur code, et qu’une personne extérieure réglait le problème, alors légalement, ils devaient attribuer le code à cette personne.

En conséquence, les dirigeants de Stack Overflow ont annoncé leur volonté de déplacer toutes les nouvelles contributions de code sous la Licence MIT, qui est une licence open source comportant moins de restrictions. En Avril 2016, ils débattent encore activement et sollicitent des retours de leur communauté pour déterminer le meilleur moyen de mettre en œuvre un système plus permissif. Cette démarche est un encouragement à la fois pour la popularité de Stack Overflow et pour la prolifération de l’open source en général. Qu’un développeur travaillant dans une grosse entreprise de logiciel puisse légalement inclure le code d’une personne complètement extérieure dans un produit pour lequel il est rémunéré est en effet un accomplissement pour l’open source.

A l’inverse, GitHub fit initialement le choix de ne pas attribuer de licence par défaut aux projets postés sur sa plateforme, peut-être par crainte que cela ne freine son adoption par les utilisateurs et sa croissance. Ainsi, les projets postés sur GitHub accordent le droit de consulter et de forker le projet, mais sont à part ça sous copyright, sauf si le développeur spécifie qu’il s’agit d’une licence open source.

En 2013, GitHub décida enfin de prendre davantage position sur la question des licences, avec notamment la création et la promotion d’un micro-site, choosealicense.com (« choisissez-une-licence »), pour aider les utilisateurs à choisir une licence pour leur projet. Ils encouragent aussi désormais leurs utilisateurs à choisir une licence parmi une liste d’options au moment de créer un nouveau « repository » (dépôt).

Ce qui est intéressant, cependant, c’est que la plupart des développeurs ne se préoccupaient pas de la question des licences : soit ignoraient que leurs projets « open source » n’étaient pas légalement protégés, soit ils s’en fichaient. Une étude informelle réalisée en 2013 par le Software Freedom Law Center (Centre du Droit de la Liberté des Logiciels) sur un échantillon de 1,6 million de dépôts GitHub révéla que seuls 15% d’entre eux avaient spécifié une licence. Aussi, les entretiens avec des développeurs réalisés pour ce rapport suggèrent que beaucoup se fichent de spécifier une licence, ou se disent que si quelqu’un demande, ils pourront toujours en ajouter une plus tard.

Ce manque d’intérêt pour les licences a amené James Governor, cofondateur de la firme d’analyse de développeurs Red Monk, à constater en 2012 que « les jeunes dévs aujourd’hui font du POSS – Post open source software. Envoie chier les licences et la gestion, contribue juste à GitHub » [en anglais « commit to GitHub » signifie littéralement « s’engager dans GitHub » mais fait également référence à la commande « commit » qui permet de valider les modifications apportées à un projet, NdT.]. En d’autres termes, faire de l’information ouverte par défaut est devenu une telle évidence culturelle aujourd’hui que les développeurs ne s’imaginent plus faire les choses autrement – un contexte bien différent de celui des rebelles politisés du logiciel libre des années 1980. Ce retournement des valeurs, quoi qu’inspirant au niveau global, peut cependant amener à des complications légales pour les individus quand leurs projets gagnent en popularité ou sont utilisés à des fins commerciales.

Mais, en rendant le travail collaboratif sur le code aussi facile et standardisé, l’open source se retrouve aux prises avec une série d’externalités perverses.

L’open source a rendu le codage plus facile et plus accessible au monde. Cette accessibilité accrue, à son tour, a engendré une nouvelle catégorie de développeurs, moins expérimentés, mais qui savent comment utiliser les composants préfabriqués par d’autres pour construire ce dont ils ont besoin.

En 2012, Jeff Atwood, cofondateur de Stack Overflow, rédigea un article de blog intitulé ironiquement « Pitié n’apprenez pas à coder », où il se plaint de la mode des stages et des écoles de code. Tout en se félicitant du désir des personnes non-techniciennes de comprendre le code d’un point de vue conceptuel, Atwood met en garde contre l’idée qu’« introduire parmi la main-d’œuvre ces codeurs naïfs, novices, voire même-pas-vraiment-sûrs-d’aimer-ce-truc-de-programmeur, ait vraiment des effets positifs pour le monde ».

Dans ces circonstances, le modèle de développement de l’open source change de visage. Avant l’ascension de GitHub, il y avait moins de projets open source. Les développeurs étaient donc un groupe plus petit, mais en moyenne plus expérimenté : ceux qui utilisaient du code partagé par d’autres étaient susceptibles d’être également ceux qui contribuent en retour.

Aujourd’hui, l’intense développement de l’éducation au code implique que de nombreux développeurs inexpérimentés inondent le marché. Cette dernière génération de développeurs novices emprunte du code libre pour écrire ce dont elle a besoin, mais elle est rarement capable, en retour, d’apporter des contributions substantielles aux projets. Beaucoup sont également habitués à se considérer comme des « utilisateurs » de projets open source, davantage que comme les membres d’une communauté. Les outils open source étant désormais plus standardisés et faciles à utiliser, il est bien plus simple aujourd’hui pour un néophyte de débarquer sur un forum GitHub et d’y faire un commentaire désobligeant ou une requête exigeante – ce qui épuise et exaspère les mainteneurs.

Cette évolution démographique a aussi conduit à un réseau de logiciels bien plus fragmenté, avec de nombreux développeurs qui publient de nouveaux projets et qui créent un réseau embrouillé d’interdépendances. Se qualifiant lui-même de « développeur-pie en rémission » [« pie » est un surnom pour les développeurs-opportunistes, d’après le nom de l’oiseau, la pie réputée voleuse, NdT], Drew Hamlett a écrit en janvier 2016 un post de blog devenu très populaire intitulé « Le triste état du développement web ». L’article traite de l’évolution du développement web, se référant spécifiquement à l’écosystème Node.js :

« Les gens qui sont restés dans la communauté Node ont sans aucun doute créé l’écosystème le plus techniquement compliqué [sic] qui ait jamais existé. Personne n’arrive à y créer une bibliothèque qui fasse quoi que ce soit. Chaque projet qui émerge est encore plus ambitieux que le précédent… mais personne ne construit rien qui fonctionne concrètement. Je ne comprends vraiment pas. La seule explication que j’ai trouvée, c’est que les gens sont juste continuellement en train d’écrire et de réécrire en boucle des applis Node.js. »

Aujourd’hui, il y a tellement de projets qui s’élaborent et se publient qu’il est tout simplement impossible pour chacun d’eux de développer une communauté suffisamment importante et viable, avec des contributeurs réguliers qui discuteraient avec passion des modifications à apporter lors de débats approfondis sur des listes courriels. Au lieu de cela, beaucoup de projets sont maintenus par une ou deux personnes seulement, alors même que la demande des utilisateurs pour ces projets peut excéder le travail nécessaire à leur simple maintenance.

GitHub a rendu simples la création et la contribution à de nouveaux projets. Cela a été une bénédiction pour l’écosystème open source, car les projets se développent plus rapidement. Mais cela peut aussi parfois tourner à la malédiction pour les mainteneurs de projets, car davantage de personnes peuvent facilement signaler des problèmes ou réclamer de nouvelles fonctionnalités, sans pour autant contribuer elles-mêmes en retour. Ces interactions superficielles ne font qu’alourdir la charge de travail des mainteneurs, dont on attend qu’ils répondent à une quantité croissante de requêtes.

Il ne serait pas déraisonnable d’affirmer qu’un monde « post-open source » implique une réflexion non seulement autour des licences, ainsi que James Governor l’exprimait dans son commentaire originel, mais aussi autour du processus de développement lui-même.

Noah Kantrowitz, développeur Python de longue date et membre de la Python Software Foundation, a résumé ce changement dans un post de blog souvent cité :

« Dans les débuts du mouvement open source, il y avait assez peu de projets, et en général, la plupart des gens qui utilisaient un projet y contribuaient en retour d’une façon ou d’une autre. Ces deux choses ont changé à un point difficilement mesurable.
[…] Alors même que nous allons de plus en plus vers des outils de niche, il devient difficile de justifier l’investissement en temps requis pour devenir contributeur. « Combler son propre besoin » est toujours une excellente motivation, mais il est difficile de construire un écosystème là-dessus.
L’autre problème est le déséquilibre de plus en plus important entre producteurs et consommateurs. Avant, cela s’équilibrait à peu près. Tout le monde investissait du temps et des efforts dans les Communs et tout le monde en récoltait les bénéfices. Ces temps-ci, très peu de personnes font cet effort et la grande majorité ne fait que bénéficier du travail de ceux qui s’impliquent.
Ce déséquilibre s’est tellement enraciné qu’il est presque impensable pour une entreprise de rendre (en temps ou en argent) ne serait-ce qu’une petite fraction de la valeur qu’elle dérive des Communs. »

Cela ne veut pas dire qu’il n’existe plus de grands projets open source avec des communautés de contributeurs fortes (Node.js, dont on parlera plus tard dans ce rapport, est un exemple de projet qui est parvenu à ce statut.) Cela signifie qu’à côté de ces réussites, il y a une nouvelle catégorie de projets qui est défavorisée par les normes et les attentes actuelles de l’open source, et que le comportement qui dérive de ces nouvelles normes affecte même des projets plus gros et plus anciens.

Hynek Schlawack, Fellow de la Python Software Foundation et contributeur sur des projets d’infrastructure Python, exprime ses craintes au sujet d’un futur où il y aurait une demande plus forte, mais seulement une poignée de contributeurs solides :

« Ce qui me frustre le plus, c’est que nous n’avons jamais eu autant de développeurs Python et aussi peu de contributions de haute qualité. […] Dès que des développeurs clefs comme Armin Ronacher ralentissent leur travail, la communauté toute entière le ressent aussitôt. Le jour où Paul Kehrer arrête de travailler sur PyCA, on est très mal. Si Hawkowl arrête son travail de portage, Twisted ne sera jamais sur Python 3 et Git.
La communauté est en train de se faire saigner par des personnes qui créent plus de travail qu’elles n’en fournissent. […] En ce moment, tout le monde bénéficie de ce qui a été construit mais la situation se détériore à cause du manque de financements et de contributions. Ça m’inquiète, parce Python est peut-être très populaire en ce moment mais une fois que les conséquences se feront sentir, les opportunistes partiront aussi vite qu’ils étaient arrivés. »

Pour la plupart des développeurs, il n’y a guère que 5 ans peut-être que l’open source est devenu populaire. La large communauté des concepteurs de logiciel débat rarement de la pérennité à long terme de l’open source, et n’a parfois même pas conscience du problème. Avec l’explosion du nombre de nouveaux développeurs qui utilisent du code partagé sans contribuer en retour, nous construisons des palaces sur une infrastructure en ruines.

Et hop, voici comme promis le remix de vos réponses aux quelques questions posées à propos des 10 ans du Framablog. Les lecteurs de la première heure se sont manifestés, mais aussi les plus récents !

Nous avons souhaité publier ce mashup pour vous donner la parole à l’occasion de cet article n° 2000 — enfin 2001, on a été un peu grillés parce que les annonces de rentrée sur le blog ont commencé à déferler, et ça ne va faire que croître et embellir, restez tunés !

Découvrez donc notre choix parfaitement arbitraire parmi vos réponses. Précisons : nous n’avons pas retenu *tous* les compliments et remerciements parce que ça faisait vraiment beaucoup, mais ça fait vachement plaisir ! Un grand merci à tous les lecteurs, nous voilà dopés pour la rentrée !

Comment tout a commencé

Voici les réponses à la question : comment avez-vous découvert le Framablog ?

• Probablement par le Planet Libre tout au début
• Par Ubuntu-fr, grâce au stand Framasoft lors d’une Ubuntu Party
• Par linuxfr
• Grâce à mes professeurs d’informatiques qui avaient installé nos ordinateurs directement avec Firefox et un marque page vers l’annuaire de logiciels libres Framasoft.
• Par un ami libriste en DUT informatique
• c’est une connaissance qui m’en a parlé.
• par mon entourage proche, famille militante qui m’a fait connaitre le libre et ses combats
• à cause de Pouhiou !! <3

Chacun sa route, chacun son chemin

J’ai connu le Framablog en m’intéressant à Linux, je voulais changer de Windows non pas pour son aspect libre, gratuit… mais parce que mon Windaube tombait tout le temps en panne. De fil en aiguille, de recherches en réponses et de liens en liens, j’ai découvert Framasoft (monde du libre oblige) et le Framablog. Je suis arrivé un peu avant le campagne « dégooglisons Internet », et je me suis mis à suivre le blog par flux RSS car cette initiative m’intérêssait. Je suis un peu un genre de « Dupuis-Morizeau » qui a basculé de l’autre côté du mur des GAFAM et utilise Linux Mint depuis 1 an en tant qu’OS principal, un peu grâce à Framasoft aussi !

• Bonne question, je ne m’en souviens même plus.
• Je ne sais plus !
• Je ne sais même plus depuis le temps…
• Je ne sais plus comment j’ai connu Framablog
• je ne m’en rappelle plus
• Je sais plus vraiment…
• Je ne me souviens plus … ça fait tellement longtemps …

Des articles ? il en manque !

Réponses sélectionnées à la question :

« Je trouve que dans le Framablog on ne parle pas assez de… »

alors, ça avance ?

…de l’avancement de dégooglisons (notament framaforms, framatweet, framapétitions et framanotes)
et des C.H.A.T.O.N.S. Vous nous avez bien titillé, on veut en savoir plus. Vous pourriez parler de jeu vidéo libre aussi, après tout c’est de la culture.

l’école du libre

• du libre… mais on n’en parlera jamais assez 😉
• des logiciels libres
• Je ne serais pas contre parler un peu plus d’éducation, et de la place du libre (ou de son absence de place parfois) dans le système éducatif, et des enjeux (cachés ou non) qu’il y a derrière cela
• Articles de fond, l’éducation (qui était vraiment très présent avant)

penser global, agir local

…d’action possible près de chez nous !

message perso

[Tac au tux] (et ça, c’est pas pour de rire, faut vraiment réorganiser ça !!!)

pour aller plus loin

• J’ai envie de dire de technique, mais je sais bien que ce n’est pas le but du framablog.
• Je pense que les articles de fond devrais proposer à la fin un index de ressources pour aller plus loin, soit techniquement, soit dans la réflexion, soit dans l’action. Par exemple un article sur le chiffrement devrait proposer des liens sur :
  – Les détails technique du chiffrement
  – D’autres articles sur le chiffrement
  – Comment essaimer (je vous mets dans ma poche avec ce mot :p)

le bistrot des distros

• Je trouve que dans le Framablog on ne parle pas assez de… Mageia. Blague à part, ne parle pas assez des distributions GNU/Linux. Le Libre par les logiciels c’est bien, le système qui les supporte a aussi son importance (même si Mme Michu ne souhaite pas adhérer au pingouin chevaucheur de Gnou).
• de distribution Gnu/Linux
• des GAFAM … cf.  https://gafam.wordpress.com/ que j’ai mis en ligne il y a quelques mois & http://www.gafam.fr/ que je suis en train de préparer tranquillement (et qui devrait être fin prêt en fin d’année) pour en faire un «  »vrai » » site concernant cette problématique : «  » gafam.fr : Faire connaître & promouvoir les alternatives aux GAFAMs
• de la protection de la vie privée (par des trucs & astuces, sous win & sous linux) : peut-être que notre ami gee pourrait faire quelques planches à se sujet ?
• des distributions GNU/Linux les plus populaires / connues / stables … pouvant judicieusement remplacer win & mac
• des logiciels libres les plus utilisés / connus … (pour présenter simplement / clairement les alternatives libres aux logiciels privateurs utilisés par mesdames Michu & Dupuis-Morizeau, en leur expliquant bien le pourquoi du comment)
• Distros et logiciels libres en remplacement des fermés

#FramaDebout

• Thèmes anticapitalistes, contre les entreprises (Ubuntu), des intérêts divergents entre les profits et 99 % de la population.
• Peut-être de structure économique justifiant les dérives, à mes yeux, -mais je m’avance un peu- ^^
• l’incompétence des décideurs (politiques, économiques…) en matière de progression de la société, ou de leur quasi volonté d’anesthésier le peuple.
• politique au sens large

le vrai problème

comment trouver l’amour quand on est un libriste !

C’est beau mais bof

« Techniquement et graphiquement, je trouve que le Framablog… »

travail non évalué

Bon, ça va, hein. Mais la perfection n’existe pas, donc ne compte pas sur moi pour un 20/20

c’est du bio c’est du bon

• C’est propre tout en ayant un petit goût de fait à la main, et quand c’est fait à la main, c’est souvent bon.
• Sobre, léger, très sympa
• est bien lisible sans se fatiguer. La navigation est facile.
• Sobre, esthétique et LISIBLE.

beugue riporte

Est assez épuré, les articles sont plaisants à lire même si parfois pour les interviews, on a des gros pâtés de texte. À noter, j’ai toujours un effet de scintillement lorsque la CSS se charge, vous pourriez peut-être voir pour améliorer les perfs de ce côté pour éviter ce « flash ».

fitcheur ricoueste

• Je n’y accède que par mes flux RSS. Peut-être un lien direct vers les commentaires en fin d’article (comme sur LinuxFR)
• Je lis les articles directement sur TheOldReader. Avoir les articles complets dans le flux RSS est important pour moi.
• Une version mobile/responsive serait un plus.

osef

• Globalement on s’en cogne… C’est le contenu qui est intéressant 🙂
• Un peu spartiate, mais ça va
• Correspond à mes attentes. En même  temps, j’en ai pas, des attentes…!

charte vermeille

• Design un peu vieux. Faudrait peut-être suivre, pour une fois, la mouvance de design (Flat par exemple?)
• Clair, mais un chouille old-school.
• Un peu vieillot mais avec les évolutions qui arrivent par petites touches on voit que ça avance Graphiquement un peu à la traîne

Framalang ? — C’est good et oui ouante encore participette.

À la question : « Un petit message pour les bénévoles de Framalang qui traduisent des nouvelles du monde du libre ? » voici les réponses que nous avons sélectionnées :

around the world around the world…

carry on & never give up !
« どうもありがとうございました
がんばってください »

holla !
Good job !
Molte gracie
Muchas gracias
Bolchoi Paciba

c’est trop bien

• Je trouve que vous faites un travail incroyable et qui mérite toutes mes félicitations. Vos traductions me sont très utiles puisque je peux ainsi lire des articles anglais que je n’aurais pas pensé chercher sur Internet.
• BRAVO ! Votre travail est vraiment excellent et permet aux anglophobes d’accéder à des informations non relayées par les médias classiques ou difficiles à appréhender avec les subtilités du langage.
• bravo et merci! Un grand merci à tous pour tout le Framaboulot accompli depuis ces années !
• Merci du gros travail de traductions, qui est de bonne qualité .

mais euh ça va trop vite !

• Pour avoir participé un petit peu il y a quelques années, j’ai trouvé la méthodo et l’infrastructure hyper efficace, j’étais toujours étonné de la rapidité des traductions, il fallait limite se dépêcher si on voulait pouvoir participer un peu.
• j’arrive souvent après la bataille :'(
• Dans le temps j’ai perdu le fil, et je ne sais même plus aujourd’hui comment m’informer des nouvelles traductions proposées. À l’époque c’était des appels par Twitter. P.S.: je viens de chercher et du coup me suis inscrit à la liste de diffusion framalang@framalistes.org :DDDDD »

Framasoft ? — On gère du pâté et on en fout partout

Voici ce qu’ont répondu quelques-uns à la question finale : « Un autre message pour l’équipe du Framablog et de Framasoft ? lâchez-vous ! »

optimiste et conquérant :

Cette année nous démarrons (grâce à vous !!!) la dégooglisation du lycée agricole d’E. et par là même la dégooglisation des esprits de nos apprenants… (il faut préciser que nous sommes de très gros consommateurs de Google Drive et que nous espérons, d’ici deux ans, conjuguer cette phrase au passé)

la belle histoire

Petite histoire, ma mère travaillait dans un collège très pauvre à M. avec des élèves vraiment très défavorisés. Elle distribuait des Framakeys à un moment je crois, et recommandait systématiquement les logiciels libres. Elle avait donné des copies de Open Office à l’époque et des élèves l’avaient remerciée chaleureusement de leur avoir fait découvrir cela, car elles ignoraient que de telles choses existaient et visiblement n’avaient même pas l’idée de craquer des logiciels de traitement de texte propriétaires et/ou avaient été épargnés par la vente liée (bizarre!).

repas de famille

En vrai, de plus en plus de gens, même mes proches et notamment ma famille : des oncles, des tantes etc, commencent fortement à s’intéresser à ces problématiques grâce au framamonde.

fédération charcutière

Merci pour tout, merci pour le bien que vous faites à Internet en général (avec d’autres services comme Qwant, l’April ou la mère Zaclys pour ne citer qu’eux), vous êtes une pierre importante de l’édifice libre que j’utilise au quotidien (Linux, Framasphère*, Framablog, Framacarte, Framatube, Framindmap, Framadrop (hyper utile, merci !), j’aurai  bien voulu un Framadrive mais y’a pu d’place… :P) ! Et rien que pour ça, vous gérez du pâté !

à l’assaut l’asso

Pas de grand discours mais juste un grand merci pour votre mobilisation et votre ouverture. J’ai appris beaucoup de chose avec vous, je me suis trouvée de nouveaux centres d’intérêts et un « combat » de la vie de tous les jours.

sentier lumineux

Vous êtes la lumière dans un monde d’obscurité

trop mignon

Des gros bisous avec plein de licornes et chats des internets <3

gâteau d’anniversaire offert par normanack (CC BY 2.0)

La sortie d’un nouveau windows est toujours une belle nouvelle pour nous… C’est l’occasion de dire à notre entourage « quitte à devoir changer vos habitudes, pourquoi ne pas passer sous GnuNux ? »

Cet argument a beau faire mouche, il ne fonctionne pas tout le temps auprès des Dupuis-Morizeau (ça faisait longtemps qu’on n’avait pas parlé de notre sympathique famille-témoin Normande, hein ?). Qu’à cela ne tienne, on est parés à tous niveaux.

Microsoft, vous nous avez gâtés <3 !

Vous avez probablement lu une pléthore d’articles sur cette nouvelle sortie et les aberrations fonctionnalités qui l’accompagnent. Il faut dire que les arguments de vente et les choix stratégiques de la firme de Redmond sont autant de raisons de passer au Libre. Plutôt que de tout réécrire, voici un petit inventaire à la Prévert des raisons qui peuvent faire mouche…

• Premier argument, et non des moindres : l’indispensable Solitaire devient payant (soit vous payez en regardant de la pub, soit vous prenez un abonnement). Microsoft n’as pas entendu parler des jeux Libres sur Framagames…
• Les bureaux virtuels ne sont pas une innovation. C’est juste l’occasion donnée aux Linuxien-ne-s de passer pour des hipsters. (II ne manque plus que la barbe. (Oh, wait.))
• Microsoft, en bon GAFAM, veut vous donner un service totalement personnalisé (et la publicité qui va avec).
• Pas moyen de faire cela sans vous connaître intimement… C’est simplement leur démarche !
• Vous pouvez même partager votre code wifi via les serveurs de Microsoft… à vos risques et périls 😉 (en anglais).
• oh et puis pendant que nous y sommes, Windows 10 utilise votre bande passante, encore une fonctionnalité par défaut qu’il vous faudra désactiver.
• L’insatiable appétit de Microsoft pour vos données s’est accru au point que la CNIL française a fait un tuto pour vous apprendre à paramétrer votre windows…
• … et que son homologue Suisse s’apprête à entamer des procédures judiciaires contre Microsoft.
• Microsoft est prêt à payer les gens en bon cadeaux pour qu’ils restent sur leur nouveau navigateur, Edge (ça fait pas du tout désespéré :p)
• Windows 10 n’est plus compatible avec les jeux «protégés » des années 2000 (oui, on peut aussi dire « verrouillés »)
• Les mouchards de Windows 10 sont désormais implantés dans les versions 8.1 et 7, parce qu’il n’y pas pas de raison de se priver au grand festin de nos données.
• On peut se défaire de ces systèmes d’espionnage publicitaire, mais c’est un poil complexe pour mon papy.
• Et le plus important : Windows ne respecte toujours pas vos libertés et personne ne sait ce qu’il y a sous le capot (à part Microsoft, bien entendu).

Mais si vous voulez malgré tout rester sous Windows…

…on peut l’entendre ! Y’a des moments où on n’a pas le choix, pas l’envie, où on se sent pas les épaules… Essayer de vous culpabiliser sur ce point, ce serait juste créer un dogme, une morale, un « bien » et un « mal » se substituant à votre esprit critique.

Néanmoins, quitte à réinstaller Windows, pourquoi ne pas en profiter pour y utiliser un maximum de logiciels Libres ? Et ce n’est pas compliqué, pour cela, il y a Framapack !
Votre navigateur ne supporte pas l’élément iframe

L’équipe de Framasoft tient à chaleureusement remercier Pyves, un de nos framacolibris pour ce magnifique boulot réalisé sur RevealJS via les dessins de Gee. Cette présentation est sous licence CC-BY-SA, n’hésitez donc pas à la partager largement et librement autour de vous.

La voie est Libre !

Chez Framasoft, nous croyons à la politique du meilleur effort. Il peut être difficile d’effacer le M de GAFAM de sa vie, et d’arrêter Windows. Pourtant, les arguments contre son utilisation ne manquent pas… et si l’envie vous en prend, vous trouverez certainement une communauté près de chez vous pour vous aider à passer sous GNU/Linux et installer un système d’exploitation qui respecte VOS libertés.

Néanmoins, il est aujourd’hui très facile d’installer un maximum de logiciels Libres (donc qui respectent vos libertés à vous) sur votre ordinateur… C’est souvent le premier pas qui a permis à nombre de Linuxien-ne-s de cheminer sur cette route parfois longue, mais dont la voie est, et reste, Libre 😉

Il fut un temps ou débuter dans « le Libre » se résumait avant tout à coder ou plus modestement installer une distribution GNU/Linux. Aujourd’hui les choses ont bien changé et il existe de multiples autres façons d’y entrer. Framasoft est d’ailleurs là pour en témoigner 😉

Une invitation à venir nous rejoindre en somme…

Remarque : Il s’agit d’une traduction et donc les liens renvoient vers des ressources anglophones. Si vous avez des liens plus locaux à proposer, surtout ne pas hésiter.

10 façons de commencer dans l‘open source

10 ways to get started with open source

Jason Hibbets – 29 janvier 2013 – OpenSource.com
(Traduction : goofy, Tibo_R, XeO2, Steph, Alpha, Sylvie, jtanguy, aKa, Liaz, Norore + anonymes)

Par expérience, je sais qu’un grand nombre de personnes veulent découvrir et participer à l‘open source, mais ne savent pas par où commencer ; et l’idée que l’on est obligé d’écrire du code pour contribuer à un projet open source constitue une véritable barrière. J’ai donc esquissé 10 façons de commencer avec l‘open source et ce sans jamais écrire une seule ligne de code.

Je suis ouvert à toutes idées et ajouts ; il y a sans doute beaucoup plus que 10 façons de contribuer.

10 façons de commencer à utiliser l‘open source

1. Utiliser de l‘open source dans votre travail quotidien. Téléchargez et installez un navigateur web, un client de messagerie, ou une suite bureautique libres — peu importe le système que vous utilisez. C’est l’une des façons les plus simples de commencer à utiliser des logiciels libres. Je conseillerai Firefox pour la navigation internet et Thunderbird pour les emails. Utilisez LibreOffice pour votre traitement de texte, vos tableurs et vos diaporamas, vous aurez un équivalent de Microsoft Office gratuit ! J’appelle ces logiciels des applications porte d’entrée, parce qu’une fois que vous commencez à les utiliser, vous allez découvrir d’autres outils open source (et vous n’aurez pas envie de revenir en arrière !)

2. Rejoindre un projet open source. Je sais que rejoindre un projet open source peut faire peur, mais les contributeurs de tous niveaux sont les bienvenus. Les communautés open source utilisent des chefs de projets, des graphistes, des communicants, des commerciaux et beaucoup d’autres compétences dans leurs travaux. Si vous souhaitez présenter l’open source aux étudiants, voilà une très bonne façon de commencer. On ne sait jamais, s’impliquer et participer activement à un projet open source peut améliorer un CV et mener à un emploi.

3. Lire un livre à propos de l‘open source. Voici un choix de quelques titres auxquels vous pouvez jeter un coup d’oeil : Open Advice (NdT : que nous sommes en train de traduire), Coding Freedom, The Power of Open, ou l’un de nos livres numériques. (NdT : En français il y a évidemment tous les titres de la collection Framabook)

4. Apprendre à créer et nourrir des communautés de contributeurs. Parcourez le livre en ligne The Open Source Way, et partagez vos nouvelles connaissances en créant une communauté ou en en rejoignant une existante.

5. Commencer à utiliser les licences Creative Commons. Avant de créer votre nouvelle œuvre d’art, photographie, écrit ou musique, utilisez un copyleft au lieu d’un copyright. En utilisant des licences Creative Commons, vous pouvez partager votre travail avec le monde entier. Vous devrez d’abord choisir celle qui vous correspond, vous pourrez ensuite trouver intéressant de découvrir comment les Creative Commons sont utilisées dans des environnements aussi variés que les gouvernements, les entreprises ou le journalisme. (NdT : Voir aussi L’éducation utilise une licence Creative Commons défectueuse, par R. Stallman sur le Framablog)

6. Commencer l’exploration. Regardez le projet OpenROV et explorez l’océan ou un lac local. Si vous ne voulez pas être mouillé, enfilez une combinaison spatiale et regardez ce que ça fait d’explorer Mars.

7. Bricoler par soi-même et créer quelque chose. Les petites cartes Linux, comme la Raspberry Pi, font des choses incroyables. Découvrez les autres cartes électroniques de création comme les « Makey Makey » (cf cette vidéo) ou une variété de produits électroniques de « SparkFUN ». Si vous êtes dans l’impression 3D, assurez-vous de savoir comment vous pourriez utiliser Inkscape.

8. Devenir créatif. Remplacez Photoshop par GNU Image Manipulation Program (GIMP), InDesign par Scribus, ou utilisez d’autres outils comme MyPaint, Inskape, Audacity et Blender. Si cela vous intéresse, regardez notre présentation en 7 minutes des outils créatifs open source. Puis découvrez l’étendue des outils de design en 2012. Assurez-vous d’avoir pris connaissance de nos autres outils tels que Dream Studio, TuxPaint et KDEnlive pour vos besoins créatifs.

9. Apprendre la programmation. Remarquez que je n’ai pas dit « Apprendre à coder ». Différents outils sont pré-installés sur certains Raspberry Pi et sont utilisés pour apprendre aux enfants à programmer. J’aurais aimé avoir ce genre de choses quand j’ai appris la programmation au lycée.

10. Suivre un cours en ligne. Le mouvement OpenCourseWare, mené par MITOCW, est en train de changer notre mode d’apprentissage. Commencez par regarder ce Webcast sur le MIT OpenCourseWare. Il y a tellement d’événements open source dans le champ éducatif: « Moodle » et « School management software for teachers and students » sont deux de ces nombreuses ressources fantastiques. (NdT : Exemple en France la présentation du MOOC ITyPA)

Le fait est qu’il y a énormément de manières de commencer dans l‘open source. Vous souvenez-vous de la façon dont vous avez débuté ? Partagez l’histoire de votre première expérience avec l‘open source ou comment vous l’avez présentée à quelqu’un d’autre.

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

Traduction Framalang : Sky, LIAR, lerouge, Goofy, peupleLa, lamessen LAuX, KoS, Nys, Julius22, okram, kalupa, 4nti7rust, CoudCoud, zn01wr + Sinma

L’art de résoudre les problèmes

Thiago Madeira

Thiago Macieira est doublement diplômé. Il a une maîtrise en administration des affaires (MBA) et un diplôme d’ingénieur. Mais son implication dans le mouvement open source, depuis près de 15 ans maintenant, est antérieur à ses diplômes. Participant actif des communautés KDE, Qt et MeeGo, il a été ingénieur logiciel et responsable produit pour Qt, il a fait des conférences et il a écouté les gens. À présent, Thiago vit à Oslo en Norvège et quand il ne travaille pas sur Qt, il essaye — sans grande réussite — d’améliorer son skill à StarCraft 2.

Les problèmes forment une routine à laquelle nous sommes confrontés presque tous les jours ; nous les résolvons et c’est tellement habituel que bien souvent nous n’en avons même pas conscience. Cela peut être des situations aussi simples que chercher le meilleur chemin pour arriver à destination ou trouver la meilleure façon de tout faire tenir dans le réfrigérateur. Ce n’est que lorsque nous ne parvenons pas à les résoudre immédiatement que nous remarquons les problèmes car nous devons alors nous arrêter et y réfléchir. Notre vie professionnelle n’échappe pas à cette règle et la résolution de problèmes commence à faire partie de la description du poste à pourvoir.

La résolution de problèmes était le sujet de mon premier cours quand j’ai commencé ma formation d’ingénieur. Dans cet amphithéâtre bondé du siècle dernier, notre professeur expliquait à environ 700 étudiants de première année en quoi les ingénieurs étaient des solutionneurs de problèmes et comment nos vies professionnelles consisteraient à enchaîner les problèmes à résoudre. Certains seraient des problèmes faciles résolus en deux temps trois mouvements ; d’autres seraient tellement difficiles que nous aurions besoin d’une structure de projet et d’une équipe pour les résoudre — mais la plupart se situeraient entre ces deux extrêmes. Puis il commença à donner des exemples sur la façon dont sa propre mentalité de « solutionneur de problèmes » l’avait aidé dans sa vie professionnelle et personnelle, et nous offrit même un exemple en direct quand tout à coup le projecteur nous tomba dessus.

La faculté de résoudre des problèmes est un talent que nous pouvons affiner par la pratique et un travail de fond. La pratique est quelque chose que l’on ne peut acquérir que par l’expérience, par succession d’essais et d’erreurs (1) ; ce n’est donc pas quelque chose qu’on peut apprendre dans un livre. Se mettre en situation de résoudre des problèmes, en revanche, est quelque chose que l’on peut apprendre. Face au problème, l’expérience est comme notre boîte à outils, et les techniques de résolution le mode d’emploi des outils.

Formuler correctement la question

La question à laquelle nous essayons de répondre fournit la direction que nous allons prendre en essayant de résoudre le problème. Posez la mauvaise question et les réponses seront peu pertinentes, invalides ou juste complètement fausses. Par conséquent, poser la bonne question est essentiel. De plus, poser correctement la bonne question est important, car cela apporte des indices quant à ce que nous recherchons. La manière la plus inutile d’énoncer un problème qu’on puisse rencontrer est : « ça marche pas », c’est pourtant un grand classique. Certes, l’énoncé est juste, puisque manifestement quelque chose a planté. Néanmoins, cette façon de présenter le problème n’apporte aucun indice sur le point de départ pour rechercher des solutions.

Les systèmes de gestion de bogues imposent souvent au rapporteur du bogue de préciser les actions effectuées qui ont conduit à ce problème, la description de ce qui s’est passé (c’est-à-dire le symptôme) et une description du comportement attendu. La comparaison entre le symptôme et le comportement attendu est un bon point de départ pour poser la question fondamentale : «  pourquoi cela s’est-il produit, pourquoi cet autre comportement ne s’est-il pas produit ? ». Même si ce n’est pas la seule manière d’y arriver, appliquer cette technique à des problèmes peut certainement aider à formuler la question.

Formuler correctement le problème et la question, dans ses moindres détails, est aussi une manière de décrire davantage le problème tel qu’il s’est manifesté. En premier lieu, nous devons avoir conscience que le problème ne se trouve probablement pas où nous nous attendons à le trouver — si c’était le cas, nous l’aurions probablement déjà résolu. Présenter tous les détails du problème permet à l’assistance technique d’avoir plus d’informations pour travailler. De plus, même si c’est contre-intuitif, le fait de décrire le problème dans sa totalité conduit souvent à trouver la solution, si bien que de nombreux groupes de développement ont besoin que des développeurs se concentrent sur cette tâche, soit en discutant avec un collègue soit en s’adressant à un être innocent, tel qu’un canard en caoutchouc ou M. Patate.

De plus, il faut revenir régulièrement à la question afin de garder l’objectif dans le viseur. Lors de la résolution du problème, il convient de faire attention à ne pas se concentrer exclusivement sur l’une de ses parties en perdant de vue l’objectif global. Pour la même raison, il est nécessaire de reprendre la question de départ lorsqu’on a trouvé une solution éventuelle, pour pouvoir s’assurer qu’elle couvre bien l’intégralité du problème. Là encore, cela prouve bien la nécessité de poser la bonne question, qui décrira le problème dans son intégralité : sans la question complète, la solution pourrait être également incomplète.

Diviser pour mieux régner (2)

L’expérience que j’ai acquise en aidant des utilisateurs en ligne à résoudre leurs problèmes m’a appris que la plupart des personnes considérent leurs difficultés comme des blocs d’achoppement, monolithiques et indivisibles, qu’il faut traiter comme un tout. Vu sous cet angle, un vaste problème pose une question à laquelle il est très difficile de répondre entièrement.

À vrai dire, la grande majorité de ces problèmes peut se décomposer en plusieurs petits problèmes qu’il est donc plus facile de traiter séparément afin de déterminer s’ils sont la cause originelle du problème, sans parler de la possibilité qu’il y ait plusieurs origines au symptôme rapporté. Répéter cette opération, ne serait-ce qu’un petit nombre de fois, revient à s’attaquer à des problèmes mieux circonscrits, et amène par conséquent à des solutions plus rapides.

Cependant, plus nous sommes obligés de décomposer, plus nous devons connaître le fonctionnement interne du système que nous avons sous la main. De fait, celui qui doit résoudre un problème ne pourra le décomposer qu’aussi loin que sa connaissance du sujet le lui permettra, et c’est depuis ce point qu’il pourra ensuite traiter la question.

Pour ce qui concerne le développement logiciel, les sous-systèmes utilisés sont souvent de bons indices pour trouver comment décomposer le problème. Par exemple, si le problème implique une transmission de données par TCP/IP, deux subdivisions possibles sont l’expéditeur et le destinataire : il ne sert à rien de chercher le problème du côté du destinataire si l’expéditeur ne transmet pas les données correctement. De même, une application graphique qui n’affiche pas les données appelées dans une base de données a une division claire : ce serait une bonne idée de vérifier d’abord que l’accès à la base de données fonctionne avant d’enquêter sur la cause du mauvais affichage. Par ailleurs, on pourrait également envoyer des informations quelconques aux fonctions d’affichage et vérifier que ces données s’affichent correctement.

Même quand les regroupements ne sont pas faciles à faire, diviser le problème peut tout de même contribuer à éclairer la question. En fait, les divisions sont presque toujours utiles, car elles réduisent la quantité de code à inspecter et le niveau de complexité à gérer. Au pire, le simple fait de diviser le code en deux parties et de chercher le problème dans l’une des deux peut être utile. Cette technique, nommée bissection, est recommandée si les divisions créées à partir des sous-systèmes et des interfaces n’ont pas encore apporté de solution.

Une succession de divisions appropriées aura pour résultat final un petit exemple autonome qui expose le problème. À ce stade, l’une des trois options suivantes est habituellement la bonne : le problème peut être identifié et localisé ; le code est en fait correct et c’était ce que l’on en attendait qui était faux ; ou bien un bogue a été trouvé dans la couche de code de plus bas niveau. Un des avantages de ce procédé, c’est qu’il génère un scénario de test à joindre à un rapport de bogue, pour peu qu’un bogue soit en cause.

Conditions aux limites (3)

Une question similaire à la division du problème est celle des conditions aux limites. En mathématiques et en physique, les conditions aux limites sont l’ensemble des valeurs qui déterminent la région de validité des équations résolues. Pour le logiciel, les conditions aux limites sont l’ensemble des conditions qui doivent être satisfaites pour que le code s’exécute correctement. Habituellement, les conditions aux limites sont loin d’être simples : à la différence des mathématiques ou de la physique, les variables des systèmes logiciels sont beaucoup trop nombreuses, ce qui signifie que leurs conditions aux limites sont également légion.

Dans les systèmes logiciels, les conditions aux limites sont souvent nommées « conditions préalables », c’est-à-dire des conditions qui doivent être satisfaites avant qu’une certaine action ne soit autorisée. Vérifier que ces conditions prélalables ont été satisfaites est un bon exercice dans la recherche d’une réponse, car leur violation est clairement un problème qui doit être résolu — quand bien même ce n’est pas la cause première du problème initial. Des conditions préalables peuvent tout simplement prendre la forme d’un pointeur qui doit être valide avant qu’on puisse le déréférencer, ou d’un objet qui ne doit pas être éliminé avant de pouvoir être utilisé. Les conditions préalables complexes seront très probablement documentées en vue de l’utilisation du logiciel.

Un autre groupe intéressant de conditions aux limites se caractérise, curieusement, par ce qui n’est pas autorisé : le comportement indéfini. Ce type de conditions aux limites est très commun lorsque l’on traite des spécifications qui essaient d’être très explicites sur la manière dont le logiciel est censé se comporter. Les compilateurs et les définitions de langage en sont un bon exemple. À strictement parler, déréférencer un pointeur null est un comportement indéfini : la conséquence la plus commune en est l’enregistrement d’une exception du processeur et l’arrêt du programme, mais d’autres comportements sont aussi autorisés, y compris le fonctionnement sans faille.

Le bon outil pour le bon usage

Si les ingénieurs sont des solutionneurs de problèmes, la devise de l’ingénieur est « Utilise le bon outil pour le bon usage ». Cela peut sembler évident, étant donné qu’on ne s’attend pas à ce que quelqu’un utilise un marteau pour résoudre un problème électronique. Cependant, les cas d’utilisation du mauvais outil sont plutôt fréquents, souvent parce qu’on ignore qu’il existe un meilleur outil.

Certains de ces outils sont la base du développement logiciel, comme le compilateur et le débogueur. L’incapacité à se servir de ces outils est impardonnable : le professionnel qui se retrouve dans un environnement d’outils nouveaux ou inconnus, si par exemple il change de poste ou d’emploi, doit consacrer du temps à apprendre à les utiliser, à se familiariser avec leurs fonctionnalités et limitations. Par exemple, si un programme plante, être capable de déterminer l’endroit du plantage ainsi que les variables appelées dans cette portion du code peut aider à trouver la cause du problème et donc la solution.

D’autres outils peu connus sont plus évolués, prévus pour des emplois spécifiques, ou encore ne sont disponibles qu’à un prix ou sous des conditions que l’ingénieur ne peut réunir. Ils peuvent toutefois être incroyablement utiles pour contribuer à la résolution de problèmes. Il peut s’agir de vérificateurs de code statique ou de processus, de débogueurs de mémoire, d’enregistreurs d’événements matériels, etc. Par exemple, le matériel de développement inclut souvent un système permettant de le contrôler à l’aide d’une interface spéficique comme JTAG ou de lister toutes les instructions exécutées et l’état des processeurs. Mais cela nécessite d’avoir du matériel et des outils spécifiques, qui ne sont pas facilement accessibles et coûtent plus cher que les machines et périphériques grand public. Un autre exemple est la suite d’outils Valgrind (4), qui comprend un vérificateur de processus et des débogueurs de mémoire. L’ensemble est gratuit, facilement disponible, mais fait partie de ces outils spécifiques de haut niveau dont l’usage n’est pas enseigné à l’école.

Connaître le contenu de sa boîte à outils est un savoir précieux. L’utilisation d’un outil spécialisé pour chercher un problème va probablement donner un résultat plus rapide, qu’il soit positif — et confirme le problème — ou négatif, et oriente la recherche dans une autre direction. Par ailleurs, il est important de savoir comment utiliser ces outils, ce qui justifie le temps passé à lire la documentation, à  s’entraîner ou simplement à expérimenter ces outils avec des problèmes connus pour comprendre comment ils fonctionnent.

Conclusion

Résoudre  les problèmes est un art accessible à tous. Comme pour tous les arts, certaines personnes semblent avoir une telle facilité qu’ils semblent être nés avec cette compétence. Mais en réalité, avec assez d’expérience et de pratique, la résolution des problèmes devient une activité insconsciente.

Quand on est confronté à un problème qui n’est pas évident à résoudre, il faut s’asseoir et le considérer dans son intégralité. Quel problème avons-nous ? Pouvons-nous formuler la question à laquelle nous devons répondre ? Une fois que nous savons ce que nous cherchons, nous pouvons commencer à examiner où peut être situé le problème. Peut-on le décomposer en parties plus petites et plus maniables ? Quels sont les meilleurs outils à utiliser pour chaque partie ? Avons-nous vérifié que nous utilisions correctement les fonctionnalités et services disponibles ?

Après avoir résolu de nombreux problèmes, on commence à repérer des schémas. Il devient plus facile de détecter des indices subtils à partir des symptômes et de diriger les recherches vers le problème réel. Un correcteur de problèmes expérimenté peut même ne pas se rendre compte que cette action a lieu. C’est un signe que l’expérience et les automatismes se sont si bien mis en place qu’il n’y a plus besoin d’effort conscient pour accéder à ces compétences.

Bien sûr il, y aura toujours des problèmes qui seront difficiles à résoudre dans la vie : problèmes professionnels, existentiels, philosophiques ou même ceux qui sont causés par la pure curiosité. Là encore, c’est le défi qui nous stimule, le besoin de comprendre toujours plus et mieux. Sans cela, la vie serait trop triste.

(1) http://fr.wikipedia.org/wiki/Apprentissage#Apprentissage_par_essais_et_erreurs

(2) http://fr.wikipedia.org/wiki/Diviser_pour_régner_(informatique)

(3) http://fr.wikipedia.org/wiki/Condition_aux_limites

(4) http://fr.wikipedia.org/wiki/Valgrind

Crédit photo Luxuryluke (CC BY-NC-ND 2.0)

Bon ben voilà, ceci est (déjà) le millième billet du Framablog ! Il tombe un dimanche matin en plein mois d’août, il ne devrait pas y avoir beaucoup de convives au banquet^[1]. La fête sera plus que confidentielle 🙂

L’aventure avait commencé ici, en septembre 2006, et contrairement à ce qui avait été annoncé on a beaucoup plus parlé du « Libre » que de Framasoft.

Par contre nous sommes restés relativement en phase avec à la phrase mise en exergue sur le bandeau : « mais ce serait peut-être l’une des plus grandes opportunités manqués de notre époque si le logiciel libre ne libérait rien d’autre que du code ».

Les digues de la résistance sont hautes et solides et il reste encore beaucoup à faire. Mais l’agent émancipateur logiciel libre est bien en train de produire ses effets et d’inspirer dans son sillage de toujours plus nombreux domaines de l’activité humaine.

C’est cette histoire en marche que nous essayons modestement de témoigner et de chroniquer ici depuis cinq ans, en assumant notre oscillation permanente entre la neutralité journalistique et le parti pris de ceux qui y croient.

Je dis « nous » parce que la plume de ce blog n’est pas uniquement tenue par son « dictateur bienveillant à vie ».

Il y a eu d’autres rédacteurs, tel l’auteur du Geektionnerd pour n’en citer qu’un. Il y a eu aussi tous ceux qui ont bien voulu que l’on reproduise leurs articles en ces lieux. Et puis surtout, ce qui constitue sans nul doute la plus forte valeur ajoutée du site, toutes ces traductions que nous devons à notre dream team Framalang. En y ajoutant les commentateurs, on a l’équipe au complet que je remercie chaleureusement comme il se doit pour son implication.

Ici comme ailleurs, la route est décidément fort longue mais ensemble la voie semble bel et bien toujours plus libre. Rendez-vous, soyons prudent, au prochain anniversaire, aKa.

PS : J’en ai profité pour mettre à jour la page « Best of » censée compiler non pas tant le meilleur du blog que des articles dont l’interet est susceptible de dépasser le temps éphémère de l’actualité.

PS2 : À propos de chiffre mille, je rappelle subrepticement l’existence de notre campagne de dons « 1000 10 1 », car là aussi il reste beaucoup à faire si nous ne voulons pas réduire la voilure.

Né en 2001 Framasoft est un réseau de sites et de projets collaboratifs dont l’objectif est de promouvoir et diffuser le logiciel libre et sa culture au plus large public. Avec le temps ce réseau a pris une telle dimension qu’il a eu besoin de s’appuyer sur une structure associative, créée en 2004, pour soutenir son action.

Vous trouverez ci-dessous le rapport moral et financier de l’association pour l’année 2010.

Encore une année riche et bien remplie. Il faut dire qu’avec un annuaire qui a dépassé les 1 500 logiciels (dont une sélection à installer automatiquement), une collection de désormais 10 livres, une clé USB et un DVD aux multiples déclinaisons, un espace de discussion, un autre d’information, un canal vidéo… et même une boutique en ligne, il y a de quoi faire. Sans compter notre présence sur le terrain à une bonne trentaine de manifestations autour du Libre.

La campagne de dons « 1000 10 1 » (1000 donateurs à 10 euros par mois pendant 1 an) n’a pour le moment pas atteint son objectif initial puisque nous n’en sommes qu’à la moitié du chemin. Elle nous assure cependant déjà la pérennisation complète d’un permanent et nous permet d’envisager l’avenir avec si ce n’est sérénité tout du moins un certain optimisme^[1].

Grand merci à tous les donateurs (que la crise n’épargnent souvent pas). Merci également à tous ceux qui nous ont laissés un petit mot sur le site de soutien, nous avons eu l’idée d’en faire une synthèse sous forme de carte heuristique que nous consultons de temps en temps pour nous redonner le moral les jours où le travail se fait trop pesant 😉

Merci enfin et surtout aux animateurs, développeurs, rédacteurs, traducteurs, relecteurs, sous-titreurs, etc., à tous ceux qui de près ou de loin participent avec nous à cette aventure qui voit chaque année le logiciel libre prendre un peu plus de place dans nos ordinateurs et dans nos esprits en témoignant par la pratique que d’autres mondes sont possibles.

Remarque : Framasoft fêtera donc ses 10 ans le 13 novembre prochain (date du dépôt du nom de domaine framasoft.net). Si vous avez des idées originales pour célébrer comme il se doit l’évènement, nous sommes preneurs 😉