—> La vidéo au format webm

En mai dernier paraissait une info très intéressante sur DLFP, titrée Une borne de distribution de logiciels libres à Bamako, dont on possède désormais deux petits reportages vidéos que nous vous présentons ci-dessus et ci-dessous.

L’association Kunnafoni et l’équipe Ubuntu Mali présentent La Source, un distributeur de contenus numériques : logiciels libres mais aussi d’autres ressources comme des livres, l’encyclopédie Wikipedia, des documentaires, des ressources éducatives et des clips vidéo d’artistes locaux.

Le fonctionnement est simple. Conçu comme un kiosque l’utilisateur se déplace dans les menus à l’aide de trois boutons et choisit le contenu qu’il veut transférer sur sa clé USB.

La Source répond à un besoin de diffusion de contenus qui soit bon marché et accessible au plus grand nombre. Si les connexions internet se démocratisent au Mali, elles restent inaccessibles au plus grand nombre et la seule alternative est d’utiliser les cyber cafés, et télécharger une distribution Ubuntu, ou les 500 Mo qui constituent Wikipedia dans un cyber n’est pas à la portée de toutes les bourses. De plus bien souvent les personnes ne savent pas qu’il existe des logiciels et des ressources libres et de bonnes qualité qui sont disponibles. Ce sont ces freins à la diffusion des ressources libres que La Source entend supprimer.

—> La vidéo au format webm

Les Rencontres Mondiales du Logiciel Libre portent parfois bien leur nom. Ainsi le mois dernier à Mont de Marsan, avons-nous fait la connaissance de Nathalie qui, tel un cadeau, nous a raconté une belle petite anecdote autour de la Framakey.

Il y a deux ans, la voici partie pour un séjour en Chine, avec décision de raconter son voyage au jour le jour sur un blog. Mais une fois sur place, problème : le surf sur internet dans les cybercafés visités semble soumis à une liberté contrôlée^[1].

Extrait issu du billet Cinquième jour : Arrivée a Fengkai du 16 juillet 2006 :

« Nous n’avons pas donné de nouvelles depuis deux jours. Pas faute de cybercafé. Dans le premier cybercafé où nous sommes allés, le proxy du navigateur empêchait d’envoyer quoique ce soit vers des sites européens, et même en lançant Firefox de ma clé USB, je n’ai pas réussi a contourner le problème, donc il devait aussi y avoir barrage par firewall. Le cybercafé essaye le lendemain semblait être encore plus bloqué au niveau des accès disque et du bureau mais ce n’était qu’en apparence. Ma petite clé a été reconnue et j’ai pu accéder au blog en écriture avec Firefox de Framakey. Génial, quel soulagement. Au passage, une pub pour Framakey car sans le concept de logiciels libres portables, nous ne serions en train d’écrire ni ce billet ni les suivants ; le blog était off pour quelques jours, et peut-être même jusqu’au séjour final a Pékin !!! Voila pour le point technique du blog, jure que ce n’est pas simple. Entre les menus de Windows, tous écrits en chinois, les sécurités locales imposées, cookies interdits par le navigateur local (accès aux options de IE interdits évidemment, firewall hyper blindé dès qu’il s’agit de sortir de Chine). Bref, cela relève presque du miracle si ce blog continue a exister 🙂 »

Vous vous rendez très bientôt à Pékin pour participer, couvrir ou assister à la grande messe olympique ?

Je ne sais si la situation a positivement évolué depuis mais, dans le doute, ne vous abstenez pas de glisser subrepticement une Framakey dans la valise 🙂

« Beaucoup d’utilisateurs étaient vraiment sympathiques, ils me remerciaient et m’encourageaient ! À chaque fois, cela ensoleillait toute ma journée… »

Ainsi s’exprime Laurent Cohen dans ce court mais enthousiaste témoignage d’un développeur de logiciel libre^[1].

Et puis, loin de moi l’idée d’idéaliser les choses^[2], mais pas une fois il n’est question d’argent. Parce qu’il est clair que, quand bien même de nombreux projets libres aient fortement besoin de soutiens financiers, ce n’est ni une fin en soi ni la principale source de motivation. La vérité est ailleurs, n’en déplaisent à certains…

Que signifie être un développeur Open Source ? Une histoire vécue de l’intérieur

What does it mean to be an Open Source author? A story from the inside

Laurent Cohen – 23 juin 2008 – JPPF Blog

J’entends parler tous les jours des projets Open Source, du modèle économique de l’Open Source, de ce que cela signifie en terme de liberté, de choix, de risques, d’investissements, etc. Ce dont je n’entends pas souvent parler, c’est à quoi ressemble la vie de ceux qui contribuent réellement et vouent une partie de leur vie à l’Open Source.

Je ne prétends pas comprendre comment cela se passe pour la plupart des contributeurs ou dire qu’il y a des modèles à suivre. Mais je crois sincèrement qu’il y a des histoires qui valent le coup d’être racontées. Voici la mienne, je vous laisse l’apprécier… ou pas 🙂

Tout d’abord, le projet s’appelle JPPF (Java Parallel Processing Framework) et c’est tout ce que j’en dirai. Cet article ne parle pas du projet lui-même, mais de ce qui lui est particulier et des conséquences que cela a sur la vie de gens, y compris la mienne.

La Génèse

Il était une fois un geek, avec une idée et un bout de code. Il se disait, « Hé, ça a l’air chouette, pourquoi est-ce que je ne mettrais pas ça à disposition des autres librement/gratuitement ? » (NdT : toujours la même ambigüité sur le mot « free », je vous laisse choisir !)

C’est une de ces idées farfelues qui vous viennent l’esprit sans raison.

Ainsi, le projet était né, et dûment enregistré sur Sourceforge. Cela semblait déjà fort passionnant à l’époque, et vous savez quoi ? Après trois ans de travail parfois harassant, c’est plus passionnant que jamais.

Le travail en solitaire

Longtemps, il n’y eut qu’un seul gars dessus, travaillant seul, faisant ce qu’il avait envie de faire, un électron libre qui n’avait qu’une vague idée de son objectif et une vision bien à lui de ce qu’était le temps libre.

C’était une époque où les heures étaient longues, les réveils matinaux, les couchers tardifs, les weekends qui passaient sans que je m’en aperçoive, les cigarettes et les cafés nombreux. Mais depuis j’ai élargi mon horizon, et je bois aussi du thé au jasmin.

Enfin voilà, c’était moi. J’adorais coder, j’aime toujours ça et j’aimerai toujours.

De 0 à plus d’1 utilisateur

Puis vint l’époque du codage, de la mise à disposition, du codage, de la mise à disposition. Le projet prenait un peu d’ampleur, et une petite communauté commençait à l’utiliser. Il était beaucoup question de « mais pourquoi ça ne marche pas dans ce cas-là ? », « pourquoi n’y a-t-il pas cette fonctionnalité ? » ou « comment pourrais-je faire ceci et cela ? » etc. Vous voyez le genre…

Et là je me suis dit : « Mon dieu, il va falloir interagir avec d’autres gars ! Comment m’y prendre ? »

Ce fut le début d’une période (brève, heureusement) d’intense introspection existentielle. Quel était le but de ce projet ? Pourquoi l’avais-je mis en Open Source ? Je résolvais le problème en décidant unilatéralement qu’il serait libre, pour tous ceux qui seraient suffisamment intéressés pour s’y pencher dessus. J’ai aussi décidé qu’il serait de ma responsabilité d’aider ces braves gens à utiliser ce projet, et tant qu’à faire, que ce soit une expérience positive pour eux.

Des utilisateurs qui participent

J’ai donc commencé à communiquer avec les autres, et j’ai vraiment été bluffé. Ces gens sont formidables ! Je ne peux pas vous dire à quel point ils ont été importants pour le projet. Voici, brièvement, en quoi :

• Ils viennent de tous les coins de la planète, c’est cool non ? J’ai eu des questions, des commentaires et des critiques des cinq continents;
• Chaque question posée correspondait à une fonctionnalité potentielle, et est souvent devenue une fonctionnalité réelle;
• Chaque bug découvert a participé à l’amélioration du projet;
• La plupart des demandes d’éclaircissement sont devenues des rubriques de la documentation;
• Beaucoup d’utilisateurs étaient vraiment sympathiques, ils me remerciaient et m’encourageaient ! À chaque fois, cela ensoleillait toute ma journée.

