L’image ci-dessous représente la copie d’écran d’une nouvelle distribution GNU/Linux qui se veut entièrement libre et bootable sur une clé USB.

Un peu comme notre Framakey Ubuntu-fr Remix, sauf qu’Ubuntu n’est pas « entièrement libre » au sens que lui donne la Free Software Foundation (principalement à cause des drivers graphiques propriétaires inclus dans la distribution, attention troll détecté !).

Elle porte le nom de RMS’s Mostly Slax (codename pour la version 1.2 : Rose), acronyme récursif faisant un double clin d’œil à Richard Matthew Stallman et à l’héritage de la distribution Slax.

RMS GNU/Linux-Libre !

RMS GNU/Linux-Libre!

Mattl – 11 février 2009 – FSF Blogs
(Traduction Framalang : Quentin)

RMS GNU/Linux-Libre est un projet visant à créer une distribution GNU/Linux composée uniquement de logiciels libres et qui soit assez petite pour tenir sur une clé USB. tion-gnu-linux-rms-mostly-slax La distribution, qui promet d’être le parfait compagnon des amoureux de la liberté, aura la capacité de garder les modifications sur la clé, ainsi que d’installer, de mettre à jour ou de désactiver les paquets logiciels dans une application de gestion des modules.

Le nom de cette distribution, RMS’s Mostly Slax, est à la fois un hommage au fondateur du système d’exploitation GNU, mais aussi une référence à l’histoire de ce projet, basé sur SLAX (elle même basée sur la vieille Slackware). RMS présente la version 2.6.27.42 de Linux-Libre, un projet pour modifier le noyau Linux et supprimer tout firmware et bouts de code propriétaire, ainsi que le navigateur GNU Icecat et l’environnement KDE 3.5. D’autres modules sont aujourd’hui en développement et devraient être prochainement disponibles au téléchargement sur le site du projet.

On trouvera une liste de distributions libres sur le site du projet GNU.

Que va-t-il se passer en 2010 dans le monde de l’open source et du logiciel libre ?

Seul Nostradamux le sait.

Mais le journaliste Bruce Byfield s’est tout de même risqué au jeu des prédictions dans un article que nous avons traduit avec un petit mois de retard (ouf, il était temps !).

Tout comme nous, vous ne serez pas forcément d’accord sur tout. Il va alors sans dire que les commentaires sont là pour accueillir vos critiques et vos propres plans sur la comète^[1].

L’open source en 2010 : Neuf prédictions

Open Source in 2010: Nine Predictions

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

Même si c’est la fin de la décennie seulement pour ceux qui ne savent pas compter, les rétrospectives semblent plus à la mode que les prédictions en ces derniers jours de 2009. Peut-être aussi qu’après une année de récession, les experts de l’avenir deviennent plus prudents.

Mais, n’étant pas de ceux qui suivent les tendances et n’étant pas du genre nostalgique, je préfère tourner mon regard vers le futur, pour envisager ce qu’il pourrait réserver aux logiciels open source. Tout bouge dix fois plus vite dans l’open source que dans l’informatique grand public, et 2010 risque bien de ne pas déroger à la règle.

Je pense que nous pouvons considérer comme acquis que l’open source va continuer à gagner en popularité. 2010 ne sera pas cette légendaire « Année où Linux se démocratise », mais nous devrions continuer à observer la même lente et constante progression de son adoption que dans la dernière décennie.

Mais quoi d’autre ? Permettez-moi de prouver ma témérité en faisant neuf prédictions sur ce que 2010 nous réserve sur le plan des communautés, de la technologie et de l’économie de l’open source.

1. L’arrivée des pilotes vidéos totalement libres

Les utilisateurs ont dû attendre longtemps pour avoir des pilotes vidéo open source aussi performant que leurs pendants propriétaires. Mais d’ici à la fin de l’année prochaine cela pourrait bien se concrétiser. Les pilotes Intel sont déjà stables, et utilisés sur plus de 25% des ordinateurs open source.

