Discussion :

[Access_to_folder]

Bonjour.

Argument majeur du logiciel libre, un "mantra" du mouvement open source selon certains, la loi de Linus : « avec suffisamment d’yeux ouverts, tous les bugs sont superficiels ». Comprendre parce que le code est libre, bien d'autres personnes vont venir le vérifier, donc il y aura moins de bugs qu'avec le logiciel propriétaire.

La page précédent met déjà des bémols sur cette affirmation, indiquant justement un laxisme du fait qu'on attend souvent alors que ce soient des tiers qui viennent débogguer.

Maintenant que l'IA relève nombreux bugs passés outre, aussi bien dans le libre que le propriétaire, je peine à trouver une actualisation de cette évaluation en tant qu'article sérieusement établi. En avez-vous à proposer ? Wikipédia n'en référence pas.

[Ti-Slackeux]

Vous me faites bien rire avec votre fixette sur le libre alors que vous vous en servez ...
Ils sont combien chez microsoft ??

Mes deux cents,

[Access_to_folder]

Cela est une recherche d'évaluation qualitative et quantitative de ce qui fut affirmé par des partisans de ce mouvement, qui a été contesté entre temps (exemple repris par Wikipédia , Robert Glass qui qualifie cela de "sophisme en raison du manque de preuves à l’appui"), et donc nous pouvons avoir avec les détections par IA un retour un peu plus conséquent sur des critères vérifiables, mais qui ne semblent guère documentés. Il est tout à fait justifié et important d'avoir à tirer le bilan de ce que cela à pu apporter, ou non, sur la qualité du code produit.

[Christophe]

Si je reprend la loi évoquée :

« Avec un nombre suffisant de bêta-testeurs et de co-développeurs, presque tous les problèmes seront rapidement identifiés et leur correction sera évidente pour au moins une personne. »

Il est simple de comprendre que si le code est opensource, il est accessible statistiquement à plus de potentiels auditeurs. Un code fermé ne sera accessible qu'à des auditeurs internes au projets, pour le cas d'entreprises commerciales, leurs codeurs, ou des prestataires en sous-traitance. Décompiler du code propriétaire est illégal (sauf exception encadrée) et techniquement empêché. Cela n'empêche pas forcément des tests de fonctionnement pouvant faire apparaitre des failles, mais l'accès au code source permet une meilleure efficacité.

Le temps étant de l'argent, il est très simple de comprendre que la recherche puis la correction de bugs (pouvant représenter des failles de sécurité) représente une charge pour une entité commerciale. Qu'est ce qui garanti qu'ils mettront les moyens ? Le libre va dépendre de la disponibilité et l’intérêt que vont y mettre des quidams. mais un nombre de personnes plus importantes que pour des sociétés commerciales, mais cela n'est que du potentiel jusqu'à réalisation concrête.

Une entreprise n'a pas forcément intérêt à communiquer sur le sujet, aussi bien sur les bugs qu'ils ont trouvés en interne, qui soit peut être une source d'informations pour les hackers sur les zones du projet potentiellement faillibles, soit une source d'inquiétude pour le client. Si ils font correctement leur travail, ils appliqueront les correctifs sous forme de mises à jour avec plus ou moins de transparence sur ce que ça corrige. D'ailleurs du point de vue utilisateur, pas besoin de détail technique, alors pourquoi détailler et donner une potentielle information à des personnes malveillantes. Et quid de projets qui ne sont plus commercialisés ?

Du coup comment avoir une source d'informations fiable ?

La fiche Wikipedia évoque en exemple la persistance d'une faille (Heartbleed) pendant 2 ans, mais on peut en citer sur Windows qui ont duré 20 ans, et sous Linux aussi probablement, je me souviens d'un truc avec SSH.
Ce qui ressort surtout de pertinent je trouve de ce document, c'est que plus un outil/projet est populaire/utilisé, plus on est susceptible d'y découvrir des failles. Mais c'est un peu un constat d'évidence.

C'est une loi qui ressemble à la loi de Murphy

[Access_to_folder]

Si je reprend la loi évoquée :
Du coup comment avoir une source d'informations fiable ?

Justement là est ma question et ma recherche documentaire sur le sujet, car je ne saurais y apporter une réponse.

Un argument est que l'open source n'implique pas forcément une mobilisation à vérifier. Combien de nous utilisons de l'open source sans auditer le code, faisant espérance à ce que quelqu'un l'a fait mais ne l'a pas fait.

On pourrait faire une analogie avec le bénévolat associatif : beaucoup de bénévoles mais très peu d'impliqués concrètement dans la productivité, fameux ratio sorti de je ne sais où de 5 % de productifs, le reste des membres étant de la pollution : faire figuration, se prétendre d'y être, venir faire la taupe ou du prosélytisme pour je ne sais quoi, tapin politique, incompétence...
J'ai pu m'inscrire sur des git de projets pour suivre une discussion, une actualité, par exemple sans jamais avoir de participation active au projet et était référencé abonné à au git, tout comme utiliser un logiciel sans vérifier le code.

Pour ma part, mais cela relève d'une impression plutôt que d'une analyse quantifiée que je cherche, je dirais que propriétaire et libre confondus, il y a un certain laxisme qui s'est instauré depuis longtemps. On n'est plus sur le temps où la ressource matérielle était limitée (chercher à optimiser le moindre octet) et il n'y a plus de coût de diffusion d'un logiciel ou d'un correctif (époque des disquettes, CD...) du faire de la connexion à un réseau international public étant devenu la norme. Donc la tendance est de laisser finir débuguer l'usager après une phase de test concluant que dans l'ensemble cela marche, et l'agilité viendra traiter un à un les bugs. Il y a aussi l'effet de mode qu'il faut sortir dans arrêt des nouvelles versions, faisant qu'un logiciel n'a pas fini d'être débugué qu'on en sort une nouvelle version parfois pour des fioritures.

La différence entre le propriétaire est le libre bien aussi du mode organisationnel et le modèle commercial : le propriétaire est là pour faire du profit, le libre en partie (car beaucoup de business s'est greffé sur les projets) pour le fun, ou des finalités politiques... La logique n'est pas la même; l'implication n'est pas la même (en particulier dans le temps : je viens comme je veux dans un projet et j'en repars comme je veux). La possibilité de forker à tout va car je veux faire mon projet à moi dans le libre peut aussi disperser les participants en lieu de les concentrer activement et efficacement sur un projet unique.

Et c'est en cela qu'il serait intéressant avec un certain recul d'en tirer un bilan qualitatif sur la production logicielle. Si le participatif apporte ou non une plus-value qualitative.