La forge logicielle SourceForge n’est plus à présenter. C’est le plus grand dépôt d’applications libres au monde, qui se comptent en centaine de milliers.

Or petit scandale et réelle polémique, SourceForge vient tout récemment et sans préavis d’en barrer l’entrée aux ressortissants de l’Iran, la Corée du Nord, Cuba, du Soudan et de la Syrie, pour se mettre en conformité avec une loi américaine sur la sécurité nationale^[1].

Tant pis pour les développeurs et utilisateurs de ces cinq pays et tant pis aussi pour les principes non discriminants qui régissent le logiciel libre.

Pour évoquer ce problème nous avons choisi de traduire la news du Register, mais nous aurions tout aussi bien pu choisir cet article de ComputerWorld dont la conclusion interpelle : « La seule manière d’empêcher réellement les pays sur liste noire d’avoir accès aux dépôts de logiciels libres hébergés aux USA est d’interdire aux Américains de participer au mouvement open source ! »

SourceForge raye 5 nations de la carte open source

SourceForge bars 5 nations from open source downloads

Dan Goodin – 26 janvier 2010 – The Register
(Traduction Framalang : Olivier)

Certains pays sont plus égaux que d’autres

Le dépôt de logiciels open source, SourceForge.net, bloque désormais automatiquement les adresses Internet des utilisateurs de l’Iran, la Corée du Nord, Cuba, le Soudan et la Syrie au prétexte d’appliquer une loi empêchant les ressortissants de ces pays de télécharger des logiciels libres.

Les réactions des puristes du mouvement des logiciels libres et open source ne se sont pas fait attendre. Ils militent pour que chacun ait accès au code, à la seule condition qu’il respecte les termes de la licence. À l’instar du dépôt open source de Google, les termes d’utilisation de Sourceforge interdisent depuis longtemps à quiconque résidant dans un des pays placés sur la liste de sanction de l’US Office of Foreign Assets Control d’envoyer ou de télécharger du code.

Depuis la semaine dernière, SourceForge a commencé à bannir certaines adresses IP pour faire respecter cette interdiction. Dans un article paru lundi, Sourceforge n’annonce pas la raison de ce changement, mais il affirme néanmoins que cette décision ne cadre pas avec la philosophie de l’entreprise :

« Cependant, notre participation à la communauté open source ne peut pas nous faire oublier que nous vivons dans le monde réel et que nous sommes tenus aux lois qui régissent le pays d’où nous exerçons », peut-on lire dans l’article. « Notre obligation est de suivre ces lois et nos vœux, aussi humanistes soient-ils, ne peuvent pas s’y soustraire. »

Les critiques de cette restriction ne se firent pas attendre. Dans les commentaires, sur le blog de SourceForge, une personne note que cette restriction entre en conflit avec la Section 5 de la définition de l’Open Source qui stipule que les licences ne doivent pas établir une discrimination « entre des personnes ou des groupes de personnes ». Les critiques soutiennent également que ces restrictions ne sont pas compatibles avec le discours que tenait la semaine précédente Hillary Clinton, la Secrétaire d’État américaine, encourageant un Internet libre.

Le livre Richard Stallman et la révolution du logiciel libre – Une biographie autorisée, qui est sorti le 21 janvier aux éditions Eyrolles, possède trois auteurs.

Il y a bien entendu Sam Williams, auteur de la version d’origine en anglais. Mais si nous n’étions qu’en face de sa simple traduction, il demeurerait alors le seul auteur de l’ouvrage. Or deux autres noms apparaissent : Richard Stallman lui-même et Christophe Masutti de Framasoft.

Pourquoi cette originalité et pourquoi méritent-ils tous deux de venir s’associer à Sam Williams ? Vous le saurez en parcourant l’histoire peu commune de ce livre, telle qu’elle a été vécue par Christophe.

Il nous propose une très jolie formule pour expliquer les intentions et les apports de Stallman :
il a souhaité « hacker » le livre.

Avec le même état d’esprit, ou plutôt la même éthique, que lorsqu’il se trouvait, plusieurs dizaines d’années auparavant, jeune programmeur parmi les siens au département de recherche en intelligence artificielle du MIT.

Il était une fois un livre sur et avec Richard Stallman

Christophe Masutti – janvier 2010 – GNU Free Documentation License

Tout a commencé en mars 2007, lorsque Alexis Kauffmann a posté un message sur le forum du réseau Framasoft, invitant les volontaires à participer à la traduction du livre de Sam Williams, Free as in Freedom: Richard Stallman’s Crusade for Free Software, publié en 2002 chez O’Reilly sous la licence libre GNU Free Documentation License.

Framasoft a une certaine habitude des traductions et s’est même constitué avec le temps une équipe entièrement dédiée à cela, le groupe Framalang. Il se trouve qu’à cette époque Framalang ne chômait pas et nous ne souhaitions pas leur rajouter une charge de travail supplémentaire avec un livre de quelque 300 pages !

Nous avons donc fait le choix de proposer directement le projet dans un wiki public, et pas n’importe lequel d’entre eux : Wikisource, la bibliothèque libre du réseau Wikimedia. Lors d’une conférence tenue aux Rencontres mondiales du logiciel libre 2009 de Nantes, Alexis donne plus de détails sur le mode opératoire : quelqu’un avait déjà traduit la préface et le premier chapitre du livre sur un site personnel, ce qui nous a servi de base pour créer la structure de l’ensemble du projet sur Wikisource. L’objectif était bien entendu d’arriver à nos fins mais il s’agissait également d’une expérience, celle d’une ambitieuse traduction collaborative et spontanée ouverte à tous, exactement comme on crée, modifie et améliore les articles de Wikipédia.

Un an plus tard, le bilan était contrasté. Nous avions bénéficié de l’exposition de Wikisource et de nombreuses personnes étaient venues participer. Mais quantitativement il restait encore beaucoup à faire et qualitativement ce qui avait été fait manquait singulièrement de cohérence et d’harmonie (ne serait-ce que pour se mettre d’accord sur la traduction de tel ou tel terme important et récurrent). Et puis nous butions sur des questions aussi élémentaires que la décision de « clore » un chapitre traduit, ce qui sur un wiki aussi fréquenté ne va pas de soi.

Ne nous en déplaise, il fallait mettre un peu de « cathédrale dans le bazar », c’est-à-dire un peu de verticalité dans l’horizontalité du projet. Alexis a alors pris la décision de relancer le projet sur le blog de Framasoft, en invitant les bonnes volontés à se regrouper sur une liste de discussion dédiée et créée pour l’occasion. Pour ma part, je pris l’initiative d’animer cette liste qui compta rapidement une bonne dizaine d’inscrits (dans le livre vous trouverez en préambule les remerciements à cette liste nominative de participants).

Notre première décision consista à créer ailleurs un deuxième wiki, mais cette fois-ci loin des regards du réseau Wikimedia. Il ne s’agissait pas de jouer les cachottiers, mais nous en étions arrivés à la conclusion qu’il n’était plus possible de continuer à travailler sur Wikisource, dans la mesure où à tout moment une personne externe à la liste pouvait s’en venir tout « bouleverser » (c’est, j’en conviens fort bien, ce qui fait tout le charme de Wikipédia, mais à cette période d’un projet si spécifique nous souhaitions avant toute chose être efficaces et coordonnés dans notre travail).

