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 ?

Citation:

---

Envoyé par grunt2000

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

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

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 ?

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.

Citation:

---

Envoyé par grunt2000

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.

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.

Citation:

---

Envoyé par grunt2000

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é.

Citation:

---

Envoyé par grunt2000

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à).