Très chers utilisateurs, vous êtes l’unique raison pour laquelle ce projet existe encore. Si ce projet a eu une importance quelconque dans votre vie, n’ayez aucun doute qu’il en a eu une énorme dans la mienne. Je vous aime.

D’un gars à une équipe

Un autre des effets merveilleux de l’interaction avec les utilisateurs, c’est que certains sautèrent le pas et passèrent de contributeur à membre actif. Je n’étais plus seul sur scène. Je n’étais plus libre de faire tout ce que je voulais et était responsable, non seulement envers moi-même, mais aussi envers chaque membre de l’équipe. Cela a généré du travail supplémentaire : nous avons du mettre en place quelques procédures, partager des idées sur l’architecture, la conception et l’implémentation, la montée en compétence des nouveaux venus etc.

Presque immédiatement, le flot d’idées a influencé ce qu’il était possible de faire avec le projet, pas seulement dans le futur, mais ici et maintenant. Le projet grossissait, en même temps que la vision que nous en avions. En conséquence, l’équipe s’est agrandie, ce qui a généré son lot de problèmes et de questions…

La question du leadership

La notion d’équipe et de communauté est intimement liée à celle du leadership. Qu’est-ce qu’un meneur ? Voici la définition que j’ai employée : « un meneur, c’est quelqu’un qui est capable de pousser les gens à agir en les faisant adhérer à une idée, de telle façon qu’ils seront touchés, émus et inspirés par cette idée ».

Avec cette définition, je dois honnêtement avouer que j’ai connu de nombreux succès mais aussi beaucoup d’échecs. Il y a deux échecs que je n’ai pas encore surmontés :

• J’ai échoué à garder une équipe motivée et inspirée. À l’heure actuelle je suis le seul contributeur actif et je n’ai pas entendu parler des autres depuis des mois. Quelle qu’en soit la raison, je dois l’accepter. Chaque membre de l’équipe aura toujours sa place au sein du projet, et je vous remercie les gars pour tout ce que vous avez fait, je vous remercie mille fois;
• J’ai échoué à trouver un autre meneur pour le projet. Ou est-ce juste que je n’ai pas réussi à me mettre suffisamment de coté ? En tout cas, je trouve ça effrayant de penser que le projet pourrait tout simplement s’arrêter, si je faisais un accident cérébral, par exemple, qui détruirait mon dernier (et unique) neurone restant.

Présenter une vitrine au monde

Ce projet est hebergé et vit sur le net. Cela veut dire qu’il doit y avoir un site web pour le présenter, expliquer ce qu’il fait, le documenter, aider les utilisateurs etc. Et aussi, pour attirer de nouveaux utilisateurs et fidéliser ceux qui le sont, ce site doit être sexy, confortable et facile à parcourir.

Je suis un développeur, et franchement… pas un concepteur de site web ! Oui, je connais le HTML, CSS et un peu de PHP. Oui, j’ai développé mes propres templates pour les pages qui rendent la maintenance du site plus facile. Mais comment cela ce fait-il que les différentes versions du site que j’ai pu faire aient toujours été nulles, moches, ennuyeuses voire plus souvent les trois en à la fois ? Bah… Je n’ai définitivement pas de talent artistique, et j’ai besoin d’une aide professionnelle dans ce domaine.

Je n’ai pas eu à chercher très loin : ma sœur est conceptrice graphique de profession et en quelques heures elle m’a conçu un site à des années lumière de ce que j’aurais pu faire en plusieurs semaines (voire mois, voire années… je n’ai tout simplement pas ce talent). Isa : merci pour ta générosité et pour avoir partagé ton talent !

Promotion, marketing, relations publiques, publication

Ok ! Le projet est vivant, il a un beau site web, beaucoup de documentations et des forums d’aide. Mais à quoi bon, si personne n’est au courant ?

C’est là que le concept de promotion d’un projet entre en jeu. Comment est-ce que cela marche ? Je ne pense pas que cela soit un secret : on doit savoir quel contenu les rédacteurs aiment lire. Cela prend du temps, il faut faire des essais, des erreurs, trouver les bons canaux de communication, et parfois … être courageux et audacieux. Vous ne saurez jamais si la grande nouvelle sur votre projet peut être publiée, tant que vous ne l’aurez pas soumise à ceux dont le métier est de publier ce genre de chose.

