Voici, révélé sur son blog par Bradley M. Kuhn (cadre dirigeant à la FSF impliqué dans le projet GNU), l’un des meilleurs ingrédients pour la réussite d’un projet de logiciel libre : rendre son développement public, dès la conception. C’est du moins l’enseignement qu’il retire d’un échange qu’il a eu avec Loïc Dachary, pionnier du logiciel libre, fondateur de la FSF France, d’EUCD.info ou encore de la plateforme d’hébergement de projets libres Gna! ^[1].

Or, si l’idée peut sembler simple, sa réalisation est loin d’être anecdotique et porte à de nombreux débats, comme le synthétise ici Bradley. Mais surtout, ce qui se dessine au travers de cette réflexion, c’est un élément fondamental de la définition de ce qu’est un projet libre, un projet ouvert, un projet pérenne : c’est un projet dont on partage les idées et la conception, en plus des sources. Bradley Kuhn oppose, en filigrane, à cette vision, celle de grands projets (qui se clament bien souvent eux-même « OpenSource ») dont en effet seul le code est publié. Des projets opposant une résistance aux contributions extérieures, et qui peuvent alors presque paradoxalement sembler hermétiques, fermés…

Plusieurs exemples viennent aisément en tête car c’est entre autres l’un des principaux reproches fait à Chromium, la version « OpenSource » du navigateur Google Chrome. Mais LibreOffice, le récent fork d’OpenOffice, illustre parfaitement la conclusion de Bradley, quand la communauté d’un projet de logiciel libre finit par n’avoir d’autre choix que de partir sur un embranchement définitif des fichiers sources pour en ouvrir au public le développement, et plus le code seulement.

Où sont les octets ? ^[2]

Where Are The Bytes?

Bradley M. Kuhn – 11 juin 2010 – EBB.org
(Traduction Framalang : Barbidule, Loquemunaine, Goofy)

Il y a quelques années, j’avais envisagé de me lancer dans un projet de logiciel libre. Il n’a pas vu le jour, mais j’ai appris au passage des choses bonnes à savoir. Quand j’ai pensé à démarrer ce projet, j’ai fait comme à mon habitude : j’ai demandé à quelqu’un qui en savait plus que moi. J’ai donc téléphoné à Loïc Dachary, qui a initié de nombreux projets de logiciels libres, pour lui demander conseil.

Avant même que je puisse ne serait-ce qu’évoquer mon idée, Loïc m’a demandé : « Tu as une URL » ? J’étais abasourdi. Ben, je n’ai pas encore commencé, répondis-je. Bien sûr que si, reprit-il, puisque tu m’en parles c’est que tu as commencé. Le plus important, c’est que tu me dises où sont les octets.

Loïc m’expliqua ensuite que la plupart des projets échouent. Le plus difficile dans un projet de logiciel libre est de le pousser à un stade suffisamment avancé pour qu’il puisse survivre même si ses créateurs initiaux le quittent. Donc, selon la théorie de Loïc, la tâche la plus urgente à accomplir au démarrage d’un projet, c’est de générer ces octets, dans l’espoir qu’ils se fraieront un chemin jusqu’à une équipe de développeurs qui contribueront à maintenir le projet actif.

Mais qu’est-ce qu’il entend par « octets » au juste ? Il veut tout simplement dire que vous devez exposer vos réflexions, votre code, vos projets, vos idées, presque tout en fait sur une adresse publique où tout le monde pourra les voir. Montrez vos octets, montrez-les à chaque fois que vous en créez si peu que ce soit. C’est la seule chance de survie de votre projet de logiciel libre.

Le premier objectif d’un projet de logiciel libre est de rassembler des développeurs. Aucun projet ne peut avoir de succès à long terme sans une base diversifiée de développeurs. Le problème c’est que le travail initial de développement et le planning du projet finissent trop souvent enfermés dans la tête d’un petit noyau de développeurs. C’est dans la nature humaine : comment puis-je passer mon temps à expliquer à chacun ce que je suis en train de faire ? Si je le fais, quand trouverai-je le temps de faire vraiment avancer les choses ? Ceux qui dirigent les projets de logiciels libres savent résister à ce désir naturel et font ce qui peut sembler contre-intuitif : ils exposent leurs octets publiquement, même si cela les ralentit un peu.

Ce processus est d’autant plus nécessaire à l’ère des réseaux. Si quelqu’un veut créer un programme qui remplisse sa mission, son premier outil est le moteur de recherche : il s’agit de savoir si quelqu’un d’autre a déjà fait le boulot. L’avenir de votre projet dépend entièrement du fait que chaque recherche de ce type aide des développeurs à découvrir vos octets.

Début 2001 j’ai demandé à Larry Wall quel était le projet le plus difficile parmi tous ceux sur lesquels il a travaillé. Sa réponse fut immédiate : "quand j’ai développé la première version de Perl5," m’a dit Larry, "j’avais l’impression que je devais coder tout seul et le faire tourner par mes propres moyens". Bien sûr, Larry est un gars tellement doué qu’il peut se permettre de créer à lui tout seul un programme que tout le monde voudra utiliser. Bien que je ne lui aie pas demandé ce qu’il ferait aujourd’hui dans une situation pareille, je devine – particulièrement quand on voit comment le développement de Perl6 est devenu public – qu’il utiliserait plutôt les nouveaux outils en ligne, tels que DVCS, pour montrer plus vite et plus souvent ses octets, et chercher à impliquer plus tôt davantage de développeurs^[3].

Il est vrai que la priorité de la plupart des développeurs est de tout cacher. "On publiera quand ce sera prêt", ou bien – pire encore – "le noyau dur de l’équipe travaille bien ensemble ; rendre le projet public maintenant ne ferait que nous ralentir". En vérité, c’est un mélange dangereux de peur et de narcissisme, exactement la même pulsion que celle qui pousse les développeurs de logiciels non-libres à les conserver propriétaires.

Les développeurs de logiciels libres ont la possibilité de dépasser la réalité fondamentale de tout développement logiciel : le code est mal fichu, et n’est généralement pas terminé. Malgré tout, il est essentiel que la communauté puisse voir ce qu’il se passe à chaque étape, dès le noyau initial du code et au-delà. Quand un projet est perçu comme actif, cela attire les développeurs et donne au projet une chance de succès.

Quand j’étais à la fac, une des équipes d’une classe de génie logiciel s’est complètement plantée. C’est arrivé alors même qu’un des membres de l’équipe avait passé près de la moitié du semestre à coder par lui-même, nuit et jour, sans se soucier des autres membres de l’équipe. Durant l’évaluation finale, le professeur lui fit remarquer : « un développeur de logiciel, ce n’est pas un pilote de chasse ». L’étudiant, ne voyant pas le rapport, plaisanta : « Ouais, je sais, au moins le pilote de chasse, il a un copilote ». En vérité, il ne suffira pas d’une personne ou deux, ou même d’une petite équipe, pour faire aboutir un projet de logiciel libre. Le projet ne marchera que s’il est soutenu par une communauté importante qui évitera tout point individuel de défaillance.

Il n’en reste pas moins que la plupart des projets de logiciels libres sont voués à l’échec. Cependant, il n’y a aucune honte à balancer quelques octets, pour inciter les gens à y jeter un oeil, quitte à laisser tomber si la mayonnaise ne prend pas. Toute la recherche scientifique fonctionne ainsi, et il n’y a pas de raison pour que l’informatique fasse exception. Garder un projet privé, c’est garantir son échec ; le seul intérêt, c’est que vous pouvez dissimuler le fait que vous avez essayé. Comme le disait mon directeur de thèse lorsque je me faisais du souci quant à la réussite de ma recherche : un résultat négatif peut être aussi intéressant qu’un résultat positif. Ce qui est important, c’est d’être sûr que tous les résultats seront publiés et que le public pourra les examiner.

Quand j’ai commencé à parler de cette idée il y a quelques semaines, certains m’ont répondu que les premiers programmes GNU, les logiciels fondateurs de notre communauté ont d’abord été développé en privé. C’est vrai, mais le fait que les développeurs du projet GNU aient procédé de cette façon ne veut pas dire que c’est la bonne. Nous disposons désormais des outils pour faire facilement du développement en public, et nous devrions le faire. De mon point de vue, aujourd’hui nous ne sommes pas vraiment dans l’esprit du logiciel libre tant que le projet, y compris les discussions sur sa conception, les plans et les prototypes, ne sont pas développés publiquement. Le code (quelque soit sa licence) qui n’est que balancé à intervalles plus ou moins réguliers mérite d’être repris par une communauté qui rende son développement public.

Mise à jour (2010-06-12) : J’ai complètement oublié de parler de « The Risks of Distributed Version Control » par Ben Collins-Sussman, qui date de cinq ans maintenant mais qui est toujours d’actualité. Ben fait un constat similaire au mien, et remarque que certaines utilisations de DVCS peuvent avoir les effets que j’encourage les développeurs à éviter. Je pense que DVCS est comme n’importe quel autre outil : il peut être mal utilisé. Il faut éviter de s’en servir comme Ben le signale, et DVCS, lorsqu’il est utilisé correctement, aide dans le processus de développement public de logiciel.

Comme nous l’annoncions il y a tout juste 10 mois, Framasoft a mis en place un service destiné à favoriser la migration, en douceur, des utilisateurs de Windows vers les logiciels libres. Or, comme pour l’annuaire Framasoft dès ses débuts, le succès rencontré par Framapack aujourd’hui nous confirme que les logiciels libres, on les aime d’abord un peu, et puis beaucoup, et même passionnément dans les associations du libre, voire à la folie selon certains.

En quelques mots, Framapack permet d’installer automatiquement sur un ordinateur équipé de Windows toute une collection de logiciels libres.

Ainsi, sur Framapack.org vous pouvez sélectionner parmi les cinquante applications proposées celles qui correspondent à vos besoins, et télécharger d’un clic l’installateur généré pour vous à la volée en fin de sélection. Un nouveau clic vous permet de lancer l’installateur sur la machine à libérer, et ce dernier se chargera alors de télécharger à son tour et d’installer pour vous les dernières versions des logiciels libres que vous avez choisis.

Il est important de préciser que les applications sont installées telles que vous les auriez téléchargées depuis leur site d’origine, sans avoir subit la moindre transformation de notre part^[1].

Or, nous sommes fiers de pouvoir annoncer aujourd’hui que ce projet, dont les maîtres mots sont simplicité et liberté^[2], a rencontré un succès dépassant nos pronostics, en distribuant plus de 100 000 logiciels libres au cours de ses 8 premiers mois d’existence.

Nous ne pouvons que remercier les quelque 5000 visiteurs mensuels de nous accorder ainsi leur confiance.

Enfin, si vous n’y trouvez pas le logiciel que vous cherchez ou si vous avez une idée d’amélioration, n’hésitez pas à nous déposer un petit message sur contact _arobase_ framapack.org. Pour l’heure, nous envisageons d’ajouter dans les prochaines versions du projet un petit morceau de musique libre pour agrémenter le temps de chargement des applications, n’hésitez pas à nous faire part de vos préférences dans les commentaires de cet article.

Ubuntu. Ce simple mot peut à la fois rassembler des milliers de personnes en un week-end et dans le même temps susciter moqueries, trolls, et critiques.

Il n’empêche que cette distribution GNU/Linux, que l’on ne présente plus, a gagné en à peine six ans d’existence une remarquable popularité auprès des nouveaux utilisateurs de systèmes d’exploitation libres. Ils y découvrent une indubitable simplicité d’utilisation et une communauté d’utilisateurs dévoués, accueillants et prêts à consacrer aux nouveau venus le temps nécessaire à leur apprentissage, un temps passé à reconquérir leurs libertés perdues dans les systèmes propriétaires.

Mais tout n’est pas rose avec Ubuntu. Certains voient en effet cette distribution en couleur poil-de-chameau. Pour ses détracteurs, Ubuntu ne mérite pas toute l’attention qu’on lui accorde et fait de l’ombre aux autres projets. De plus, ce système, emballé dans du papier cadeau aux couleurs chaudes se contenterait de singer jusque dans leurs défauts les systèmes propriétaires dont les icônes, la maniabilité à la souris et les effets graphiques séduisent les utilisateurs peu soucieux de technicité. Défauts parmi lesquels, la fin du pilotage intégral du système en ligne de commande pourtant si chère aux administrateurs système, ou encore une approche marketing qui diluerait les valeurs du logiciel libre.

Six ans, c’est presque l’âge de raison, cette période où l’on n’est plus petit, mais pas encore tout à fait grand. C’est peut-être cet âge-là qu’a atteint le projet de Mark Shuttleworth^[1] révélé (une fois de plus) au travers du dernier billet de son fondateur et mécène comme une distribution « clicodrome », accompagnée d’un marketing professionnel et soigné, et destinée à séduire le plus large public possible… Dans ce long billet, spontanément traduit en l’espace de deux heures par une dizaine de contributeurs répondant à l’appel d’Olivier Fraysse (Ubuntu-fr) sur Twitter^[2], Mark Shuttelworth revient sur les motivations qui l’animent au quotidien, et que les milliers de contributeurs faisant la réussite assez inédite d’Ubuntu semblent bien partager.

Introduction rédigée collaborativement par Olive, Poupoul2, JoKot3, Goofy et Siltaar.

Réflexions sur Ubuntu, Canonical et la route vers l’adoption des logiciels libres

Reflections on Ubuntu, Canonical and the march to free software adoption

Mark Shuttleworth – 14 septembre 2010
(Traduction Framalang : @olivierfraysse, @Gordontesos, @ldemay alias Louis Demay, @okhin, @Siltaar, @tshirtman, @winael, @pierretravers, @ricomoro et @framasoft)

Poussé en partie par les critiques concernant la contribution de Canonical au code du noyau Linux ou à l’infrastructure profonde de GNOME, j’ai cherché à savoir si j’avais la conscience tranquille : est-ce que je fais bien mon travail ? Ma manière de le faire convient-elle ? Il est important pour moi de savoir que ce que je fais est utile aux autres et contribue à un monde meilleur. Et dans mon cas, il s’agit d’une redistribution en proportion de la bonne fortune que j’ai pu connaître.

Deux messages que j’ai reçus le mois dernier définissent sans doute ce que je pense apporter à la communauté. Le premier, c’est un mot de remerciement arrivé de Nouvelle-Zélande, quelqu’un constatant qu’Ubuntu 10.04 change vraiment la donne dans son foyer. Pour lui, c’est une sorte de petit miracle de générosité si cet environnement complet, intégré et fonctionnel existe et est maintenu par des milliers de personnes. Quant au deuxième, c’est un contrat d’assistance avec une entreprise pour les dizaines de milliers de poste de travail fonctionnant sous Ubuntu 10.04 qu’elle utilise. Ces deux messages illustrent les piliers jumeaux du projet Ubuntu et de Canonical : apporter au monde entier l’extraordinaire générosité de la communauté du logiciel libre, comme un cadeau, gratuit, léger et cohérent, et le faire de manière pérenne.

Dans le premier cas, celui de Nouvelle-Zélande, quelqu’un apprend à ses enfants comment utiliser un ordinateur dès leur plus jeune âge, se rend compte de tout ce qu’apporte Ubuntu par rapport à Windows, et à quel point il est plus simple d’aborder l’informatique avec Ubuntu lorsqu’on s’adresse à des enfants. Pour cette famille, le fait qu’Ubuntu leur apporte l’univers du logiciel libre en un paquet harmonieux et soigné est extraordinaire, c’est une grande avancée, et ils en sont très reconnaissants.

C’est une histoire que j’espère voir se répéter des millions de fois. Et c’est une histoire qui donne bonne réputation et grande satisfaction, pas qu’à moi, pas qu’à ceux qui consacrent leur passion et leur énergie à Ubuntu, mais aussi à tous ceux qui contribuent au logiciel libre de manière générale. Ubuntu ne mérite pas à elle seule tous les honneurs, elle fait partie d’un écosystème large et complexe, mais sans elle, cette distribution de logiciels libres n’aurait pas la même portée ni la même force. Nous savons tous que le corps du logiciel libre a besoin de nombreux organes, de nombreuses cellules, chacun ayant ses propres priorités et intérêts. Le corps ne peut exister qu’avec chacun d’entre eux. Nous sommes une petite composante d’un vaste ensemble, et c’est un privilège pour nous d’assumer nos responsabilités en tant que distribution. Nous devons donner un point de départ à ceux qui débuteront leur voyage dans le monde du logiciel libre avec Ubuntu, et nous nous efforçons de nous assurer que toutes ces pièces s’accordent bien ensemble.

Ubuntu, et les possibilités qu’elle crée, n’aurait pu naître sans l’extraordinaire communauté Linux, qui elle-même n’existerait pas sans la communauté GNU, et n’aurait pas pris autant d’importance sans les efforts d’entreprises comme IBM et Red Hat. Et ç’aurait été une toute autre histoire sans les gens de Mozilla, ou Netscape avant eux, GNOME et KDE, et Google, ainsi que tout ceux qui contribuent de façons différentes à cet empilement, rendent le tout meilleur. Des dizaines de milliers de personnes qui ne sont pas directement associées à Ubuntu contribuent à rendre cette histoire bien réelle. Beaucoup d’entre eux y travaillent depuis plus d’une décennie… un succès soudain exige un gros travail en amont, et Ubuntu n’est sur le marché que depuis six ans. Ubuntu ne peut donc pas être crédité seul de la satisfaction qu’elle apporte à ses utilisateurs.

Néanmoins, le projet Ubuntu apporte quelque chose d’unique et d’inestimable au logiciel libre : un dévouement total aux utilisateurs et à l’ergonomie, à l’idée que le logiciel libre devrait être « pour tout le monde », d’un point de vue économique et d’un point de vue facilité d’utilisation, et à la volonté de traquer les problèmes qui y nuisent. Je perçois ce dévouement comme un don à ceux qui ont contribué à l’une de ces briques. Si nous pouvons multiplier par dix l’adoption du logiciel libre, nous aurons multiplié la valeur de votre générosité par dix, décuplé l’importance de toutes les heures passées à résoudre un problème ou à créer quelque chose de formidable. Je suis très fier de consacrer autant de temps et d’énergie à Ubuntu. Oui, je pourrais faire beaucoup d’autres choses, mais rien d’après moi qui aurait un tel impact sur le monde.

Je conçois que tout le monde ne perçoive pas les choses de cette façon. Multiplier l’audience de son travail par dix sans apporter de contribution au projet pourrait passer pour du parasitage, ou seulement décupler l’afflux de rapports de bogues. On pourrait avancer que peu importe notre générosité envers les utilisateurs finaux, si les développeurs en amont ne prennent que le code en considération, alors tout apport en dehors du code ne sera pas comptabilisé. Je ne sais pas bien comment y remédier – je n’ai pas créé Ubuntu comme un moyen d’écrire beaucoup de code, car ça ne me paraissait pas être ce dont le monde avait besoin. Le logiciel libre avait besoin d’un moyen pour aller de l’avant, d’amener le code déjà existant à un haut niveau de qualité et de fiabilité. La plupart des éléments du bureau étaient déjà en place – et le code affluait – il n’était simplement pas livré d’une manière qui lui permettrait d’être adopté ailleurs que sur les serveurs, par un public plus large.

Le second e-mail, dont je ne peux citer d’extraits, était en substance un contrat de services confié à Canonical pour aider une entreprise à migrer plus de 20 000 machines de bureau de Windows à Ubuntu. Nous avons récemment signé plusieurs accords d’échelle similaire, et le ryhtme augmente à mesure que la confiance en Ubuntu grandit. Alors que GNU/Linux est depuis longtemps reconnu comme un système de bureau intéressant pour les développeurs motivés et inspirés, il y a un écart entre cette utilisation et le besoin des grosses entreprises. À ma connaissance, aucune autre entreprise ne se consacre entièrement à la production d’un système de bureau libre, et je suis fier que Canonical joue ce rôle. Il me peinerait que tous les efforts de la communauté du logiciel libre ne puissent servir à ces utilisateurs. Il n’y a rien de propriétaire ou de secret dans les postes de travail dont Canonical assure le support dans ces grandes entreprises. Ce qui m’émerveille le plus, c’est que dans les cas de la famille de Nouvelle-Zélande et de cette entreprise, il est question du même code. Voilà à mon sens la véritable promesse du logiciel libre : lorsque je participais moi-même à des projets open-source, j’ai toujours été ravi que mon travail subvienne à mes besoins, mais qu’il soit également utile au plus grand nombre.

Ubuntu n’est qu’une petite partie de cet immense écosystème, mais je suis fier que nous ayons intensifié nos efforts pour relever ces défis. Canonical adopte une approche différente des autres entreprises qui travaillent dans l’univers Linux, non pas comme critique implicite des autres, mais simplement parce que c’est l’ensemble des valeurs que nous défendons. C’est une force pour le logiciel libre qu’un tel nombre d’entreprises différentes poursuivent autant d’objectifs importants.

Au cours des dernières semaines, on a suggéré que l’action de Canonical est égoïste et non dédiée au bénéfice d’une communauté plus large. C’est une critique blessante car la plupart d’entre nous ressentons justement le contraire : notre motivation, c’est tout faire pour servir la cause du logiciel libre, au bénéfice à la fois des utilisateurs finaux et de la communauté qui le produit, et nous sommes convaincus qu’élaborer Ubuntu et travailler pour Canonical sont les meilleures façons d’atteindre ce but. Ces critiques ont provoqué de nombreuses discussions et réflexions chez chacun de nous et chez Canonical. Ce billet s’inscrit dans cette réflexion : j’y témoigne de ce que je ressens lorsque je contribue, et pourquoi je suis fier du travail que j’accomplis chaque jour. Que faisons-nous pour le logiciel libre ? Et que fais-je moi-même ?

