1

Du bon usage des deniers publics par les municipalités danoises

Une douzaine de villes danoises se sont mises d’accord pour développer ensemble des solutions libres en partenariat avec des sociétés de services locales.

Un exemple à suivre…

Angel Torres - CC by

Les municipalités danoises utilisent l’open source pour innover et collaborer

Danish municipalities using open source to innovate and collaborate

Gijs Hillenius – 1er février 2013 – OpenSource.com
(Traduction : Moosh, Sphinx, lgodard, Doh-a + anonymes)

Les municipalités danoises utilisent de plus en plus les logiciels libres et open source pour apporter des solutions innovantes et collaboratives dans leurs missions d’information et de communication (ICT). L’année dernière, plus de 10% des municipalités du pays ont rejoint la communauté nouvellement créée Open Website Community OS2. Le groupe possède déjà à son actif un système de gestion municipal de contenu basé sur Drupal (appelé OS2Web) ainsi qu’une application de gestion des réunions sans papier (intitulée OS2dagsorden, NdT : littéralement OS2-ordre du jour).

Les 12 municipalités du consortium OS2 sont soutenues par 19 fournisseurs de services open source danois. En Décembre dernier, le groupe a commencé le développement des deux prochaines applications, OS2kontactcenter et OS2kle, déclare JonBadstue Perdersen, responsable de la section à la municipalité de Syddjurs.

« Comme OS2 le fait habituellement, nous avons commencé à travailler sur OS2kontaktcenter dans un hackerspace en impliquant vingt participants provenant des municipalités et des fournisseurs », indique Badstue. « Et en seulement deux jours nous avons prouvé que nous pouvions proposer des solutions de centres de contacts pour les municipalités, qui combinent et présentent aux visiteurs sur le site web des informations qui sont déjà disponibles sur certains sites et bases de données. » Cette solution utilise efficacement deux taxonomies prédéfinies de l’information, appelées KLE et FORM, rendues disponibles par les administrations publiques.

Marquage du contenu

La seconde et nouvelle solution, OS2kle a pour but de fournir une interprétation automatique du texte. Elle utilise Taxon, un logiciel open source, pour ajouter automatiquement des balises aux documents électroniques.

« Le balisage est devenu un moyen fréquent de structurer de grandes quantités de contenu sur un site web, » explique Badstue. « Mais le procédé consistant à baliser les contenus avec des méta-données utilise beaucoup de ressources. Nous améliorons ce procédé, soit en ajoutant automatiquement des balises, soit en suggérant à l’utilisateur certaines balises à utiliser. »

Le consortium OS2 a débuté en avril de l’année dernière avec les cinq villes de Copenhague, Ballerup, Sønderborg, Syddjurs et Ishøj. Morsø, Jammerbugt, Ringsted, Kolding, Odsherred, Favrskov et Skanderborg les ont rejointes peu après. Selon Badstue : « OS2 a pour objectif de contribuer à l‘open source dans le secteur public. Nous voulons faire du Danemark un pionnier à la fois international et innovant dans ce domaine. »

« Notre communauté montre que les administrations publiques danoises adoptent de plus en plus l‘open source avec le soutien de leurs politiciens locaux. Ce type de logiciels offre les meilleurs outils pour créer une société numérique, ouverte et innovante, nous permettant de collaborer et partager notre travail tout en évitant le blocage dû aux logiciels propriétaires. »

Crédit photo : Angel Torres (Creative Commons By)




MakerPlane : quand l’open source prend son envol dans l’aviation

Cette décennie est et sera marquée par le développement tous azimut du matériel libre.

Sera-t-on à terme capable de réellement modifier la donne dans le secteur industriel ?

Difficile à dire aujourd’hui mais rien n’empêche d’essayer, d’explorer, de bidouiller, même dans les secteurs les plus fous comme l’aviation…

MakerPlane

MakerPlane : L’open source prend son envol dans l’aviation

MakerPlane: Open source takes flight in aviation

Ted Brunell – 7 janvier 2013 – OpenSourceWay
(Traduction : tibs, Kenoris, RavageJo, KoS, ehsavoie, goofy, lamessen + anonymous)

J’ai parlé avec John Nicol du projet MakerPlane à propos de leur équipe passionnée de contributeurs des quatres coins du monde qui conçoivent et construisent un ULM biplace complet. Leur objectif est de « créer des avions innovants et de changer la donne dans l’avionique et ses systèmes connexes ainsi que dans les procédés de fabrication ».

Quand avez vous entendu parler de l’open source pour la première fois, et qu’est-ce qui vous a le plus impressionné à propos de celui-ci ?

J’ai évolué dans l’industrie de haute technologie depuis plus de 20 ans, à des postes différents, comme vice-président de la branche ingénierie d’une entreprise cotée au NASDAQ à Fremont (Californie), et PDG de mes propres entreprises en Nouvelle-Zélande et au Canada. J’ai donc été confronté à l’open source depuis un certain temps. J’ai utilisé et développé des logiciels et ressources open source tout au long de ma carrière et je continue à le faire pour un autre projet que je mène actuellement (je ne veux pas vendre la mèche, mais j’espère pouvoir publier des logiciels de modélisation 3D open source l’année prochaine).

Ce qui m’impressionne le plus, c’est qu’une communauté intéressée peut grandir et stimuler l’innovation de manière exponentielle. Elle peut devenir autonome et, dans de bonnes conditions, peut être très prolifique. Ce que je veux dire, c’est que de nouveaux développeurs motivés peuvent toujours prendre le relais et apporter de la fraîcheur au logiciel ou au système en cours de développement. Bien sûr, la communauté est la clé de ce genre de projet et c’est là que tout se joue : l’open source peut survivre en dehors des entreprises et sans la présence de personnalités.


Les principes de l’open source sont désormais tout aussi bien ancrés dans le domaine matériel, et j’ai récemment présenté MakerPlane à l’Open Source Hardware Summit (NdT : Sommet du matériel libre) à New York.

Comment est utilisé l’open source dans le projet MakerPlane ?

Pour résumer, nous fournissons du matériel open source et le logiciel dirigeant l’avion « fait maison ». Ce logiciel est toujours en cours de développement, mais il contiendra un système de visualisation électronique (EFIS), qui est une sorte d’ordinateur de bord qui affiche des informations sur le vol et les moteurs. Il contient également des micrologiciels pour des périphériques comme Android et Arduino.