Voici quelques-uns des canaux de communications avec lesquels j’ai eu du succès :

• Les magazines en ligne;
• Les blogs;
• Les sites qui traitent de technologie;
• Les web-séminaires;
• Les présentations que j’ai effectuées moi même.

Je ne saurais trop insister sur combien ce travail de promotion permet à un projet de décoller et de faire la différence, et ce à tous les niveaux.

Très chers éditeurs en ligne et journalistes, merci pour le travail épatant que vous faites en écrivant sur les gens, la technologie et l’Open Source. Je vous aime également.

Remerciements

Je tiens à remercier :

• Toi, très cher lecteur, de m’avoir lu jusqu’ici ;
• Tous ceux qui travaillent ou contribuent aux logiciels Open Source. Garder la flamme vivante !
• Tous ceux qui utilisent l’Open Source. Sans vous les gars, il n’y aurait rien à utiliser.

Restez à l’écoute…

Les programmes de gestion de versions sont indissociables des (gros) projets de logiciels libres. Ils permettent aux développeurs de coordonner leur travail et de suivre au jour le jour qui a fait quoi dans le projet.

En suivant ces programmes, Michael Ogawa a mis au point un modèle graphique de visualisation chronologique de l’élaboration d’un logiciel libre. Il appelle cela code_swarm (essaim de code), qui utilise dans sa conception le moteur libre Processing.

Le résultat est fascinant, un véritable objet mutant aussi bien esthétique que pédagogique.

Pour le moment figurent dans le catalogue : Eclipse, PostgreSQL, Apache et Python. Comme le suggère l’auteur, j’ai choisi de reproduire^[1] ce dernier comme exemple d’illustration parce qu’on voit bien comment au départ et pendant plusieurs années le créateur du fameux langage de programmation Python, Guido van Rossum (alias guido), travaille quasiment seul jusqu’à l’an 2000 où le projet sort de sa niche et explose littéralement.

Pour ce que soit un peu plus clair, nous avons traduit^[2] ci-dessous les explications données par Michael Ogawa sur la page présentant le projet.

code_swarm

Michael Ogawa – juin 2008

« J’étudie les projets de développement logiciel depuis un petit moment maintenant. Pas la programmation, mais les gens, la façon dont ils interagissent à travers leurs collaborations et leurs communications. Mes investigations ont toujours été visuelles : J’ai bâti des applications qui créent des images de ce qui se passe au cours de l’élaboration des projets logiciels. Mais ils ont toujours eu une structure rigide. La visualisation d’information organique, inventée par Ben Fry, est une approche différente de la visualisation de l’information. Elle évite les confinements traditionnels d’information dans l’espace, et laisse les éléments jouer librement ensemble d’une manière aléatoire.

Cette visualisation, appelée code_swarm, montre l’historique des commits d’un projet de développement logiciel. Un commit intervient lorsqu’un développeur effectue des changements dans le code ou les documents et les transfère au dépôt central du projet. Les développeurs et les fichiers sont ici représentés par des éléments mobiles. Lorsqu’un développeur commite un fichier, celui-ci s’illumine et vole en direction du développeur concerné. Si des fichiers ou des développeurs ne sont pluss actifs, ils s’estompent peu à peu. Un histogramme, au bas de la visualisation, vient rappeler ce qui s’est passé précédemment. »

Je ne pense pas me tromper en affirmant que nombreux sont les visiteurs de ce blog à posséder un compte chez Flickr et/ou Del.icio.us.

Exemples emblématiques de la réussite du web 2.0, ces deux petites startups avaient été rachetés en 2005 par Yahoo! qui avait eu l’intelligence d’intégrer les fondateurs dans la transaction et de ne pas bouleverser les fonctionnalités du service offert.

Or coup sur coup, Stewart Butterfield et Caterina Fake (fondateurs de Flickr) et Joshua Schachter (fondateur de Del.icio.us) ont choisi de démissioner. Et ce n’est pas une coïncidence puisque d’autres membres émérites de Yahoo! ont récemment également quitté le navire.