Nous nous trouvions cependant face à un dilemme : d’un côté la traduction d’origine sur Wikisource restait bien entendu ouverte et continuait sa vie de texte wiki (bien que fort peu active, puisque la liste avait capté une bonne part de l’énergie disponible) et de l’autre côté, le travail sur notre nouveau wiki prenait forme et la traduction avançait plutôt bien. Une fois terminée, notre intention était de reverser la traduction de Free as in Freedom dans Wikisource, quitte à « écraser » les contributions effectuées dans l’intervalle (ces contributions peuvent néanmoins être réhabilitées grâce à l’historique des modifications). Aujourd’hui, on peut donc trouver sur Wikisource cette traduction française de Free as in Freedom publiée par Sam Williams en 2002. Modulo le fait que quelqu’un est peut-être venu en déplacer un mot il y a une heure 😉

Notre traduction avançait donc plutôt bien jusqu’à obtenir une forme convenable à la relecture en novembre 2008, avec en prime la décision définitive d’en faire un volume de plus de la collection de livres libres Framabook.

Une petite parenthèse est ici nécessaire. En effet, nous travaillions depuis peu en étroite collaboration avec l’équipe de La Poule ou l’Oeuf, qui est une chaîne éditoriale en ligne pour la production de livres, pensés comme unités d’une collection, permettant un rendu final de type TeX, PDF, ePub ou HTML. Ce livre était aussi pour nous l’occasion d’implémenter dans le système non seulement l’ouvrage mais aussi la maquette générale de notre collection Framabook. Nous sommes très heureux du résultat car non seulement la Poule ou l’Oeuf a servi pour la mise en page du livre publié chez Eyrolles, mais ce sont désormais tous les framabooks qui vont bénéficier de la puissance de cet outil et des compétences de l’équipe de la Poule ou l’Oeuf.

Parenthèse fermée. Un mois plus tard, en décembre 2008, j’écrivis à Sam Williams pour lui demander une préface. Il accepta, tout en me précisant qu’il aurait bien aimé que Richard Stallman eût participé aux éventuelles modifications de l’ouvrage en anglais mais que finalement cela ne s’était pas produit. À ce moment-là, je ne compris guère l’allusion qui trouva son explication quelques jours plus tard.

Nous réfléchissions également aux illustrations possibles de l’ouvrage. Il y avait une belle photo de Richard Stallman dans le livre d’origine chez O’Reilly, tirée du site web personnel de Richard. Je contacte donc ce dernier, non seulement pour lui demander l’autorisation d’utiliser sa photo, mais aussi pour l’informer que nous comptions publier la traduction en français (une traduction en italien avait été publiée en 2003).

C’est là que tout a basculé (positivement).

Il faut savoir que le livre Free as in Freedom n’a jamais obtenu l’appui formel de Richard Stallman. Pire : Richard aurait déjà affirmé qu’il était hors de question de venir lui demander un autographe sur le livre. On peut légitimement se demander pourquoi… Certes le travail de Sam Williams est d’abord un travail de journaliste, et il dresse un portrait sans concession de la personnalité de Richard Stallman : introverti, controversé, irascible et intransigeant. Tous ceux qui se sont rendus au moins une fois à l’une de ses conférences et qui sont au courant de ses activités, ont une bonne idée de ce que je veux dire.

Mais ce n’est pas sur ce point que Richard Stallman était en désaccord avec l’ouvrage : il y avait des erreurs manifestes voire des interprétations faussées dans les faits concrets relatés dans l’ouvrage. En somme, un travail mené un peu trop vite et sans assez de recul. Par ailleurs, un programmeur de l’envergure de Richard Stallman met un point d’honneur à vouloir reformuler avec exactitude les approximations, même lorsqu’elles ont été commises volontairement dans le but de rendre l’ouvrage plus accessible. Il n’en demeure pas moins que sous le prétexte de l’accessibilité, certaines approximations transformaient carrément le propos ou les évènements. La manière dont Richard a agit sur le texte est relatée dans sa préface et lorsque le propos relève notamment de l’interprétation personnelle de Sam Williams, les ajouts de Richard sont clairement identifiés dans le livre par des encarts et des notes de bas de page. Les lecteurs pourront donc se faire une bonne idée des transformations ainsi opérées, quitte à aller voir et comparer avec l’original de Sam Williams.

Je prends un exemple : lorsque Sam Williams relate la tension entre Eric S. Raymond et Richard Stallman, on comprend que Raymond accuse Richard d’être la principale cause du manque de réactivité du projet Hurd (le projet de noyau du système GNU), et que cette accusation est fondée (on se doute néanmoins que Raymond n’a pas bien digéré la fin de non recevoir pour les modifications de l’éditeur Emacs qu’il voulait imposer). Pour Williams, et aussi pour Raymond, c’est le « micro-management » à la Stallman, c’est à dire sans concession, qui a freiné Hurd, avec pour conséquence la popularisation du noyau Linux, qui obéit, lui, à un schéma de développement beaucoup plus ouvert. Il serait pourtant simpliste de se contenter de cette interprétation. Richard l’explique autrement, tant en montrant que Hurd n’est pas une mince affaire qu’en montrant aussi que le noyau Linux n’est pas la panacée du point de vue technique comme du point de vue éthique (le plus important à ses yeux).

Bref, suite à mon courriel, Richard me répondit qu’il désirait apporter quelques précisions sur l’épisode LMI et Symbolics, deux entreprises qui débauchèrent le gros de l’équipe de hackers du MIT au début des années 1980. Cet épisode était très important, mais il ne touchait en gros qu’une dizaine de paragraphes dans l’ouvrage. Lorsque j’en fis référence à l’équipe de notre liste de discussion, tout le monde approuva l’idée.

Pourtant, au fil des échanges, Richard me confia qu’il n’avait jamais lu le livre de Sam Williams, et qu’en lisant les chapitres en anglais que je lui envoyais (repris depuis le site personnel de Sam Williams), il ressentait fortement le besoin de le réécrire.

Et tout l’art du hacker se révéla.

Alors que je lui suggérais d’écrire lui-même son autobiographie (d’un certain côté, j’anticipais sur mes craintes : la retraduction de l’ensemble à partir de toutes ces nouvelles modifications !), il se contenta de me renvoyer des chapitres réécris, sur lesquels je faisais un « diff » (une commande Unix permettant d’afficher les différences entre deux fichiers) pour pouvoir implémenter ces modifications dans la traduction française.

Après tout, qu’est-ce qu’un hacker ? Le lecteur en trouvera une bonne définition historique en annexe de l’ouvrage. L’essentiel est de comprendre que « hacker » signifie surtout améliorer, et qu’un bon hacker qui se respecte ne supporte pas l’imperfection. En toute logique, Richard ressentait tout simplement l’envie irrésistible de « hacker » le livre de Sam Williams. Qui d’autre sinon lui ?