Pour commencer, nous le fournissons. Nous réduisons la friction et l’inertie qui empêchent les utilisateurs d’essayer les logiciels libres et de décider eux-mêmes s’ils les aiment suffisamment pour s’y plonger. Aujourd’hui, des centaines de développeurs de logiciels libres, traducteurs, concepteurs, porte-parole, ont l’occasion de prendre part au mouvement, parce qu’il est facile pour eux de faire le premier pas. Et ce n’est pas un travail aisé. Songez aux années d’efforts que nécessite la conception d’un simple installeur pour Linux comme http://www.techdrivein.com/2010/08/…, qui est l’aboutissement d’énormes quantités de travail par plusieurs groupes, mais qui sans Canonical et Ubuntu n’aurait jamais vu le jour.

Des milliers de personnes se contentent de concevoir des logiciels libres pour elles-mêmes, et ce n’est pas un crime. Mais la volonté d’en faire quelque chose que d’autres pourront explorer, utiliser et apprécier doit également être plébiscitée. Et c’est une valeur qui est fortement mise en avant dans la communauté Ubuntu : si vous lisez http://planet.ubuntu.com, vous verrez que l’on se réjouit grandement de compter des *utilisateurs de logiciels libres*. En tant que communauté, c’est pour nous une immense satisfaction de voir que des gens les *utilisent* pour résoudre leurs problèmes quotidiens. C’est plus satisfaisant pour nous que des récits sur l’amélioration de sa rapidité ou l’ajout d’une fonctionnalité. Certes, nous jouons sur les deux tableaux, mais notre communauté mesure davantage l’impact sur le monde que l’impact sur le code. Tous ses membres sont généreux de leur temps et de leur expertise, et il s’agit là de leur récompense. Je suis fier du fait qu’Ubuntu attire des personnes généreuses dans leurs contributions : à leurs yeux, ces contributions prennent de la valeur si elles sont retravaillées par d’autres, et qu’elles n’y perdent pas. C’est pourquoi nous nous réjouissons de l’existence de Kubuntu, Xubuntu, PuppyLinux et Linux Mint. Ces distributions ne marchent pas sur nos plate-bandes, elles se tiennent sur nos épaules, tout comme nous nous tenons sur les épaules de géants. Et c’est une bonne chose. Notre travail a plus de sens et plus de valeur parce que leur travail atteint des utilisateurs que le nôtre seul ne peut pas atteindre.

Quoi d’autre ?

Nous réparons ses défauts, aussi. Prenons par exemple le projet PaperCut, né parce que l’on s’est rendu compte que cette technologie formidable et les efforts que l’on consacre à réaliser un projet aussi complexe que le noyau Linux se trouvent diminués si l’utilisateur moyen n’obtient pas le résultat escompté alors que tout devrait fonctionner sans accroc. Des centaines de Papercuts ont été réparés, dans de nombreuses applications, ce qui ne bénéficie pas qu’à Ubuntu mais aussi à toutes les autres distributions qui intègrent ces applications. Ça n’a rien de simple : songez aux milliers de suggestions à trier, à la coordination des réparations et à leur partage. Grâce aux efforts sans répit d’une équipe nombreuse, nous changeons la donne. Épargner une heure par semaine à des millions d’utilisateurs représente un trésor d’énergie économisée, que l’utilisateur peut alors consacrer à une utilisation plus efficace du logiciel libre. L’équipe Canonical Design est à l’origine du projet Papercuts, mais les plus méritants sont les personnes comme Vish et Sense, qui sont venus gonfler nos rangs. Chaque patch a son importance, sur le poste de travail http://ubuntuserver.wordpress.com/2… et sur le serveur.

À un niveau plus personnel, un élément clé auquel je consacre de l’énergie est la direction, la gouvernance et la structure de la communauté. Aux débuts d’Ubuntu, j’ai passé beaucoup de temps à observer les différentes communautés qui existaient à l’époque, et comment on y gérait les inévitables tensions et divergences qui apparaissent lorsque beaucoup de fortes personnalités collaborent. Nous avons conçu l’idée d’un code de conduite qui assurerait que nos passions pour ces technologies ou ce travail ne prennent pas le dessus sur notre objectif principal : amener des gens de divers horizons à collaborer sur une plateforme commune. Je suis ravi que l’idée se soit étendue à d’autres projets : nous ne voulons pas garder jalousement ces idées, designs ou concepts, ce serait l’inverse de notre objectif premier.

Nous avons mis en place une structure simple : un forum technique et un conseil communautaire. Cette organisation est désormais courante dans beaucoup d’autres projets. Alors qu’Ubuntu se développe, la gouvernance évolue également : des équipes s’occupent de diriger des groupes tels que Kubuntu, les forums et les canaux IRC, fournissent conseils et orientation aux équipes des LoCo^[3], aux modérateurs, aux opérateurs et aux développeurs, qui à leur tour s’efforcent d’atteindre la perfection technique et l’aisance sociale au sein d’une immense communauté mondiale. C’est fantastique. Ceux qui viennent participer à Ubuntu sont en général autant motivés par le désir d’appartenir à une merveilleuse communauté que par celui de résoudre un problème spécifique ou d’alléger la charge de travail d’un groupe.

Avec le temps, certains s’aperçoivent qu’ils ont le don d’aider les autres à être plus productifs : résoudre les conflits d’opinion, assurer l’organisation d’un groupe pour permettre de réaliser ce qu’un individu seul n’aurait pu accomplir. La structure de gouvernance d’Ubuntu leur crée l’opportunité de montrer leur valeur : ils forment le pivot et la structure qui permettent à cette communauté de s’adapter, de rester productive et agréable.

Défendre les valeurs d’un projet comme Ubuntu nécessite une vigilance constante. Lorsqu’on débute et que l’on affiche une ligne directrice précise, on n’attire en général que ceux qui sont sur la même longueur d’ondes que nous. Lorsque le projet gagne en envergure et en visibilité, il attire TOUT LE MONDE, car les gens veulent être là où ça bouge. Ainsi, les valeurs auxquelles on tient peuvent vite finir noyées dans la masse. C’est pourquoi je m’implique autant dans le travail du Conseil Communautaire d’Ubuntu et des équipes communautaires de Canonical. Les deux font preuve d’une grande perspicacité et ne rechignent pas à la tâche, ce qui fait de cette partie de mon travail un vrai plaisir.

Le Conseil Communautaire d’Ubuntu prend très au sérieux sa responsabilité en tant que dépositaire des valeurs des projets communautaires. Le CC est en grande partie composé de personnes qui ne sont pas affiliées à Canonical, mais qui croient que le projet Ubuntu est important pour le logiciel libre dans son ensemble. Jono Bacon, Daniel Holbach, et Jorge Castro, par exemple, sont des professionnels qui savent comment rendre une communauté productive et en faire un lieu de travail agréable.

Quelque chose d’aussi gros que la communauté Ubuntu ne peut être porté à mon seul crédit, ni à aucun autre, mais je suis fier du rôle que j’ai joué, et motivé pour continuer tant que ce sera nécessaire. Depuis quelques années, je me consacre davantage à mettre en avant le rôle du design dans le logiciel libre. Je suis convaincu que l’Open Source produit la meilleure qualité de logiciels qui soit, mais nous devons nous pencher sur l’expérience que nous souhaitons créer pour nos utilisateurs, que ce soit sur le bureau, les netbooks ou les serveurs. Je me suis donc beaucoup employé à encourager diverses communautés – celle d’Ubuntu et d’autres qui travaillent en amont – à réserver un bon accueil à ceux qui portent sur le logiciel libre un regard d’utilisateur final et non celui d’un codeur chevronné. C’est un changement de fond dans les valeurs de l’Open Source, et je ne pourrai l’accomplir seul, mais je suis tout de même fier d’être un défenseur de cette approche, et heureux qu’elle soit de plus en plus partagée.

Des designers travaillaient dans le logiciel libre avant que nous ne donnions cette impulsion. J’espère que l’insistance de Canonical sur l’importance du design leur facilite la tâche, que la communauté au sens large est plus sensible à leurs efforts et plus réceptive à leurs idées. En tout cas, si vous accordez *vraiment* de l’importance au design des logiciels libres, l’équipe de designers de Canonical est faite pour vous !

Je travaille moi aussi sur le design, et j’ai surtout participé à la conception détaillée de Unity, l’interface d’Ubuntu Netbook Edition 10.10. C’est une évolution de l’ancienne interface UNR, qui a surtout pour fonction de montrer que le poste de travail Linux n’a pas à rester bloqué dans les années 90. Nous allons tenter d’élaborer de nouvelles façons efficaces d’utiliser les ordinateurs.

J’ai été ravi de constater la vitesse à laquelle des centaines de projets ont adopté les fonctionnalités de Unity. Leur but est de rendre Linux plus facile d’utilisation et plus élégant. Ce rythme d’adoption permet de mesurer combien nous réduisons la difficulté pour les nouveaux utilisateurs qui découvrent une meilleure façon d’utiliser leur PC.

Si nous nous contentions du design sans nous occuper de la mise en application, on pourrait nous accuser d’attendre que les autres fassent le travail à notre place, alors je suis également fier de diriger une équipe géniale qui se charge de l’implémentation de certains de ces composants clés. Des éléments comme dbusmenu ont prouvé leur utilité pour apporter de la consistance à l’interface des applications GNOME et KDE fonctionnant sous Unity, et j’espère vraiment qu’elles seront adoptées par d’autres projets qui ont besoin de ces mêmes fonctions.

J’aimerais féliciter l’équipe d’ingénieurs pour le soin qu’ils apportent à la qualité et la testabilité, et pour leur désir de fournir aux développeurs des API propres et des documentations complètes permettant leur utilisation optimale. Si vous utilisez le jeu complet d’indicateurs dans Ubuntu 10.10, vous savez à quel point ce travail discret et continu permet d’obtenir un tableau de bord harmonieux et efficace. Nous allons livrer la première release de Utouch, qui continuera d’évoluer afin que GNOME et KDE puissent intégrer facilement les interfaces de mouvements multi-touch.

