Mais surtout, l'article ignore pour moi un problème de fond qui limite fortement le nombre de contributions : la plupart des projets sont inaccessibles au commun des autres devs.

Combien de projets ont des README ? Une documentation lisible, bien structurée et à jour ? Des instructions d'installation claires (en développement) ? Des informations de contact autres qu'IRC ?

Des informations sur comment lancer les tests (quand il y a des tests) ? Une CI ? Du tooling pour réduire la barrière à l'entrée sur le déploiement ? Des instructions sur comment contribuer (et pas que au dev) ?

Quand tu démarre un projet, ça fait partie de ta responsabilité de penser à ça et de mettre en place ce qu'il faut. Ou alors, il ne faut pas venir râler que personne ne participe.

Un projet ce n'est pas juste le code, c'est le code plus tout ce qui permet aux autres d'y accéder, de l'utiliser, de le comprendre, de l'améliorer, etc.

Cet espèce de reproche que les utilisateur·ices sont passifs, ça me fait un peux penser aux discours en mode « non mais les gens participent plus à la vie démocratique du pays ». Quand tu vois comment c'est fait, ça donne pas spécialement envie...

Ensuite, la plupart des projets n'ont pas de feuille de route définie ou explicite et publiquement accessible. Ça veut dire que les contributions externes ne peuvent être que ponctuelles et sur des points de détail.

Personne ou presque ne va prendre le risque de faire une grosse contribution sur un projet sans savoir si cela va plaire à celleux qui maintiennent, si cela n'entre pas en conflit avec d'autres developpements, etc.

Et les rapports de bugs, c'est bien gentil (et utile, je ne le nie pas), mais là aussi, écrire un rapport de bug qui soit pertinent et utile, c'est une démarche qui prend du temps.

Et un bug tracker, ça se maintient : tagguer les issues, commenter, organiser, fermer les doublons, faire des liens, etc.

Quand des personnes assez motivées pour écrire un rapport de bug tombent sur un truc avec 800 tickets pas catégorisés, avec une recherche pourrie, le premier réflexe c'est de fermer la fenêtre et de se dire « je laisse tomber, quelqu'un d'autre à déjà du le rapporter).

Tout ça, ça s'entretient, il faut offrir des templates de rapports, pour faire gagner du temps et de l'énergie, et accepter d'ouvrir les tickets soi même par moment

Et si quelqu'un est assez motivé pour faire une contribution, ouvrir une Pull Request sur le projet, encore faut il faire une revue rapide, utile et pertinente, expliquer les améliorations possibles, voire refuser en expliquant pourquoi, etc.

Quand on voit le ton et la culture pourrie dans pleins de projets, ça ne donne juste pas envie de passer par tous ça.

Un projet, ça s'anime. Et si personne ne contribue, ou pas suffisamment, c'est à la personne (ou les personnes) impliquées de mettre en place l'environnement (technique, culturel, organisationnel, etc.) pour que ça change.

Traiter les autres de consommateurs parce qu'ils n'ont pas envie de se heurter à tous les obstacles que tu as placé (volontairement ou non) sur leur chemin, c'est se tromper de problème.

Donc voilà, je trouve ça hallucinant qu'en 2018, on en soit encore à raisonner comme ça, et à être dans le reproche et l'antagonisme permanent pour essayer de faire contribuer les gens.

Quand on leur fait confiance et qu'on leur donne les moyens, les gens sont généralement ravis d'aider dans la mesure de leurs possibilités.

Je m'arrête là, merci de m'avoir lu.

@eliotberriot +1 à tout ça, y compris au ton de l'article qui est assez détestable.
La caricature, le cliché, ça ne passe pas du tout.

@eliotberriot
tout a fait d'accord avec ça.
Il faut aussi que les devs prennent conscience que les personnes qui ouvrent des tickets sont des contributeurs plus que des utilisateurs.
Quand je vois des dépôts avec des tickets fermés du jour au lendemain sans aucune explication, ou alors laissé sans réponse pendant plus de 6 mois, ça ne donne pas très envie.

