J’ouvre ce sujet pour parler du packaging de Duniter v2 qui à mon avis a une importance stratégique dans l’adoption de l’outil auprès d’un large public.
Retour d’expérience sur Duniter v1
Mes connaissances et compétences ont beaucoup évolué depuis, mais je me souviens de mes débuts dans Duniter v1. À l’époque, de manière générale pour les logiciels libres :
- je ne considérais même pas l’option d’utiliser un logiciel s’il n’avait pas de paquet debian ou d’exécutable précompilé pour ma machine (OS, architecture)
- les projets qui présentaient docker comme solution de packaging privilégiée me repoussaient vivement (j’avais été assez influencé par cet article de blog de @aeris à l’époque)
L’existence d’un paquet debian Duniter pour architecture ARM a donc joué en faveur du logiciel alors que je le découvrais. Même si la situation a évolué depuis, je pense que publier plusieurs paquets différents reste très important d’un point de vue expérience utilisateur.
note : ici “utilisateur” désigne les utilisateurs directs de Duniter, c’est-à-dire les hébergeurs de nœuds forgerons et miroir, pas les utilisateurs indirects qui utilisent le Duniter de quelqu’un d’autre via les applis client
Donner d’abord pour espérer recevoir
Si l’on voit le logiciel comme un commun numérique, et que l’on espère que les utilisateurices viennent vers nous pour suggérer des modifications, il me semble important de montrer notre bonne volonté en faisant le premier pas vers elleux, c’est-à-dire en rendant le logiciel aussi facile à prendre en main que possible.
La documentation est évidemment une étape indispensable, mais les étapes documentées doivent être lissées au maximum, et les points qui ne sont pas couverts par la documentation doivent être clairement explicités et doivent rediriger vers des ressources externes.
Cela passe par le fait d’adopter une attitude généreuse “voici le paquet que nous avons fait pour vous” plutôt qu’accusatrice “t’as qu’à compiler toi-même”. Et quand on ne répond pas au besoin de l’utilisateur qui souhaite tel ou tel packaging (flatpack, snap…), plutôt chercher à comprendre le besoin et le visibiliser (du genre “xxx package n’est pas disponible, mais une contribution est bienvenue”) plutôt que de rembarrer dans le genre “t’as qu’à contribuer si t’es pas content”.
Tout ça peut paraître évident, mais comme dirait quelqu’un :
Voilà pour la partie stratégie. Pour la partie concrète cf les posts suivants :