Re: Arg

> Ça fait 3 ans au moins que il dit que tant que launchpad est pas
> indispensable il peut pas ouvrir le code sinon ca fragmenterait.
>
> Le but c'est d'être la plate-forme incontournable et de ne liberer
> que si aucun concurrent ne peut se mettre à l'égal.

Oui pour la première assertion, la seconde, concernant le but, me semble une interprétation hative.

Dans le fil de discussion lié par la dépêche, Mark Shuttleworth indique que la libération de Launchpad est proche parce qu'il est désormais en mesure de répliquer les données, en fonctionnant plus ou moins en « peer to peer », de façon distribuée.

En ce moment, les développeurs de Launchpad finalisent une API permettant de transférer/échanger/synchroniser/répliquer le contenu à distance, de façon programatique, entre plusieurs installations de Launchpad, et entre des Launchpads, des Bugzilla, des Mantis, des Savannah, des Trac, etc.

Ainsi Launchpad pourra garder sa pertinence (rassembler le plus de données possibles sur une même interface, faciliter les échanges et réduire la fragmentation entre les projets opensource, puisque les diverses copies installées sur internet pourront se synchroniser) sans être centralisé (sans nécessiter d'avoir un seul point d'entrée / une seule installation du logiciel). Et la crainte d'augmenter la fragmentation disparaît.

Si Shuttleworth dit vrai, ce timing me semble légitime, et éclaire rétrospectivement son argument pour ne pas libérer Launchpad immédiatement (« nous le libérerons lorsque le code sera suffisamment avancé ») : il fallait attendre que soient implémentées les fonctionnalités permettant à plusieurs instances/installations séparées du logiciel de fonctionner tout en continuant d'assurer l'objectif fondamental de LP, rassembler/dé-fragmenter l'information.

Pour rappel, LP a toujours été présenté comme un outil destiner à faciliter les échanges entres projets opensource, l'intégration et la centralisation des informations. C'est dans ce but qu'il fut développé (à l'époque, il existait déjà de simples bugtrackers, des outils de suivis de projet, etc déjà tout faits). Il est assez normal qu'il ne soit releasé qu'à partir du moment ou il respecte le contrat, à partir du moment où il peut faire ce pour quoi il est conçu et ce au nom de quoi il se vends (et non l'exact opposé).

Pour faire une analogie simple, c'est un peu comme si vous développiez un nouveau serveur de son et l'annonciez comme « l'API qui va enfin résoudre le merdier du à la multiplicité (alsa, oss, esd, arts, nas, jack, ...) des API exclusives (accès verrouillé au dsp) et plus ou moins incompatibles ». Si vous distribuez votre API alors qu'elle est encore incompatible avec les autres, et que des logiciels commencent à l'utiliser, vous avez simplement renforcé le problème et ajouté votre pierre au merdier. Même si votre logiciel est génial, vous avez aggravé le problème. C'est pourquoi PulseAudio n'a été inclus par défaut dans les grandes distributions (Fedora en premier) qu'à partir du moment où il était capable de cohabiter proprement avec les principaux systèmes « legacy » (via l'émulation esd, les hooks dans alsa-lib, etc.). Question de sens des responsabilités.

Maintenant, on peut légitimement se demander pourquoi il a fallu tant de temps à Canonical pour faire de LP un logiciel « distribué » (à tout les sens du terme)...

[ Répondre ]