Yahoo! se retrouve fragilisé pour ne pas dire dans la tourmente. Et il y a fort à craindre que désormais ces deux services ne soit plus épargnés, logique économique oblige.

Ce web 2.0 là ne ressemble décidément pas au logiciel libre…

Séquence évasion avec ces quelques photos d’une récente installation de la toute dernière version de GNU/Linux Ubuntu, la 8.04 du Hardy Heron, dans un village du Nicaragua.

Une (courte) traduction signée GaeliX pour Framalang.

Parier sur l’avenir

Bet on the future

Blog comuNIdad – 19 juin 2008

Jalapa est une commune du département de Nueva Segovia, Nicaragua, située près de la frontière avec le Honduras.

Jalapa est une région très pauvre et a été une de celles qui ont le plus souffert de la guerre civile dans les années 80.

Aujourd’hui, le gouvernement local fait un pari sur l’avenir en migrant toutes ses stations de travail et ses serveurs vers des logiciels libres et en particulier vers Ubuntu Linux.

C’est une occasion unique de réduire la fracture numérique et d’amener le progrès dans les zones rurales. Un grand merci à l’équipe locale Ubuntu d’avoir travaillé dur pendant plusieurs mois pour faire de cette initiative une réalité.

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.

Voici une traduction^[1] un peu technique mais qui illustre bien la problématique de la démocratisation de GNU/Linux.

Elle fait suite à la proposition récente de Mark Shuttleworth (Monsieur Ubuntu) de synchroniser les cycles et donc les sorties des principales distributions Linux (outre Ubuntu il cite celles de Red Hat, Novell et Debian ainsi que le noyau, GNOME/KDE, X et OpenOffice.org). Histoire que tout ce petit monde avance groupés, ce qui d’après lui simplifierait la vie de tout le monde à commencer par celle des utilisateurs.

Mais Ryan Paul du site Ars Technica n’est visiblement pas tout à fait de cet avis. Au ce serait bien si… de Mark Shuttleworth il répond avec des arguments précis qui évoquent souvent le quotidien collaboratif d’un développeur de logiciels libres (en particulier tout ce qui touche à la gestion de versions). Et lorsque l’on est, comme moi, utilisateur mais non développeur de logiciels libres, c’est culturellement fort enrichissant.

On notera qu’à la suite de sa proposition et du vif débat suscité, Shuttleworth a précisé voire nuancé son propos quelques jours plus tard sur son blog.

Pourquoi Linux n’est pas encore prêt pour des cycles de parution synchronisés

Why Linux isn’t yet ready for synchronized release cycles

Ryan Paul – 21 mai 2008 – ars technica

Le fondateur d’Ubuntu, Mark Shuttleworth a répété son appel aux développeurs des principaux logiciels libres et des distributions Linux pour une synchronisation des développements et des cycles de publication. Il avance que l’adhésion fidèle et universelle à un modèle de parution régulier encouragerait la collaboration entre les projets, assurerait aux utilisateurs l’accès aux dernières nouveautés des applications populaires et ferait de la plateforme Linux une cible plus stable et prévisible pour les vendeurs de logiciels.

Shuttleworth souhaite organiser les principales sorties en trois vagues distinctes, chacune formant un ensemble cohérent. La première vague concernerait les composants fondamentaux comme le noyau Linux, le compilateur GCC, les boîtes à outils graphiques comme GTK+ et les plateformes de développement comme Python et Java. La deuxième vague apporterait les environnements graphiques et les applications tandis que la troisième vague serait composée des distributions.

Bien qu’un cycle de sortie unifié rendrait plus aisée la création d’une distribution Linux, ce concept apporte d’importantes difficultés et n’est que peu gratifiant pour les développeurs de logiciels. Pour parvenir à une synchronisation à grande échelle comme Shuttleworth le souhaite, certains logiciels libres devraient radicalement changer leur modèle de développement actuel et adopter une nouvelle approche qui ne sera pas viable pour nombreux d’entre eux.

Comprendre les cycles de sorties réguliers