En plus de donner de mon temps, je soutiens aussi divers projets en les finançant. Injecter de l’argent dans un logiciel libre nécessite de se poser une question cruciale : cette somme serait-elle mieux employée ailleurs ? Il existe beaucoup de façons d’aider les gens : avec 100 000 $, on peut scolariser, vêtir ou nourrir beaucoup de monde. Il me faut donc être sûr que cet argent apporte des bénéfices réels et quantifiables sur la vie des gens. Les messages de remerciement que je reçois chaque semaine pour Ubuntu me confortent dans cette idée. Plus important encore, je constate moi-même l’effet de catalyseur qu’a Ubuntu sur l’ensemble de l’écosystème Open Source – les nouveaux développeurs qui le rejoignent, les nouvelles plateformes qui apparaissent, les créations de nouvelles entreprises et l’arrivée de nouveaux participants – et j’en conclus que le financement que je fournis a un impact significatif.

Quand Ubuntu a été conçu, l’écosystème Linux était dans un sens complètement formé. Nous avions un noyau, GNOME et KDE, Xorg, la Lib C, GCC et tous les autres outils bien connus. Bien sûr, il y avait des failles, des bugs et des feuilles de route pour les combler. Mais il manquait quelque chose, parfois définit comme « marketing », parfois défini comme « orienté utilisateur final ». Je me souviens avoir pensé « c’est ce que je peux apporter ». Donc Ubuntu et Canonical n’ont clairement PAS investi d’efforts dans ce qui fonctionnait déjà, mais dans de nouvelles idées et de nouveaux outils. J’y vois une contribution stimulante à l’écosystème Open Source en général, et je sais que beaucoup partagent cet avis. Ceux qui reprochent à Canonical de ne pas faire ci ou ça ont peut-être raison, mais ces critiques ne tiennent pas compte de tout ce que nous apportons et qui ne figurait pas sur la feuille de route avant notre arrivé. Bien sûr, il y a peu de travaux que nous accomplissons à nous seuls, et peu d’avancées que d’autres ne pourraient réaliser s’ils s’en faisaient un objectif, mais je crois que la passion de la communauté Ubuntu et l’enthousiasme de ses utilisateurs reflètent la nouveauté et l’originalité de ce projet. Ce doit être une source de satisfaction, de fierté et de motivation pour continuer dans cette voie.

Aucun projet particulier ne compte plus que le logiciel libre dans son ensemble. Il est plus important que le noyau Linux, plus important que GNU, plus important que GNOME et KDE, plus qu’Ubuntu, Fedora et Debian. Chacun de ces projets joue un rôle, mais c’est le tout qu’ils forment qui est vraiment en train de changer le monde. À cause des querelles concernant la contribution de chacun au logiciel libre, nous risquons de passer à côté de l’essentiel. Un peu comme une maladie auto-immune, quand le corps commence à s’attaquer lui-même. Par définition, quelqu’un qui se donne du mal pour diffuser le logiciel libre auprès d’un public plus large est dans le même camp que moi, contrairement aux 99% du reste du monde, si je veux penser en termes de camps. J’admire et respecte tout ceux qui consacrent leur énergie à faire avancer la cause du logiciel libre, même si parfois nos avis divergent en ce qui concerne les détails et la manière de procéder.

Par nature décentralisés et collaboratifs, les logiciels libres ont besoin d’être hébergés sur Internet dans des forges qui en assurent leur développement (en offrant de nombreux services comme la gestion des versions ou le suivi des bugs).

SourceForge est certainement la plus célèbre d’entre elles et abrite en son sein plusieurs centaines de milliers de logiciels libres. Google, encore lui, n’est pas en reste avec son Google Code qui accueille de plus en plus d’applications.

Or si ces forges sont bien gratuites et très pratiques (puisque l’on crée et gère son projet en quelques clics), la plupart ne sont paradoxalement pas libres ! Il n’est ainsi pas possible de récupérer le code qui les fait tourner pour installer sa propre forge sur son propre serveur.

On comprend aisément qu’un site comme Facebook garde jalousement son code puisque son objectif est de concentrer au même endroit un maximum d’utilisateurs et surtout pas de les voir partir pour y faire leur petit Facebook personnel dans leur coin. Mais on comprend moins que les développeurs de logiciels libres se retrouvent un peu dans la même situation en acceptant de placer leur code sur des plateformes propriétaires. C’est une question de principe mais aussi de l’avenir incertain d’un code qu’il est alors difficile de déplacer^[1].

C’est tout l’objet de cette mise en garde de notre ami Benjamin Mako Hill dont c’est déjà la quatrième traduction.

Il faut des outils libres pour faire des logiciels libres

Free Software Needs Free Tools

Benjamin Mako Hill – 4 juin 2010 – Blog personnel
(Traduction Framalang : Misc, Cheval boiteux, Siltaar et Goofy)

Au cours des dix dernières années, les développeurs de logiciels libres ont été régulièrement tentés par des outils de développement qui offrent la capacité d’élaborer des logiciels libres de façon plus efficace et productive.

Le seul prix à payer, nous dit-on, est que ces outils eux-mêmes ne sont pas libres ou s’exécutent comme des services réseaux avec du code que nous ne pouvons pas voir, ou lancer nous-mêmes. Dans leurs décisions d’utiliser ces outils et services (tels que BitKeeper, SourceForge, Google Code et GitHub), les développeurs de logiciels libres ont décidé que « la fin justifie les moyens » et ont en quelque sorte vendu la liberté de leur communauté de développeurs et d’utilisateurs. Cette décision d’adopter des outils de développement non libres et privés a entamé notre crédibilité dans la promotion des libertés logicielles et a compromis notre liberté comme celle de nos utilisateurs d’une façon que nous devrions rejeter.

En 2002, Linus Torvalds a annoncé que le noyau Linux utiliserait le systéme de gestion de version distribué BitKeeper. Bien que la décision ait généré beaucoup de craintes et de débats, BitKeeper a permis aux codeurs du noyau de travailler de manière décentralisée avec une efficacité qu’il n’aurait pas été possible d’obtenir avec les outils libres de l’époque. Certains développeurs Linux ont décidé que les bénéfices obtenus justifiaient la perte de liberté des développeurs. Trois ans plus tard, les sceptiques prirent leur revanche quand le proprétaire de BitKeeper, Larry McVoy, a retiré la licence gratuite d’utilisation de plusieurs développeurs importants du noyau, car Andrew Tridgell avait commencé à écrire un remplaçant libre de BitKeeper. Les développeurs furent forcés d’écrire leur propre outil libre pour le remplacer, un projet connu maintenant sous le nom de Git.

Bien sûr, les relations entre logiciels libres et outils non libres vont au-delà du cas de BitKeeper. Le code source des logiciels du service SourceForge était jadis disponible pour ses utilisateurs, mais les auteurs sont revenus à un modèle totalement fermé. Bien que SourceForge soit construit sur des briques libres, les utilisateurs interagissent avec le logiciel uniquement via le Web sur l’unique site SourceForge. Comme les utilisateurs n’ont pas de copie du logiciel de Sourceforge, ils ne peuvent pas en demander le code source. Des projets similaires comme le service Tigris.org de CollabNet, Google Code et GitHub ont tous des buts similaires, et gardent leur code pour eux de la même façon. Les services sont souvent fournis gratuitement et promeuvent le développement de logiciel libre, mais leur dévouement ne s’étend pas aux logiciels qui font tourner leur plateforme de développement. Le code source de chacun de ces services reste privé et non modifiable par les développeurs utilisant ces services.

Ces outils de développement proprietaires posent un dilemme à de nombreux développeurs de logiciels libres. Le but de chacun de ces services est de permettre le succès des logiciels libres et l’obtention de plus de libertés grâce à l’utilisation d’outils plus efficaces. CollabNet, Google et GitHub annoncent chacun qu’ils veulent que le logiciel libre progresse et qu’ils veulent l’aider à avancer. Pour certaines raisons, ces entreprises ont choisi de soutenir les libertés logicielles par des moyens moins en phase avec les éthiques du mouvement que celle qu’ils cherchent à créer. Le résultat est que les développeurs sont dépossédés. La liberté du code logiciel que produisent ces hackers est dépendante d’une restriction inacceptable.

Tout d’abord, l’utilisation d’outils non libres envoie un message irrecevable pour les utilisateurs du logiciel libre produit. « La liberté des logiciels est importante pour vous », semblent dire les développeurs, « mais pas pour nous ». Un tel comportement sape l’efficacité basique du fort engagement éthique au cœur du mouvement du logiciel libre. À tous ceux qui ont déja fait le choix du logiciel libre, nous devons montrer que nous pouvons réussir – et prospérer – en utilisant des logiciels libres. Nous devons soutenir les alternatives libres face aux systèmes propriétaires, comme Savane qui peut remplacer SourceForge ou Google Code, et qui est à la base de GNU Savannah, ou encore Gitorious, pour remplacer GitHub, en les utilisant et en les améliorant dans les domaines où ils peuvent être améliorés.

Deuxièmement, nous devrions comprendre en nous projetant plus en avant que le logiciel que nous produisons n’est libre qu’en fonction des logiciels dont il dépend pour son usage, sa distribution et son évolution.

La licence GNU GPL et le code source ne signifient pas grand-chose pour un utilisateur qui veut modifier un programme sans avoir un accés libre au logiciel requis pour permettre cette modification. Il ne s’agit pas que de mettre les libertés des développeurs dans la balance, mais aussi finalement celles des utilisateurs et de tous les développeurs qui prendront le relais. Ceux qui choisissent d’utiliser des logiciels non libres placent tout le monde à la merci des groupes et des individus qui produisent les logiciels dont ils dépendent.

Tandis que les outils de développement propriétaires peuvent aider les développeurs de logiciels libres à produire de meilleurs logiciels à court terme, le prix à payer est inacceptable. Dans le débat controversé des logiciels privés et des services réseaux, les développeurs de logiciels libres devraient se placer du côté de « l’excès » de liberté. Compromettre nos principes afin d’obtenir plus de liberté est auto-destructeur, instable et au final injuste envers nos utilisateurs et la communauté des développeurs de logiciels libres dans son ensemble.

Tout comme les premiers mainteneurs du projet GNU se sont d’abord concentrés sur la création d’outils libres pour la création de logiciel libre, nous devons nous assurer que nous pouvons produire des logiciels sans entrave et utiliser des outils incontestablement ouverts. Si nous échouons, les logiciels seront indirectement moins libres. Nous devons refuser l’utilisation de logiciels qui ne nous garantissent pas les libertés que nous tentons de donner à nos utilisateurs par le développement de logiciels, et nous devons faire pression en ce sens sur les producteurs de nos outils de développement. Le logiciel libre n’a pas réussi en compromettant nos principes. Nous ne serons pas bien servis d’un point de vue technique, pragmatique ou éthique en compromettant la liberté des outils que nous utilisons pour constuire un monde libre.

Benjamin Mako Hill
Creative Commons By-Sa

