Saint-Étienne, le 28 avril 2022
En Open Source, des briques logicielles essentielles dépendent de leurs développeur⋅ses, dont le travail n’est pas toujours visible ni reconnu. Quels sont leurs besoins ? Comment les soutenir ? Nous tentons de répondre ici, à partir du point de vue de Damien Clochard, contributeur à la communauté PostgreSQL.
L’exemple de PostgreSQL Anonymizer
PostgreSQL Anonymizer est une extension qui cache, voire remplace, les données personnelles ou sensibles dans une base PostgreSQL. Elle a été créée par Damien en 2019, alors que le RGPD continuait de s’imposer à toutes les organisations.
Selon Damien, la phase intiale d’un projet implique surtout des choix structurels, chaque modification y est rapide et visible. Puis, c’est le « syndrome du chantier » à l’approche de la première version majeure, où l’on passe beaucoup de temps à affiner le code. Outre l’aspect peu gratifiant de ce travail, chaque modification demande la plus grande vigilance, surtout si l’outil est déjà utilisé.
Damien est actuellement dans cette phase-là avec PostgreSQL Anonymizer, dont la sortie de la v.1 est imminente.
Un projet logiciel implique forcément des difficultés, et pour faciliter son développement, nous avons identifié les conditions favorables suivantes :
- les apports des utilisateur⋅rices,
- le soutien d’une entité,
- du temps planifié.
Développer avec les équipes utilisatrices
L’objectif principal est de satisfaire leurs besoins au mieux. Après la version bêta, il s’agit pour le/la développeur⋅se de respecter un « contrat moral », un engagement fort, et il est attendu qu’il/elle aille plus loin que le traitement des bugs.
Ainsi, un cadre collaboratif aide à améliorer l’outil, en confirmant parfois ses intuitions initiales, comme, dans le cas de Damien, celle de la nécessité d’impliquer les équipes en charge du développement applicatif dans le processus d’anonymisation (Cf. sa tribune sur lesechos.fr en juillet 2020).
À côté des prestations comme le support, une conférence ou une démo animée chez un client utilisateur du logiciel est une excellente occasion d’échanger sur les cas d’utilisation, les besoins et contraintes, les projets, etc. Les choix de développement seront davantage influencés par les besoins réels des destinataires, partie prenante du projet.
Une entité pour soutenir le projet
Pour la personne qui développe, il est très important d’être soutenue et reconnue par une organisation, en général son employeur.
Concrètement, ses collègues, les testeurs, mais aussi la réputation, le soutien juridique et la participation de son organisation à des événements communautaires sont essentiels pour coder efficacement et sereinement, tout en faisant connaître son projet auprès de ses pairs. Dès lors, elle a les moyens d’accomplir un travail de qualité, qui bénéficiera en retour à l’entité qui la soutient.
Un bon exemple actuel est celui de la Fondation Linux, à laquelle Microsoft vient de confier l’avenir de son logiciel de mise en réseau Sonic (Cf. article du Monde informatique du 19 avril 2022). La multinationale a compris que l’utilisation de ce logiciel sera favorisée par un écosystème vertueux centré sur les développeur⋅ses.
Pour en revenir à PostgreSQL, le PostgreSQL Global Development Group réalise un travail remarquable en respectant à la lettre sa feuille de route. La régularité des mises à jour - quatre par an, dont une majeure - démontre une organisation efficace, avec des moyens investis par sa communauté, composée d’organisations prestataires et utilisatrices actives.
Du temps planifié pour un code de qualité
Chez Dalibo, les DBA et développeur⋅ses ont du temps pré-alloué à leurs projets libres : en moyenne, une semaine par mois est dédiée à la contribution et à la R&D. Grâce à ce « temps CCC » inspiré de la culture libriste, nous pouvons aussi bien effectuer de la veille techologique que préparer une conférence communautaire, ou encore, justement, maintenir régulièrement un projet logiciel.
La planification de ce temps permet donc de résoudre efficacement et rapidement les problèmes imprévus, voire de les anticiper. En effet, plongé⋅es dans le code, nous conservons une bonne mémoire de travail. Moins soumis⋅es au stress et à la dispersion, nous faisons moins de choix à la hâte et moins d’erreurs, dont le coût futur est non négligeable. Nous avons le temps de tester, faire tester, consulter nos pairs, réaliser des démos internes, etc.
Un projet communautaire aura beaucoup plus de chance d’innover qu’un projet personnel isolé, car le/la développeur⋅se disposera de moyens et de ressources importantes. Il est alors possible de dépasser le « bricolage » pour donner à son projet une autre dimension, où les organisations ont tout intérêt à investir.
Des questions, des commentaires ? Écrivez-nous