Un cycle de sorties régulier nécessite de sortir de nouvelles versions à une fréquence donnée. Le processus de développement pour les projets qui emploient ce modèle implique en général une planification des fonctionnalités prévues et ensuite une implémentation maximale jusqu’à ce que le projet gèle le code lorsque l’échéance approche. À partir de ce moment là, les fonctionnalités qui ne sont pas terminées sont reportées. On se concentre alors sur la correction des bogues et sur l’assurance qualité jusqu’à la date butoir, quand le logiciel est officiellement sorti.

Ce modèle fonctionne bien pour de nombreux projets, en particulier pour l’environnement GNOME. Mais, une conséquence de ce modèle est que les développeurs doivent travailler par incrémentation et il décourage les modifications de grande ampleur, celles qui nécessiteraient plus de temps que n’en offre le cycle. Parfois cet intervalle n’est simplement pas suffisant pour ajouter au code principal et tester des changements d’architecture importants qui sont incubés en parallèle en dehors de l’arbre principal du code.

Quand cela se produit, les développeurs doivent se demander si les avantages de la nouvelle fonctionnalité compensent les effets néfastes de la régression (comme avec l’adoption de GVFS dans GNOME 2.22 par exemple). Ils doivent parfois décider de retirer des fonctionnalités à la dernière minute ou de repousser la date de sortie pour améliorer la stabilité. Ce sont des choix difficiles à prendre et, comme le reconnaît Shuttleworth lui-même, faire ces choix demande beaucoup de discipline.

Même si des cycles réguliers peuvent convenir à certains projets, tenter d’imposer l’adoption de cette approche à tous les projets et ensuite les faire correspondre universellement pourrait gravement endommager le processus de développement. Si les projets deviennent dépendants de la synchronisation, alors un retard à n’importe quelle étape aurait des conséquences sur toutes les autres étapes. Chaque projet subirait alors une pression énorme pour tenir les délais et ce serait néfaste pour le programme et ses utilisateurs finaux.

L’utilisation des branches pour faciliter des sorties régulières

D’après Shuttleworth, de bons outils, en particulier des systèmes de contrôle de version possédant de bonnes capacités de création de branches et de fusion, peuvent rendre ce problème obsolète. Il se réfère spécifiquement à Bazaar, un système de contrôle de version mis au point par Canonical qui s’intègre à la plateforme de développement Launchpad de l’entreprise. J’ai beaucoup testé Bazaar durant ces deux dernières semaines en cherchant des technologies de contrôle de version distribuées et je ne peux qu’être d’accord avec l’argument de Shuttleworth.

Bazaar rend très facile le portage du flot continu de petits changements, du tronc vers les branches, où les fonctionnalités importantes sont développées, afin que ces fonctionnalités puissent être fusionnées sans accroc dans la branche principale quand elles sont achevées. En utilisant cette approche, où la majeure partie du développement est faite dans des branches, le code du tronc est naturellement et systématiquement plus robuste qu’il ne le serait autrement. Shuttleworth va même plus loin encore et théorise que lorsque cette approche est employée en parallèle à des tests automatisés le code du tronc est toujours prêt à être sorti à n’importe quel moment.

« Un ensemble de tests complet … vous permet d’être plus ouvert aux gros ajouts au tronc parce que les tests assurent les fonctionnalités que les gens ont avant l’ajout. Un ensemble de tests agit comme un champ de force, il protège l’intégrité du code dont le comportement était connu le jour précédent face au changement perpétuel. » écrivait ainsi Shuttleworth sur son blog.

« La plupart des projets que je finance maintenant ont adopté une politique de tests avant ajout. Les ajouts au tronc sont gérés par un robot qui refuse de valider l’ajout s’il ne satisfait pas à tous les tests. Vous ne pouvez pas discuter avec un robot ! Ce que je trouve beau là-dedans c’est que le tronc est toujours dans un état publiable. Ce n’est pas complètement vrai ; on peut toujours faire un peu plus d’assurance qualité avant de sortir quelque chose, mais vous avez cette garantie que l’ensemble de tests est toujours satisfait. Toujours. »

Les ensembles de tests et les très bons systèmes de contrôle de version peuvent simplifier le développement et améliorer la qualité du code, mais ils ne sont pas la panacée. Shuttleworth surestime largement la capacité de ces outils à pallier aux problèmes associés aux sorties régulières. Des bogues surgiront toujours quand de grosses nouveautés sont fusionnées au code existant et parfois ces bogues nécessitent un report de la date de sortie. Si les développeurs ne peuvent ou ne veulent pas faire cela, la qualité du logiciel s’en retrouvera forcément affectée.