Si vous êtes un lecteur assidu du Framablog, vous ne découvrirez probablement pas grand-chose de nouveau dans l’article qui suit. Mais il n’est pas non plus dépourvu d’intérêt, loin s’en faut : il peut être une référence pour tous ceux qui ne connaissent pas bien la différence entre les « hackers » et les « crackers », et ils sont nombreux. On dit souvent, à raison, que cette confusion est de nature médiatique, mais malheureusement ce n’est que partiellement vrai. Avec l’influence que les médias ont pu avoir, il est devenu très courant d’entendre au détour d’une conversation que des « hackers ont piraté (ou que des pirates ont hacké !) tel système ». Et même dans les GUL ! C’est pour cela qu’il m’a paru important de revenir aux sources… Pourquoi hacker n’a rien à voir avec cracker ?

Il me semble d’autant plus dommage de confondre ces deux notions qu’à mon avis le « hacking » a un grand rôle à jouer dans notre société. On a souvent beaucoup de préjugés sur Marx, à cause de la simplification de ses écrits qui a nourri le marxisme (à tel point qu’on appelle les personnes qui étudient directement Marx, les marxiens !). Sans tomber dans le marxisme, le concept de fétichisme de la marchandise me semble particulièrement intéressant pour décrire la situation actuelle : pour faire fonctionner le système économique tel qu’il est, il faut que l’acheteur se réduise à une simple fonction de consommation, sans produire par lui-même, ou pour lui-même. Le fétichisme est à la fois une admiration et une soumission. Il faut acheter des produits de marque. Apple est à mon avis un super exemple : le simple fait de poser une pomme (même pas entière) sur un produit de qualité moyenne, double son prix, et entraîne une myriade de « fans ».

Derrière ce nom barbare du fétichisme de la marchandise, se cache un double phénomène : la sacralisation de la marchandise, engendrant l’aliénation de l’homme à cette dernière. Tout cela pour dire que les produits sont pris pour plus qu’ils ne sont réellement, que par exemple l’homme est prêt à sacrifier beaucoup pour acquérir un objet. Ainsi, le fétichisme de la marchandise permet, à mon sens, de rendre compte de la situation de l’économie actuelle. Une instance économique (le plus souvent les entreprises) produit un objet ou un service qui apparaît cher aux yeux des consommateurs, qui ne doivent l’utiliser que dans le sens pour lequel il a été créé. Encore une fois Apple, cas extrême, permet de rendre compte de la situation : tout ne repose que sur leur image de marque, de haut de gamme, alors que la réalité est terrifiante (Big Brother censure, qualité de l’électronique tout à fait moyenne, matériel et logiciels fermés et propriétaires jusqu’à l’os, bidouillabilité et respect des utilisateurs faibles voire nuls, etc). Là où je veux en venir est que le fétichisme de la marchandise permet de masquer les yeux du consommateur pour que celui-ci se contente d’utiliser servilement ce qu’on lui propose tout en étant satisfait.

Pour entrer plus dans le détail du concept, selon Marx si l’objet est sacralisé c’est parce que le rapport social de production, qui est extérieur au produit, est pris comme faisant partie intégrante de la marchandise. Concrètement, un produit (ou un service) est conçu conformément à des exigences sociales, mais on croit que la valeur sociale attribuée à l’objet vient de l’objet lui-même. On croit que le produit peut exister tout seul, en dehors de tout contexte de société. Par exemple, on peut être fier d’avoir le tout dernier joujou à la mode qui en jette plein les yeux. Dans ce cas, la reconnaissance sociale liée à la possession de l’objet est prise comme étant intégralement due à l’objet que l’on achète. La marchandise est alors élevée à un statut supérieur par une opération certes magique mais inconsciente. L’objet est donc sacralisé, l’aliénation en est ensuite la conséquence : l’objet qui semble posséder des pouvoirs « magiques » doit être protégé, conservé, etc. C’est la soumission qui va de pair avec toute forme de sacré. Et c’est exactement ce qu’essaient de cultiver les entreprises.

De plus, un effet de mode étant très éphémère, l’objet devient vite un fardeau, une vieillerie, car son « pouvoir » secret se tarit. Ce qui, à mon sens, explique la frénésie du schéma achat-consommation-rejet-poubelle de notre système économique, et de nos modes de vie. Le fétichisme de la marchandise vient de là : un rapport social occulté qui entraîne une sacralisation du produit : il faut se contenter pour être heureux d’acheter, de ne pas abîmer, de préserver le produit à l’identique (pour essayer de garder ses vertus magiques que l’on a pu avoir l’impression de palper), de ne pas bidouiller, ni en faire une utilisation trop originale.

Quel est le rapport en fin de compte avec le hacking ? C’est une solution ! Je n’ai fait le rapprochement que très récemment dans une interview de la radio des RMLL de John Lejeune, un animateur du projet Hackable Devices, qui disait que « Tout ce qui est do-it-yourself, bidouille, réappropriation des connaissances, etc, est en train de revenir. L’intérêt est aussi de détourner des fonctions, savoir comment ça marche, comprendre, et désacraliser les objets ». Et effectivement, manipuler, bidouiller, faire par soi-même permet de démystifier le produit, de ne plus être dans une attitude de simple consommation, de ne pas se contenter de vivre en lecture seule^[1]. On voit que ce n’est pas compliqué de créer, qu’à l’intérieur de la boîte noire du dernier joujou à la mode, il n’y a finalement rien d’extraordinaire, ni de magique. Le rapport à la marchandise s’inverse : au lieu de se soumettre à elle, on la maîtrise, la contrôle et l’adapte à ses besoins. Confondre « Hacking » et « Cracking » est donc d’autant plus dommageable que les deux notions recouvrent des modes de vie et des fonctionnements différents. Égaliser les deux notions, c’est faire réprimer le vrai « Hacking » par la société et donc en un sens se voiler la face sur des problèmes existants. Cet article me parait donc un début de solution !

Hacker vaillant, rien d’impossible 😉

Lettre ouverte aux médias sur le mauvais usage du terme « hacker »

Open letter to the media about the misuse of the term "hacker"

Matija Šuklje – 2 août 2010 – Hook’s Humble
(Traduction Framalang : Marting, Siltaar, Loque Humaine et Barbidule)

Ces derniers jours et semaines, on a beaucoup parlé dans les médias slovènes de trois Slovènes qui auraient collaboré au botnet Mariposa. Si vous ne savez pas de quoi il s’agit, vous pouvez lire ce communiqué de presse du FBI. Les médias n’ont cessé d’appeller ces présumés cybercriminels des « hackers ». Comme c’est un abus de langage et que nous sommes nombreux, au sein du groupe Slovène de la Free Software Foundation Europe, à nous définir par ce terme de « hackers », nous avons estimé que quelque chose devait être fait. Nous avons donc écrit et envoyé une lettre ouverte aux médias pour leur expliquer la différence entre « hacker » et « cracker » et les inviter aimablement à employer ces mots correctement à l’avenir. Cette action a été soutenue par plusieurs autres groupes et organismes. La suite correspond au texte entier de la lettre ouverte et à sa traduction.

Madame, Monsieur,

Ces dernières semaines, au sujet de l’action du FBI contre un cybercrime ayant abouti à l’arrestation d’un suspect en Slovénie, le mot « hacker » a été utilisé à plusieurs reprises dans les médias dans un contexte et dans un sens erronés. Ce terme ayant un sens différent pour les experts et pour le public profane, nous avons trouvé opportun de vous le signaler par cette lettre ouverte.

« Hacker » vient du verbe « to hack », « bidouiller ». Cette expression fut forgée au MIT (Massachusetts Institute of Technology) dans les années 50, et signifie résoudre un problème technique d’une manière originale. Dans le jargon de l’informatique, elle est encore utilisée pour désigner des modifications inventives ou originales d’un programme ou d’un système, basées sur une compréhension profonde et dans un but qui n’était pas celui prévu initalement.

Beaucoup d’autorités dans le domaine de l’informatique et de la sécurité entendent le terme « hacking » comme un état d’esprit, la capacité à penser hors des frontières, des façons de faire et des méthodes établies, en essayant de surmonter ces obstacles. Les exemples sont nombreux de « hackers » mettant leurs compétences et leur créativité au service de causes nobles et de l’intérêt général, en faisant en sorte que tout le monde puisse utiliser ou modifier leur programme. Des exemples de tels logiciels libres sont : GNU/Linux, Mozilla Firefox, Mozilla Thunderbird, Google Chromium, OpenOffice.org, SpamAssassin, GIMP, Scribus etc.

Ce furent les médias et l’industrie du film qui utilisèrent ensuite (à tort) le mot « hacker » pour désigner les cybercriminels, ce qui provoqua évidemment une certaine confusion. Ce désordre est encore alimenté par l’évolution de la terminologie, et par les traductions dans la langue slovène.

Pour désigner une personne qui s’introduit dans des systèmes informatiques avec une intention criminelle, il est plus approprié d’utiliser le terme « cracker ». Ce terme désigne les personnes qui contournent des systèmes de sécurité sans autorisation et/ou qui utilisent les TIC (c’est-à-dire habituellement des ordinateurs, des téléphones ou des réseaux) pour s’introduire dans des systèmes et se livrer à des activités illégales ou criminelles — vandalisme, fraudes aux cartes de crédit, usurpation d’identité, piratage, et autres types d’activités illégales.

Ainsi, le dictionnaire slovène d’informatique fait bien la distinction entre le terme « hacker », entendu comme « un passionné d’informatique orienté sur la technique » et le terme « cracker » « qui s’introduit dans les systèmes informatiques avec l’intention d’utiliser des données ou des programmes sans autorisation ».

C’est pourquoi il convient d’utiliser le terme « crackers » pour désigner ces personnes suspectées de crimes informatiques. Au cours des dernières décennies, de nombreuses avancées technologiques furent le fruit du phénomène « hacker » — les ordinateurs personnels, l’Internet, le logiciel libre — il serait donc abusif d’assimiler hackers et criminels. Cela équivaudrait à qualifier tous les pharmaciens d’empoisonneurs.

Nous comprenons que la confusion actuelle existe depuis assez longtemps et c’est d’ailleurs pour cela que nous pensons qu’il est largement temps de clarifier ce point ensemble. Aussi nous vous demandons, s’il vous plaît, de bien vouloir à l’avenir utiliser le terme approprié.

Bien cordialement,

Matija Šuklje : coordinateur du groupe slovène de la FSFE^[2]

Co-signataires : Andrej Kositer (président du COKS^[3]), Simon Delakorda, (directeur du INePA^[4]), Andrej Vernekar (président du LUGOS^[5]), Klemen Robnik (de Kiberpipa/Cyberpipe^[6]) et Ljudmila^[7].

Les mouvements alternatifs d’émancipation portés par le numérique, dont le logiciel libre fait partie, ont été récupérés et domestiqués par le système et sa force marketing sous la bannière et le vocable du « web 2.0 ».

Un web 2.0 qui présente de plus l’avantage de favoriser l’institution d’une sorte de totalitarisme global décentralisé avec notre complicité et toutes les traces personnelles, permanentes et continues, que nous laissons, le plus souvent volontairement, dans les nuages d’Internet.

