C'est le titre d'un article un peu polémique qui est paru récemment dans les Communications of the ACM [1] 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[2] 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 ports de FreeBSD :
- Il y a plus de 1000 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, de python, voire des deux.
Tout cela se poursuit avec le constat que des outils de build comme libtool et configure qui 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 elle 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 Gnome3, 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.
[1] L'article original
[2] The Cathedral and the Bazaar (traduction française (NdM: remplacement par un lien archive.org))
# Traduction
Posté par Julien Gilbert . Évalué à 4.
Quelqu'un pourrait proposer une traduction ? Ou ouvrir un framapad ?
Vous voulez pas la jouer soft ? Je suis pas contraignant... vous voulez la jouer hard ? On va la jouer hard
[^] # Re: Traduction
Posté par pmoret (site web personnel) . Évalué à 4.
S'il y a de la demande, je peux me lancer dans une traduction, je ne voulais pas le faire d'office de peur que personne ne s'y intéresse. Le cas échéant s'il y'a des volontaires pour m'aider je suis preneur ;-)
[^] # Re: Traduction
Posté par liberforce (site web personnel) . Évalué à 6.
Tu pourrais en profiter pour éclaircir ta remarque ?
Je sais que c'est vendredi, mais j'ai pas trop compris ce que tu voulais dire.
[^] # Re: Traduction
Posté par pmoret (site web personnel) . Évalué à 1.
Oui j'ai un peu remanié en vitesse et j'ai relu, mais trop tard… je pense que je voulais dire plutôt:
[^] # Re: Traduction
Posté par liberforce (site web personnel) . Évalué à 4. Dernière modification le 09 novembre 2012 à 13:38.
Je dois être un peu con sur les bords, mais j'ai toujours pas compris. Ces projets te semblent positifs ou négatifs ? Issus de la Cathédrale ou du bazar ? Parce que sans être dans ta tête, j'ai du mal à voir ce que tu veux transmettre comme information derrière ta remarque…
[^] # Re: Traduction
Posté par freem . Évalué à 1.
il suffit de remanier la phrase pour comprendre sa pensée:
on peut se demander si le modèle du bazar amène
==> amènent-ils
Ce qui nous donne: "les récents dév […] amènent-ils du bazard?
Traduction et super raccourci trollesque:
Les récents dév de […], c'est le bordel
(perso, j'en sais rien, j'en utilise aucun )
# Choses vues en entreprises
Posté par palm123 (site web personnel) . Évalué à 10.
Oui, on peut reprocher des choses à ce modèle.
Cependant, ayant travaillé dans un certain nombre de (grandes) entreprises, je trouve le libre très en avance, quand je compare avec ce que je vois couramment
- code développé sans respecter les moindres règles de codage
- pas de svn, git, mercurial ou autre outil de gestion des sources
- pas de documentation
- pas de spécifications
- pas de tests (ah si, on lance le programme une fois, il ne s'est pas planté de suite, donc c'est bon, non ?). TTD c'est quoi?
http://fr.wikipedia.org/wiki/Test_Driven_Development
- Fuzzing c'est quoi
http://fr.wikipedia.org/wiki/Fuzzing
Cela est d'autant plus vrai que l'entreprise se vante d'avoir des méthodes, normes, et d'être certifée ISO "mes c…", ITIL et autres machins.
ウィズコロナ
[^] # Re: Choses vues en entreprises
Posté par mazarini . Évalué à 10.
La certification ISO 9001 est souvent une vaste fumisterie. Dans les faits la certification est purement et simplement achetée.
J'ai travaillé dans une société ou j'ai mis 2 ans avant de savoir que je ne respectais pas les normes qualité pour les mises en production.
Récemment, on s'est fait engueuler parce qu'un incident n'était pas affecté à l'équipe qui était en train de s'en occuper, par contre que l'incident traînait depuis 15 jours ne dérangeait visiblement personne.
Dans une autre boite, on nous a fait rendre nos manuels qualité de peur qu'ils ne soient pas à jour lors d'un audit : il vaut mieux que l'on y ait pas accès plutôt que d'avoir la version précédente.
Dans une SSII, on avait certifié le service compta interne ISO 9001 pour pouvoir dire aux clients que l'on était certifié.
J'ai souvent l'impression que que la certificat qualité est uniquement une vitrine pour les clients.
[^] # Re: Choses vues en entreprises
Posté par Christophe Turbout . Évalué à 6.
dans iso 9001 tu peux faire du grand n'importe quoi, ce que te donnes la norme iso c'est que, ce que tu vas faire, c'est ce que tu as décris … Mais si ce que tu as décris est nul, ça n'empêche pas d'être certifié.
[^] # Re: Choses vues en entreprises
Posté par Misc (site web personnel) . Évalué à 2.
Comme bien souvent , si une certif a de la valeur, alors des gens vont contourner le système, et vont ne psa comprendre ce qu'il faut faire, et mal communiquer ( à dessein parfois ). Ensuite, si la survie de ton poste, de ta boite est en jeu, ouais, c'est difficile de jouer le jeu ( car bien sur, si la certif existe, c'est parce que des clients la demandent )
[^] # Re: Choses vues en entreprises
Posté par djano . Évalué à 3.
Voici comment marche la certification ISO 9001: Si tu produis de la merde, la certification ISO 9001 certifiera que tu es capable de produire la même merde de manière constante dans le temps avec un écart minime. :)
[^] # Re: Choses vues en entreprises
Posté par pmoret (site web personnel) . Évalué à 2.
Oui, mais est-ce que tu parles d'éditeurs de logiciels, ou d'entreprises qui développent leurs propres outils en interne ?
Je pense qu'il y a une différence à faire, dans le sens qu'un éditeur (à mon avis) peu moins se permettre d'avoir des "features" pas documentées ou un code ingérable. Tandis qu'une entreprise qui ne développe que pour son usage interne sera plus tentée par du "quick & dirty" pas documenté, pas testé, pas versionné. Bien entendu sur le moyen/long terme c'est pas loin d'être catastrophique, mais ça me semble, malheureusement, plus viable dans ce cas que dans le premier.
[^] # Re: Choses vues en entreprises
Posté par palm123 (site web personnel) . Évalué à 2.
Je parle d'entreprises qui développent leurs propres outils en interne.
ウィズコロナ
[^] # Re: Choses vues en entreprises
Posté par djano . Évalué à 2.
Ben j'ai déjà vu une entreprise dont le produit phare ne suivait aucune des pratiques ci-dessus. Elle est toujours vivante… mais je ne conseille a personne de suivre son chemin! Peut être ont ils changés leurs pratiques depuis?
[^] # Re: Choses vues en entreprises
Posté par Spack . Évalué à 8.
Ah non, TTD c'est http://fr.wikipedia.org/wiki/Transport_Tycoon#Transport_Tycoon_Deluxe_.28TTD.29
# trotrotrotro troll !
Posté par Firwen (site web personnel) . Évalué à -2.
Ahh, Le meilleur sujet à troll dés Vendredi Matin : Cathédrale vs Bazaar ! félicitations
Quelqu'un de la communauté BSD, communauté qui a toujours prôné le developpement à la "Apache", controlé, centralisé, etc… crache sur le développement de style bazaar, vraiement étonnant :D
J'ai par ailleurs un peu de mal à voir le rapprochement entre un développement de style bazaar : c'est à dire, "git-style" avec des branches partout, où tout le monde contribue et soumet ses modifications… cad réellement communautaire quoi et … autotools….
Le fait que autotools soit une usine à gaz avec des horreurs comme libtool tient à son architecture et à ses choix de design… qu'est-ce que son modèle de développement vient faire là dedans ?
[^] # Re: trotrotrotro troll !
Posté par liberforce (site web personnel) . Évalué à 5.
Le point de vue est pourtant expliqué dans le journal… Il pense que c'est le fait de s'adapter à de multiples cas différents par manque de normalisation qui a obligé libtool à devenir une usine à gaz pour gérer toutes les exceptions à la règle.
[^] # Re: trotrotrotro troll !
Posté par Firwen (site web personnel) . Évalué à 0.
Oui et c'est justement sur ça que ça sent le troll.
S'adapter à de multiple cas ou autrement dit: être aussi portable que possible a été un choix de design de autotools/libtool.
ça n'a rien à voir avec le modèle de développement collaboratif, un modèle de type "cathédrale" ayant fait les même choix de design que les GNU/autotools auraient les même problèmes…
[^] # Re: trotrotrotro troll !
Posté par GaMa (site web personnel) . Évalué à 3.
La question est de savoir si un modèle de type "cathédrale" aurait fait les même choix de design.
Matthieu Gautier|irc:starmad
[^] # Re: trotrotrotro troll !
Posté par psychoslave__ (site web personnel) . Évalué à 3.
La réponse est sans doute que l’architecte de la cathédrale, tout génial puisse être son cervelet générateur d’élégances rationalisées, n’aurait sûrement pas le temps de s’égarer dans l’élaboration d’un dixième de toutes les fonctionnalités que vomis le grand bazar.
[^] # Re: trotrotrotro troll !
Posté par barmic . Évalué à 3.
La question n'est pas la manière dont les autotools sont développés, mais la manière dont les autotools doivent gérer les développements en bazaar des autres. Il parle de l'organisation globale, du fait que certains paquets ajoute des dépendances sans chercher à avoir une quelconque cohérence avec le reste de leurs dépendances (puis-je déjà faire le travail avec une dépendance déjà existante ?) ni avec le reste des système cible (quelle est la bibliothèque pour faire ce boulot la plus utilisée sur les systèmes existant ?). Bien sûr qu'il peut y avoir de bonnes raisons pour ajouter une dépendance, mais il faut justement la chercher avant de la créer. Si une bibliothèque qu'on utilise déjà (ou qui est utilisée sur le système) devrait faire le boulot mais ne le fait, il faudrait en parler au projet upstream en question.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: trotrotrotro troll !
Posté par freem . Évalué à 5.
Ben, pour autotool, perso, j'ose pas apprendre à m'en servir.
Dès que je regarde le contenu de ces choses, mon PC mets une musique d'outre-tombe, la lumière diminue et prends des reflets de rouge sang, ma chaise et mon velux claque…
CMake, j'avais peur aussi. Mais quand j'ai regardé un fichier la première fois, aucune ambiance inquiétante ne s'est déclenchée, alors j'ai même trouvé et résolu le problème que je cherchais en moins de 10 minutes.
[^] # Re: trotrotrotro troll !
Posté par barmic . Évalué à 2.
Ouai mais bon, ils ne font pas la même chose, les deux.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: trotrotrotro troll !
Posté par liberforce (site web personnel) . Évalué à 1.
C'est à dire ? KDE est passé à CMake il y a un bon moment, donc CMake n'est pas non plus un jouet…
[^] # Re: trotrotrotro troll !
Posté par barmic . Évalué à 2.
Ça n'est absolument pas mon propos. CMake est un super outil très pratique. C'est juste pas une solution de build. Il ne se substitue pas complètement aux autotools. Bref c'est pas CMake qui appel le compilateur (malheureusement).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: trotrotrotro troll !
Posté par liberforce (site web personnel) . Évalué à 3. Dernière modification le 09 novembre 2012 à 17:34.
Pardonne ma naïveté, mais a priori sa sortie, c'est un makefile, comme les autotools. Tu aurais un lien à me filer qui parlerait des défauts que tu trouves à CMake ? J'ai toujours vu SCons, CMake et les autotools comparés comme étant le même type de solutions.
[^] # Re: trotrotrotro troll !
Posté par barmic . Évalué à 2.
Réellement je ne lui trouve pas de défauts (enfin si peut être mais c'est pas le sujet).
Avec CMake tu va écrire un CMakeLists.txt qui va te permettre de générer des fichiers pour différents systèmes de build, dont autotool si je ne me trompe pas. Pour la recherche de bibliothèques il s'appuie sur ces générateurs, non ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: trotrotrotro troll !
Posté par Gilles G. . Évalué à 4.
Non, la recherche de bibliothèques est effectuée par CMake. En fait CMake génère des makefiles, il suffit donc d'avoir make d'installé.
[^] # Re: trotrotrotro troll !
Posté par liberforce (site web personnel) . Évalué à 3.
Effectivement, comme dit au dessus, tu te trompes, CMake produit bien des Makefile, pas des fichiers consommés par les autotools. Du coup, je ne comprenais pas tes critiques.
[^] # Re: trotrotrotro troll !
Posté par liberforce (site web personnel) . Évalué à 2.
Zut, je répondais au commentaire de Michel bien sûr !
[^] # Re: trotrotrotro troll !
Posté par Kerro . Évalué à 4.
La communauté BSD est moins centralisée que celle de Linux. Et je n'ai pas le souvenir d'en avoir spécialement vu cracher sur d'autres modèles de développement (UN exemple ne compte pas, il faut que ce soit une attitude générale).
C'est Mister Tovarlds qui décide comment doit être implémentée telle fonctionnalité (selon les propositions qui sont faites). C'est lui qui donne des coups de cravaches pour que les choses avancent dans le sens qui lui convient.
Avec NetBSD par exemple, c'est bien moins le cas.
[^] # Re: trotrotrotro troll !
Posté par Firwen (site web personnel) . Évalué à 1.
OpenBSD ?
[^] # Re: trotrotrotro troll !
Posté par djano . Évalué à 2.
Et DragonflyBSD aussi?
Les leaders charismatiques sont Theo de Raadt pour OpenBSD et Matt Dillon pour Dragonfly.
# Sauf que le noyau n'est pas vraiment un "bazar"
Posté par reno . Évalué à 6.
On ne peut pas vraiment dire que le développement du noyau Linux soit de style "bazar" car le noyau a gardé une ABI garantissant la compatibilité ascendante ce qu'on peut mettre au crédit de Linus (contrairement à ce qu'en dit un certain M..d.).
Après pour le reste (Gnome, KDE, machinKit/udev/systemD, etc), effectivement c'est un exemple du développement en mode bazar, avec les avantages (ça existe, ça marche pas trop mal) et les inconvénients (tout casser régulièrement, pas de compatibilité ascendante).
Maintenant voir les inconvénients du mode bazar, ça n'aide pas trop à voir comment on pourrait faire mieux..
[^] # Re: Sauf que le noyau n'est pas vraiment un "bazar"
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à -3.
Gné ? Linux n'a jamais été stable ni en API ni en ABI. C'est d'ailleurs pour ça que Greg Hartman a bien expliqué que de vouloir maintenir des drivers (propriétaires ou pas) de son côté sans intégration dans les sources du noyau est peine perdu et qu'il sera toujours difficile à une entreprise de suivre les évolutions et refacto qui sont fait dans le noyau si le code en question n'est pas dedans directement.
Donc non Linux n'a ni une API ni une ABI stable, et la compatibilité ascendante ou descendante n'existe que dans ton commentaire.
[^] # Re: Sauf que le noyau n'est pas vraiment un "bazar"
Posté par Martin Peres (site web personnel) . Évalué à 4.
Je pense qu'il voulait parler de l'ABI avec l'espace utilisateur. Pas l'ABI interne qui n'est en aucun cas stable.
Une solution pour ça serait par exemple d'autoriser le changement de l'ABI uniquement tous les x kernels ou une fois par an. Pour pas empêcher le développement de certains projets, faudrait que seulement certaines parties soient considérées comme stables. Typiquement, ça serait les parties qui sont des dépendances de drivers propriétaires ou plus généralement, "out of the tree".
Je n'ai personnellement aucun besoin d'avoir une ABI stable mais je peux comprendre que ça gène certains. Cette gène est peut-être aussi bénéfique car elle pousse les constructeurs à contribuer upstream si ils ne veulent pas continuellement porter leur code.
[^] # Re: Sauf que le noyau n'est pas vraiment un "bazar"
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 1. Dernière modification le 09 novembre 2012 à 22:25.
Mais j'avais bien compris de quoi il s'agissait…et non ce n'est pas stable.
Les outils en espace utilisateurs qui s'interfacent avec le noyau doivent se mettre à jour de temps en temps. Essaye de mettre une kernel récent sur une vieille distro, tu vas voir que la libc sera foireuse par exemple.
J'ai retrouvé la vidéo dont je parlais plus haut : https://www.youtube.com/watch?v=L2SED6sewRw (si qq1 a une autre source que youtube…)
# Objectivement...
Posté par StreakyCobra . Évalué à 5.
Je me suis toujours demandé comment un système comme Bazaar pouvait fonctionner. Non je ne l'aime pas, j'aime la structure, les choses bien faites, bien pensées dès le début, retravaillées. Il m'arrive souvent de recommencer depuis zéro certains codes qui pourtant marchent, rien que parce qu'avec les connaissances acquises en faisant la première version une autre solution, architecture me semble plus propre ou plus adaptée pour une évolutivité future.
Mais objectivement il faut bien admettre que ce système fonctionne. Aujourd'hui j'ai un ordinateur sous linux qui fonctionne parfaitement malgré un bordel de programmes et librairies hétérogènes sans nom (un bazaar en somme). Mais ça marche, et c'est ce qui compte dans mon utilisation de tous les jours.
Après je pense que le jour ou j'aurais le temps de contribuer à des logiciels libres, je choisirai FreeBSD plutôt que Linux (dans le cas d'un noyau/système d'exploitation), simplement parce que je n'arriverai pas à travailler avec un modèle trop bazaardisé.
Mon passage préféré de l'article :
[^] # Re: Objectivement...
Posté par barmic . Évalué à 6.
Tu confond bazaar et LaRache.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Objectivement...
Posté par Firwen (site web personnel) . Évalué à 5.
Exactement, développé en "Bazaar" ça veut dire avec un modèle de développement horizontale, ça ne veut pas dire accepter la première merde venu dans ton code.
[^] # Re: Objectivement...
Posté par barmic . Évalué à 3.
C'est ce dont je parlais plus bas. Il ne faut pas confondre le modèle à larache et le modèle en bazaar.
Mais en l’occurrence d'après le journal ce manque d'organisation viens du fait que personne n'a cette tâche.
D'autre part je crois que le noyau linux a un modèle pyramidale. Contrairement à ce que dis le journal les DCVS sont très bons pour ça (et git a était conçu dans ce but). On propose sont patch à l'échelon n+1 qui va éventuellement le pousser à l'échelon n+2 etc.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Objectivement...
Posté par barmic . Évalué à 2.
Hum je pensais être plus haut dans la page dans un autre fil…
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Objectivement...
Posté par StreakyCobra . Évalué à 4.
Possible que je confonde, je ne voulais pas dire que le code écrit en mode bazaar ne peut pas être propre et structuré.
Mais dans l'idée c'est que même 50 codes de très bonne qualité, si ils ne suivent pas une même ligne conductrice, une même philosophie, d'une fois assemblé ça devient juste un ensemble incohérent et le tout n'est plus de qualité. C'est là ou je rejoins l'avis de l'article en disant que la "qualité n'arrive que lorsque quelqu'un en est responsable":
On peut imager ça en quelque sorte en disant qu'une distribution Linux c'est un assemblage de pleins de programmes, de bonne qualité pour une grande partie, mais qui font un tout désuni, parce que chacun fait comme il veut dans son coin. FreeBSD m'a l'air⁽¹⁾ plus structuré à ce niveau, d'avoir une ligne conductrice, etc.
Mais bon, comme toujours le bon choix se situe très certainement entre les deux, entre le bazar et la cathédrale.
(1) parce que je ne connais pas
beaucoupdu toutencore FreeBSD[^] # Re: Objectivement...
Posté par reno . Évalué à 1.
Euh à peine plus, FreeBSD n'a pas son propre desktop, son propre gestionnaire de version, son propre navigateur, sa propre suite bureautique..
OpenBSD est peut-être plus poussé sur ce point là avec OpenSSH, OpenBGPD, OpenNTPD, OpenCVS, OpenSMTPD, mais bon juste un peu.
[^] # Re: Objectivement...
Posté par barmic . Évalué à 4. Dernière modification le 09 novembre 2012 à 14:48.
Je crois que ça n'a rien avoir, c'est l'organisation du développement qui est important pas le code en question. Tu peut avoir un modèle en bazaar, sur un logiciel particulier.
Il me semble que les BSD avec leur organisation en basesystem d'un coté et port de l'autre permet d'avoir quelque chose d'organisé dans le basesystem et d'avoir du bazzar dans les ports.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Objectivement...
Posté par Misc (site web personnel) . Évalué à 4.
Et quand tu propose de refuser des trucs pour faire les choses suivant une ligne directrice, ça va jusqu'aux insultes comme on puet le voir pour Lennart P. ou les devs GNOME 3 ( et je prends ça parce que c'est des exemples que tout le monde peut voir, mais j'ai d'autres exemples qui me sont arrivés personnellement, certes pas au niveau des 2 premiers, mais avec le même fond ).
Tout le monde est d'accord pour suivre une ligne directrice tant que ça s'applique pas à lui…
[^] # Re: Objectivement...
Posté par reno . Évalué à 3.
Tu ne comprends pas: le "bazar" interviens car il y a beaucoup de contributeurs, même si chacun des contributeurs aime "l'ordre", comme chaque contributeurs a une notion différente de l'ordre --> bazar.
L'exemple bien parlant est Firefox qui dépend à la fois de Python et de Perl, deux langages de scripts qu'on peut pourtant considérer comme équivalent, dans une architecture "en cathédrale" il y aurait un architecte qui te dirais par exemple que le langage de scripting utilisé doit être Guile..
Maintenant tout ces apôtres du développement "en cathédrale" oublient juste quelques détails: Qui sera l'architecte? Pourquoi des développeurs non-payés l'écouteraient?
Si tu as plusieurs petit projets pour faire la même chose avec chacun l'architecte de son projet, ça ressemble fortement à du bazar non?
[^] # Re: Objectivement...
Posté par StreakyCobra . Évalué à 2.
Pour la première partie de ton commentaire je me suis corrigé dans un commentaire juste en dessus :)
Je vois bien ce que tu veux dire pour la deuxième partie. Je n'ai pas de réponses à ces questions. J'ai simplement l'impression qu'un despotisme éclairé (Linus?) est plus prolifique que l’absence de direction. Après choisir qui sera l'architecte et donner une raison de l'écouter… là je sèche.
[^] # Re: Objectivement...
Posté par barmic . Évalué à 2.
C'est une question de leadership (comme en entreprise d'ailleurs). Par contre les développeurs non-payés l'écouteraient car 1) il a raison (et s'il a tord il sait entendre raison), 2) leur code ne serait pas commité s'ils refusent les règles (libre à eux de forker s'ils pensent que c'est la bonne solution).
À moins de développer comme un tout l'OS (ce qui est fait chez Apple et MS) en partie oui. Mais certaines grandes lignes pourraient devenir communes et on verrait apparaître des standards de fait. Un modèle encore plus haut serait de passer par POSIX/LSB/Freedesktop pour plus de choses encore.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Objectivement...
Posté par reno . Évalué à 2.
Pour ta réponse ok, c'est la raison pour laquelle Linus a de "l'autorité", donc la question est maintenant pourquoi ça a pu se produire pour le noyau mais pas pour un desktop?
Et est-ce que ça s'est produit ailleurs que pour le noyau?
Samba (et Andrew Tridgell) est un exemple, mais c'est le seul qui me viens a l'esprit..
Je dirais qu'un desktop n'a pas d'interface bien définie, donc ça n'aide pas..
[^] # Re: Objectivement...
Posté par StreakyCobra . Évalué à 3.
J'imagine que c'est principalement dû au fait que le noyau (et samba surement aussi) sont des gros projets, complexes, techniquement difficiles et donc restreints à une certaine élite.
Ainsi personne n'a d'intérêt de partir sur un fork ou de crée un nouveau projet, et du coup l'acceptation de l'autorité paraît la meilleure solution.
Par contre le desktop n'entre pas dans cette catégorie. Là tout le monde a son mot à dire parce que tout le monde peut comprendre le sujet, tout le monde peut coder sa propre application et même avec un petit groupe de personne il est possible de maintenir en vie un projet annexe.
[^] # Re: Objectivement...
Posté par freem . Évalué à 1.
Mais tout ça n'empêche pas que le bazard ou la cathédrale m'avaient toujours semblé s'appliquer au dev d'un seul logiciel? Pas d'un OS complet et des multitudes de logiciels qu'il inclue, et c'est la "faute" des dev qui ont tous différents besoins… Je me vois mal obliger les dev de firefox à utiliser telle librairie gérant la sérialisation plutôt que boost::serialization, par exemple.
[^] # Re: Objectivement...
Posté par barmic . Évalué à 2.
Gnome fait fasse à une crise ça peut arriver. Une direction donnée par le projet qui ne correspond plus à l'attente d'une partie de leur utilisateurs. C'est le principe d'un fork. Après les « forkeurs » ne se mettent pas d'accord pour sur la manière de forker et on se retrouve avec mate et cynamone, mais c'est à mon avis transitoire.
Pour Xorg elles n'ont pas trop le choix.
Je parlais surtout d'avoir un organisme de standard/normalisation. En l'état aucun des 3 ne fait le boulot. POSIX se met à jour très lentement et a plutôt tendance à être dans le mode inverse (elle normalise l'existant). Freedesktop est pas mal critiqué pour suivre plus Gnome que KDE, mais quoi qu'il en soit elle ne s'intéresse qu'au desktop (système d'init inclu évidement). C'est la LSB qui devrait faire ce travail mais elle ne le fait pas ou mal.
Tu ne les oblige pas. Mais entend que mainteneur tu peut dire que chez toi la biblio pour faire de la sérialisation c'est ultra_serialisation++ et que ce qui n'utilise pas celle-ci pourraient avoir des problèmes d'intégration. Si Debian et RedHat décident que toutes leur base logicielle sera dorénavant compilée en
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Objectivement...
Posté par Mali (site web personnel) . Évalué à 3.
Je me fais la même réflexion chaque fois que mes hauts parleurs émettent du son :p
# Les ports de FreeBSD
Posté par Anonyme . Évalué à 2.
C'est à dire ?
Les ports de FreeBSD sont en train de bouger petit à petit et dans ce modèle bordélique, il manque surtout des branches. Plus de travail, certes, mais on y réfléchit à deux fois avant de pondre une bouse.
[^] # Re: Les ports de FreeBSD
Posté par pmoret (site web personnel) . Évalué à 1.
Je faisait référence au constat de l'auteur:
Traduit (approximativement):
La modularité et la réutilisation de code sont, bien sûr, une bonne chose. Cependant, même dans des cas triviaux, le dogme de la réutilisation de code est totalement étranger dans le bazar: le logiciel inclu dans la collection de ports de FreeBSD contient au moins 1'342 algorithmes cryptographiques copiés et collés.
# Réussites historiques
Posté par arnaudus . Évalué à 10.
Je pense qu'on peut aller beaucoup plus loin que ça. Le modèle bazar est le seul modèle de développement qui a jamais démontré qu'il était possible de mettre en place, d'améliorer, et de complexifier un système sans aucune régression bloquante pendant 3 milliards d'années. À côté de ça, quelles sont les réussites d'un système cathédrale? Oui, bon, OK, les cathédrales. Les constitutions démocratiques les plus anciennes ont à peine plus de 2 siècles, et de toutes manières on voit bien que les systèmes juridiques se développent selon le modèle du bazar. Il semble que le fonctionnement de type cathédral soit limité à des projets de taille réduite, et surtout au développement limité dans le temps (une cathédrale est finie, on n'y touche plus). Dès qu'il faut maintenir l'objet, le faire évoluer, le complexifier, le rendre robuste à un environnement imprévisible, le développement cathédrale ne peut tout simplement plus tenir la route—et plus on s'approche du point de rupture, plus il faut d'énergie pour continuer à faire progresser le bouzin.
[^] # Re: Réussites historiques
Posté par barmic . Évalué à 2.
Tu considère l'ensemble de la vie comme un développement unique ?
La seule chose importante dans ton exemple c'est que le bazar permet le darwinisme, mais personnellement je ne suis pas convaincu que le monde du génie informatique soit divisé en 2 et je ne suis pas non plus convaincu que le bazar soit le seul qui permet le darwinisme.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Réussites historiques
Posté par arnaudus . Évalué à 3.
Bah c'est un soft unique, avec des millions de forks et de projets qui disparaissent. Mais c'est le même logiciel depuis le début.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.