Du difficile travail en association et en public

L’organisation de la promotion des logiciels libres dans un cadre associatif est une activité très enrichissante et intéressante, mais potentiellement lourde et épuisante. N'étant pas directement relative au travail des développeurs, elle n'est pas toujours reconnue par ces derniers.

Beaucoup d'organisateurs d’évènements le reconnaissent : ils manquent souvent de bras, de jambes et de têtes pour seconder et accompagner l’équipe principale. De plus, les équipes en charge font souvent appel à des soutiens locaux et de ce fait demeurent différentes suivant les lieux d'organisation. Pour pérenniser et faire voyager l'activité, il devient alors nécessaire d'assurer la transmission de l’information d'un lieu à l'autre et d’une année sur l’autre.

Voici des réfléxions et propositions pour essayer d’apporter des éléments de réponse à cela.

Travailler en public

Le logiciel libre fonctionne en grande partie sur la transparence des sources. Maintenant, il devient également possible de s'attacher à la transparence du processus complet du développement. On peut s’en rendre compte en suivant les listes de discussion du développement de nombreux projets, dont celle du noyau Linux. Le succès de la plateforme Github en est la parfaite illustration.

Ces espaces de collaboration deviennent avec le temps des zones d'informations privilégiées et ouvrent des perspectives nouvelles sur le processus de recrutement.

Assurer une pérennité

Les projets qui vivent bien prévoient de maintenir une continuité et cherchent à minimiser autant que possible les ruptures. Par exemple, le FOSDEM, la grande réunion annuelle de développeurs de logiciels libres qui se tient annuellement à Bruxelles au début du mois de février, maintient une liste de discussion publique active tout au long de l’année, à laquelle les participants peuvent souscrire. Et les archives sont librement accessibles et indexées par les moteurs de recherche.

Les informations diverses, appels à présentations, etc. y sont publiés, et les membres de la liste s’y attendent aux alentours du mois d’octobre précédent. Cela crée une fidélité.

Dans le cas de votre association, cela peut aussi aider à la transmission des informations par les membres du comité d’une année à l’autre.

Un seul wiki public principal permettrait d’y capitaliser l’information essentielle, ce qui a fonctionné et ce qui n’a pas fonctionné, ce qui est disponible d’une année à l’autre (matériel audio, vidéo, serveurs, matériel de promotion, avec les sources des fichiers…). Ceci n’empêche pas que chaque année il y ait en plus des outils et sites spécifiques, des moyens plus discrets, notamment pour des sujets délicats comme les questions financières.

Préciser des critères de sélection

Si les critères de sélection sont bien définis, à temps, avec des outils et méthodes claires, tout le monde sait à quoi s’attendre et peut calibrer le projet et les propositions par rapport à ces critères précis.

En plus, on pourrait utiliser des outils d’aide à la décision, discuter des pondérations et de la pertinence des critères, etc., et peut‐être participer au développement d’outils libres d’aide à la décision multicritère (le sujet m’intéresse, j’y ai consacré une partie de ma thèse de doctorat !).

Par la transparence, encourager la participation

Et si le comité posait la question en public, de savoir où les personnes intéressées préféreraient aller ? Dans le genre discussion, puis référendum. Le comité expose les possibilités, fait un joli tableau comparatif des propositions des différentes villes candidates qui parleraient aussi, si possible en public, présente les critères de choix, laisse tout le monde commenter publiquement, propose aux candidats de contribuer et invite les personnes intéressées par le processus de sélection à participer. Bien sûr, la décision finale est du ressort du comité. Mais cela se passe ouvertement, en public.

Cela aurait peut‐être l’avantage de la transparence, de la participation et mettrait en évidence des attentes qui ne sont pas claires pour tous, ou pas primordiales ou justement qui manquent, pour le comité et les candidats.

En plus, cela impliquerait les personnes intéressées qui pourraient dans tous les cas servir aussi de relais, et leur permettrait de participer plus volontairement, tout en évitant certains oublis ou réactions pas assez rapides !

Débattre

Voilà quelques propositions à discuter, étendre, et sûrement à débattre.

« Release early, release often » proposait en 1997 le hacker connu Eric S. Raymond dans La Cathédrale et le Bazar. Et si on le faisait aussi pour le processus de sélection des RMLL/WLSM ?

Aller plus loin

• Liste de discussion publique des RMLL (113 clics)
• Le site du comité des RMLL (31 clics)
• Aide à la décision multicritère (55 clics)
• Un logiciel gratuit d’aide à la décision… mais pas libre (91 clics)