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.

Nadia Eghbal a déjà évoqué plusieurs fois les liens entre l’argent et l’open source (si vous avez manqué des épisodes). Elle y revient dans ce chapitre, en insistant sur les questions fondamentales que pose l’argent aux communautés open source ainsi qu’à leurs membres.

Question de nature quasi-philosophique : l’open source peut-il perdre son âme à cause de l’argent ? Question de gouvernance : qui va décider de l’utilisation des fonds ? Et pour finir question éthique et politique : jusqu’à où peut-on, doit-on accepter les requêtes des financeurs ?

La relation compliquée de l’open source avec l’argent

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

L’argent est un sujet tabou dans les projets open source, et ce depuis les premiers jours du mouvement du logiciel libre qui émergea en réponse directe aux pratiques commerciales des logiciels propriétaires. Dans le contexte du mouvement du logiciel libre, l’aversion pour l’argent est tout à fait compréhensible. L’argent est ce qui permettait de commercialiser les logiciels dans les années 1980 et il a fallu des décennies pour revenir sur cet état d’esprit et promouvoir les avantages liés à l’élaboration de logiciels qui soient libres d’utilisation, de distribution et de modification. Même si de nos jours, nous prenons les logiciels libres pour acquis, dans les années 1980, c’était une véritable contre-culture, un état d’esprit révolutionnaire.

Au sein même des communautés open source, il existe une croyance répandue selon laquelle l’argent est de nature à corrompre l’open source. Et en effet, le nombre de projets nés d’un « travail-passion » est assez incroyable. Aujourd’hui, le développement de logiciel est considéré comme un domaine lucratif, dont les écoles de programmation appâtent leurs futurs étudiants avec des promesses de premiers salaires en dollars à six chiffres. Par contraste, il y a quelque chose de pur et d’admirable dans le fait de créer un logiciel simplement pour le plaisir.

D’un point de vue plus pratique, les projets open source se créent traditionnellement autour d’un besoin réel et identifiable. Quelqu’un estime qu’un projet pourrait être mieux fait, décide de le forker, effectue des améliorations, puis les diffuse pour qu’on en fasse usage. Le pragmatisme est au cœur de la culture open source, comme le prouve sa scission stratégique avec le mouvement du logiciel libre à la fin des années 1990. Certains contributeurs open source craignent, peut-être avec raison, que l’argent n’introduise un développement « artificiel » du système, avec des développeurs qui lancent de nouveaux projets simplement pour acquérir des financements, plutôt que pour répondre à un besoin réel.

David Heinemeier Hansson (aussi connu sous le pseudo de DHH), qui a créé le framework populaire Ruby on Rails, mettait en garde en 2013 contre les mélanges entre open source et argent :

Si l’open source est une incroyable force pour la qualité et pour la communauté, c’est précisément parce qu’elle n’a pas été définie en termes de marché. Dans le cadre du marché, la plupart des projets open source n’auraient jamais eu leur chance.

Prenez Ruby on Rails. […] C’est une réalisation colossale pour l’humanité ! Des milliers de gens, collaborant pendant une décennie entière pour produire une structure et un écosystème incroyablement aboutis, disponibles pour tous gratuitement. Prenez une seconde pour méditer sur l’ampleur de cette réussite. Pas seulement pour Rails, évidemment, mais pour de nombreux autres projets open source, encore plus grands, avec une filiation plus longue et encore plus de succès.

C’est en considérant ce fantastique succès, dû aux règles de vie d’une communauté, que nous devrions être extraordinairement prudents avant de laisser les lois du marché corrompre l’écosystème.

Structurellement, le meilleur atout de l’open source : son penchant pour la démocratie, est aussi sa faiblesse. Beaucoup de projets open source ne sont rien de plus qu’un dépôt numérique public où est stocké du code auquel un groupe de gens contribue régulièrement : l’équivalent d’une association officieuse sur un campus universitaire. Il n’y a pas de structure légale et il n’y a pas de propriétaire ou de chef clairement défini. Les  « mainteneurs » ou les contributeurs principaux émergent souvent de facto, en fonction de qui a créé le projet, ou de qui y a investi beaucoup de temps ou d’efforts. Cependant, même dans ces cas-là, dans certains projets on répugne à introduire une hiérarchie favorisant clairement un contributeur par rapport à un autre.

En avril 2008, Jeff Atwood, un développeur .NET bien connu et dont nous avons déjà parlé, a annoncé qu’il donnait 5 000 $ au projet open source : ScrewTurn Wiki. ScrewTurn Wiki est un projet de wiki développé par Dario Solara, un autre développeur .NET, et maintenu par des volontaires. Atwood a dit à Dario que le don était « sans condition » : Solara pouvait utiliser l’argent de la manière qu’il jugerait la plus utile au projet.
Plusieurs mois plus tard, Atwood demanda à Solara comment il avait décidé de dépenser l’argent. Solara lui répondit que l’argent de la donation était « encore intact. Ce n’est pas facile de l’utiliser… Que suggères-tu ? » Atwood a écrit que cette réponse l’avait « terriblement déçu ».

La nature décentralisée du monde open source en a fait ce qu’il est : des logiciels produits de façon participative, que n’importe qui peut élaborer, partager, et améliorer. Mais quand vient le moment de discuter des besoins organisationnels, ou de la viabilité, il peut être difficile de prendre des décisions faisant autorité.

Ces transitions vers une viabilité à long terme peuvent êtres interminables et douloureuses. Un des exemples les plus connus est le noyau Linux, un projet open source utilisé dans de nombreux systèmes d’exploitation à travers le monde, parmi lesquels Android et Chrome OS. Il a été créé en 1991 par Linus Torvalds, un étudiant en informatique .
Au fur et à mesure que le noyau Linux gagnait en popularité, Linus rechignait à discuter de l’organisation du développement du projet, préférant tout gérer tout seul.  L’inquiétude et aussi la colère à l’égard de Torvalds grandirent chez les développeurs du projet, déclenchant de « vraies grosses disputes » selon Torvalds. Le conflit a atteint son apogée en 2002, on évoqua même un possible schisme.

Torvalds attribua ces conflits internes à un manque d’organisation, plutôt qu’à un quelconque problème technique :

Nous avons eu de vraies grosses disputes aux alentours de 2002, quand j’appliquais des correctifs à droite à gauche, et que les choses ne fonctionnaient vraiment pas. C’était très douloureux pour tout le monde, et également beaucoup pour moi. Personne n’aime vraiment les critiques, et il y avait beaucoup de critiques virulentes, et comme ce n’était pas un problème strictement technique, on ne pouvait pas juste montrer un correctif et dire :  « Hé, regardez, ce patch améliore les performances de 15% » ou quoique ce soit de ce genre. Il n’y avait pas de solution technique. La solution a été d’utiliser de meilleurs outils, et d’avoir une organisation du travail qui nous permette de mieux distribuer les tâches.

La Fondation Linux a été créée en 2007 pour aider à protéger et à maintenir Linux et ses projets associés. Torvalds ne pilote pas la Fondation Linux lui-même, il a préféré recevoir un salaire régulier en tant que « Compagnon Linux », et travailler sur ses projets en tant qu’ingénieur.

Malgré le fait que le logiciel open source soit admirablement ancré dans une culture du volontariat et de la collaboration relativement peu touchée par des motivations extérieures, la réalité est que notre économie et notre société, depuis les sociétés multimillionnaires jusqu’aux sites web gouvernementaux, dépendent de l’open source.

Dans l’ensemble, c’est probablement une évolution positive pour la société. Cela signifie que les logiciels ne sont plus limités à un développement privé et propriétaire, comme cela a été le cas pendant des dizaines d’années. Le fait que le gouvernement des États-Unis, ou un réseau social possédant des milliards d’utilisateurs, intègrent des logiciels construits par une communauté, annonce un futur optimiste pour la démocratie.

De plus, de nombreux projets fonctionnent très bien de manière communautaire lorsqu’ils sont d’une des deux tailles extrêmes possibles, c’est-à-dire soit des petits projets qui ne demandent pas de maintenance significative (comme dans l’exemple de Arash Payan et Appirater), soit de très gros projets qui reçoivent un soutien important de la part d’entreprises (comme Linux).

Cependant, beaucoup de projets sont coincés quelque part entre les deux : assez grands pour avoir besoin d’une maintenance significative, mais pas d’une taille suffisante pour que des entreprises déclarent leur offrir un soutien. Ces projets sont ceux dont l’histoire passe inaperçue, ceux dont on ne parle pas. Des deux côtés, on dit aux développeurs de ces projets « moyens » qu’ils sont le problème : du côté des « petits projets », on pense qu’ils devraient simplement mieux s’organiser et du côté des « gros projets », on pense que si leur projet était « assez bon », il aurait déjà reçu l’attention des soutiens institutionnels.

