Alors j'ai sans doute été un peu vite vu que j'ai sauté des étapes. Je vais donc commencer par poser les termes et expliquer plus clairement la différence entre "codeur" et "utilisateur"
Dans mon argument, il faut vor ça comme des classes (au sens de Marx, pas au sens de Stroustrup), et pour simplifier, il s'agit de 2 identités séparées (bien sur, je sais que la vie réelle est plus compliquée).
Je vais qualifier de codeur la personne qui a la capacité technique de toucher au code, donc de le comprendre, de le modifier, d'en faire quelque chose. Et je vais qualifier d'utilisateur tout le reste, en supposant une utilisation (les gens qui n'utilisent pas un logiciel et qui ne codent pas sont hors scope dans le cadre de la démonstration).
Comme c'est une abstraction et une simplification, je vais pas rentrer dans les détails des compétences pour utiliser, dans les trucs hybrides comme un logiciel pour codeur, comme le fait que même les codeurs connaissent pas tout, etc, etc. Juste une pur abstraction avec des vaches sphériques dans le vide, et du code dans un seul langage dont la connaissance implique d'être dans la classe des codeurs, qui sont tous sur-compétent.
Maintenant que j'ai posé les bases, regardons les 4 libertés du logiciel libre tel que théorisé par RMS et qui sont un peu la base de la philosophie du libre:
- liberté 0, exécuter le programme via son code pour tout les buts.
- liberté 1, étudier le code du programme.
- liberté 2, distribuer le programme et/ou son code.
- liberté 3, modifier le programme via son code.
Jusqu'ici je pense que j'ai perdu personne.
Et le cœur de mon analyse se base sur la répartition du "pouvoir" (au sens sociologique, en l’occurrence, savoir quelle classe "peut" faire plus de choses, donc a plus de libertés).
Sur les 4, je dirais que la 1 et la 3 nécessitent d'avoir des compétences de codeur. Si tu ne comprends pas le code (eg, dans la classe "utilisateur"), l'étudier n'apporte rien en tant que tel, sauf à passer dans la classe codeur.
Et si tu ne comprends pas le code, alors le modifier est aussi impossible, sauf encore une fois à devenir codeur par la définition même de la classe.
La liberté 2 est plus nuancé, dans le sens ou effectivement, elle s'applique aux deux classes, mais c'est bien via la liberté 3 que la liberté 2 prends tout son sens, donc j'estime qu'elle donne plus de "pouvoir" à la classe codeur qu'à l'autre..
Et il reste la 0, qui va bénéficier aussi bien aux gens de la classe codeur que de la classe utilisateur.
Bilan, les 4 libertés fondamentales du libre bénéficient plus aux gens de la classe codeur de manière direct tandis que la classe utilisateur n'a que des bénéficies totales moindres des 4 libertés, et va être en situation de dépendance de l'autre classe.
Il y a pour moi une situation d'inégalité dans le sens ou la classe des codeurs a plus d'autonomie que la classe des utilisateurs. Et d'ailleurs, tu le dis toi même, l'utilisateur peut se barrer si le codeur refuse quelque chose, mais il doit soit devenir codeur, soit dépendre d'un autre codeur.
Comme l'a dit Anatole France dans son roman Le Lys Rouge: "Ils y doivent travailler devant la majestueuse égalité des lois, qui interdit au riche comme au pauvre de coucher sous les ponts, de mendier dans les rues et de voler du pain."
La, c'est pareil, la majestueuse égalité de la GPL permet à la personne qui connaît le C et celle qui ne le connaît pas de modifier le noyau Linux.
Ensuite, je ne dit pas que c'est bien ou mal, je fait juste un constat, et je ne pense pas qu'on puisse faire mieux (en tout cas pas via la licence). Mais je fait ce constat sur les bases de la philosophie du libre pour expliquer mon point indiquant que venir parler implicitement de démocratie (via "L’ouverture d’une concertation réelle et transparente" du billet du CNLL), c'est quand même un peu du bullshit quand les communautés du logiciel libre tienne plus d'une forme de feodalisme que d'autres choses.
Et encore, l'article que je pointe cite Debian comme une démocratie, mais il n'y a que les DD (eg, une minorité) qui peuvent voter. Donc c'est une démocratie tout comme Athènes était une démocratie, malgré le fait qu'elle interdisait le droit de vote à plus de la moitié de sa population (cad aux jeunes, aux femmes, aux esclaves et aux métèques/barbares).
On passera sur le "volontariat" (travail bénévole) probablement minoritaire aujourd'hui vu le nombre de projets maintenus par des salarié·es,
Mais ça ne change rien. Si tu regardes le blog de Daniel Steinberg sur les rapports de bugs et les LLM, et les commentaires qui ont suivis comme celui la ou ça parle de "gacher le temps du mainteneur", je pense que la majorité des gens vont être de l'avis du mainteneur de curl (à savoir qu'il faut pas soumettre des rapports de merde). Pourtant, il est à temps plein sur curl depuis 2019 d’après sa propre page web. Plus récemment, il y a un article de Drew Devault sur les crawlers qu'il doit gérer (alors qu'il est à temps plein sur son entreprise). Et ça s'applique aussi aux crawlers sur Fedora (qui a une équipe d'admin à temps plein), à GNOME (qui a un admin à temps plein payé par la fondation), etc.
Le salariat ne change pas grand chose à ce niveau, on a toujours la perception qu'il ne faut pas gaspiller le temps, même des salariés (sauf bien sur quand on est du coté demandeur).
et sur le fait qu'on est beaucoup à être content d'avoir des retours utilisateurs
Ok, et du coup, est ce qu'il y a le moindre truc fait pour favoriser les dits retours ?
Parce qu'en plus de 20 ans de logiciel libre (dont plus de 10 chez un grand éditeur), j'ai rarement vu ça.
Je peux citer des initiatives qui m'ont marqué pourtant. Par exemple, Mandrakesoft avait le Mandrake club avec des votes sur les features vers le milieu des années 2000, (ce qui a poussé à intégrer le patch avec les lecteurs de CD LG). Ça a nourri un certain ressentiment assez visible par des groupes d'utilisateurs car personne ne faisait ce qui était demandé.
Mageia a tenté des choses, quand on a monté le board et la structure, je sais qu'on avait parler d'ajouter un poste de représentant des utilisateurs, mais je sais plus si c'est passé ou pas.
Ubuntu avait un système de vote/suggestion annoncé vers 2008/2009, Ubuntu Brainstorm. Il a fini par être abandonné, car personne ne voulait s'en occuper je suppose. Du coup, c'est passé sur Discourse, ce qui a le bon goût d'être supporté par d'autres, mais qui change sans doute pas grand chose.
Python a fini par créer une liste de discussion python-ideas ou la core team ne mets pas les pieds (cf l'aveu d'un membre que je connais), le but étant de donner un espace pour se débarrasser des lourds qui postent des idées sans arrêt sans jamais donner de patch.
Une grande partie des projets ou j'ai bossé mettent en place une séparation assez nette entre espace de discussion pour les devs, et espace pour le support (comprendre les utilisateurs), séparation qui s'accentue encore plus quand le support payant finance les devs.
Et de mon expérience, il y a assez rarement de circulation de l'un vers l'autre au moins dans les projets communautaires. En fait, les outils de support/feedbacks sont moisis dans ce domaine. Par exemple, les projets font le support via un chat ou il n'y a pas de ticket et/ou de fil, c'est juste tout le monde papote. De nos jours, ça va sur un forum (genre discourse), ce qui est mieux mais c'est non exploité car personne n'est jamais en charge de faire un compte rendu des plus gros soucis de la base utilisatrice. Si 30 personnes ont un souci, on va pas le savoir car on a pas de mécanisme pour dire "moi aussi" sur la première réponse, et on va juste demander aux gens d'aller chercher la réponse sans déranger plutôt que l'inverse.
Presque personne n'envoie des sondages corrects ou des demandes de feedback construites. On centralise jamais ce qui s'est mal passé dans une install party, savoir qui a galéré et ou, etc.
Quasiment personne ne fait des tests d'UX dans le libre (alors que je le dit depuis toujours, un salon pourrait servir à ça). Pour moi, on part vraiment de loin par rapport à ce qui se fait dans des structures plus commerciales (et c'est pas une question de moyen, mon employeur, un petit éditeur de logiciel libre avec 20000 personnes, ne le fait pas que je sache, en tout cas pas pour les projets communautaires sinon je l'aurais vu).
Donc ouais, on est content quand les gens nous parlent, mais faut bien reconnaître qu à part parler de temps en temps aux confs, c'est pas vraiment une priorité pour la grande partie de la communauté du logiciel libre, ou si c'est le cas, ça n'en a pas l'air.
[^] # Re: Violation du droit ?
Posté par Misc (site web personnel) . En réponse au lien Polytechnique et ministère de l'Éducation Nationale : le CNLL exige l'arrêt immédiat des migrations . Évalué à 3.
Alors j'ai sans doute été un peu vite vu que j'ai sauté des étapes. Je vais donc commencer par poser les termes et expliquer plus clairement la différence entre "codeur" et "utilisateur"
Dans mon argument, il faut vor ça comme des classes (au sens de Marx, pas au sens de Stroustrup), et pour simplifier, il s'agit de 2 identités séparées (bien sur, je sais que la vie réelle est plus compliquée).
Je vais qualifier de codeur la personne qui a la capacité technique de toucher au code, donc de le comprendre, de le modifier, d'en faire quelque chose. Et je vais qualifier d'utilisateur tout le reste, en supposant une utilisation (les gens qui n'utilisent pas un logiciel et qui ne codent pas sont hors scope dans le cadre de la démonstration).
Comme c'est une abstraction et une simplification, je vais pas rentrer dans les détails des compétences pour utiliser, dans les trucs hybrides comme un logiciel pour codeur, comme le fait que même les codeurs connaissent pas tout, etc, etc. Juste une pur abstraction avec des vaches sphériques dans le vide, et du code dans un seul langage dont la connaissance implique d'être dans la classe des codeurs, qui sont tous sur-compétent.
Maintenant que j'ai posé les bases, regardons les 4 libertés du logiciel libre tel que théorisé par RMS et qui sont un peu la base de la philosophie du libre:
- liberté 0, exécuter le programme via son code pour tout les buts.
- liberté 1, étudier le code du programme.
- liberté 2, distribuer le programme et/ou son code.
- liberté 3, modifier le programme via son code.
Jusqu'ici je pense que j'ai perdu personne.
Et le cœur de mon analyse se base sur la répartition du "pouvoir" (au sens sociologique, en l’occurrence, savoir quelle classe "peut" faire plus de choses, donc a plus de libertés).
Sur les 4, je dirais que la 1 et la 3 nécessitent d'avoir des compétences de codeur. Si tu ne comprends pas le code (eg, dans la classe "utilisateur"), l'étudier n'apporte rien en tant que tel, sauf à passer dans la classe codeur.
Et si tu ne comprends pas le code, alors le modifier est aussi impossible, sauf encore une fois à devenir codeur par la définition même de la classe.
La liberté 2 est plus nuancé, dans le sens ou effectivement, elle s'applique aux deux classes, mais c'est bien via la liberté 3 que la liberté 2 prends tout son sens, donc j'estime qu'elle donne plus de "pouvoir" à la classe codeur qu'à l'autre..
Et il reste la 0, qui va bénéficier aussi bien aux gens de la classe codeur que de la classe utilisateur.
Bilan, les 4 libertés fondamentales du libre bénéficient plus aux gens de la classe codeur de manière direct tandis que la classe utilisateur n'a que des bénéficies totales moindres des 4 libertés, et va être en situation de dépendance de l'autre classe.
Il y a pour moi une situation d'inégalité dans le sens ou la classe des codeurs a plus d'autonomie que la classe des utilisateurs. Et d'ailleurs, tu le dis toi même, l'utilisateur peut se barrer si le codeur refuse quelque chose, mais il doit soit devenir codeur, soit dépendre d'un autre codeur.
Comme l'a dit Anatole France dans son roman Le Lys Rouge: "Ils y doivent travailler devant la majestueuse égalité des lois, qui interdit au riche comme au pauvre de coucher sous les ponts, de mendier dans les rues et de voler du pain."
La, c'est pareil, la majestueuse égalité de la GPL permet à la personne qui connaît le C et celle qui ne le connaît pas de modifier le noyau Linux.
Ensuite, je ne dit pas que c'est bien ou mal, je fait juste un constat, et je ne pense pas qu'on puisse faire mieux (en tout cas pas via la licence). Mais je fait ce constat sur les bases de la philosophie du libre pour expliquer mon point indiquant que venir parler implicitement de démocratie (via "L’ouverture d’une concertation réelle et transparente" du billet du CNLL), c'est quand même un peu du bullshit quand les communautés du logiciel libre tienne plus d'une forme de feodalisme que d'autres choses.
Et encore, l'article que je pointe cite Debian comme une démocratie, mais il n'y a que les DD (eg, une minorité) qui peuvent voter. Donc c'est une démocratie tout comme Athènes était une démocratie, malgré le fait qu'elle interdisait le droit de vote à plus de la moitié de sa population (cad aux jeunes, aux femmes, aux esclaves et aux métèques/barbares).
Mais ça ne change rien. Si tu regardes le blog de Daniel Steinberg sur les rapports de bugs et les LLM, et les commentaires qui ont suivis comme celui la ou ça parle de "gacher le temps du mainteneur", je pense que la majorité des gens vont être de l'avis du mainteneur de curl (à savoir qu'il faut pas soumettre des rapports de merde). Pourtant, il est à temps plein sur curl depuis 2019 d’après sa propre page web. Plus récemment, il y a un article de Drew Devault sur les crawlers qu'il doit gérer (alors qu'il est à temps plein sur son entreprise). Et ça s'applique aussi aux crawlers sur Fedora (qui a une équipe d'admin à temps plein), à GNOME (qui a un admin à temps plein payé par la fondation), etc.
Le salariat ne change pas grand chose à ce niveau, on a toujours la perception qu'il ne faut pas gaspiller le temps, même des salariés (sauf bien sur quand on est du coté demandeur).
Ok, et du coup, est ce qu'il y a le moindre truc fait pour favoriser les dits retours ?
Parce qu'en plus de 20 ans de logiciel libre (dont plus de 10 chez un grand éditeur), j'ai rarement vu ça.
Je peux citer des initiatives qui m'ont marqué pourtant. Par exemple, Mandrakesoft avait le Mandrake club avec des votes sur les features vers le milieu des années 2000, (ce qui a poussé à intégrer le patch avec les lecteurs de CD LG). Ça a nourri un certain ressentiment assez visible par des groupes d'utilisateurs car personne ne faisait ce qui était demandé.
Mageia a tenté des choses, quand on a monté le board et la structure, je sais qu'on avait parler d'ajouter un poste de représentant des utilisateurs, mais je sais plus si c'est passé ou pas.
Ubuntu avait un système de vote/suggestion annoncé vers 2008/2009, Ubuntu Brainstorm. Il a fini par être abandonné, car personne ne voulait s'en occuper je suppose. Du coup, c'est passé sur Discourse, ce qui a le bon goût d'être supporté par d'autres, mais qui change sans doute pas grand chose.
Python a fini par créer une liste de discussion python-ideas ou la core team ne mets pas les pieds (cf l'aveu d'un membre que je connais), le but étant de donner un espace pour se débarrasser des lourds qui postent des idées sans arrêt sans jamais donner de patch.
Une grande partie des projets ou j'ai bossé mettent en place une séparation assez nette entre espace de discussion pour les devs, et espace pour le support (comprendre les utilisateurs), séparation qui s'accentue encore plus quand le support payant finance les devs.
Et de mon expérience, il y a assez rarement de circulation de l'un vers l'autre au moins dans les projets communautaires. En fait, les outils de support/feedbacks sont moisis dans ce domaine. Par exemple, les projets font le support via un chat ou il n'y a pas de ticket et/ou de fil, c'est juste tout le monde papote. De nos jours, ça va sur un forum (genre discourse), ce qui est mieux mais c'est non exploité car personne n'est jamais en charge de faire un compte rendu des plus gros soucis de la base utilisatrice. Si 30 personnes ont un souci, on va pas le savoir car on a pas de mécanisme pour dire "moi aussi" sur la première réponse, et on va juste demander aux gens d'aller chercher la réponse sans déranger plutôt que l'inverse.
Presque personne n'envoie des sondages corrects ou des demandes de feedback construites. On centralise jamais ce qui s'est mal passé dans une install party, savoir qui a galéré et ou, etc.
Quasiment personne ne fait des tests d'UX dans le libre (alors que je le dit depuis toujours, un salon pourrait servir à ça). Pour moi, on part vraiment de loin par rapport à ce qui se fait dans des structures plus commerciales (et c'est pas une question de moyen, mon employeur, un petit éditeur de logiciel libre avec 20000 personnes, ne le fait pas que je sache, en tout cas pas pour les projets communautaires sinon je l'aurais vu).
Donc ouais, on est content quand les gens nous parlent, mais faut bien reconnaître qu à part parler de temps en temps aux confs, c'est pas vraiment une priorité pour la grande partie de la communauté du logiciel libre, ou si c'est le cas, ça n'en a pas l'air.