Avec l’avènement du web 2.0, non seulement vous voyez s’éloigner le rêve d’une autre société mais vous renforcez le contrôle et la surveillance de l’actuelle ! Difficile de faire pire en quelque sorte…

Telle n’est pas mon opinion mais mon propre (et donc faillible) résumé d’un article parcouru récemment sur Indymedia dont le titre exact est “Become the media!” : de l’hacktivisme au web 2.0.

Attention, c’est dense, politisé et plein de références à des auteurs qui vous seront peut-être peu familiers si vous ne baignez pas dans une certaine culture intellectuelle « de gauche » (cf Félix Guattari, Jello Biafra, Walter Benjamin, Jean Baudrillard, Gilles Deleuze, Michel de Certeau, Michel Maffesoli).

Nous en avons reproduit la fin ci-dessous pour vous donner (ou non) l’envie de le parcourir dans son intégralité^[1].

Je ne vous cache pas qu’il m’intéresse d’avoir vos réactions dans les commentaires. En espérant que les uns et les autres sauront s’écouter et échanger en toute sérénité sur un sujet, je le reconnais bien volontiers, un peu glissant. Un petit débat courtois et non un gros troll poilu pour le dire autrement 😉

Pour ce qui me concerne, je ne partage pas la radicalité et le pessimisme du propos et j’ai justement l’impression que les actions que nous menons participent modestement à échapper à ce piège. Mais il est vrai que lorsque le « logiciel libre » devient « open source », il prend le risque de perdre en route tout ce qui fait sa substantifique moelle.

“Become the media!” : de l’hacktivisme au web 2.0 (extraits)

URL d’origine du document

Dr No – 26 juillet 2010 – Indymedia Nantes

(…)

Quoiqu’il en soit, ce dont il s’agit là encore finalement, avec cette « réappropriation », ce « devenir-media » de la masse et cette « démocratisation » des dispositifs d’informations et de communication, c’est du déploiement toujours plus important d’un macro-système technique, d’un maillage global comme dispositif de socialisation forcée par dressage à la discipline inconsciente d’un code, c’est-à-dire – à l’instar du système électoral ou de la consommation – d’imposition de règles du jeu (ici de la communication) et d’intériorisation de ces règles comme subtil mode de mobilisation et de contrôle social. Indépendamment des contenus qui n’en sont que l’alibi, le médium – le code, le modèle, la forme, le canal, le dispositif, la technique – est le message, il influe directement sur nos modes de perception sensibles, modifie nos rapports à l’espace et au temps et par conséquent nos modes d’être-au-monde. En l’occurrence, « ce qui est médiatisé, ce n’est pas ce qui passe par la presse, la TV, la radio : c’est ce qui est ressaisi par la forme/signe, articulé en modèles, régi par le code. » La réappropriation du code ne jouant donc là au final que comme « reproduction élargie du système » sous couvert de nouvelles modalités. C’est pourquoi il ne faut jamais sous-estimer la capacité de ce système à intégrer les innovations (même et peut-être surtout si elles se veulent « révolutionnaires ») a fortiori si celui-ci fonctionne sur les principes d’interaction, de réversibilité, de participation et de feed-back comme c’est d’ailleurs le cas aujourd’hui beaucoup plus qu’hier.

« l’éthique hacker », l’utopie cyberpunk et les expérimentations cyberculturelles, les trouvailles de « l’hacktivisme » électronique et de « l’Internet militant », du mouvement des logiciels libres, l’Open Source, l’Open Publishing, le P2P, le Wi-Fi, les média-tactiques alternatives, collaboratives et communautaires elles-mêmes, c’est-à-dire en somme toutes ces « pratiques moléculaires alternatives » que Félix Guattari appelaient de ses vœux pour renverser le pouvoir grandissant de l’ingénierie logicielle et les nouvelles modalités de la « société de contrôle » ont pour la plupart, dans ce qu’elles avaient d’original et novateur, été absorbées et recyclées par celle-ci et les industriels pour donner naissance à ce que l’on peut appeler les nouveaux « agencements post-médiatiques » du web 2.0.

C’est-à-dire toutes ces nouvelles applications de l’Internet « participatif » et « collaboratif » basé sur le principe du « contenu généré par les utilisateurs », ce qui précisément, on l’aura remarqué, était bien l’idée de « l’open publishing » (publication libre) proposé par le réseau international des sites Indymedia dans l’esprit du partage horizontal de l’information, de la participation et de la collaboration en vue de favoriser l’auto-organisation des groupes et des individus constitués en « machines de guerre » contre l’axiomatique mondiale exprimée par les Etats.

Un Web 2.0 dit « participatif » et « collaboratif » donc, où effectivement, convergence numérique aidant, la masse devient son propre média (MySpace, Facebook, YouTube, Twitter, Wikis et autres blogs), engendrant à leur tour de nouveaux usages qui inspirent également de nouveaux produits, services et dispositifs reconfigurant de fond en comble notre rapport au monde et nos relations sociales, tout en développant de nouveaux marchés ainsi que de nouveaux « business models » (management 2.0, marketing 2.0, « gratuité », « co-création de valeur », etc.) qui incarnent des changements de paradigmes économiques par où se joue la mutation du capitalisme. Car en effet, force est de constater que les principes du « participatif », du « collaboratif », de la « coopération » et du « partage » sont aujourd’hui devenus les principaux éléments d’un nouvel esprit du capitalisme de l’ère 2.0 fonctionnant par « boucles de récupération » et recyclage écosystémique des singularités comme moteur et dynamique de l’innovation (technologique, économique, culturelle, sociale, etc.). C’est en quelque sorte ce qui se présente plus communément aujourd’hui sous l’appellation d’ « innovation ascendante » qui consiste justement pour les entreprises et/ou les institutions à observer, et même à favoriser, les pratiques de réappropriation, investissement, exploration, détournement, expérimentation par les usagers/consommateurs des produits, services et technologies dans le but de réintégrer les éventuelles micro-inventions et les « usages innovants » dans leur propre processus de création et développement industriel, commercial, technocratique, etc.

C’est une dynamique qui s’appuie sur la compréhension des comportements que permet en l’occurrence la « sociologie des usages » et notamment les travaux de Michel de Certeau sur ce qui constitue en quelque sorte les « arts de faire avec » . Recherche qui se voulait un travail de compréhension et en premier lieu de mise en valeur des arts de vivre la société de consommation, par élaboration de « lignes de fuites » (Deleuze et Guattari) pourrait-on dire, c’est-à-dire plus particulièrement des ruses subtiles, des tactiques de résistance, de contournements, détournement, réappropriation, braconnage, dissimulation, en somme toute la multitude de pratiques inventives et créatives qui se disséminent dans la banalité du quotidien des usagers/consommateurs et que la rationalité occidentale, selon les mots de l’auteur, aurait eu trop tendance à occulter. Et on pourrait voir dans ce travail la saisie de l’essence même de la notion anglo-saxonne de « hacking », de son esprit ou de son éthique élargie à l’ensemble de la société. Quoiqu’il en soit, on le voit bien, ce dont il s’agit avec « l’innovation ascendante » mise en œuvre dans le nouveau paradigme économique des entreprises les plus à l’avant-garde du capitalisme c’est de capter/capturer la puissance créatrice de la socialité de base, l’énergie et le vitalisme qui émergent de ce que Michel Maffesoli appelle la « centralité souterraine ». Dans le même ordre d’idée se développe aujourd’hui dans les milieux du marketing et du management, par le biais des différentes plateformes multimédias de la société en réseaux, le « crowdsourcing » (approvisionnement par la foule) qui consiste pour une entreprise là encore à faire « participer » et « collaborer » directement la foule des internautes comme usagers/consommateurs à la recherche et au développement de nouveaux produits et services, à apporter des améliorations, etc..

Enfin, toutes choses mettant en œuvre un processus communicationnel global s’appuyant sur des dispositifs de « feed-back » et des mécanismes circulaires tout à fait caractéristiques des boucles causales rétroactives qui furent à la base de la modélisation des systèmes cybernétiques qui simulent les lois de la nature et dont la finalité, rappelons-le, est le Contrôle par auto-régulation comme mode de management et de gouvernance.

Des systèmes de contrôle et de gouvernance de l’ère des machines de « troisième espèce » qui se déploient sur toute l’étendue de la vie quotidienne par le biais de la globalisation d’un méga-réseau engagé dans un processus matriciel. Une « matrice communicationnelle », un maillage systémique à vocation ubiquitaire qui tend par ailleurs à rendre obsolètes les modèles panoptiques de surveillance hyper-centralisés et transcendants de type orwellien qu’incarne la fameuse figure de « Big Brother ». Car en effet, ce à quoi on a de plus en plus nettement affaire aujourd’hui c’est à un processus de capillarisation du Contrôle en quelque sorte et qui tend par là à devenir totalement immanent.

Comme le remarquait déjà pertinemment Jean Baudrillard au début des années 70 « même à long terme, l’impossibilité des mégasystèmes policiers signifie simplement que les systèmes actuels intègrent en eux-mêmes, par le feed-back et l’autorégulation, ces métasystèmes de contrôle désormais inutiles. Ils savent introduire ce qui les nie comme variables supplémentaires. (..) Ils ne cessent donc pas d’être totalitaires : ils réalisent en quelque sorte l’idéal de ce que l’on peut appeler un totalitarisme décentralisé. » Par ailleurs, dans son texte annonçant l’avènement d’une "subjectivité post-médiatique" Félix Guattari rappelait que toutes les anciennes formations de pouvoir et leurs façon de modéliser le monde avaient été déterritorialisées. C’est ainsi, disait-il, que « la monnaie, l’identité, le contrôle social passent sous l’égide de la carte à puce. » Car en effet, ce qui se joue aujourd’hui avec tout ce maillage systémique planétaire, ce déploiement du méga-réseau matriciel à vocation ubiquitaire, c’est un processus de globalisation des « sociétés de Contrôle » , fluides, ouvertes, modulaires, multipolaires et à géométrie variable comme installation d’un nouveau régime de domination qui remplacent peu à peu les « sociétés disciplinaires » (Foucault) avec la crise généralisée des milieux d’enfermement en système clos (familles, écoles, armée, usines, prisons, hôpitaux, etc.) ainsi que l’avait bien vu à la même époque Gilles Deleuze, et où, entre autres choses, les individus deviennent peu à peu des entités « dividuelles » encodées comme multiplicité de données dans un macro-système d’information. « Ce sont les sociétés de contrôle qui sont en train de remplacer les sociétés disciplinaires. (..) On ne se trouve plus devant le couple masse-individu. Les individus sont devenus des « dividuels », et les masses, des échantillons, des données, des marchés ou des « banques ». (..) les sociétés de contrôle opèrent par machines de troisième espèce, machines informatiques et ordinateurs (..). Ce n’est pas une évolution technologique sans être plus profondément une mutation du capitalisme. »

