J’ai l’air bête, j’ai publié dans la mauvaise liste.
Cela dit le lien du post (https://bzg.fr/logiciel-produit-projet/) donne
bien maillto:~bzg/dev@lists.sr.ht…
-------- Forwarded Message --------
Subject: [Tout logiciel libre est un produit et un projet] Effet
délétère, modèle économique et effets délétères ?
Date: Thu, 12 Dec 2024 00:43:51 +0100
From: lvgn <lvgn@lvgn.xyz>
To: ~bzg/dev@lists.sr.ht
C’est marrant, je n’avais jamais fait attention à cette distinction.
Notamment, j’avais vu quelqu’un aller à l’extrême de GitHub disant
qu’aujourd’hui un logiciel n’est libre que s’il est empaqueté avec
docker et déployable en un clic (impossible de remettre la main sur
cette prise de parole). Ça ne m’avait pas l’air vraiment réfléchi comme
remarque, mais du coup ça reflète bien l’effet « GitHub mélange tout » ;
un effet délétère. ;-)
Ce que cette distinction m’amène surtout à penser, c'est le potentiel
modèle économique. En effet, on peut faire du logiciel libre, en ne
donnant qu’un simple tar.gz, sans historique, sans issues, sans
gouvernance, sans packaging, etc. et faire payer pour accéder à tout ça.
Deux exemples différents :
1. Peut-être que j’ai halluciné parce que maintenant leur code est
disponible (https://github.com/odoo/o-spreadsheet), mais il y a quelques
années lorsque j’avais regardé, il y avait un dépôt GitHub avec presque
rien dedans si ce n’est un peu de doc, et des éléments disparates sans
trop de sens. Si on voulait le code source, il fallait souscrire
l’abonnement (gratuit ou payant) et faire la demande par mail. Ils
envoyaient alors une archive du code source.
2. Ardour (https://community.ardour.org/download) sous GPL-v2 fait payer
l’empaquetage du logiciel pour les différentes plateformes, mais le code
source est facilement accessible tant sur GitHub que sur leur plateforme
https.//git.ardour.org, ainsi que les issues sur
https://tracker.ardour.org, la documentation, et accepte les contributions.
Et on pourrait aller plus loin dans cette conception d’un modèle
économique : faire payer pour le support (déjà fait et accepté), pour la
documentation (je ne connais pas de cas, probablement moins accepté), ou
bien pour créer des issues, voire pour pouvoir proposer des merges
requests. En revanche, sur ces deux derniers cas, je ne suis pas sûr du
bénéfice. C’est un peu se tirer une balle dans le pied : faire du
logiciel libre et limiter les contributions en ajoutant beaucoup de
frictions ?
Pourtant, je peux imaginer des cas où cela a un intérêt. Par exemple sur
de gros projets qui ont déjà acquis une notoriété, il est plus
intéressant que sa contribution soit acceptée en amont, quitte à payer,
plutôt que de se lancer dans la création d’un fork et tout ce qui vient
avec (on en revient toujours à ce /risque de fork/).
Sur cet aspect modèle économique, tu écris la chose suivante :
> une tension inhérente à tout logiciel libre : d'un côté les coûts de
> distribution du produit sont quasi-nuls, mais de l'autre, l'énergie à
> dépenser pour maintenir le projet est élevée.
Ça me fait beaucoup penser aux conclusions du livre de Nadia Asparouhova
(/Working in Public: The Making and Maintenance of Open Source Software/
https://nadia.xyz/open-source/). Elle le dit, le modèle GitHub 1)
mélange tout, 2) fait du mal aux communautés, puisque la friction pour
la contribution a été drastiquement réduite, rendant la maintenance des
projets fastidieux et très couteuse /attentionnellement/ (économie de
l’attention). Elle propose donc d’ajouter de la friction sur cet aspect
maintenance (que toi, tu appelles *le projet*) pour les rendre plus
sains et plus viables.
Ce modèle économique pourrait être un moyen d’ajouter de la friction
pour réduire les coûts /attentionnels/ et capitaliser dessus pour la
bonne tenue du projet.
Cependant, avec cette vision minimaliste des 4 libertés très
Stallmanienne, est-ce que l’on ne va pas à l’encontre même du mouvement
du logiciel libre ? Oui, on respecte bel et bien les 4 libertés, mais à
ajouter autant de friction pour qu’une petite élite puisse être la seule
à participer au projet, on empêche « le partage avec les autres. »[1] Je
me demande si on ne déborde pas. Cette vision minimaliste est à dépasser ?
Je ne sais pas. Je raconte peut-être n’importe quoi. Il est tard. Je
vais me coucher.
[1] https://www.gnu.org/gnu/manifesto.fr.html
--
https://liber-it.fr
lvgn <lvgn@lvgn.xyz> writes:
> J’ai l’air bête, j’ai publié dans la mauvaise liste.
Pas du tout, l'erreur venait de la configuration de mon blog qui
pointait effectivement vers la mauvaise liste...
> Cela dit le lien du post (https://bzg.fr/logiciel-produit-projet/)
> donne bien maillto:~bzg/dev@lists.sr.ht…
Merci d'avoir vu ça !
Tes remarques m'ont incité à rajouter une section à l'article, en
espérant qu'il ne soit pas devenu trop long et lourd.
> Deux exemples différents :
>
> 1. Peut-être que j’ai halluciné parce que maintenant leur code est
> disponible (https://github.com/odoo/o-spreadsheet), mais il y a
> quelques années lorsque j’avais regardé, il y avait un dépôt GitHub
> avec presque rien dedans si ce n’est un peu de doc, et des éléments
> disparates sans trop de sens. Si on voulait le code source, il fallait
> souscrire l’abonnement (gratuit ou payant) et faire la demande par
> mail. Ils envoyaient alors une archive du code source.
Si on n'a pas accès au code source, le logiciel n'est pas libre car il
est alors de facto impossible de le modifier. Voir les souci avec Red
Hat qui a fait un move du même genre l'année dernière.
> Et on pourrait aller plus loin dans cette conception d’un modèle
> économique : faire payer pour le support (déjà fait et accepté), pour
> la documentation (je ne connais pas de cas, probablement moins
> accepté), ou bien pour créer des issues, voire pour pouvoir proposer
> des merges requests. En revanche, sur ces deux derniers cas, je ne
> suis pas sûr du bénéfice. C’est un peu se tirer une balle dans le
> pied : faire du logiciel libre et limiter les contributions en
> ajoutant beaucoup de frictions ?
On peut aussi ne pas accepter de contribution... par choix :
https://grisebouille.net/lhdg13-le-libre-doit-il-etre-communautaire/
> Sur cet aspect modèle économique, tu écris la chose suivante :
>
>> une tension inhérente à tout logiciel libre : d'un côté les coûts de
>> distribution du produit sont quasi-nuls, mais de l'autre, l'énergie
>> à
>> dépenser pour maintenir le projet est élevée.
> Ça me fait beaucoup penser aux conclusions du livre de Nadia
> Asparouhova (/Working in Public: The Making and Maintenance of Open
> Source Software/ https://nadia.xyz/open-source/).
Oui ! J'ai ajouté la référence en NB de l'article.
> Elle le dit, le modèle GitHub 1) mélange tout, 2) fait du mal aux
> communautés, puisque la friction pour la contribution a été
> drastiquement réduite, rendant la maintenance des projets fastidieux
> et très couteuse /attentionnellement/ (économie de l’attention).
> Elle propose donc d’ajouter de la friction sur cet aspect
> maintenance (que toi, tu appelles *le projet*) pour les rendre plus
> sains et plus viables.
Pour rendre à César, il faut aussi rappeler que c'est GitHub qui a
popularisé Git, et, sûrement, « l'open source » - je suis le premier à
taper dessus, mais tout de même :)
> Cependant, avec cette vision minimaliste des 4 libertés très
> Stallmanienne, est-ce que l’on ne va pas à l’encontre même du
> mouvement du logiciel libre ? Oui, on respecte bel et bien les 4
> libertés, mais à ajouter autant de friction pour qu’une petite élite
> puisse être la seule à participer au projet, on empêche « le partage
> avec les autres. »[1] Je me demande si on ne déborde pas. Cette vision
> minimaliste est à dépasser ?
>
> Je ne sais pas. Je raconte peut-être n’importe quoi. Il est tard. Je
> vais me coucher.
Pas du tout, c'est le coeur du sujet « militant » - je n'ai pas voulu
trop étirer l'article... je pense qu'on peut combiner clarté dans les
définitions (du logiciel libre) et ambition dans les objectifs (aller
vers plus de liberté _réelle_) et qu'il faut effectivement rester bien
attentifs à ne pas faire que servir une petite communauté de geeks...
--
Bastien Guerry