Le matériel se trouve dans deux domaines principaux : l’avionique et l’avion. Les instruments de bord et l’électronique à l’intérieur de l’avion constituent l’avionique. A ce jour, nous avons 24 plans de matériel avionique open source disponibles en téléchargement dans nos dépôts, pour que tout le monde puisse les construire. La gamme de projets s’élargit en permanence. Pour ce qui est des avions, nous sommes en train de concevoir et de construire notre premier ULM open source (un ULM biplace grandeur nature). Nous cherchons à améliorer le design pour qu’il puisse être construit à la maison, grâce à des machines à commande numérique ou des imprimantes 3D. Avec la démocratisation de celles-ci, et la vague du « fait maison », on profite à la fois de la technologie et du matériel de construction à bas prix, indispensables à ceux qui veulent construire leur propre avion.

Les chiffres que nous avons indiquent que 75% des projets de construction d’avion en kit ou à partir de plans sont abandonnés avant d’être terminés. Les entreprises aéronautiques qui fournissent des kits ou des plans font faillite, laissant à l’abandon de nombreux projets. Notre but est de rassembler le plus possible de plans d’avions open source, avec des notices semblables à celles d’IKEA pour les assembler (enfin, en espérant qu’elles soient plus facile à comprendre que celles d’IKEA !). Ces plans, étant open source, seraient disponibles pour quiconque voudrait y accéder, et pourraient survivre aux fondateurs de MakerPlane.

Les gens ont tendance à s’inquiéter quand je parle d’avion open source. Leur principale préoccupation est le fait que n’importe qui peut venir modifier les plans, les rendant du même coup dangereux. Mais un ingénieur en aéronautique est responsable des plans. Comme pour un logiciel open source, il surveille les modifications et aucune ne sera appliquée sans son accord. Bien sûr, tout le monde peut modifier et personnaliser l’avion à sa convenance, et c’est une des principales qualités de l’open source. Cependant, dans 99% des pays, tout avion doit normalement être inspecté par les autorités aériennes ou leurs représentants, avant de recevoir l’autorisation de décoller. Aux Etats-Unis, c’est le rôle de la Federal Aviation Administration (FAA) (Administration Fédérale de l’Aviation). Ces règles sont élaborées pour assurer la sécurité des pilotes, des passagers, et des populations au sol. Vous devez aussi avoir un brevet de pilote, particulièrement pour la catégorie des avions que nous concevons et fabriquons.

Quels sont les défis avec le projet ?

Le financement est le plus gros défi, comme pour la plupart des sociétés à initiatives open source ! De nombreuses personnes n’imaginent sans doute pas qu’un nombre important de projets open source sont financés par des grosses sociétés. La base des mouvements open source semble être toujours sous-financée et nous ne faisons pas exception. La dimension supplémentaire avec nous, c’est que nous avons besoin d’acheter beaucoup de matériel et d’équipements pour arriver à construire un avion. Nous sommes conscients que pour demander des dons et continuer, nous devons faire des progrès et faire voler l’avion. Or nous ne pouvons pas l’envoyer dans les airs sans argent pour acheter les fournitures, c’est donc en quelque sorte un cercle vicieux.

Les modèles commerciaux pour soutenir les initiatives open source sont de fournir des produits et/ou services qui gravitent autour du produit open source libre. Pour aider à financer notre projet nous avons donc ouvert une boutique en ligne et nous y vendons des pièces et des kits pour l’avionique et finalement pour l’avion. Pour le moment l’ensemble de l’entreprise est financé par mes propres économies et cartes de crédits, c’est comme ça. Cela signifie que la progression est plus lente que je le voudrais étant donné que je ne peux malheureusement pas sortir et acheter les pièces quand je le veux. Je voudrais plus que tout avoir une plus grosse machine à commande numérique et une imprimante 3D, mais nous faisons avec ce que j’ai actuellement. Si nous avions le financement, nous aurions sans doute beaucoup plus avancé.

Quel sera selon vous l’impact de MakerPlane sur le monde ?

L’utilisation de technologies de fabrication à domicile change la façon dont les gens font des choses et la vitesse à laquelle ils le font. Une bonne machine-outil à commande numérique peut être faite ou assemblée à partir de kit pour quelques milliers de dollars et une personne peu qualifiée peut utiliser une machine à commande numérique ou une imprimante 3D pour produire quelques objets très précis et le faire de nombreuses fois. Au lieu de prendre une paire d’années pour faire des pièces d’avion, je devrais être capable de découper les pièces en quelques jours, les assembler et terminer avec un avion complet. Je ne veux plus avoir à faire expédier des pièces par un fabriquant ou un distributeur. Je veux pouvoir faire mes propres kits comme j’en ai besoin. J’aurais juste besoin de télécharger un fichier, charger les matériaux dans la machine et les couper. Les méthodes que nous explorons pour assembler l’avion comprennent des fentes et des languettes, ce qui permet aux pièces de ne se monter que dans un sens et sont auto-équerrés. Il est à espérer que de nombreuses techniques permettant de gagner du temps que nous avons appris grâce à MakerPlane trouveront leur place chez les grands constructeurs d’avions en kit.

Comment peut-on s’impliquer dans MakerPlane ?

Il y a plusieurs manière pour les gens de contribuer à notre ambition de changer le monde de l’aviation ! Voici quelques idées :

  • Rejoignez le forum MakerPlane et participez aux discussions. Dites-nous quelles sont vos compétences et même si vous ne pouvez pas contribuer directement de façon technique, dites simplement « Salut » et dites nous ce que vous aimez ou n’aimez pas sur les designs.
  • Reprenez un projet open source déjà disponible dans le dépôt. De très bons projets ont déjà été envoyés, mais beaucoup ont encore besoin de TLC, de mises à jour, et d’une documentation plus aboutie.
  • Commencez un nouveau projet ! Si vous avez une idée géniale pour quelque chose en rapport avec l’aviation open source et quelques compétences pour l’implémenter, ouvrez un nouveau projet sur le dépôt et allez-y ! Si vous avez déjà du code, ou du matériel que vous avez conçu et construit, alors nous serions ravis de le voir dans le dépôt également.
  • Parlez de MakerPlane à vos amis, qu’ils soient pilotes ou pas. Aimez notre page Facebook, suivez-nous sur Twitter, partagez, envoyez des courriels, ou des vraies lettres ! Faites passer le mot, pour que nous puissions vraiment construire notre communauté.
  • Nous acceptons avec gratitude des dons de pièces détachées, de ressources, et/ou d’argent. Et nous sommes toujours à la recherche de sponsors. Merci beaucoup pour votre aide !

