Journal Qualité du logiciel : le logiciel libre est bien meilleur que le propriétaire !

Posté par  . Licence CC By‑SA.
34
17
avr.
2014

Le rapport 2013 de Coverity est sorti

http://www.ciol.com/ciol/features/213112/coverity-scan-report-source-software-quality-outpaces-proprietary-code

Coverity propose un service de vérification de code par analyse statique. Depuis 2008, ils testent à grande échelle des logiciels libres et comparent les statistiques à leur large base de clientèle reposant sur du logiciel propriétaire. Il s'agit majoritairement de programmes C/C++.

Régulièrement, la qualité du logiciel libre est mise en avant et surpasse celle du logiciel propriétaire, selon leur métrique de nombre de problèmes trouvés par coverity par 1000 lignes de code. On peut toujours discuter de la pertinence de la métrique, mais elle a le mérite de l'objectivité.

Les délais de réparation des défauts constatés, le noyau Linux s'améliore fortement, passant en 6 ans de 122 à 6 jours en moyene.

Les logiciels libres ont 19% de défauts en moins par 1000 lignes de code par rapport aux logiciels propriétaires.

Enfin la nouveauté 2013 de ce test concerne l'étude de programmes écrits en java. Il s'avère que les développeurs java ont beaucoup plus confiance dans le langage et corrigent une proportion beaucoup moins élevée des défauts trouvés par l'outil que les développeurs C++ (13% contre 46), notamment tout ce qui concerne les fuites de ressources systèmes que même un garbage collector parfait ne pourrait pas libérer. On note toutefois l'exception notable de HBase, qui est le projet de bases de données de la fondation Apache utilisé par Hadoop.

  • # Biais

    Posté par  . Évalué à 5.

    Dans les biais évident, on peut penser que leur base de client est composée de gens qui ont déjà identifié que leur code devait être amélioré. Donc pas forcement représentatif.

    • [^] # Re: Biais

      Posté par  (site web personnel) . Évalué à 10. Dernière modification le 17 avril 2014 à 12:39.

      Tu peux aussi penser que le biais s'exerce en sens inverse. Les firmes qui ont la volonté de proposer des logiciels propriétaires de bonne qualité vont soumettre leur code à Coverity.
      Les firmes qui se foutent de la qualité et dont le code propriétaire est dégueulasse ne vont même pas envisager d'utiliser Coverity.

      Donc peut-être que la qualité moyenne du code proprio est encore bien pire que ce qu'on voit dans ce rapport.

      • [^] # Re: Biais

        Posté par  . Évalué à 10.

        De toute façon le biais de sélection est tellement énorme et incontrôlé que ces résultats ne veulent rien dire.
        (par exemple il est évident que Coverity, qui propose gratuitement son service à certains projets libres, cible en priorité - marketing oblige - de gros projets bien établis, donc relativement bien maintenus aussi…)

        Pour comparer la qualité des logiciels libres et propriétaires il faudrait sélectionner des logiciels fonctionnellement équivalents, avec également une popularité et une maturité relativement proches.

        Les libristes naïfs qui répercutent ce genre d'infos devraient comprendre qu'elles ne servent qu'à une chose : faire la pub de Coverity, pas celle du logiciel libre.

        • [^] # Re: Biais

          Posté par  . Évalué à 4.

          Pour comparer la qualité des logiciels libres et propriétaires il faudrait sélectionner des logiciels fonctionnellement équivalents, avec également une popularité et une maturité relativement proches.
          Ou alors suivre l'évolution d'un indicateur, fût-il imparfait.

          L'intérêt principal de cette étude est qu'elle est faite tous les ans avec la même méthodologie, et qu'on peut en suivre l'évolution. Même s'il existe des biais, il est clair que le logiciel libre a fait de gros progrès.

          Concernant les biais possibles, le nombre de logiciels testés (aussi bien libres que propriétaires) est tout de même très large.

        • [^] # Re: Biais

          Posté par  . Évalué à 2.

          N'importe qui peut soumettre son project libre sur Coverity Scan, d'après ce que je vois sur le site http://scan.coverity.com .

          Par contre c'est certain que la démarche venant des projets, ce sont probablement les plus gros qui doivent s'intéresser à ce genre d'analyse, les petits ont plus urgent à faire :)

  • # Je me tue à le dire

    Posté par  . Évalué à 5.

    Enfin la nouveauté 2013 de ce test concerne l'étude de programmes écrits en java. Il s'avère que les développeurs java ont beaucoup plus confiance dans le langage et corrigent une proportion beaucoup moins élevée des défauts trouvés par l'outil que les développeurs C++ (13% contre 46), notamment tout ce qui concerne les fuites de ressources systèmes que même un garbage collector parfait ne pourrait pas libérer.

    Ce n'est pas parce qu'on a un gb, qu'il faut coder en se foutant de l'allocation. Quel que soit le langage objet, lorsqu'on fait une allocation, il faut se poser la question de à qui appartient l'objet, quel est sa durée de vie, sa visibilité, et si en C++ c'est assez simple au final (entre les destructeurs et les smart pointer, notamment celui qui permet de préciser la fonction pour désallouer l'objet ;) )
    C'est juste de la rigueur. Théoriquement en java c'est plus ou moins la même chose (prédictibilité en moins), mais comme pour tous les petits projets c'est pas nécessaire, les mauvaises habitudes sont vites prises…)

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • # Autre étude, autre biais

    Posté par  . Évalué à 10. Dernière modification le 17 avril 2014 à 15:51.

    Les délais de réparation des défauts constatés, le noyau Linux s'améliore fortement, passant en 6 ans de 122 à 6 jours en moyene.

    Sinon pour le biais inverse, il y a le Trustwave Global Security Report, qui compare les vulnérabilités dans différents projets (non pas la qualité du code, mais les vulnérabilités CVE).

    La presse informatique insistait sur le fait que les failles publiques étaient corrigées bien plus rapidement dans windows que dans linux*, en constatant que les deux zero-day du noyau linux en 2012 avaient été corrigées en 857 jours (après introduction de la faille), les deux zero-day du noyau de windows en 375 jours. Les données sont probablement correctes mais sans intérêt : pour commencer une statistique avec N=2, ensuite Windows a eu quatre fois plus de vulnérabilités critiques que linux pendant la même période (34 au lieu de 9 pour linux) et ce sont ces nombres bien plus grands qui sont significatifs pour la statistique, et enfin le temps depuis introduction n'est pas très pertinent (il pourrait aussi bien être infini si la faille n'est pas découverte), c'est le temps entre la publication et la correction qui est intéressant, et ce paramètre n'est pas pris en compte (que ce soit par volonté de tromper ou par incompétence).

    * voir : Linux trailed Windows in patching zero-days in 2012, report says

    • [^] # Re: Autre étude, autre biais

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

      le temps depuis introduction n'est pas très pertinent […], c'est le temps entre la publication et la correction qui est intéressant

      Effectivement, sinon on n’évalue pas vraiment l’équipe de développement, mais l’équipe qui cherche des failles.

      ce commentaire est sous licence cc by 4 et précédentes

  • # Les joies des sociétés de services

    Posté par  . Évalué à 7.

    Il y a 4 mois, je ne connaissais pas le javascript, l'ajax et les css. J'en étais resté au pour le html… Depuis 2 mois, je fait l'intégration d'un site pour un client, je ne vous parle pas du code, je fais ce que je peux, mais j'ai un peu honte. Rassurez, je n'ai pas été formé en dehors d'un travail personnel à base de tuto.

    Si j'étais sur un projet libre, on aurait déjà corrigé des erreurs et j'aurai refait une partie du code. La, personne ne regarde mon code, j'ai droit à il ne faut pas utiliser des span mais des img puis le contraire. C'est de la que vient la différence de qualité.

    • [^] # Re: Les joies des sociétés de services

      Posté par  . Évalué à 10.

      Il y a 4 mois, je ne connaissais pas le javascript, l'ajax et les css. J'en étais resté au pour le html… Depuis 2 mois, je fait l'intégration d'un site pour un client, je ne vous parle pas du code, je fais ce que je peux, mais j'ai un peu honte. Rassurez, je n'ai pas été formé en dehors d'un travail personnel à base de tuto.

      C'est pas grave, tu as été intronisé expert en tout dans l'heure qui a suivi la signature de ton contrat.

    • [^] # Re: Les joies des sociétés de services

      Posté par  (site web personnel) . Évalué à 4. Dernière modification le 18 avril 2014 à 10:05.

      Si j'étais sur un projet libre, on aurait déjà corrigé des erreurs et j'aurai refait une partie du code.

      C'est beau les fantasmes.

      La, personne ne regarde mon code,

      Comme pour la plupart de projets libres.
      Faut arrêter d'imaginer que parce que c'est libre, des gens regardent automatiquement le code et proposent des patchs.

      Perso, j'ai des centaines de milliers d'utilisateurs de mon logiciel libre, quelques dizaines de gens qui compilent et se plaignent que ça ne compile pas sans pour autant patcher, et quelques patchs basiques de temps en temps, point barre, alors que mon code est moche de chez moche et pourrait être amélioré.
      Pareil que même pour un projet sensible comme OpenSSL, quasi personne ne regarde le code (sinon Heartbleed aurait été détecté…), les gens s'en foutent et veulent surtout au mieux ajouter des fonctionnalités.

      Les gens veulent utiliser, point. A moins que tu sois dans un super gros projet super sensible (et encore, donc)

      C'est de la que vient la différence de qualité.

      Donc : non. C'est de marketing pour que les libristes s'auto-persuadent qu'ils sont plus mieux bien, mais ça ne convainc que qui vuet être convaincu (tout comme le gens qui font la pub de coverty juste parce que Coverty les brossent dans le sens du poil, l'objectivité reste au placard).

      • [^] # Re: Les joies des sociétés de services

        Posté par  . Évalué à 3.

        Pour avoir participé à un projet libre, on ne se privait pas de critiquer le code. J'avais appris plein de chose en PHP à cette époque.
        Le fait de travailler sur du PHP et que les utilisateurs modifiaient les scripts pour les adapter n'était peut être pas étranger aux remarques sur le code.

        • [^] # Re: Les joies des sociétés de services

          Posté par  (site web personnel) . Évalué à 4. Dernière modification le 18 avril 2014 à 22:06.

          Je suis souvent tombé sur du code libre vraiment pourri ou sans aucune documentation et ce, même sur de gros projets (genre Hadoop il y a quelques années, maintenant je regarde un peu moins le code), quasiment toutes les fonctions avaient TBD (To Be Documented) comme seule doc…
          Par contre, je suis aussi souvent tombé sur du code libre plutôt bien fichu. Là où ça pêche quand même pas mal, c'est la doc, même si le code en soi est propre. Mais ça se comprend, le temps est limité pour tout le monde, et c'est dur de demander de multiplier par deux (voire davantage) le temps de développement juste pour ajouter une doc qui a de fortes chances de ne servir à rien.

          En entreprise, ça va dépendre de plein de choses : si la boîte a une culture de qualité (et qu'elle a compris l'intérêt de faire un code propre), si les développeurs sont suffisamment geeks pour aimer le code propre, etc.
          J'ai pas mal d'échos dans un sens comme dans l'autre ; bon, ok, pour le code pondu par la majeure partie des SSII, les échos vont tous dans le même sens :D

    • [^] # Re: Les joies des sociétés de services

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

      C'est sûr que le code des SSII peut être absolument dégueulasse, et ne sera jamais corrigé, puisque c'est un coût incompris et difficile à mesurer par le client.

      Par ailleurs, le code libre d'une même organisation et le code propriétaire, en terme de qualité, ça n'a souvent rien à voir.

      Le plus amusant c'est de trouver des failles bateau qui sont là depuis des années, mais que visiblement personne n'a daigné exploiter. Comme quoi, la sécurité par l'obscurité, ça peut marcher ;-)

      • [^] # Re: Les joies des sociétés de services

        Posté par  (site web personnel) . Évalué à -9. Dernière modification le 18 avril 2014 à 15:03.

        Comme quoi, la sécurité par l'obscurité, ça peut marcher ;-)

        Par la non obscurité, ça peut marcher aussi.
        (arrétez de fantasmer sur l'idée que des gens lisent forcément votre code libre, ou gardez le comme fantasme mais n'en concluez rien pour la vraie vie, il y a assez de démonstration de code libre dont la faille est découverte que des années plus tard par hasard et pas par lecture du code, juste par fuzzing, vous vous ridiculisez et par les même occasion la communauté du libre donc en disant que le libre permet automatiquement plus de sécurité comme par enchantement)

    • [^] # Re: Les joies des sociétés de services

      Posté par  . Évalué à 3. Dernière modification le 18 avril 2014 à 14:49.

      je ne connaissais pas le javascript, l'ajax et les css. (…) Si j'étais sur un projet libre, on aurait déjà corrigé des erreurs et j'aurai refait une partie du code

      Je ne savais pas qu'il était si difficile d'accéder au code-source js/css d'une page web. Je pensais qu'il suffisait de faire ctrl+U ou d'utiliser firebug… :)
      (bon, du reste, c'est vrai que même si le code-source est visible, le fait qu'il soit développé en projet fermé n'incitera probablement pas les visiteurs/utilisateurs à contribuer)

  • # Il faut bien lire...

    Posté par  . Évalué à 4.

    For the 2013 Coverity Scan Report, the company analyzed code from more than 700 open source C/C++ projects **as well as an anonymous sample of enterprise projects**. 
    

    "Entreprise projects" c'est pas vraiment la meme chose que 'logiciel proprietaire', plutot un sous-ensemble tres particulier qui ne concerne que les logiciels developpes en interne par certaines entreprises pas forcement specialistes du sujet.

    Ce que fait Adobe, MS, Apple, … par exemple n'entre pas dedans.

    • [^] # Re: Il faut bien lire...

      Posté par  . Évalué à 3.

      Qui parle d'Adobe, MS etc. dans l'article ? Et que sait-on des relations de clientèle entre Adobe et Coverity ?

      Ensuite, si les enterprise projects sont bien ce que tu affirmes, il s'agit sans conteste de la plus grosse quantité de logiciels propriétaires : ce sont justement eux qui font vivre les SSII.
      Il est donc vrai d'affirmer qu'en toute généralité, le logiciel libre est bien meilleur que le propriétaire. Après, on pourra toujours trouver un logiciel propriétaire de meilleure qualité qu'un logiciel libre on ne pourra jamais évaluer la qualité d'un logiciel propriétaire vu qu'on n'en a pas les sources.

      • [^] # Re: Il faut bien lire...

        Posté par  . Évalué à 10.

        C'est la ou il est bon de comprendre de quoi on parle plutot que vite reposter un article…

        Voila le produit dont on parle : https://scan.coverity.com/

        C'est un service , il faut uploader ton code source pour qu'il soit analyse.

        Aucune boite ayant du code 'important' (= la ou ils font attention a la qualite) ne va le passer la dedans car cela revient a poser les bijoux de la couronne chez une partie tierce. Ils vont plutot utiliser http://www.coverity.com/products/coverity-save/ qui est un produit installable en interne, et qui ne donne aucune info (donc pas de statistiques) a Coverity.

        Resultat, ici la comparaison est entre des outils internes qu'une entreprise a juge assez peu importants pour etre uploades sur le service, et du code libre qui est probablement un mix entre les joyaux (Apache, Linux, …) et des trucs moins importants.

        Bref, une comparaison sacrement bancale. Si tu veux comparer proprio a libre, tu prends des softs de memes types (ils essaient de resoudre le meme probleme, donc complexite a peu pres identique) et tu compares.

        Mettre Linux ou Apache d'un cote, et pas un OS/serveur web de meme importance de l'autre, cela biaise totalement la comparaison.

        • [^] # Re: Il faut bien lire...

          Posté par  . Évalué à -10.

          Toutafé, Un Tout Grand Merci pour la Rectification. Heureusement qu'il reste des entreprises^Wemployeurs, responsables et humain(e)s, pour nous nous aider à rester critiques. Merci à eux ! Merci à ton employeur. Merci à tes collègues, savants, qui n'ont que comme seules ambitions, celles de rendre la connaissance universelle et l'épanouissement partagé par tous. Ô qu'ils soient (bah tiens, toi aussi hein) loués, car nous savons comme l'Humanité peut être si ingrate, des fois.

        • [^] # Re: Il faut bien lire...

          Posté par  . Évalué à 2.

          et qui ne donne aucune info (donc pas de statistiques) a Coverity.
          Même pas de statistiques anonymes ? Tu as vu le code ?

Suivre le flux des commentaires

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