A Generation Lost in the Bazaar, c’est le titre d’un article un peu polémique qui est paru récemment dans les Communications of the ACM, dont je recommande la lecture. L’auteur, qui est un contributeur FreeBSD depuis plus de 20 ans, y décrit les limites du modèle du bazar décrit dans le célèbre essai d’Eric S. Raymond. Le sous‐titre, Quality happens only when someone is responsible for it, donne aussi à réfléchir. L’auteur reproche au modèle du bazar son manque de cohérence et de standardisation, il motive son propos en donnant quelques exemples de non‐optimalités dans la collection de portages de FreeBSD :
- il y a plus de 1 000 algorithmes cryptographiques copiés‐collés dans l’ensemble des paquets ;
- pour compiler Firefox, il ne faut pas moins de 122 paquets, dont plusieurs dépendent de Perl ou Python, voire des deux.
Tout cela se poursuit avec le constat que des outils de compilation comme libtool et configure deviennent ingérables à force d’essayer d’apporter une certaine compatibilité entre systèmes. Là aussi quelques absurdités : par exemple, les 26 tests pour trouver un compilateur Fortran absent et inutile. Au final, le modèle du bazar tend à complexifier beaucoup de choses qui auraient pu être unifiées par un standard défini.
Certes, au niveau de l’écosystème il y a des redondances et des absurdités dues au nombre de bibliothèques proposant des fonctionnalités similaires. Chacune d’entre elles vient avec ses dépendances propres, ce qui rend la gestion d’un ensemble cohérent difficile. Cependant, le modèle du bazar a, à mon avis, permis quelques réussites, à l’instar du célèbre noyau qui a donné son nom à ce site. Avec les récents développements de GNOME 3, Unity, systemd, etc. À se demander si le modèle du bazar amène autre chose que du bazar… Tout ça pour vous souhaiter un bon vendredi.
NdM : merci à pmoret pour son journal.
Aller plus loin
- A Generation Lost in the Bazaar (373 clics)
- The Cathedral and the Bazaar (60 clics)
- La cathédrale et le bazar (NdM: lien archive.org) (162 clics)
- Journal à l’origine de la dépêche (136 clics)
# C'est tout autant le bazar sous Windows...
Posté par xcomcmdr . Évalué à 9. Dernière modification le 09 novembre 2012 à 19:12.
Rien que pour (dé)coder de l'audio/vidéo on a droit à 4 frameworks Microsoft au sein de Windows, et leurs propres codecs :
Video For Windows (remplacé par DirectShow mais toujours assez utilisé)
DirectShow (remplacé par WMF, mais toujours très utilisé)
DirectMedia (mort)
Windows Media Foundation (remplace tous les précédents, mais j'ai pas encore vu de codec WMF…)
Youpi (et j'ai pas parlé du fait que DirectShow offre de multiples renderers différents: overlay, VMR7 (basé sur DirectDraw 7), VMR9, … !)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: C'est tout autant le bazar sous Windows...
Posté par pasBill pasGates . Évalué à -1.
Rien a voir.
Chez nous, il y a une clarte certaine sur quel framework est a utiliser et quel framework est supporte mais a ne pas utiliser dans des nouveaux softs, tu l'as decrit toi-meme d'ailleurs, et c'est une grosse difference compare a Linux ou il n'y a rien de tel, c'est totalement flou.
# Inepties
Posté par gasche . Évalué à 7.
Cet article est fade et les arguments sont mauvais. L'auteur a fait des choses très bien et publie dans un média impressionnant par ses connotations scientifiques, mais à part les anecdotes historiques qui sont toujours enrichissantes ça reste une râlerie moyenne d'un utilisateur aigri.
L'auteur râle parce qu'un paquet donné a trop de dépendances. En même temps il râle parce que certains codes sont copiés dans plein de paquets différents. C'est quoi la solution pour résoudre son deuxième problème ? Factoriser le code comme un paquet et en faire… une dépendance supplémentaire. Bonjour la contradiction.
L'écosystème logiciel est complexe. Il y a beaucoup de programmes différents, qui ont beaucoup de dépendances (pour éviter la redondance). Selon les sous-communautés, les organisations sociales, les moyens disponibles, les gens vont avoir un processus de développement structuré de façon plus ou moins rigide. Il n'y a pas une seule bonne manière de faire, mais des choses qui sont adaptées dans certaines situations et pas dans d'autres. Donc au final quand on regarde dans la nature sauvage on observe… un continuum d'états entre "la cathédrale" et "le bazaar" (modèles caricaturaux et extrêmes), avec tout au milieu. Structurer en cathédrale c'est bien pour certains usages, mais ça demande de l'énergie, et en pratique les projets évoluent en moindre effort et les gens font de leur mieux. Il est illusoire de penser qu'on pourrait magiquement, en râlant, faire passer tout le monde à un style particulier donné, ça ne résoudrait rien et ça n'est tout simplement pas la façon dont les choses se passent.
Des choses intéressantes ont été dites sur le "bloat" des logiciels modernes. Le projet STEPS du Viewpoint Research Institute, auquel participe notamment Alan Kay, essaie de concevoir le logiciel d'un ordinateur personnel en moins de 20 000 lignes de code. John Regehr dit des choses intéressantes sur la question ici (Can Simplicity Scale) et là (It's All About Interfaces). En comparaison, l'article de cette dépêche fait pâle figure, énumérant les jérémiades sans lien logique ou proposition constructive.
[^] # Re: Inepties
Posté par barmic . Évalué à 4.
En lisant un peu plus, on voit de quoi il veut parler :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Inepties
Posté par gasche . Évalué à 10. Dernière modification le 09 novembre 2012 à 23:20.
Je ne sais pas ce que tu veux dire par "en lisant un peu plus", j'ai bien sûr lu le billet avant de le critiquer.
Le texte que tu cites n'a rien de particulièrement convaincant : tu peux avoir un paquet Firefox qui dépend du paquet Toto qui lui-même dépend du paquet Tiff pour certaines de ses fonctionnalités, que Firefox lui-même n'utilise pas (genre, au hasard, un truc à la ImageMagick qui supporte 60 formats dont 59 intéressent Firefox).
Avec un gestionnaire de paquets source, tu peux gérer un peu finement les dépendances de tes dépendances (genre les USE flags de gentoo), mais déjà ça suppose que Toto a été pensé pour pouvoir désactiver sélectivement des formats (pas forcément la priorité des développeurs), et ensuite les packageurs binaires vont souvent faire le choix simplificateur d'activer tous les formats pour pouvoir servir tous les paquets utilisant Toto et pas juste Firefox et se simplifier la vie de gestionnaire de dépôts—et parce qu'ils s'en moquent que l'auteur du billet fasse une crise de nerf parce que Firefox installe libtiff.
De même, Firefox peut décider d'utiliser deux bibliothèques super utiles, une pour parser le HTML et l'autre pour communiquer à travers le réseau, l'une étant écrite en Python et l'autre en Perl, deux langages qui demandent un support runtime donc doivent être installés avec ces libs. Qu'est-ce que l'auteur aigri conseille aux développeurs de Firefox (ou autre) de faire en ce cas ? Ré-écrire l'une des bibliothèques dans l'autre langage pour n'installer qu'un seul runtime ? Demain il refait un billet pour dire que c'est un scandale, son système a voulu installer deux bibliothèques implémentant le même algorithme, et ce dans deux langages différents.
Peut-être que dans son esprit les développeurs et packageurs de Firefox devraient se plier en quatre pour, surtout surtout, n'avoir aucune dépendance superflue et porter les bibliothèques en Perl vers Python pour simplifier encore les dépendances. Sauf que dans la vraie vie ces gens-là ont bien plus intéressant et utile à faire de leur temps et leur énergie, pour aider à résoudre d'autres problèmes qui font certainement râler quelqu'un d'autre sur le net. Et si un jour ces problèmes deviennent gênants (oui ça arrive), les gens investissent plus d'effort là-dedans, on a un peu plus de cathédrale et un peu moins de bazaar le temps d'une restructuration, et ça repart.
PS: et tout ce que j'ai dit est assez évident, tu aurais certainement pu faire l'effort de dérouler cette argumentation toi-même.
[^] # Re: Inepties
Posté par barmic . Évalué à 2.
Je voulais dire « en allant 2 paragraphes plus bas ».
Merci je connais la logique qui induit ce genre de dépendances.
Soit.
D'arrêter de faire du bloatware. Avoir 2 runtimes (un perl et un python) pour finallement en exécuter un autre (JS), en passant son temps à faire des bindings dans tout les sens ces contre-productifs et contre-performant. Ça rend le logiciel plus compliquer à maintenir (multiplier les langages dans un même projet ça ne simplifie rien). Ça rend de plus le logiciel plus fragile si l'une des briques a un problème, firefox en a un.
Je vais me contenter de citer ce que j'ai dis dans le journal :
Si la raison est simplement qu'un développeur préfère tel ou tel langage, ça ne me semble pas être une bonne raison.
Le problème à grande échelle c'est que l'on arrive a avoir des systèmes de paquet dont le graphe de dépendances des paquets se rapproche d'une clique pour éxagérer. Tu peut le voir comme un aigri, mais c'est un réel problème pour le packaging.
Parce que tu pense que la lourdeur de Firefox n'est pas aussi (mais pas que) lié à ce genre de gestion ? Si demain, Mozilla trouve qu'OSGi est vraiment la meilleure manière pour gérer les plugins et ajoute comme dépendance à Firefox la JVM (et felix histoire de). Tu vois pas où est-ce que ça peut mener ?
Ouai on se traine une dette technique et il n'y a que quand on ne peu plus regarder ailleurs qu'on y fait attention. C'est une manière de faire, c'est pas la seule et je pense que tu peut comprendre que l'opposée est envisageable.
Tout comme sa critique était assez évidente, tu aurais probablement pu faire l'effort de la dérouler toi même.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Inepties
Posté par xcomcmdr . Évalué à 0.
La lourdeur de Firefox à ce que j'ai compris c'était surtout dû à ses fuites de mémoire, et à celles, très fréquentes, des extensions.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Inepties
Posté par Anonyme . Évalué à 9.
Interessant comme conseil. Tant qu'a faire, on pourrait aussi conseiller d'arreter de faire des bugs, des logiciels trop lents, qui consomment de la RAM, du CPU ou de l'espace disque, des logiciels qui manquent de fonctionnalités, ou qui sont trop compliqués à utiliser.
Mais pourquoi donc les développeurs n'écoutent ils jamais nos précieux conseils ? On leur a deja pourtant dit plusieurs fois qu'il fallait faire des logiciels sans bugs et sans bloat, mais à chaque nouvelle version c'est pareil, on peut constater qu'ils n'en ont pas tenu compte !
[^] # Re: Inepties
Posté par Antoine . Évalué à 4.
Ils n'ont certainement pas vu cette émission très instructive :
http://www.youtube.com/watch?v=tNfGyIW7aHM
[^] # Re: Inepties
Posté par barmic . Évalué à 2.
Je peux critiquer un choix de développement, je présume, non ? J'affirme qu'avoir 2 dépendances qui dépendent de runtime différents apportent un certains nombre de problèmes. Ma phrase était un peu assassine mais mon commentaire était argumenté et expliqué.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Inepties
Posté par djano . Évalué à 3.
Dites donc, vous êtes tous les deux en train de tirer des plans sur la comète: Est ce que ces fameuses dépendances sont le fait de choix des développeurs ou des empaqueteurs? A moins de parler d'un cas précis et d'argumenter sur celui-ci, ça reste juste un joli troll tout juste bon pour occuper un dimanche pluvieux.
Oh! Je viens de comprendre! ;)
[^] # Re: Inepties
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
Sous BSD, comme sous Gentoo, on ne fait que peu de paquets, la voie royale, c'est la re-compilation des sources donc on peut facilement dire que ça vient des développeurs.
[^] # Re: Inepties
Posté par djano . Évalué à 2.
Sous Gentoo, reste a ce que les USEFLAGS soient bien présents. Il est aussi possible d'utiliser les paquets binaires sous Gentoo.
Je ne connais pas le système de paquets sur BSD.
[^] # Re: Inepties
Posté par djano . Évalué à 2.
Et j'ajouterai: mais pourquoi donc les utilisateurs demandent les fonctionnalités qui mènent au bloat et s'en plaignent ensuite? ^_^
[^] # Re: Inepties
Posté par gasche . Évalué à 4.
Pas du tout, s'ils sont dans cette situation c'est parce que c'était le plus simple étant donné leurs besoins et les circonstances. Ou alors tu penses que les développeurs de Firefox ont fait exprès des choix contre-productifs, par erreur ou aveuglement, et que leur donner un message aussi utile et construit que "bouh le bloatware c'est mal" va les aider à sortir de leur erreur et donc leur rendre grand service. Des erreurs arrivent toujours, et c'est bien de prendre soin d'éduquer les développeurs, mais il se trouve que dans ce cas précis je pense pouvoir prédire sans me tromper qu'utiliser à la fois du software perl et du software python leur a vraiment simplifié la vie, et que supprimer l'un des deux leur demanderait du travail pour un bénéfice qui n'en vaut pas la peine.
Bien sûr si toi tu accordes une importance supérieure à ces questions (tu choisis de favoriser la propreté du design plutôt que les besoins objectifs, ce qui peut avoir un intérêt, je le dis en perfectionniste averti), tu es libre de donner ton propre temps pour résoudre cette situation, c'est beau le logiciel libre. Mais bon écrire des articles rageux dans Communication of the ACM (ou des réponses un peu creuses sur LinuxFR) c'est quand même plus simple.
[^] # Re: Inepties
Posté par barmic . Évalué à 3.
Comme répété déjà 3 fois : c'est une situation qui peut avoir du sens mais il ne faut pas oublier qu'elle apportent un certains nombre de contraintes et de problèmes (déjà sus-cité).
Avoir des contraintes de simplicité et de temps c'est tout à fait normal. Faire des choix pragmatiques aussi, mais ce n'est pas pour ça qu'il faut se voiler la face et dire qu'il n'y a pas de problème. Il est tout à fait possible d'adopter une solution simple et rapide tout en indiquant qu'il faudra faire mieux plus tard. Reconnaître ce genre de chose n'est pas une tare.
Tu as raison, tout comme je suis libre de faire des remarques. Je regarderais plus en détail ce que c'est ces dépendances.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Inepties
Posté par GeneralZod . Évalué à 4. Dernière modification le 10 novembre 2012 à 03:13.
c'est une description assez réaliste des lutins. :o)
# Captain Obvious
Posté par Nico C. . Évalué à 6.
En gros, l'auteur vient de decouvrir que le modele du Bazaar a aussi des defauts et il s'en indigne joyeusement… Hé bien, il a mis autant de temps pour decouvrir tout ca ? wow…
[^] # Re: Captain Obvious
Posté par Antoine . Évalué à 2.
Et puis, le monde des cathédrales n'est pas exempt de forks, donc de bazar. Combien de BSD libres, déjà ?
[^] # Re: Captain Obvious
Posté par Tonton Th (Mastodon) . Évalué à 2.
Il y en a juste assez pour avoir un vrai choix. Ceci dit, je m'attend à voir débarquer un de ces jours le LP-Bsd, avec du vrai code moderne dedans.
Oh wait…
# Ce n'est pas qu'un problème technique
Posté par Albert Seandhils . Évalué à 1.
Le bazar ne pose pas qu'un problème technique de programmeur.
Il faut aussi s'y retrouver dans tous les choix qu'on nous propose.
Dans la vraie vie, quand je vais au bazar, je "chine", je prends mon temps, je compare, je négocie.
Mais des fois, je n'ai que 20 minutes pour faire mes courses, dans ce cas, c'est l'hypermarché du coin avec ses rayons bien organisés et ses produits calibrés.
Dans l'open source, la dérive, c'est que chacun est tenté de refaire son truc dans son coin, plutôt que d'essayer d'améliorer l'existant. Pour un étudiant, c'est bien. Pour une entreprise, on n'a pas toujours le temps pour tout étudier.
Autant je trouvais ça bien de savoir qu'il existait des alternatives "libres/open source" pour les logiciels propriétaires, autant quand ça foisonne trop, on s'y perd et on se rabat sur le propriétaire, mais pour des mauvaises raisons.
Faire un comparatif entre IIS / Apache / Nginx, c'est constructif.
Passer des semaines à comparer Project / EGrouWare / Collabtive / PHPCollab / ProjectLead / …
Ca devient compliquer et chronophage.
A cela se rajoute une tendance à l'escalade dans les projets libres. Parfois difficile (pour une entreprise) de suivre le rythme des releases de Firefox par exemple.
Tout se passe comme si, bien que n'ayant (à priori / en apparence) pas d'intérêt financier, ces groupes projets seraient dans une "course au buzz". course en avant pour assoir son leader ship.
La plupart des boîtes ne font pas de l'informatique pour l'informatique.
[^] # Re: Ce n'est pas qu'un problème technique
Posté par djano . Évalué à 3.
Si tu es dans une entreprise, essaie donc de choisir un ERP privateur. Tu vas voir combien de temps tu y mettras et c'est pas dit que ce sera moins de temps qu'avec les ERP libres :)
[^] # Re: Ce n'est pas qu'un problème technique
Posté par Albert Seandhils . Évalué à 0.
Oui mais le choix d'un ERP, ou d'un logiciel RH, c'est structurant pour l'entreprise. Tout le monde va comprendre qu'on va prendre du temps pour comparer. Ce n'est pas forcément la cas pour un anti-spam, un proxy …
[^] # Re: Ce n'est pas qu'un problème technique
Posté par Antoine . Évalué à 1.
Oui, acheter de la merde calibrée à l'hypermarché est vraiment une alternative supérieure au choix du bazar !
(et c'est vrai qu'on s'y retrouve très bien, à l'hypermarché : tous les yaourts sont pareils même s'il y a vingt marques différentes)
[^] # Re: Ce n'est pas qu'un problème technique
Posté par reno . Évalué à 5.
C'est surtout le problème d'avoir beaucoup d'alternatives pas très finie qui est un problème plus que le choix en lui-même.
[^] # Re: Ce n'est pas qu'un problème technique
Posté par Albert Seandhils . Évalué à 1.
Tout a fait d'accord
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.