Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Membre confirmé

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    577
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 577
    Points : 610
    Points
    610

    Par défaut Quelles pratiques de la programmation open source devraient, selon vous, être révisées ?

    Bonjour,

    Les projets open source sont de plus en plus nombreux et utiles. Ils sont même devenus indispensables et je ne crois pas qu'il soit encore possible d'écrire un logiciel de nos jours sans faire appel à aucun d'entre-eux, ne serait-ce que comme composant d'un plus vaste projet doté d'une API propriétaire.

    Mais les projets open source naissent et meurent, et il n'est pas toujours sûr de se fier à eux sur une très longue durée. En ce début 2019, comment aimeriez-vous que les projets open source changent dans leur manière d'aborder leur gestion de projet, de développement, ou d'anomalies ? Je vais vous donner trois de mes idées, elles en susciteront peut-être d'autres :

    1) Bien qu'ils soient maintenant plus rares, de nombreux projets open source restent avec des sources sans commentaires (ou presque pas). Et malheureusement, la croyance qu'un bon programme s'explique tout seul par son code au bon programmeur qui connaît bien son langage montre souvent ses limites. Le temps qu'il faut pour réinterpréter de tête ce que chaque bloc de code va réaliser nous fait nous transformer en compilateurs tournant à plein régime à chaque lecture du code, et c'est fastidieux. Quelques projets ont été abandonnés pour être devenus inaccessibles. Leurs créateurs les maîtrisaient très bien, mais ils sont partis, s'en sont désintéressés. Et les suivants n'arrivent pas à tout appréhender.

    2) Un mois complet ou même un trimestre de gel des évolutions devraient s'instituer annuellement dans le but d'une curation complète des projets open source. Certains sont des sacs à bugs anciens (ou même récents) pénibles et jamais corrigés. Certains projets populaires il y a seulement quelques années deviennent inutilisables et chaque mois voit pourtant chez eux nouvelles évolutions. C'est quelque-chose d'irritant parfois. On a envie de dire : "Stop ! Vous ne pouvez pas arrêter un moment et revenir sur les bugs majeurs ou bloquants pour les purger ?".

    3) Une facilité s'est transformée en habitude puis en obligation : celle d'apporter toujours un cas de test lorsque l'on déclare une issue pour voir celle-ci prise en compte. Des anomalies très pénibles ne sont jamais résolues parce que ceux qui les mentionnent ne sont pas en mesure d'apporter eux-mêmes le nécessaire pour qu'il puissent être rejoués. C'est un pré-requis indu qui devrait être abandonné. Quand il y a bug, il y a bug et il doit finir par être pris en compte en l'état de ce que l'on possède pour le résoudre, même si c'est : aucun élément de départ sinon la description qu'en ont fait la/les victimes.


    Qu'en pensez-vous ? Avez-vous d'autres idées sur ce qui devrait évoluer ?

  2. #2
    Modérateur
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    3 714
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 3 714
    Points : 14 616
    Points
    14 616

    Par défaut

    Citation Envoyé par grunt2000 Voir le message
    Des anomalies très pénibles ne sont jamais résolues parce que ceux qui les mentionnent ne sont pas en mesure d'apporter eux-mêmes le nécessaire pour qu'il puissent être rejoués. C'est un pré-requis indu qui devrait être abandonné.
    Je ne suis pas d'accord sur ce point. Si t'es pas capable de produire un protocole de reproduction du problème c'est qu'il y a 9 chances sur 10 (et je suis gentil) que le problème vienne de toi. C'est pas possible de demander à des gens de gérer un bug que l'on est pas capable de reproduire. Par quel bout prendre le problème ? Comment tu fais en tant que mainteneur pour résoudre un problème que tu ne peux pas étudier ? C'est juste impossible.

    Citation Envoyé par grunt2000 Voir le message
    C'est quelque-chose d'irritant parfois. On a envie de dire : "Stop ! Vous ne pouvez pas arrêter un moment et revenir sur les bugs majeurs ou bloquants pour les purger ?".
    Ben si c'est important pour toi tu fork et tu PR. Si ça réagit pas tu publies ta version. Où est le problème ?

    Citation Envoyé par grunt2000 Voir le message
    Quelques projets ont été abandonnés pour être devenus inaccessibles.
    Si les sources ne sont plus accessibles par définition le projet n'est pas opensource. Si elles le sont et que les mainteneurs sont inactifs tu peux forker et publier ta version. Là aussi où est le problème ?
    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  3. #3
    Membre confirmé

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    577
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 577
    Points : 610
    Points
    610

    Par défaut

    Avec ces règles tacites-là, aucun utilisateur non informaticien ne peut plus espérer voir le moindre bug corrigé.
    En effet, il ne va pas reprendre un projet open source, le forker, et souvent : il ne sait pas comment créer un cas de test. Et même : ça ne suffit pas. J'ai inscrit il y a peu un bug sur QGis : j'ai passé quatre jours en question-réponses pour aider à cerner le problème, et ça ne suffit toujours pas pour que l'équipe open source se décide à investiguer. Elle me demande toujours si je ne pourrais pas me mettre dans telle ou telle situation, et à la fin, certaines de ces situations qu'elles voudraient me voir expérimenter que je vois pas comment les atteindre... Et comme je n'ai pas répondu à la huitième question consécutive (qui peut-être fait partie d'un tas de quarante questions préalables, comment puis-je le savoir ?), eh bien, l'investigation s'arrête-là. Pas de prise en charge.

    Et c'est la source du problème. Les projets open source tendent à ne plus prendre en compte que les problèmes rapportés par des informaticiens qui auront pris le temps d'y consacrer un temps particulier, et plus ceux des utilisateurs classiques.


    – Bonjour, ma voiture est en panne, elle s'est arrêté brutalement sur l'autoroute. Je tourne la clef, il ne se passe plus rien.
    – Ce n'est pas la batterie, vous l'avez testée ?
    – Non, je n'ai pas les outils.
    – Mais vous avez regardé si ce n'est pas la batterie ?
    – Je ne sais pas comment regarder.
    – Mais il faut que vous regardiez et que vous nous disiez si c'est la batterie ou si c'est autre chose.
    – Vous ne pouvez pas intervenir ?
    – Non, tant que vous ne nous faites pas le diagnostic complet et que ne nous dites pas où est la pièce défectueuse et la panne qu'elle a, nous n'interviendrons pas pour vous aider.


    Aux urgences, on vient d'amener une personne trouvée inconsciente sur la voie publique.
    On la jette : il n'y pas mot à côté d'elle pour expliquer ce qui lui arrive, alors on ne va pas la prendre en charge.



    Alors, je force le trait, mais on demande de plus en plus de travaux préliminaires aux déclarants d'anomalies, et à un moment donné, en excès par rapport au nombre d'anomalies réellement prises en charge.
    Sur QGis, justement, les utilisateurs commencent à râler parce que toutes leurs issues sont remises en cause, alors que le logiciel devient si instable que ses créateurs ont du le reconnaître sur leur site web. On marche sur la tête.
    Or, pour des bugs aux descriptions très plausibles ou très répétées par de nombreux utilisateurs, des investigations devraient avoir lieu sans additions requises. L'abus de prérequis fait tourner les projets open source à l'administratif, et les rend inefficaces.

  4. #4
    Modérateur
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    3 714
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 3 714
    Points : 14 616
    Points
    14 616

    Par défaut

    Citation Envoyé par grunt2000 Voir le message
    des investigations devraient avoir lieu sans additions requises
    Financées par ?

    C'est le coeur du problème. Si beaucoup de mainteneurs demandent plus de travail d'investigation aux utilisateurs c'est que ça prend un temps fou et que la plupart du temps ils ne sont pas payés pour écrire leur projet et que donc ils le font sur leur temps libre.

    Tes analogies ne sont pas du tout correctes, pour financer un garagiste on le paie, pour financer les hôpitaux on paie des cotisations.

    Quand tu utilises un projet opensource ou libre, ou même un freeware, il faut avoir conscience que l'assistance utilisateur et la maintenance peut être très aléatoire. Ça dépend du projet, du nombre de contributeurs, de son financement, de sa structure juridique, etc ... Il y a beaucoup de projets opensource qui sont backés par des entreprises et qui ont une grande réactivité mais ce n'est pas automatique.

    Quand je me risque à intégrer une lib dans un projet par exemple, je vais toujours prendre le temps de bien regarder l'historique des releases pour voir la fréquence, le nombre de contributeurs, le nombre de tickets ouverts, les dates de résolutions des tickets résolus, si possible le nombre d'utilisateurs, etc ... Si la communauté est morte et réagi très peu on peut considérer le projet comme mort.

    Je ne connais pas le projet dont tu parles mais peut être qu'il faudrait le considérer comme mort et trouver une alternative.

    Bref, en bout de ligne, tu ne peux pas exiger de gens qui bossent sur leur temps libre de te fournir une certaine qualité de service, ça n'a pas de sens. Si c'est une entreprise qui est derrière et que tu as signé un contrat avec elle ok, mais sinon je pense que tu fais fausse route sur la nature du produit que tu utilises.
    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  5. #5
    Membre confirmé

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    577
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 577
    Points : 610
    Points
    610

    Par défaut

    Là, je pense le contraire de toi.

    La plupart de ceux qui participent à des projets open source bénévolement et hors temps ouvrable sont aussi, le plus souvent, des informaticiens professionnels en heures ouvrées.
    D'une part, le fait qu'un projet soit professionnel n'implique pas que la qualité de ce qui y est produit soit toujours bonne (quoi que je sois d'accord : le marché a tendance à les sanctionner dans le cas où ils font du travail de mauvaise qualité),
    D'autre-part, cela n'empêche pas que si tu t'astreins professionnellement à réaliser un travail d'une qualité donnée, il n'y a pas de raison valable que tu fasses relâche devant un projet open source qui va, par nature, toucher un plus grand nombre d'utilisateurs que le logiciel que professionnellement tu développes pour ta société. Pour ma part, sur le projet open source sur lequel je développe, je considère que je dois y mettre toute la rigueur, sinon plus, que celle que je mets au quotidien sur mon lieu de travail. Un bug qui est annoncé et qui pourrait éventuellement graviter autour de ce que j'ai écrit, eh bien, je regarde mes sources et j'examine sérieusement s'ils pourraient en être la cause. Ça se sent, tout de même.

    D'un côté, il y a les tests réclamés bien sûr, et les bonnes pratiques. Il y a l'arrivée des git masters sévères quant à la qualité du code commité. Et d'autres avancées que l'on doit au monde open source.
    Mais celle de refuser de voir les bugs, qui par nature sont agaçants car ils interrompent es évolutions que l'on entreprenait, c'est aussi quelque-chose de patent. Et je trouve qu'il n'y a pas d'excuse. Tout le monde rechigne toujours à s'y mettre, c'est pas nouveau ; au boulot aussi ! Mais voilà, il faut quand même y consacrer le temps nécessaire à ce débogage à fond.

    De manière générale, je trouve que l'argument "bénévole, gratuit et pris sur son temps" ne doit pas servir à autoriser un code et un suivi de qualité plus faible.
    Il y a une règle en informatique : réduire le nombre de fonctionnalités plutôt que la qualité. Et cette règle-là ne devrait pas être brisée.

  6. #6
    Modérateur
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    3 714
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 3 714
    Points : 14 616
    Points
    14 616

    Par défaut

    Citation Envoyé par grunt2000 Voir le message
    De manière générale, je trouve que l'argument "bénévole, gratuit et pris sur son temps" ne doit pas servir à autoriser un code et un suivi de qualité plus faible.
    Il y a une règle en informatique : réduire le nombre de fonctionnalités plutôt que la qualité. Et cette règle-là ne devrait pas être brisée.
    Je suis d'accord avec toi sur ce point et je ne pense pas avoir écrit le contraire. Je parlais du temps disponible à consacrer au projet pas de qualité.
    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  7. #7
    Membre éprouvé
    Homme Profil pro
    Ingénieur R&D
    Inscrit en
    mai 2016
    Messages
    261
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Ingénieur R&D
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mai 2016
    Messages : 261
    Points : 968
    Points
    968

    Par défaut

    Citation Envoyé par grunt2000 Voir le message
    Bonjour,

    Les projets open source sont de plus en plus nombreux et utiles. Ils sont même devenus indispensables et je ne crois pas qu'il soit encore possible d'écrire un logiciel de nos jours sans faire appel à aucun d'entre-eux, ne serait-ce que comme composant d'un plus vaste projet doté d'une API propriétaire.

    Mais les projets open source naissent et meurent, et il n'est pas toujours sûr de se fier à eux sur une très longue durée. En ce début 2019, comment aimeriez-vous que les projets open source changent dans leur manière d'aborder leur gestion de projet, de développement, ou d'anomalies ? Je vais vous donner trois de mes idées, elles en susciteront peut-être d'autres :
    ...
    La pérennité est un des critères de sélections les plus importants pour les bibliothèques opensource et composants divers que j'utilise.
    J'essaye d'évaluer l'équipe qui est derrière, qui sont les utilisateurs, et en particulier s'il y a des organisations importantes.
    Il est évident que des utilisateurs comme la NASA, le LANL, DOE US, etc. ont plus de poids que moi pour tirer la qualité vers le haut et faire corriger les bugs.
    Moyennant quoi il est exceptionnel que j'ai des problèmes.
    Par exemple, pour la visualisation de données, j'utilise VTK depuis presque 20 ans, et je pense que ce sera toujours là dans 20 ans (bon, je serais à la retraite à ce moment là).

Discussions similaires

  1. Quelle est la pire libraire Open Source portée de Java vers .Net ?
    Par Invité dans le forum Général Dotnet
    Réponses: 1
    Dernier message: 30/03/2012, 17h51
  2. Réponses: 15
    Dernier message: 02/04/2010, 13h09
  3. Réponses: 0
    Dernier message: 13/11/2009, 12h39
  4. Quelle technologie pour une application open source en Java de type desktop ?
    Par Pierre8r dans le forum Interfaces Graphiques en Java
    Réponses: 2
    Dernier message: 30/06/2009, 18h22
  5. [LZW] utilisation dans un programme open source
    Par Muesko dans le forum Algorithmes et structures de données
    Réponses: 4
    Dernier message: 02/04/2007, 12h47

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo