J’ai 32 ans, sud africain, habitant Londres. La majeure partie de mon temps est consacrée au projet Ubuntu en tant que leader et pour maintenir un peu de discipline. Je viens de passer environ un an à m’occuper de l’infrastructure collaborative Launchpad, en écrivant une bonne partie du projet et en aidant l’équipe à définir nos objectifs. C’est enthousiasmant de voir tout ça être mis en service. Plus de détails sur markshuttleworth.com.
Ubuntu n’est pas sans controverses. C’est une bonne chose (au moins à mon avis) car cela suggère tout à la fois que nous défions le status quo, et que nous prenons des risques. Me concernant, mes motivations pour financer et participer si fortement à Ubuntu viennent pour une large part d’un désir de faire ces deux choses. J’aime secouer les courants de pensées établis, et j’aime prendre des risques. Ce document existe pour donner à la communauté un aperçu de ce que je pense - et dans une certaine mesure de ce que pense le Community Council (le Conseil de la communauté), le Technical Board (le Comité technique), et autres structures de gouvernance - sur certains points et certaines décisions qui ont été controversés.
Je vais tenter de répondre aux rumeurs, aux questions fréquement posées, aux allégations et névroses courantes, et bien sûr aux controverses au sein du projet ("notre bureau par défaut devrait être *pourpre*") et dans la communauté du logiciel libre en général ("Alerte ! Alerte ! Ubuntu est en train de devenir un projet commercial !"). Vous pouvez en avoir croisé des variantes ici et là. Vous pouvez considérer ce document comme faisant autorité à leur sujet, et là où c’est indiqué vous avez aussi la position du Ubuntu Community Council (Conseil communautaire Ubuntu) ou du Technical Board (Comité technique). Si vous aimeriez voir des sujets supplémentaires abordés ici, merci de les évoquer lors d’une réunion du Community Council sur IRC, ou de correspondre avec moi ou les membres du CC, ou d’en parler sur ubuntu-devel.
Pourquoi je m’occupe d’Ubuntu ?
Pour corriger le bug n°1 évidement. Je crois que le logiciel libre nous amène dans une nouvelle ère technologique, avec la promesse de l’accès universel aux outils de l’ère numérique. Je pilote Ubuntu car j’aimerais que cette promesse devienne réalité.
Est-ce-qu’Ubuntu exigera un jour une licence payante ou des royalties ?
Non. Jamais. Je n’ai aucun interêt à faire qu’Ubuntu rejoigne l’industrie du logiciel propriétaire. C’est une horrible activité qui est ennuyeuse et difficile, et qui disparaît rapidement de toute façon. Ma motivation et mon but sont de trouver une manière de créer un système d’exploitation à usage bureautique général qui soit libre et gratuit, mais également pérenne et d’une qualité comparable à tout ce que vous pouvez acheter. C’est ce que j’essaye de faire, et si nous échouons, et bien je trouverai un autre projet à mener plutôt qu’entrer dans l’industrie du logiciel propriétaire. Je ne pense pas qu’un seul développeur de l’équipe Ubuntu, ou qu’une bonne partie de la communauté, resterais dans les parages si je devenais timbré et décidais de tenter ça en tout cas.
Si ce n’est pas suffisant pour vous, alors vous serez content de savoir que Canonical a signé un engagement public avec des services gouvernementaux stipulant que l’entreprise ne produira jamais de version "commerciale" d’Ubuntu. Il n’y aura jamais de différence entre le produit "commercial" et le produit "libre", tel que chez Red Hat (THEL et Fedora). Les versions d’Ubuntu seront toujours libres.
Cela dit si vous VOULEZ payer Ubuntu, ou quelque chose qui inclut le code Ubuntu, vous pouvez probablement. Il y a déjà du code Ubuntu dans Linspire, que vous pouvez payer (W000h !). Bien que Linspire ne soit pas (encore) directement basé sur Ubuntu, il n’est pas impossible que les gars de Linspire comprennent que ce soit un bon choix pour eux tôt ou tard. Il est probable qu’il y ait un grand nombre de versions d’Ubuntu, sous d’autre noms, qui auront des caractéristiques commerciales ou propriétaires. Ca pourrait être des polices de caractères propriétaires ou des logiciels ou des ajouts ou de l’intégration avec des services, etc. Il y aura aussi probablement pas mal de logiciels propriétaires disponibles pour Ubuntu (il y en a déjà quelques un - Opera pour Ubuntu a été annoncé récemment par exemple). Mais Canonical, et Je-moi-même, et le Ubuntu Community Council et le Technical Board, ne produirons pas un "Ubuntu Edition professionnelle (XX.00 €)". Il n’y aura pas de "Ubuntu Vista".
Si vous ne faites pas un "Ubuntu édition professionnelle", comment Ubuntu peut-il être viable ?
Nous avons quelques revenus initiaux venant de services apparentés à Ubuntu. Nous sommes sous contrat pour produire des distributions sur mesure, et nous participons à des appels d’offre à grande échelle pour de gros déploiement de Linux, habituellement en partenariat avec des entreprises locales, en faisant du support de haut niveau. En plus de sa généralisation dans les pays en voie de développement, Ubuntu pourrait bien envahir prochainement le site Moffett Field de la NASA... Donc nous avons les fondements pour un projet viable, et je suis confiant dans le fait que nous ayons une chance raisonnable de mener Ubuntu jusqu’au point où il se finance lui-même pour poursuivre sa croissance.
Comment ça se goupillera du point de vue des affaires est difficile à estimer. Je n’ai pas toutes ces réponses. OK, c’est une aventure risquée, qui en est toujours à une phase précoce, donc je ne m’attends pas à savoir. Je peux personnellement justifier mon investissement dans Ubuntu pour des raisons philantropiques (au moins concernant l’argent que nous dépensons pour des développements libres et pour des outils pour les développeurs du libre, tels que Launchpad) parce que la plus grande partie de ma chance et de ma fortune n’a pu être créée qu’avec des outils libres. Je suis heureux de renvoyer l’ascenseur à la communauté. Dans la mesure où nous commençons à dépenser de l’argent en procès, ils (ndt : les projets) ont besoin d’être viables rapidement. Nous faisons actuellement de l’argent en offrant des services relatifs aux certifications (certifications de développeurs, d’administrateurs, d’application et de matériel) et en services sur mesure (si vous voulez votre propre distro, basée sur Ubuntu, discutons-en). La demande pour ces services est grandissante. Je suis assez confiant dans le fait que je puisse amener Canonical à rentrer dans ses fonds. Et rentrer dans ses fonds est une bonne chose selon moi, parce que ça veut dire qu’Ubuntu continuera à marcher même si je décide qu’il est temps de revenir dans l’espace et que je choisisse le mauvais Soyuz.
Il est également important de faire la distinction entre Canonical, qui fait du service pour en tirer des bénéfices, et la Fondation Ubuntu, dont le capital viens de moi, sans but lucratif, pour poursuivre le travail sur Ubuntu. Avec l’annonce de la Fondation Ubuntu, je disais au fond que "OK, le projet marche tout seul, j’ai apporté suffisamment de capital pour que ça continue longtemps quoi qu’il arrive à Canonical ou à moi". Donc nous avons largement le temps pour créer de la pérennité autour du projet. Si vous voulez aider sur ce point, envoyez du travail à Canonical la prochaine fois que vous avez besoin que quelque chose soit fait avec Ubuntu. Nous ne vous laisserons pas tomber.
Que pensez-vous de la compatibilité binaire entre distributions ?
Beaucoup de choses ont été dites à propos du fait que Debian n’est pas compatible au niveau des binaires avec Ubuntu. Parfois cela se manifeste par "Je n’arrive pas à installer les paquets Ubuntu sur Debian", parfois c’est plutôt "Pourquoi est-ce qu’Ubuntu utilise GCC 4 alors que Debian utilise GCC 3.3 ?". Ou "Pourquoi est-ce que le noyau et glibc sur Ubuntu est différent de ce qu’il y a sur Debian Sarge ?". Je vais tenter de répondre à tout cela.
Je vais commencer par notre politique et approche générales, pour ensuite examiner certains de ces exemples en détail.
Premièrement, la "compatibilité binaire" signifie des choses différentes pour différentes personnes. Si vous avez suivi les tribulations de la création des standards LSB, vous comprendrez combien il est difficile de simplement *définir* la compatibilité binaire d’une manière qui ait un sens pour de multiples distributions. C’est pourquoi, par essence, nous n’avons pas la "compatibilité binaire" comme but pour Ubuntu. Ca arrive parfois, mais lorsque c’est le cas, c’est accidentel ou parce que quelqu’un a pris l’opportunité de faire fonctionner quelque chose élégamment - pas parce que c’est un but spécifique.
Pour être bien clair, je le redis, que ce soit bien noté. Nous ne visons pas la "compatibilité binaire" avec les autres distributions. Pourquoi ?
En bref, parce que nous croyons au logiciel libre en tant que processus collaboratif focalisé sur le CODE SOURCE, et nous le considérons supérieur au processus propriétaire qui est focalisé sur des applications spécifiques et des octets. Nous avons choisi de consacrer la plus grande partie de notre énergie à l’amélioration du code source qui est largement et librement disponible, plutôt que d’essayer de travailler sur des octets qui ne peuvent pas être partagés aussi largement. Lorsque nous passons des heures sur une fonctionnalité, nous voulons que ce travail soit utilisable par autant d’autres distributions que possible, donc nous publions le code source en "temps réel" lorsque nous publions de nouvelles versions des paquets. Nous nous donnons beaucoup de mal pour que ces correctifs soient largement disponibles, dans un format facile à trouver, afin qu’il soient utiles à ceux qui travaillent en amont (ndt : sur les logiciels, les pilotes, le noyau), et aux autres distributions. Cela bénéficie à Debian, mais bénéficie aussi à Suse et RedHat, si ils ont la volonté de prendre le temps d’étudier et d’appliquer les correctifs.
Nous synchronisons régulièrement nos développement avec ceux qui travaillent en amont, et avec Debian, et avec d’autres distributions comme Suse, Gentoo, Mandrake et Red Hat. Nous tirons le code à partir des derniers projets en amont (qui peuvent même ne pas être dans Debian, ou Red Hat, ou indiqué dans la LSB). Nous essayons d’unifier avec Debian Unstable (c’est à dire Sid) tous les six mois. Nous n’avons aucun contrôle sur le processus de sortie des autres distributions, ni sur les projets en amont, donc il nous serait impossible de définir à l’avance une API ou une ABI pour chaque version. Nous sommes entre les mains de centaines d’autres développeurs chaque fois que nous figeons Ubuntu en vue d’une nouvelle version. Bien que la communauté Ubuntu soit importante et grandisse rapidement, elle est encore toute petite comparée au nombre total de développeurs travaillant sur toutes les applications libres qui forment les distributions elles-même. Notre job est de packager ce qu’il y a là, efficacement et de manière cohérente, pas d’essayer de le manipuler pour arriver à un stade pré-défini de compatibilité. Nous nous concentrons sur la distribution des versions récentes-mais-stabilisées-et-avec-une-bonne-finition des meilleures applications libres pour votre serveur ou votre ordinateur de bureau. Si nous en étions à avoir la compatibilité binaire (à quelque niveau que ce soit) comme haute priorité, cela amoindrirait considérablement notre capacité à livrer des logiciels plus récents, ou une meilleure intégration et une bonne finition. Et nous pensons que nos utilisateurs font plus attention au fait qu’ils ont les meilleures applications, et les mieux intégrées, sur le CD.
Il faut noter que le noyau Linux lui-même utilise la même approche, éviter la "compatibilité binaire" en faveur d’un "noyau monolithique sur mesure". Chaque version du noyau nécessite d’être compilé séparément des versions précédentes. Les modules (les pilotes) doivent être recompilés avec la nouvelle version, ils ne peuvent pas simplement être utilisés sous leur forme binaire. Linus a expressément indiqué que le noyau monolithique - basé sur le code source, sans tenter de garder une interface binaire pour les pilotes d’une version à l’autre - est mieux pour le noyau. Nous pensons que la même chose est vraie pour la distribution.
Donc l’impératif de travailler avec le tout dernier code annule l’idée de maintenir la compatibilité avec une ABI spécifique, specialement si nous avons peu ou pas à dire à propos de l’ABI pour laquelle nous devrions tenter de rester compatible.
Mais, j’ai entendu dire qu’Ubuntu est MOINS compatible que d’autres projets similaires ?
C’est n’est absolument pas vrai. Si vous touchez ou modifiez le noyau, ou le serveur x ou les clients, ou la libc, ou le compilateur, vous vous rendez vous-même parfaitement incompatible. Et pour autant que je sache toute distribution significative a, avec de bonnes raisons, investi du travail dans ces composants pour assurer qu’ils répondent aux besoins de leurs utilisateurs. Faisant cela, ils se rendent eux-mêmes "incompatibles binairement". Ce qui fait que le monde du libre fonctionne malgré cela, bien entendu, est le fait que ces codes sources et ces correctifs fonctionnent généralement d’une distribution à l’autre, c’est pourquoi nous focalisons notre attention là-dessus, et pas sur les octets.
Certaines personnes pourraient dire "mais j’ai installé un paquet Linspire sur Ubuntu, et il a fonctionné, donc il doivent être compatibles". Et oui, dans beaucoup de cas un paquet binaire de Linspire ou Debian sera Parfaitement Fonctionnel (TM) sur Ubuntu. Mais c’est une "compatibilité accidentelle", et non une "compatibilité binaire certifiée". Cette variabilité de résultat n’est certainement pas le type de certitude que la plupart des gens accepterait, et peut difficilement être appelée "compatibilité binaire". Beaucoup de paquets ont des dépendances très simples, et ne nécessitent pas vraiment de version particulière des bibliothèques système, et elles peuvent très bien être Parfaitement Fonctionnel (TM). Mais si vous regardez sous le capot, à un niveau ou un autre, vous allez trouver des incompatibilités binaires dans toutes les distributions importantes, de Knoppix à Linspire ou la DDC, Ubuntu ne faisant pas exception à la règle.
Il est possible de faire une nouvelle distribution en utilisant uniquement des sélections de paquets venant d’autres distributions, et c’est utile. C’est comme le projet DDC - et ce sera important je pense dans le futur dans le monde d’Ubuntu aussi. Mais c’est fondamentalement peu intéressant - c’est juste une sélection de paquets, qui est utile à une certaine catégorie d’utilisateurs mais n’amène rien à l’art du monde du libre.
Ok, pourquoi recompilez-vous les paquets ?
Nous nous assurons qu’Ubuntu soit entièrement compilable en utilisant la suite d’outils par défaut dans Ubuntu. Nous avons généralement une nouvelle version de GCC dans Ubuntu, et certainement une version plus récente que Debian. Donc nous veillons à compiler tous les paquets dans Ubuntu avec cette nouvelle version.
En théorie, utiliser de nouvelles versions de GCC devrait donner de meilleurs binaires (bien que dans le passé, quelques changements de version de GCC aient inclu des régressions qui établissaient les fondations pour de futurs progrès). De plus, cela nous permet de faire face aux changements d’ABI, en particulier dans le code C++, et de réduire le nombre de versions de paquets d’ABI que nous avons à conserver dans nos archives.
C’est également vrai pour les paquets dans "universe", qui sont les centaines de paquets d’Ubuntu qui viennent principalement de Debian, bien qu’il y ait des sources alternatives également. L’équipe MOTU ("Masters of the Universe ;-)" - Les maîtres de l’univers) d’Ubuntu se charge de ces paquets, assurant les transitions d’ABI, et (par exemple) les transitions de versions de Python se font là aussi. Pour assurer la cohérence, tous ces paquets sont également recompilés.
Quelques exemples précis ?
Il y a de bons exemples d’autres distributions faisant la même chose. Puisqu’Ian Murdock et Progeny ont été très loquace à ce sujet, commençons par là. Progeny 1.x n’était pas "compatible binairement" avec la version stable de Debian du moment. Oui, réellement. L’actuelle version de "l’alliance DDC" utilise un noyau différent, et une LibC différent, de celles de Debian Sarge. Dans les deux cas, toutefois, les correctifs de code source passent facilement depuis ces projets vers Ubuntu, et vers Debian, et nous sommes content de les utiliser. C’est ce qui rend le développement du logiciel libre, focalisé sur le CODE SOURCE et la collaboration autour du code lui-même, plus productif que le développement propriétaire.
Je ne veux en aucun cas dénigrer ces autres distributions. Il faut cependant préciser toutefois que ce sont souvent les personnes qui crient le plus à propos de la "compatibilité binaire" qui l’ont joyeusement négligée dans leur propre travail. Parce qu’en réalité ce n’est simplement pas si important dans le monde du logiciel libre, et que ce n’est pas applicable en tant qu’objectif hautement prioritaire.
Pourquoi Ubuntu 5.04 (Hoary Hedgehog — Hérisson chenu) n’était pas "compatible binairement" avec Debian Sarge ?
Beaucoup de gens indiquent qu’il n’y a pas de problème de paquets entre Ubuntu 5.04 et Sarge. Mais ils ne sont pas totalement compatibles. Ubuntu 5.01 et Debian Sarge ont de légères différences, mais significatives, entre leurs versions de libc. Lorsqu’Ubuntu 5.04 est sortie, elle ETAIT compatible avec la version de Sarge, qui était en gel absolu des ajouts de fonctionnalités (deep freeze). Après la sortie d’Hoary, un changement a été proposé dans Debian. Afin de pouvoir l’implémenter, l’équipe Debian aurait eu à rompre la compatibilité avec Hoary, qui avait déjà été sortie. Cela a été discuté ouvertement, et la décision a été prise d’effectuer le changement. Nous (à Ubuntu) pensons vraiment que c’est la bonne décision pour Debian. C’est du logiciel libre, et nous pouvons collaborer efficacement si nous nous focalisons sur le code source. Si Debian s’était senti obligé de NE PAS implémenter le changement, afin de conserver la compatibilité avec Ubuntu, le monde du libre aurait en fait été appauvri.
Bien qu’il y ait une incompatibilité binaire entre ces deux versions, elle n’a pas été introduite par l’équipe Ubuntu. Nous avons cependant activement soutenu le processus de décision qui a mené à cette incompatibilité - c’est ce qui fait que le monde du logiciel libre est fort.
Et à propos de la transition vers GCC 4.0 ? Pourquoi avez-vous adopté GCC 4.0 ?
Nous essayons toujours d’inclure les dernières versions stables des outils de développement, des bibliothèques et des applications. GCC 4.0 est sorti tôt dans le développement de Breezy (Ubuntu 5.10), donc c’était le choix approprié pour le compilateur de cette version. Cela voulait dire que les applications C++ compilées sur Breezy aurait par défaut une interface applicative binaire (ABI) différente que celle des mêmes bibliothèques de Sarge, qui utilisait GCC 3.
Ca a été débattu avec les mainteneurs de la suite d’outils de Debian, qui projetaient eux-mêmes d’adopter GCC 4 dans quelques temps. Il a été convenu d’un plan en ce qui concerne le nommage spécifique des paquets binaires compilés avec GCC 4, afin qu’il puisse y avoir une solution élégante de migration et de mise à niveau pour les utilisateurs qui mettraient à jour depuis une version précédente d’Ubuntu (ou Debian). L’équipe Ubuntu a alors pris de l’avance et a lancé les travaux, fournissant des correctifs pour des centaines de paquets afin de les mettre en conformité avec le nommage prévu pour GCC 4. Ces correctifs sont disponibles pour tous les mainteneurs Debian, et rendent leur vie beaucoup plus facile pour la migration vers GCC 4.0 de Debian.
Pourquoi le fond d’écran par défaut d’Ubuntu est-il MARRON ?
Le thème général de la première série de version d’Ubuntu est "Humanité". Ca détermine notre choix graphique autant que notre selection de paquets et les décisions autour de l’installeur. Notre thème par défaut dans les quatre premières versions d’Ubuntu est appelé "Human", et il met l’accent sur la couleur humaine chaude - le marron.
Oui, c’est plutôt inhabituel dans un monde où la plupart des fonds d’écran sont bleus ou verts, et MacOSX est devenu comme des ustensiles de cuisine. En partie, nous aimons le fait qu’Ubuntu soit différent, plus chaud. L’ordinateur n’est plus un outil, c’est une extension de votre esprit, votre porte vers les autres (par email, voip, irc et le web). Nous voulions une sensation qui soit unique, saisissante, apaisante et surtout, humaine. Nous avons choisi le marron. C’est plutôt un choix hautement risqué, car pour restituer le marron votre écran doit restituer de subtiles nuances de bleu, et de vert, et de rouge. Même de légères variations par rapport à la norme peuvent modifier le "marron" substanciellement. Mais les moniteurs et les écrans LCD sont de nos jours de plus en plus à un niveau qui nous a fait ressentir le risque comme acceptable. Dans Hoary et Breezy nous apportons un brun plus riche, plus rouge, basé sur les commentaires des utilisateurs d’ordinateurs portables bas de gamme et d’écrans LCD.
Est-ce que le marron sera toujours la couleur de fond d’écran par défaut ?
Bien que RIEN ne soit figé pour toujours, nous comptons qu’Ubuntu soit là pour un bon bout de temps :-)
Nous prévoyons actuellement que Dapper Drake (Canard Pimpant - Ubuntu 6.04 si nous atteignons notre objectif de sortie en avril 2006) sera la dernière version de cette "série". Donc après Dapper nous avons l’opportunité de définir de nouvelles "sensations" ou un nouveau thème général. Il est peu probable qu’il soit ... bleu. Mais il pourrait être très différent du théme Human actuel. Pour le moment restons concentré sur Dapper, en perfectionnant au maximum le thème Human existant, pour ensuite s’occuper du futur.
Est-ce qu’Ubuntu est un fork (un travail dérivé) de Debian ?
Oui, Ubuntu est un fork. Non, ce n’en est pas un. Si, c’en est un ! Oh, qu’est-ce que ça peut faire ?
Brièvement, nous sommes un projet qui tente vraiment de collaborer avec plein d’autres projets - tels que X.org, GNOME, et bien évidemment Debian. Dans beaucoup de cas, le code que nous fournissons est modifié ou différent du code fournit pas ces autres projets. Lorsque ça arrive, nous travaillons dur pour s’assurer que nos changements soient publiés le plus largement possible, dans un format qui soit facile à comprendre pour les mainteneurs d’autres projets, et facile à incorporer dans leur propre arbre de travail.
Dans la pratique, nous avons mis fort longtemps pour développer les outils qui rendent facile la collaboration avec Ubuntu, et nous aident à collaborer avec les projets en amont et les autres distributions. Par exemple, nous avons un publicateur automatique de correctifs qui montre aux mainteneurs de Debian quels correctifs pour leurs paquets sont disponibles pour Ubuntu. Il ne pourrait pas être plus facile pour les développeurs de Debian de décider quels correctifs ils veulent, et ceux qu’ils ne veulent pas. Et franchement, c’est bien plus facile pour nous si il les prennent effectivement, mais nous ne pouvons pas les forcer. Beaucoup des correctifs n’ont de sens que pour Ubuntu. Comme bénéfice secondaire, ces correctifs sont également disponibles pour Gentoo, Red Hat, Linspire (oui, vraiment) et Suse. Et nous savons qu’ils y jettent un oeil et en utilisent certains, ce qui est cool.
Cependant la collaboration va au-delà des correctifs. Nous avons développé Malone, un système de gestion de bugs qui tente explicitement de créer une collaboration entre Ubuntu, les autres distros, et les projets amonts, pour la correction des bugs. Chaque bug peut correspondre à plusieurs programmes, et en un seul lieu vous pouvez voir l’état du bug dans tous ces programmes. C’est vraiment cool.
Un des déclics qui m’ont fait sortir du jeu "cosmonaut playboy international love rat of mystery" (ndt : je traduis ça comment moi, hein ?!) pour m’occuper d’Ubuntu a été l’emergence d’outils tels que TLA, qui semblait offrir la promesse d’une bien meilleure collaboration entre les distros et les projets amonts. Alors nous avons fait beaucoup de travail sur TLA, au point qu’il avait l’air suffisamment différent pour l’appeler Bazaar. Nous avons alors repris l’écriture depuis le début en Python, et le résultat est Bazaar-NG, ou Bzr, qui sera Bazaar 2.0 en mars 2006. Pourquoi est-ce si important ? Parce que faire circuler les correctifs n’est pas aussi efficace que travailler avec un système de contrôle de révision réellement distribué. Beaucoup des gars d’Ubuntu ne travaillent pas sur la distro, ils travaillent sur des outils comme Bazaar, et HCT, qui nous espérons accelérera vraiment le type de collaboration qui est possible dans le monde du libre. Le temps nous le dira.
En résumé : la compatibilité binaire entre Ubuntu et Debian n’est pas une priorité pour nous. Nous pensons que nous contribuons plus au monde du logiciel libre en fournissant des correctifs pour que les paquets Ubuntu (et Debian) fonctionnent mieux, et en fournissant un distribution de pointe pour que les autres puissent collaborer avec. Nous investissons beaucoup d’énergie en nous nous assurant que nos correctifs soient largement plubliés et facilement disponibles pour les développeurs de TOUTES les autres distributions et des projets amonts, parce que nous pensons qu’ainsi notre travail offrira le maximum de bénéfices à long terme. Et nous développons des outils (voyez Bazaar et Bazaar-NG et LaunchPad et Rosetta et Malone) qui nous l’espérons rendrons la collaboration sur le code source encore plus efficace.
Que pensez-vous de scinder la communauté ?
La communauté Ubuntu a grandi très vite, et certaines personnes s’inquiètent que cette croissance se fasse avec un certain coût pour d’autres communautés du libre, Debian en particulier. Etant donné que les correctifs peuvent circulent très facilement entre Ubuntu et Debian, il me semble que plus nous pourrons avoir de développeurs dans nos deux communautés, mieux se sera pour les deux projets. Ubuntu bénéficie d’un Debian fort, et Debian benéficie d’un Ubuntu fort. C’est particulièrement vrai parce que les deux projets ont des buts légèrement différents. Ubuntu fait des changements plus tôt, et Debian bénéficie énormément de ces correctifs (regardez juste les changelogs (journaux des modifications) de Debian Sid depuis que Sarge est sortie, et vous verrez combien il y a de références à "Ubuntu" là-dedans. Et ce sont uniquement les cas où les crédits ont été indiqués.
(ndt : non, il n’y a pas de parenthèse fermante)
Si les communautés Ubuntu et Debian avaient travaillé de la même manière, alors je pense que cette inquiétude serait plus fondée, parce que nous attirerions les mêmes sortes de gens, ce qui veut dire que nous serions en compétition pour les talents. Mais les deux communautés sont assez différentes. Nous nous organisons différemment, et nous fixons des priorités différentes. Cela veux dire que nous avons tendance à attirer différentes sortes de développeurs.
Maintenant, il y a certainement des développeurs Debian qui ont commencé à avoir la majeure partie de leur travail sur Ubuntu maintenant. Il y a aussi des développeurs qui travaillent autant sur Ubuntu que sur Debian. Mais la majorité de la communauté Ubuntu est faite de développeurs plus récents, qui ont été attirés par la manière de faire d’Ubuntu. Il y aura toujours des mouvements entre les communautés, et c’est sain car ça aide à propager les bonnes idées.
Que faire si le succès d’Ubuntu signifie la mort de Debian ?
Ce serait vraiment mauvais pour Ubuntu, puisque tout développeur Debian est également un développeur Ubuntu. Nous synchronisons nos paquets avec Debian régulièrement, parce que ça amène les dernières modifications, le dernier code, et le plus récent effort d’empaquetage à partir d’une énorme et compétente communauté du logiciel libre. Sans Debian, Ubuntu ne serait pas possible. Et l’avenir de Debian n’est pas menacé, on en parle de plus en plus dans des endroits plus intéressants maintenant qu’Ubuntu a montré quelles choses incroyables peuvent être faites au sein de cette communauté.
Pourquoi Ubuntu ne fait pas partie de l’Alliance DCC ?
Je ne crois pas que DDC réussira, bien que ses buts soient nobles et louables. Il serait onéreux de participer, et cela ralentirait notre capacité à ajouter les fonctionnalités, la finition et l’intégration que nous voulons pour les nouvelles versions. Je ne suis pas préparé à affecter des ressources limitées à une initiative qui je pense échouera en fin de compte. Il n’y a aucun intérêt ici à s’étendre sur les raisons pour lesquelles je crois que DDC échouera - le temps le dira. J’aimerais encourager les membes de la communauté Ubuntu à participer aux discussions de DDC si ils en ont le temps et qu’ils sont intéressés. Si la DDC produit du bon code, nous devront l’intégrer dans les versions d’Ubuntu, et il devrait être facile de le faire.
Pourquoi financez-vous Ubuntu, plutôt que de donner l’argent à Debian ?
J’ai passé beaucoup de temps à penser comment contribuer au mieux au monde du logiciel libre, et comme explorer au mieux les idées pour lesquelles je suis personnellement intéressé ; telles que les meilleures manières de déployer du logiciel libre sur les ordinateurs de bureautique. Une solution était de postuler pour le poste de DPL (je suis DD, premier mainteneur d’Apache en 1996 et blabla) et de faire entrer ces idées dans Debian. J’ai fini par décider de créer une distribution parallèle, et d’investir dans l’infrastructure pour faire que la collaboration inter-distro soit bien plus efficace.
(ndt : DPL = Debian Project Leader = Chef de projet Debian DD = Debian Developper = Développeur Debian)
Voici pourquoi.
Premièrement, beaucoup de choses que je veux impliquent de réduire l’étendue de la distro. Ca la rend PLUS utile pour une partie des gens, mais assez clairement MOINS utile pour d’autres. Par exemple, nous supportons actuellement de manière officielle seulement 3 architectures. C’est SUPER pour les gens qui utilisent ces architectures, mais clairement pas si utile pour les gens qui utilisent autre chose.
De la même façon, nous supportons environ 1.000 applications fondamentales dans Ubuntu. Elles sont les pièces maîtresses qui sont dans le composant "main" (principal) d’Ubuntu, Kunbuntu et Edubuntu. Tout le reste est accessible, en tant que Universe ou Multiverse, mais pas officiellement supporté.
Plus je pensais à cela, plus je réalisais que c’était une mauvaise chose pour Debian, qui tire beaucoup de sa force de son "universalité". Il est plus sensé d’utiliser cette approche dans un projet séparé. Nous avions à devenir précurseur et nous concentrer sur ces choses, et les correctifs sont instantanément accessibles aux DD qui estiment qu’ils sont appropriés pour Debian aussi.
Deuxièmement, le problème de "partager entre distributions" est celui qui est vraiment intéressant. En ce moment, nous avons tendance à voir le monde comme étant composé de projets amonts, d’une distro, et de dérivés. En fait, le monde ressemble plus à une flopée de projets qui ont besoin de collaborer. Nous avons besoin de collaborer avec Debian, mais nous devons aussi être capable de collaborer avec les projets amonts, et avec Gentoo. Et avec Red Hat, aussi. Nous avons besoin de comprendre comment collaborer efficacement avec des distributions qui utilisent un système de paquetage totalement différent du nôtre. Parce que la réalité du monde du logiciel libre est telle que le nombre de distributions continue d’augmenter - chacune répondant aux besoins d’un groupe spécifique de personnes, basé sur leur travail, sur leur identité culturelle, ou sur l’institution pour laquelle ils travaillent, ou leurs intérêts personnels.
Résoudre le "problème de collaboration entre distros" ferait vraiment progresser l’état du logiciel libre. Ansi c’est ce que nous avons entrepris de faire avec Ubuntu. Nous travaillons sur Launchpad, qui est le service web pour la collaboration sur les bugs, et les traductions, et le support technique. Nous travaillons sur Bazaar, qui est un système de contrôle de revision qui comprend les branches et les distributions, et est intégré avec Launchpad. Et avec un peu de chance ces outils nous permettent de rendre notre travail disponible pour Debian, et pour Gentoo, et pour les projets amonts. Et nous permettent également d’utiliser le bon travail des autres distros (même si ils préfèrent que nous ne le fassions pas ;-) ).
Et finalement, il me semble que la difficulté n’est pas de rendre des financements disponibles, c’est de les allouer à des gens et des projets. Je pourrais facilement faire un chèque à SPI (ndt : Software in the Public Interest = Logiciels d’intérêt publique, c’est une entreprise) pour la même somme que j’ai investi dans Ubuntu. Mais qui décidera comment cet argent sera dépensé ? Avez-vous fait l’effort de lire les comptes-rendus financiers de SPI durant ces dernières années ? Qui décide qui est employé à plein temps, et qui ne l’est pas ? Qui décide quels projets obtiennent un financement pour travailler dessus, et ceux qui n’en obtiennent pas ? Bien que j’admire la gouvernance et les structures sociales de Debian, je ne crois pas qu’il soit efficace de lui allouer des fonds et de s’attendre à voir le même niveau de productivité que celui que nous avons pu obtenir dans le projet Ubuntu.
Mélanger le financement avec le volontariat soulève toutes sortes de problèmes. Demandez à Mako de vous parler de cette expérience qui a montré que cette difficulté pourrait bien être codée en dur dans nos gènes - il y a des difficultés sociales profondes avec les projets qui mixent le travail salarié et le volontariat. Je ne suis pas certain que Debian ait besoin de ce genre de défi. Vous pouvez très rapidement avoir un conflit profond entre ceux qui allouent l’argent et qui recrutent, et ceux dont les idées obtiennent des fonds et ceux qui n’en obtiennent pas. Une des choses qui je pense donne à Debian sa vraie force est le sens de la "pureté". Et dans une certaine mesure, le fait qu’Ubuntu n’impose PAS les changements dans Debian a aidé à renforcer cette saine réputation pour Debian.
Ok, mais pourquoi ne pas l’appeler "Debian pour la bureautique" alors ?
Parce que nous respectons la politique de Debian concernant leur marque. Vous pouvez avoir constaté les circonvolutions cérébrales autour de la définition de "l’Alliance DDC" récemment pour avoir un exemple de ce qui arrive lorsque les gens ne la respecte pas (ndt : ne respectent pas la politique de Debian).
Pendant que nous parlons des noms, qu’en est-il du système de nommage "Funky Fairy" ?
Le nom officiel de toute version Ubuntu est "Ubuntu X.YY" où X représente l’annés, moins 2000, et YY représente le mois de la sortie dans cette année. Ainsi la première version, sortie en octobre 2004 était Ubuntu 4.10. La prochaine version (au moment de l’écriture du texte) est prévue pour octobre 2005, et donc elle sera Ubuntu 5.10.
Les noms de code pour le développement prend la forme "adjectif animal". Donc par exemple : Warty Warthog (Phacochère verruqueux - Ubuntu 4.10), Hoary Hedgehog (Hérisson chenu - Ubuntu 5.04), Breezy Badger (Blaireau jovial - Ubuntu 5.10), sont les trois premières versions d’Ubuntu. En général, les gens préfèrent se référer à la version en utilisant l’adjectif, comme "warty" ou "breezy".
Beaucoup de personnes sensées se sont demandées pourquoi nous avons choisi ce schéma de nommage. Il vient d’une plaisanterie sur un ferry entre Circular Quay et un autre endroit, à Sydney :
— lifeless : Combien de temps avant que nous ne sortions la première version ?
— sabdfl : Ca devra être dynamique. Six mois max.
— lifeless : Six mois ! Ca n’est pas beaucoup pour la finition.
— sabdfl : donc nous aurons à la surnommer la version phacochère verruqueux.
Et voilà, le nom est resté. La première liste de discussion pour l’équipe Ubuntu était appelée "warthog" (phacochère), et nous avions l’habitude de traîner sur #warthogs sur irc.freenode.net. Pour les versions postérieures nous voulions rester avec les noms en "hog", alors nous avons eu Hoary Hedgehog (Hérisson chenu), et Grumpy Groundhog (Marmotte grognon). Mais "Grumpy" ne sonnait pas bien, pour une version qui avait l’air vraiment bien, et qui avait une fantastique participation de la part de la communauté. Alors nous avons cherché et trouvé "Breezy Badger" (Blaireau jovial). Nous utiliserons "Grumpy Groundhog", mais ces projets sont encore une surprise à annoncer...
Pour ceux d’entre vous qui pensent que les noms choisis peuvent être améliorés, vous pourriez être soulagé en sachant que le "Breezy Badger" allait à l’origine être le "Bendy Badger" (Blaireau tordu) (je pense encore que ça rend bien). Il y en a eu d’autres...
Pour la santé mentale de tous nous allons essayer de garder un ordre alphabétique après Breezy. Nous pourrions sauter des lettres, et nous auront à reboucler un jour. Mais la convention de nommage est là pour longtemps, au moins. Les possibilités sont sans fin. Gregaruis Gnu (Gnou grégaire) ? Antsy Aardvaark (Oryctérope nerveux) ? Phlegmatic Pheasant (Faisant flegmatique) ? Vous les envoyez, nous examinerons.
L’article original est diffusé sous une licence qui ne permet pas a priori de le reproduire et de le traduire sans la permission de l’auteur. Dans l’attente de sa réponse, nous le publions pourtant car il nous semble que l’information qu’il contient mérite d’être diffusée le plus largement possible et d’être accessible aux locuteurs français qui ne lisent pas ou peu l’anglais.
Néanmoins, il se peut que nous soyons dans l’obligation de le retirer du site si l’auteur en fait la demande. c’est pourquoi nous vous demandons de ne pas reproduire cette traduction ailleurs sur le web, et de vous y référer uniquement à travers un lien. Merci.
sources : http://www.framasoft.net/article624.html
THROUD LE BARBARE qui aime Ubuntu
Commentaires