Quant aux autres cartes graphiques, le noyau 2.6.33 de Linux devrait apporter une meilleure gestion des cartes ATI et NVIDIA. Attendez-vous donc à de gros progrès d’ici à la fin de l’année. Et dans le pire des cas, si des fonctions manquent encore, elles devraient être au point pour la mi-2011^[2].

2. La communauté crééra un fork de MySQL

Quand Oracle a racheté Sun Microsystems en avril 2009, ils ont également acquis MySQL, la base de données la plus populaire d’Internet. Huit mois plus tard, le sort réservé par Oracle à MySQL est toujours incertain et les gens s’inquiètent.

Richard Stallman a demandé publiquement à Oracle de rendre MySQL à la communauté, alors que Monty Widenius, le créateur de MySQL, a initié une campagne de rédaction de lettres à la Commission européenne pour éviter le démembrement de la base de données par Oracle.

Étant donné qu’il semble n’y avoir aucune logique juridique pour aider ces campagnes, je pense qu’ils vont échouer. S’ils y arrivent, la méfiance envers Oracle aura certainement raison de l’intégration de MySQL dans les distributions open source.

Il y a de grandes chances que la communauté privilégie des forks existants de MySQL, probablement MariaDB de Widenius, qui est déjà intégrée au Launchpad d’Ubuntu. PostgreSQL, l’autre grande base de données open source, ne devrait pas tant en profiter car elle semble moins adaptée aux besoins des sites Web.

3. La sortie de Gnome 3.0 risque de déclencher une révolte chez les utilisateurs

Il y a deux ans, un vent de révolte accompagna la sortie de KDE 4.0, car cette nouvelle version instaurait une rupture avec les précédentes (des fonctions clés n’y étaient pas encore intégrées). GNOME 3.0, provisoirement prévu pour septembre 2010, ne devrait pas souffrir du même manque de fonctionnalités, mais les premières versions suggèrent un style nouveau, comme KDE 4.0 (et les premières réactions montrent que les utilisateurs y seront aussi hostiles).

L’avantage de GNOME est que ses développeurs peuvent bénéficier de l’expérience de KDE. Aucune hostilité n’est permanente, surtout si la prochaine version a une feuille de route claire.

Tout de même, les plaintes peuvent être spécialement fortes ou longues, qui sait ? Peut-être que les critiques envers GNOME attireront plus d’utilisateurs vers KDE ou vers des environnements graphiques moins connus comme Xfce.

4. La différence entre Logiciel Libre et Open Source va se creuser davantage

De l’extérieur, open source et logiciel libre sont des noms différents désignant le même phénomène. Cependant pour beaucoup de membres de communautés c’est comme dire que le Protestantisme n’est pas différent du Catholisisme. Malgré bon nombre de similarités l’open source est un mouvement de développeurs qui vise à perfectionner la qualité du code source, alors que le mouvement du logiciel libre se concentre sur les libertés accordées à l’utilisateur^[3].

Dans la pratique, les deux philosophies coexistent (souvent à l’intérieur d’un même projet). Cependant, de temps à autre, ces membres rentrent en conflit. Le dernier conflit majeur était il y a deux ou trois ans à propos de la version 3.0 de la licence GNU GPL (GNU General Public License), qui donnait plus d’importance au logiciel libre que la version 2.0.

Le problème suivant qui provoquera un conflit reste incertaine. Cependant, les personnes soutenant le logiciel libre n’ont jamais été timides sur le fait d’exprimer leurs opinions, et les adhérents de l’open source sont devenus de plus en plus méprisants envers le logiciel libre en général et leur fondateur Richard Stallman en particulier. Dans la même veine, la rhétorique est devenue si méprisante que le conflit semble n’être qu’une question de temps.

Il y a deux ou trois semaines, le problème le plus probable apparaissait être le possible retrait de GNOME du projet orienté logiciel libre GNU, un changement qui ne signifierait presque rien dans la pratique, mais qui serait probablement perçu comme une preuve que GNOME est désormais clairement dans le camp de l’open source. Le problème, cependant, est plus complexe que la contestation du conflit lui-même.

5. L’open source sera encore confronté au sexisme