Il existe aussi des intérêts politiques autour de la question du soutien financier qui rendent encore plus difficile la prospection d’une source de financement fiable. On peut imaginer qu’une entreprise seule ne souhaite pas sponsoriser le développement d’un travail qui pourrait également bénéficier à son concurrent, qui lui n’aurait rien payé. Un mécène privé peut exiger des privilèges spécifiques qui menacent la neutralité d’un projet. Par exemple, dans les projets en lien avec la sécurité, le fait d’exiger d’être le seul à qui sont révélées les potentielles failles (c’est-à-dire payer pour être le seul à connaître les failles de sécurité plutôt que de les rendre publiques) est un type de requête controversé. Des gouvernements peuvent également avoir des raisons politiques pour financer le développement d’un projet en particulier, ou pour demander des faveurs spéciales comme une « backdoor » (une porte dérobée, c’est-à-dire un accès secret qui permet d’outrepasser les authentifications de sécurité), même si le projet est utilisé dans le monde entier.

Les récents démêlés légaux entre le FBI et Apple sont un bon révélateur des tensions qui existent entre technologie et gouvernement, au-delà même des projets open source.
Le FBI a, de manière répétée, et à l’aide d’assignations en justice, demandé l’aide d’Apple pour déverrouiller des téléphones afin d’aider à résoudre des enquêtes criminelles. Apple a toujours refusé ces requêtes. En février 2016, le FBI a demandé l’aide d’Apple pour déverrouiller le téléphone d’un des tireurs d’une attaque terroriste récente à San Bernardino, en Californie. Apple a également refusé de les aider, et a publié une lettre sur son site, déclarant :

Tout en croyant que les intentions du FBI sont bonnes, nous pensons qu’il serait mauvais pour le gouvernement de nous forcer à ajouter une « backdoor » dans nos produits. Et finalement, nous avons peur que cette demande mette en danger les libertés que notre gouvernement est censé protéger.

En mars 2016, le FBI a trouvé une tierce partie pour l’aider à déverrouiller l’iPhone et a laissé tomber l’affaire.

Une des plus grandes forces de l’open source est que le code est considéré comme un bien public, et beaucoup de projets prennent la gestion de ces projets au sérieux.  Il est important à titre personnel, pour beaucoup de développeurs de projets, que personne ne puisse prendre seul le contrôle d’une chose que le public utilise et dont il bénéficie. Toutefois, cet engagement à rester neutre a un prix, puisque beaucoup de ressources disponibles pour les développeurs de nos jours (comme les capitaux-risques ou les donations d’entreprises) attendent en contrepartie d’influer sur le projet ou des retours sur investissement.

Le logiciel open source est créé et utilisé de nos jours à une vitesse jamais vue auparavant. Beaucoup de projets open source sont en train d’expérimenter la difficile transition d’une création désintéressée à une infrastructure publique essentielle.
Ces dépendances toujours plus nombreuses signifient que nous avons pour responsabilité partagée de garantir à ces projets le soutien dont ils ont besoin.

Une question épineuse pour les projets libres et open source est leur maintenance à long terme, et bien évidemment les ressources, tant financières qu’humaines, que l’on peut y consacrer. Tel est le sujet qu’aborde ce nouveau chapitre de l’ouvrage de Nadia Eghbal Des routes et des ponts que le groupe Framalang vous traduit semaine après semaine (si vous avez raté les épisodes précédents)

Elle examine ici une série de cas de figures en fonction de l’origine de l’origine projet.

Comment les projets d’infrastructure numérique sont-ils gérés et maintenus ?

TraductionFramalang : Diane, Penguin, Asta, Rozmador, Lumibd, jum-s, goofy, salade, AFS, Théo

Nous avons établi que les infrastructures numériques sont aussi nécessaires à la société moderne que le sont les infrastructures physiques. Bien qu’elles ne soient pas sujettes aux coûts élevés et aux obstacles politiques auxquels sont confrontées ces dernières, leur nature décentralisée les rend cependant plus difficiles à cerner. Sans une autorité centrale, comment les projets open source trouvent-ils les ressources dont ils ont besoin ?

En un mot, la réponse est différente pour chaque projet. Cependant, on peut identifier plusieurs lieux d’où ces projets peuvent  émaner : au sein d’une entreprise, via une startup, de développeurs individuels ou collaborant en communauté.

Au sein d’une entreprise

Parfois, le projet commence au sein d’une entreprise. Voici quelques exemples qui illustrent par quels moyens variés un projet open source peut être soutenu par les ressources d’une entreprise :

Go, le nouveau langage de programmation évoqué précédemment, a été développé au sein de Google en 2007 par les ingénieurs Robert Griesemer, Rob Pike, et Ken Thompson, pour qui la création de Go était une expérimentation. Go est open source et accepte les contributions de la communauté dans son ensemble. Cependant, ses principaux mainteneurs sont employés à plein temps par Google pour travailler sur le langage.

React est une nouvelle bibliothèque JavaScript dont la popularité grandit de jour en jour.
React a été créée par Jordan Walke, ingénieur logiciel chez Facebook, pour un usage interne sur le fil d’actualités Facebook. Un employé d’Instagram (qui est une filiale de Facebook) a également souhaité utiliser React, et finalement, React a été placée en open source, deux ans après son développement initial.
Facebook a dédié une équipe d’ingénieurs à la maintenance du projet, mais React accepte aussi les contributions de la communauté publique des développeurs.

Swift, le langage de programmation utilisé pour iOS, OS X et les autres projets d’Apple, est un exemple de projet qui n’a été placé en open source que récemment. Swift a été développé par Apple en interne pendant quatre ans et publié en tant que langage propriétaire en 2014. Les développeurs pouvaient utiliser Swift pour écrire des programmes pour les appareils d’Apple, mais ne pouvaient pas contribuer au développement du cœur du langage. En 2015, Swift a été rendu open source sous la licence Apache 2.0.

Pour une entreprise, les incitations à maintenir un projet open source sont nombreuses. Ouvrir un projet au public peut signifier moins de travail pour l’entreprise, grâce essentiellement aux améliorations de la collaboration de masse.
Cela stimule la bonne volonté et l’intérêt des développeurs, qui peuvent alors être incités à utiliser d’autres ressources de l’entreprise pour construire leurs projets.

Disposer d’une communauté active de programmeurs crée un vivier de talents à recruter. Et parfois, l’ouverture du code d’un projet aide une entreprise à renforcer sa base d’utilisateurs et sa marque, ou même à l’emporter sur la concurrence. Plus une entreprise peut capter de parts de marché, même à travers des outils qu’elle distribue gratuitement, plus elle devient influente. Ce n’est pas très différent du concept commercial de « produit d’appel ».

Même quand un projet est créé en interne, s’il est open source, alors il peut être librement utilisé ou modifié selon les termes d’une licence libre, et n’est pas considéré comme relevant de la propriété intellectuelle de l’entreprise au sens traditionnel du terme. De nombreux projets d’entreprise utilisent des licences libres standard qui sont considérées comme acceptables par la communauté des développeurs telles que les licences Apache 2.0 ou BSD. Cependant, dans certains cas, les entreprises ajoutent leurs propres clauses. La licence de React, par exemple, comporte une clause additionnelle qui pourrait potentiellement créer des conflits de revendications de brevet avec les utilisateurs de React.

En conséquence, certaines entreprises et individus sont réticents à utiliser React, et cette décision est fréquemment décrite comme un exemple de conflit avec les principes de l’open source.

Via une startup

Certains projets d’infrastructures empruntent la voie traditionnelle de la startup, ce qui inclut des financements en capital-risque. Voici quelques exemples :
Docker, qui est peut-être l’exemple contemporain le plus connu, aide les applications logicielles à fonctionner à l’intérieur d’un conteneur. (Les conteneurs procurent un environnement propre et ordonné pour les applications logicielles, ce qui permet de les faire fonctionner plus facilement partout). Docker est né en tant que projet interne chez dotCloud, une société de Plate-forme en tant que service (ou PaaS, pour  platform as a service en anglais), mais le projet est devenu si populaire que ses fondateurs ont décidé d’en faire la principale activité de l’entreprise. Le projet Docker a été placé en open source en 2013. Docker a collecté 180 millions de dollars, avec une valeur estimée à plus d’1 milliard de dollars.

Leur modèle économique repose sur du support technique, des projets privés et des services. Les revenus de Docker pour l’année 2014 ne dépassaient pas 10 millions de dollars.

Npm est un gestionnaire de paquets sorti en 2010 pour aider les développeurs de Node.js à partager et à gérer leurs projets. Npm a collecté près de 11 millions de dollars de financements depuis 2014 de la part de True Ventures et de Bessemer Ventures, entre autres. Leur modèle économique se concentre sur des fonctionnalités payantes en faveur de la vie privée et de la sécurité.