Quel est votre utilisation de l’open source en dehors de votre projet ?

J’utilise quotidiennement OpenOffice pour le travail et Inkscape, Gimp, et Blender de façon plus occasionnelle. J’ai de l’expérience en électronique, donc je m’amuse avec du matériel Arduino open source, et mon téléphone et ma tablette sont bien entendus sous Android. L’open source est partout dans ma vie !

Voir cette vidéo illustrant les étapes de la création d’un prototype de MakerPlane.




Restons courtois ! (Libres conseils 17/42)

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

Traduction Framalang : peupleLa, goofy, lamessen, SaSha_01, lerouge, Kalupa, RavageJo, lenod, Sky, Astalaseven, Alpha, KoS, purplepsycho +tala

De L’importance des bonnes manières

Rich Bowen

Rich Bowen a travaillé dans le domaine du logiciel libre et open source pendant près de quinze ans. La majeure partie de son travail a porté sur le serveur HTTP Apache ; il a également travaillé sur Perl, PHP et diverses applications web. Il est l’auteur de Apache Cookbook, The Definitive Guide to Apache et divers autres livres. Il fait également de fréquentes apparitions dans diverses conférences sur les technologies.

J’ai commencé à travailler sur le projet de documentation du serveur HTTP Apache en septembre 2000. Du moins, c’est à ce moment-là que j’ai réalisé mon premier commit dans les docs. Auparavant, j’avais présenté quelques corrections par courriel, et quelqu’un d’autre les avait appliquées.

Depuis cette période, j’ai réalisé un peu plus d’un millier de modifications de la documentation du serveur HTTP Apache, ainsi qu’une poignée de modifications du code lui-même. Ceux qui s’impliquent dans les logiciels libres et open source le font pour tout un tas de raisons différentes. Certains tentent de se faire un nom. La plupart essaient de « gratter là où ça les démange » comme ils disent, s’efforçant d’ajouter une fonctionnalité, ou de créer une nouvelle brique logicielle pour satisfaire un de leurs besoins.

Je me suis impliqué dans l’écriture de la documentation sur des logiciels parce que j’avais été enrôlé pour aider à l’écriture d’un livre et que la documentation existante était vraiment horrible. Donc, pour rendre le livre cohérent, j’ai dû discuter avec différentes personnes du projet afin qu’elles contribuent à donner du sens à la documentation. Lors de la rédaction de l’ouvrage, j’ai amélioré la documentation, avant tout pour me faciliter la tâche. À peu près à la même époque, Larry Wall, le créateur du langage de programmation Perl, promouvait l’idée selon laquelle les trois principales qualités d’un programmeur étaient la paresse, l’impatience et l’arrogance. Selon moi, Larry avançait des arguments fondés et avec un sens de l’humour certain. Néanmoins, une partie non négligeable de la communauté des programmeurs a pris ses paroles comme un permis de connerie.

La paresse

Nous écrivons de la documentation pour ne pas avoir à répondre aux mêmes questions tous les jours pour le restant de notre vie. Si la documentation est insuffisante, les gens auront des difficultés à utiliser le logiciel. Bien que cela puisse être la source d’une activité lucrative de consultant, il s’agit aussi du meilleur moyen de faire avorter un projet, car les gens abandonneront, frustrés, et se tourneront alors vers d’autres choses qu’ils n’auront pas à passer des heures pour comprendre.

Ainsi, la paresse est la première vertu d’un rédacteur de documentation. Quand un client pose une question, nous devrions répondre à cette question en profondeur. Et même, de la façon la plus complète possible. Nous devrions alors enregistrer cette réponse pour la postérité. Nous devrions l’enrichir avec des exemples et si possible des diagrammes et des illustrations. Nous devrions nous assurer que le texte est clair, grammaticalement correct et éloquent. Nous devrions alors l’ajouter à la documentation existante dans un endroit facile à trouver et largement référencé partout où quelqu’un pourrait le chercher.

La prochaine fois que quelqu’un posera la même question, nous pourrons lui répondre avec un lien vers la réponse. Et les questions que l’on pourrait poser après l’avoir lue devraient être la source d’améliorations et d’annotations à ce qui a déjà été écrit. C’est la vraie paresse. La paresse ne signifie pas simplement se dérober au travail. Cela veut aussi dire faire le travail si bien qu’il n’aura pas à être refait.

La patience

ll existe une tendance dans le monde de la documentation technique à être impatient et querelleur. Les sources de cette impatience sont nombreuses. Certaines personnes pensent que, comme elles ont dû travailler dur pour comprendre ces choses, vous le devez aussi. Beaucoup d’entre nous dans le monde du technique sommes des autodidactes et nous avons peu de patience pour ceux qui viennent après nous et veulent accéder rapidement au succès. J’aime appeler ça le comportement du « tire-toi de mon chemin ». Ce n’est pas vraiment constructif.

Si vous ne parvenez pas à être patient avec le client, alors vous ne devriez pas être impliqué dans le service clientèle. Si vous vous mettez en colère quand quelqu’un ne comprend pas, vous devriez peut-être laisser quelqu’un d’autre gérer la question.

Bien sûr, c’est très facile à dire, mais beaucoup plus difficile à faire. Si vous êtes un expert sur un sujet particulier, les gens vont inévitablement venir à vous avec leurs questions. Vous êtes obligé d’être patient, mais comment allez-vous y parvenir ? Cela vient avec l’humilité.

L’humilité

J’ai fait de l’assistance technique, en particulier par liste de diffusion, pendant à peu près deux ans, quand j’ai commencé à suivre des conférences techniques. Ces premières années ont été très amusantes. Des idiots venaient sur une liste de diffusion et posaient des questions stupides que des milliers d’autres perdants avaient posées avant eux. Et si seulement ils avaient regardé, ils auraient trouvé toutes les réponses déjà données auparavant. Mais ils étaient trop paresseux et trop bêtes pour le faire.

Ensuite, j’ai assisté à une conférence, et j’ai constaté plusieurs choses. Tout d’abord, j’ai découvert que les personnes qui posaient ces questions étaient des êtres humains. Ils n’étaient pas simplement un bloc de texte écrit noir sur blanc, à espacement fixe. Il s’agissait d’individus. Ils avaient des enfants. Ils avaient des loisirs. Ils connaissaient beaucoup plus de choses que moi sur une grande variété de sujets. J’ai rencontré des gens brillants pour qui la technologie était un outil qui servait à accomplir des choses non techniques. Ils souhaitaient partager leurs recettes avec d’autres cuisiniers. Ils souhaitaient aider les enfants d’Afrique de l’Ouest à apprendre à lire. Ils étaient passionnés de vin et voulaient en apprendre davantage. Ils étaient, en bref, plus intelligents que moi, et mon orgueil était le seul obstacle sur la route de leur succès.