2009 nous a montré une série d’évènement dans lesquels des gens comme Richard Stallman^[4] et Mark Shuttleworth ont été accusés de sexisme à cause de remarques faites en public.

Et avec l’observation que les femmes sont sous-représentées dans l’open source, 2009 a été l’année où la communauté a semblé découvrir cette problématique^[5].

6. Google Chrome OS inaugurera les OS dans les nuages

Chrome OS, le système d’exploitation dans les nuages de Google, devrait sortir dans la deuxième moitié de 2010. Étant donné ce que l’on dit toujours sur l’état des version bêta des produits de Google, personne ne sera surpris que version finale soit retardée. Mais 2010 montrera, au moins, une version bêta avancée ou une release candidate. Malgré l’existence de Jolicloud, la majorité des utilisateurs verra Chrome OS comme le premier système d’exploitation dans les nuages.

Chrome OS devrait être téléchargé des millions de fois dans le premier mois de sa sortie, du fait de sa nouveauté. De plus, Google est en train de travailler avec les fabricants de matériel pour être sûr que Chrome OS sera supporté. Malgré tout, une grande partie des utilisateurs resteront sceptiques à l’égard de Chrome OS. Beaucoup d’entre-eux ont déjà de sérieux doutes sur les systèmes d’exploitations dans les nuages, et jusqu’à présent ils y sont moins à l’aise que sur les systèmes d’exploitations traditionnels, desquels ils sont censés être ainsi délivrés.

Je pense et j’espère que Chrome OS ne sera rien de plus qu’un produit de niche. De toutes les façons, on aura quand même le verdict sur la validité du concept avant la fin de 2010.

7. Mozilla Firefox et Google Chrome se disputeront la première place

Même si je ne me trompe pas en affirmant que Chrome OS ne suscitera que peu d’engouement, ce qu’il restera après sa disparition c’est bien le navigateur Chrome. Sa vitesse et son aspect multitâches sont des défis que devra relever Mozilla Firefox avec habileté pour lui faire face, d’autant plus que Chrome pourrait signifier une interruption du soutien de Google dans le développement de Mozilla.

Pour le moment, le plus grand avantage de Firefox réside dans ses milliers d’extensions. Bien que les premières extensions pour Chrome soient d’ores et déjà disponibles, elles ne battront pas celles de Mozilla en nombre ou en polyvalence avant quelques années (et ceci seulement s’il se forme une large communauté).

Cette situation veut dire que Chrome n’est pas plus prêt à dépasser Mozilla que Mozilla est prêt à dépasser Internet Explorer dans les prévisions futures. Cependant, en 2010, Chrome peut ronger la base des utilisateurs de Firefox sur le même principe que Firefox le fait avec ceux d’Internet Explorer.

8. Raindrop et Wave ne vont pas réussir à trouver des utilisateurs

Par coïncidence, deux des nouvelles applications que nous trouvons prometteuses pour 2010 sont Mozilla Raindrop, un outil de réseau social et de messagerie électronique one-stop^[6], et Google Wave, un outil collaboratif.

Les deux sont intéressants pour les développeurs et les ergonomes. Cependant, à l’heure où j’écris ces lignes, Raindrop n’est pas encore sorti, et Wave est seulement accessible sur invitations. Je serais surpris que l’un ou l’autre devienne un grand succès. Il s’agit en effet de résoudre des problèmes que les utilisateurs ne voient pas comme tels. Je n’ai simplement pas l’impression que les utilisateurs souhaitent centraliser leur messagerie, ou soient particulièrement intéresses par une collaboration en temps-réel.

Même si les utilisateurs se montrent motivés, Raindrop et Wave sont tous les deux en l’état trop compliqués et spécialisés en l’état pour qu’ils soient réellement adoptés. Un réajustement est nécessaire. Les critiques seront probablement enthousiastes, parce qu’ils font partie des utilisateurs expérimentés. Et les autres utilisateurs ? Pas tellement.

9. Le Nexus One ne sera qu’un jouet pour les geeks