Meteor est un framework JavaScript publié pour la première fois en 2012. Il a bénéficié d’un programme d’incubation au sein de Y Combinator, un prestigieux accélérateur de startups qui a également été l’incubateur d’entreprises comme AirBnB et Dropbox. À ce jour, Meteor a reçu plus de 30 millions de dollars de financements de la part de firmes comme Andreessen Horowitz ou Matrix Partners. Le modèle économique de Meteor se base sur une plateforme d’entreprise nommée Galaxy, sortie en Octobre 2015, qui permet de faire fonctionner et de gérer les applications Meteor.

L’approche basée sur le capital-risque est relativement nouvelle, et se développe rapidement.
Lightspeed Venture Partners a constaté qu’entre 2010 et 2015, les sociétés de capital-risque ont investi plus de 4 milliards de dollars dans des entreprises open source, soit dix fois plus que sur les cinq années précédentes.

Le recours aux fonds de capital-risque pour soutenir les projets open source a été accueilli avec scepticisme par les développeurs (et même par certains acteurs du capital-risque eux-mêmes), du fait de l’absence de modèles économiques ou de revenus prévisibles pour justifier les estimations. Steve Klabnik, un mainteneur du langage Rust, explique le soudain intérêt des capital-risqueurs pour le financement de l’open source :

« Je suis un investisseur en capital-risque. J’ai besoin qu’un grand nombre d’entreprises existent pour gagner de l’argent… J’ai besoin que les coûts soient bas et les profits élevés. Pour cela, il me faut un écosystème de logiciels open source en bonne santé. Donc je fais quoi? … Les investisseurs en capital-risque sont en train de prendre conscience de tout ça, et ils commencent à investir dans les infrastructures. […]
Par bien des aspects, le matériel open source est un produit d’appel, pour que tu deviennes accro…puis tu l’utilises pour tout, même pour ton code propriétaire. C’est une très bonne stratégie commerciale, mais cela place GitHub au centre de ce nouvel univers. Donc pour des raisons similaires, a16z a besoin que GitHub soit génial, pour servir de tremplin à chacun des écosystèmes open source qui existeront à l’avenir… Et a16z a suffisamment d’argent pour en «gaspiller » en finançant un projet sur lequel ils ne récupéreront pas de bénéfices directs, parce qu’ils sont suffisamment intelligents pour investir une partie de leurs fonds dans le développement de l’écosystème. »

GitHub, créé en 2008, est une plateforme de partage/stockage de code, disponible en mode public ou privé, doté d’un environnement ergonomique. Il héberge de nombreux projets open source populaires et, surtout, il est devenu l’épicentre culturel de la croissance explosive de l’open source (dont nous parlerons plus loin dans ce rapport).
GitHub n’a reçu aucun capital-risque avant 2012, quatre ans après sa création. Avant cette date, GitHub était une entreprise rentable. Depuis 2012, GitHub a reçu au total 350 millions de dollars de financements en capital-risque.

Andreessen Horowitz (alias a16z), la firme d’investissement aux 4 millards de dollars qui a fourni l’essentiel du capital de leur première levée de fonds de 100 millions de dollars, a déclaré qu’il s’agissait là de l’investissement le plus important qu’elle ait jamais fait jusqu’alors.
En d’autres termes, la théorie de Steve Klabnik est que les sociétés de capital-risque qui investissent dans les infrastructures open source promeuvent ces plateformes en tant que « produit d’appel », même quand il n’y a pas de modèle économique viable ou de rentabilité à en tirer, parce que cela permet de faire croître l’ensemble de l’écosystème. Plus GitHub a de ressources, plus l’open source est florissant. Plus l’open source est florissant, et mieux se portent les startups. À lui seul, l’intérêt que portent les sociétés d’investissement à l’open source, particulièrement quand on considère l’absence de véritable retour financier, est une preuve du rôle-clé que joue l’open source dans l’écosystème plus large des startups.
Par ailleurs, il est important de noter que la plateforme GitHub en elle-même n’est pas un projet open source, et n’est donc pas un exemple de capital-risque finançant directement l’open source. GitHub est une plateforme à code propriétaire qui héberge des projets open source. C’est un sujet controversé pour certains contributeurs open source.

Par des personnes ou un groupe de personnes

Enfin, de nombreux projets d’infrastructures numériques sont intégralement développés et maintenus par des développeurs indépendants ou des communautés de développeurs. Voici quelques exemples :

Python, un langage de programmation, a été développé et publié par un informaticien, Guido van Rossum, en 1991.
Van Rossum déclarait qu’il « était à la recherche d’un projet de programmation « passe-temps », qui [le] tiendrait occupé pendant la semaine de Noël. »
Le projet a décollé, et Python est désormais considéré comme l’un des langages de programmation les plus populaires de nos jours.