J’énonce tout ceci avec le recul que me permet la parution de l’ouvrage. Dans les faits, je recevais plusieurs courriels par semaine contenant les modifications de Richard. Je les implémentais après les avoir lues, demandé des précisions, et argumenté lorsqu’elles étaient discutables. Bref, un travail soutenu qui nous amena Richard et moi jusqu’au début de l’été 2009.

Un mois auparavant, Alexis avait rencontré Muriel Shan Sei Fan, directrice de la collection Accès Libre aux éditions Eyrolles. Et entre la poire et le fromage, il évoqua « l’aventure » de cette traduction qu’il continuait à suivre attentivement. Muriel trouva le projet tant est si bien intéressant qu’elle nous proposa de le publier chez eux.

Nous acceptâmes, mais ce serait vous mentir que d’affirmer que ce fut une décision facile et unanime dans l’équipe. En effet, nous avons, et nous avons encore, nos habitudes chez InLibroVeritas, l’éditeur si particulier et attachant de tous les autres framabooks, avec qui nous travaillons main dans la main depuis des années pour défendre et faire la promotion du logiciel libre et sa culture.

Plusieurs arguments ont cependant pesé dans la balance. Tout d’abord nous n’avions plus affaire cette fois à un livre sur un logiciel libre particulier (Thunderbird, OpenOffice.org, LaTeX, Ubuntu…). Nous étions face à un livre mutant, une traduction devenue « biographie autorisée » car modifiée et enrichie pour l’occasion par son sujet même. Et pas n’importe quel sujet : la plus illustre des personnalités de la jeune histoire du logiciel libre. Cela méritait assurément de rechercher la plus grande exposition possible. Outre sa capacité de diffusion et distribution, Eyrolles nous offrait aussi son expertise et expérience. Le livre avait été traduit et une première fois relu, mais nous étions néanmoins conscients de sa perfectibilité de par les conditions mêmes de sa réalisation mentionnées plus haut (sachant de plus qu’à ce moment précis de l’histoire Richard n’en avait toujours pas fini avec ses propres modifications). Eyrolles a ainsi retravaillé le texte et mis à disposition du projet plusieurs personnes non seulement pour effectuer de nouvelles relectures mais parfois même pour retraduire certains passages. J’ajoute que nous appréciions la collection pionnière Accès Libre qui abrite en son sein de nombreux ouvrages de qualité sur le logiciel libre. Et enfin dernier argument et non des moindres : sous notre impulsion, Eyrolles allait pour la première fois publier d’emblée un livre sous licence libre, avec tous les avantages et inconvénients que cela suppose.

Nous nous rencontrâmes in the real life, Muriel, Richard, Alexis et moi, au cours d’un déjeuner en marge des Rencontres mondiales du logiciel libre de Nantes en juillet 2009. Nous discutâmes des modalités de publication et surtout, justement, de la question de la licence. L’ouvrage d’origine étant sous licence GNU Free Documentation License (à cause d’un Stallman insistant, Sam Williams s’en explique à la fin de son livre), sa traduction ne pouvait que l’être également. Or publier sous licence libre n’était pas dans les habitudes d’Eyrolles et cela ne rentrait pas forcement dans les « cases » de ses contrats types (rien que le fait d’interdire la classique interdiction de photocopier était une nouveauté). De plus nous connaissons les positions sans concession de Stallman dès que l’on touche à ces questions de licence. Mais nous avons néanmoins réussi sans trop de mal à nous mettre d’accord, et il faut rendre ici hommage aux éditions Eyrolles d’avoir su s’adapter et innover.

La dernière ligne droite fut en tout cas aussi passionnante que stressante, avec ses nombreux va-et-vient entre Richard (apportant ses dernières modifications), Eyrolles (éditant à la volée l’ensemble de l’ouvrage), La Poule (obligée à mettre en forme un texte sans cesse en mouvement) et moi (dispersé un peu partout). Toujours est-il que vers la fin décembre 2009, ouf, nous étions prêts et le projet bouclé. Nous méritions tous ce beau cadeau de Noël que nous nous offrions là 😉

De leur côté, Richard Stallman et John Sullivan vont très prochainement publier en anglais le livre dans sa nouvelle version, aux éditions internes à la Free Software Foundation, ajoutant ainsi une dimension supplémentaire au projet. Non seulement nous touchons les lecteurs francophones, mais le monde anglophone pourra aussi se délecter de ce « hack biographique ». Grâce à la licence libre (et aux efforts de quelques uns), le livre, parti des États-Unis, revient à la maison après un détour par la France qui l’aura transformé !

Pour moi, ce livre n’est pas seulement une biographie, même s’il en a l’apparence et la saveur. Il s’agit d’une histoire, celle du mouvement pour le logiciel libre, qui a influencé profondément l’histoire générale de l’informatique depuis la fin des années 1960. On considère généralement cette histoire à travers celle de l’industrie logicielle ou des composants d’ordinateurs. Mais il manque souvent une approche en termes de pratiques d’ingénierie et de circulation de l’information. Le logiciel libre constitue en cela une belle illustration de l’ingénierie logicielle, qui avance non seulement par projet, mais aussi parce qu’elle est fondamentalement un débat permanent sur la disponibilité et le partage de l’information. Lorsque le partage d’idées est impossible (notamment à cause des brevets) et lorsque les développeurs et les utilisateurs sont restreints dans leurs libertés, alors c’est la société toute entière qui pâti de la pénurie de code et de libertés.

Tous les métiers ont leur déontologie. Les informaticiens ont une éthique et ceux qui la distillent sont les hackers. Par delà ses actes et ses programmes, l’un des principaux mérites de Richard Stallman est d’avoir réussi à concentrer et matérialiser cette éthique dans une simple licence (la fameuse GNU General Public License), qui va non seulement fonder, défendre et diffuser le logiciel libre mais qui constitue aujourd’hui une référence et une source d’inspiration pour d’autres mouvements émancipateurs. En fait, les programmes ont toujours été libres, et c’est un non-sens éthique qui les a rendu privateurs à un moment donné. L’histoire de l’informatique est heureusement loin d’être terminée.

Celle de ce livre touche par contre à sa fin, puisqu’il sera officiellement publié le 21 janvier prochain sous le titre Richard Stallman et la révolution du logiciel libre – Une biographie autorisée. Je remercie chaleureusement tous ceux que cette aventure a mis sur notre chemin. Toutes ces rencontres qui font aussi le sel d’un tel projet. À Framasoft, nous sommes fiers d’avoir pu le mener à son terme. Et malgré le labeur qui n’a pas manqué, ce fut un réel plaisir. Plaisir que nous espérons désormais partager avec le lecteur…

Cette histoire touche donc à sa fin, disais-je, mais, licence libre oblige, rien ne dit qu’il ne subisse pas à l’avenir d’autres métamorphoses. Ne serait-ce que parce que Richard est heureusement toujours parmi nous et qu’il lui reste encore certainement de belles pages à écrire dans le livre de sa vie.

Parce que Tata Jeanine vient de recevoir une machine neuve pour Noël, parce que Tonton Paul a la sienne tellement vérolée (sic !) qu’il valait mieux repartir de zéro que de tenter de la nettoyer, parce que Cousin Léonard administre les postes de son lycée… nombreux peuvent être les cas de figure où l’on se trouve devant un ordinateur, qui n’est pas forcément le nôtre, dont le système d’exploitation Windows aurait besoin d’accueillir d’un coup tout plein de logiciels libres.