Dans le courant du mois de janvier, le Nexus One de Google va être disponible^[7]. Le Nexus One a fait un gros (bien que pas totalement favorable) buzz à l’intérieur de la communauté des techniciens, mais on peut se demander se faire une place.

D’après des rapports, le Nexus One n’inclura pas de fonctionnalités qui aurait pu lui attirer les faveurs du grand public. En plus, il va entrer sur le marché des téléphones mobiles déjà saturé, et Google ne possède pas la réputation d’Apple. Sans compter qu’il sera d’autant moins aidé que, au début, il ne sera pas vendu par les opérateurs de téléphonie mobile, et ne sera pas non plus dans les boutiques. En ces circonstances, je pense que il se vendra principalement aux développeurs, et qu’il peinera à élargir ce cercle^[8].

Avec un peu de recul

Cette liste a été établie en toute indépendance. Pourtant, en la relisant, je réalise que quatre des neuf prédictions impliquent Google. Cette observation suggère une meta-prédiction : 2010 sera une année cruciale pour Google. Son évolution de développeur en acteur majeur aussi bien dans le logiciel que dans le matériel se joue cette année.

Connaissant l’histoire de Google, le succès de cette entreprise me laisse pessimiste. Et pourtant, Google lance tellement d’innovations que tôt ou tard, elle est susceptible de sortir quelque chose d’incroyable, la démonstration du paradoxe du singe savant peut-être tout simplement^[9].

Pour ce qui est de mes autres prédictions, même si je m’attends à des changements dans la communauté open source, je ne me prépare pas à l’Apocalypse. La communauté est vaste, les changements sont inéluctables, mais en même temps, cela n’aura pas forcément beaucoup d’impact sur les milliers de personnes qui envoient des correctifs quotidiennement. Sur le coup, les sentiments sont exacerbés, mais en fin de compte, la communauté poursuivra tranquillement sa route, même si de temps en temps le cours des choses sera perturbé par un événement imprévisible.

Et si jamais je me trompe ? Alors j’en appelle aux privilèges des voyantes et demanderait qu’il ne me soit pas tenu rigueur de mon manque de précision ou de mon incapacité à prévoir le futur et je me réserve le droit de retenter ma chance l’an prochain, sans que personne ne me rappelle à mes erreurs passées.

Si vous avez le malheur de développer un projet « open source » au sein de votre entreprise alors vous courrez le risque de voir arriver une « communauté » qui peut à tout moment s’agréger autour du code source de votre logiciel et en menacer sa bonne gouvernance.

Heureusement le développeur Josh Berkus est là pour vous expliquer point par point comment faire pour être certain de ruiner et dissoudre toute velléité communautaire (au cours d’une intervention donnée il y a un mois à la Linux.Conf.au et relatée ici par Jonathan Corbet)^[1].

Un article évidemment ironique (qui détourne les howto), mais qui donne à réfléchir sur les relations subtiles et complexes qui peuvent exister entre les communautés et les entreprises qui œuvrent sur un même projet.

Pas toujours facile de se comprendre en effet quand les uns disent plutôt « logiciel libre » et les autres plutôt « open source » (voire même parfois carrément « fauxopen source »).

Et puis, c’est pratique, puisqu’on dispose ainsi de tout ce qu’il ne faut pas faire pour réussir un projet communautaire.

On notera que Josh Berkus avait la société Sun Microsystems en tête lorsqu’il a énoncé son propos (Sun soutient notamment MySQL et OpenOffice.org). Mais comme il le précise lui-même a posteriori sur son blog, cela peut s’appliquer à n’importe quelle « corporate open source » et de citer alors entre autres Red Hat, Microsoft, IBM, Cisco, SugarCRM, Novell, Compiere, Borland, Google, ou encore Apple. « Si vous avez à faire à une compagnie qui possède un projet open source, vous pouvez être sûr à 95% qu’elle suit au moins un des dix points mentionnés ci-dessous »

Et de conclure positivement sur la nécessité de cultiver l’un des mots clés les plus importants de la communauté : la confiance.

Comment détruire votre communauté : mode d’emploi

How to destroy your community