Quand je suis revenu de cette première conférence, j’ai regardé les utilisateurs de listes de diffusion sous un tout autre jour. Ce n’étaient plus des idiots posant des questions stupides, simplement des gens qui avaient besoin d’un peu de mon aide pour pouvoir accomplir une tâche. Pour la plupart, la technologie n’était pas une passion. La technologie était seulement un outil. Il était donc compréhensible qu’ils n’aient pas passé des heures à lire les archives de la liste de diffusion de l’année passée et choisissent plutôt de reposer des questions.

Bien entendu, si un jour les aider devient pénible, la chose la plus polie à faire est de prendre du recul et de laisser quelqu’un d’autre répondre à la question plutôt que de leur dire que ce sont des imbéciles. Mais il faut aussi se rappeler toutes les fois où j’ai eu à poser des questions stupides.

La Politesse et le Respect

En fin de compte, tout cela se résume à la politesse et au respect. J’ai principalement abordé la question de l’assistance technique, mais la documentation n’est rien d’autre qu’une forme statique d’assistance technique. Elle répond aux questions que vous attendez des gens et elle offre des réponses dans une forme semi-permanente à titre de référence.

Lorsque vous écrivez cette documentation, vous devriez essayer de trouver le juste équilibre entre penser que votre lecteur est un idiot et penser qu’il devrait déjà tout savoir. D’un côté, vous lui demandez de s’assurer que l’ordinateur est branché, de l’autre, vous utilisez des mots comme « simplement » et « juste » pour faire comme si chaque tâche était triviale, laissant au lecteur l’impression qu’il n’est pas tout à fait à la hauteur.

Cela implique d’avoir beaucoup de respect et d’empathie pour votre lecteur, en essayant de vous rappeler ce que c’est que de débuter ou d’avoir un niveau intermédiaire dans l’apprentissage d’un nouveau logiciel. Cependant, les exemples de mauvaise documentation sont si répandus qu’il ne doit pas être difficile de s’en souvenir. Il y a des chances que vous en ayez fait l’expérience au cours de la dernière semaine.

J’aurais aimé…

J’aurais aimé être moins arrogant quand j’ai commencé à travailler sur la documentation open source. Quand je relis ce que j’ai pu écrire sur des listes de diffusion archivées publiquement, gravées à jamais dans le marbre d’Internet, j’ai honte d’avoir été aussi grossier.

La plus grande vertu humaine est la politesse. Toutes les autres vertus en découlent. Si vous ne pouvez pas être poli, tout ce que vous accomplirez importera peu.




Introduction à l’économie contributive – Vidéo de Simon Lincelles (Ars Industrialis)

Le Framablog a pris l’habitude de suivre les travaux de Bernard Stiegler au sein d’Ars Industrialis. Il faut dire que ça n’est pas tous les jours qu’un philosophe affirme que « le logiciel libre peut redonner sens à nos vies » !

Nous vous proposons ci-dessous le réplication d’une vidéo de Simon Lincelles intitulée « Introduction à l’économie contributive » et co-écrit par Bernard Stiegler.

Malgré quelques inexactitudes, nous partageons l’hypothèse que le logiciel libre (et Wikipédia) représentent un espoir et un modèle pour l’avenir de notre économie.

Remarque : cette vidéo (lien direct Vimeo) est le troisième épisode d’une série initiée ici.




Ça a débuté comme ça, par un simple tweet sur le peigne liturgique…

Aujourd’hui c’est le top départ de la désormais traditionnelle levée de fonds annuelle et internationale visant à financer et soutenir tous les projets de la fondation Wikimedia, l’encyclopédie Wikipédia en tête.

Vous ne le savez peut-être pas mais les dons collectés en France se partagent pour moitié entre la fondation et l’association Wikimédia France.

Il y a deux ans nous avions relayé un excellent reportage de la télévision suisse qui précisait la destination et illustrait l’usage des dons helvètes. Cette année nous vous proposons de mettre modestement en avant une action parmi tant d’autres de Wikimédia France : le partenariat avec le Musée de Cluny.

Je cite ce dernier (Elisabeth Taburet-Delahaye Conservateur général du Patrimoine, directrice du musée de Cluny et Claire Séguret Responsable adjointe Communication et Mécénat, musée de Cluny sur le blog du Ministère de la Culture) :

L’encyclopédie Wikipedia est aujourd’hui au cœur des pratiques quotidiennes de nos visiteurs, mais également des universitaires et des conservateurs. En mars 2012, Wikimedia Foundation se classe 5e groupe français en terme d’audience sur Internet.

En étant présent sur cette formidable plateforme, le musée répond à sa mission première de diffusion du savoir et va à la rencontre d’un large public. L’amélioration d’articles existants ou la création de nouvelles entrées sont également une possibilité pour l’établissement, au moment même de la refonte de son site, de sensibiliser ses équipes aux spécificités de l’écriture pour le web, mais aussi aux notions d’outil collaboratif ou à la question des licences libres. C’est également l’occasion d’un travail collectif au sein du musée, transcendant les habituels cloisonnements.

Et c’est ainsi que deux ateliers ont été organisés en juin dernier. Pour en savoir davantage nous vous invitons à écouter le très intéressant entretien ci-dessous (vidéo réalisée par Buzzeum).

Mais ce qui est également intéressant c’est l’originalité de la toute première prise de contact dont il est rapidement fait mention dans l’entretien : un simple tweet d’Adrienne Charmet-Alix, directrice des programmes de l’association, s’étonnant du peu d’informations concernant un objet du musée, le peigne liturgique. Et rien non plus sur Wikipédia, pas d’article !

Qu’à cela ne tienne, une fois à la maison elle s’attelle à la tâche pour réparer cette incongruité. Mais nouveau problème : l’absence d’image pour illustrer le propos, tant il est vrai qu’il y a des articles qui se bonifient grandement avec des photos ad hoc

Alors elle interpelle gentiment le compte Twitter du musée via son propre compte :

Et :

Ceci fit prendre conscience à l’animatrice du compte (en l’occurrence Claire Séguret) qu’il y avait une demande et un besoin. Et c’est ainsi que l’aventure commença…

Fin de l’histoire, Je peux désormais vous donner le lien vers l’article (illustré) Peigne liturgique de Wikipédia et vous inviter à suivre ce lien 😉