@lthms @roipoussiere les commentaires sur lobste.rs sont très intéressants. Celui ci particulièrement je trouve : https://lobste.rs/s/iratx6/foss_passive_consumerism_kills_our#c_sdvmlp

> The nature of contribution is not transactional in nature. Since it’s a community, in theory, giving back to a single FOSS project is like contributing to each one of them.

On est pas obligé d'avoir une réciprocité permanente pour chaque truc qu'on utilise

@eliotberriot @lthms @roipoussiere il y a du vrai dans l'article mais il vrai que le manque de doc, de contact ou clarté sont souvent un frein.
Après je suis d'accord avec le fait qu'un utilisateur qui ouvre des tickets est un contributeur comme un autre même s'il ne touche pas au code. @kaiyou pourra le dire je n'ai pas contribué côté code mais côté ticket ou code j'ai plutôt bien aidé ou encore en répondant à des questions sur comment fonctionne ceci ou cela et c'est important aussi.

@roipoussiere
Ou marqué c'est un troll (je l'ai de travers celle là) https://github.com/tootsuite/mastodon/issues/8229#issuecomment-414069242
@eliotberriot

@roipoussiere @eliotberriot
Mouais, plus facile à dire qu'à faire.

J'avais exactement le même discours (qui a du sens) avant de me cogner à la réalité : maintenir plusieurs projets est épuisant et incroyablement chronophage.

A un moment, tu peux être totalement épuisé et ne plus arriver à suivre.

@Nico3333fr @roipoussiere complètement d'accord, c'est l'idéal et en pratique il faut des ressources énormes pour faire ça bien.

Mais du coup, il n'y a aucune raison de dire que c'est la faute des personnes qui utilisent ton projet si toi même tu n'est pas en mesure de faire ça.

@eliotberriot @roipoussiere je pense qu'il y a une différence entre contributeur et utilisateur.

Dans mon xp perso, les contributeurs sont majoritairement charmants et géniaux.

Côté utilisation, c'est parfois la croix et la bannière pour avoir un simple respect de licence (une mention, etc.), et parfois y a des comportements un poil abusés. J'imagine que c'est ce dont parle l'article.

@eliotberriot @roipoussiere
Y a un moment, quand tu mets à dispo un truc gratuit qui permet de gagner du temps voir de faire du fric, je peux comprendre que celui ou celle qui maintient gracieusement en ait marre et veuille un petit retour d'ascenseur.

D'ailleurs, la plupart ne demandent pas plus.

@Nico3333fr @roipoussiere l'article dit que ne pas contribuer régulièrement (quotidiennement) aux logiciels que l'on utilise va tuer le FOSS ou lui nuire.

Ça passe complètement à côté de la situation de plein de personnes qui n'ont pas le temps ni l'énergie ni la disponibilité ni les compétences pour contribuer (et ce n'est pas grave !)

@Nico3333fr @roipoussiere et on en revient à la contradiction : si tu fais un truc gratuit pour ton utilisation perso, tu ne peux pas t'attendre à recevoir des torrents de contributions.

Et si tu veux recevoir des contributions, tu dois mettre en place ce qu'il faut pour inciter les personnes à contribuer.

@eliotberriot haaaa c'est tellement important de souligner ça. Tu penses faire ce retour en commentaire sous l'article ?

@gordon ça a été suggéré, j'ai rajouté le lien vers le thread dans les commentaires ;)

@eliotberriot L'auteur est connu pour tenir un discours alarmiste depuis quelques années déjà. J'ai déjà eu l'occasion de le rencontrer. Un type très sympa par ailleurs mais qui tient un discours avec lequel je suis aussi en désaccord. En particulier l'alarmisme dont il fait preuve sur la fin annoncée des logiciels libres.

@AugierLe42e c'est vrai que ce n'est pas le premier article que je vois sur son blog sur cette thématique ou avec ce ton

@eliotberriot J'ai, pour ma part, un point de vue plus sociologique sur la question. Je pense que les LL existent parce qu'ils ont une fonction societale (le besoin de partager la connaissance dans une société). De fait, rien ne peut provoquer sa fin car son destin est intimement lié à celui de la société même.

@AugierLe42e c'est intéressant comme analyse, ça rejoint un peu les questions de bénévolat : est-ce que les gens font moins de travail bénévole (volontairement j'entends) maintenant qu'il y a 10 ans ou 5 siècles ?