Jonathan Corbet – 18 janvier 2010 – LWN.net
(Traduction Framalang : Olivier, Daria et Don Rico)

Le réputation de Josh Berkus en tant que hacker de PostgreSQL n’est plus à faire, mais ce n’est pas sa seule compétence, puisqu’il a aussi acquis une précieuse expérience durant sa pige au « Laboratoire de Destruction des Communautés », plus connu sous le nom de Sun Microsystems. Il y a suivi « l’enseignement breveté en 10 étapes » pour apprendre à débarrasser un projet de toute ingérence de la communauté.

La présentation très dynamique qu’a donnée Josh à la Linux.Conf.au sur le sujet était la première discussion de la miniconf L’économie de l’open source ; l’audience lui a réservé un accueil chaleureux.

Si vous êtes développeur dans une grosse entreprise, vous vous rendrez rapidement compte que les communautés de développement des logiciels libres sont une plaie. Dites adieu à vos plans marketing, par exemple, car elle se chargera d’introduire le logiciel dans des pays où vous êtes absents et pour lesquels vous n’avez pas de plan. Ils flanqueront par terre vos prévisions produits en sortant des innovations non-prévues, en implémentant des fonctionnalités des années avant ce que vous aviez planifié, ou pire encore, des fonctionnalités qui devaient être réservées à la version propriétaire de votre logiciel. Les communautés de logiciels libres sont d’éternelles insatisfaites, elles n’ont de cesse de vouloir améliorer les choses. Elles ont tendance à redéfinir les relations avec vos partenaires et vos clients, et vos commerciaux ne savent plus à quel saint se vouer. Et sans arrêt elles vous dérangent : un e-mail par ci, une conférence à laquelle vous devriez assister par là, etc.

Mais heureusement, des solutions existent pour vous débarrasser de la menace que représente cette communauté. Il suffit d’appliquer une ou plusieurs des étapes suivantes.

1. Rendez le projet dépendant d’outils complexes

Il a remarqué qu’en général, les entreprises n’ont pas de problème avec cette technique puisqu’elles aiment s’appuyer sur leurs propres outils. Pour les projets où la communauté n’est pas la bienvenue, il faut par exemple employer des systèmes singuliers qu’on ne trouve nulle part ailleurs. Un système de contrôle de version propriétaire (NdT : version control system) est absolument obligatoire. Mieux encore, un outil de suivi des problèmes (NdT : issue tracking system) avec un nombre limité de licences, afin que tout le monde doive s’y connecter avec le même compte.

N’oubliez pas de mettre en place un site Web qui respecte la parité : 50% du temps planté, 50% du temps opérationnel. Ne pas mettre de site à disposition ne suffira pas : dans de telles situations, la communauté a la fâcheuse habitude de créer le sien. Avec un site bancal, en revanche, vous vous en prémunirez et vous assurerez que l’information restera bien cachée.

2. Attirez les participants nocifs et optimisez les dégâts qu’ils peuvent engendrer

Ce cas particulier nécessite quelques étapes :

1. Prenez sur vous et engagez-vous dans de longs débats avec ces personnes et dénoncez-les sur les listes du projet.
2. Au bout d’un certain temps, bannissez-les par décret ; évitez à tout prix tout processus communautaire.
3. Les gens bannis déverseront leur bile ailleurs. Vous devez les suivre et poursuivre votre débat sur ces sites externes.
4. Enfin, la communauté se plaindra de ce comportement. Votre réponse sera simple : réintégrez les enquiquineurs à la communauté. Reprenez à la première étape et recommencez.

D’après Josh, un casse-pieds bien pris en main peut annihiler une communauté de plusieurs centaines de membres.

3. Ne fournissez pas de documentation

Aucune information utile ne devrait être disponible, ni pour le code, ni sur les méthodes de compilation, rien sur le processus de soumission de correctif, ni sur le processus de sortie, rien de rien. Puis, quand on demandera de l’aide, répondez « Lis la notice, bordel ! » (NdT : RTFM pour Read the fucking manual)

4. Prenez les décisions relatives au projet en petit comité

