Open versus closed sources

Posté par  . Modéré par Nÿco.
Étiquettes :
0
1
juil.
2003
Communauté
Ca y est! Après la découverte de l'ADN, la démonstration du théorème de Fermat..., une nouvelle énigme scientifique vient d'être résolue. Une équipe de chercheurs anglais de l'université d'Oxford vient de montrer que le modèle "code source ouvert" est plus avantageux (à plusieurs égards) que le modèle "code source fermé".

Merci la science. Une équipe de chercheur anglais de l'université d'Oxford (Damien Challet et Yann Le Du) a modélisé l'étape de "debugging" d'un code source ouvert et d'un code source fermé.
Le flux d'information plus important dans le cas d'un code ouvert, rend ce modèle plus efficace en terme de réactivité. Autre point d'importance, la probabilté d'avoir un produit sans bug est non nulle, même si aucun des développeurs ne sait comment éliminer un bug donné.

Aller plus loin

  • # Re: Open versus closed sources

    Posté par  . Évalué à 10.

    Le terme "scientifiquement prouvé" à toujours eu un impact important sur les gens. Ca fait un peu dentifrice, mais l'essentiel c'est que les mentalités changent.

    • [^] # Re: Open versus closed sources

      Posté par  . Évalué à 1.

      Surtout que "Nature" est un géant dans le domaine des mags de science.

      Là on peut être _certains_ de l'impact positif de cette action.

      Merci les gars.

      • [^] # Re: Open versus closed sources

        Posté par  (site web personnel) . Évalué à 2.

        Ce n'est qu'une brève sur Nature.com, je ne sais pas si ce sera dans l'édition papier et, en ce cas-même, ça n'aura pas l'impact de la publication complète dans Nature.

      • [^] # Re: Open versus closed sources

        Posté par  . Évalué à -2.

        Nature fait autant référence que Science & Vie ou Science & Avenir. Ce sont souvent des articles pasassez sérieux pour paraitre dans des publications scientifiques de haut niveau. En outre, l'article n'a rien de vraiment probant à proposer, mis à part un modèle qui a été maintes fois refait dans les forums de LinuxFR (et d'ailleurs): le bug report est plus efficace en open source. Rien de révolutionnaire (ce qui ne remet pas en question l'intérêt de la news).

        • [^] # Re: Open versus closed sources

          Posté par  . Évalué à 3.

          Euh... j'espere que c du second degre ou alors tu ne connais pas du tout le domaine. Nature est LA reference mondiale avec Science en matiere de publications scientifiques. Regarde les facteurs d'impact des journaux scientifiques.

          Par curiosite, qu'elles sont ces publications scientifiques de haut niveau auxquelles tu fais reference ? J'espere que c pas E=M6 :)

    • [^] # Re: Open versus closed sources

      Posté par  . Évalué à 10.

      A part que ici, la news est abusivement trompeuse : ce n'est ni scientifiquement prouvé et c'est encore moins "une nouvelle énigme scientifique [qui] vient d'être résolue".
      En effet il s'agit juste d'un modèle mathématique, qui PEUT s'avérer exact, mais qui n'est pas la vérité absolue.
      Pour faire une comparaison, c'est un peu comme les études scientifiques sur les téléphones portables : suivant les paramètres pris en compte (suivant aussi les commanditaires de l'étude) on considère qu'il est dangeureux, ou qu'il ne l'est pas.

      Dans 10 ou 20 ans, ayant plus d'information, plus de reflexion, et plus de temps, les études seront probablement plus fiable aussi.
      D'ici la, on ne peut faire que des supputations ...

      Affirmer que cette études est comparable à la découverte de l'ADM ou la démonstration du théorème de Fermat, c'est catastrophique, car dans ces 2 cas, il s'agit de la découverte d'éléments existant (l'ADN existait avant sa découverte, le théorème de Fermat est une propriété mathématique).
      Ici, on oppose 2 systèmes. C'est comme dire le capitalisme c'est mieux que le communisme. C'est très simplifié, car il n'existe pas une seule forme de capitalisme, et il n'existe pas non plus une seule forme de communisme. Alors c'est vrai que jusqu'a présent, le système capitaliste s'est avéré plus efficace, mais toutes les variantes n'ont pas été exploré, et bien malin celui qui pourra dire si cela sera toujours vrai dans 100 ans.
      Il en va de même avec les systèmes open et closed source : jusqu'à présent, l'open source à un meilleur modèle de développement, mais rien ne dit que ce sera vrai dans 100 ans.

      Pour conclure, j'en appelle a la sagesse des lecteurs/rédacteurs/modérateurs : ici la rédaction de la news est une opération de communication / désinformation.
      Si microsoft faisait demain une étude avec d'autres paramètres pondérés différemments, ils pourraient très bien arriver à la conclusion inverse. Ce ne serai pas forcément une fausse étude, mais une étude différente proposant un modèle différent. Seul l'avenir serait capable de donner raison à un des 2 modèle, voire ni l'un, ni l'autre.
      Par contre, sur linuxfr, beaucoup de monde crierait au mensonge, ce qui n'est pas mieux que d'imposer l'étude présenté comme la vérité ...

      • [^] # Re: Open versus closed sources

        Posté par  . Évalué à -3.

        Tout à fait d'accord avec ton post.
        C'est un article de recherche. Il propose un modèle, qui, comme tout modèle scientifique, n'est valable que jusqu'à ce qu'on ait prouvé quil est faux.

        Cordialement,

        • [^] # Re: Open versus closed sources

          Posté par  . Évalué à 3.

          C'est un article de recherche. Il propose un modèle, qui, comme tout modèle scientifique, n'est valable que jusqu'à ce qu'on ait prouvé quil est faux. Non, désolé, c'est au tenant du modèle de prouver qu'il est juste ou vraisemblable, pas aux détracteurs de prouver qu'il est faux. En science à l'inverse de la pensée dogmatique, religieuse ou sectaire, la charge de la preuve incombe à celui qui propose une théorie.

      • [^] # reprogrammons la programmation

        Posté par  . Évalué à 2.

        > il s'agit juste d'un modèle mathématique, qui PEUT s'avérer exact, mais qui n'est pas la vérité absolue.

        Certains ne prennent pas toutes ces précautions encombrantes.

        > Si microsoft faisait demain une étude avec d'autres paramètres pondérés différemments, ils pourraient très bien arriver à la conclusion inverse.

        Chacune de ces approches impose une nouvelle catégorie de logiciels. Étant donné que le nombre et la complexité des machines augmentent, le problème de l'administration dépasse celui relatif à la disponibilité et à l'expérience des personnes formées.

        Le résultat est que les membres de la communauté des programmeurs vont devoir se pencher sur la création de meilleures méthodes pour développer des programmes. Les personnes qui réfléchissent sur la façon de gérer les ordinateurs vont devoir penser à la façon de créer des ordinateurs capables de s'organiser et de se gérer automatiquement.

        Nous devons continuer à améliorer les outils de programmation puisque         la programmation telle qu'elle existe aujourd'hui est trop sujette aux erreurs.

        Craig Mundie, Octobre 2002, Microsoft winword.exe
        http://216.239.37.100/search?q=cache:OZQb7t3EI5IJ:www.microsoft.com(...)

        • [^] # Re: reprogrammons la programmation

          Posté par  . Évalué à 3.

          Plusieurs points meritent une clarification:

          Il s'agit effectivement d'une breve de Nature, l'article ne sera pas publie dans
          Nature. L'article a ete soumis a une revue du groupe Elsevier. On ne sait donc
          meme pas si il sera publie ou non. Le chemin peut etre *tres* long entre la
          soumission du papier, son acceptation (sous reserve de corrections) et son edition.
          Concernant l'aspect mathematique, il ne s'agit que d'un modele. Et celui-ci
          ne concerne *que* la partie "correction des bugs". Il n'est pas inimaginable
          qu'une autre equipe puisse proposer un modele different.

      • [^] # Re: Open versus closed sources

        Posté par  . Évalué à 3.

        Sauf que la rédaction de la news était surtout humoristique, je pense, mais bon ...

      • [^] # Re: Open versus closed sources

        Posté par  (site web personnel) . Évalué à 2.

        Ce qui est scientifiquement prouve l'est toujours jusqu'a preuve du contraire... C'est le propre de toute verite scientifique, elle n'est jamais definitive, et c'est d'ailleurs pour cela que les verites scientifiques sont demontrables... Parce qu'elles decoulent, parfois apres une longue chaine, d'hypotheses et de l'application de regles de raisonnement a ces hypotheses.
        Les hypotheses de depart sont des axiomes consideres comme verifies dans une certaine mesure, et les verites qui en ont ete tirees sont toutes et entierement soumises a la verification des axiomes initiaux... Le scientifique honnete garde a l'esprit et rappelle a chacun que les verites qu'il a decouvertes sont soumises a la verification des ces axiomes...

        Dans 100 ans, nous decouvrirons peut-etre une situation ou la vitesses de la lumiere dans le vide n'est pas un maximum indepassable... Tout comme, Einstein avait demontre les limites de la mecanique Newtonienne...

        Par consequent, dans le cadre des hypotheses formulees par cette equipe de chercheurs, il est scientifiquement prouve que les logiciels au code source ouvert sont plus rapidement et mieux debogues que les logiciels fermes.

        • [^] # Re: Open versus closed sources

          Posté par  . Évalué à 1.

          Ce qui est scientifiquement prouve l'est toujours jusqu'a preuve du contraire Il n'y a rien de prouvé dans cet article. Le modèle proposé tient de la spéculation la plus idiote. Le minimum quand on propose un modèle est d'aligner des résultats expérimentaux prouvant la vraisemblance du modèle. Mais là, rien de cela. Du pipo intégral.

          • [^] # Re: Open versus closed sources

            Posté par  . Évalué à 1.

            Je crois que tu n'as pas eu la curiosite de suivre tout les liens... Le modele est confronte a des donnees experimentales qui sont le developpement du noyau entre 2.5.5 et 2.5.69, et de mozilla.

        • [^] # Re: Open versus closed sources

          Posté par  . Évalué à 1.

          L'ADN ou le théorème de fermat existent. C'est "scientifiquement prouvé", c'ets à dire que l'ADN a effectivement été observé, et que le théorème de fermat à mathématiquement été démontré. Il est donc vrai, sinon il ne serait pas théorème de Fermat, mais un postulat de Fermat. Le probleme, c'est que contrairement a ce que tu dis le modèle en question n'est pas scientifiquement prouvé, ni démontrable d'ailleurs. La mécanique newtonienne, la relativité restreinte, la relativité générale, la mécanique quantique ne sont pas scientifiquement prouvée non plus contrairement à ce que croit le grand public. Il s'agit de modèles, c'est à dire d'éléments qui s'approchent le plus possible de la réalité, mais sans jamais l'atteindre. Ils servent à décrire l'élément auxquels ils s'appliquent, et sont ainsi très pratique. Mais tout les scientifiques savent qu'il ne s'agit que de descriptions de la réalité, et non la réalité. Quand il s'agit de la relativité (par exemple), suffisamment de temps est passé, et suffisamment de scientifiques l'ont étudiée pour savoir qu'il s'agit d'un modèle assez proche de la réalité, qui permet de décrire le monde pas trop mal. Pour l'étude sus-nommée, elle n'a aucun de ces 2 éléments déterminant pour savoir si elle resistera à l'épreuve du temps. Par ailleurs, la relativité générale s'appuie sur la relativité restreinte, qui s'appuie sur la mécanique newtonienne, ... Quid de cette étude ? Avant de dire des absurdités, merci de reflechir un petit peu, et de garder son sens critique, indispensable a tout individu qui se veut scientifique ...

          • [^] # Re: Open versus closed sources

            Posté par  (site web personnel) . Évalué à 1.

            Bonjour, Je crois que nous ne nous sommes pas compris, du moins je n'ai pas ete assez clair... Donc, je reformule. Epistemologiquement, les scientifiques ne traitent que de modeles. Un scientifique observe un phenomene dans la nature, il le reproduit en laboratoire, lui applique des raisonnements logiques et avec du travail et parfois de la chance il peut construire un modele... Et ce modele scientifique reste prouve (vrai) jusqu'a ce qu'on puisse prouver son contraire, c'est a dire dans les limites fixees par les hypotheses et par l'experimentation. Voila a mon sens, ce que signifie la locution "scientifiquement prouve" Une loi dont pour laquelle on ne disposerait pas de moyen logique de prouver son contraire c'est un dogme. Par exemple, "Dieu existe, il est unique, omniscient, omnipresent et omnipotent" est un dogme dont decoulent des principes dogmatiques: le tronc commun des 3 principales religions. En revanche, "par un point donne il ne passe qu'une seule et unique droite parallele a une droite donnee" est un axiome scientifique dont on peut, moyennant des raisonnements logiques, tirer des lois scientifiques: les lois du modele geometrique euclidien, ces lois restent scientifiquement vraies tant que l'axiome d'Euclide est (tenu pour) vrai, lorsque cela n'est plus le cas ce sont les lois d'un autre modele geometrique qui deviennent vraies... La mecanique newtonienne et la mecanique quantiques sont des modeles scientifiquement prouves, c'est a dire qu'ils ont ete construits a partir de faits de laboratoires et de raisonnements logiques, et que par essence ils ont des limites au-dela desquelles ils ne sont plus applicables. Mon intervention visait a dire, que ce que ces chercheurs ont prouve, c'est a dire le modele qu'ils ont bati, n'est vrai que dans le contexte de leurs hypotheses.

            • [^] # Re: Open versus closed sources

              Posté par  . Évalué à 1.

              Je traduis les deux premières phrases de l'article. L'importance de la fiabilité du logiciel est évidente de nos jours, car les ordinateurs contrôlent une part croissante de notre vie. Dans le même temps, la complexité du logiciel est toujours croissante. Ca tient du dogme. Je retrouve ce même dogme dans le discours de Craig Mundie, dans la parano des politiques vis à vis des nouvelles technologies. Peu de faits vient appuyer ce dogme. Ca fait un bail qu'on réfléchit au sujet. Les logiciels sont désinstallables. On peut mettre les logiciels en concurrence. On sait faire des micros distributions. On programme par objet, par composants. On répartis les taches. Les utilisateurs se foutent profondément de la fiabilité. Ils utilisent en masse windows 98, Outlook, Sendmail, Bind, wu-ftpd, kazaa et PHPNuke. Les utilisateurs veulent avant tout communiquer. Les ordinateurs ne contrôlent rien. Si les auteurs étaient partis sur cette piste, leur étude n'aurait pas pris en compte Linux et Mozilla mais les logiciels que je viens de citer. Les conclusions s'en seraient quand même ressenties, je présume.

          • [^] # Re: Open versus closed sources

            Posté par  . Évalué à 1.

            "L'ADN ou le théorème de fermat existent. C'est scientifiquement prouvé"... cette partie est de moi, j'en porte l'entiere responsabilite. Mais le decalage entre l'importance de l'ADN pour la biologie moleculaire, du theoreme de Fermat pour les mathematiciens et l'etude de la dynamique de correction des bugs entre open et closed source ne laisse a mon avis aucun doute sur la nature (un peu) ironique du propos... J'espere qu'a part Djrom, d'autres s'en etaient apercus... "Avant de dire des absurdités, merci de reflechir un petit peu, et de garder son sens critique, indispensable a tout individu qui se veut scientifique ..." Je crois que tu connais deja cette phrase :-))) Par ailleurs, tu as manque la mise au point que j'ai postee la veille. C'est etonnant le pouvoir trollesque de cette petite news...

  • # Re: Open versus closed sources

    Posté par  (site web personnel) . Évalué à 1.

    Qui l'eu cru ?.. C'est extraordinaire !..

  • # Re: Open versus closed sources

    Posté par  . Évalué à 2.

    Une équipe de chercheur anglais de l'université d'Oxford (Damien Challet et Yann Le Du)

    s/anglais/français
    ?

  • # Re: Open versus closed sources

    Posté par  . Évalué à -10.

    Comme quoi avec un bac +10 on n'est pas plus con que la moyenne les évidences nous sautent aussi a la figure.

    J'espere juste qu'il ne leur a pas fallut 10 ans car sinon on comprend mieux le deficite des USA !!

  • # Re: Open versus closed sources

    Posté par  . Évalué à 8.

    Afin d'éviter justement les commentaires qui prennent pour argent comptant la chose, précisons que l'article ne "montre" rien du tout. Il s'agit d'un article présentant un modèle de mécanique statistique de la dynamique des bugs logiciels. L'une des conclusions du modèle est que le système de type "bazaar" (KDE par exemple) est plus efficace et rapide à la correction de bug que les systèmes de type "cathedral" (logiciels propriétaires, Gnome).
    Cela n'implique bien sur pas que ce modèle est réellement vailde : seul l'avenir le dira. Il précise aussi que certaines présomptions faites pour établir la base du modèle sont inexactes et demaderont plus de recherches pour affiner ledit modèle. Mais ses conclusions sont intéressantes néanmoins.

    Cordialement,

    • [^] # Re: Open versus closed sources

      Posté par  . Évalué à 6.

      Mmm, à la réflexion, Xfree est un meilleur exemple que Gnome de projet OS de type Cathedral.

      Cordialement,

    • [^] # Re: Open versus closed sources

      Posté par  (site web personnel) . Évalué à 5.

      Je pense qu'il y a un probleme dans la definition de "Cathedral" et de "Bazaar", car je ne comprends pas l'association KDE "Bazaar" et Gnome "Cathedral". Quelqu'un pour m'expliquer car je pensais que c'etait le contraire.

      • [^] # Re: Open versus closed sources

        Posté par  . Évalué à 4.

        voici ce que j'ai trouvé sur le net :

        Le style de développement de Linus Torvalds - distribuez vite et souvent, déléguez tout ce que vous pouvez déléguer, soyez ouvert jusqu'à la promiscuité - est venu comme une surprise. À l'opposé de la construction de cathédrales, silencieuse et pleine de vénération, la communauté Linux paraissait plutôt ressembler à un bazar, grouillant de rituels et d'approches différentes (très justement symbolisé par les sites d'archives de Linux, qui acceptaient des contributions de n'importe qui) à partir duquel un système stable et cohérent ne pourrait apparemment émerger que par une succession de miracles.

        • [^] # Re: Open versus closed sources

          Posté par  (site web personnel) . Évalué à 4.

          Mon propos n'est pas sur la definition de "Cathedral" et de "Bazaar", mais plutot sur cette association malencontreuse avec Gnome et KDE.

          je pense que ces deux projets sont tout deux du cote bazaar, avec un cote nebuleux plus pousse pour Gnome.

          • [^] # Re: Open versus closed sources

            Posté par  . Évalué à 3.

            Comme dans un post additif, effectivement, Gnome n'était pas un bon exemple. Xfree me parait mieux : conseil décidant des orientations de développements, une certaine opacité dans les prises de décisions, tout le monde ne peut pas poster un patch, etc.

            Cordialement,

        • [^] # Re: Open versus closed sources

          Posté par  . Évalué à 0.

          Mouais, Linus Torvalds délegue pas tant que ça (preuve en est, il utilise pas CVS). L'exemple semble très discutable.

          • [^] # Re: Open versus closed sources

            Posté par  (site web personnel) . Évalué à 3.

            il n'y a pas que CVS dans la vie.

            Linus utilise BitKeeper pour la gestion du source du noyau.

            • [^] # Re: Open versus closed sources

              Posté par  . Évalué à 10.

              A table !! :o)
              Steak de troll pour tout le monde !

              -1

            • [^] # Re: Open versus closed sources

              Posté par  . Évalué à 1.

              « il n'y a pas que CVS dans la vie.
              Linus utilise BitKeeper pour la gestion du source du noyau. »


              1) Tu as oublié de préciser depuis combien de temps c'est le cas. C'est récent.
              2) Ce logiciel a été conçu pour permettre à Linus de continuer à gérer le noyau comme il l'a toujours fait.
              [3) On peut noter au passage que ce logiciel est tout sauf libre.]

              Ceci implique que :
              1) Le fait que Linus n'a pas voulu utiliser CVS montre qu'il n'est pas inspiré par un développement de type bazar.
              2) Le fait que BitKeeper existe ne change rien à cela.


              En bref : ta réponse est hors-sujet puisque mon propos était « Linus Torvalds délegue pas tant que ça » et que ta réponse n'apporte aucun élément suspectible d'infirmer cette remarquer.

              • [^] # Re: Open versus closed sources

                Posté par  . Évalué à 1.

                1) Le fait que Linus n'a pas voulu utiliser CVS montre qu'il n'est pas inspiré par un développement de type bazar.

                Linus a ete le premier a accepter de nombreux patchs a droite/a gauche, et maintenant son boulot consiste principalement a decider quels patchs vont dans la branche de developpement et quels patchs restent dehors. Les softs du GNU par exemple etaient fait par un groupe beaucoup plus ferme de developpeurs.

                Apres il y a d'autres projets qui ont repris un mode de developpement ouvert, peut-etre plus, n'empeche que Linus a beaucoup innove en matiere de gestion de projet.

                • [^] # Re: Open versus closed sources

                  Posté par  (site web personnel, Mastodon) . Évalué à 0.

                  Linus a ete le premier a accepter de nombreux patchs a droite/a gauche, et maintenant son boulot consiste principalement a decider quels patchs vont dans la branche de developpement et quels patchs restent dehors.
                  Donc, c'est du développement cathédrale avec la particularité que le conseil décisionnel est réduit à 1.

                  • [^] # Pas si simple

                    Posté par  . Évalué à 2.

                    > Donc, c'est du développement cathédrale avec la
                    > particularité que le conseil décisionnel est réduit à 1.

                    Pas tout à fait. Il a des lieutenants par lesquels tu es
                    censé passer si tu veux que ton patch ait un jour une
                    chance d'être intégré. Donc c'est du développement
                    cathédrale, version pyramide.

        • [^] # Re: Open versus closed sources

          Posté par  (site web personnel) . Évalué à 2.

          tu veux dire un peu comme les 10 milliards de singes qui tapent à la machine ??

          oui oui, jmenvé...

    • [^] # Re: Open versus closed sources

      Posté par  . Évalué à 3.

      Au contraire, je trouve que leurs hypothèses sont très intéressantes, étant donné qu'elles sont assez restrictives. Ils considèrent notamment que les bugs-reports sont très peu descriptifs (genre juste "y'a ça qui marche pas") et qu'il y a le même nombre de programmeurs dans les projets cathédral et bazaar, ce qui, dans le cas du logiciel proprio, est souvent faux.

    • [^] # Re: Open versus closed sources

      Posté par  . Évalué à 1.

      Le coup sur gnome et kde c'et vraiment très moyen !

      Jamais l'article ne dit cela, sur quoi tu te bases concretement pour affirmer des choses pareil ?
      Etant donné le nombre de contributeurs de gnome (plus nombreux que kde quand on prend toutes les applications GTK, et meme sans p-e ?), c'est un peu osé, non ?

      • [^] # Re: Open versus closed sources

        Posté par  . Évalué à 1.

        L'aspect cathédrale ou bazar ne vient pas du nombre de developpeurs mais du système de décision.

        Pour construire une cathédrale, il faut énormement de monde... Tout comme dans un bazar. Par contre, pour construire une cathédrale, il faut une grosse coordination avec un centre de décision précis.

        Vu comme ça, le noyau Linux, le logiciel Emacs, sont de type "cathedrales"... Et pourtant ça marche bien. Je doute que KDE soit un bazar...
        Quant à GNOME, je pense que la question beaucoup plus vicieuse puisque GNOME à des organismes de décisions qui semblent uniquement là pour cautionner les décisions prises par les personnes les plus impliquées : une cathédrale qui se présente un peu comme un bazar.

        Ceci dit, dans tout ceci, je pense qu'il y a un équilibre. Exemple : Debian où chaque développeur à pas mal de liberté tout en devant respecter une charte précise... Ni tout à fait un bazar ni tout à fait une cathédrale (tel qu'on comprend le mot ici - je pense personnellement que cette compréhension de la construction d'une cathédrale est sur un plan historique assez douteuse).

        • [^] # Re: Open versus closed sources

          Posté par  (site web personnel) . Évalué à 1.

          Si je me souviens bien, Emacs est justement l'exemple d'un logiciel "cathedrale" pris par ESR au debut de son papier.

        • [^] # Re: Open versus closed sources

          Posté par  . Évalué à 2.

          Je ne suis pas d'accord sur les definitions.

          pour moi cathédrale est utilisé pour designé un logiciel programmé par une équipe restreinte (une dizaine par exemple) ce qui est le cas de certains logiciels libres et de beaucoup (tous?) de logiciels proprietaires.

          les logiciels 'bazar' sont ceux qui acceptent de nombreux contributeurs car les sources sont reguliairement mise à jour en ligne, on peut donc voir les evolutions et donc contribuer.

          exemples cathedrale : xfree, certains logiciels GNU, logiciels proprietaires
          exemples bazar : linux, gnome, kde
          exemple je sais pas trop : java (tres forte ecoute des demandes des utilisateurs)

          • [^] # Re: Open versus closed sources

            Posté par  . Évalué à 1.

            « pour moi cathédrale est utilisé pour designé un logiciel programmé par une équipe restreinte (une dizaine par exemple) ce qui est le cas de certains logiciels libres et de beaucoup (tous?) de logiciels proprietaires. » Cette définition ne me semble pas du tout pertinente : as-tu idée du nombre de corps de métiers et de personnes qui ont du contribuer conjointement pour batir des cathédrales ? Autant dire d'entrée de jeu qu'on est loin d'équipes restreintes (entre les tailleurs de pierres, maçons, peintres, vitriers, ecclesiastiques etc...). « les logiciels 'bazar' sont ceux qui acceptent de nombreux contributeurs car les sources sont reguliairement mise à jour en ligne, on peut donc voir les evolutions et donc contribuer. » Ah ? « exemples cathedrale : xfree, certains logiciels GNU, logiciels proprietaires exemples bazar : linux, gnome, kde » Si l'on suit ta définition pour cathedrale, Emacs ne rentre pas dans cette catégorie (essaye un peu de deviner le nombre de contributeurs à ce projet !)... mais tout à fait dans la catégorie bazar (CVS dispo à n'importe quelle heure). Mais les définitions que tu utilisent ne permettent pas de désigner quoi que ce soit précisement. - ta définition de cathédrale designe tout les projets développé par un nombre restreint de personne (en quoi est-ce un mode de développement ??) - ta définition de bazar désigne tout les projets libres - y compris TOUT les projets GNU, tous développés sur un CVS en accès (lecture) libre. Il faut donc revoir les termes. Voir les définitions proposées dans les autres messages. exemples bazar : linux, gnome, kde

      • [^] # Re: Open versus closed sources

        Posté par  . Évalué à 2.

        > Etant donné le nombre de contributeurs de gnome (plus nombreux que kde quand on prend toutes les applications GTK, et meme sans p-e ?), c'est un peu osé, non ?

        Je vois mal comment on peut considérer que les développeurs développant des applications GTK qui n'utilisent pas le framework GNOME sont des développeurs GNOME... Sinon, tu as des chiffres sur ce que tu avances, concernant le nombre de développeurs GNOME, et le nombre de développeurs KDE?

        • [^] # Re: Open versus closed sources

          Posté par  . Évalué à 1.

          Il y avait un point d'interrogation à la fin de ma phrase, ceci :'?' donc je n'affirme pas grand chose sur les developpeurs GNOME, par contre il est evident qu'il y a bien plus de developpeurs GTK que QT, je crois que je n'ai pas besoin de me justifier sur ce point.

          Quand à la polémique GNOME != GTK, je suis bien d'accord, c pour cela que j'ai differencié les 2.

    • [^] # Re: Open versus closed sources

      Posté par  (site web personnel) . Évalué à 4.

      Il y a un contresens facheux dans l'article original, et plus encore dans ton commentaire.

      La cathédrale, dans les écrits de ESR, ne désigne pas le logiciel propriétaire, mais le développement de type BSD (ou Slackware): une petit équipe gardant un étroit controle sur l'ensemble du processus de développement, depuis le noyau jusqu'à la pochette des CD finaux. On ne rentre dans cette équipe que par co-optation, en montrant patte blanche.

      Au contraire, le bazar, c'est le développement de type Linux. Une joyeuse équipe qui s'étripe joyeusement autour du kernel, d'autres qui font les logiciels qui vont autour, et enfin les distributions qui font l'emballage. Chacun peut faire quelque chose dans son coin, sans rien demander à personne.

      • [^] # Re: Open versus closed sources

        Posté par  . Évalué à 0.

        Il n'y a pas de contresens dans l'article qui prend la définition que tu donnes. Par contre l'exemple que j'avais pris de Gnome n'était pas bon. Je l'ai rectifié en proposant XFree dans un commentaire suivant (qui est la première réponse à mon propre post) mais apparemment aucun de ceux qui m'ont répondu, à commencer par toi, ne l'ont lu.

        Cordialement,

        • [^] # Re: Open versus closed sources

          Posté par  (site web personnel) . Évalué à 0.

          >Il n'y a pas de contresens dans l'article qui prend la définition que tu donnes.
          Si, il parle de bazar pour qualified le logiciel propriétaire, et toi aussi. Il est là le contresens. Pour Gnome vs KDE, ce n'est pas un contresens, c'est une affirmation infondée.

          • [^] # Re: Open versus closed sources

            Posté par  . Évalué à 1.

            Tu devrais vraiment relire l'article en détail :

            "cathedral open-source projects and closed-source projects have the same dynamics in our model, thus we shall refer to them as closed source, and to baazar projects as open source."

            Donc j'ai raison et tu as tort. :-)
            D'autre part, comme je l'ai déjà posté 4 fois, l'exemple de Gnome était un mauvais choix. Je l'ai déjà reconnu. Pourquoi remettre cela sur la table une fois de plus?

            Cordialement,

            • [^] # Re: Open versus closed sources

              Posté par  . Évalué à 1.

              « cathedral open-source projects and closed-source projects have the same dynamics in our model » Il y a bien le contresens que souligne Guillaume. Ca me semble parfaitement idiot... Je vais radoter en rappellant que le logiciel linux et GNU emacs sont très clairement construits comme des cathédrales (réunissant de nombreuses personnes mais dirigés par des groupes de personnes restreints, clairement sous la tutelle de l'initiateur du projet)... Ce sont deux exemples de logiciels libres qu'on peut sans mentir dire de bonne qualité... Cette association libre-bazar/proprietaire-cathédrale, comme le fait remarquer Guillaume, ne tient pas la route. Et pourtant, c'est un postulat de départ de ces chercheurs... problème.

              • [^] # Re: Open versus closed sources

                Posté par  . Évalué à 1.

                Ils n'opposent pas "libre" et "propriétaire" dans leur article. Ils regroupent les modes de développement qui sont proches, càd "bazaar" opposé à "cathédrale". La catégorie "cathédrale" peut regrouper des logiciels libres à développement relativement fermé comme xfree et des logiciels proprio, étant donné que les méthodes de développement sont proches. Eric Raymond décrit clairement bien ça, avec des propositions assez efficaces pour différencier les deux. Les auteurs de l'article partent sur cette base.

      • [^] # Re: Open versus closed sources

        Posté par  . Évalué à 2.

        La tu ne parles pas de Linux. Autant je trouve que Stallman abuse parfois avec son GNU/Linux, autant si tu utilisait ce terme tu ne ferait pas cette confusion.

        Linux c'est le noyau, donc le modele de bazar c'est ici pour "un OS base sur le noyau Linux".

        • [^] # Re: Open versus closed sources

          Posté par  . Évalué à 0.

          Richard Stallman ne fait pas la promotion du terme GNU/Linux pour une autre raison que la clarté, la cohérence. En d'autres termes, nous avons ici un brillant exemple démontrant l'intérêt d'utiliser des termes précis.

    • [^] # Re: Open versus closed sources

      Posté par  . Évalué à 1.

      Comment peut-on juger de la validite d'un modele?
      A mon sens, on ne peut pas "demontrer" (stricto-sensus) la validite d'un modele.
      La seule possibilite est de le confronter a des donnees reelles (figure 7 et figure 8).
      A ce petit jeu, on ne peut optenir que des "indications". Toutefois, pour les exemples
      choisis par les auteurs, ca semble coller (ca serait dommage).
      Je suis donc d'accord, le travail est "interessant".

  • # Re: Open versus closed sources

    Posté par  . Évalué à 0.

    Ca zalor, je m'amusait à prendre l'ADN (code ouvert modifiable et copiable à volonté) pour expliquer l'opensource et ses bienfaits (imaginez l'évolution de la nature avec de l'ADN proprio ! :-p), j'était loin de penser que yavé des chercheur qui théorisaitent ça avec sérieux ! Je suis bleuffé !

    • [^] # Re: Open versus closed sources

      Posté par  . Évalué à 4.

      Avec de l'ADN proprio, on auraient un parc plein de dinosaures et de milliardaires qui se font bouffer par les premiers ....
      Hein... quoi ? ... éteindre la télé ? naaann!!! :-)

      (-1 parceque ca fait pas avancer le débat)

    • [^] # Re: Open versus closed sources

      Posté par  (site web personnel) . Évalué à 1.

      Il n'est pas fait mention de l'ADN dans cette étude.
      N'aurais-tu pas lu la brève en diagonale ?

  • # Lassitude

    Posté par  . Évalué à 0.

    Evidemment, quand paraît un article ridicule qui prétend modéliser des mécanismes sociaux et économiques par quelques équations simplistes, il se retrouve en une de Linuxfr (si l'article avait démontré l'inverse, à savoir que le closed source est plus efficace que l'open source, on l'aurait à juste titre descendu en flèche).

    Lamentable.

    • [^] # Re: Lassitude

      Posté par  (site web personnel) . Évalué à 3.

      Ouais, j'ai survolé l'article. En gros, il dit que si les gens qui font des rapports de bugs travaillent sur la dernière version, les rapports de bugs sont plus pertinents.

      Rien sur le modèle économique il me semble, or, c'est quand même bien la question intéressante : OK, à moyens équivalents, un logiciel open source est meilleur, mais comment trouver des moyens équivalents avec une licence libre, ca, c'est une question plus difficile ...

    • [^] # Re: Lassitude

      Posté par  (site web personnel) . Évalué à 4.

      En plus, des 2 arguments habituels, ils en rajoutent 2 autres.

      En génral, on dis que les programmeurs opensources font 2x plus gaffe d'être propre car il serotn beaucoup relu, ce qui n'est pas ou peu le cas en proprio. Ensuite, la notion de temps, un bon programmeur, s'il n'a pas le temps va torcher. (on peut rajouter que le debugging se fait très bien en //, et que finalement, il y a bien plus de beta testeur dans le ll que dans le proprio)

      Eux, il en rajoute 2. La première est que cacher des informations coutent de l'énergie et empèche que tous les intervenants est facilement et directement toutes les informations pertinentes.

      La 2ième est que la méthode open source permet des release très rapide qui permet d'avoir une boucle de feed back importante et rapide alors que le logiciel proprio à en général une boucle très lente.

      "La première sécurité est la liberté"

    • [^] # Re: Lassitude

      Posté par  . Évalué à 1.

      Je n'ai pas lu l'article. Quels éléments fondent ta conclusion ?


      Ceci dit, cette article parle du libre et à ce titre est interessant à être discuté, qu'il soit médiocre ou fabuleux, non ?

      • [^] # Re: Lassitude

        Posté par  . Évalué à 2.

        Guillaume B (plus haut) a parfaitement répondu à cet article, et je partage entièrement son opinion (que j'avais la flemme de formuler, tellement ce genre d'article est à la fois caricatural et terriblement banal dans sa médiocrité). Quand on fait une modélisation, on prouve la vraisemblance de cette modélisation en s'appuyant sur des données expérimentales tangibles. Il n'y a rien de tel dans l'article, la thèse exposée semble surgir ex nihilo. C'est de la spéculation gratuite, un rideau de fumée pour cacher l'inexistence de résultats fiables et réutilisables.

    • [^] # Re: Lassitude

      Posté par  . Évalué à 1.

      Tu l'as lu ? Il ne modélise pas du tout des "mécanismes sociaux et économiques". Il formalise et compare des méthodes de développement, en les comparant sur la base d'une donnée clairement mesurable: la quantité de bugs présents dans un programme. Il ne tire aucune conclusion définitive genre "l'opensource, c'est mieux, ça coute moins cher, ça produit des logiciel de meilleure qualité", il étudie juste un modèle et en tire des conclusions. Après, à toi de voir dans quel mesure le modèle correspond à la réalité, et à toi d'ajuster les paramètres du modèles en fonction de critères économiques et sociaux. Mais ce n'est pas le but de leur travail.

      • [^] # Re: Lassitude

        Posté par  (Mastodon) . Évalué à 1.

        «sur la base d'une donnée clairement mesurable: la quantité de bugs présents dans un programme»

        Et comment je mesure clairement la quantité de bugs présente dans mon programme ? Ça m'intéresse :-)

        Bon je suppose que tu faisais référence aux bugs détectés, mais ça me semble un peu risquer de comparer des logiciels au code source privé et d'autres au code source ouvert à ce niveau là. Mais je n'ai pas (encore) lu l'article, si ça se trouve ça n'a rien à voir.

      • [^] # Re: Lassitude

        Posté par  . Évalué à 0.

        Le mode de développement du logiciel libre, comme n'importe quel processus de production non entièrement automatisé, est un mécanisme social et économique. en les comparant sur la base d'une donnée clairement mesurable: la quantité de bugs présents dans un programme Le problème est que cette donnée, bien que "clairement mesurable", n'est pas du tout mesurée dans l'article. Elle fait juste l'objet de suppositions totalement gratuites et non validées par des résultats expérimentaux. L'étude est donc totalement déconnectée de la réalité. à toi de voir dans quel mesure le modèle correspond à la réalité Non, justement, c'est eux qui prétendent bien que leur modèle colle à la réalité. Sinon le modèle n'aurait aucun intérêt.

        • [^] # Re: Lassitude

          Posté par  . Évalué à 1.

          Le mode de développement du logiciel libre, comme n'importe quel processus de production non entièrement automatisé, est un mécanisme social et économique. Oui, on est d'accord. Mais on peut aussi l'étudier sous ses composantes uniquement technique, non ? L'étude n'est pas déconnectée dans la réalité, ils comparent (as-tu lu la publication proposée en lien dans l'article ?) les résultats que leur modèle prévoit en terme de nombre de bugs corrigés avec ce qui s'est passé dans le cas de projets réels (linux et mozilla). Cela ne te semble pas suffisant ? Alors argumente et développe: pourquoi les exemples proposés ne te conviennent pas ? Non, justement, c'est eux qui prétendent bien que leur modèle colle à la réalité. Sinon le modèle n'aurait aucun intérêt. Ils ne *prétendent* rien du tout, ils proposent juste quelque chose, avec des exemples montrant que leur modèle semble bien coller à la réalité. C'est donc bien à toi de juger si leurs exemples te semblent suffisement nombreux et probants, en attendant d'éventuelles preuves/démonstrations flagrantes de l'incohérence/inefficience/inadéquation de ce modèle.

    • [^] # Re: Lassitude

      Posté par  . Évalué à -1.

      Lit l'article au lieu de dire des bêtises

  • # Re: Open versus closed sources

    Posté par  (site web personnel) . Évalué à 3.

    Je m'étonne du fait qu'il n'y ait aucune critique sur le modèle en lui-même : les auteurs expliquent rapidement que leur modèle est "simple" et repose sur beaucoup de présomptions, mais ils n'expliquent pas comment l'améliorer.

    De plus, je trouve que l'idée de comparer avec l'évolution du nombre de bugs dans linux est bonne mais trop simpliste. Je ne sais pas où les auteurs ont eu les stats du nombre de bugs dans linux (si on savais combien il y en a, il y a longtemps qu'on les aurait fixé...) et ils auraient dû comparer avec d'autres logiciels open-source (au moins une vingtaine). Ils ne valident pas non plus leur modèle pour la partie "closed-source" en comparant avec des logiciels type Windows(r).

    Enfin, il ne font aucunes distinction entre les bugs majeurs et mineurs : avoir un OS qui ne boote pas est quand même plus gênant qu'un OS qui affiche un message avec une faute d'orthographe...

    • [^] # Re: Open versus closed sources

      Posté par  . Évalué à 1.

      Bravo. Une critique constructive ie je partage.
      Les auteurs donnet tout de même une ou deux pistes sur les dévelopmments possibles à la fin mais la plupart des points que tu soulignes me paraissent justes.

      Cordialement,

    • [^] # Re: Open versus closed sources

      Posté par  . Évalué à 1.

      tout a fait d'accord !

      Dans l'article que j'ai lu : naviger dans : http://www.linux-france.org/article/these/cathedrale-bazar/cathedra(...)
      (encore un lien qui va se faire coupé)

      le type explique qu'il a fait son propre logiciel libre, et qu'il compare avec les logiciel propriétaire qu'il faisait avant

      extrait de http://www.linux-france.org/article/these/cathedrale-bazar/cathedra(...) :


      Le fait que ce style du bazar semblait fonctionner, et bien fonctionner, fut un choc supplémentaire. Alors que j'apprenais à m'y retrouver, je travaillais dur, non seulement sur des projets particuliers, mais encore à essayer de comprendre pourquoi le monde Linux, au lieu de se disloquer dans la confusion la plus totale, paraissait au contraire avancer à pas de géant, à une vitesse inimaginable pour les bâtisseurs de cathédrales.

      Vers le milieu de 1996, je pensais commencer à comprendre. Le hasard m'a donné un moyen incomparable de mettre ma théorie à l'épreuve, sous la forme d'un projet dont le code source est ouvert et que je pourrais consciemment faire évoluer dans le style du bazar. Ce que je fis -- et je rencontrai un franc succès.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.