Discussion :

[Hinault Romaric]

Le code open source égal ou meilleur que le code propriétaire
selon Coverity


Coverity, l’éditeur de solutions pour l’analyse statique du code source dans son dernier rapport révèle que le code source des applications open source est au même niveau, voire meilleur que le code des applications propriétaires.

Le projet « Coverity Scan » a débuté en 2006 en partenariat avec le département américain de la sécurité intérieure. L’étude examine l’intégrité et la qualité des logiciels open sources et propriétaires en utilisant la plateforme d’analyse statique Coverity. L’outil recherche des défauts dans le code tels que le déréférencement des pointeurs, la corruption de mémoire, les problèmes de flux de contrôle, les variables non initialisées, etc.

Le rapport de Coverity est basé sur l’analyse de plus de 37 millions de codes open source et de plus de 300 millions de codes propriétaires. C’est la première fois que le code propriétaire est pris en compte dans l’étude.

Suite à l’examen de 45 projets open sources majeurs ayant en moyenne chacun près de 820 000 lignes de code, l’éditeur a constaté une densité moyenne de défauts de 0,45 sur la base du nombre de défauts pour 1 000 lignes de code.

Tandis qu’un taux de défauts de 0,64 pour 1 000 lignes de code a été constaté pour les applications propriétaires. L’entreprise a examiné 41 projets propriétaires ayant en moyenne 7,55 millions de lignes de code.

Les projets open source Linux 2.6, PHP 5.3 et PostgreSQL ont été marqués comme ayant du code de bonne qualité par les chercheurs de Coverity, avec respectivement une densité de défauts de 0,62, 0,20, 0,21. Linux 2.6 avec ses 7 millions de lignes de code présente une densité de défauts de code presque identique à celle de ses homologues propriétaires.

Coverity conclut de ce fait que l’hypothèse que les solutions open sources soient de qualité inférieure ne devrait pas être considérée comme une raison valable pour éviter les applications libres.




Source : Le rapport de Coverity



Et vous ?

Trouvez-vous que le code open source est meilleur que le code propriétaire ?

[el_slapper]

La qualité du code, c'est important. Mais l'open source ne se focalise pas sur les mêmes éléments que le commercial. Souvent, le commercial est créé dans une optique de prendre le marché avant le concurrent. Ca ne favorise pas la qualité intrinsèque du code.

Je ne sais plus ou j'avais lu que la base de code d'Amazon était exceptionellement mauvaise en terme de qualimétrie. Sauf que cette lourde dette technique leur a permis de s'emparer du marché. Ils continuent à la payer, mais au vu du succès, c'est un prix tout à fait acceptable, à mon sens.

[Jon Shannow]

37 millions de code open source et plus de 300 millions de code propriétaire

Ça veut dire quoi ces chiffres ? Qu'est-ce qu'un "code" ? Je ne connais pas cette unité !

En supposant qu'un "code" soit mesurable, comparer un échantillon de 37 millions à un échantillon de 300 millions ne me semble pas très scientifique !

[Doksuri]

Je pense que les codes open-sources sont, a long terme, de meilleure qualite, car un jour, un gars (ou femme) dira "tiens, ca, ca peut etre ameliore"... du coup...au fil du temps, le code sera de mieux en mieux..
alors que le proprietaire n'a pas autant "d'yeux".

[Neko]

Autant je vois comment ils ont pu faire des scans sur du code Open Source, autant sur du code propriétaire... ils font comment ?
Autre chose je vois qu'ils ont inclut dans les stats de très gros projets bien connus pour l'Open source, mais pas d'infos pour les codes propriétaire ?
Puis bon faire des stats sur une 40 aine de projets c'est loin d'être révélateur.
Bref beaucoup de choses bizarres, ils semblent juste chercher à se faire de la pub en créant la polémique.

[MiaowZedong]

Je ne pense pas que la problème soit l'échantillon....

Comment definissent-t-ils le défaut, pour que leur outil automatisé puisse le detecter?

Sinon, +1 pour El Slapper.

P.S. à lire l'article, c'est effectivement plus une pub pour Coverity qu'une étude fiable.

[teddyalbina]

Je pense que les codes open-sources sont, a long terme, de meilleure qualite, car un jour, un gars (ou femme) dira "tiens, ca, ca peut etre ameliore"... du coup...au fil du temps, le code sera de mieux en mieux..
alors que le proprietaire n'a pas autant "d'yeux".

Mouais franchement je n’ai pas vue beaucoup de projet open source bien codé et encore moins bien documenté.
Pour le problème d'yeux quand tu sais qu'un soft comme windows c'est 6000 personnes je pense que niveau yeux ça doit être suffisant. Mais il ne faut pas oublier que tout simplement un soft est par définition imparfait car l'Homme ne l'est pas.
Sans compter que par moment tu dois résoudre des problèmes dont la solution n'est pas belle mais pour autant efficace (Voir le super hack des dev de MS dans winbase.h pour résoudre les problèmes du à certain cpu n'implémentant pas ou mal certaines fonctionnalités de l'archi X86-64). L'outil (le langage) apporte aussi son lot de limitations, en outre une chose peut sembler simple pour un humain très complexe à faire exécuter par une machine (et nécessiter quelques "astuces" ).

[teddyalbina]

Je ne pense pas que la problème soit l'échantillon....

Comment definissent-t-ils le défaut, pour que leur outil automatisé puisse le detecter?

Sinon, +1 pour El Slapper.

P.S. à lire l'article, c'est effectivement plus une pub pour Coverity qu'une étude fiable.

C'est LA QUESTION

[Traroth2]

La qualité du code, c'est important. Mais l'open source ne se focalise pas sur les mêmes éléments que le commercial. Souvent, le commercial est créé dans une optique de prendre le marché avant le concurrent. Ca ne favorise pas la qualité intrinsèque du code.

Je ne sais plus ou j'avais lu que la base de code d'Amazon était exceptionellement mauvaise en terme de qualimétrie. Sauf que cette lourde dette technique leur a permis de s'emparer du marché. Ils continuent à la payer, mais au vu du succès, c'est un prix tout à fait acceptable, à mon sens.

C'est tout à fait crédible. Mais ça explique sans excuser, parce qu'au final, on se retrouve quand même avec des produits moins bons que ce qu'on pouvait attendre.

[gorgonite]

Autant je vois comment ils ont pu faire des scans sur du code Open Source, autant sur du code propriétaire... ils font comment ?

ils se basent sûrement sur des statistiques renvoyées par leurs clients, mais clairement cela signifie que c'est au bon vouloir des clients... donc pas forcément représentatif

Autre chose je vois qu'ils ont inclut dans les stats de très gros projets bien connus pour l'Open source, mais pas d'infos pour les codes propriétaire ?

informations confidentielles... on ne livre pas son porte-feuille client a priori sans accord, etc. Il est donc plus simple de parler de "logiciels propriétaires" sans en dire plus

Bref beaucoup de choses bizarres, ils semblent juste chercher à se faire de la pub en créant la polémique.

Sinon, +1 pour El Slapper.

P.S. à lire l'article, c'est effectivement plus une pub pour Coverity qu'une étude fiable.

Cela semble évident... d'autant plus pour un produit qui a en fait peu de parts de marché en Europe, et technique assez proche d'un PolySpace assez répandu chez les éditeurs de logiciels critiques (mais avec un moindre support des langages si je me souviens bien... là encore est-ce important pour du soft critique ?)

Comment definissent-t-ils le défaut, pour que leur outil automatisé puisse le detecter?

une partie de ses analyses statiques utilisent l'interprétation abstraite (comme les outils PolySpace ou Astrée) et la précision de l'analyse repose sur la performance du/des domaine(s) abstrait(s) utilisés en interne... il y a des grands exemples hyperconnus (signes, intervalles, zones, octogones, polyèdres) et d'autres beaucoup plus confidentiels (surtout les domaines relationnels).

donc ils ont cité quelques exemples d'erreurs : déréférencement de pointeur null, utilisation de variables non initialisées, etc. Mais clairement, être précis sur ce point n'est pas du niveau a priori d'un rédacteur de news (et comprendre le fonctionnement d'un domaine abstrait c'est M2 recherche mini)