Mutation post-industrielle du capitalisme de plus en plus flexible, flottant, immatériel, sémiotique et cognitif, où le « service de vente » devient le centre ou l’âme de « l’entreprise » qui a remplacé « l’usine » de production désormais démantelée, automatisée, externalisée et assez souvent reléguée en périphérie du tiers-monde à l’instar des grandes enseignes multinationales qui se concentrent sur les logiques de Communication et le développement médiatique, si ce n’est psycho-technique, de leur « image de marque ». « On nous apprend que les entreprises ont une âme, ce qui est bien la nouvelle la plus terrifiante du monde. Le marketing est maintenant l’instrument du contrôle social, et forme la race impudente de nos maîtres » affirmera ainsi sans détours Gilles Deleuze. De même, « il n’y a pas besoin de science-fiction pour concevoir un mécanisme de contrôle qui donne à chaque instant la position d’un élément en milieu ouvert, animal dans une réserve, homme dans une entreprise (collier électronique). Félix Guattari imaginait une ville où chacun pouvait quitter son appartement, sa rue, son quartier, grâce à sa carte électronique (dividuelle) qui faisait lever telle ou telle barrière ; mais aussi bien la carte pouvait être recrachée tel jour, ou entre telles heures ; ce qui compte n’est pas la barrière, mais l’ordinateur qui repère la position de chacun, licite ou illicite, et opère une modulation universelle. »

Vision qui prend d’autant plus d’importance aujourd’hui avec l’informatisation généralisée de la société, l’injonction à la mobilité, l’hyperconnectivité et les projets de dissémination des technologies numériques et autres puces communicantes (informatique ubiquitaire/ubimedia) dans tout l’environnement physique de nos métropoles postmodernes où peut désormais s’opérer de façon massive, par la grâce de l’ingénierie logicielle, la traçabilité, la géolocalisation, le fichage et le profilage des « dividus » dispersés dans les flux et les réseaux, dans et par lesquels se dispensent désormais leur être-au-monde fantomatique sous « le règne de la Technique planétaire »

Il est trop rare que nous évoquions le système d’exploitation libre BSD (Berkeley Software Distribution). La dernière fois il s’agissait d’un billet consacré à l’histoire d’Unix, à l’occasion de son quarantième anniversaire.

Et c’est dommage parce que cela finit par laisser à penser qu’il n’existe que GNU/Linux dans le monde des OS libres. Or il y a aussi la famille BSD (FreeBSD, OpenBSD, NetBSD…), louée pour la propreté de son code, sa sécurité, sa fiabilité et sa stabilité, que l’on compare souvent à son « cousin » GNU/Linux justement, histoire de l’appréhender plus facilement et de mieux comprendre ce qui fait sa spécificité.

Si on le rencontre peu souvent sur ce blog, c’est aussi parce qu’il serait difficile de le conseiller de prime abord à un utilisateur lambda pour sa machine personnelle, surtout si ce dernier provient de l’univers Windows. La matériel est moins bien et moins vite supporté, il y a moins d’applications disponibles et il se destine surtout au monde des serveurs. Mais rien ne dit qu’un jour, vous aussi…

Ce billet s’adresse donc à tous les curieux et plus particulièrement à ceux qui se sont déjà frottés de près ou de loin à une distributions GNU/Linux. Il s’adresse également aux experts et aux aficionados de BSD qui sont cordialement invités à témoigner, compléter et surtout critiquer l’article et ses arguments dans les commentaires.

D’autant plus que l’auteur propose en conclusion une classification des OS en fonction de la maîtrise de leurs utilisateurs qui ne fera sans doute pas l’unanimité !

Remarque 1 : Le personnage ci-dessus s’appelle Beastie (bi-esse-di), c’est la mascotte BSD et il représente un charmant petit démon, oups, je veux dire daemon.

Remarque 2 : Il y a du BSD dans Mac OS X, comme aiment à la rappeler certains Macfans et les geeks qui, ayant adopté cet OS, « culpabilisent » moins ainsi 😉

10 différences entre Linux et BSD

10 differences between Linux and BSD

Jack Wallen – 4 août 2010 – TechRepublic
(Traduction Framalang : Loque huaine et Mathieu)

Malgré une tendance courante à minimiser leurs différences, Linux et BSD ont un certain nombre de caractéristiques qui les distinguent. Jack Wallen attire l’attention sur plusieurs différences importantes.

Combien de fois avez-vous déjà entendu les gens mettre Linux et n’importe quel BSD dans le même panier ? Bien sûr, il existe un grand nombre de similarités entre Linux et BSD : ils sont tous les deux basés sur UNIX. Dans l’ensemble, les deux systèmes sont développés par des organisations à but non lucratif. Et je dois dire que Linux comme les variantes BSD ont un but commun : créer le plus utile et le plus fiable des systèmes d’exploitation qui soit.

Toutefois, il y a aussi des différences significatives. Et quand les gens n’y font pas attention, c’est toute la communauté BSD qui frissonne de colère. Aussi, j’ai pensé que je pourrais aider mes frères de BSD et expliquer un peu en quoi Linux est différent de BSD.

1. Licences

Comme nous le savons tous, le système d’exploitation Linux est sous licence GPL. Cette licence est utilisée pour empêcher l’inclusion de logiciels aux sources fermées et pour assurer la disponibilité du code source. La GPL essaye d’empêcher la distribution de sources sous forme de binaires seulement.

La Licence BSD est bien moins restrictive et autorise même la distribution de source sous forme de binaires. La principale différence peut cependant être vue de la façon suivante : la GPL vous donne le droit d’utiliser le logiciel de n’importe quelle façon, mais vous DEVEZ vous assurer que le code source est disponible pour la prochaine personne qui utilisera le logiciel (ou votre variante du logiciel). La licence BSD n’exige pas que vous soyez sûr que la prochaine personne qui utilise (ou modifie votre code) rende ce code disponible.

2. Contrôle

Le code BSD n’est pas « contrôlé » par une personne en particulier, ce que beaucoup de gens voient comme un gros plus. Alors que le noyau Linux est principalement contrôlé par Linus Torvalds (le créateur de Linux), BSD n’est pas régi par une personne unique dictant ce qui peut ou ne peut pas aller dans le code. À la place, BSD utilise une « équipe centrale » (NdT : core team) pour gérer le projet. Cette équipe centrale a un droit de parole dans la direction du projet plus important que celui des autres membre de la communauté BSD.

3. Noyau contre système d’exploitation

Le projet BSD maintient un système d’exploitation entier, alors que le projet Linux se focalise principalement sur le seul noyau. Ce n’est pas aussi fondamental que ça en a l’air parce qu’un grand nombre d’applications qui sont utilisées le sont sur les deux systèmes d’exploitation.

4. UNIX-like

Il y a un vieux dicton à propos de BSD contre Linux : « BSD est ce que vous obtenez quand une poignée d’hackers UNIX se rassemblent pour essayer de porter un système UNIX sur un PC. Linux est ce que vous obtenez quand une poignée d’hackers PC se rassemblent et essaient d’écrire un système UNIX pour le PC » (NdT : BSD is what you get when a bunch of UNIX hackers sit down to try to port a UNIX system to the PC. Linux is what you get when a bunch of PC hackers sit down and try to write a UNIX system for the PC).

Cette expression en dit long. Ce que vous pourrez constater, c’est que les BSD ressemblent beaucoup à UNIX parce qu’ils sont en fait des dérivés directs du traditionnel UNIX. Linux, en revanche, était un OS nouvellement créé, vaguement basé sur un dérivé d’UNIX (Minix, pour être précis).

5. Systèmes de base

Ce point est crucial pour comprendre les différences entre BSD et Linux.

Le « système de base » pour Linux n’existe pas vraiment, puisque Linux est un conglomérat de systèmes plus petits qui s’imbriquent ensemblent pour former un tout. La plupart diront que le système de base de Linux est le noyau. Le problème c’est qu’un noyau est plutôt inutile sans aucune application utilisable. BSD en revanche, a un système de base comprenant de nombreux outils — même libc fait partie du système de base. Parce que ces pièces sont toutes traitées comme un système de base, elles sont toutes développées et packagées ensemble. D’aucun argueront du fait que cela crée un tout plus cohésif.

6. Plus à partir des sources

À cause de la façon dont BSD est développé (en utilisant le système de Ports), davantage d’utilisateurs ont tendance à installer à partir des sources plutôt que de paquets binaires pré-empaquetés.

Est-ce un avantage ou un inconvénient ? Cela dépend des individus. Si vous êtes adepte de la simplicité et de la convivialité, vous vous en détournerez. Ceci est particulièrement vrai pour les nouveaux utilisateurs. Peu de nouveaux utilisateurs veulent avoir à compiler à partir des sources. Cela peut engendrer une distribution pataude. Mais installer à partir des sources a aussi ses avantages (gestion des versions des bibliothèques, construction de paquets spécifiques au système, etc.).

7. Changements de version

Grâce à la façon dont BSD est développé (voir le point 5), vous pouvez mettre à jour l’ensemble de votre système de base vers la plus récente des versions avec une seule commande. Ou bien vous pouvez télécharger les sources de n’importe quelle version, les décompresser, et compiler comme vous le feriez pour n’importe quelle autre application. Avec Linux, vous pouvez aussi changer un système de version en utilisant le gestionnaire de paquets du système. La première façon ne mettra à jour que le système de base, la seconde mettra à jour l’ensemble de l’installation. Rappelez-vous cependant que passer à la nouvelle version du système de base ne veut pas dire que tous vos paquets supplémentaires seront mis à jour. Alors qu’avec les mises à jour de version de Linux, tous vos paquets bénéficieront du processus de mise à niveau. Est-ce que cela signifie que la façon de faire de Linux est meilleure ? Pas nécessairement. J’ai vu de mes propres yeux une mise à jour Linux qui s’est horriblement mal passée, nécessitant la réinstallation du système tout entier. Cela a beaucoup moins de chances de se produire avec un changement de version BSD.

8. Dernier cri

Il est peu probable que vous voyiez un BSD exécuter la toute dernière version de quoi que ce soit. Linux au contraire, a beaucoup de distributions qui offrent les dernières versions des paquets. Si vous êtes fan du « Si ce n’est pas cassé, ne le corrigez pas » (NdT : If it isn’t broken, don’t fix it), vous serez un grand fan de BSD. Mais si vous êtes du genre à avoir besoin que tout soit le plus récent possible, vous feriez mieux de migrer vers Linux aussi vite que possible histoire de ne pas être à la traîne.

9. Support matériel