Pour bien commencer, vous pouvez organiser vos réunions en ligne en ne prévenant les participants que très peu de temps à l’avance. Pour que cette technique soit vraiment efficace, prévoyez ces réunions à des heures incompatibles avec le fuseau horaire commun à la plupart des membres de la communauté.

Le mieux est encore de tout faire en visioconférence : vous exclurez de fait environ un tiers de la planète pour qui elle se déroule de nuit, de plus, les gens ont un boulot, tant pis pour eux aussi. Mais le must reste encore d’organiser les réunions en personne au siège de la société.

5. Sortez la grosse artillerie juridique

S’impliquer dans le projet devrait rimer avec accords de participation alambiqués, contrats de licence protégeant le contenu du site Web, accords de confidentialité, marques déposées, etc. Pour ne pas faire les choses à moitié, tous ces documents devraient être modifiés en catimini à peu près tous les deux mois.

6. Choisissez avec soin l’agent de liaison avec la communauté

Votre meilleur candidat : quelqu’un de solitaire, quelqu’un qui n’a pas d’amis et qui n’apprécie pas vraiment les autres. Si vous n’en avez pas sous la main, prenez le membre de votre équipe qui a le plus de travail, quelqu’un avec des responsabilités en développement et en gestion, et qui travaille déjà au minimum 70 heures par semaine. Dans ce cas, il est primordial de ne pas le décharger de la moindre de ses responsabilités.

Quelqu’un qui ne maîtrise pas la technologie fera aussi l’affaire. Prenez un spécialiste de Java pour assurer la liaison dans un projet en Perl. Ou, si vraiment ces solutions ne sont pas possibles, laissez simplement la place vacante pendant des mois.

7. Rendez opaques les prises de décision

Les entreprises réfractaires aux communautés devraient, d’après Josh, s’inspirer des Nations Unies et créer des processus longs et complexes. Personne ne doit savoir qui prend réellement les décisions, c’est très bon pour transformer les contributeurs en éléments nocifs. Il va de soi que les règles devraient être immuables ou presque.

8. Faites n’importe quoi avec les licences

Les membres de la communauté étant souvent à cheval sur la question des licences, modifiez la licence et vous avez de bonnes chances de les faire fuir. Évoquer des changements de licence sans jamais vraiment rien modifier peut se révéler encore plus efficace : vous faites fuir les contributeurs actuels qui apprécient la licence choisie sans pour autant en attirer d’autres, adeptes eux de la future licence supposée.

9. N’accordez jamais, au grand jamais, l’accès au commit à quelqu’un d’extérieur à l’entreprise

Ce devrait être une règle (tacite évidemment) : seuls les employés peuvent avoir les droits de commit (NdT : avoir ces droits revient à avoir accès et contrôle sur le code source du dépôt officiel du logiciel). Vos réponses doivent être évasives, « problèmes légaux, on y travaille » est une bonne carte à jouer. Afin que cette mesure prenne tout son effet, choisissez un employé qui n’écrit pas de code et confiez lui l’accès au commit sur le projet.

10. Réfugiez-vous dans le silence

Laissez les questions sans réponse, ne dites rien. Maîtriser cette technique peut rendre, à elle seule, toutes les autres inutiles. C’est le meilleur moyen de détruire une communauté qui existe.

En conclusion, Josh ajoute que grâce à Sun, il peut témoigner de l’efficacité de toutes ces techniques. Mais Sun est loin d’être la seule entreprise dans cette situation. Un ancien du X Consortium a avoué à Josh qu’eux aussi avaient un jour recouru à chacune de ces méthodes. Ces compétences de destruction de communauté sont monnaie courante dans l’industrie du logiciel.

Mais que faire si votre entreprise veut au contraire se bâtir une communauté ?

Il paraît évident qu’elle devrait alors s’employer à appliquer à l’inverse les méthodes énumérées ci-dessus. Mais d’après Josh, la clé de voûte du système reste la confiance. À l’instar du mariage, développer une communauté peut prendre des années, mais une seule infidélité détruira la confiance qui en constitue le socle. Ainsi, une entreprise peut perdre la moitié de sa communauté en un week-end. Pour ne pas connaître ce triste sort, il faut avoir confiance en la communauté et agir de sorte que cette confiance soit réciproque.