Van Rossum reste le principal auteur de Python (aussi connu parmi les développeurs sous le nom de « dictateur bienveillant à vie » et il est actuellement employé par Dropbox, dont les logiciels reposent fortement sur Python.

Python est en partie géré par la Python Software Foundation (NdT: Fondation du logiciel Python), créée en 2001, qui bénéficie de nombreux sponsors commerciaux, parmi lesquel Intel, HP et Google.

RubyGems est un gestionnaire de paquets qui facilite la distribution de programmes et de bibliothèques associés au langage de programmation Ruby.
C’est une pièce essentielle de l’infrastructure pour tout développeur Ruby. Parmi les sites web utilisant Ruby, on peut citer par exemple Hulu, AirBnB et Bloomberg. RubyGems a été créé en 2003 et est géré par une communauté de développeurs. Certains travaux de développement sont financés par Ruby Together, une fondation qui accepte les dons d’entreprises et de particuliers.

Twisted, une bibliothèque Python, fut créée en 2002 par un programmeur nommé Glyph Lefkowitz. Depuis lors,  son usage s’est largement répandu auprès d’individus et d’organisations, parmi lesquelles Lucasfilm et la NASA.
Twisted continue d’être géré par un groupe de volontaires. Le projet est soutenu par des dons corporatifs/commerciaux et individuels ; Lefkowitz en reste l’architecte principal et gagne sa vie en proposant ses services de consultant.

Comme le montrent tous ces exemples, les projets open source peuvent provenir de pratiquement n’importe où. Ce qui est en général considéré comme une bonne chose. Cela signifie que les projets utiles ont le plus de chances de réussir, car ils évitent d’une part les effets de mode futiles inhérents aux startups, et d’autre part la bureaucratie propre aux gouvernements. La nature décentralisée de l’infrastructure numérique renforce également les valeurs de démocratie et d’ouverture d’Internet, qui permet en principe à chacun de créer le prochain super projet, qu’il soit une entreprise ou un individu.
D’un autre côté, un grand nombre de projets utiles proviendront de développeurs indépendants qui se trouveront tout à coup à la tête d’un projet à succès, et qui devront prendre des décisions cruciales pour son avenir. Une étude de 2015 menée par l’Université fédérale de Minas Gerai au Brésil a examiné 133 des projets les plus activement utilisés sur Github, parmi les langages de programmation, et a découvert que 64 % d’entre eux, presque les deux tiers, dépendaient pour leur survie d’un ou deux développeurs seulement.

Bien qu’il puisse y avoir une longue traîne de contributeurs occasionnels ou ponctuels pour de nombreux projets, les responsabilités principales de la gestion du projet ne reposent que sur un très petit nombre d’individus.

Coordonner des communautés internationales de contributeurs aux avis arrêtés, tout en gérant les attentes d’entreprises classées au Fortune 500 qui utilisent votre projet, voilà des tâches qui seraient des défis pour n’importe qui. Il est impressionnant de constater combien de projets ont déjà été accomplis de cette manière. Ces tâches sont particulièrement difficiles dans un contexte où les développeurs manquent de modèles clairement établis, mais aussi de soutien institutionnel pour mener ce travail à bien. Au cours d’interviews menées pour ce rapport, beaucoup de développeurs se sont plaints en privé qu’ils n’avaient aucune idée de qui ils pouvaient solliciter pour avoir de l’aide, et qu’ils préféreraient « juste coder ».

Pourquoi continuent-ils à le faire ? La suite de ce rapport se concentrera sur pourquoi et comment les contributeurs de l’open source maintiennent des projets à grande échelle, et sur les raisons pour lesquelles c’est important pour nous tous.

Vous prendrez bien un peu une petite DDoSe de paranoïa ce matin ? Blague à part, j’avais choisi de ne pas vous proposer la traduction de cet article de Bruce Schneier, lorsqu’il est paru au mois de septembre, en pensant qu’il allait un peu loin dans l’énoncé de la menace : en route vers la cyberguerre, pas moins.

L’épisode récent qui a vu hier « tomber » des sites populaires comme Twitter ou eBay et bien d’autres m’incite à y revenir.

Attention toutefois : cette récente attaque n’a probablement rien à voir avec ce que décrit Schneier (voyez par exemple cet article sur la récente « panne »), et par ailleurs les intuitions ou soupçons de ce spécialiste de la cybersécurité ne sont nullement des preuves : il serait trop « facile » d’accuser des puissances présumées hostiles quand de « simples » négligences, des erreurs humaines ou la zombification d’objets connectés sans sécurité peuvent s’avérer responsables.

L’intérêt de cet article est plutôt de montrer la toile de fond de la Toile, sa fragilité surtout dont nous ne prenons véritablement conscience que lorsqu’elle se déchire brutalement, révélant un bric-à-brac high-tech dont on se demande par quel miracle il ne tombe pas en panne de lui-même plus souvent.

Pas grand-chose à faire, conclut de façon pessimiste Bruce Schneier.

Re-décentraliser Internet, peut-être ?

Quelqu’un est en train d’apprendre à faire tomber Internet

par Bruce Schneier

article original sur son blog : Someone Is Learning How to Take Down the Internet

Depuis un ou deux ans, quelqu’un a sondé les défenses des entreprises qui font tourner des composantes critiques d’Internet. Ces sondes prennent la forme d’attaques précisément calibrées destinées à déterminer exactement comment ces entreprises peuvent se défendre, et ce qui serait nécessaire pour les faire tomber. Nous ne savons pas qui fait cela, mais ça ressemble à un grand État-nation. La Chine ou la Russie seraient mes premières suppositions.

Tout d’abord, voyons la toile de fond. Si vous voulez vous emparer d’un réseau sur Internet, la meilleure façon de le faire est avec une attaque (DDoS) distribuée par déni de service. Comme son nom l’indique, il s’agit d’une attaque destinée à empêcher les utilisateurs légitimes d’accéder au site désiré. Ça peut être plus subtil, mais, fondamentalement, cela signifie saturer le site cible de tellement de données qu’il est débordé. Ces attaques ne sont pas nouvelles : les pirates l’utilisent contre des sites qu’ils n’aiment pas, et les criminels l’utilisent comme une méthode d’extorsion. Il y a toute une industrie, avec un arsenal de technologies, consacrée à la défense DDoS. Mais surtout, il est une question de bande passante. Si l’attaquant a un plus gros pipeline pour déverser ses données que le défenseur, c’est l’attaquant qui gagne.

Récemment, quelques-unes des grandes entreprises qui fournissent l’infrastructure de base qui fait fonctionner Internet ont vu une augmentation des attaques DDoS contre elles. De plus, elles ont repéré un certain type d’attaques. Ces attaques sont nettement plus importantes que ce qu’elles sont habituées à voir. Elles durent plus longtemps. Elles sont plus sophistiquées. Et elles ressemblent à des coups de sonde. Une semaine, l’attaque commencera à un niveau particulier d’attaque et progressera lentement avant de cesser. La semaine suivante elle commencera à ce point élevé et continuera. Et ainsi de suite, selon ce même processus, comme si l’attaquant était à la recherche du point exact de fragilité fatale

Les attaques sont également configurées de manière à voir la totalité des défenses de l’entreprise ciblée. Il existe de nombreuses façons de lancer une attaque DDoS. Plus vous utilisez de vecteurs d’attaque simultanément, plus le défenseur doit multiplier ses diverses défenses pour les contrer. Ces entreprises voient davantage d’attaques qui utilisent trois ou quatre vecteurs différents. Cela signifie que les entreprises doivent utiliser tout ce qu’elles ont pour se défendre. Elles ne peuvent pas garder de munitions. Elles sont obligées de démontrer leurs capacités de défense face à l’attaquant.

Il m’est impossible de donner des détails, parce que ces entreprises m’ont parlé sous couvert d’anonymat. Mais tout cela est conforme à ce que Verisign rapporte. Verisign est le registraire pour de nombreux domaines Internet parmi les plus populaires, comme.com et.net. Si Verisign tombe, on assiste à une panne mondiale de tous les sites et adresses électroniques des domaines les plus courants. Chaque trimestre, Verisign publie un rapport sur les tendances DDoS. Bien que sa publication n’ait pas le niveau de détail des propos que m’ont confié des entreprises, les tendances sont les mêmes : « au 2^e trimestre 2016, les attaques n’ont cessé de devenir plus fréquentes, persistantes et complexes »

Il y a plus. Une entreprise m’a parlé d’une variété d’attaques par sondage associées aux attaques DDoS : elles consistent à tester la capacité de manipuler des adresses et des itinéraires Internet, voir combien de temps il faut à la défense pour répondre, et ainsi de suite. Quelqu’un est en train de tester en profondeur les capacités défensives de base des sociétés qui fournissent des services Internet critiques.

Qui pourrait faire cela ? Ça ne ressemble pas à ce que ferait un activiste, un criminel ou un chercheur. Le profilage de l’infrastructure de base est une pratique courante dans l’espionnage et la collecte de renseignements. Ce n’est pas ce que font normalement les entreprises. En outre, la taille et l’échelle de ces sondes – et surtout leur persistance – pointe vers les acteurs étatiques. Tout se passe comme si l’armée électronique d’une nation essayait de calibrer ses armes dans l’éventualité d’une cyberguerre. Cela me rappelle le programme de la guerre froide des États-Unis qui consistait à envoyer des avions à haute altitude au-dessus de l’Union soviétique pour forcer son système de défense aérienne à s’activer, et ainsi cartographier ses capacités.

Pouvons-nous y faire quelque chose ? Pas vraiment. Nous ne savons pas d’où viennent les attaques. Les données que je vois suggèrent la Chine, une évaluation partagée par les gens auxquels j’en ai parlé. Mais d’autre part, il est possible de dissimuler le pays d’origine de ces sortes d’attaques. La NSA, qui exerce plus de surveillance sur la colonne vertébrale d’Internet que tout le reste du monde combiné, a probablement une meilleure idée, mais à moins que les États-Unis ne décident d’en faire un incident diplomatique international, on ne nous dira pas à qui l’attribuer.

Mais c’est ce qui se passe. Et ce que les gens devraient savoir.

• Pour aller plus loin, un article en anglais qui reprend et discute des arguments de Bruce Schneier, sans le contredire toutefois.

Photo de Bruce Schneier par Terry Robinson CC BY-SA 2.0

Si Framasoft contribue régulièrement aux logiciels libres que nous utilisons, nous ne sommes pas pour autant  une association de développeurs. En vérité, tous nos services reposent sur des logiciels développés par d’autres communautés.

Tous…? Non.

Framadate est l’irréductible exception qui confirme la règle. Ce service de sondages dates (et sondages classiques) « à la Doodle » a récemment évolué dans sa version 1, l’occasion de faire le tour des nouvelles fonctionnalités avec son équipe de développement.

Happy Hour : un Framadate plus clair et plus efficace !

L’équipe de dev de Framadate ne manque pas d’humour… Après avoir nommé Open Bar la version 0.9 (que vous utilisiez jusqu’à présent) ; ils ont choisi Happy Hour comme sobriquet de cette version 1. Au delà des paris sur le nom de la prochain mouture (After Party… ? Designated Driver… ?), ce qui nous intéresse vraiment, c’est de découvrir les nouveautés qui sont d’ores et déjà disponibles sur le service le plus utilisé chez Framasoft ! Et elles sont nombreuses…

Des fonctionnalités nouvelles :

• Vous pouvez protéger vos sondages par mot de passe !
• Vous pouvez choisir l’adresse web de votre sondage (du type https://framadate.org/NomDeVotreChoix)
• Vous pouvez modifier un sondage après son expiration
• Vous pouvez choisir des intervalles de dates (par exemple : du lundi 7 au lundi 28 novembre)
• De nombreuses traductions disponibles (qui ont été améliorées) : Allemand, Anglais, Espagnol, Français, Hollandais, Italien… Mais aussi Breton et Occitan.

Celles qui tiennent compte de vos utilisations :

• Désormais, envoyer un commentaire n’effacera plus les votes que vous aviez cliqués mais pas encore validés !
• Le mode « Chaque sondé peut modifier son propre vote » a été amélioré
• Affichage de la date et de l’heure pour les commentaires d’un sondage
• La description d’un sondage tient compte des sauts de ligne
• Une confirmation vous est demandée avant de supprimer une colonne (mais vous pouvez supprimer une colonne vide)
• L’abstention (pas de vote) est prise en compte (et plus comptabilisée comme un « non »)

Celles qui simplifient l’utilisation :

• L’écran de création de sondage a été simplifié (avec un menu « paramètres optionnels »)
• La légende pour les votes (au dessus du tableau des votes) est désormais cachée derrière un bouton
• Un clic suffit pour sélectionner le lien d’un sondage
• Les noms des champs que vous avez à remplir ont été repensés
• Le défilement de la page est plus fluide
• Le format des dates et des heures a encore été amélioré

Celles qui simplifient la vie à ceux qui ont installé Framadate sur leur serveur :

• Un joli fichier check.php pour vérifier la possibilité d’installation
• Un travail sur le service de notifications
• Les mails envoyés par Framadate sont compatibles avec les lecteurs d’emails qui n’aiment pas le HTML (envoi multipart)
• D’ailleurs, le format des emails a été amélioré (utilisation de PHPMailer)
• Nettoyage de code et Smartization

Allez, juste pour le plaisir voici l’écran de création d’un sondage quand on déroule les paramètres optionnels :

3 questions à l’équipe de développement

Partant du principe que « ce sont ceux qui le font qui en parlent le mieux », nous avons décidé de poser 3 questions à Olivier Perez et Antonin Murtin, qui ont pris le relais de JosephK (toujours présent, bien entendu) dans le maintien du développement de Framadate.

Question n°0001 : Bonjour ! L’équipe de développement a bien évolué depuis la reprise du projet… Vous pourriez la présenter au lectorat du Framablog ? Car on aimerait bien savoir comment cela se fait que des gens donnent de leur temps et de leur savoir faire pour améliorer ce projet… et où vous rejoindre pour aider ^^ !

Olivier :

Il y a aujourd’hui 3 personnes qui encadrent Framadate : JosephK, Antonin et Olivier. Notre rôle est d’organiser l’évolution du produit et d’assurer sa stabilité.

Avec Antonin nous sommes passionnés tous deux par le développement depuis pas mal d’années, et le fait que Framadate ait un code source ouvert dans un langage (PHP) très répandu nous a donné envie de le regarder.

Petit à petit, on se dit « le développeur aurait pu faire comme ça plutôt », « j’ai l’impression qu’il y a un bug en regardant ce bout de code » ou bien « j’aimerais bien, en tant qu’utilisateur pouvoir faire telle ou telle chose ». Et comme on sait modifier le code pour emmener le produit vers l’avant, on essaye. C’est aussi simple que ça, aucune peur, juste une envie d’essayer quelque chose.

Au début on a commencé en utilisateur de Framadate, puis cette envie nous a poussés à devenir contributeurs, puis à force d’avoir codé sur les différents modules on est devenu mainteneurs. Aujourd’hui, on lit les propositions des utilisateurs, on relit leurs contributions et on avance sur des sujets qui nous tiennent à cœur. On est vraiment LIBRES, c’est nous qui décidons si on veut bosser sur telle ou telle partie, c’est vraiment très sympa d’avoir autant de marge de manœuvre.

On le dit très souvent, sûrement parce que c’est vrai, mais pour contribuer à Framadate, il suffit d’être utilisateur. Si vous nous remontez des erreurs, ou des envies, c’est encore mieux.

Et si vous voulez coder, c’est surtout pour votre bonheur 😉

Question n°42 :  C’est très excitant d’arriver à la v1 d’un logiciel, surtout quand il est aussi utilisé. Quelles sont les parties/fonctionnalités/particularités de ce projet dont vous êtes le plus fiers ?

Olivier :

Perso, il y a 2 parties que j’ai beaucoup aimé livrer :

• dans l’administration de Framadate, la possibilité de rechercher des sondages. Ça aide énormément lorsqu’on est admin du service.
• l’envoie de mes sondages par mail. C’est un besoin perso, j’en avais marre de perdre les liens vers mes sondages ^^

Antonin :

La gestion de mots de passe sur un sondage ou encore la page « check.php » pour simplifier l’installation étaient vraiment sympa à faire. Mais question fierté, le simple fait de contribuer à ce projet est déjà très chouette !

Question n°1337 : C’est quoi la suite pour Framadate…? Vous avez des défis qu’il vous tarde de conquérir (ou bien des gros morceaux qui vous collent un peu les miquettes :p ?) Et du coup, si on rêve d’améliorations pour Framadate, on vous les propose où ?

Olivier :

On n’est pas assez ouvert 🙂 on ne l’est jamais assez. Mon kiffe serait de proposer une API qui permettrait de faire exactement TOUT, de la création de sondages, du votes, des commentaires, mais aussi de l’administration du service.

J’y vois 2 grands intérêts, la possibilité d’intégrer Framadate à d’autres services, ou la création d’applications tierces qui proposent l’accès à Framadate sur des supports différents (Smartphones, télés, montres, t-shirts ?, etc.)

Plusieurs personnes ont demandé à avoir la possibilité de créer un sondage via leurs propres systèmes informatiques.

Par exemple, une association de Tennis veut organiser des rencontres, elle pourrait générer un sondage qui aiderait 2 opposants à choisir la date et/ou le lieu de la rencontre.

Un collègue m’a avoué utiliser une alternative à Framadate car il n’avait pas l’application smartphone pour organiser ses événements, j’aimerais lui offrir la possibilité de sortir des griffes crochues de l’autre service non pas en développant l’application pour Framadate mais en donnant la possibilité à d’autres de la faire.

Antonin :

Entre les fonctionnalités qui nous manquent dans notre usage quotidien de Framadate et les innombrables propositions d’améliorations venant des utilisateurs, on ne manque pas d’idées !

Mais je pense qu’il y a surtout beaucoup d’améliorations à faire pour faciliter les contributions sur le projet, et ça commence par pas mal de documentation à mettre à jour. Donner plus de transparence et de possibilité de participation sur le pilotage du projet serait un plus !

On commence avec Olivier à réfléchir à un framework plus moderne pour se faciliter la vie sur les améliorations futures, car il y a quelques problématiques qui reviennent mais qu’on ne peut pas résoudre simplement. Mais ce n’est qu’au stade d’embryon de réflexion !

À vous de Dé-Doodliser votre entourage

C’est parfois difficile de se dégoogliser, d’abandonner le confort et les habitudes qu’on a prises dans les services des géants du web. Or, Framadate (en alternative à Doodle) est un des services les plus faciles à adopter : finalement, vous bénéficiez du libre sans trop (vous) y perdre… Et vos ami-e-s ayant une déficience visuelle y gagnent, puisque ce logiciel a été pensé pour être accessible, c’est-à-dire utilisable avec un lecteur d’écran et une navigation au clavier.

De fait, si vos proches ne savent pas comment se dégoogliser, vous pouvez leur proposer de commencer par se Dé-Doodliser 😉

• Utiliser Framadate
• Installer Framadate sur votre serveur
• Participer au développement
• Proposer des améliorations
• Dégooglisons Internet
• Soutenir Framasoft

Imaginez une alternative à tous les favoris que vous confiez à Google Chrome ; qui vous permettrait en même temps de vous y retrouver parmi tous les frama-services que l’on propose…

Le Libre nous a donné les briques pour le faire, alors nous avons retroussé nos manches pour vous présenter MyFrama !

Un del.ico.us fourre-tout numérique pour vos marque-pages et favoris !

Avant toute autre chose, MyFrama est un service de bookmarking (de marque-pages) basé sur le logiciel libre Shaarli (créé par SebSauvage ^^)

Vous voyez tous ces onglets que vous gardez ouverts, parce qu’il y a là une recette que vous n’avez pas encore pris le temps d’essayer, un article de blog à lire ou le site d’un artisan que vous voulez garder… ? Vous vous souvenez de toutes ces fois où vous étiez sur l’ordinateur de Tata Jeannine, et que vous n’avez pas pu retrouver ce site si pratique qui est toujours en favori dans vos marque-pages… ? Si ces deux exemples vous ont arraché un petit sourire, c’est que MyFrama peut vous servir.

Le principe est simple : vous vous créez un compte, vous vous y connectez et vous avez désormais un fourre-tout numérique accessible d’où vous le souhaitez. Dans ce fourre-tout, vous mettez des liens, des adresses web, des URL. Vous pouvez le faire directement en ligne (en les copiant/collant sur votre compte my.framasoft.org), en utilisant le marque-page dynamique (un bouton que vous aurez glissé-déposé sur la barre de favoris de votre navigateur) ou encore depuis une application android (shaarlier, aussi disponible sur le Google PlayStore).

Lorsque vous ajoutez un lien à votre MyFrama, vous pouvez lui donner un titre, une description, des étiquettes (des tags), afin de le retrouver aisément et de vous souvenir de ce dont ça parle. Et voilà, la puissance du logiciel Shaarli permet à MyFrama d’être une alternative à Del.ico.us (pour les vétéran-ne-s du web) et aux favoris de votre compte Google Chrome (le service « Google Favoris »)…

… Mais ce n’est pas tout.

MyFrama : ne perdez plus vos Frama – pads, – dates, – calcs, etc.

Comme nous l’avons expliqué en lançant la 3e année de notre campagne : nous ne souhaitons pas, à court ou moyen terme, créer de « Compte Framasoft » comme vous pourriez avoir un compte Google, ou Apple, ou Microsoft… Ce serait trop compliqué (beaucoup de technologies et langages disparates), trop risqué (cela créerait un seul endroit où « tout peut péter »… ou bien peut être piraté) mais surtout ce serait à l’inverse de ce que nous prônons : re-décentraliser les usages du Web, afin que vos vies numériques ne soient plus jamais enfermées dans des silos de données.

Franchement, entre nous : on ne va pas dégoogliser internet pour le framasoftiser, hein 😉 ? Notre but secret est atteint (pour notre plus grande joie) quand vous quittez fièrement un service Framasoft. Parce que cela veut dire que vous l’avez tellement aimé que vous avez décidé de l’installer pour vous-même (ou d’utiliser le serveur d’un CHATON, d’un ami, de votre asso, collectif, entreprise, etc.). Bref : nous vous souhaitons, à vous et vos données, la plus grande indépendance numérique.

Tout cela, c’est bien joli. Mais pour autant, on ne répond pas à un besoin que, en attendant, vous nous exprimez régulièrement.

« Comment je fais pour retrouver tous les Frama-bidules que j’utilise ??? »

La réponse, c’est le nouveau bouton violet “MyFrama” que vous avez vu apparaître dans la “framanav” la barre de menu qui se trouve en haut de chacun de nos sites web. Lorsque vous êtes sur un Framapad (ou date, ou calc, ou autre…) il vous suffit de cliquer sur ce bouton pour que non seulement ledit pad s’ajoute dans votre compte MyFrama, mais qu’en plus il soit automatiquement classé sous l’étiquette “Pad”, afin que vous puissiez le retrouver (avec tous ses camarades) en un clic…

… Et ce n’est pas tout.

Triez tout Internet si vous le voulez (mais c’est long)

Le logiciel Shaarli ne proposait pas cette option de tri automatique. Quelque chose qui permette de reconnaître qu’il y ait « framapad.org » dans l’adresse web et donc qui attribue à cette adresse l’étiquette “pad”. Qu’à cela ne tienne, JosephK, notre codeur tout terrain, a écouté la grande loi du Yakafokon et passé quelques heures sur son clavier pour développer un nouveau plugin qui permette exactement cela sur Shaarli.

Du coup, ce tri automatique ne sert pas qu’aux services Framasoft ! En effet, vous pouvez tout à fait (et facilement) le paramétrer pour qu’il reconnaisse, étiquette et trie automatiquement les “nextinpact”, “linuxfr”, “numerama” ou “korben” (ceci sont des exemples totalement pris au hasard :p) qui se trouvent dans les liens que vous ajouterez à votre fourre-tout numérique !

Et si vous avez déjà un Shaarli sur votre serveur, pas de soucis : le plugin « tags_advanced » est libre, il vous suffit de l’ajouter à votre instance, voire de l’améliorer si le cœur vous en dit ! Quand on utilise du Libre, on finit toujours par en vouloir plus et donc par apporter sa pierre, sa contribution. C’est ça le cercle vertueux !

Mouais, mais concrètement, je fais comment pour utiliser MyFrama ?

OK, allons-y étape par étape. La première, c’est de se créer son compte ! Vous allez sur my.framasoft.org, et vous cliquez sur « Créer un compte » pour entrer vos informations :

Voilà, votre compte est créé, il vous suffit de taper votre mot de passe une seconde fois pour vous y connecter (par contre ne cochez la case « rester connecté » que si vous êtes sur votre ordinateur perso). Notez que votre nom d’utilisateur est passé en « tout en minuscules » (beaucoup plus facile à retenir ^^)

Vous arrivez donc sur votre compte MyFrama, où nous vous avons pré-rempli quelques filtres et liens pour l’exemple. Regardons cela ensemble :

1) la barre d’outils

Elle vous permet de :

• rechercher un lien parmi vos favoris ;
• régler l’affichage des liens ;
• obtenir le flux RSS de vos liens ;
• gérer vos paramètres ;
• se déconnecter de MyFrama.

2) ajouter des liens

Il y a plusieurs moyens d’ajouter des adresses web dans votre MyFrama.

Le premier est de la copier puis la coller dans la grande barre en haut de de l’accueil (cadre 2).

Le deuxième est d’aller dans vos paramètres (bouton ) pour ajouter un des boutons suivants à votre navigateur préféré :

Le dernier c’est d’utiliser une application sur votre mobile.

Pour Android, vous avez l’application Shaarlier, qui est disponible sur le magasin libre Fdroid et sur le Playstore de Google. Pensez à préciser :

• L’url de votre shaarli : https://my.framasoft.org/u/votrepseudo
• Pseudo : en minuscule
• Mot de passe (sans se tromper ^^)
• Le nom du compte : répétez votre pseudo en minuscule…

Voici le résultat sous vos yeux ébaubis.

3) 4) et 5) lorsque vous ajoutez un lien

Un lien est une adresse web (URL), et afin de la retrouver plus facilement dans votre fourre-tout, vous pouvez en préciser :

• Le titre (cadre 3)
• La description (cadre 4)
• Des étiquettes (les « tags », cadre 5)
• Et si vous voulez qu’il soit privé ou public.

6) des filtres automatiques pour retrouver vos services Framasoft

On vient de partager un Framapad avec vous ? Vous voulez mettre de côté le Framadate de votre prochaine réunion d’équipe ? Pas de soucis : allez sur la page en question, et cliquez sur le bouton violet MyFrama dans la Framanav (la barre tout en haut)

