Qu'est-ce que la réplique canonique à "c'est open source, soumettre un patch"? [fermé]

Le danger de jamais suggérer une fonctionnalité sur un produit, notamment open source, est que vous obtiendrez la réponse "pourquoi ne pas le faire?".

C'est valide, et c'est cool que vous puissiez faire le changement vous-même. Mais nous savons pratiquement que les produits s’améliorent souvent lorsque les programmeurs écoutent la voix des utilisateurs - même si ces utilisateurs sont d’autres programmeurs. Et, pour apporter ces changements de manière efficace, il peut être utile de faire appel à une personne qui travaille déjà sur le projet et qui la concrétise.

Certains termes courants sont utilisés pour désigner des problèmes de développement de logiciels. par exemple Bikeshedding . Existe-t-il un terme commun qui réponde en substance: "Oui, je sais que je peux changer à peu près tout dans le monde - même dans le cas d’une source fermée. Je pourrais être embauché et écrire ce code. Mais dans ce cas, je ne fais que une observation qui peut en fait être utile pour un autre codeur déjà bien placé pour effectuer facilement ce changement - ou simplement pour discuter des possibilités en général. "

[ps (quelques jours) - J'aurais dû préciser que "soumettre un patch" est souvent dit avec un humour ironique et je cherche une réponse spirituelle appropriée.]

C'est un point difficile: étant donné que l'utilisateur ne paie pas directement ou indirectement un produit, il ne peut pas demander la mise en œuvre d'une fonctionnalité. Ce n'est pas comme si vous étiez un intervenant ou un client direct qui avait commandé le produit, et même pas l'utilisateur final d'un produit commercial.

Ceci étant dit, "soumettre un patch" n'est pas une réponse valide. Ce n'est pas poli. Ce n'est pas correct. Même pour un produit open source. "Submit a patch" est la version courte de:

"Peu importe que vous aimiez notre produit ou non. Modifiez-le si vous le souhaitez, mais ne nous embêtez pas avec les demandes de vos clients."

Qu'en est-il de soumettre un patch?

Eh bien, ce n'est pas si facile. Pour le faire:

• Vous devez connaître la ou les langues utilisées dans le projet open source.

• Vous devez pouvoir charger le code source à partir du contrôle de version pour pouvoir le modifier.

• Vous devez avoir toutes les versions correctes de toutes les dépendances de construction installées (y compris les bibliothèques d'exécution et les outils de construction).

• Vous devez être capable de compiler ce code source , ce qui n’est pas si évident dans certains cas. En particulier, lorsqu'un projet énorme prend quelques heures à compiler et affiche 482 erreurs et des milliers d'avertissements, vous pouvez avoir le courage d'aller à la recherche de la source de ces erreurs.

• Vous devez très bien comprendre comment le projet est réalisé , quel style de codage utiliser, le cas échéant, comment exécuter des tests unitaires, etc. Si le projet ne dispose pas d'une documentation correcte (ce qui est souvent le cas pour les projets open source ), cela peut être vraiment difficile.

• Vous devez vous adapter au projet et aux habitudes des développeurs qui participent activement au projet. Par exemple, si vous utilisez .NET Framework 4 quotidiennement, mais que le projet utilise .NET Framework 2.0, vous ne pouvez utiliser ni LINQ, ni les contrats de code, ni d'autres milliers de nouvelles fonctionnalités des dernières versions du framework.

• Votre patch doit être accepté (à moins que vous ne fassiez le changement que pour vous-même, sans intention de le partager avec la communauté).

Si votre intention est de participer activement au projet, vous pouvez faire toutes ces choses et y consacrer votre temps. Si, au contraire, il ne reste qu'un bogue mineur ou une simple fonctionnalité manquante, passer des jours, des semaines ou des mois à étudier le projet, faire le travail en quelques minutes est déraisonnable, à moins que vous ne l'aimiez.

Alors, y a-t-il une réplique canonique à "c'est open source, soumettre un correctif"? Je ne pense pas. Soit vous expliquez à la personne qu'elle est impolie, ou vous arrêtez simplement de lui parler.

La réplique canonique est de soumettre un correctif.

C'est la réponse habituelle lorsque les développeurs ne pensent pas qu'ils vont arriver à faire quelque chose dans un délai raisonnable, mais cela a été évoqué à plusieurs reprises.

C'est très injuste quand on en a parlé à plusieurs reprises, mais la personne qui a récemment mentionné le fait ne le sait pas et dit simplement "nous prenons des correctifs pour cela" tout de suite. Dans ce cas, le responsable en a marre de la discussion, mais l'utilisateur pense que c'est un nouveau sujet. Quoi qu'il en soit, il est fort probable que si vous «prenez les correctifs» tout de suite, vous ne devriez pas le prendre personnellement, mais vous voudrez peut-être lire les archives et le suivi des bogues pour plus de détails sur le problème.

Si vous formulez vous-même une demande à plusieurs reprises, "prendre des correctifs" est potentiellement censé être un pinceau relativement poli, par opposition à des alternatives moins polies ...

Et bien sûr, il y a des mainteneurs impolis qui diront "prendre des correctifs" sans explication à qui que ce soit, mais je dirais que c'est une minorité.

Si vous avez déjà géré un projet open source avec de nombreux utilisateurs, vous saurez qu'il y a 100 fois plus de demandes que les responsables de la maintenance ne pourraient jamais en obtenir, et que beaucoup de ces demandes sont importantes pour le demandeur, mais seraient incroyablement difficiles. ou perturberait de nombreux autres utilisateurs, ou présenterait une autre faille visible uniquement avec une compréhension globale du projet et de la base de code. Ou parfois, il y a juste des jugements, et il faut trop de temps pour se disputer encore et encore.

La plupart des entreprises non-open-source ne vous donneront absolument pas accès aux développeurs et vous obtiendrez simplement le traitement silencieux ou une histoire polie mais fictive du support client. Donc, en open source au moins, vous avez quelques options (payer quelqu'un pour coder la fonctionnalité, etc.) et, bien que les développeurs puissent être impolis, au moins ils donnent des réponses franches. Je préférerais "non" à l'habituel "c'est sur notre feuille de route ... [2 ans plus tard] ... c'est toujours sur notre feuille de route" du genre de chose que j'ai eu chez un certain nombre de fournisseurs ...

Donc, je ne pense pas qu'il y ait une réplique. Peut-être que le mainteneur open source est vraiment très occupé, peut-être est-ce un imbécile, mais de toute façon, ils ont probablement un travail difficile et se lancer dans un débat qui a le dernier mot ne mène à rien. Le mieux que vous puissiez faire est de contribuer d'une manière ou d'une autre et d'essayer d'être constructif.

Peut-être que ce n'est pas du code, mais il y a peut-être beaucoup d'analyses et de documentation de scénarios utilisateur que vous pourriez faire. Lorsque je maintenais le gestionnaire de fenêtres GNOME, il aurait souvent été utile d’analyser un problème de manière globale en tenant compte de tous les utilisateurs et d’écrire les problèmes, les avantages et les inconvénients et ce qui devrait se passer dans une perspective globale.

(Au lieu de cela, la chose habituelle était de commencer à flamber comme s’ils étaient le seul utilisateur qui importait et qu’il n’y avait pas de compromis. Et bien, c’est génial et c'était un point de données, et souvent je réussissais à rester poli ou même à résoudre leur problème par la suite. flaming ne fait rien arriver plus vite, il confond simplement les émotions et fait perdre le temps à tout le monde.)

La raison pour laquelle vous obtenez cette réponse n’est pas que les responsables sont des imbéciles, mais bien que vous ne les avez pas suffisamment convaincus de la proposition de valeur qu’ils travaillent sur votre fonctionnalité pour vous .

La meilleure solution consiste à entamer un dialogue sur la valeur de votre fonction pour la communauté dans son ensemble , afin de voir si vous pouvez le convaincre de changer d'avis. Peut-être ont-ils raison et savent-ils plus que vous sur les besoins de leur propre communauté - mais, encore une fois, peut-être que non.

Si cette fonctionnalité n’est utile que pour vous et n’a que peu ou pas de valeur pour la communauté, j’aperçois que l’argent est un excellent facteur de motivation, alors que se plaindre de leur attitude ne l’est pas.

Qu'est-ce que la réplique canonique à "c'est open source, soumettre un patch"?

Il n'y a pas de réponse raisonnable susceptible de faire une différence. Essayer de persuader les volontaires de faire quelque chose qu'ils n'ont aucune intention de faire est une perte de temps ... ou pire.

Vos options sont:

• Faites ce que la réponse suggère. c'est-à-dire implémenter la fonctionnalité et la soumettre comme un correctif. Cela s'appelle "rendre quelque chose en retour".

• Trouvez quelqu'un qui serait prêt à mettre en œuvre la fonctionnalité pour vous avec de l'argent réel. Il peut s'agir du projet lui-même (par exemple en échange d'un parrainage), d'une personne associée au projet ou d'un "codeur à embaucher" aléatoire.

• Trouvez un produit alternatif.

Si vous avez reçu cette réponse lorsque vous avez fait une suggestion "utile", réfléchissez à la manière dont vous auriez pu réagir si vous étiez à sa place. Par exemple, comment répondriez-VOUS si vous pensiez que la suggestion n’était pas valable / bien réfléchie / intelligible / etc., mais n’aviez pas le temps ni la patience d’engager un débat prolongé?

J'ai été impliqué dans un projet d'exploitation open source de longue date, et l'un des problèmes les plus gênants concerne les personnes qui siègent dans la "galerie des arachides" et vous émeuvent de suggestions pour faire "mieux" les choses suivantes:

• sont incomplets, inintelligibles ou complètement insensés,
• sont des idées non essayées avec une chance de succès objectivement faible,
• nécessiterait des efforts considérables pour mettre en œuvre et / ou
• sont contraires aux objectifs déclarés du projet.

Souvent, la meilleure solution consiste à demander à la personne de s’impliquer de manière significative dans le projet… et d’espérer qu’elle profite de l’allusion… pour «se lever ou se taire». Malheureusement, les plus ennuyeux ne comprennent même pas.

Bien entendu, l'autre réponse à ces personnes est de ne pas répondre du tout ou de les ignorer complètement.

La réponse serait raisonnable si vous et le programmeur en question restiez égaux et saviez à peu près la même chose à propos de la base de code et du langage, ainsi que de tout ce qui concerne la chose que vous signalez.

Vous n'êtes pas égaux (ou vous l'auriez probablement fait), alors je suggérerais une réplique appropriée:

"Il est impossible que je puisse le faire aussi vite et bien que vous le pouvez, c'est pourquoi je vous ai demandé de m'aider en premier lieu. S'il vous plaît!"

Je pense qu’il est contraire à la nature humaine fondamentale de dire "Oh, oui, cette chose sur laquelle j’ai passé beaucoup de temps et est vraiment bonne, est si simple que quiconque peut venir de la rue et faire un aussi bon travail que moi. Je peux ".

La réplique canonique consiste à bifurquer le projet.

La réponse canonique à "soumettre un patch" est:

"Je n'ai ni les compétences, ni l'expérience ni le temps nécessaires, alors pouvez-vous s'il vous plaît me dire où envoyer les caisses de bière au gars qui peut le faire pour moi"

Soumettez un cas de test complet .

"Si vous le faites, je l'inclurai" est bien mieux que "non".

Si vous êtes incapable de faire le travail pour une raison ou une autre, expliquez la situation en privé au responsable du projet.

Si vous ne souhaitez pas contribuer de quelque manière que ce soit à un projet open source que vous souhaitez utiliser, vous devriez alors rechercher un support commercial ou un autre produit commercial.

"Merci pour la réponse."

Parce que:

• À prix nul, la demande (demandes de fonctionnalités) dépasse l'offre (codeurs disponibles pour implémenter lesdites fonctionnalités).
• Ragging sur tout ce qui est fourni gratuitement manque de classe IMHO.
• C’est le but principal de FOSS: les gens apportent des légumes et de la viande pour enrichir la soupe aux pierres. Si je ne peux pas contribuer à quelque chose, je devrais être reconnaissant de pouvoir manger du tout et de ne pas me plaindre de ne pas manger mieux.

Tu n'as rien à dire. Le fait même que les développeurs aient répondu indique suffisamment qu'ils savent déjà que le problème existe et que cela cause des difficultés pour (au moins certains) utilisateurs.

En fin de compte, rien de ce que vous dites ne convaincra le développeur de travailler pour vous s'il ne le souhaite pas.

Un bon projet open source aura un système de demande de bogue / fonctionnalité dans lequel les utilisateurs peuvent soumettre des bogues / fonctionnalités et d'autres peuvent voter sur eux afin que les responsables puissent identifier ce qui est important pour la communauté dans son ensemble. Cependant, le moyen le plus rapide de mettre votre fonctionnalité en place est de lui envoyer un correctif. Période ... aucun moyen de contourner cela.

Personnellement, je préférerais recevoir la réponse suivante: "C’est un problème connu, mais malheureusement, ce n’est pas un problème qui doit être résolu dans un avenir rapproché. Les développeurs travaillent sur d’autres problèmes. Il n’existe actuellement pas d’ETA."

La réponse "submit a patch" est très grossière, car elle suppose un certain nombre de choses:

1. Tous les utilisateurs du programme sont des programmeurs ou tous les rapporteurs de bogues sont des programmeurs.
2. Tous les programmeurs connaissent la langue du programme.
3. Tous les programmeurs connaissent tous les types de problèmes qu'un programme peut rencontrer.
4. Tous les programmeurs ont du temps libre pour travailler sur un projet open source.

Même si nous supposons que le fabricant de réponses «soumettre un correctif» connaît tout ce qui précède, cela donne simplement l’affirmation suivante: «X heures de mon temps valent plus que les ordres de grandeur que vous auriez à vous lever accélérer et résoudre le problème ".

Généralement, lorsque je reçois une réponse grossière d'un développeur lorsque je pose une question sur un problème que je rencontre ou que je soumets un bogue, je cesse d'utiliser ce programme.. Je n'utilise plus uTorrent (pas de source ouverte, mais le point reste inchangé), par exemple, parce que les réponses que j'ai obtenues sur leur forum de "support" étaient très grossières. J'ai soumis un problème que j'avais sur le forum de rapports de bugs. Le thread a été immédiatement verrouillé avec un lien vers un autre thread concernant un problème similaire, mais différent, dans un thread (qui était également verrouillé, bien sûr). Dans l'intervalle, j'ai ouvert un fil de discussion dans le forum de discussion générale pour demander si quelqu'un avait trouvé une solution de contournement au problème. Dans le temps qu'il a fallu pour sauvegarder ce fil et revenir en arrière et voir que mon premier fil avait été verrouillé, mon fil en général était verrouillé et mon compte de forum banni pour comportement perturbateur. J'ai désinstallé uTorrent et je n'y suis pas retourné depuis.

Rien que répondre à "envoyer un correctif" est une grossière OMI, mais quand même ... si vous utilisez un logiciel open source pour quelque chose de grave, vous devez être prêt à en prendre soin si le besoin s'en fait sentir.

Ce qui suit est basé sur un message de Jeremias Maerki (de la renommée Apache FOP):

Si quelque chose ne fonctionne pas pour vous, vous avez plusieurs options:

• Ceci est open source: vous pouvez le réparer vous-même.
• Si vous ne pouvez pas le réparer vous-même, vous pouvez attendre que quelqu'un ait du temps libre et pense que c'est amusant à mettre en œuvre.
• Si cela ne se produit pas, vous pouvez trouver ou embaucher quelqu'un pour le faire à votre place.

Je pense que c'est une version complète très valide de la réponse "submit a patch".

Chaque fois que je vois cela, je commence immédiatement à chercher un produit alternatif. Pour moi, c'est un signe dangereux que les responsables ne se soucient pas de leurs utilisateurs (mauvais si votre projet est utilisé partout) ou ont perdu tout intérêt pour le projet. Ces deux facteurs signifient généralement que le projet va mourir bientôt ou sera en proie à la stagnation, les développeurs refusant de faire avancer le projet.

(Notez que je ne dis pas que le tout premier rapport de bogue que vous voyez avec ce type de réponse est celui que vous générez. Vous devez examiner une tendance générale. Si la plupart des rapports de bogue se terminent par ce type de réponse, suivez ce conseil. c’est juste quelques-unes, alors ce sont probablement des demandes de fonctionnalités qui ne correspondent pas aux objectifs du projet ou qui sont extrêmement spécifiques à l’utilisation)

Comme @MainMa l'a dit, commencer à contribuer à un tout nouveau projet est très difficile. La plupart des développeurs ne comprennent pas cela, car ils travaillent sur le projet depuis des mois et des années et que cela leur semble logique. Cela peut parfois être une erreur honnête.

Je plaisante à l'occasion que les logiciels libres peuvent être gratuits comme dans la bière, libres comme dans le discours ou libres comme si vous en avez pour votre argent.

Bien que je le dise en plaisantant (je travaille pour une entreprise qui utilise beaucoup de logiciels libres), mais je pense qu’il ya une vérité là-dedans - si vous voulez un support de niveau commercial, vous devez soit utiliser un logiciel commercial avec un contrat de support approprié, soit trouver un support. solution logicielle open source qui vous permet ce niveau de support (généralement par le biais d'une personne payée pour le fournir, mais éventuellement par le biais de votre organisation employant ou affectant une ressource de développement pour y travailler).

"Soumettre un correctif" est exaspérant, mais il met en évidence quelque chose au sujet du logiciel libre et cela devrait peut-être rappeler que le logiciel libre ne convient pas à tout le monde dans toutes les situations, du moins pas sans vous assurer que vous disposez d'un solide interne, payé pour ou par la communauté).

Nous pensons souvent à un logiciel gratuit comme dans la bière mais pas à la parole (c'est un freeware non ouvert). C’est peut-être un cas où nous devrions penser au logiciel aussi librement que dans la parole mais pas comme dans la bière.

Passez à une alternative bien entretenue.

D'après mon expérience avec des projets open source bien entretenus, si vous créez un rapport de bogue ou une demande de fonctionnalité bien défini, il y a de fortes chances qu'il soit implémenté.

"Je ne peux travailler que sur une chose à la fois, mais je peux me plaindre de plusieurs choses à la fois. Je pense que les deux fonctions sont utiles." - akkartik sur ycombinator .

Je considère que quand on travaille sur un projet, en fournissant des versions et du support, un contrat de support tacite, implicite, entre le développeur et l'utilisateur commence à exister. Le développeur a assumé la responsabilité implicite de prendre en charge la base de code pour ses utilisateurs, y compris en ajoutant des fonctionnalités à la demande.

"Soumettre un patch", c'est à mon avis donner le doigt aux utilisateurs. C’est contextuel - parfois c’est tout simplement trop d’efforts à mettre en œuvre, parfois cela ruinerait le projet existant ou entraînerait une créatite chronique, ou une foule d’autres raisons. Mais en fin de compte, il dit: "Va te faire foutre, ne pas le faire". Ce qui, à mon sens, constitue, à un certain niveau, une violation de ce contrat tacite.

Il y a plusieurs façons de le faire.

• Proposition de fonction et vote. mais cela prend du temps.

• Faites-vous embaucher par une entreprise qui en a besoin pour faire le correctif. Évidemment, c'est la meilleure solution, mais préparez-vous à collaborer avec le créateur du logiciel open source que vous souhaitez mettre à niveau.

• Il est également important de savoir pourquoi la fonctionnalité n'est pas implémentée en premier lieu. Souvent, la fonctionnalité ne correspond pas au projet logiciel: l'équipe ne la souhaite pas, ne se sent pas nécessaire ou pense simplement que ce n'est pas la bonne façon de faire quelque chose. Dans ce cas, vous devez simplement créer le projet et le créer vous-même.

• Utilisez un logiciel propriétaire qui fait ce que vous voulez.

• N'oubliez pas que le logiciel POO facilite souvent le processus d'intégration d'une fonctionnalité.

• Se lamenter sur une liste de diffusion, sur irc ou sur un forum ne fera que déranger les programmeurs et donnera des munitions aux promoteurs de logiciels libres.

Vous ne pouvez rien dire qui le fasse faire. Après tout, pourquoi devrait-il? À la demande d'un utilisateur? Ce n'est pas une raison suffisante.

Mais , si vous pouvez collecter un nombre raisonnable d'utilisateurs et donner des raisons rationnelles ("Je le veux" n'est pas une raison rationnelle.) Pourquoi cette fonctionnalité pourrait-elle être utile .

Bien que, il y a aussi un cas particulier qui doit être considéré. C'est un dev. est fatigué de développer l'application, souhaitant lentement l'abandonner (a d'autres choses à faire), et il abandonne donc lentement les demandes de fonctionnalités. À part essayer de le convaincre de publier le code, dans ce cas, vous ne pouvez pratiquement rien faire, même en ce qui concerne ce qui précède.

Les projets open source en particulier sont favorables aux primes ou au financement du développement d'une fonctionnalité particulière, même si la nouvelle fonctionnalité ne parvient pas aux versions officielles.

De plus, oui, l'une des idées derrière la publication de l'open source est que tout le monde ait le droit et la responsabilité de faire sa propre contribution.

Avec des sources fermées, votre meilleure ressource consiste à rassembler auprès de la base d'utilisateurs un groupe important sur le plan statistique qui souhaite des solutions similaires à celles que vous souhaitez.

D'après mon expérience, cette réponse est généralement donnée si la demande de l'utilisateur ne correspond pas à l'objectif du projet. Cela se produit lorsque les gens pensent que vous allez mettre en œuvre tout ce qu'ils vous proposent, et même un peu plus - gratuitement, en open source et avec un bel avenir.

"Soumettre un correctif" est une réponse relativement grossière (et il faut bien sûr l'éviter. Surtout sous cette forme concise et précise. Il existe de nombreuses manières d'exprimer à peu près le même message - par exemple, "invitez" les utilisateurs à vous aider car vous n’avez pas le temps de le mettre en œuvre vous-même). Mais en l'état, c'est un indicateur clair de «cesser de perdre mon temps». En tant que tel, vous ne pouvez rien faire à ce sujet et il n’existe pas non plus de réponse «canonique».

La meilleure réponse à laquelle je puisse penser est de présenter un correctif . En supposant que votre correctif fonctionne, vous avez au moins prouvé que l’idée n’est pas totalement irréaliste. Habituellement, cela signifie que les responsables du projet réexamineront la proposition.

"soumettre un correctif" est un moyen légitime de chercher des idées qui ne correspondent pas aux objectifs du projet. Il est probablement préférable à long terme de simplement vous dire que l'idée est nulle ou que vous essayez d'utiliser le projet pour quelque chose qui dépasse le cadre prévu, mais "hé, si vous pensez que ce que vous demandez est si trivial, pourquoi ne pas Tentez-vous de l’intégrer dans notre base de code existante "est parfois approprié.

Si cela est mineur et vraiment utile aux utilisateurs prévus du projet, soumettez simplement le rapport de bogue, décrivez clairement le problème, indiquez les étapes à reproduire, indiquez que vous utilisez la version nocturne en cours, et ne le laissez pas.

Ce qui peut sembler être un simple changement mineur qui aiderait des tonnes d'utilisateurs peut en réalité être une douleur énorme que personne n'utiliserait à part vous. C'est le meilleur cas pour "soumettre un patch".

Il est également possible que vous ayez rencontré un cas tel que le réputé responsable de la glibc qui semble penser que son système est l’univers, que son interprétation des spécifications est la parole de dieu, et c’est tout de combien de personnes préféreraient autrement.

Je suggérerais de créer un projet pour implémenter la fonctionnalité sur des sites tels que RentACoder / ELance / etc, et de publier à ce sujet sur le forum du projet open source original. Tous les programmeurs des projets open source, y compris l'auteur, bénéficient désormais d'un incitatif financier pour prendre en compte votre requête.

Je me suis inscrit juste pour répondre à cette question.

Une réplique est-elle nécessaire? cette réponse est généralement utilisée lorsque le développeur est au courant du problème mais ne le considère pas aussi important.

Je vais vous donner un exemple en direct. Ubuntu a abandonné le support systray (mais peut être contourné par une liste blanche d'une application) et a ajouté de nouveaux indicateurs d'application. Certaines applications telles que jupiter s'appuyaient sur le support systray. Le développeur a donc parlé de workaournd au lieu d'ajouter le support app-indicateur. J'ai donc demandé au développeur d'ajouter le support app-indicateur, la réponse étant "Envoyez-nous des correctifs". en demandant la raison pour laquelle ils ont choisi de ne pas mettre cela en œuvre. il y avait ça

Je n'ai aucun intérêt à passer mon temps à construire du support pour une bibliothèque que je n'utiliserai jamais, simplement parce que quelqu'un qui a beaucoup d'argent l'exige, en listant ma capacité des applications à fonctionner correctement sur sa distribution Linux simplement parce qu'il le peut.

Si c’était un problème technique, j’agirais probablement, mais c’est une manoeuvre purement politique, alors non, je ne le pense pas.

Non, je vais juste la mettre en liste blanche

C'est suffisant. le développeur a des raisons de ne pas implémenter une fonctionnalité mais est prêt à accepter les correctifs. ce n'est pas vraiment impoli et offensif, il n'y avait donc pas besoin d'une réplique.

ligne de fond: la réplique canonique serait de soumettre le correctif mais si vous ne pouvez pas, il n’est pas nécessaire de répliquer.

Commencez une prime pour la fonctionnalité que vous souhaitez.

Vous pouvez également acheter le produit qui prétend faire exactement ce que vous voulez et abuser de son personnel de soutien lorsque vous découvrez que le marketing ne correspond pas à vos attentes.

Le mieux que je puisse penser est "tu crains".

Désolé, cela n’est évidemment pas très utile, mais je pense que cela n’est que l’une des situations malheureuses dans lesquelles l’utilisateur est complètement foutu. Un appel brutalement honnête à la conscience du développeur est un dernier effort.

Vous pouvez essayer de l' offre ( toux ) « dons » d'avoir votre problème à résoudre, mais je crains qu'une telle pratique si commune faite conduirait à une perte d'intégrité vraiment mauvais dans l'industrie, que des corrections de bugs ne doivent jamais être mis à profit, que ce soit pour Logiciel "gratuit" ou commercial.