D’un côté vous avez le « copyright » qui fait semble-t-il perdre la tête de certains musées lorsque l’on en vient à interdire à un enfant de dessiner une œuvre ou lorsque l’on menace d’une action en justice un contributeur bénévole de Wikipédia souhaitant enrichir l’encyclopédie avec des reproductions de peintures du domaine public.

De l’autre côté vous avez le « copyleft », qui pousse les gens à se rencontrer pour faire de belles balades dans le but d’améliorer l’iconographie photographique de leur ville dans Wikipédia.

Gardons l’état d’esprit du second pour pénétrer dans le premier et vous obtenez l’opération « Britain Loves Wikipedia » dont nous partageons l’enthousiasme de Glyn Moody sur son blog.

Et ce n’est rien moins que le prestigieux Victoria and Albert Museum qui inaugure l’évènement.

Je me prends à rêver de manifestations similaires en France où l’enseignant que je suis pourrait emmener ses élèves découvrir des musées tout en les sensibilisant à ce bien commun qu’est Wikipédia…

La Grande-Bretagne adore Wikipédia. Pas trop tôt…

Britain Loves Wikipedia – And About Time, Too

Glyn Moody – 1 février 2010 – Open…
(Traduction Framalang ; Don Rico)

L’un des rôles majeurs des musées est de participer à l’éducation en permettant au public de découvrir et d’étudier les chefs d’œuvres que recèlent leurs collections. Il pourrait donc paraître logique que ces institutions ne demanderaient qu’à voir des photographies de ces œuvres exposées dans la plus grande galerie en ligne au monde, Wikipédia. Pourtant, cette idée rencontre une certaine résistance çà et là, en raison, vous l’aurez deviné, d’une crispation maladive concernant le « copyright ».

C’est inepte à deux titres : d’une part, il s’agit d’œuvres anciennes, aussi l’idée que leur image devrait être protégée par le copyright est aberrante; d’autre part elle est contradictoire, car ce serait empêcher les visiteurs potentiels de savoir ce que proposent les musées, ce qui va à l’encontre de leurs intérêts.

Face à cette situation regrettable, je ne peux évidemment qu’applaudir cette initiative :

« Britain Loves Wikipedia » (La Grande-Bretagne adore Wikipédia) est une compétition et une série d’évènements qui se tiendra pendant un mois dans les musées partenaires à partir du 31 janvier 2010. La compétition, ouverte aux participants de tous âges, tous milieux et toutes origines, encourage le public à photographier les trésors de nos musées d’art et les incite à prendre une part active dans l’archivage numérique des collections nationales. Toutes les photographies qui entreront en lice pour la compétition « Britain Loves Wikipedia » seront mises à disposition sous licence libre sur le site Wikimedia Commons et pourront alors servir à illustrer les articles de Wikipédia.

Quel dommage que cette initiative ne soit pas systématique partout dans le monde.

L’âge de faire est un mensuel indépendant, sans publicité et à petit prix (1,50 €) qui cherche à sensibiliser un large public aux questions d’écologie, de citoyenneté, de solidarité.

Tiré à 25 000 exemplaires, il utilise un mode de distribution un peu particulier : plutôt qu’une diffusion en kiosque classique (mais coûteuse), ce journal s’appuie sur un réseau d’abonnés, de coopérateurs (invités à revendre leurs exemplaires), et de points relais volontaires.

Pourquoi donc en parler sur le Framablog ?

Parce qu’il existe des ponts naturels entre le logiciel libre et le « développement durable » (pris au sens noble et non marketing du terme).

Il nous arrive du reste d’en parler comme en témoigne notre tag « Écologie » regroupant divers billets autour du sujet^[1].

Ponts naturels que l’on pourrait assez paresseusement synthétiser par le diagramme ci-dessous :

Nous constatons par ailleurs que les rencontres et synergies se multiplient.