Vous constaterez, en général, que Linux supporte le matériel bien plus tôt que BSD. Ça ne veut pas dire que BSD ne supporte pas autant de matériel que Linux. Ça veut juste dire que Linux le supporte avant BSD (dans certains cas, BIEN avant BSD). Donc si vous voulez la toute dernière carte graphique, ne pensez même pas à BSD. Si vous voulez le nouveau portable qui en jette avec un chipset sans-fil dernier cri, vous aurez plus de chance avec Linux.

10. Communauté d’utilisateurs

Je vais me risquer ici à généraliser sur les utilisateurs d’ordinateurs. En préambule je dirai qu’il y a des exceptions à TOUTES les règles (ou généralités, dans le cas présent). Mais je vous présente ma généralisation sur la répartition des distributions en fonction des utilisateurs. De la gauche vers la droite on passe des utilisateurs maîtrisant le moins un PC à ceux le maîtrisant le plus. Comme vous pouvez le constater, Linux est au milieu, alors que BSD penche plus sur la droite. Beaucoup ne seront pas d’accord ; certains en seront même offensés. Mais c’est d’après moi une généralité assez juste sur l’usage du système d’exploitation selon l’utilisateur.

Mac —–> Windows —–> Linux —–> BSD —–> UNIX

Autres différences ?

Cette liste n’est en aucune façon destinée à dire que l’un est meilleur que l’autre. Je trouve que BSD et Linux ont chacun leur place. Et vous ?

Trouvez-vous les différences entre Linux et BSD assez significatives pour préférer rester sur l’un plutôt que l’autre ? Avez-vous essayé les deux ? Qu’est-ce qui vous fait préférer l’un par rapport à l’autre ? Argumentez, et faites connaître votre opinion à vos amis lecteurs.

Le succès actuel de l’écosystème Apple et de son dernier bébé l’iPad n’en finissent plus de nous interpeller.

Après Cory Doctorow, voici le vibrant témoignage du vieux développeur Mark Pilgrim qui, paradoxe, est devenu ce qu’il est grâce aux anciens ordinateurs d’Apple (cf photo ci-contre^[1] en plein apprentissage).

Ces ordinateurs étaient ouverts et c’est parce qu’on pouvait les bidouiller que Mark a pu trouver sa vocation et faire de sa passion son métier.

Ce ne serait plus le cas aujourd’hui. Et de se demander alors combien de Mozart de l’informatique est-on actuellement en train de virtuellement assassiner…

L’informatique est une science jeune mais qui commence à avoir ses anciens combattants dont certains cèdent à la tentation du « c’était mieux avant ». Le problème c’est qu’ici c’était effectivement mieux avant !

Ce serait déprimant si le logiciel et le hardware libres n’existaient pas. Mais encore faudrait-il qu’ils rencontrent massivement la jeune génération. Et malheur à nous si le rendez-vous est manqué !

Le crépuscule du bidouilleur

Tinkerer’s Sunset

Mark Pilgrim – 29 janvier 2010 – DiveIntoMark
(Traduction Framalang : Loque humaine)

Quand DVD Jon fut arrêté après avoir cassé l’algorithme de chiffrement CSS, il a été inculpé « d’intrusion d’ordinateur non-autorisée ». Cela mena alors ses avocats à poser la question suivante : « sur quel ordinateur s’est-il introduit ? ». Réponse du procureur : « le sien » !

Si cette introduction ne vous a pas fait bondir mieux vaut arrêter dès maintenant la lecture de cet article.

Lorsque j’étais plus jeune, « l’intrusion » était quelque chose que vous pouviez uniquement perpétrer sur les ordinateurs des autres. Mais mettons ça de côté, nous y reviendrons plus tard.

Mon père était professeur d’université la plus grande partie de sa vie d’adulte. Une année, il prit un congé sabbatique pour écrire un livre. Il avait suffisamment économisé pour s’acheter un ordinateur et une chose super récente appelé logiciel de traitement de texte. Ainsi il écrivit, il édita, et il écrivit encore. C’était évidemment tellement mieux que de travailler sur une machine à écrire qu’il ne s’est jamais posé la question de savoir si c’était de l’argent bien dépensé ou non.

Il se trouve que sur cet ordinateur, le langage de programmation BASIC était pré-installé. Vous n’aviez même pas besoin de booter le système d’exploitation à partir d’un disque. Vous allumiez l’ordinateur, appuyiez sur Ctrl-Reset, et vous aviez une invite de commande. Et sur cette invite de commande, vous pouviez taper un programme tout entier, puis vous tapiez EXECUTE, et, bordel, ça s’exécutait.

J’avais 10 ans. C’était il y a 27 ans, mais je me souviens encore de ce que j’ai ressenti quand j’ai réalisé que vous pouviez — que je pouvais — faire faire n’importe quoi à cet ordinateur en tapant les bons mots dans le bon ordre, en lui disant EXECUTE, et que, bordel, ça s’exécutait.

Cet ordinateur était un Apple IIe.

À l’âge de 12 ans, j’écrivais des programmes BASIC si complexes que l’ordinateur n’avait plus assez de mémoire pour les contenir. À 13 ans, j’écrivais des programmes en Pascal. À 14 ans j’écrivais des programmes en assembleur. À 17 ans, je participais à l’épreuve de Programmation de l’Olympiade Nationale (et la remportais). À 22 ans, j’étais employé comme programmeur.

Aujourd’hui, je suis un programmeur, un rédacteur technique, et un hacker au sens de Hackers and Painters. Mais vous ne devenez pas hacker en programmant ; vous devenez hacker en bidouillant. C’est le bricolage qui donne ce sens de l’émerveillement.

Vous devez bondir hors du système, abattre les barrières de sécurité, enlever une à une les couches posées par l’ordinateur pour faciliter la vie des gens qui ne veulent pas savoir comment ça marche. Il s’agit d’utiliser l’éditeur de secteur Copy+ pour apprendre comment le disque du système d’exploitation démarre, puis de le modifier de manière à ce que l’ordinateur fasse du bruit à chaque fois qu’il lit un secteur sur le disque. Ou alors d’afficher une page de garde au démarrage avant qu’il liste le catalogue du disque et mène à l’invite de commande. Ou de copier une myriade de merveilleuses commandes du tableau Peeks & Pokes du magazine Beagle Bros. et d’essayer de comprendre ce que je venais de faire. Juste parce que ça me bottait. Juste parce que c’était fun. Parce que ça effrayait mes parents. Parce que je devais absolument savoir comment tout ceci marchait.

Après, il y a eu un Apple IIgs. Et encore après, un Mac IIci. MacsBug. ResEdit. Norton Disk Editor. Arrêtez-moi si ça vous rappelle quelque chose.

Apple a fait les machines qui ont fait qui je suis. Je suis devenu qui je suis en bidouillant.

Le titre de ce billet est tiré de « On the iPad » d’Alex Payne, que je vais citer maintenant dans ses grandes largeurs :

L’iPad est un objet attractif, fort bien pensé et conçu, mais profondément cynique. C’est une machine de consommation digitale. Or, comme Tim Bray et Peter Kirn l’ont fait remarquer, c’est un appareil qui ne favorise pas la créativité…

Le tragique avec l’iPad est qu’il semble offrir un meilleur modèle d’informatique pour beaucoup de personnes — peut-être la majorité des gens. Envolés les métaphores et concepts déroutants de ces trente dernières années d’informatique. Envolé la possibilité de tripatouiller et modifier sans but particulier. L’iPad est simple, va droit au but, ne demande pas d’entretien…

La chose qui me préoccupe le plus avec l’iPad est la suivante : si j’avais eu un iPad plutôt qu’un vrai ordinateur lorsque j’étais petit, je ne serais jamais devenu un programmeur aujourd’hui. Je n’aurais jamais eu la possibilité d’exécuter n’importe quel programme stupide, potentiellement dangereux, mais hautement éducatif que j’aurais pu télécharger ou écrire. Je n’aurais pas été capable de titiller ResEdit et de supprimer le son du démarrage du Mac de façon à ce que je puisse bricoler sur l’ordinateur à toute heure sans réveiller mes parents.

Maintenant, je suis conscient que vous allez pouvoir développer vos propres programmes pour l’iPad, comme vous pouvez développer pour l’iPhone aujourd’hui. Tout le monde peut développer ! Tout ce dont vous avez besoin, c’est d’un Mac, XCode, un « simulateur » d’iPhone, et de 99 dollars pour un certificat de développeur à durée limitée. Le « certificat de développeur » est en vrai une clé cryptographique vous permettant (temporairement) d’accèder (partiellement) à… votre propre ordinateur. Et c’est très bien — tout du moins exploitable — pour les développeurs d’aujourd’hui, parce qu’ils savent qu’ils sont développeurs. Mais les développeurs de demain ne le savent pas encore. Et sans cette possibilité de bidouiller, certains ne le seront jamais.

(À y réfléchir, j’avais tort et Fredrik avait raison, car il semblerait que les ordinateurs sous Chrome OS donneront bien la possibilité aux développeurs d’exécuter leur propre code en local. Je ne connais pas les détails de ce à quoi cela va ressembler, si ça sera un bouton, un interrupteur physique ou autre chose. Mais ça sera là, une plateforme officielle prenant en compte les développeurs d’aujourd’hui et, plus important, les développeurs de demain.)

Et, je sais, je sais, vous pouvez « jailbreaker » votre iPhone, pour (re)gagner l’accès administrateur, et exécuter n’importe quoi qui, bordel, puisse s’exécuter. Et je n’ai aucun doute sur le fait que quelqu’un trouvera comment « jailbreaker » l’iPad aussi. Mais je ne veux pas vivre dans un monde où il faut forcer l’entrée de son propre ordinateur avant de pouvoir bidouiller. Et je ne veux certainement pas vivre dans un monde où bidouiller son ordinateur est illégal. (Au passage, DVD Jon a été acquitté. Le procureur a fait appel et il a été acquitté à nouveau. Mais qui a besoin de la loi quand vous avez la cryptographie à clé publique de votre côté ?)

Il était une fois des machines, fabriquées par Apple, qui ont fait de moi ce que je suis.

Je suis devenu ce que je suis en bidouillant. Maintenant, il semble qu’ils fassent tout ce qui est en leur pouvoir pour empêcher mes enfants de trouver ce sens de l’émerveillement. Apple a déclaré la guerre aux bidouilleurs. À chaque mise à jour de logiciels, la génération « jailbreakée » précédente cesse de fonctionner, et les gens doivent trouver de nouvelles façons pour entrer de force dans leurs propres ordinateurs. Il n’y aura même pas de MacsBug pour l’iPad. Il n’y aura pas de ResEdit, ou un éditeur de secteur Copy ][+, ou un tableau Peeks & Pokes pour l’iPad.

Et c’est une vraie perte. Peut-être pas pour vous, mais pour quelqu’un qui ne le sait pas encore et qui pourrait même ne jamais le savoir.