Mouais franchement je n’ai pas vue beaucoup de projet open source bien codé et encore moins bien documenté.
Pour le problème d'yeux quand tu sais qu'un soft comme windows c'est 6000 personnes je pense que niveau yeux ça doit être suffisant. Mais il ne faut pas oublier que tout simplement un soft est par définition imparfait car l'Homme ne l'est pas.

avis particulièrement partisan et preuve d'une méconnaissance du fonctionnement des "gros et beaux" projets open-source (après si on ne regarde que les CMS php codés par des kevins, forcément c'est ultra-représentatif)

[Christuff]

Moi je vois surtout l'etude tronquee :

Suite à l’examen de 45 projets open sources majeurs ayant en moyenne chacun près de 820 000 lignes de code, l’éditeur a constaté une densité moyenne de défauts de 0,45 sur la base du nombre de défauts pour 1 000 lignes de code.

Tandis qu’un taux de défauts de 0,64 pour 1 000 lignes de code a été constaté pour les applications propriétaires. L’entreprise a examiné 41 projets propriétaires ayant en moyenne 7,55 millions de lignes de code.

forcement dans 1 ligne de code il y a moins d'erreur que dans 10 ....
La ou ca se revele interessant c'est ou il est dit

Linux 2.6 avec ses 7 millions de lignes de code présente une densité de défauts de code presque identique à celle de ses homologues propriétaires.

Comme quoi, le défaut dans le code est plus lié a la taille du projet / nombre de lignes a écrire / nombre d'intervenant que dans le simple débat open-source vs propriétaire

[ZiGoM@r]

Cela me parait aller de soit ; à taux égaux de développement et d'utilisation, un code ouvert à tout simplement plus de lecteurs potentiels. Ne vous est-il jamais arriver de remonter directement le fix plutôt que les seuls symptômes ?
Aussi, l'Open Source, étant beaucoup plus apte à offrir des technologies standards, incite naturellement les professionnels à y investir des ressources pour rendre plus fiable leur propres systèmes. Quand bien même voudraient-ils le faire pour une technologie fermée, ils ne pourraient pas.

[_skip]

Déjà je pense que juger de la qualité d'un code uniquement sur de l'analyse statique est peut être pas suffisant. Je doute que les outils de ce genre sachent évaluer précisément si une base de code est humainement de qualité ou non et encore moins si la solution résultante est bonne ou non.

La qualité d'une solution ça peut aussi être un tout qui englobe la documentation, le support, le fonctionnel, la réponse adéquate au besoin. Un code en soi, ça peut être une oeuvre d'art dans l'IDE et pourtant une fois compilé ça donne un produit de merde.

Enfin pour parler du code puisque c'est ce qui est testé ici, je pense que ce n'est pas vraiment facile de savoir si la qualité open source est généralement meilleure que le propriétaire. Je pense que la qualité d'un code dépend de la personne qui l'écrit puis de celles qui dirigent le projet, de la qualité des standards en place et de leurs moyens (parfois financiers) en terme de test notamment. Je pense qu'avant même l'aspect open source ou non, il y a la façon dont le projet est géré et sa politique interne qui vont jouer un rôle.

Je ne suis pas persuadé que les clients qui utilisent du open source aient forcément l'envie ou les moyens de faire du développement, j'utilise professionnellement pas mal de logiciels open source mais s'ils posent des problèmes je ne vais pas aller télécharger le code et faire du débuggage. Ce n'est pas parce que l'utilisateur peut techniquement s'impliquer qu'il va le faire ou qu'il a les compétences pour le faire, s'il a un problème avec postgresql, il est probable qu'il fasse la même chose qu'avec oracle ou sql server ou encore db2, càd aller sur les forums, signaler le bug (si possible encore) et attendre avec beaucoup d'espoir. Et s'il a trop de problème, il va peut être envisager de passer à autre chose.

[Er3van]

En repartant du titre, j’émets une petite réserve de forme : "Le code open source égal ou meilleur que le code propriétaire". Comment, puisqu'ils ne font pas la même chose, peut-on comparer des sources et dire que l'une est meilleure que l'autre? Et j'espère qu'on compare à technologies équivalentes !

