Attaques personnelles, accusations de malware et abandon : un projet Linux prometteur prend fin après que son développeur ait été victime de harcèlement Kapitano était une interface graphique pour ClamAV
Kapitano visait à rendre ClamAV, un antivirus open source reconnu, beaucoup plus accessible aux utilisateurs Linux via une interface graphique GTK4/libadwaita. En évitant l’usage du terminal, il promettait une adoption facilitée pour les novices — une initiative simple mais puissante. Mais son développeur, connu sous le pseudonyme de « zynequ », a annoncé l'abandon de son projet d'antivirus Kapitano suite à une vague de harcèlement en ligne. Cet événement met en lumière les défis auxquels sont confrontés les créateurs de logiciels bénévoles, souvent ciblés par des attaques personnelles et des critiques virulentes.
Kapitano était un outil dont la fonction était simple : donner au moteur d'analyse ClamAV une interface moderne sous Linux. Il s'appuyait sur la base de données ClamAV, une liste massive et constamment mise à jour utilisée pour détecter toutes sortes de menaces telles que les virus, les vers et les chevaux de Troie. Comme ClamAV est avant tout un outil en ligne de commande, il dépend d'une interface graphique (frontend) pour les utilisateurs qui préfèrent ne pas travailler dans le terminal. Il existe des applications telles que ClamWin sous Windows, ClamXav sous Mac et, jusqu'à récemment, Kapitano sous Linux.
Kapitano, cette interface graphique pour le moteur de scan antivirus en ligne de commande ClamAV, avait été conçu par zynequ comme un projet de loisir. Le développeur, travaillant sur son temps libre et sans aucun soutien financier, souhaitait offrir une solution de sécurité conviviale à la communauté Linux.
Dérive subite : du bug à l’attaque personnelle
Le tournant est survenu lorsqu’un utilisateur a ouvert une issue sur Codeberg affirmant : « Kapitano resulted in 24 positives – for win.exploits and Trojans » (« Kapitano a donné lieu à 24 résultats positifs – pour win.exploits et chevaux de Troie »), accompagné d’un « DO NOT DOWNLOAD ! » catégorique. Il affirmait que Kapitano générait de faux positifs ciblant Windows. L'utilisateur est allé jusqu'à qualifier Kapitano de malware.
Zynequ a tenté de calmer la situation en expliquant que Kapitano n'était qu'une interface et que le problème provenait du moteur ClamAV lui-même, soulignant au passage que le code était ouvert et vérifiable par tous. Kapitano, développé avec GTK4 et libadwaita, n'est qu'un wrapper qui envoie des commandes à l'utilitaire clamscan, mais n'a aucune influence sur ce qui est signalé.
Envoyé par Zynequ
Pour référence, voici le code qui concerne vos préoccupations : https://codeberg.org/zynequ/Kapitano...tils/clamav.py
Sur les méthodes scan_for_malware et update_malware_definitions, vous pouvez voir qu'elles appellent simplement clamscan et freshclam.
Sur les méthodes scan_for_malware et update_malware_definitions, vous pouvez voir qu'elles appellent simplement clamscan et freshclam.
Le développeur a également reproché à l'utilisateur ses « attaques personnelles » et a abordé la question de l'absence totale d'avis, soulignant qu'il ne s'agissait pas d'un complot puisque le projet était très récent, ayant été lancé en juin. Il a insisté sur le fait que son code n'avait rien de « louche » et qu'il était entièrement ouvert à l'examen.
La situation s'est alors envenimée. Après que Zynequ ait clos le dossier, l'utilisateur en a créé un autre, puis a soumis à nouveau sa plainte sous le numéro 13, cette fois-ci avec un titre différent : « Le développeur de Kapitano est un acteur malveillant. Bloquez ce distributeur de logiciels malveillants ».
Après un échange houleux avec le développeur, l'utilisateur a finalement publié : « Votre projet n'est plus sur le disque dur de mon ordinateur portable. Laissez tomber. Au revoir. »
Face à la pression psychologique, zynequ a annoncé l’archivage du projet. Son message exprimait clairement son découragement :
Envoyé par zynequ
Je suis désolé de vous annoncer que ce projet n'est plus maintenu. Récemment, j'ai vécu une expérience désagréable concernant les problèmes n° 12 et n° 13, où j'ai été accusé de distribuer des logiciels malveillants. Bien que j'aie expliqué que le problème ne venait pas de l'application, la conversation a dégénéré en attaques personnelles et en propos virulents à mon égard.
Ce projet a toujours été un projet amateur, créé pendant mon temps libre sans aucun soutien financier. Des incidents comme celui-ci rendent difficile de rester motivé. Cela dit, je suis sincèrement reconnaissant à tous ceux qui ont essayé l'application et j'apprécie l'attention qu'elle a reçue.
À partir de maintenant :
Je présente mes sincères excuses à tous ceux qui sont déçus par cette décision.
Ce projet a toujours été un projet amateur, créé pendant mon temps libre sans aucun soutien financier. Des incidents comme celui-ci rendent difficile de rester motivé. Cela dit, je suis sincèrement reconnaissant à tous ceux qui ont essayé l'application et j'apprécie l'attention qu'elle a reçue.
À partir de maintenant :
- Le projet est publié dans le domaine public sous licence The Unlicense. Vous êtes libre de l'utiliser, de le modifier, de le vendre ou de le redistribuer comme vous le souhaitez, sans attribution.
- Il sera retiré de Flathub et marqué comme étant en fin de vie.
- Le dépôt restera en ligne pendant quelques mois au cas où quelqu'un souhaiterait le forker ou le poursuivre. Après cela, je fermerai mon compte Codeberg.
Je présente mes sincères excuses à tous ceux qui sont déçus par cette décision.
Contexte et résonance dans l’open source
Une toxicité trop souvent ignorée
L’abandon de Kapitano n’est pas un cas isolé. Sur Reddit, un utilisateur cite plusieurs projets abandonnés à cause du harcèlement et du manque de gratitude des utilisateurs, comme Ueberzug (un utilitaire en ligne de commande qui permet de dessiner des images sur des terminaux à l'aide de fenêtres enfants), dont le développeur a quitté en citant la négativité constante et l’absence de respect pour son travail bénévole. Ce témoignage souligne une réalité douloureuse du monde open source : les mainteneurs bénévoles subissent parfois une faible reconnaissance, voire de la toxicité.
Pression intense sur les responsables de projets
Le phénomène va au-delà de simples soucis au niveau du frontend : même des mainteneurs de projets essentiels en abandonneraient pour des raisons non techniques. Par exemple, un responsable du projet Rust for Linux a quitté, évoquant la fatigue face à des discours non techniques. Cela montre que des aspects sociaux peuvent être tout aussi destructeurs que les défis techniques.
Perte fréquente de développeurs clés
Une étude académique révèle que 70 % des projets open source perdent leur développeur principal dans les trois premières années, et seuls 27 % parviennent à attirer un successeur. Kapitano illustre cette statistique : un projet prometteur, mais solo, vulnérable et rapidement abandonné. Les projets isolés restent les plus exposés.
Envoyé par résumé de l'étude
Tout au long de leur cycle de vie, les systèmes logiciels open source attirent naturellement de nouveaux contributeurs et perdent des contributeurs existants. Cependant, tous les contributeurs OSS ne sont pas égaux, car certains contributeurs au sein d'un projet possèdent des connaissances et une expertise significatives du code source (c'est-à-dire les développeurs principaux).
Lorsqu'on examine la capacité des projets à attirer de nouveaux contributeurs et la fréquence à laquelle un projet perd des contributeurs, il est donc important de tenir compte de l'expertise des contributeurs. Les développeurs principaux étant essentiels à la pérennité des projets, nous cherchons donc à déterminer si les projets OSS peuvent attirer de nouveaux développeurs principaux et à quelle fréquence les projets OSS perdent des développeurs principaux.
Afin d'étudier les modèles de contribution des développeurs principaux, nous calculons le facteur camion (ou facteur bus) de plus de 36 000 projets OSS afin d'étudier la fréquence à laquelle les développeurs TF rejoignent ou abandonnent les projets OSS. Nous constatons que 89 % des projets étudiés ont perdu leur équipe de développement principale au moins une fois.
Nos résultats montrent également que dans 70 % des cas, l'abandon d'un projet survient au cours des trois premières années de son existence. Nous constatons également que la plupart des projets OSS dépendent d'un seul développeur principal pour maintenir les activités de développement. Enfin, nous constatons que seuls 27 % des projets abandonnés ont réussi à attirer au moins un nouveau développeur TF. Notre analyse montre qu'il n'est pas rare que les projets OSS perdent leur équipe de développement principale initiale.
Cela s'explique probablement par le fait que la plupart des projets OSS dépendent d'un seul développeur principal pour maintenir les activités de développement. La première année de développement est cruciale pour les projets OSS, car c'est à ce moment-là qu'ils risquent le plus de perdre leur(s) développeur(s) principal(aux). De plus, les projets qui perdent leur(s) développeur(s) principal(aux) dès le début semblent moins susceptibles de survivre à cet événement que les projets qui ont perdu leur(s) développeur(s) principal(aux) plus tard au cours de leur vie.
Lorsqu'on examine la capacité des projets à attirer de nouveaux contributeurs et la fréquence à laquelle un projet perd des contributeurs, il est donc important de tenir compte de l'expertise des contributeurs. Les développeurs principaux étant essentiels à la pérennité des projets, nous cherchons donc à déterminer si les projets OSS peuvent attirer de nouveaux développeurs principaux et à quelle fréquence les projets OSS perdent des développeurs principaux.
Afin d'étudier les modèles de contribution des développeurs principaux, nous calculons le facteur camion (ou facteur bus) de plus de 36 000 projets OSS afin d'étudier la fréquence à laquelle les développeurs TF rejoignent ou abandonnent les projets OSS. Nous constatons que 89 % des projets étudiés ont perdu leur équipe de développement principale au moins une fois.
Nos résultats montrent également que dans 70 % des cas, l'abandon d'un projet survient au cours des trois premières années de son existence. Nous constatons également que la plupart des projets OSS dépendent d'un seul développeur principal pour maintenir les activités de développement. Enfin, nous constatons que seuls 27 % des projets abandonnés ont réussi à attirer au moins un nouveau développeur TF. Notre analyse montre qu'il n'est pas rare que les projets OSS perdent leur équipe de développement principale initiale.
Cela s'explique probablement par le fait que la plupart des projets OSS dépendent d'un seul développeur principal pour maintenir les activités de développement. La première année de développement est cruciale pour les projets OSS, car c'est à ce moment-là qu'ils risquent le plus de perdre leur(s) développeur(s) principal(aux). De plus, les projets qui perdent leur(s) développeur(s) principal(aux) dès le début semblent moins susceptibles de survivre à cet événement que les projets qui ont perdu leur(s) développeur(s) principal(aux) plus tard au cours de leur vie.
Conclusion
Cet incident, bien que centré sur un seul projet, a ravivé le débat au sein de la communauté open source sur la nécessité de créer des environnements plus respectueux et de protéger les développeurs bénévoles du harcèlement. Cela soulève une question fondamentale : comment concilier la liberté de parole avec la protection des créateurs de contenu qui investissent leur temps et leur énergie pour le bien commun ?
Sources : Zynequ, Mythe : la perte de développeurs principaux est un problème critique pour les communautés OSS, ClamAV
Et vous ?
Quelle lecture faites-vous de cette situation ? Avez-vous déjà rencontré des cas comme celui-ci ? Selon vous, sont-ils plutôt rare ou plus fréquent qu'on ne pourrait le penser ? Qu'est-ce qui conduit à de telles situations ? Comment les plateformes de développement comme GitHub ou GitLab peuvent-elles mieux protéger les contributeurs contre le harcèlement, au-delà de la simple modération des commentaires ? Quelles mesures pourraient être mises en place pour offrir un soutien psychologique ou une aide juridique aux développeurs bénévoles ciblés ? Comment sensibiliser la communauté open source à l'impact que les commentaires négatifs et le harcèlement peuvent avoir sur la santé mentale des créateurs ?
Vous avez lu gratuitement 386 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.
