Merci pour le petit résumé, il est intéressant de lire quelqu'un qui est des 2 côtés de la "barrière".
Ceci étant dit, j'ai, comme j'imagine une frange non négligeable de la population qui visite linuxfr, déjà contribué à certains projets, ou au moins essayé.
Du peu de contributions que j'ai tentées, j'ai discerné, peut-être à tord, plusieurs axes qui vont influencer le comportement en réponse de la contribution:
si le projet est un outil, ou un "produit" final.
le nombre de personnes occupées (temps plein ou partiel, professionnellement ou par loisir, je parle ici des contributeurs qui ont intégré, d'une façon ou d'une autre le cœur du projet) par la maintenance du projet, ou la taille de la communauté.
l'âge du projet.
la vitalité du projet.
Je n'ai qu'une ou deux anecdotes sur des projets de type outils, uniquement des bibliothèques C ou C++ (la réaction des développeur change-t-elle en fonction du langage? Je n'en sais rien.). En général, j'ai eu l'impression, si le développement était encore actif, d'une certaine bienveillance.
J'ai corrigé 2-3 bugs (one-liners, souvent) et erreurs ou imprécisions de doc ici et là.
Dans le cas (oui, LE) ou j'ai corrigé une imprécision de la doc, j'en ai profité pour soumettre une demande de fonctionnalité (sur GLFW3, une histoire de presse-papier, j'avais surtout testé pour le fun, mais la doc était imprécise et le comportement faisait que si l'utilisateur (un dev, donc) considérait une erreur comme une raison de crash (comme moi, encore, même si parfois le contexte fait qu'il faut tenter de récupérer un état stable). Du coup, j'ai suggéré plusieurs choses: donner un moyen de vérifier que le presse-papier contiens effectivement des données avant de les récupérer, ou... je ne me souviens plus.
Les devs ont opté (ce que j'aurai aussi fait, et donc ai mis en valeur dans ma suggestion) pour améliorer la précision de la doc et introduire une fonction pour vérifier que le presse papier contiens quelque chose dans une version future. On verra dans le futur si la fonctionnalité est implémentée... Ça ne me tenais pas vraiment à cœur, sinon j'aurai sûrement soumis un patch, je voulais juste jouer un peu avec le code quand je suis tombé sur le comportement surprenant en question.
Sur des "produits finaux", en revanche, j'ai un peu plus à dire. j'ai tenté bien plus souvent d'aider, et les retours sont assez divers.
Parfois, on à l'impression d'être ignoré, purement et simplement.
J'ai en mémoire un vent sur Debian, ou j'ai signalé un bug de udev qui partait en boucle infinie, qui menait à une augmentation des processus udev, et donc une saturation de la RAM, ce qui mène à un état ou Linux ne répond juste plus. Au temps pour le fameux "dans l'open source on corrige en 2s les bugs signalés". Au final, il n'était pas tombé dans l'oubli, j'ai eu un retour sur mon mail plus d'un an après avoir soumis le bug.
J'avoue, mon comportement n'a pas été modèle sur ce coup: au bout d'un an, j'ai encore une image disque avec les données qui reproduisent le bug, mais je n'ai même pas daigné répondre. J'ai mal pris le fait de ne même pas avoir le moindre retour en 12 mois. J'ose espérer que c'est humain. D'autant que, pendant ces 12 mois, Jessie est parue ( est-ce la raison pour laquelle je n'ai pas eu de retours avant? ) et les changements de Debian autant que mon évolution personnelle font qu'il ne me manque pas grand chose pour changer de distrib. Cette histoire à aussi dû contribuer à cette volonté, malgré que j'éprouve réellement un grand respect pour Debian.
Dans d'autres cas le mainteneur est en désaccord avec le ticket, mais répond rapidement et poliment. Là, c'est agréable. Ça m'est arrivé, encore une fois sur Debian, par rapport à un jeu (mars shooter, plutôt fun, je vous le conseille) qui à une dépendance dure sur ... des polices de caractères. Son argument était valide par rapport au projet, au final, donc je n'ai pas insisté (mais c'est probablement une des raisons qui font que je cesserai d'utiliser Debian quand j'aurai le courage d'aller sur une distro plus pointue).
Il y à aussi le cas ou l'on cherche à s'impliquer, et ou l'on s'aperçois sur une session IRC laissée en suspend qu'en fait les gens préfèrent vous ignorer plutôt que de répondre. Même pas ils diraient qu'on va trop loin, non non, il préfère laisser les contributeurs potentiels rédiger des messages propres et essayer de patcher le code, sans leur dire qu'en fait, ils en ont rien à carrer. Je ne citerai pas le projet en question, mais vous comprendrez que j'ai juste arrêté de donner des nouvelles, du jour au lendemain. Aujourd'hui, il est encore vivant, tant mieux, il à évolué, tant mieux encore, mais j'ai constaté pas mal de régressions dans les fonctionnalités, et ça me fait autant sourire que mal (parce que si je voulais m'y impliquer c'est que je l'aime).
Il y à aussi les projets, genre valyria tear (un jrpg, des plus prometteurs à mon avis), ou il y a peu de gens, qui sont heureux de recevoir les contributions, et vont jusqu'a recontacter les gens (un nettoyage des allocations mémoire C dans un code C++, je soupçonnais un memory leak de là mais ça n'a rien résolu... le problème viendrai peut-être de la lib pour lua du coup... Tant pis, le code semble avoir quand même été intégré vu que j'ai refondu pour respecter mieux le style de code qui semblait être le final, il faudrait que j'aille remercier).
Enfin, il y à toutes sortes de projets, et ce ne sont pas mes expériences négatives avec certains qui m'empêcheront de tenter de contribuer à de nouveaux projets, que ce soit par le code ou par les tickets. Je reste par contre un véritable contributeur de passage, les rares fois ou j'ai tenté de m'impliquer à fond dans un projet m'ont tellement refroidi que je n'ai plus l'intention de m'intégrer dans une équipe (sauf boulot, mais c'est différent). Tant qu'a faire, je préfère encore forker ou réécrire, si j'ai trop de trucs à changer. Et le signaler au projet original, qui est du coup libre d'intégrer ou non les patchs.
Oui, ça augmente potentiellement la fragmentation, mais entre nous: je m'en fiche. Je mets toujours un lien vers le projet originel, je l'averti aussi toujours en face, et s'il intègre assez de modifs, je vire mon fork.
Au final, moi, je suis plus serein parce que je n'ai pas à me prendre la tête à convaincre par des mots qui ne serons même pas lus (et personne pour répondre franchement: "TL;DR" ou "rien à foutre de ton idée") et j'ai un soft qui marche comme je le veux. Et le projet originel est libre d'intégrer mes idées si ça lui chante et si ça fonctionne. Gagnant-gagnant pour moi.
# Différences entre les outils et les applications finales
Posté par freem . En réponse au journal Cinq ans de projets libres: bilan et retour d'expérience sur la contribution. Évalué à 10.
Merci pour le petit résumé, il est intéressant de lire quelqu'un qui est des 2 côtés de la "barrière".
Ceci étant dit, j'ai, comme j'imagine une frange non négligeable de la population qui visite linuxfr, déjà contribué à certains projets, ou au moins essayé.
Du peu de contributions que j'ai tentées, j'ai discerné, peut-être à tord, plusieurs axes qui vont influencer le comportement en réponse de la contribution:
Je n'ai qu'une ou deux anecdotes sur des projets de type outils, uniquement des bibliothèques C ou C++ (la réaction des développeur change-t-elle en fonction du langage? Je n'en sais rien.). En général, j'ai eu l'impression, si le développement était encore actif, d'une certaine bienveillance.
J'ai corrigé 2-3 bugs (one-liners, souvent) et erreurs ou imprécisions de doc ici et là.
Dans le cas (oui, LE) ou j'ai corrigé une imprécision de la doc, j'en ai profité pour soumettre une demande de fonctionnalité (sur GLFW3, une histoire de presse-papier, j'avais surtout testé pour le fun, mais la doc était imprécise et le comportement faisait que si l'utilisateur (un dev, donc) considérait une erreur comme une raison de crash (comme moi, encore, même si parfois le contexte fait qu'il faut tenter de récupérer un état stable). Du coup, j'ai suggéré plusieurs choses: donner un moyen de vérifier que le presse-papier contiens effectivement des données avant de les récupérer, ou... je ne me souviens plus.
Les devs ont opté (ce que j'aurai aussi fait, et donc ai mis en valeur dans ma suggestion) pour améliorer la précision de la doc et introduire une fonction pour vérifier que le presse papier contiens quelque chose dans une version future. On verra dans le futur si la fonctionnalité est implémentée... Ça ne me tenais pas vraiment à cœur, sinon j'aurai sûrement soumis un patch, je voulais juste jouer un peu avec le code quand je suis tombé sur le comportement surprenant en question.
Sur des "produits finaux", en revanche, j'ai un peu plus à dire. j'ai tenté bien plus souvent d'aider, et les retours sont assez divers.
Parfois, on à l'impression d'être ignoré, purement et simplement.
J'ai en mémoire un vent sur Debian, ou j'ai signalé un bug de udev qui partait en boucle infinie, qui menait à une augmentation des processus udev, et donc une saturation de la RAM, ce qui mène à un état ou Linux ne répond juste plus. Au temps pour le fameux "dans l'open source on corrige en 2s les bugs signalés". Au final, il n'était pas tombé dans l'oubli, j'ai eu un retour sur mon mail plus d'un an après avoir soumis le bug.
J'avoue, mon comportement n'a pas été modèle sur ce coup: au bout d'un an, j'ai encore une image disque avec les données qui reproduisent le bug, mais je n'ai même pas daigné répondre. J'ai mal pris le fait de ne même pas avoir le moindre retour en 12 mois. J'ose espérer que c'est humain. D'autant que, pendant ces 12 mois, Jessie est parue ( est-ce la raison pour laquelle je n'ai pas eu de retours avant? ) et les changements de Debian autant que mon évolution personnelle font qu'il ne me manque pas grand chose pour changer de distrib. Cette histoire à aussi dû contribuer à cette volonté, malgré que j'éprouve réellement un grand respect pour Debian.
Dans d'autres cas le mainteneur est en désaccord avec le ticket, mais répond rapidement et poliment. Là, c'est agréable. Ça m'est arrivé, encore une fois sur Debian, par rapport à un jeu (mars shooter, plutôt fun, je vous le conseille) qui à une dépendance dure sur ... des polices de caractères. Son argument était valide par rapport au projet, au final, donc je n'ai pas insisté (mais c'est probablement une des raisons qui font que je cesserai d'utiliser Debian quand j'aurai le courage d'aller sur une distro plus pointue).
Il y à aussi le cas ou l'on cherche à s'impliquer, et ou l'on s'aperçois sur une session IRC laissée en suspend qu'en fait les gens préfèrent vous ignorer plutôt que de répondre. Même pas ils diraient qu'on va trop loin, non non, il préfère laisser les contributeurs potentiels rédiger des messages propres et essayer de patcher le code, sans leur dire qu'en fait, ils en ont rien à carrer. Je ne citerai pas le projet en question, mais vous comprendrez que j'ai juste arrêté de donner des nouvelles, du jour au lendemain. Aujourd'hui, il est encore vivant, tant mieux, il à évolué, tant mieux encore, mais j'ai constaté pas mal de régressions dans les fonctionnalités, et ça me fait autant sourire que mal (parce que si je voulais m'y impliquer c'est que je l'aime).
Il y à aussi les projets, genre valyria tear (un jrpg, des plus prometteurs à mon avis), ou il y a peu de gens, qui sont heureux de recevoir les contributions, et vont jusqu'a recontacter les gens (un nettoyage des allocations mémoire C dans un code C++, je soupçonnais un memory leak de là mais ça n'a rien résolu... le problème viendrai peut-être de la lib pour lua du coup... Tant pis, le code semble avoir quand même été intégré vu que j'ai refondu pour respecter mieux le style de code qui semblait être le final, il faudrait que j'aille remercier).
Enfin, il y à toutes sortes de projets, et ce ne sont pas mes expériences négatives avec certains qui m'empêcheront de tenter de contribuer à de nouveaux projets, que ce soit par le code ou par les tickets. Je reste par contre un véritable contributeur de passage, les rares fois ou j'ai tenté de m'impliquer à fond dans un projet m'ont tellement refroidi que je n'ai plus l'intention de m'intégrer dans une équipe (sauf boulot, mais c'est différent). Tant qu'a faire, je préfère encore forker ou réécrire, si j'ai trop de trucs à changer. Et le signaler au projet original, qui est du coup libre d'intégrer ou non les patchs.
Oui, ça augmente potentiellement la fragmentation, mais entre nous: je m'en fiche. Je mets toujours un lien vers le projet originel, je l'averti aussi toujours en face, et s'il intègre assez de modifs, je vire mon fork.
Au final, moi, je suis plus serein parce que je n'ai pas à me prendre la tête à convaincre par des mots qui ne serons même pas lus (et personne pour répondre franchement: "TL;DR" ou "rien à foutre de ton idée") et j'ai un soft qui marche comme je le veux. Et le projet originel est libre d'intégrer mes idées si ça lui chante et si ça fonctionne. Gagnant-gagnant pour moi.