Ainsi le Festival du Développement Durable 2009 de Genève a accueilli plusieurs associations locales. C’est d’ailleurs à cette occasion et sous leur impulsion qu’est né le fort intéressant site Logiciels libres et développement durable d’où est issue l’illustration ci-dessus (pour l’anecdote on remarquera également cette très jolie Framakey durable en bois).

De même le Salon Primevère de Lyon accorde chaque année une place plus importante au logiciel libre (cette année le thème sera « Le prix de la gratuité » et de nombreuses associations du libre, dont Framasoft, y feront des conférences).

L’autre raison, c’est que le numéro actuel de L’âge de Faire (n°39 – février 2010) propose un excellent petit dossier d’une double page intitulée fort à propos : Et si on passait au libre ?

Suite à notre demande, l’auteur Didier Bieuvelet a tout de suite accepté d’en placer les articles sous licence Creative Commons By-Sa (articles dont les titres sont les suivants : Des logiciels citoyens, Témoignage d’un converti, Informatique libre et solidaire, Quels logiciels libres ?, Simple comme Ubuntu et De la vente liée à la vente forcée)

Vous trouverez donc :

• Les textes du dossier : au format ODT et au format PDF.
• Les pages originales du dossier au format PDF telles que vous pouvez les voir sur la copie d’écran : page 12 et page 13 (certaines photos n’étant pas sous licence libre, si un gentil volontaire souhaite refaire un PDF avec d’autres images libres pour diffusion/impression, nous nous ferons un plaisir de l’ajouter ici).

Quant au reste du journal, nous vous encourageons à vous rendre sur leur site pour vous le procurer.

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.

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.

Lu sur le site de l’AFUL : Éric Magnien, qui a gagné deux fois en justice contre le constructeur ASUS (lire le commentaire détaillé de la décision de justice par Me Frédéric Cuif), s’exprime dans le journal télévisé 19-20 de France 3 Bretagne le 21 décembre 2009 : Un Morbihannais en lutte contre Windows, par Géraldine Lassalle.

—> La vidéo au format webm

Transcript

Voix off : C’est un combat semblable à celui de David contre Goliath. Dans le rôle de David, Éric Magnien, régiseur de théâtre lorientais, dans le rôle de Goliath, le fabricant d’ordinateur Asus. Tout commence en mai 2008 quand Eric décide de s’acheter un ordinateur.

Éric Magnien : Je voulais acheter un ordinateur, mais je ne voulais pas des logiciels qui étaient installés avec, parce que j’utilisais déjà avec un autre ordinateur des logiciels libres, donc sous Linux.

Voix off : Pourtant Éric n’a pas le choix. il doit acheter l’ordinateur avec avec le système d’exploitation de Microsoft déjà installé. Il décide alors de demander au constructeur le remboursement des logiciels Windows dont il n’a pas besoin.

Éric Magnien : Il me demandait à ce que je renvois l’ordinateur à mes frais, à leur service après-vente à Paris, pour effacer totalement le disque dur et enlever l’étiquette de Windows. Donc c’était totalement inacceptable, pour un remboursement de 40 euros alors que dans le commerce ces mêmes logiciels coutaient 205 euros.

Voix off : S’engage alors une bataille juridique qui va durer plus d’un an. Avec l’aide de l’Association Francophone des Utilisateurs de Logiciels Libres (AFUL), Éric rassemble tous les elements demontrant l’abus dont il est victime. Face à lui une armée d’avocats experts, un combat inégal mais Éric sait qu’il est légitime. En août 2009 la justice condamne le constructeur.

Éric Magnien : C’est une procédure longue, difficile mais nécessaire, et qui vaut le coup parce que c’est notre droit. On a le droit d’obtenir réparation de ce genre de choses, on a le droit d’obtenir le remboursement de ces licences. Et donc c’est aussi pour une certaine idée du droit, de la justice, que j’ai été jusqu’au bout de la démarche.

Voix off : La décision de justice rendu par le tribunal de Lorient pourrait bien décider d’autres consommateurs à faire valoir leurs droits. Le 2 décembre dernier, la société Acer a été condamnée pour la cinquième fois pour des faits similaires.