Ubuntu 8.04 est le parfait exemple de la voie à ne pas suivre

Pas besoin de chercher très loin pour constater la baisse de qualité résultante d’un engagement sans compromis à un cycle de sorties régulières. Prenez l’exemple de la dernière version d’Ubuntu. Shuttleworth vante Ubuntu 8.04 comme l’exemple d’une gestion plus intelligente des sorties et soutient que cela démontre la capacité des développeurs à s’en tenir à un programme strict.

« 8.04 LTS représente pour nous un grand pas en avant dans notre conception de la gestion d’une sortie. Pour autant que je sache, jamais une sortie de cette envergure ne s’est faite exactement le jour prévu jusqu’à maintenant, dans le monde des OS propriétaires ou des OS libres. » commente Shuttleworth sur son blog. « Nous avons non seulement démontré que l’on peut préparer une version LTS dans les 6 mois impartis, mais cela prouve également que l’on peut s’engager par anticipation sur un tel cycle LTS. Félicitations aux preneurs de décisions techniques, aux responsables versions et à toute la communauté qui a calqué nos efforts sur le but fixé. »

Ubuntu 8.04, qui est parue le mois dernier, est une version avec support à long terme (LTS pour Long Terme Support), ce qui signifie qu’elle sera maintenue trois ans pour la version Desktop et 5 ans pour la version serveur. Depuis le début, Shuttleworth affirmait aux utilisateurs que la qualité et la fiabilité seraient les mots d’ordre pour la 8.04 et qu’elle serait faite pour durer. Malheureusement, la version n’a pas atteint ces objectifs et est sortie avec quelques bogues importants. Le problème le plus frustrant que nous avons relevé dans notre test d’Ubuntu 8.04 est la configuration défectueuse de PulseAudio, qui affecte à la fois les fonctionnalités audio et vidéo.

Un léger retard aurait permis de résoudre les problèmes de ce genre avant la sortie, mais ce n’est jamais arrivé, peut-être parce que l’engagement de faire la sortie à temps l’a emporté sur l’engagement de la qualité. Mais certains diront qu’une version défaillante n’est pas un problème parce que les bogues peuvent être réparés par des petites mises à jour après sa sortie.

« Les grands déploiements attendent la première ou la deuxième version consolidée de toute façon » fait noter Shuttleworth en réponse à un commentaire sur ton blog (NdT : La sortie de Ubuntu 8.04.1 est prevue pour le 3 juillet). Je me doute que je ne suis pas seul à avoir pensé aux Service Packs de Microsoft en voyant cette remarque. Mais une version officielle n’est-elle pas censée être un gage de qualité ? Si les sorties sont basées sur des jalons arbitraires posés sur une chronologie plutôt que sur une réelle amélioration, alors elles perdent leur sens ou leur pertinence pour les utilisateurs finaux.

D’autres approches

Les cycles de sortie devraient être flexibles et les développeurs devraient pouvoir en ajuster la durée pour qu’ils collent à leur activité. Selon les projets, la culture de développement et les buts peuvent être très différents, les stratégies de publication sont par conséquent différentes. L’appel de Shuttleworth en faveur d’une synchronisation reflète une forme d’incapacité à reconnaître la valeur et la profondeur de la diversité dans la communauté du logiciel libre. Des distributions qui visent des publics différents et qui ont des priorités différentes pourraient ne pas rentrer dans le même moule que les distributions généralistes comme Ubuntu. On retrouve également des logiciels libres multi-plateformes, comme le navigateur Web Firefox par exemple, qui réunissent beaucoup d’utilisateurs sur d’autres systèmes d’exploitation et qui peuvent avoir d’autres priorités que la fréquence de sortie des distributions Linux.

Je tiens à dire quand même que je ne rejette pas catégoriquement les idées de Shuttleworth. Même si je suis vraiment contre une approche descendante et centralisée de la planification des sorties synchronisées je pense qu’il y pourrait y avoir des bénéfices à tirer d’un meilleur alignement du calendrier de quelques distributions principales qui partagent déjà des buts, une technologie et une méthodologie similaires.