Rien ne serait arrivé sans la loi de Moore

La loi de Moore (qui n’est en fait qu’un conjecture) affirme que le nombre de transistors des microprocesseurs sur une puce de silicium double tous les deux ans. Ce qui, par extension, a donné pour le grand public que le rapport entre la puissance d’un ordinateur et son prix double tous les dix-huit mois.

Autrement dit, les machines sont de plus en plus puissantes et de moins en moins chères.

C’est bien ce qu’il s’est produit et se produit encore, pour le plus grand bonheur du logiciel libre et sa culture…

Leonardo Rizzi - CC by-sa

Un allié secret de l’open source : la loi de Moore

Open source’s secret ally: Moore’s Law

Glyn Moody – 10 octobre 2012 – The H
(Traduction : KoS, ProgVal, Sylvain, greygjhart)

Linux est passé du statut de petit bidouillage sympa dans une chambre à celui de logiciel capable de changer le monde il y a un peu plus de 21 ans lorsque Linus a envoyé son fameux message : « Bonjour aux utilisateurs de minix », invitant les gens à le rejoindre. Comme je l’ai remarqué le mois dernier, cette approche ouverte, collaborative était tout à fait nouvelle et s’est avérée décisive dans l’adoption et le développement de Linux.

Cela fut possible car Internet était déjà suffisamment présent pour qu’assez de gens se joignent à l’équipe de volontaires de Linus en faisant jouer à plein l’intelligence distribuée. En d’autres termes, l’émergence du logiciel libre est intimement liée à internet. En effet, le décollage rapide de Linux, comparé aux progrès plutôt lents du projet GNU est probablement dû, au moins en partie, au fait que ce dernier ne pouvait se reposer sur une connectivité globale. C’est grâce à cela que Richard Stallman a pu vivre des ventes de GNU Emacs, qu’il distribuait sur des bandes magnétiques.

La nature symbiotique du logiciel libre et d’internet, le premier utilisant le second, le second étant utilisé par le premier, est maintenant largement reconnue. Mais un autre facteur clé dans l’apparition de l’open source a été sous-estimé, alors que Linus lui-même le mentionne dans ce fameux premier message :

Je programme un système d’exploitation (gratuit, c’est juste un passe-temps, ça ne sera pas un gros projet professionnel comme GNU) pour des clones AT 386(486).

Comme nous vivons à l’ère Intel depuis deux décennies, une ère qui touche peut-être à sa fin, avec la montée en puissance des smartphones et des tablettes et leurs processeurs de familles différentes, il est facile de négliger l’importance du fait que Linus développa Linux pour les processeurs 80386.

Aussi étrange que cela puisse paraître , l’ordinateur principal de Linus avant qu’il n’écrive Linux était un Sinclair QL, un ordinateur typiquement anglais qui utilisait le processeur Motorola 68008 (qui fonctionnait à 7,5 MHz), fourni avec 128K de RAM et utilisait un infâme microdrive comme stockage.

Passer à un PC 386, fonctionnant à 33MHz, avec 8 Mo de RAM et 40Mo de disque dur, était un véritable bond en avant pour Linus, et poussa ses finances à leurs limites. En fait, il n’a pu acheter son premier PC que le 5 janvier 1991 parce qu’il reçut de l’argent pour Noël qu’il ajouta à un prêt étudiant que le gouvernement Finlandais lui avait récemment accordé. Ce dernier était censé payer sa nourriture et son logement pendant qu’il étudiait à l’université d’Helsinki mais comme il vivait toujours avec sa mère pendant cette période, il réussi à le détourner pour un usage plus intéressant.

Le fait qu’il puisse se payer un système aussi performant reposait sur l’amélioration continuelle du matériel, couplée à la diminution régulière des prix. C’est à dire que c’est grâce à la loi de Moore, qui dit que le ratio entre performances et prix double tous les 18 mois environ, que Linus a pu se retrouver avec le système 386 qu’il mentionne dans le premier message sur Linux.

Sans la loi de Moore, il serait sans doute resté avec son Sinclair QL, codant pour un système dont peu de gens se souciaient. Avec le 386, il a pu rentrer dans le courant dominant de l’informatique en même temps que de nombreuses autres personnes. Partout dans le monde (ou en tout cas dans les zones les plus riches) les jeunes gens ont pu s’acheter de vrais ordinateurs basés sur l’Intel 80386 et (plus tard) 80486. Cela signifiait qu’ils pouvaient faire tourner le code de Linux dès ses débuts, et aussi qu’ils pouvaient contribuer.

Encore une fois, sans la loi de Moore mettant des ordinateurs moins chers dans les mains de bidouilleurs, Linus n’aurait pas été en mesure de construire cette communauté mondiale à travers Internet et le rythme de développement en aurait souffert. En effet, comme la loi de Moore continuait de tirer les prix vers le bas tout en augmentant les performances, de plus en plus de gens dans un nombre croissant de pays ont pu acquérir des PCs suffisamment puissants pour rejoindre le projet Linux. Des processeurs plus rapides signifiaient des temps de compilation plus courts pour les programmes ce qui rendait le bidouillage du code plus facile – et plus agréable.

Il y a ici un contraste intéressant avec le développement du logiciel propriétaire. Les avancées dues à la loi de Moore ne profitent que peu aux programmeurs dans les entreprises, puisqu’ils ont généralement du matériel assez bon. Et les entreprises n’en bénéficient guère plus, puisque ce qui coûte le plus dans la programmation est le salaire des programmeurs, pas le prix de leurs PCs. Dans le monde du logiciel libre, les programmeurs volontaires sont bénévoles et le facteur limitant est le prix du matériel. C’est pourquoi la loi de Moore est très avantageuse pour l’open source.

Potentiel futur

Ce n’est pas un effet purement historique des premières heures de Linux. Nous voyons encore aujourd’hui la Loi de Moore tirer les prix vers le bas en accueillant toujours plus d’utilisateurs. Un bon exemple est le mini-ordinateur Raspberry Pi. Il offre les bases de la puissance d’un PC sur une petite carte mère, à un prix minuscule. Cela signifie que non seulement les personnes ordinaires – même des enfants – peuvent l’acheter sans avoir à penser au prix, mais aussi que les écoles peuvent envisager d’en acheter un pour chaque étudiant, ce qui est normalement inenvisageable avec les prix prohibitifs des PC, même ceux bon marché.

L’effet que le Raspberry Pi aura sur l’éducation n’est pas encore clair, mais il semble que celui-ci ou l’un des nombreux systèmes semblables à prix très bas va permettre l’arrivée de nouveaux types de projets avec des nouveaux groupes de contributeurs, dans les pays émergents par exemple.

Et les choses sont déjà en train d’aller plus loin. Voici un projet Kickstarter qui illustre à merveille cette progression continue rendue possible grâce à la loi de Moore. Il s’agit de Parallella. l se décrit comme un « Supercalculateur Grand Public », et ce n’est pas une blague.

Une fois terminé, l’ordinateur Parallella devrait fournir l’équivalent d’un processeur à plus de 45Ghz sur un circuit de la taille d’une carte de crédit tout en consommant moins de 5 Watts en fonctionnement normal. En s’en tenant seulement à la fréquence, c’est plus de puissance qu’un serveur haut de gamme qui coûte des milliers de dollars et consomme 400W.

Important, tout le système sera ouvert :

  • Accès ouvert : absolument aucun accord de non divulgation ou accès spéciaux nécessaires ! Toute l’architecture et le kit de développement seront publiés sur le web dès que le projet sera financé sur Kickstarter.
  • Open Source: la plateforme Parallella sera basée sur des outils et des bibliothèques libres et gratuites. Tous les fichiers de conception des circuits seront fournis une fois que Parallella sera sur le marché
  • Bon marché : les coûts du matériel et des outils de développement ont toujours été une barrière très difficile à franchir pour les développeurs cherchant à écrire des applications haute-performance. Notre but est de fournir l’ordinateur haute-performance Parallella à un coût inférieur à 100$, le rendant accessible à tous.

Oui, c’est un super ordinateur à 45GHz, fourni en standard avec Ubuntu, pour moins de 100$. Si Parallella parvient à sortir cela – et en tant que projet Kickstarter (il y a toujours le risque qu’il ne soit pas totalement financé ou qu’il ne fonctionne pas correctement) il va mettre un nouveau niveau de puissance de calcul entre les mains de tout le monde, y compris les étudiants.

Potentiellement, cela va permettre à des gens qui, jusqu’à présent, ne pouvaient tout simplement pas s’acheter une telle puissance de calcul de démarrer une toute nouvelle génération de projets open source. Encore une fois, le principal bénéficiaire ici est l’open source : si une entreprise a besoin d’un supercalculateur, elle va généralement l’acheter immédiatement, puisqu’elle peut se permettre de payer un prix conséquent pour les modèles actuels. Ce que Parallella apporte, grâce à la loi de Moore, est la démocratisation d’une puissance de calcul de cet ordre, qui ne va plus être réservée à des projets commerciaux disposant de solides fonds.

Il est important de noter que c’est la loi de Moore, agissant sur le matériel qui apporte ces bénéfices, plutôt que n’importe quel changement exponentiel dans le logiciel (qui n’y contribue qu’indirectement). De plus des lois de Moore pour d’autres types de matériel commencent également à prendre forme. Un exemple frappant en est l’impression 3D, où les prix baissent régulièrement. Ou encore le monde du séquençage du génome, démêler les milliards de « lettres » chimiques qui forment la double hélice de l’ADN, qui voit l’arrivée de changements encore plus importants.

Vous savez peut-être que le coût de séquençage du génome baisse mais vous n’avez peut-être pas la moindre idée de la vitesse à laquelle il baisse. Le National Human Genome Research Institute qui fait partie du National Institute of Health américain a compilé des données étendues sur le coût de séquençage de l’ADN au cours de la dernière décennie et a utilisé ces informations pour créer deux graphique à couper le souffle. Les chercheurs du NHGRI montrent que non seulement les coûts de séquençage sont en chute libre mais ils dépassent la courbe exponentielle de la loi de Moore d’une grande marge.

Cela signifie que le coût de séquençage de votre génome, ou de n’importe quel autre organisme, va bientôt devenir à la portée de tout le monde. Cela va-t-il créer une communauté globale de bio-hackers libristes, menée par un nouveau Linus avec un séquenceur de bureau (et peut-être un supercalculateur Parallella) dans sa chambre à coucher ? L’expérience des logiciels libres suggère que oui et nous apprend que nous ne devrions jamais sous-estimer le simple pouvoir de la loi de Moore à conduire des changement inattendus et révolutionnaires.

Crédit photo : Leonardo Rizzi (Creative Commons By-Sa)




Point de réseau social sérieux sans lolcats !

Framasoft harcèle (et parfois excède) ses followers Twitter actuellement avec ses « lolcats de soutien » (, , , , , , , , , ou encore ), ce qui ne nous empêche de nous penser sérieux et appliqués dans notre démarche de promotion et diffusion du Libre.

L’idée générale de la traduction ci-dessous c’est que si vous voulez créer un véritable réseau social au sein de votre structure alors il vous faudra aussi accepter ce qui n’a rien à voir avec votre structure. C’est le coté social du réseau social et il est beaucoup moins futile qu’on peut à priori le penser car c’est souvent un préalable à une bonne ambiance d’où pourront émerger des choses bien pertinentes pour votre structure.

Michellelevine - CC by-sa

Si vous voulez une culture vraiment collaborative, vous devez aussi accepter les LOLCats

If you want a culture of collaboration, you need to accept the LOLCats too

Steve Radick – 11 janvier 2012 – OpenSource.com
(Traduction : KoS, Maïeul, @ali0une, greygjhart)

Même lorsque la presse était sacrée, nous avons eu des romans érotiques 150 ans avant d’avoir des journaux scientifiques
Clay Shirky (Conférence TED Cannes juin 2010)

C’est une de mes citations favorites de l’une de mes personnalités favorites d’Internet, Clay Shirky. Je l’aime particulièrement parcequ’elle illustre selon moi l’époque où certaines organisations se trouvent en essayant d’intégrer les médias sociaux en leur sein.

Avant que les wikis ne soient utilisés par les communautés de coopération scientifique, les personnes s’y inscrivaient pour désigner leur équipe de foot favorite. Avant que l’intranet de ma propre entreprise ne remporte un prix, nous avions des personnes qui nous expliquaient comment elles étaient heureuse de se montrer (presque) nues sur leurs profils. Avant que nos dirigeants commencent à utiliser Yammer pour communiquer avec la base, des groupes de fanas d’Android ou de fitness s’étaient déjà constitués. Je vous parle de cela parce que si vous décidez un jour d’intégrer un média social interne à votre organisation, vous devrez préparer vous-même, vos collègues, vos patrons, votre haute direction à cette vérité inexorable.