Nous avons pré-réglé des filtres automatiques pour que votre compte MyFrama reconnaisse automatiquement les adresses « framapad.org » ou « framadate.org » etc. et leur attribue une étiquette correspondante. Une fois dans votre compte, il vous suffit de cliquer sur le bon tag (cadre 6) pour y retrouver vos liens !

7) des filtres que vous pouvez modifier à loisir

Bien entendu, vous restez libre de gérer le tri automatique de vos favoris !

Pour cela :

• rendez-vous dans les paramètres des tags (bouton en bas à droite)
• indiquez l’étiquette que vous voulez dans la colonne « Nom » (ici korben)
• et éventuellement le motif que MyFrama doit repérer pour trier automatiquement (ici korben.info)
• déterminez l’ordre avec les flèches de gauche
• cochez/décochez les options à droite (page d’accueil/lien privé)

Et voilà, vous n’avez plus qu’à vous créer votre petit fourre-tout du web avec MyFrama !

Pour aller plus loin :

• Essayer MyFrama
• Application Android
  • Sur le store libre FDroid
  • Sur le Google Play Store
• Participer au code de Shaarli
• Installer Shaarli sur vos serveurs
• Dégooglisons Internet
• Soutenir Framasoft

Ouais ! Cette campagne se passe comme tout grand moment chez Framasoft : avec beaucoup de rires… et même la création d’un micro-micro service qui va changer Internet (rien que ça !)

Petit tour dans les coulisses de la préparation de cet anniversaire…

Les titres auxquels vous avez échappé !

Pour annoncer cette nouvelle campagne, nous avons cherché un titre qui claque ! (au moins autant que celui de cet article… -_-)

Cette année, on a fait dans la sobriété avec « Dégooglisons saison 3 : 30 services alternatifs aux produits de Google & co ». Pour en arriver là, nous avons fait un brainstorming sur un pad… Et le moins qu’on puisse dire, c’est qu’une tempête de cerveaux chez Framasoft, ça éclabousse ! Petit florilège :

Mode « Marathon » avec option « j’ai les foies »

• Dégooglisons Internet : On ne lâche rien ! (ouais… non.)
• Dégooglisons Internet : même pas peur, on va le faire ! (ça se sent qu’on balise ?)
• Eh, chiche : et si on arrivait vraiment à Dégoogliser Internet ? (ou pas : internet c’est grand, surtout vers la fin.)
• La route est longue mais Framasoft tient la distance (on va finir par user ce truc-là)
• Dégooglisons Internet : putain, 2 ans…

Quand on se prend pour des barils de lessive…

• Dégooglisons Internet : deux ans, deux fois plus de confiance (c’est les soldes)
• Framasoft, le dégooglizeur triple action : il nettoie, désinfecte et remplace vos services web pourris (Frama l’dire à tout l’monde !)
• L’An III de la dégooglisation, la troisième lame coupe le Gafam (pour des barbu-e-s, ça la fout mal)

Bonjour, c’est pour un Copyright Infrigement !

• Dégooglisons Internet épisode 3 : la revanche des sites
  • Dégooglisons Internet : la revanche des six sites (six sites l’impératrice, l’impératrice du côté obscur, bien sûr…)
• Dégooglisons Internet : ils sont fous ces gaulois ! (procès des éditions Albert René, et pis il y en a un qui nous a piqué l’idée)
• Framasoft et la dernière croisade (ça fouette, comme titre)
• Dégooglisons Internet an III : le retour du libre (rien à voir avec Star Wars, on parle du Seigneur des anneaux :D)
• Chatons rises
• Dégooglisons Internet : Jusqu’au bout du Monde
• Dégooglisons Internet an III : l’œil du CHATON
• Dégooglisons Internet an III : l’affrontement final
• Dégooglisons Internet an III : Instructeurs de choc
• Dégooglisons Internet an III : Framasoft ne renonce jamais
• Dégooglisons avec Framasoft : saison III, le retour de la vengeance du Libre

