Une majorité d'utilisateurs va trouver des choses perfectibles : Le dev est pas sympa, une réponse au bout de 3 mois, il y a des bugs honteux, le README n'existe pas, etc. C'est une réalité et ce sont des arguments tout à fait valables. Cependant il est probable que le logiciel/projet fonctionne.
D'un côté on se retrouve avec une équipe restreinte de quelques personnes qui a passé des centaines d'heures de travail/sueur sur ce projet et qui tentent d'améliorer les choses. Ils sont peu nombreux mais ont beaucoup donné (et continuent à le faire). De l'autre côté des centaines d'utilisateurs qui vont remonter des choses perfectibles (et bien réelles) en se plaignant que l'accueil n'a pas été bon, le bug toujours présent, exigeant qu'on répare. Ils sont nombreux et n'ont rien donné encore ou quasiment.
Le combat n'est pas du tout équitable, la balance (surtout niveau engagement) dans le projet n'a rien à voir. Passez 100 heures à développer un projet et quand le premier retour sera “il est où le README ?”, demandez-vous si il faut prendre la défense de celui qui a bossé 100 heures ou de celui qui pointe un vrai problème mais n'a rien apporté encore.
Ce sont les personnes qui font qui doivent être mises en avant, remerciées, soutenues. Elles ne sont pas parfaites mais c'est elles qui ont donné et continuent de donner malgré les critiques et les très rares remerciements.
Bonjour,
Personnellement j'utilise des logiciels open source dans des environnements Windows & Linux et j'ai parfois fait des donations.
J'utilise également des logiciels en milieu professionnel mais dans une entreprise quand c'est gratuit -> pas de donations.
Même si cela peut être ringard ou autre, je pense qu'il faudrait mettre un popup d'appel au dons à chaque lancement d'un logiciel.
Ce popup disparaîtrait pendant un certain temps après un don.
Pour un particulier ce popup ne serait pas gênant mais dans une entreprise quand le logiciel est sollicité à maintes reprises cela peut devenir gênant.
Malheureusement,je pense qu'il faut forcer un peu pour avoir une contribution qui serait méritée.
Marco
Même s’il m´est arrivé de faire des PR avec correctif de bugs qui sont restées sans réponse, je suis 100% d’accord avec Carl.
Mes projets FOSS sur Github ne sont pas bien populaires mais lorsque je reçois une PR avec soit correction de bug soit ajout de fonctionnalité, je m’efforce toujours de remercier.
En effet, article intéressant… même si sous certains aspects, il peut sembler réducteur.
Quoiqu'il en soit, actuellement, personnellement, je contribue d'une manière différente, sur un projet qui aux antipodes de mes intérêts. Et, cela me surprend moi-même, d'autant que je suis capable de gérer du code shell… car ce n'est même pas du code que je fais, mais de la participation à la documentation du projet.
Alors, certes je ne le fais pas tous les jours, pour des raisons personnelles, mais assez régulièrement. Ce projet est #play.it - pour les jeux sous Linux.
Ce qui m'est sûr, c'est que j'apprécie de pouvoir le faire, d'autant que @vv222 est très compréhensif, et amical.
Ensuite, j'ai quelques développements en suspens… je sais qu'il y en a un qui attend un correctif… mais je suis agréablement surpris de recevoir une petite contribution financière par le biais de liberapay, semaine après semaine… quoique celle-ci est peut-être pour ma participation active au projet obsd4a (administration, traduction inofficielle de la FAQ OpenBSD sur le wiki, etc…) !
Alors, oui, y'a plusieurs moyens de participer à un projet ou l'autre… et de le faire dans la bonne humeur ;)
Je suis totalement d'accord sur le fait que beaucoup d'utilisateurs le font en temps que consommateurs (souvent par ignorance du modèle FOSS, j'ai vu y'a pas longtemps, quelqu'un qui pensait que libreoffice, était une version de M. office gratuite et light).
Autrement, en lisant l'article, j'ai eu l'impression que tu disais que la remonté de bug n'était pas considérer comme une contribution, alors que pour moi, c'est la première contribution, et surement la plus importante.
Personnellement, j'essai de contribuer au maximum, mais quotidiennement, c'est impossible. Quand c'est possible, et que mes faibles compétences en devs le permets, je peux ajouter des features et/ou faire de la correction de bug. Sinon sur github, je star, et si bug il y a, je remonte. Je ne fais pas de documentation, car je n'ai pas un niveau rédactionnel très élevé.
Pour ce qui est des dons, c'est plus compliqué (pas une question d'argent), car la je me base plus sur le comportement des devs, leurs relationnel, que sur le code ou le soft lui même, si le mec réclame un don dès qu'on lui remonte un bug, ou prends les gens de haut, il n'aura jamais un don de moi.
C'est drôle de voir la réaction entre le public Anglais (sur https://carlchenet.com/foss-passive-consumerism-kills-our-community/) et le public Français (sur https://framablog.org/2018/08/29/les-logiciels-libres-meurent-lentement-sans-contributions/), ce n'est pas du tout la même. Comme d'habitude le contexte et la culture sont très importants dans la réception du message.
Je pense pour ma part que Carl a lourdement raison de signaler et d'appuyer ce problème qui va nous coûter cher à l'avenir (y compris sur le Jdh).
C'est très simple à pointer et expliquer si on prend ce thread (https://mastodon.eliotberriot.com/@eliotberriot/100633055572089222) et celui-ci malheureusement en Anglais (https://www.reddit.com/r/archlinux/comments/9aotjr/aurman_no_longer_being_maintained_publicly/e4xklt3/).
Une majorité d'utilisateurs va trouver des choses perfectibles : Le dev est pas sympa, une réponse au bout de 3 mois, il y a des bugs honteux, le README n'existe pas, etc. C'est une réalité et ce sont des arguments tout à fait valables. Cependant il est probable que le logiciel/projet fonctionne.
D'un côté on se retrouve avec une équipe restreinte de quelques personnes qui a passé des centaines d'heures de travail/sueur sur ce projet et qui tentent d'améliorer les choses. Ils sont peu nombreux mais ont beaucoup donné (et continuent à le faire). De l'autre côté des centaines d'utilisateurs qui vont remonter des choses perfectibles (et bien réelles) en se plaignant que l'accueil n'a pas été bon, le bug toujours présent, exigeant qu'on répare. Ils sont nombreux et n'ont rien donné encore ou quasiment.
Le combat n'est pas du tout équitable, la balance (surtout niveau engagement) dans le projet n'a rien à voir. Passez 100 heures à développer un projet et quand le premier retour sera “il est où le README ?”, demandez-vous si il faut prendre la défense de celui qui a bossé 100 heures ou de celui qui pointe un vrai problème mais n'a rien apporté encore.
Ce sont les personnes qui font qui doivent être mises en avant, remerciées, soutenues. Elles ne sont pas parfaites mais c'est elles qui ont donné et continuent de donner malgré les critiques et les très rares remerciements.
Tcho !
Très bon article.
Tcho !
Merci ! et merci à Framasoft pour la traduction à quatre mains. Je n'aurais sans doute pas sorti l'article en français si vite sinon.
Bonjour, Personnellement j'utilise des logiciels open source dans des environnements Windows & Linux et j'ai parfois fait des donations. J'utilise également des logiciels en milieu professionnel mais dans une entreprise quand c'est gratuit -> pas de donations. Même si cela peut être ringard ou autre, je pense qu'il faudrait mettre un popup d'appel au dons à chaque lancement d'un logiciel. Ce popup disparaîtrait pendant un certain temps après un don. Pour un particulier ce popup ne serait pas gênant mais dans une entreprise quand le logiciel est sollicité à maintes reprises cela peut devenir gênant. Malheureusement,je pense qu'il faut forcer un peu pour avoir une contribution qui serait méritée. Marco
Même s’il m´est arrivé de faire des PR avec correctif de bugs qui sont restées sans réponse, je suis 100% d’accord avec Carl. Mes projets FOSS sur Github ne sont pas bien populaires mais lorsque je reçois une PR avec soit correction de bug soit ajout de fonctionnalité, je m’efforce toujours de remercier.
En effet, article intéressant… même si sous certains aspects, il peut sembler réducteur.
Quoiqu'il en soit, actuellement, personnellement, je contribue d'une manière différente, sur un projet qui aux antipodes de mes intérêts. Et, cela me surprend moi-même, d'autant que je suis capable de gérer du code shell… car ce n'est même pas du code que je fais, mais de la participation à la documentation du projet. Alors, certes je ne le fais pas tous les jours, pour des raisons personnelles, mais assez régulièrement. Ce projet est #play.it - pour les jeux sous Linux. Ce qui m'est sûr, c'est que j'apprécie de pouvoir le faire, d'autant que @vv222 est très compréhensif, et amical.
Ensuite, j'ai quelques développements en suspens… je sais qu'il y en a un qui attend un correctif… mais je suis agréablement surpris de recevoir une petite contribution financière par le biais de liberapay, semaine après semaine… quoique celle-ci est peut-être pour ma participation active au projet obsd4a (administration, traduction inofficielle de la FAQ OpenBSD sur le wiki, etc…) !
Alors, oui, y'a plusieurs moyens de participer à un projet ou l'autre… et de le faire dans la bonne humeur ;)
[Comment from banned user removed]
https://www.journalduhacker.net/c/xqgp7d
Tcho !
Je suis totalement d'accord sur le fait que beaucoup d'utilisateurs le font en temps que consommateurs (souvent par ignorance du modèle FOSS, j'ai vu y'a pas longtemps, quelqu'un qui pensait que libreoffice, était une version de M. office gratuite et light).
Autrement, en lisant l'article, j'ai eu l'impression que tu disais que la remonté de bug n'était pas considérer comme une contribution, alors que pour moi, c'est la première contribution, et surement la plus importante.
Personnellement, j'essai de contribuer au maximum, mais quotidiennement, c'est impossible. Quand c'est possible, et que mes faibles compétences en devs le permets, je peux ajouter des features et/ou faire de la correction de bug. Sinon sur github, je star, et si bug il y a, je remonte. Je ne fais pas de documentation, car je n'ai pas un niveau rédactionnel très élevé. Pour ce qui est des dons, c'est plus compliqué (pas une question d'argent), car la je me base plus sur le comportement des devs, leurs relationnel, que sur le code ou le soft lui même, si le mec réclame un don dès qu'on lui remonte un bug, ou prends les gens de haut, il n'aura jamais un don de moi.
++