Si vous paniquez en voyant tout ça sur votre intranet, vous n’êtes probablement pas prêt pour un intranet social.

Si vous voulez créer une culture dynamique de collaboration, vous devez accepter les photos de LOLCats, les sujets parlant de foot, les débats sans fin sur Apple et Andoid, et même les critiques sur la politique de l’entreprise.

Acceptez et intégrez ce fait maintenant et vos communautés auront de bien meilleurs chances de succès. Ou, continuez à penser que de telles choses sont une perte de temps et ne sont pas professionnelles, et soyez prêt à payer beaucoup d’argent pour un système que personne n’utilise à moins d’être forcé à le faire (et ils l’utiliseront alors mal).

Malheureusement, « social » à l’air d’être devenu un gros mot en entreprise, associé à l’image d’employés perdant leur temps sur Facebook, parlant à leur petit ami au téléphone, ou prenant une pause déjeuner de trois heures. Acceptons d’arrêter d’essayer d’enlever le social d’un réseau social. Les interactions sociales ne doivent pas seulement être acceptées, elles doivent même être encouragées et récompensées. Shirky explique pourquoi dans cette conférence TED (à partir de 5 minutes 33 secondes).

Shirky explique :

Le fossé est entre faire quelque chose et ne rien faire. Et quelqu’un qui fait des LOLcat a déjà franchi ce fossé. Oui, il est tentant de vouloir obtenir des projets aussi noble que Ushahidi sans les LOLCats, d’avoir les choses sérieuses sans les choses futiles. Mais l’abondance de médias ne marche pas comme ça. La liberté d’expérimenter, c’est aussi voire surtout la liberté d’experimenter n’importe quoi.

Il y a cette tendance de la part des dirigeants à vouloir supprimer (voire sanctionner) les blogs qui évoqueraient des solutions de contournement de la politique d’entreprise et les pages wiki détaillant les meilleurs restaurants pour déjeuner. Ils veulent aller droit au but qui serait la co-création de méthodologies avec des équipes inter-fonctionnelles et des initiatives de crowdsourcing qui font économiser des millions de dollars !

Ça ne fonctionne pas pas comme ça. Les communautés collaboratives ne commencent pas à innover juste parce que vous mettez en place un site web et envoyez un mémo. Souvenons-nous que les nouvelles érotiques sont apparues bien avant les journaux scientifiques. Il y aura donc des LOLCats avant des Ushahidi. Vous devez accepter le fait que vos employés parleront de sport et de vacances avant d’être prêts à utiliser l’outil pour procéder à un « vrai » travail.

C’est intuitivement du bon sens. N’est-il pas plus facile de publier votre bon plan du midi plutôt que d’envoyer ce rapport sur lequel vous travaillez depuis trois semaines ? Si quelqu’un n’apprécie pas votre restaurant préféré, quelle importance ? En revanche si quelqu’un critique le rapport que vous avez passé des semaines à écrire, c’est un peu plus intimidant. Une fois que vous avez franchi ce seuil, ce seuil entre ne rien faire et faire quelque chose, c’est plus facile alors de monter les marches. Une fois la glace rompue avec la mention de votre passion pour la gastronomie chinoise, il vous sera soudainement plus facile de participer à la conversation sur tel projet important de votre entreprise. Peut-être même que vous accepterez d’envoyer une partie coriace du rapport en demandant aide et éclaircissement aux autres. Sous cet angle, même les publications les plus stupides et les conversations les plus insignifiantes ont de la valeur, parce qu’elle n’engage qu’un risque mineur pour les gens à se jeter à l’eau et faire le premier pas.

Cela peut prendre du temps pour que les employés se sentent vraiment à l’aise avec l’utilisation des réseaux sociaux au travail. En lui laissant ainsi la possibilité de s’épanouir et d’apprendre ensemble à son propre rythme, votre communauté supportera bien mieux les changements d’échelle et durera bien plus longtemps.

Alors acceptez les LOLCats, les délires footballistiques, les discussions sur la bouffe, et les avatars personnalisés : au moins vos employés créeront et partageront quelque chose avec quelqu’un d’autre. Parce que ce qui viendra après ces stupides discussions mènera à du lien, des relations, des questions, des réponses, et finalement, à des innovations très créatives, à des produits et des solutions qui vous feront économiser du temps et (beaucoup) d’argent. Et vous serez récompensés pour avoir participé à rendre votre entreprise humaine et chaleureuse.

Crédit photo : Michellelevine (Creative Commons By-Sa)




Un logiciel libre n’est pas toujours collaboratif et de qualité

Voici un titre étrange pour un blog comme le nôtre.

Oui il existe des logiciels libres de mauvaise qualité qui ne souffrent pas la comparaison avec leurs concurrents propriétaires ! Et oui encore la majorité des logiciels libres sont uniquement développés par un seul et unique contributeur : leur créateur !

Face à de tels logiciels, les partisans de l’open source pleurent car ils détruisent aussi bien leur argumentaire pratico-technique que le mythe de la collaboration spontanée. Les partisans de logiciel libre envisagent quant à eu les choses différemment car ce qu’ils voient avant tout c’est que le logiciel est libre.

Le logiciel libre n’est pas meilleur en pratique mais il est libre en théorie et c’est bien ça le plus important…

Remarque : Cette traduction est le fruit d’une coopération entre Framasoft (et son énergie plurielle présente sur Framalang et les réseaux sociaux) et l’April (via son équipe de traduction du site GNU.org)

James Rickwood - CC by

Quand le logiciel libre n’est pas meilleur, en pratique

When Free Software Isn’t (Practically) Better

Benjamin Mako Hill – GNU.org
Licence Creative Commons By-Nd – Version du 6 octobre 2012
(Traduction : Framalang et l’équipe Trad-GNU de l’April)

Les objectifs affichés par l‘Open Source Initiative sont les suivants : « L’open source est une méthode de développement logiciel qui exploite la puissance d’une évaluation décentralisée, par les pairs, et la transparence des processus. Les promesses de l’open source sont une meilleure qualité, une plus grande fiabilité, davantage de flexibilité, un moindre coût et la fin d’une situation permettant à des fournisseurs rapaces de verrouiller leurs produits. »

Depuis plus de dix ans maintenant, la Free Software Foundation ne cesse d’argumenter contre la qualification d’« open source » dont on affuble le mouvement du logiciel libre. Si nous, les partisans du logiciel libre, réfutons ce qualificatif d’« open source », c’est surtout parce que nous considérons qu’il s’agit d’un effort volontaire pour réduire la portée de notre message de liberté et masquer le rôle de notre mouvement dans le succès du logiciel que nous avons bâti. Si nous disons que le terme « open source » est mauvais, c’est fondamentalement parce qu’il tente d’éviter toute discussion à propos de la liberté du logiciel. Mais il y a une autre raison pour laquelle nous devrions nous méfier du cadre « open source ». L’argument fondamental de l’open source, tel qu’il est défini dans la déclaration ci-dessus, est souvent incorrect.

Malgré la suggestion de l‘Open Source Initiative, que « la promesse de l’open source est une meilleure qualité, une plus grande fiabilité, plus de flexibilité », cette promesse n’est pas toujours honorée. Bien que nous ne le mettions pas souvent en avant, tout utilisateur d’un logiciel libre aux premiers stades de son développement peut expliquer que ce logiciel n’est pas toujours aussi pratique, sur le plan purement fonctionnel, que ses concurrents privateurs[1] Un logiciel libre est parfois de piètre qualité. Il n’est pas toujours très fiable. La souplesse lui fait parfois défaut. Si les gens prennent les arguments en faveur de l’open source au sérieux, ils doivent expliquer pourquoi l’open source n’a pas tenu ses « promesses » et conclure que des outils privateurs seraient un meilleur choix. Il n’y a aucune raison pour que nous fassions de même.

Richard Stallman parle de cela dans son article « Pourquoi l’open source passe à côté du problème que soulève le logiciel libre » lorsqu’il explique : « L’open source repose sur l’idée qu’en permettant aux utilisateurs de changer et redistribuer le logiciel, celui-ci en sortira plus puissant et plus fiable. Mais cela n’est pas garanti. Les développeurs de logiciels privateurs ne sont pas forcément incompétents. Parfois ils produisent un programme qui est puissant et fiable, même s’il ne respecte pas la liberté de l’utilisateur. »

Pour l’open source, la mauvaise qualité d’un logiciel est un problème à analyser ou une raison de fuir ce logiciel. Pour le libre, c’est un problème à résoudre. Pour les partisans du libre, les bogues et les fonctionnalités manquantes ne sont jamais une raison d’avoir honte. Tout logiciel qui respecte la liberté de ses utilisateurs possède un avantage inhérent sur son concurrent privateur. Même s’il a ses propres problèmes, un logiciel libre a toujours la liberté.

Bien évidemment, tout logiciel libre doit commencer quelque part. Un nouveau programme, par exemple, a peu de chances d’offrir plus de fonctionnalités qu’un programme privateur déjà établi. Un projet commence avec de nombreux bogues et s’améliore avec le temps. Alors que les partisans de l’open source peuvent argumenter qu’un projet deviendra utile avec du temps et un peu de chance, un projet libre représente pour les partisans du logiciel libre une importante contribution, dès le premier jour. Chaque logiciel qui donne aux utilisateurs le contrôle sur leur technologie est un pas en avant. L’amélioration en qualité due à la maturation d’un projet n’est que la cerise sur le gâteau.

Un second point, peut-être plus accablant encore, est que le processus de développement collaboratif, distribué, évalué par les pairs, qui est au cœur de la définition de l’open source, ne ressemble que de loin à la manière dont sont développés en pratique la plupart des projets sous licence libre (ou « open source »).

Plusieurs études universitaires menées sur les sites d’hébergement de logiciels libres SourceForge et Savannah ont démontré ce que beaucoup de développeurs de logiciels libres ayant mis en ligne une base de code savent déjà : la grande majorité des projets libres ne sont pas particulièrement collaboratifs. Le nombre médian de contributeurs à un projet de logiciel libre sur SourceForge ? Un. Un développeur solitaire. Les projets de SourceForge du quatre-vingt-quinzième centile en termes de nombre de participants n’ont que cinq contributeurs. Plus de la moitié de ces projets libres, et même la plupart des projets qui ont fait plusieurs versions à succès et ont été téléchargés fréquemment sont l’œuvre d’un seul développeur avec un peu d’aide de l’extérieur.

En insistant sur la puissance du développement collaboratif et de « l’évaluation décentralisée par les pairs », l’approche open source semble ne pas avoir grand chose à dire, dans la majorité des cas, sur les raisons pour lesquelles on devrait contribuer à un projet libre ou se servir d’un logiciel en développement. Puisque les avantages supposés de la collaboration ne peuvent être constatés quand il n’y a pas de collaboration, la grande majorité des projets de développement libres n’ont pas d’avantage technique sur leurs concurrents privateurs.

Pour les partisans du logiciel libre, ces mêmes projets sont tous vus comme des succès importants. Comme chaque logiciel libre respecte la liberté de ses utilisateurs, les partisans du libre peuvent argumenter qu’il possède au départ un avantage éthique intrinsèque sur les concurrents privateurs – même sur ceux qui proposent plus de fonctionnalités. En insistant sur la liberté plutôt que sur les avantages pratiques, la défense du logiciel libre est ancrée dans la réalité technique d’une façon qui manque souvent à l’open source. Quand le logiciel libre est meilleur, nous pouvons nous en réjouir. Quand il ne l’est pas, nous n’avons pas à considérer cela comme une attaque dirigée contre lui ni même comme un argument valable contre l’utilisation du logiciel en question.

Les partisans de l’open source doivent défendre leur thèse selon laquelle le logiciel développé librement devrait, ou devra avec le temps, être meilleur que le logiciel privateur. Les militants du logiciel libre peuvent quant à eux demander : « Comment peut-on rendre le logiciel libre meilleur ? » Dans le cadre du libre, les logiciels de haute qualité existent comme un moyen plutôt que comme une fin en soi. Les développeurs de logiciels libres doivent s’efforcer de créer des logiciels fonctionnels, flexibles, qui servent bien leurs utilisateurs. Mais ceci n’est pas le seul moyen de progresser vers la réalisation d’un objectif qui est à la fois plus simple et bien plus important : respecter et protéger leurs libertés.

Bien sûr, nous ne cherchons pas à nier que la collaboration joue un rôle important dans la création de logiciels de haute qualité. Dans la plupart des projets libres ayant réussi, ce fut d’ailleurs le cas. Il faut comprendre, soutenir et développer la collaboration, plutôt que de considérer dogmatiquement qu’elle va de soi, quand bien même les faits sont là pour montrer le contraire.

Crédit photo : James Rickwood (Creative Commons By)

Notes

[1] Autre traduction de proprietary : propriétaire