Cela mis de côté, cela me parait totalement logique que l'open source soit de qualité égale ou meilleure.
Pour faire taire tout de suite les mauvaises langues, je ne participe à aucun projet d'open source (mais j'en utilise régulièrement).

Le fait est qu'en entreprise, "Time is money" (comme dirait B. Franklin) et que du coup, on ne laisse généralement pas le temps aux développeurs de faire de la "qualité" (je parle de qualité interne, par opposition à la qualité au sens ISO 9001). Alors que dans l'open source, par principe, on ne fait pas ça pour l'argent, et on peut prendre le temps de faire les choses "bien", et faire de la revue de code, ou de la reprise (en entreprise c'est rare!)
Après, c'est évidemment contre-balancé par le fait qu'il y ait plus d'outils, de méthodes en entreprise et des professionnels (ce qui n'est pas toujours un gage de qualité...) qui travaillent potentiellement mieux ensemble, ce qui amène à un résultat assez équilibré au final.

Cela étant dit, je rejoins l'idée qu'il s'agisse plus d'un coup de com' qu'autre chose.

[kolodz]

J'ai toujours été septique sur l'analyse sur les LOC...
Je vois tous les jours au travail des classes/fonctions kilométrique. Elles n'ont certes pas de défauts en soit, mais c'est un magma de copier-coller.
La densité de défaut n'est une métrique en soit...

Si t'as trois programmes qui font la même chose :
1 a une densité de défaut de 10 et 2M de LOC
2 a une densité de défaut de 1 et 100M de LOC
3 a une densité de défaut de 5 et 5M de LOC

Je vous pari tout ce que vous voulez que 1 et 3 sont largement plus facile à corriger, à maintenir et à faire évoluer.

Ce qu'il faut retenir, c'est qu'un code libre n'est pas moins bien qu'un code propriétaire. Combien de serveur tourne sous apache ?...

Cordialement,
Patrick Kolodziejczyk.

[Aiekick]

C'est pas parce que le code est plus propre ou équivalent aux solution commerciales qui me fait aller vers une solution open-source plutôt que commerciale.

C'est plus l'ergonomie qui est bien souvent a la ramasse coté open-source.

[gorgonite]

Déjà je pense que juger de la qualité d'un code uniquement sur de l'analyse statique est peut être pas suffisant. Je doute que les outils de ce genre sachent évaluer précisément si une base de code est humainement de qualité ou non et encore moins si la solution résultante est bonne ou non.

La qualité d'une solution ça peut aussi être un tout qui englobe la documentation, le support, le fonctionnel, la réponse adéquate au besoin. Un code en soi, ça peut être une oeuvre d'art dans l'IDE et pourtant une fois compilé ça donne un produit de merde.

et que connais-tu des analyses statiques ? de ce qui est démontrable avec ? sais-tu que nombre d'éditeurs de tels analyseurs fournissent également un ensemble de fonctionnalités telle que les métriques de manière à suivre plus finement le projet, le respect de certaines règles de codage, etc. (je ne suis pas un VRP )

après clairement, si l'on veut jouer l'avocat du diable, il est clair qu'il est souvent possible de tricher avec les métriques ou outils statistiques surtout si l'on connait les critères (comme certains le font avec le page ranking des moteurs de recherche)



mais clairement, là, cette annonce (et donc indirectement cette news) ressemble plutôt à un gros coup de pub de Coverity pour faire parler de lui sur un marché qu'il attaque difficilement. ceux qui ont eu/auront l'occasion de croiser leur "VRP" aux différents salons solutions embarqués l'an dernier comprendront... essayez de parler techniquement des analyses statiques, de leurs intérêts et de comparaison avec des outils existants

