Quand bien même on en trouverait et qu’illes seraient motivé⋅e⋅s, je continue de ne pas encore savoir ni comprendre quand est-ce que ces gens vont pouvoir contribuer à tel projet, mis à part sur leur temps personnel et familial. La question du #temps de contribution est pour moi essentielle.
Quand on est issu d’une culture geek, et que l’on fait surtout du code, il parait normal de contribuer à des projets aussi bien sur son temps de travail, qu’en dehors, la nuit, en mangeant des chips.
Lorsque l’on a pas cet état d’esprit, et que le soir ou le week-end (1) on préfère plutôt jouer avec son enfant, lire des livres, faire du vélo, cuisiner, jongler, militer ici ou là, et bien le SEUL moment où l’on peut contribuer à des logiciels libres c’est : sur le temps de travail salarié ou assimilé.
Et excusez-moi de la découverte, mais c’est d’ors et déjà ce qui se passe dans une grande partie (la plupart ?) des projets libres un peu gros, même en ne parlant que du code fonctionnel.
Or, pour quelqu’un qui ajoute un module fonctionnel, il est relativement facile de faire en sorte que cette fonctionnalité soit payée par des gens, tout en la publiant en licence libre une fois terminée, car une fonctionnalité est assez souvent générique, peut servir à d’autres.
En revanche, de-nos-jours-pour-l’instant, à peu près aucune entreprise ou collectivité ne va payer pour améliorer l’ergonomie d’un logiciel déjà existant. Elles vont payer pour leur charte graphique à elles. Elles vont payer pour l’ergonomie de leur site internet ou de leur module métier qui est unique et propre à elles.
Dans ces cas-là, les améliorations d’ergonomie, de lisibilité, de navigation, sont souvent le fait de francs-tireur⋅euse⋅s hyper-rares, qui parfois arrivent à trouver le temps de modifier l’UX d’un logiciel.
Mais ça veut dire qu’on ne compte que sur des exceptions, alors que pour le code fonctionnel beaucoup plus de monde arrivent à contribuer sans être geek, sans être étudiant, et sans nuire à leur vie sociale.
S’il est besoin, on peut essayer de donner des cas concrets. (2)
(1) Je reprends ici la temporalité de la majorité, je sais bien que certains n’ont pas la même organisation du temps.
(2) Mais ne serait-ce que dans #SPIP (forcément), on voit bien la différence entre corrections de bugs et ajouts fonctionnels d’un côté / amélioration générale de l’admin et refonte de la documentation-communication de l’autre.