C’est ici que Framapack, le nouveau projet du réseau Framasoft, peut vous être potentiellement utile.

Vous vous rendez sur le site dédié à l’opération (qui n’abrite en fait qu’une seule page). Vous choisissez vos logiciels libres comme on fait son marché, parmi la sélection proposée qui compte déjà une bonne cinquantaine d’unités. Enfin vous cliquez sur la grosse flêche verte qui vous proposera de télécharger un tout petit exécutable que vous… exécuterez, et puis c’est tout !

Vous n’avez plus qu’à attendre tranquillement, comme le pingouin de notre illustration, puisque le boulot de cet unique fichier exécutable sera d’aller automatiquement chercher les logiciels un à un et de les installer tout seul sur votre ordinateur (avec la dernière version stable et l’installation par défaut de chaque logiciel choisi).

Ceci implique de nous faire confiance lorsque l’on vous assure que l’on ne rajoute évidemment aucun spyware et autres conchoncetés au passage (ce serait même plutôt le contraire puisqu’avec PDF Creator par exemple, on vous propose l’installation sans la suspicieuse barre d’outils et l’inopportun changement de moteur de recherche). Et pour accroitre la confiance, rien de tel que de placer l’application Framapack elle-même sous licence libre (GNU/GPL) sur SourceForge.

Animé par Simon Leblanc, le projet Framapack est tout jeune, avec sa version actuelle 1.0 (ou plutôt 1.0.1 pour être précis). Tous les avis, remarques, critiques, tests, rapport de bugs et propositions de participation sont bien entendu les bienvenus.

Découvrir Framapack…

Ah qu’il était doux et rassurant le temps de l’informatique à grand-papa où nous avions nos ordinateurs fixes qui se connectaient de temps en temps et où nous luttions avec confiance et enthousiasme contre le grand-méchant Microsoft !

Ce temps-là est révolu. Nous entrons dans une autre décennie et il se pourrait bien que le principal sujet de conversation de la communauté du logiciel libre dans les dix ans à venir ne soit plus Microsoft (symbole du logiciel propriétaire, j’ai mal à mes fichiers !) mais Google (symbole de l’informatique dans les nuages, j’ai mal à mes données personnelles !)^[1].

Firefox, bouffé par Chrome ? Ubuntu, court-circuité par Chrome OS ? Le Web tout entier se transformant petit à petit en un fort joli Minitel 2.0 bourré de services Google à tous les coins de rue ? Ces différents scénarios ne relèvent pas forcément de la science-fiction.

Le problème c’est que nous n’avons plus un Microsoft en face d’une limpide ligne de démarcation. Le problème c’est que nous avons affaire à rien moins qu’au premier contributeur open source de la planète. Et cela rend légèrement plus complexe le positionnement…

La plus grande entreprise mondiale de l’open-source ? Google

World’s biggest open-source company? Google

Matt Asay – 16 septembre 2009 – Cnet news
(Traduction Framalang : Julien et Cheval boiteux)

Red Hat est généralement considérée comme la principale société open source de l’industrie, mais c’est une distinction dénuée de sens parce qu’elle est inexacte. Alors que les revenus de Red Hat proviennent des logiciels open source que la société développe et distribue, d’autres entreprises comme Sun, IBM et Google écrivent et contribuent en réalité à beaucoup plus de code open source. Il serait temps d’arrêter de parler d’entreprises open source et de revenir à l’importance du code open source.

L’open source est de plus en plus le socle sur lequel reposent les entreprises d’internet et du logiciel. Myspace a dernièrement fait des vagues en ouvrant les sources de Qizmt, un framework de calcul distribué (qui curieusement tourne sur Windows Server) qui active la fonction « Personnes que tu pourrais connaître » du site. Mais Myspace, comme l’a noté VentureBeat, n’a fait que rattraper la récente ouverture des sources de Tornado par Facebook.

Aucun d’eux ne le fait pour marquer des points auprès des utilisateurs branchés. S’ils le font, c’est motivé par leurs propres intérêts, qui nécessitent de plus en plus souvent d’inciter des communautés de développeurs à adopter et étendre leurs propres applications et services Web.

C’est également un moyen d’améliorer la qualité des logiciels. En adoptant les projets open source d’une entreprise, puis en l’étendant à travers ses propres logiciels open source, la qualité collective de l’open source est forte et croissante, comme le note Kit Plummer d’Accenture.

C’est cette compréhension de l’intérêt qu’il apporte et la qualité qui en découle qui a fait de l’open source une architecture essentielle pour potentiellement tous les logiciels commerciaux, ce qui signifie que Red Hat et d’autres entreprises qui ne font que de l’open source ne sont désormais plus le centre de cet univers.

Le noyau Linux est composé de 11,5 millions de lignes de code, dont Red Hat est responsable à hauteur de 12% (mesuré en termes de lignes de code modifiées). Même si l’on y ajoute le serveur d’applications JBoss Application Server (environ 2 autres millions de lignes de code) et d’autres projets Red Hat, on obtient toujours un total inférieur à d’autres acteurs.

Prenons Sun, par exemple. C’est le principal développeur derrière Java (plus de 6.5 millions de ligne de code), Solaris (plus de 2 millions de lignes de code), OpenOffice (environ 10 millions de lignes) et d’autres projets open source.

Ou bien IBM, qui a contribué à lui seul à 12,5 millions de lignes pour Eclipse, sans parler de Linux (6.3% du total des contributions), Geronimo, et un large éventail d’autres projets open source.

Google, cependant, est la société la plus intéressante de toutes, car elle n’est pas une entreprise de logiciels en soi. J’ai interrogé Chris DiBona, responsable des programmes open source et secteur public de Google, à propos des contributions de la société dans le domaine de l’open source (NdT : Cf Tout, vous saurez tout sur Google et l’Open Source sur le Framablog). Voici sa réponse :