La simultanéité des sorties est déjà à l’ordre du jour (Fedora 9, Ubuntu 8.04 et OpenSolaris 2008.05 ont toutes vu le jour à quelques semaines d’intervalle) et je suis convaincu que de meilleurs résultats sont atteignables si on laisse cette tendance se développer d’elle-même. Encourager trop d’interdépendance créerait des risques sévères, on parle d’un domaine où une planification consciencieuse et un calendrier gravé dans la roche seraient à l’origine de plus de problèmes qu’ils n’en résolvent.

Aaron Seigo, développeur KDE, est l’un des détracteurs ayant exprimé des inquiétudes convaincantes et perspicaces au sujet de la proposition de Shuttleworth. Seigo met à plusieurs reprises en avant que le genre de synchronisation que souhaite Shuttleworth améliore l’efficacité d’intégration au dépend de l’efficacité des développeurs, une concession qu’il décrit comme contre-productive car c’est dans le développement que se trouve le richesse des logiciels.

« Mark parle de processus en flux tendu, mais seulement du point de vue de l’intégration ; il existe aussi des processus en flux tendu dans le développement et définir le cycle de développement à l’aune du cycle de sorties, surtout s’il n’est pas bon, érode la fluidité du flux de développement », écrit Seigo sur son blog. « Il ne faut pas oublier que c’est le processus de développement qui fait toute la valeur d’une distribution Linux. La distribution rend cette valeur accessible à grande échelle et crée un autre type de valeur ajoutée par-dessus (le support, le marketing, etc.) mais c’est le développement, pas l’intégration, qui est la source primaire de valeur. Il devrait alors être évident que le processus de développement n’est pas quelque chose qu’on peut prendre comme ça à la légère. »

Seigo propose une alternative qui faciliterait la synchronisation en aval sans nécessiter de synchronisation ou de chamboulement en amont. D’après lui, les distributions devraient gérer par elle-mêmes les sorties en créant leurs propres branches et en tenant compte des contraintes de leurs propres cycles.

« Puisqu’il y a cette volonté en aval pour des cycles de parution synchronisés… pourquoi est-ce que l’aval ne prendrait pas en charge les sorties ? Pourquoi attendre que les tarballs soient livrées devant leur porte pour mettre en place une équipe de publication ? » s’interroge Seigo. « Pourquoi ne pas demander à la communauté d’intégration (les vendeurs de systèmes d’exploitation en gros) de coordonner leur efforts pour créer une branche en vue d’une sortie à un moment donné, moment qu’ils définissent eux-mêmes, et travailler avec l’amont pour la stabilisation de cette branche ? Plutôt que d’espérer que l’amont fasse ce qu’ils désirent, pourquoi ne peuvent-ils pas regrouper un tas de gars des communautés de chez Novell, Red Hat, Debian, Mandriva, MacOS et Microsoft, de chez Canonical ou encore de chez n’importe qui qui voudrait s’impliquer et offrir un vrai processus sérieux de sortie par lequel l’amont pourrait s’intégrer naturellement ? »

Les suggestions de Seigo sont plus viables que les propositions de Shuttleworth. Elles permettraient aux distributions Linux de bénéficier des avantages pratiques de la synchronisation dont bénéficieraient également les utilisateurs finaux sans avoir à bouleverser ou synchroniser le développement en amont. Cela engendrerait cependant un coût additionnel et un défi nouveau pour les distributeurs et leur ferait porter le poids de la gestion des sorties. Seigo assure que si les distributeurs veulent vraiment des sorties synchronisées en aval autant que ça ils seront prêts à accepter cette charge supplémentaire et trouveront un bon moyen pour y parvenir.

Il est bien probable que cette discussion dure pendant encore quelques temps à mesure que les acteurs principaux pèsent le pour et le contre. La communication a déjà fait avancer le débat de bien des manières et a déjà fait émerger des alternatives attirantes et des variations de la proposition initiale. Le résultat final pourrait avoir des implications importantes sur la gestion des sorties par les logiciels libres et les distributions, mais pour l’instant aucune des idées proposées n’est suffisamment mature pour être appliquée à grande échelle.