d'ailleurs, il n'y a qu'à voir à quel point le débat ne tourne pas autour des analyses statiques et ce qu'elles peuvent détecter (le fond du problème si l'on veut vraiment étudier les résultats annoncés), mais plutôt vers un nième troll open-source/propriétaire ou un gueguerre de détails sur l'intérêt du panel (qui est effectivement le second point noir de l'annonce)

[_skip]

et que connais-tu des analyses statiques ? de ce qui est démontrable avec ?

sais-tu que nombre d'éditeurs de tels analyseurs fournissent également un ensemble de fonctionnalités telle que les métriques de manière à suivre plus finement le projet, le respect de certaines règles de codage, etc. (je ne suis pas un VRP )

Tu trouves aussi, sauf erreurs, des outils tiers et des plug ins pour certains IDE qui permettent de sortir des chiffres sur la complexité d'une base de code en se basant sur différents critères plus ou moins simples, tout comme le respect des règles de nommage etc que tu cites. Donc oui je peux me douter qu'une grosse suite comme celle dont il est question ici propose cela. Cependant est-ce que j'ai le droit de douter du fait que ces chiffres puissent servir de base solide de comparaison entre des projets de nature différente?
Je ne doute pas que l'on puisse utiliser de ce genre d'analyse pour suivre l'évolution d'un projet et de sa complexité et éventuellement d'en tirer si nécessaire certaines conclusions. Mais là il s'agit de projets clairement très différents.

après clairement, si l'on veut jouer l'avocat du diable, il est clair qu'il est souvent possible de tricher avec les métriques ou outils statistiques surtout si l'on connait les critères (comme certains le font avec le page ranking des moteurs de recherche)

A ce titre, crois-tu à titre d'exemple qu'un code coverage à 99% avec des tests unitaires est signe que les tests effectués sont d'excellentes qualité? A nouveau c'est un chiffre concret qui est un des éléments d'une analyse globale, mais ce n'est pas forcément la réponse du 100%.

Tu as sans doute raison de faire remarquer que je ne suis pas un expert de ce genre d'outil mais cependant, bien que je ne critique aucunement le recours à ce genre de technique lorsqu'elles sont disponibles, je me dis toujours que lorsque l'on sait à quel point la qualité est parfois une notion subjective chez les humains c'est difficile pour un outil d'établir un classement fiable sur des logiciels totalement hétérogènes.
Je ne critique pas du tout l'utilité d'essayer d'anticiper un maximum d'anomalies avec des outils de ce genre, ni l'aptitude à sortir des rapports cohérents (même si je t'avoue que je suis loin de connaître tous les mécanismes auxquels on a recours pour ce faire), je me méfie juste de la comparaison qui est faite ici.

[lequebecois79]

Mouais franchement je n’ai pas vue beaucoup de projet open source bien codé et encore moins bien documenté.

Tu dois pas avoir vu grand chose aussi.....

très rapidement: spring, netbeans, amarok, koffice, konqueror, apache.........

[gorgonite]

A ce titre, crois-tu à titre d'exemple qu'un code coverage à 99% avec des tests unitaires est signe que les tests effectués sont d'excellentes qualité? A nouveau c'est un chiffre concret qui est un des éléments d'une analyse globale, mais ce n'est pas forcément la réponse du 100%.

déjà ils trichent, le code est "couvert" à 99%, ce qui ne signifie pas du tout que 99% des chemins d'exécution possibles le soient (et ça change tout )
par ailleurs, il est facile d'écrire des tests bidons appelant chaque bout de code et de ne pas tenir compte de la valeur de retour... auquel cas seul le "core dump" ou l'exception non gérée sera détectée (faut être pervers, mais si on est payé à la ligne et qu'en face y a des commerciaux pour contrôler )

Je ne critique pas du tout l'utilité d'essayer d'anticiper un maximum d'anomalies avec des outils de ce genre, ni l'aptitude à sortir des rapports cohérents (même si je t'avoue que je suis loin de connaître tous les mécanismes auxquels on a recours pour ce faire), je me méfie juste de la comparaison qui est faite ici.

le problème est qu'on ne tente de prouver que ce qu'on souhaite réellement chercher... et déjà, si l'on a des je-m'en-foutistes, c'est très mal parti

encore une fois, tout dépend de ce qu'on souhaite démontrer, de ce qu'on cherchait et du contrôle réel qui est fait de l'utilisation même de ces outils (potentiellement très utiles). y a quand même des raisons que les équipes soient séparées pour "valider" les projets DAL ou SIL (car une suite de tests et d'outils dont on décide de tordre volontairement le coup vont valider ce qu'on souhaite... à savoir au moins tout ce qu'on ne veut pas réellement tester)