Au bas mot, nous avons libéré environ 14 millions de lignes de code. Android dépasse les 10 millions de lignes, puis vous avez Chrome (2 millions de lignes, Google Web Toolkit (300 000 lignes), et aux alentours d’un projet par semaine sorti au cours des cinq dernières années. Vous avez ainsi quelques centaines d’employés Google qui patchent sur une base hebdomadaire ou mensuelle.

Si DiBona se garde bien de suggérer que Google soit devenu le premier contributeur open source (« disons que nous sommes parmi les premiers »), c’est néanmoins probablement le cas, en particulier lorsque l’on considère ses autres activités open source, incluant Google Code, l’hébergement du plus grand dépôt peut-être de projets open source, avec plus de 250 000 projets hébergés, dont au moins 40 000 sont actifs, sans parler de son Summer of Code. Après tout, les lignes de code, bien que fondamentalement utiles, ne sont pas nécessairement la meilleure mesure de la valeur d’une contribution à l’open source.

En fait, Patrick Finch de la fondation Mozilla estime que la meilleure contribution de Google à l’open source n’a probablement rien à voir avec l’écriture de nouveau code :

La plus grande contribution de Google à l’open-source n’est sans doute pas du code, mais de prouver que vous pouvez utiliser Linux à grande échelle sur des machines démarquées (NdT : whitebox hardware).

C’est une étape importante, et qui souligne le fait que le label « entreprise open source » est devenu quelque peu obsolète. Google ne se présente pas, à juste titre, comme une entreprise open source. L’open source fait simplement partie de leur stratégie pour distribuer des logiciels qui vont aider à vendre davantage de publicité.

Sun a tenté de se transformer en entreprise open source, mais une fois que son acquisition par Oracle aura été finalisée, cette dernière ne va certainement pas prendre ce label. Pas parce que c’est un mauvais label, mais simplement parce qu’il n’est plus pertinent.

Toutes les entreprises sont désormais des entreprises open source. Ce qui signifie aussi qu’aucune ne l’est. L’open source est simplement un élément parmi d’autres de la politique de développement et de croissance de ces entreprises, que l’on s’appelle Red Hat, Microsoft, Google ou Facebook.

Et étant donné que les entreprises du Web comme Google n’ont pas besoin de monétiser directement l’open source, on va en fait avoir l’occasion à l’avenir de voir encore plus de code open source émerger de la part de ces sociétés que ce qui a déjà été réalisé par ces traditionnelles « entreprises de logiciels open-source » que sont Red Hat, Pentaho ou MySQL.

En janvier 2008, Bruce Byfield écrivait, dans un article que nous avions traduit ici-même (Ce qui caractérise les utilisateurs de logiciels libres) : « La communauté du Libre peut se targuer d’être une méritocratie où le statut est le résultat d’accomplissements et de contributions ».

Deux ans plus tard, le même nous propose de sonder plus avant la véracité d’une telle assertion, qui ne va finalement peut-être pas de soi et relève parfois plus du mythe savamment auto-entretenu.

Et de poser en guise de conclusion quelques pertinentes questions qui si elles trouvaient réponse participeraient effectivement à combler l’écart constaté entre la théorie et la pratique.

Nos propres discours n’en auraient alors que plus de consistance et de maturité^[1].

Les projets open source et le mythe de la méritocratie

Open Source Projects and the Meritocracy Myth

Bruce Byfield – 2 décembre 2009 – Datamation
(Traduction Framalang : Olivier et Cheval boiteux)

« Ce n’est pas une démocratie, c’est une méritocratie. »

On trouve cette déclaration sur la page de gouvernance d’Ubuntu, mais les notes de version de Fedora présentent quelque chose de similaire, tout comme la page Why Debian for developers et partout où l’essence des projets libres et open source (NdT : FOSS) est débattue.

La méritocratie est un mythe, une de ces histoires que la communauté des logiciels libres et open source aime se conter. Par mythe je n’entends pas mensonge, mais cette méritocratie est une histoire que les développeurs se racontent à eux-mêmes pour les aider à se forger une identité commune.

En d’autres termes, l’idée que les logiciels libres et open source sont une méritocratie est aussi vraie que de dire que les États-Unis sont une terre d’opportunité, ou que les scientifiques sont objectifs. Pour les membres de la communauté des logiciels libres et open source cette idée est primordiale dans leur perception du système et leur perception d’eux-même, car ils ont foi en cette idée que le travail est récompensé par la reconnaissance de leurs pairs et l’attribution de plus de responsabilités

Afin de perdurer, il faut que le mythe renferme une part de vérité, et ainsi personne ne le remet en question. Des exceptions peuvent survenir, mais elles seront justifiées, voire niées.

Cependant, si les mythes de la communauté ne sont pas des mensonges, ils ne révèlent pas toute la vérité non plus. Ils sont souvent des versions simplifiées de situations bien plus complexes.

La méritocratie dans les logiciels libres et open source n’échappe, à mon avis, pas à ce constat. Selon le contexte, si vous contribuez dans un bon projet et faites les choses biens, l’aspect méritocratique des logiciels libres et open source s’ouvrira à vous, c’est souvent le cas.

Mais de là à dire que les communautés ne fonctionnent qu’au mérite, il y a un pas que je ne franchirai pas. Le mérite n’est qu’un facteur à prendre, parmi tant d’autres, le mérite seul ne vous accordera ni reconnaissance, ni responsabilités. Bien d’autres considérations, souvent ignorées, entrent en jeu.

Hypothèses contestables

En invoquant l’argument du mérite on tourne rapidement en rond, c’est l’un des problèmes d’une méritocratie. Une hiérarchie est déjà établie, oui, mais comment ? Au mérite. S’ils n’avaient pas de mérite, ils n’auraient pas leur place.

Pas besoin de chercher bien loin pour voir que seul le mérite ne compte pas dans la hiérarchie des logiciels libres et open source. Les fondateurs du projet, en particulier, ont tendance à conserver leur influence, peu importe l’importance de leurs dernières contributions… si tant est qu’ils contribuent toujours au développement.

Par exemple, lorsque Ian Murdock fonda Progeny Linux Systems (entreprise pour laquelle j’ai travaillé) en 2000, il n’avait pas participé au projet Debian depuis quelques années. Et malgré cela, lorsque l’entreprise s’intéressa à Debian, son statut n’avait pas bougé. Tout portait à croire qu’il n’allait pas s’impliquer personnellement dans le projet et pourtant, s’il n’avait pas refusé la proposition, on lui aurait malgré tout attribué le titre de Debian Maintainer sans passer par le processus habituel.

Plus récemment, Mark Shuttleworth est devenu dictateur bienveillant à vie pour Ubuntu et Canonical, non pas à cause de ses contributions aux logiciels libres, mais parce qu’il disposait de l’énergie et de l’argent pour se propulser à ce rang. Sa position au sein d’Ubuntu ou de Canonical n’est pas remise en cause, mais toujours est-il qu’elle ne doit rien au mérite (au sens où l’entend la communauté), mais plutôt à son influence.

Et les leaders ne sont pas les seuls à gagner de l’influence pour des raisons autres que leur mérite. Dans les projets où certains contributeurs sont rémunérés et d’autres bénévoles, les contributeurs rémunérés ont presque toujours plus d’influence que les bénévoles. Dans certains cas, comme sur le projet OpenOffice.org, les contributeurs salariés peuvent presque entièrement éclipser les bénévoles.

D’autres projets, comme Fedora, repartissent l’influence plus équitablement, mais les contributeurs payés occupent souvent des postes à responsabilité. Par exemple, des dix membres du comité d’administration de Fedora, sept sont des salariés de Red Hat. Idem pour openSUSE où trois des cinq membres du comité sont des employés de Novell, le principal sponsor du projet, et un autre est consultant spécialisé dans les produits Novell. Et la situation est similaire dans bon nombre d’autres projets.

Alors oui, vous allez me dire que les membres payés ont plus de temps à accorder à ces responsabilités. C’est juste, mais ce n’est pas le sujet. Le fait est que les membres payés occupent statistiquement plus de postes à responsabilité que les bénévoles. Et c’est toute le postulat de départ qui est remis en cause, on constate alors que votre statut dans le projet n’est pas directement déterminé par votre mérite.

D’autres moyens de se faire remarquer

La méritocratie semble être le système parfait en théorie. Mais le fait est que la théorie est rarement mise en pratique. Avant de le reconnaître, encore faut-il déjà définir ce qu’est le mérite, la communauté des logiciels libres et open source ne fait pas exception.

Bâtie sur le code, la communauté des logiciels libres et open source valorise principalement la capacité à coder, bien que les plus gros projets soient beaucoup plus variés : tests, rédaction de la documentation, traduction, graphisme et support technique. De nombreux projets, comme Fedora et Drupal, évoluent et tentent de gommer cet a priori, mais cela demeure vrai pour la plupart des projets. Ainsi, les noms connus dans les projets ou les personnes qui font des présentations lors des conférences sont majoritairement des développeurs.

Cet a priori est cependant justifié. Après tout, sans le code, le projet de logiciel libre ou open source n’existerait pas. Et pourtant, le succès du projet dépend autant des autres contributions que du code lui-même.

Et comme le fait remarquer Kirrily Robert, blogueur chez Skud, même si certaines contributions sont moins estimées que d’autres, ça n’est pas une raison de les occulter complètement.

Par exemple, la personne la mieux placée pour écrire la documentation pourrait bien être le chef du projet, mais peut-être alors a-t-il mieux à faire que de rédiger la documentation. Il vaut peut-être mieux qu’une autre personne, même moins douée, rédige la documentation. Dans ce cas, celui qui écrit la documentation devrait être remercié, non seulement pour son travail, mais aussi parce qu’il libère l’emploi du temps du chef du projet. Et pourtant ceci est rarement reconnu dans les projets de logiciels libres ou open source.

L’idée que le mérite soit remarqué, reconnu et recompensé est rassurante dans notre culture industrielle moderne. J’aurai même tendance à penser que c’est encore plus rassurant dans le cercle des logiciels libres et open source, dont de nombreux membres admettent être introvertis, voire même se diagnostiquent eux-mêmes comme étant victime du syndrome d’Asperger.

Mais le mérite est-il toujours reconnu dans les logiciels libres et open source ? Voici ce que Noirin Shirley écrit à propos des obstacles à franchir par les femmes pour participer à cet univers :

Souvent, les valeurs reconnues dans une méritocratie deviennent rapidement le couple mérite/confiance en soi et obstination, dans le meilleur des cas. « Le travail bien fait ne vous apporte pas d’influence. Non, pour gagner de l’influence il faut faire du bon travail et bien s’en vanter, ou au minimum le rappeler à tout le monde régulièrement. » Les femmes échouent à cette étape là.

Shirley suggère ici qu’il faut non seulement être bon et régulier, mais il faut aussi savoir se rendre visible sur les forums, chats et listes de discussion, ainsi qu’aux conférences. Puisque les femmes sont apparemment conditionnées culturellement pour ne pas se mettre en avant, elles sont nombreuses à ne pas être à leur avantage dans un projet de logiciel libre ou open source (idem pour les hommes manquant de confiance en eux). Si elles ne peuvent ou ne souhaitent pas s’auto-promouvoir un minimum, leurs idées peuvent passer inaperçues, être sous-estimées ou carrément écartées.

À l’inverse, selon la même logique, certains gagnent en autorité plus parce qu’ils sont sociables ou opiniâtres que pour ce qu’ils réalisent concrètement (j’ai quelques exemples en tête, mais je ne veux pas faire d’attaque personnelle).

Tout comme la démagogie peut pervertir la démocratie, l’auto-promotion peut pervertir la méritocratie. Si un projet n’y prend pas garde, il se retrouvera bien vite à accepter des contributions, non pas sur la base de leur qualité, mais à cause de la visibilité et de l’insistance de celui qui les propose.

L’attraction sociale et comment s’y soustraire

Dans Le mythe de la méritocratie, Stephen J. McNamee et Robert K. Miller, Jr. avancent que la méritocratie aux États-Unis est influencée par ce qu’ils nomment l’attraction sociale. Ce sont des facteurs comme l’origine sociale ou l’éducation qui peuvent modifier positivement ou négativement la perception qu’ont les autres de nos contributions.

D’après moi, l’attraction sociale touche aussi la communauté des logiciels libres et open source, pas simplement parce qu’elle fait partie de notre société industrielle moderne, mais pour des facteurs qui lui sont propres. Reconnaître son existence n’est pas forcément facile, mais ça n’est pas pour autant une remise en cause de la méritocratie dans les logiciels libres et open source. L’importance du travail réalisé par les contributeurs n’en est pas non plus amoindrie.

Au contraire, reconnaître l’existence de l’attraction sociale peut être un premier pas pour améliorer la méritocratie dans le monde des logiciels libres et open source.

Kirrily Robert émet une idée intéressante. À l’instar des auditions anonymes où les musiciennes sont plus facilement choisies lorsque le sexe de la personne qui postule n’est pas connu, Robert propose que les soumissions soient également anonymes afin que leur évaluation ne soit pas biaisée. Si l’augmentation des contributions féminines lui tient à cœur, ces soumissions anonymes pourraient aussi garantir que seul le mérite entre en ligne de compte pour chaque contribution.

Mais ce n’est là qu’une proposition. Si vous voulez que la communauté des logiciels libres et open source devienne véritablement méritocratique, alors elle doit avoir le courage se poser quelques bonnes questions.

Pour commencer, par quel autre moyen peut-on réduire l’importance de l’auto-promotion ? Comment peut-on s’assurer que les employés et les bénévoles soient réellement au même niveau ? Peut-on redéfinir le mérite pour qu’il ne reflète pas uniquement ce qui est lié au code, mais au succès global du projet ?

Répondre à ces questions n’affaiblira pas le principe du mérite. Au contraire, ce principe de base de la communauté devrait en ressortir renforcé, et mieux utilisé. Et c’est, sans aucun doute, ce que souhaite tout supporter des logiciels libres et open source.

Paint.NET^[1] est un très bon logiciel libre de retouches d’images pour Windows. De l’avis de beaucoup, bien plus « sexy » et accessible au grand public que Gimp par exemple.

Sauf qu’il possède deux défauts, un petit et un bien plus grand, éliminatoire même. Il nécessite, comme son nom l’indique, l’implémentation préalable du framework .NET de Microsoft, mais surtout il a très vite été un logiciel libre contesté qui n’avait en fait de logiciel libre que le nom, ou plutôt « que » la licence (en l’occurrence la licence MIT).

Contrôle du code, communauté inexistante et absence des dernières version des sources à télécharger, faisaient en effet de ce logiciel un exemple emblématique de « fauxpen source ». De l’aveu même de Rick Brewster, son unique développeur : « le code source était publié mais il n’a jamais été question d’un projet ouvert et collaboratif qui acceptait des soumissions de code non sollicitées ». Il appelle d’ailleurs cela un logiciel « released sources ».

Aujourd’hui les choses sont clarifiées. Rick Brewster a décidé il y a un mois de changer la licence pour en faire un vrai logiciel propriétaire gratuit (ou freeware). « You may not modify, adapt, rent, lease, loan, sell, or create derivative works based upon the Software or any part thereof », peut-on lire sur l’article de son blog qui annonce la nouvelle.

Cette nouvelle n’est pas forcément bonne (un logiciel qui quitte la lumière pour rejoindre le côté obscur de la force) mais elle est logique et cohérente vue l’évolution de l’application. Il nous a cependant semblé intéressant de traduire cet article, d’abord pour mieux comprendre les motivations de cette migration à contre-courant, mais aussi parce que les arguments avancés sont autant de justifications plus ou moins convaincantes qui vous feront peut-être réagir dans les commentaires.

Une nouvelle licence pour Paint.NET 3.5

A new license for Paint.NET v3.5

Rick Brewster – 9 novembre 2009 – Blog personnel
(Traduction Framalang : Jimbo)

Au fil des années, j’ai été obligé de me battre avec un certain nombre de personnes, et de sociétés, qui tentaient de plagier Paint.NET en recompilant le programme sous une dénomination commerciale différente et en insérant leur propre nom dans les crédits. Parfois, ils se faisaient payer pour ce service. J’ai même créé mon propre terme pour désigner cela : un « backspaceware » (NdT : en français cela donnerait quelque-chose comme « effaciciel », le backspace étant la touche « retour en arrière », qui permet d’effacer le dernier caractère tapé). En outre, de temps en temps, on trouve Paint.NET en vente sur eBay.

Et, comme beaucoup d’entre vous le savent, Paint.NET était open source. Ou plutôt, il était « released sources » (NdT : C’est-à-dire « sources publiées ») : le code source était publié mais il n’a jamais été question d’un projet ouvert et collaboratif qui acceptait des soumissions de code non-sollicitées. J’aimais publier le code source, parce qu’il me semblait bon de permettre à d’autres de l’étudier. Il y a environ un an, fatigué de voir ces versions plagiées de Paint.NET et j’ai décidé de retirer le code source du site Web. Cependant le code source était toujours dans la nature en différents endroits d’Internet (ce qui n’est guère illégal). Même sans le code source, une personne maline et douée pouvait probablement encore décompiler, modifier puis recompiler le programme, afin de lui faire dire ou faire ce qu’elle voulait.

Le plus gros problème était que, même si ces actions déplorables manquaient clairement d’éthique, le licence MIT autorisait tout cela. Ou, du moins, dans certains cas particuliers, ce qu’elle interdisait n’était pas clair. Donc, d’un point de vue juridique, ce qui pouvait précisément être entrepris à ce sujet n’était pas clair. Je ne suis pas juriste et je ne voulais pas dépenser des milliers de dollars pour avoir une explication de tout cela. Quelques personnes ont affirmé que j’avais choisi la mauvaise licence et, avec le recul, c’est sans aucun doute exact.

En outre, tout ceci va plus loin que le plagiat ou ma propre tension artérielle. La publication de copie dérivées de Paint.NET est source de confusion et perturbe la plupart des utilisateurs. J’ai reçu des e-mail de personnes troublées parce qu’elles pensaient que Paint.NET avait été renommé et que des fonctions manquaient dans « la nouvelle version ». Ces copies dérivées provoquent du désordre puisque souvent elles désinstallent le vrai Paint.NET (avec la même interface graphique que pour l’installation Windows) tout en conservant le système de mise à jour d’origine. Ce qui signifie que lorsque vous installez une telle copie dérivée, elle supprime Paint.NET, et puis lorsque Paint.NET est mis à jour, il désinstalle la version dérivée et la remplace par Paint.NET, etc… Ou la version modifiée plante, et le rapport de bugs indique à l’utilisateur de l’envoyer à mon adresse mail. Il y a aussi a risque réel de trojans et de virus.

Tout est désormais fini.

Pour la version finale de Paint.NET 3.5, qui ne devrait plus tarder, j’ai modifié la licence. Pour la plupart des utilisateurs, cela n’aura aucun impact. C’est toujours un freeware. Il n’y a toujours aucune prétention sur les fichiers créés, ouverts ou sauvés avec Paint.NET. Vous pouvez toujours établir un miroir du fichier zippé à télécharger sur votre site web (par exemple Betanews, Download.com, etc.) sans en demander la permission. Vous pouvez toujours vendre des trucs que vous créez avec Paint.NET (pour autant que vous ayez le droit de le faire bien sûr). Vous pouvez continuer à utiliser dans un contexte commercial, et à l’installer sur autant de machines que vous le désirez.

Cependant, la licence spécifie que vous ne pouvez plus modifier Paint.NET lui-même, ou créer une œuvre dérivée basée sur le logiciel Paint.NET (c’est-à-dire un logiciel dérivé). Vous ne pouvez pas non plus le vendre. Je ne pense pas que cela aura un impact sur quiconque d’autre que ceux qui désirent plagier ou détrousser Paint.NET. Je ne vais implémenter aucune restriction quant au reverse engineering ou la décompilation, par exemple à l’aide de Reflector. Je pense que ce serait bête, et je crois encore de tout mon cœur qu’il est bon qu’on soit capable d’étudier le code de Paint.NET, quand bien même il ne s’agit que du démontage approximatif fourni par Reflector. Toutefois, vous n’êtes pas autorisé à modifier et recompiler une nouvelle version de Paint.NET à partir de ce démontage.

Cette décision créera à n’en pas douter de la confusion. Par exemple, « Est-ce que les plugins sont autorisés ? ». Oui, absolument: le programme est conçu pour accepter ces dernier et ils ne constituent pas une modification de Paint.NET lui-même. Je devrai certainement mettre la FAQ à jour sur cette question, comme sur d’autres.

Je m’attends à ce qu’il y ait une minorité bien en voix qui condamne ce changement de licence. Avant de vous exprimer, veuillez vous poser cette question : cela vous touche-t-il réellement ? Comptiez vous vraiment faire quelque chose que cette nouvelle licence interdit ? Je parie que la réponse est « non », mais, je vous en prie, postez un commentaire si la réponse est un véritable oui. Beaucoup de personnes ont condamné ma décision de supprimer le code source mais après enquête, il s’est avéré que c’était une pure question de principe : elles n’avaient jamais téléchargé le code source, jamais rencontré quelqu’un qui l’avait téléchargé, et jamais prévu de faire quoi que ce soit qui tirerait profit ou dépendrait de l’accès au code source. Je comparerai cela à être contrarié par le fait que votre passeport vous interdit de voyager en Antarctique : comptiez-vous vraiment vous rendre là-bas un jour ?^[2]

L’autre décision que je compte prendre est de publier le code source de portions de Paint.NET 3.5, probablement sous une licence de type MIT ou BSD. Les développeurs de plugins gagneraient en effet beaucoup à disposer du code source des effets graphiques et de certaines commandes relatives à l’interface WinForms. La meilleure façon de résumer les choses est de dire que la nouvelle licence (NdT : Voir les termes de la nouvelle licence sur l’article d’origine) couvre les « binaires », c’est-à-dire « ce que vous venez de télécharger et d’installer ». Je peux toujours créer des paquets à télécharger qui sont couverts par d’autres termes de licence. D’un point de vue de la philosophie, c’est peut-être déroutant, mais je suis prêt à en payer le prix.

Le code informatique écrit par des femmes serait-il plus « utile » que celui des hommes ?

C’est en tout cas ce qui ressort de ce récent article d’un blog du Wall Street Journal.

Il serait en effet mieux documenté et par là-même plus facilement exploitable par d’autres développeurs^[1].

L’occasion d’évoquer aussi peut-être dans les commentaires la problématique de l’écart des sexes dans le secteur informatique en général et dans la communauté du logiciel libre en particulier…

Les hommes écrivent du code provenant de Mars, et les femmes du code plus utile venant de Vénus.

Men Write Code from Mars, Women Write More Helpful Code from Venus

Rebecca Buckman – 6 juin 2008 – The Wall Street Journal
(Traduction Framalang : GaeliX et Burbumpa)

Nous savons tous que les hommes détestent demander leur chemin. Apparemment, ils détestent tout autant indiquer les directions dans le code informatique.

Emma McGrattan, première vice-présidente en ingénierie de la société Ingres spécialisée en bases de données, l’une des femmes développeuses les plus cotées de la Silicon Valley, insiste sur le fait qu’hommes et femmes ne codent pas de la même façon. Les femmes sont plus sensibles et plus attentives à ceux qui pourraient utiliser leur code ultérieurement. Elles parsèment leur code, vous savez, ces lignes d’instructions qui donneront naissance à d’astucieuses applications et programmes, de commentaires et consignes, expliquant avec précision pourquoi elles ont écrit leur code de cette façon là.

Le code devient alors une sorte de « feuille de route » pour ceux qui voudraient le modifier ou l’étendre par la suite, ajoute McGrattan, irlandaise de souche ayant rejoint Ingres en 1992.

Les hommes, d’un autre côté, n’ont pas les mêmes motivations. Souvent, « ils essayent de montrer combien ils sont intelligent en produisant du code cabalistique » dit-elle sur le blog Business Technology. « Ils essayent de dissimuler des choses dans le code », et ne laissent pas de consignes claires pour les futurs utilisateurs. McGrattan se targue de pouvoir, dans 70% à 80% des cas, déterminer à partir d’un morceau de code s’il a été écrit par un homme ou par une femme.

Par souci de rendre le code d’Ingres plus facile à utiliser et dépourvu de genre sexuel, McGrattan a aidé à la mise en œuvre de nouveaux standards de programmation au sein de la société. Elle demande aux développeurs d’inclure un certain nombre de commentaires précis avant chaque portion de code, expliquant ce que chacun fait et pourquoi; les développeurs doivent aussi fournir un historique détaillé de chaque changement effectué. Ces règles s’appliquent aussi bien aux employés d’Ingres qu’aux membres de la communauté Open Source qui participent au code des produits Ingres.

Il y a grand besoin de modifier le code à haute teneur en testostérone chez Ingres car seulement 20% des ingénieurs sont des femmes, précise McGrattan, la plupart d’entre elles ayant des postes liés à l’assurance qualité ou à l’adaptation à un nouveau pays et non à la programmation de haut vol.

Elle s’est donnée comme mission d’intéresser plus de femmes aux carrières dans le développement. Mais « cela s’avère très difficile » conclut-elle.

Petite traduction pédagogique sans prétention illustrant la paralysie qui affecterait Internet si le logiciel libre n’était plus là, permettant par là-même au grand public de se rendre compte par la négative de son importance et de sa diffusion^[1].

En fait si le logiciel libre n’existait pas il faudrait l’inventer…

A Day Without Open Source

William Hurley – 9 mai 2007
(Traduction Framalang : HL et Don Rico)

J’étais à une conférence quand deux techniciens entrèrent dans la salle de bar, l’un favorable au logiciel libre, l’autre résolument contre. Ils mirent le moulin en route après quelques verres et Mr Contre remarqua d’une voix forte : « Le logiciel libre, je voudrais bien que ça dégage ! Ça crée plus de problèmes que ça n’a d’avantages.» Déclarations avec lesquelles, de toute évidence, j’ai quelques difficultés. Bon, je sais que la plupart des gens ne comprennent pas le rôle du logiciel libre dans notre monde, ou ignorent combien de services que nous tenons pour acquis disparaitraient sans sa présence. Si vous êtes membre du club, vous voyez probablement où je veux en venir.

Imaginons qu’au douzième coup de minuit, tout logiciel libre s’évapore comme par magie. Qu’est-ce qui fonctionnerait encore demain ? Pour commencer, Internet « disparaîtrait » pour l’utilisateur moyen. La plupart des serveurs de nom de domaines (DNS) fonctionnent sous des logiciels libres comme BIND, qui transforme www.framablog.org en une adresse IP du serveur adéquat. On perdrait en route la majorité des utilisateurs de base d’Internet. Bien sûr, BIND n’est pas le seul logiciel libre pour les DNS. Et toutes les solutions logicielles pour DNS ne sont pas libres.

Mais supposons que les DNS fonctionnent toujours, ou que par hasard vous avez mémorisé 72.14.207.99 au lieu de www.google.com. Même si les serveurs de noms de domaines fonctionnaient, Google disparaîtrait complètement d’Internet. Google tourne essentiellement sous Linux – qui est sans doute le plus populaire des systèmes d’exploitation libres de la planète. Pas de souci. Vous n’avez qu’à aller voir chez Yahoo!, Pas vrai ? Eh bien non. Yahoo! est l’un des plus grands consommateurs d’un autre système d’exploitation très répandu issu du libre : FreeBSD. A présent, vous vous êtes résigné à essayer 207.68.172.246. Nous savons tous qu’ils n’utilisent pas de logiciel libre, et qu’ils s’échinent depuis un bout de temps sur cette fonction de recherche.

OK, MSN est là, paré à la manoeuvre, alors maintenant lançons une recherche. J’ai entendu un remix sympa de Shakira à la radio ce matin, c’est ce que je vais rechercher. MSN me renvoie une liste de sites qui proposent la chanson… Je clique dessus… et… rien. Pas de dance music ? Pas de rythmes latinos ? Plus de 60% des sites Internet tournent sous Apache, un serveur web issu du libre. Avant même que je ne clique sur un lien, mes chances de succès ont été réduites à 4 sur 10.

Sur les 118 023 363 sites recensés jusqu’à présent par NetCraft ce mois de mai, un petit peu plus de 70 millions ne fonctionneraient plus si le logiciel libre venait à disparaître. Certes, Apache n’est pas le seul seveur web issu du libre et… Vous connaissez la suite. Je pourrais continuer des heures et des heures sur vos transactions en ligne, qui ne pourraient être sécurisées sans OpenSSH et OpenSSl et tous les autres services auxquels des utilisateurs ont recours tous les jours et qui, selon ce scénario, n’existeraient pas.

Le logiciel libre n’est pas une nouvelle tendance. Ce n’est pas un phénomène de mode éphémère. Il est partout, que vous le reconnaissiez ou non. De Linux intégré aux nouveaux routeurs sans fil en passant par Firefox, le navigateur libre le plus utilisé au monde, le logiciel libre est la force motrice d’Internet et d’innombrables autres technologies.

Vous savez déjà que je suis un inconditionnel du libre, mais vous, qu’en pensez-vous ? J’aimerais connaître votre avis sur la façon dont la disparition du logiciel libre vous affecterait.