Je n'ai pas l'impression, au contraire

@eliotberriot Moi non plus, je n'ai pas l'impression. Le partage, que ce soit de connaissance (LL/Wikipedia) oubde compétence (bénévolat), est le fondement d'une société. C'est la raison même pour laquelle la structure sociétale existe (faire communauté pour partager).

@eliotberriot Merci, j’avais tellement la flemme de critiquer cet article tellement y a trop de trucs à dire dessus

@eliotberriot
D'ailleurs toujours aucun moyen de t'aider financierement? Parce que Liberapay ca marche plus

@adidal j'attend toujours la réponse d'OpenCollective pour l'activation de la page de Funkwhale : https://opencollective.com/funkwhale

Je vais les relancer cette semaine

@adidal J'avais cru comprendre que @Liberapay fonctionnait à nouveau, avec un nouveau prestataire de paiement (Stripe), ce n'est pas le cas ?

@eliotberriot

@nicod_ @adidal @eliotberriot

Ceci est correct. LiberaPay fonctionne avec Stripe, et un support de PayPal devrait arriver probablement bientôt. Puis d'autres options de paiement sont envisagées pour être intégrées.

@eliotberriot
La CI est de nos jours généralement inclue quand tu forkes : travis, gitlab-ci…

@eliotberriot

C'est un peu la poule ou l’œuf cette histoire. Pour avoir des contributeurs il faut des gens pour communiquer et documenter...

Perso je suis rémunéré pour faire ce job pour le #logiciellibre @communecter. Pas sûr que tous les projets #opensource puissent se le permettre...

https://wiki.communecter.org/fr/

@drakone @communecter le projet est quand même là avant les contributeur·ices normalement ;)

@eliotberriot @communecter

L'holoptisme et plus particulièrement la documentation est un métier. Même si les devs peuvent clairement faire un effort.

Au #CommonsCamp nous avons fait un atelier #SynergieNumérique. Un des projets qui en ai sorti est de faire de l'échange de pratique entre projet #opensource sur la manière dont chacun arrive à trouver de nouveaux et nouvelles contributrices.

http://synergie-numerique.initiative.place/

@eliotberriot Le README ? Beaucoup. Je pense que je peux compter sur les doigts des deux mains le nombre de projets libres sans README que j'ai croisé.
La doc lisible… oui, y a des efforts à faire. Bien structurée ? Tout le monde n'a pas la même idée d'une bonne structure, je pense. À jour ? C'est compliqué 😛

@framasky on a pas la même expérience alors. Je croise régulièrement des projets sans readme, ou avec des readme incomplets / inutiles.

@eliotberriot
Je dois avoir de la chance ou une mauvaise mémoire 😂

@eliotberriot Ha ! Je ne suis pas la seule personne à être gênée ou choquée ! Merci.

@nlavielle je t'en prie, j'avais un peu de temps ce midi pour écrire là dessus :)

@eliotberriot
s’il te reste une minute, tu pourrais joindre tes récents pouets sur le sujet et les mettre en commentaire du billet de blog ;-)

@nlavielle

@goofy e ne sais pas trop, ça fait un peu too much non ?

@eliotberriot ben non ça enrichirait le débat à un endroit plus "visible" qu’un thread mastodon, mais c’est toi qui vois

@goofy c'est fait :)

@goofy @eliotberriot Vu le ton employé par l'auteur, je ne suis pas sûr·e qu'Eliot soit très chaud :) !

@nlavielle @eliotberriot

Merci !👍

@eliotberriot
Je pense qu'il faut voir le consommateur professionnel, qui utilise le logiciel/la lib comme une brute, pas l'utilisateur final. Exemple typique : openssl utilisé partout, et le gars galère tout seul sans rien recevoir… jusqu'à heartbleed 🤷