Comme il est grand ce petit !

• Dégooglisons Internet : 2 ans et toutes ses dents
• Dégooglisons : il a 2 ans et il sait déjà marcher
• Dégooglisons Internet rentre en 3e, dans la cour des grands
• Un deux trois, Dégooglisons tout ça !
• Miam miam, on va bouffer GAFAM
• Am stram gram, au revoir GAFAM

Et sinon, les chevilles…?

• Remplaçons GAFAM par les Grandes Alternatives Framasoftiennes Aux Monopoles !

Quand Murphy est de la partie…

Bien évidemment, la loi de Murphy s’applique à tout, et donc au mois intense qu’a demandé la préparation de cette campagne…

« Tout ce qui est susceptible de mal tourner tournera nécessairement mal. »

— Edward A. Murphy Jr.

Imaginez un Pouhiou qui apprend le git. Non, y’a pas besoin d’en dire plus pour attirer Murphy : Pouhiou. Git.

Imaginez un service qui se met à planter pile poil une semaine avant sa sortie… Oui, Framatalk, c’est toi qu’on regarde ! Et ne fais pas ton innocent, tu sais très bien que c’est ta mise à jour bien opportune qui t’a (et nous a) sauvé la mise ! Non parce que bien marcher pendant 2 mois de tests et planter une semaine avant la mise en prod, ça se fait pas, hein ? (oui : on fait les gros n’yeux aux services les plus récalcitrants).

Imaginez un administrateur système (celui qui est là pour que les serveurs tiennent debout quand le raz de marée des utilisateurs et utilisatrices arrive) qui, pile poil le jour du lancement de la campagne, au plus fort de la tempête, perd tout accès à Internet. Box qui plante, téléphone qui bloque l’au-delà du data… la totale ! Nous ne remercierons jamais assez la voisine de Framasky qui lui a prêté un code wifi le temps qu’il résolve le problème ^^.

Imaginez enfin une équipe tellement à fond sur les « Frama-ceci » et « Framacela » qu’elle finit un peu par s’emmêler les pinceaux…

Le bingo du troll : le service que même GAFAM n’a pas osé sortir !

Parmi les petites joies que vivent nos bénévoles, il en est une particulière. Les nuées de trolls dont le flux migratoire se pose parfois dans les commentaires du Framablog. Pour se détendre, il faut bien trouver quelque chose. Chez Framasoft, on a Gee, notre illustre dessinateur-docteur-ukuléliste, qui avait déjà inventé le Bingo du Troll. Comme c’est libre, JosephK a décidé d’en faire un service en ligne.

À vous désormais de le tester sur troll.framasoft.org et de vous en emparer dès qu’un troll des montagnes vient étaler ses pollutions intellectuelles sur vos plate-bandes numériques !

On n’a pas peur de le dire, voilà un service qui va changer la face des internets :p !

Aucun chaton n’a été maltraité pour l’écriture de cet article !

« Dites-le avec des chatons », c’est un peu notre maxime depuis que Framasky a bidouillé GiphyMatHooker pour ajouter le support de Cat as a service et ainsi nous permettre de faire des gifs rigolos sur notre groupe de discussion Framateam. Et puis ça tombe bien, parce que les CHATONS (ainsi que MyFrama), on va en parler la semaine prochaine, et c’est un collectif qui nous tient tout particulièrement à cœur, tant il vous permettra de vous « dé-framasoftiser » ^^.

En attendant, au milieu de tous ces éclats de rire, il y a beaucoup de travail, et de passion. Or, 90 % de nos ressources, des sous qui nous permettent de réaliser tout ce que l’on fait (même le bingo du troll ^^), c’est à vos dons qu’on les doit. Cette année encore nous en avons besoin, et nous espérons que, si vous en avez la possibilité, vous répondrez à l’appel.

Et pour tout le soutien que vous nous avez déjà apporté, il n’y a qu’un mot :

Un service d’agenda touche à l’intime. On a beau partager le rendez-vous « déjeuner d’affaires » et mettre en privé celui qui est noté « Dépist.HIV »… notre emploi du temps est malgré tout partagé avec celui à qui on le confie : l’hébergeur.

Google Agenda.

Apple Agenda.

Microsoft Agenda…

Si vous êtes le produit, ce n’est pas gratuit

(ceci est une référence à l’excellente tribune de Laurent Chemla, à lire !)

Comment Siri (Apple™) sait-elle que vous préférez tel restaurant pour vos déjeuners d’affaires ? Comment Cortana (Microsoft™) peut-elle vous proposer d’ajouter ce PowerPoint™ à la réunion que vous êtes en train de planifier ? Comment Google Now™ sait-elle vous prévenir à temps de rejoindre votre voiture afin d’éviter les bouchons pour aller à votre rendez-vous ? (eh oui : les GAFAM accordent les assistants numériques au féminin -_-)

C’est simple : vous leur donnez ces informations et ils ne se privent pas pour les scanner, analyser, indexer. Pour alimenter votre profil personnel, votre graphe social. Les gestionnaires d’emploi du temps sont l’illustration parfaite de ce que recouvre l’expression « données personnelles ». Tout simplement, la traduction de nos vies : nos vies numériques, liées à nos vies physiques. Où nous sommes, à quel moment, pour quoi faire, avec qui…

« Oui, mais c’est tellement pratique…»

En effet. Mais ce confort a un prix : des morceaux de votre vie… et de celle des personnes qui la partagent, par ricochet. Bien sûr, vous pouvez tenter de tricher, de noter une cryptique « chasse au crabe avec Jérôme » pour indiquer l’accompagnement de votre frère à sa séance de chimiothérapie. Mais si lui (ou vous) n’a pas désactivé la géolocalisation de vos téléphones, une fois arrivé-e-s au centre anti-cancer, un GAFAM aura vite fait de recouper les données et de déjouer votre subterfuge. Surtout si vous avez utilisé votre téléphone en mode GPS pour trouver cette fichue clinique…

Sans aller si loin dans l’intime, nous ne souhaitons pas toujours dévoiler les informations de nos plannings collaboratifs : les réunions d’un syndicat, le rétro-planning du projet phare de votre entreprise, le local d’accueil pour victimes de violences conjugales, les horaires d’arrivée et de départ des loupiots à la crèche, etc.

Un planning, ou un agenda, note ce que vous faites de votre vie et avec qui. Il était plus qu’urgent de trouver une alternative éthique offrant une réelle indépendance.

L’histoire du stagiaire qui fit la nique à Google Agenda

Nous connaissions déjà Thomas, vu qu’il est l’un des développeurs principaux de wallabag, le logiciel libre qui fait fonctionner Framabag, notre service de lecture différée d’articles Web. Lorsqu’il nous a proposé de faire son stage de fin d’études chez nous, nous avons tout de suite pensé à ce projet d’agenda libre !

Le besoin était aussi grand que précis : il nous fallait une solution permettant de gérer des agendas privés, confidentiels et publics. Qui offre la possibilité d’inviter (par courriel) une personne sur un des événements qu’on y saisit. Qui soit vraiment facile à installer sur un serveur (sur le petit hébergement mutualisé d’une association, par exemple). Et, enfin, qui se base sur des logiciels libres déjà existants, parce que même si aucun ne remplissait déjà tous nos critères, on n’allait pas non plus réinventer la roue alors qu’on pouvait simplement contribuer à un projet (et une communauté) déjà reconnu(e).

Thomas a donc travaillé d’arrache-pied sur l’application Agenda de ownCloud/NextCloud, en collaboration avec les communautés de ces logiciels, afin qu’on puisse rendre certains plannings publics (si on le veut) et que l’on puisse s’abonner à des agendas existants (par le standard CalDAV). Le moins que l’on puisse dire, c’est que c’est un succès, vu l’accueil que Thomas a reçu lors de sa présentation à la ownCloud Contributors Conference en septembre dernier à Berlin.

Le résultat ? Vous pouvez le tester dès aujourd’hui, il s’appelle Framagenda. La morale de cette histoire ? Au sortir de son stage, Thomas a été engagé en tant que développeur chez Framasoft pour un CDD de six mois, que nous envisageons de pérenniser si tel est son souhait, et si les moyens que vous nous offrez par vos dons nous le permettent.

Framagenda expliqué aux pros du mulot

Ici, nous allons être un peu techniques mais brefs. Si vous préférez un petit tutoriel illustré, n’hésitez pas à passer directement au titre suivant ;).

Framagenda vous permet :

• La création d’un compte (sur une instance Nextcloud, mais avec 5 Mo d’espace disque, ce n’est pas un Framadrive)
• La création et l’édition de multiples agendas (perso, pro, associatif, fêtes familiales, etc.)
• La création d’événements (rendez-vous) dans un agenda :
  • Privé, confidentiel, public…
  • Possibilité de détailler : horaires, lieux, description…
  • Possibilité de faire des rappels
  • Récurrence : possibilité de paramétrer des événements qui se répètent régulièrement
  • Possibilité d’ajouter des participant-e-s par email (avec envoi d’email & d’un fichier .ics en pièce jointe)
• L’intégration avec un carnet de contacts (le calendrier de leurs anniversaires est automatiquement créé \o/)
• L’intégration avec les listes de tâches (une par agenda, mais plus si affinités)
• La synchronisation avec vos appareils (exemple pour Android : via DAVDroid)
  • de vos agendas (avec un choix agenda par agenda)
  • des listes de tâches afférentes (exemple pour Android : avec Open Tasks)
  • de vos contacts (toujours via DAVDroid pour Android)
• Le partage d’un ou plusieurs agendas avec d’autres utilisateurs de Framagenda (par leur pseudo)
• L’abonnement à d’autres agendas/calendriers externes (intégration via ics/WebCal, dont les calendriers des GAFAM : Gmail, Apple, Outlook, etc.)
• La création de liens publics vers chacun de vos agendas :
  • Lien « vue publique », toute simple
  • Lien CalDAV pour les clients (Thunderbird, DAVDroid, etc.)
  • Lien WebDAV pour ajouter dans Google Agenda & Cie
• La possibilité de publier un agenda sur votre site web (code d’intégration iframe)
• L’import ics (dans un nouvel agenda ou dans un agenda existant)
• L’export ics (agenda ou événement)

Framagenda est basé sur l’application Nextcloud 11 et l’application Agenda (1.5), sous licence GNU AGPL v3. Si vous voulez l’installer sur vos serveurs (et gagner en indépendance) notre tutoriel d’installation se trouve ici.

« Expliquez-moi Framagenda en un exemple simple à comprendre »

C’est une demande que nous avons régulièrement, le fameux exemple « simple à comprendre ». C’est aussi un bon exercice d’expliquer comment fonctionne un service et ce qu’il peut faire (à une personne qui n’est pas forcément passionnée par l’informatique). Nous nous y plions donc avec plaisir mais surtout avec cet exemple :

Farida se dégooglise de l’Agenda
(et du carnet de contacts)

Farida n’est pas une libriste de la première heure : juste une personne indépendante à qui ça pose problème de dévoiler sa vie à Google. Agnès, qui coache l’équipe de football de sa fille, lui a parlé de Framagenda : elle décide de se lancer.

Pour cela elle doit se créer un compte. Mouais, OK, mais que va-t-on faire de ses données ? Elle prend cinq minutes pour lire les conditions générales d’utilisation des services Framasoft (il n’en faut pas plus) et cela lui convient. Du coup, elle :

1. se rend donc sur Framagenda.org ;
2. clique sur « S’enregistrer » ;
3. saisit son adresse email pour recevoir un lien de vérification ;
4. crée son compte dans la fenêtre ouverte par le lien de vérification.

Bien. Une fois son compte créé, elle n’a plus qu’à saisir son mot de passe, quelque chose de somme toute classique. C’est bien, dès l’accueil, elle a droit à quelques liens pour savoir comment utiliser son Framagenda : de la documentation, des outils pour le synchroniser sur son mobile…

Elle décide de voir si elle arrive à récupérer son agenda personnel Google. Ce n’est pas hyper intuitif (tiens, Google est moins son ami, sur ce coup !), mais en suivant leur tutoriel, elle arrive à aller dans les paramètres dudit agenda pour obtenir l’export de son calendrier.

Bon il lui faut le dézipper (merci Google, grrrrr), mais ça y est, elle a un fichier .ics ! Ce doit être ça qu’il lui faut…

Dans son Framagenda, il lui suffit de cliquer sur « paramètres » puis sur « importer un agenda » pour qu’elle puisse intégrer son Google Agenda à son agenda personnel (ouf, sauvée, c’est bien le fichier .ics qu’il lui fallait !).

La voilà devant une interface d’agenda comme elle en connaît bien, avec au choix une visualisation de la journée, de la semaine, du mois ; ainsi qu’un agenda personnel (celui dans lequel elle a importé ses rendez-vous qui étaient sur Google) et un « Anniversaire de ses contacts » déjà intégrés.

Bon, c’est pas tout ça, mais samedi à 15 h elle a une réunion avec Agnès, justement, l’entraîneuse de l’équipe de foot de sa fille. Elle crée donc l’événement en cliquant sur l’horaire. Comme elle veut inviter Agnès au rendez-vous, elle clique sur « plus » pour détailler cet événement. Elle rentre l’email d’Agnès, pour que cette dernière soit prévenue du rendez-vous directement dans sa boite mail.

Sandrine trouve que finalement, c’est pas si compliqué que ça, de se dégoogliser. Elle se dit qu’elle devrait aller rencontrer des libristes près de chez elle. Du coup, elle va sur l’Agenda du Libre, LE site qui regroupe les événements publics des libristes en France. Farida voit que dans les flux, en bas, elle peut s’abonner au calendrier des rencontres libristes de sa région.

Bon, c’est bien gentil, mais entre le RSS, le WebCal, l’iCal et autres, elle ne sait que choisir (si ce n’est sa région : l’Occitanie). Heureusement, lorsqu’elle clique sur « nouvel abonnement » dans son Framagenda, elle voit qu’on lui demande une adresse Webcal : d’un clic-droit de la souris, elle copie l’adresse du lien WebCal de l’agenda du libre, et ajoute cet abonnement à son Framagenda.

La voilà désormais avec un agenda bien chargé. C’est bien. Mais ce serait tout de même mieux si elle pouvait l’avoir sur son téléphone. Mince : dans l’image qui l’a accueillie lors de son inscription, il y avait le lien d’un tuto pour synchroniser son agenda avec son téléphone Android, mais elle a oublié de noter ce lien… Pas de soucis, elle le retrouve dans l’aide de Framagenda.

Farida télécharge donc DAVDroid (3€99… si ce n’est pas gratuit c’est bien que c’est elle qui soutient le produit !) et se laisse porter par le tutoriel… Et voilà le travail !

#gallery-1 { margin: auto; } #gallery-1 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 50%; } #gallery-1 img { border: 2px solid #cfcfcf; } #gallery-1 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */

Oh ! Incroyable ! En suivant le tuto d’installation de son agenda sur son téléphone, elle se rend compte qu’elle peut aussi y prendre les contacts qu’elle avait confiés à Google (ses ami-e-s, leurs téléphones, leurs emails et adresses physiques) et les importer dans son Framagenda…

Elle peut même ajouter les listes de tâches liées à chacun de ses agendas en utilisant l’application OpenTasks.

Cela ne lui prend que quelques tapotis de plus, alors elle s’exécute avec plaisir !

#gallery-2 { margin: auto; } #gallery-2 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 50%; } #gallery-2 img { border: 2px solid #cfcfcf; } #gallery-2 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */

Du coup, Farida se demande si elle ne peut pas aller plus loin. Le club de foot de sa fille a besoin d’un agenda partagé pour afficher les entraînements, matchs et événements des différentes équipes.

Elle tente donc de créer un agenda « FootClub des Arceaux » avec un événement récurrent (entraînement tous les samedis matin pour l’équipe de sa fille). Du coup elle va cacher ses autres agendas (en cliquant sur leurs pastilles colorées) pour en voir le résultat :

Elle partage ensuite la tenue de cet agenda avec Agnès, la coach. Il lui suffit de cliquer sur l’icône partager à côté de l’agenda « FootClub des Arceaux » et de rentrer le pseudonyme d’Agnès. Comme Agnès est aussi sur Framagenda, cela se complète automatiquement et fonctionne directement.

Avec cette astuce, Agnès a elle aussi la main sur cet agenda partagé. Cela lui permet de rentrer les entraînements des autres équipes et les prochains matchs. En cherchant à partager le lien public de l’agenda du club de foot, Farida et elle se rendent compte qu’en regardant les paramètres de cet affichage public, elles ont justement un code HTML à intégrer dans le site web du club de foot ! Et voilà leur agenda en ligne !

Si on intègre ce code ici cela donne :

Ni Farida, ni Agnès ne se définissent comme expertes en informatique ou même Geeks. Pourtant, désormais, leurs rendez-vous, contacts et listes de tâches n’appartiennent plus ni à Google (pour Farida) ni à Apple (pour Agnès qui s’est désintoxiquée de l’Iphone). Prochaine étape : voir avec les libristes du coin si elles peuvent installer le même logiciel sur les serveurs du Foot-Club des Arceaux et y importer leurs données Framagenda (on leur a assuré qu’avec Nextcloud, c’est hyper facile).

Cette fois-ci, elles deviendront totalement indépendantes !

Si vous voulez les suivre sur cette route, c’est simple, la voie est libre : testez Framagenda !

Pour aller plus loin :

• Essayer Framagenda
• Le site officiel de Nexcloud (à soutenir !)
• Participer au code de Nextcloud
• Installer Nextcloud sur vos serveurs
• Dégooglisons Internet
• Soutenir Framasoft