Comme pour beaucoup de choses dans la vie, la motivation est primordiale. Cela s’applique également au développement de logiciels, un domaine qui a pris une importance considérable au cours des dernières décennies. Dans un contexte commercial, la motivation à écrire des logiciels est avant tout financière, dans la mesure où les produits d’une entreprise sont développés par des individus qui sont rémunérés financièrement pour leur temps. Ceci est souvent différent avec les projets de logiciels libres et open source (FOSS), où la motivation pour développer le logiciel découle dans de nombreux cas davantage d’une passion et parfois d’un passe-temps extrêmement réussi plutôt que d’incitations financières.
Et si des incitations financières étaient ajoutées par ceux qui ont tout intérêt à voir certaines fonctionnalités ajoutées ou modifiées dans un projet FOSS ? Alors qu’avec un projet commercial, il est clair (ou devrait l’être) que les clients payants sont ceux dont les besoins doivent être satisfaits, avec un projet FOSS basé sur le volontariat, l’ajout d’incitations financières rend le système beaucoup plus flou. C’est là que les projets FOSS comme le langage de programmation Zig ont mis le pied à l’étrier, qualifiant les primes FOSS de « préjudiciables ».
Chasse aux primes
Dans ce sujet absolument volatile et incendiaire, c’est probablement une bonne idée de commencer par définir ce que l’on entend par « prime », car il existe un certain nombre d’interprétations possibles uniquement dans le domaine du développement logiciel. Le plus connu est peut-être le concept des programmes de bug bounty, où quelqu’un qui découvre une faille dans le produit ou le service logiciel d’une entreprise peut obtenir une sorte de récompense (monétaire). Cette récompense est censée être là à la fois pour motiver les chercheurs en sécurité à découvrir de nouveaux bugs et à signaler ces bugs à l’entreprise plutôt que de laisser des individus moins scrupuleux les utiliser à des fins mal acquises.
D’une certaine manière, cela fait d’un tel programme de primes un équivalent moderne de l’ancienne tradition des chasseurs de primes, mais il est tout à fait distinct des programmes de primes qui ciblent le développement de fonctionnalités logicielles plutôt que la découverte de bugs. Lorsqu’il s’agit de motiver le développement de nouvelles fonctionnalités, nous pouvons distinguer deux grands types d’incitations :
- Une prime de la communauté pour soumettre un correctif de fonctionnalité au projet.
- Une récompense monétaire remise au(x) développeur(s) du projet à la fin de la nouvelle fonctionnalité.
Dans le billet de blog du projet Zig, nous pouvons voir qu’ils n’ont aucun problème avec les bug bounties, ce qui est compréhensible. Malgré certains problèmes liés aux programmes de bug bounty au fil des décennies, ils constituent en général une incitation positive nette qui peut créer une relation saine entre les chercheurs en sécurité et les développeurs. Après tout, même le projet logiciel le mieux exécuté comportera inévitablement des bugs dans la version Golden Master qui sera diffusée dans le monde, dont vous préférerez entendre parler par un chercheur réputé plutôt que dans les médias.
En revanche, la notion de primes communautaires est présentée comme étant essentiellement nuisible et contre laquelle les développeurs de Zig mettent en garde. Plutôt que de créer une atmosphère amicale et coopérative, de telles primes sont vouées à inciter à des implémentations développées à la hâte et mal réfléchies, où la principale mesure du « succès » est de savoir si tous les cas de test s’allument ou non en vert. Ajoutez à cela la possibilité que les développeurs du projet doivent juger et probablement rejeter diverses propositions concurrentes, et il semblerait raisonnable de conclure que seuls les chercheurs en sécurité gagnent dans un tel scénario.
Jalonnement des revendications
L’idée de mettre en place des primes logicielles pour promouvoir le développement de fonctionnalités n’est pas du tout une nouveauté, avec par exemple le projet GNU Hurd en 2011 expliquant pourquoi ils pensent que les primes sont une excellente idée. Pourtant, le site Web auquel le projet fait référence – FOSS Factory – semble être pour l’essentiel mort depuis 2008 environ, soit trois ans avant même que le projet GNU Hurd n’en encourage l’utilisation.
Un exemple plus récent de site Web de primes logicielles est Bountysource, qui accepte toujours activement de nouvelles primes. Cependant, après avoir été acheté et revendu par un certain nombre de sociétés de crypto-monnaie, il se trouve actuellement dans une situation délicate pour ne pas avoir versé l’argent de la prime qu’il est censé détenir en dépôt. C’était apparemment déjà un problème en 2020, avec certains projets passant aux sponsors GitHub, ce qui, fait intéressant, est essentiellement l’inverse d’un système de primes car il implique de faire un don à un projet.
Cependant, plutôt que d’être strictement un système de dons, Naomichi Shimada et ses collègues dans une étude de 2022 notent que GitHub Sponsors transforme un projet en sponsorware. Même si la différence entre don et parrainage peut paraître académique à certains, ces derniers ont des attentes précises en matière de retour, quelle que soit la forme. Dans l’étude de Shimada et al., ces attentes différentes entre les chefs de projet et ceux qui parrainent ou contribuent à un projet autrement qu’en tant que développeur sont abordées comme un problème potentiel qui devrait être gardé à l’esprit par les propriétaires de projet avant d’autoriser les parrainages.
Logiciel libre commercial
Un moyen viable de régler le coût financier du développement de fonctionnalités logicielles est couvert en détail par Brad Collette de l’équipe principale d’Ondsel (FreeCad). Bien que les points soulevés contre les primes communautaires soient à peu près les mêmes que ceux soulevés par les développeurs de Zig, la méthode suggérée qui fonctionne implique essentiellement le financement participatif, le projet Krita étant fourni comme un brillant exemple.
Essentiellement, les développeurs du projet se réuniront pour déterminer quelles fonctionnalités pourraient ou devraient être implémentées dans la prochaine version majeure et les présenteront à la communauté. En lançant une campagne de financement participatif avec des objectifs étendus, la communauté peut ainsi financer directement les nouvelles fonctionnalités tandis que les objectifs étendus sont également décidés par la communauté via leur financement. Bien que le projet soit encore techniquement FOSS, cela fait de la communauté (utilisateurs) une partie intégrante du projet en en faisant des parties prenantes du projet.
Il est intéressant de noter que ce montant n’est pas très éloigné du nombre de grands projets FOSS – tels que le noyau Linux et les plus grandes distributions – qui sont financés. Bien que remplis de petits projets de loisir susceptibles de faire échouer le projet plus vaste s’ils développaient un problème, ces grands projets FOSS sont dans l’ensemble parrainés et financés par les entreprises les plus riches du monde.
À titre d’exemple, le noyau Linux est soutenu par les sponsors de la Linux Foundation, avec en 2021 Huawei fournissant le plus d’ensembles de modifications et Intel contribuant le plus de lignes de code modifiées sur le noyau 5.10. En 2022, le noyau 6.0 a vu Intel, AMD, Google et Linaro s’affronter dans le top 4 de chaque catégorie. Dans l’ensemble, la plupart des développements de logiciels libres sont financés directement – souvent par des développeurs internes – par des géants de l’informatique comme Microsoft, Amazon Web Services (AWS), Intel et Google. Cela rend alors clairement la question des primes logicielles sans objet pour ce type de projets FOSS alors que des entreprises avec des milliards de dollars de revenus paient déjà la facture.
Petit logiciel libre
Lire par exemple cette discussion de 2021 sur Hacker News sur le thème des primes logicielles est également plutôt intéressant comme moyen d’évaluer les sentiments et les expériences des gens à ce sujet. Le consensus général semble être que pour les projets FOSS qui ne bénéficient pas déjà du soutien de riches sponsors ou similaires, il est crucial de maintenir l’engagement et la motivation du ou des développeurs derrière eux.
En tant que personne ayant connu un succès moyen avec des projets FOSS modérément réussis, il y a une certaine précipitation qui vient du fait que les gens prêtent réellement attention à votre logiciel, et même l’utilisent dans de vrais projets commerciaux. Pourtant, en fin de compte, il est essentiel de différencier si un projet est un passe-temps ou un travail, la différence étant ici de savoir si vous êtes payé pour effectuer un travail.
Si vous êtes propriétaire d’un projet et que vous lancez une demande de financement participatif qui finit par couvrir les coûts prévus de mise en œuvre de vos fonctionnalités, même si ce n’est que pour couvrir le loyer et la nourriture pour humains/animaux, vous assumez la responsabilité de mettre en œuvre cette fonctionnalité afin que ceux qui ont contribué financièrement sont satisfaits des résultats.
Si, toutefois, quelqu’un crée un ticket dans votre projet GitHub disant qu’il « aimerait vraiment voir la fonctionnalité XZ implémentée », mais qu’aucun financement n’a été alloué, il ne s’agit toujours que de votre projet de passe-temps et vous êtes libre d’ignorer ces tickets, ou seulement acceptez-le car cela semble intéressant comme défi dans le cadre dudit projet de loisir.
L’un des risques majeurs des projets FOSS est l’exploitation des FOSS, qui est récemment devenue un sujet très controversé. En conséquence, certaines entreprises abandonnent désormais les licences FOSS très ouvertes au profit de licences plus restrictives (comme la GPL), afin d’empêcher d’autres entreprises de gagner de l’argent avec quelque chose qui a été distribué gratuitement. Cela pourrait être considéré comme une réponse naturelle à une telle exploitation, dans la mesure où les entreprises et les particuliers cherchent à se protéger.
On nous apprend, lorsque nous sommes enfants, que « partager, c’est prendre soin », mais le concept d’équité est encore plus crucial. Bien que les logiciels libres soient parfois décrits comme une sorte de rêve utopique de logiciels libres infinis, la dure réalité est que chaque ligne de code est toujours écrite et testée par des êtres humains, dont chacun a besoin de manger et mérite son juste dû.
