Was ist die kanonische Erwiderung auf "Es ist Open Source, Reiche einen Patch ein"? [geschlossen]

Die Gefahr, jemals eine Funktion für ein Produkt vorzuschlagen, insbesondere Open Source, besteht darin, dass Sie die Antwort erhalten: "Warum machen Sie das nicht?".

Das ist gültig und es ist cool, dass Sie die Änderung selbst vornehmen können. Aber wir wissen praktisch, dass sich Produkte oft verbessern, wenn Programmierer auf die Stimme der Benutzer hören - auch wenn diese Benutzer andere Programmierer sind. Die effiziente Möglichkeit, diese Änderungen vorzunehmen, besteht darin, dass bereits jemand an dem Projekt arbeitet, der die Idee aufgreift und umsetzt.

Es gibt einige gebräuchliche Begriffe, die sich auf Softwareentwicklungsprobleme beziehen. zB Bikeshedding . Gibt es einen gebräuchlichen Begriff, der im Wesentlichen antwortet: "Ja, ich weiß, dass ich so gut wie alles auf der Welt ändern kann - sogar geschlossene Quellen. Ich könnte eingestellt werden und diesen Code schreiben. Aber in diesem Fall mache ich nur eine Beobachtung, die in der Tat nützlich sein kann für einen anderen Programmierer, der bereits gut geeignet ist, um diese Änderung einfach vorzunehmen - oder einfach nur Möglichkeiten allgemein zu diskutieren. "

[ps (ein paar Tage später) - Ich hätte darauf hinweisen sollen, dass "einen Patch einreichen" oft mit schiefem Humor gesagt wird, und ich suche eine angemessene witzige Antwort.]

Dies ist ein schwieriger Punkt: Da der Benutzer weder direkt noch indirekt für ein Produkt bezahlt, kann er die Implementierung einer Funktion nicht verlangen. Es ist nicht so, als ob Sie ein Stakeholder oder ein direkter Kunde wären, der das Produkt bestellt hat, und nicht einmal ein Endverbraucher eines kommerziellen Produkts.

Dies wird gesagt, „einen Patch einreichen“ ist keine gültige Antwort. Das ist nicht höflich. Das ist nicht richtig. Auch für ein Open Source Produkt. "Submit a Patch" ist die Kurzversion von:

"Es ist uns egal, ob Sie unser Produkt mögen oder nicht. Ändern Sie es, wenn Sie möchten, aber stören Sie uns nicht mit Ihren Kundenwünschen."

Was ist mit dem Einreichen eines Patches?

Nun, es ist nicht so einfach. Es zu tun:

• Sie müssen die Sprache (n) kennen, die im Open Source-Projekt verwendet werden.

• Sie müssen in der Lage sein, den Quellcode aus der Versionskontrolle zu laden, um ihn ändern zu können.

• Sie müssen alle korrekten Versionen von Build-Abhängigkeiten installiert haben (einschließlich Laufzeitbibliotheken und Build-Tools).

• Sie müssen in der Lage sein, diesen Quellcode zu kompilieren , was in einigen Fällen nicht so offensichtlich ist. Insbesondere wenn ein großes Projekt einige Stunden benötigt, um 482 Fehler und Tausende von Warnungen zu kompilieren und anzuzeigen, ist es möglicherweise mutig, nach der Quelle dieser Fehler zu suchen.

• Sie sollten sehr gut verstehen, wie das Projekt ausgeführt wird , wie der zu verwendende Codierungsstil ist, wie Unit-Tests usw. ausgeführt werden ), kann es sehr schwer sein.

• Sie müssen sich an das Projekt und an die Gewohnheiten der Entwickler anpassen, die sich aktiv am Projekt beteiligen. Wenn Sie beispielsweise .NET Framework 4 täglich verwenden, das Projekt jedoch .NET Framework 2.0 verwendet, können Sie weder LINQ noch Codeverträge oder andere Tausende neuer Funktionen der neuesten Versionen des Frameworks verwenden.

• Ihr Patch muss akzeptiert werden (es sei denn, Sie nehmen die Änderung nur für sich selbst vor, ohne die Absicht, sie mit der Community zu teilen).

Wenn Sie beabsichtigen, sich aktiv an dem Projekt zu beteiligen, können Sie all diese Dinge tun und Ihre Zeit dafür investieren. Wenn auf der anderen Seite nur ein nerviger kleiner Fehler oder eine einfache Funktion fehlt, die Tage, Wochen oder Monate damit verbringt, das Projekt zu studieren, ist es einfach unvernünftig, die Arbeit selbst in wenigen Minuten zu erledigen, es sei denn, Sie mögen es.

Gibt es also eine kanonische Erwiderung zu "Es ist Open Source, Reiche einen Patch ein"? Ich glaube nicht Entweder erklärst du der Person, dass sie unhöflich ist, oder du hörst einfach auf, mit ihr zu reden.

Die kanonische Retorte besteht darin, einen Patch einzureichen.

Dies ist die Standardantwort, wenn Entwickler nicht glauben, dass sie in einem vernünftigen Zeitrahmen etwas tun können, aber sie wurde wiederholt angesprochen.

Es ist am unfairsten, wenn es wiederholt zur Sprache gebracht wird, aber die Person, die es zuletzt erwähnt hat, weiß das nicht und bekommt sofort die Meldung "Wir nehmen Patches dafür". In diesem Fall hat der Betreuer die Diskussion satt, aber der Benutzer denkt, dass es sich um ein neues Thema handelt. Auf jeden Fall sollten Sie es höchstwahrscheinlich nicht persönlich nehmen, wenn Sie sofort "Patches nehmen", sondern in den Archiven und im Bug Tracker nachlesen, um weitere Informationen zu diesem Problem zu erhalten.

Wenn Sie wiederholt selbst eine Anfrage stellen, ist das "Nehmen von Patches" möglicherweise eine relativ höfliche Abzocke im Vergleich zu einigen weniger höflichen Alternativen ...

Und dann gibt es natürlich unhöfliche Betreuer, die "Patches nehmen" sagen, ohne jemals jemandem eine Erklärung zu geben, aber ich würde sagen, das ist eine Minderheit.

Wenn Sie jemals ein Open Source-Projekt mit vielen Benutzern unterhalten haben, wissen Sie, dass es 100-mal mehr Anfragen gibt, als die Betreuer jemals erhalten könnten. oder würde eine Menge anderer Benutzer stören oder einen anderen Fehler aufweisen, der nur sichtbar ist, wenn man das Projekt und die Codebasis global versteht. Oder manchmal gibt es nur Urteilsforderungen, und es braucht zu viel Zeit, um sich immer wieder zu streiten.

Die meisten Nicht-Open-Source-Unternehmen geben Ihnen überhaupt keinen Zugriff auf die Entwickler, und Sie erhalten lediglich die stille Behandlung oder eine höfliche, aber gefälschte Geschichte vom Kundensupport. Zumindest in Open Source haben Sie also einige Optionen (zahlen Sie jemanden, der das Feature codiert usw.), und während Entwickler vielleicht unhöflich sind, geben sie zumindest klare Antworten. Ich hätte lieber "nein" als das übliche "es steht auf unserer Roadmap ... [2 Jahre später] ... es steht immer noch auf unserer Roadmap", was ich von einer Reihe von Anbietern bekommen habe ...

Ich glaube also nicht, dass es eine Retorte gibt. Vielleicht ist der Open-Source-Betreuer nur sehr beschäftigt, vielleicht sind sie ein Idiot, aber so oder so haben sie wahrscheinlich einen schweren Job, und eine Debatte darüber, wer das letzte Wort hat, führt nirgendwo hin. Das Beste, was Sie tun können, ist auf irgendeine Weise beizutragen und zu versuchen, konstruktiv zu sein.

Möglicherweise handelt es sich nicht um Code, aber möglicherweise gibt es eine Menge Analyse- und Dokumentationsszenarien für Benutzer, die Sie durchführen können. Als ich den GNOME-Fenstermanager gewartet habe, war es oft hilfreich, ein Problem global unter Berücksichtigung aller Benutzer zu analysieren und die Probleme und Vor- und Nachteile sowie die Auswirkungen aus globaler Sicht aufzuschreiben.

(Stattdessen war es üblich, zu brennen, als ob sie der einzige Benutzer wären, der etwas ausmachte, und es gab keine Kompromisse. Und obwohl das großartig war und ein Datenpunkt war, gelang es mir oft, höflich zu bleiben oder ihr Problem zu lösen.) Flammen lässt nichts schneller passieren, sondern verwirrt Emotionen und verschwendet Zeit.

Der Grund, warum Sie diese Antwort erhalten, ist nicht, dass die Betreuer Idioten sind, sondern dass Sie sie nicht ausreichend davon überzeugt haben, dass sie an Ihrem Feature für Sie arbeiten .

Die beste Antwort ist, einen Dialog über den Wert Ihres Features für die gesamte Community zu beginnen , um zu sehen, ob Sie sie davon überzeugen können, ihre Meinung zu ändern. Vielleicht haben sie recht und wissen mehr über die Bedürfnisse ihrer eigenen Gemeinde als Sie - aber andererseits vielleicht auch nicht.

Wenn das Feature nur für Sie wertvoll und für die Community von geringem bis gar keinem Wert ist, finde ich, dass Geld ein hervorragender Motivator ist, während es sich über ihre Haltung nicht beschwert.

Was ist die kanonische Erwiderung auf "Es ist Open Source, Reiche einen Patch ein"?

Es gibt keine vernünftige Antwort, die einen Unterschied machen könnte. Der Versuch, Freiwillige zu überreden, etwas zu tun, was sie nicht vorhaben, ist Zeitverschwendung ... oder schlimmer.

Ihre Möglichkeiten sind:

• Mach, was die Antwort nahelegt. dh implementieren Sie das Feature und senden Sie es als Patch. Es heißt "etwas zurückgeben".

• Finden Sie jemanden, der bereit wäre, die Funktion für Sie für echtes Geld zu implementieren. Es kann sich um das Projekt selbst handeln (z. B. als Gegenleistung für Sponsoring), um jemanden, der mit dem Projekt in Verbindung steht, oder um einen zufälligen "Coder for Hire".

• Finden Sie ein alternatives Produkt.

Wenn Sie diese Antwort erhalten haben, als Sie einen "hilfreichen" Vorschlag gemacht haben, überlegen Sie, wie Sie möglicherweise reagiert haben, wenn Sie in seinen Schuhen stecken. Wie würden SIE beispielsweise reagieren, wenn Sie der Meinung wären, dass sich der Vorschlag nicht lohnt / durchdacht / verständlich / usw., aber nicht die Zeit oder die Geduld hatte, sich auf eine langwierige Debatte einzulassen?

Ich war an einem langjährigen Open-Source-OS-Projekt beteiligt, und eines der nervigsten Dinge sind die Leute, die in der "Erdnussgalerie" sitzen und Ihnen eine Reihe von Vorschlägen liefern, wie Sie Dinge "besser" machen können:

• unvollständig, unverständlich oder geradezu unsinnig sind,
• sind unerprobte Ideen mit objektiv geringen Erfolgschancen,
• eine enorme Menge an Aufwand zur Implementierung erfordern würde, und / oder
• stehen im Widerspruch zu den erklärten Zielen des Projekts.

Oft ist es die beste Antwort, die Person gezielt aufzufordern, sich an dem Projekt zu beteiligen ... und zu hoffen, dass sie den Hinweis auf "Aufgeben oder den Mund halten" versteht. Leider verstehen die Ärgerlichsten nicht einmal einen Hinweis.

Natürlich besteht die andere Antwort auf solche Leute darin, überhaupt nicht zu antworten oder sie vollständig zu ignorieren.

Die Antwort wäre angemessen, wenn Sie und der betreffende Programmierer gleich wären und die Codebasis, die Sprache und alle anderen für diese bestimmte Sache relevanten Dinge, auf die Sie hinweisen, in etwa gleich gut kennen.

Sie sind nicht gleichberechtigt (oder Sie hätten es wahrscheinlich einfach getan), daher würde ich eine angemessene Retorte vorschlagen:

"Ich kann es auf keinen Fall so schnell und gut machen wie du. Deshalb habe ich dich gebeten, mir zu helfen. Bitte!"

Ich glaube, dass es gegen die fundamentale menschliche Natur verstößt, zu sagen: "Oh, ja, diese Sache, für die ich lange Zeit gearbeitet habe und die ich wirklich gut kann, ist so einfach, dass jeder von der Straße hereinkommen und so gute Arbeit wie möglich leisten kann Ich kann ".

Die kanonische Retorte soll das Projekt verzweigen.

Die kanonische Antwort auf "Patch einreichen" lautet:

"Ich habe nicht die Fähigkeiten, die Erfahrung oder die Zeit, die ich benötige. Kannst du mir bitte sagen, wohin ich die Bierkisten an den Mann schicken soll, der das für mich tun kann?"

Reichen Sie einen umfassenden Testfall ein .

"Wenn Sie es tun, werde ich es einschließen" ist viel besser als "nein".

Wenn Sie die Arbeit aus dem einen oder anderen Grund nicht ausführen können, erklären Sie den Umstand dem Projektbetreuer unter vier Augen.

Wenn Sie nicht bereit sind, in irgendeiner Weise zu einem Open-Source-Projekt beizutragen, das Sie verwenden möchten, sollten Sie stattdessen nach kommerzieller Unterstützung oder einem anderen kommerziellen Produkt suchen.

"Danke für die Antwort."

Weil:

• Bei einem Preis von Null übersteigt die Nachfrage (Anforderungen nach Funktionen) das Angebot (verfügbare Codierer zum Implementieren dieser Funktionen).
• Wenn man auf irgendetwas herumwirbelt, das kostenlos zur Verfügung gestellt wird, fehlt IMHO die Klasse.
• Das ist der springende Punkt bei FOSS: Leute, die selbst Gemüse und Fleisch mitbringen, um die Steinsuppe zu nähren. Wenn ich nichts beitragen kann, sollte ich dankbar sein, dass ich überhaupt essen kann, und mich nicht darüber beklagen, dass ich nicht besser esse.

Du musst nichts sagen. Die Tatsache, dass die Entwickler geantwortet haben, ist ein Hinweis darauf, dass sie bereits wissen, dass das Problem besteht, und dass dies (zumindest einigen) Benutzern Schmerzen bereitet.

Letztendlich wird nichts, was Sie sagen, den Entwickler davon überzeugen, für Sie zu arbeiten, wenn er dies nicht möchte.

Ein gutes Open-Source-Projekt verfügt über ein System zur Anforderung von Fehlern / Features, in dem Benutzer Fehler / Features einreichen und andere über sie abstimmen können, damit die Betreuer erkennen können, was für die Community insgesamt wichtig ist. Der schnellste Weg, um Ihre Funktion zu implementieren, besteht darin, einen Patch dafür einzureichen. Periode ... daran führt kein Weg vorbei.

Persönlich würde ich eher die Antwort "Dies ist ein bekanntes Problem, aber es ist leider kein Problem, das in Kürze behoben wird. Entwickler arbeiten an anderen Problemen. Derzeit gibt es keine ETA."

Die Antwort "Patch einreichen" ist sehr unhöflich, da sie eine Reihe von Dingen voraussetzt:

1. Alle Benutzer des Programms sind Programmierer, oder alle Programmierer sind Programmierer.
2. Alle Programmierer kennen die Sprache, in der sich das Programm befindet.
3. Alle Programmierer kennen alle Probleme, die ein Programm haben könnte.
4. Alle Programmierer haben freie Zeit, um an einem Open-Source-Projekt zu arbeiten.

Selbst wenn wir davon ausgehen, dass der "Submit a Patch" -Antwortgeber all das oben Genannte weiß, klingt die Aussage einfach so, dass "X Stunden meiner Zeit mehr wert sind als die Größenordnungen mehr Stunden Ihrer Zeit, die Sie aufstehen möchten das Problem zu beschleunigen und zu beheben ".

Wenn ich von einem Entwickler eine unhöfliche Antwort bekomme, wenn ich nach einem Problem frage oder einen Fehler einreiche, stoppe ich im Allgemeinen die Verwendung dieses Programms. Ich benutze uTorrent nicht mehr (nicht Open Source, aber der Punkt bleibt), zum Beispiel, weil die Antworten, die ich in ihrem "Support" -Forum erhielt, so unhöflich waren. Ich habe ein Problem im Bug Reports-Forum gemeldet. Der Thread wurde sofort mit einem Link zu einem anderen Thread gesperrt, der sich auf ein ähnliches, aber anderes Thema in einem Thread bezog (der natürlich auch gesperrt war). In der Zwischenzeit habe ich im allgemeinen Diskussionsforum einen Thread geöffnet, in dem gefragt wurde, ob jemand eine Problemumgehung gefunden hat. In der Zeit, die es dauerte, um diesen Thread zu speichern und zu überprüfen, ob mein erster Thread gesperrt war, war mein Thread im Allgemeinen gesperrt und mein Forum-Account wegen störenden Verhaltens gesperrt. Ich habe uTorrent deinstalliert und bin seitdem nicht mehr zurück.

Das bloße Antworten auf "Submit a Patch" ist unhöflich, aber dennoch ... Wenn Sie Open-Source-Software für irgendetwas Ernstes verwenden, müssen Sie bereit sein, sich darum zu kümmern, falls dies erforderlich sein sollte.

Das Folgende basiert auf einem Beitrag von Jeremias Maerki (von Apache FOP):

Wenn etwas bei Ihnen nicht funktioniert, haben Sie mehrere Möglichkeiten:

• Dies ist Open Source: Sie können es selbst beheben.
• Wenn Sie das Problem nicht selbst beheben können, können Sie warten, bis jemand Zeit zur freien Verfügung hat und der Meinung ist, dass die Implementierung Spaß macht.
• Wenn dies nicht der Fall ist, können Sie jemanden finden oder einstellen, der dies für Sie erledigt.

Ich denke, es ist eine sehr gültige Vollversion der "Submit a Patch" -Antwort.

Jedes Mal, wenn ich das sehe, suche ich sofort nach einem alternativen Produkt. Für mich ist dies ein gefährliches Zeichen dafür, dass sich die Betreuer entweder nicht um ihre Benutzer kümmern (schlecht, wenn Ihr Projekt überall verwendet wird) oder das Interesse an dem Projekt verloren haben. Beides bedeutet normalerweise, dass das Projekt bald ausfällt oder von einer Stagnation geplagt wird, da die Entwickler sich weigern, das Projekt voranzutreiben

(Beachten Sie, dass ich nicht sage, dass der allererste Fehlerbericht, den Sie sehen, mit dieser Art von Antwort ausgeführt wird. Sie müssen sich einen allgemeinen Trend ansehen. Wenn die meisten Fehlerberichte mit dieser Art von Antwort enden, befolgen Sie diesen Rat. Wenn Es sind nur ein paar, dann handelt es sich höchstwahrscheinlich um Feature-Anfragen, die nicht den Projektzielen entsprechen oder extrem anwendungsspezifisch sind.

Wie @MainMa sagte, ist es sehr schwierig, einen Beitrag zu einem brandneuen Projekt zu leisten. Die meisten Entwickler verstehen das nicht, da sie seit Monaten / Jahren an dem Projekt arbeiten und es für sie sinnvoll ist. Dies kann manchmal ein ehrlicher Fehler sein.

Ich scherze gelegentlich, dass freie Software frei sein kann wie in Bier, frei wie in Sprache oder frei wie Sie bekommen, wofür Sie bezahlen.

Ich sage es zwar im Scherz (ich arbeite für ein Unternehmen, das viel OSS einsetzt), aber ich denke, dass es eine Wahrheit gibt - wenn Sie kommerziellen Support wünschen, müssen Sie entweder kommerzielle Software mit einem geeigneten Support-Angebot verwenden oder einen finden Open-Source-Softwarelösung, mit der Sie diesen Grad an Unterstützung erhalten (in der Regel durch eine Person, die dafür bezahlt wird, möglicherweise jedoch durch Ihr Unternehmen, das Entwicklungsressourcen für die Bearbeitung einsetzt oder zuweist).

"Einen Patch einreichen" ist ärgerlich, aber es hebt etwas über OSS hervor und sollte vielleicht daran erinnern, dass OSS nicht in jeder Situation für jeden geeignet ist, zumindest nicht, ohne sicherzustellen, dass Sie ein solides Support-Framework dafür haben (auch nicht) Inhouse, bezahlt für oder durch die Community).

Wir denken oft an Software, die kostenlos ist wie in Bier, aber nicht wie in Sprache (das ist nicht offene Freeware). Vielleicht ist dies ein Fall, in dem wir über die Software so frei wie in der Rede, aber nicht wie in Bier nachdenken sollten .

Wechseln Sie zu einer gut gewarteten Alternative.

Aus meiner Erfahrung mit gut gepflegten Open-Source-Projekten geht hervor, dass wenn Sie einen gut definierten Fehlerbericht oder eine Feature-Anfrage erstellen, die Wahrscheinlichkeit sehr hoch ist, dass diese implementiert werden.

"Ich kann immer nur an einer Sache arbeiten, aber ich kann mich über viele Dinge gleichzeitig beschweren. Ich denke, beide Funktionen sind nützlich." - akkartik auf ycombinator .

Ich denke, wenn man an einem Projekt arbeitet und Releases und Support anbietet, entsteht ein unausgesprochener, impliziter Supportvertrag zwischen Entwickler und Benutzer. Der Entwickler hat die implizite Verantwortung übernommen, die Codebasis für seine Benutzer zu unterstützen, einschließlich des Hinzufügens von Funktionen auf Anfrage.

"Einen Patch einreichen" bedeutet meiner Meinung nach im Grunde genommen, den Benutzern den Finger zu geben. Dies ist kontextabhängig - manchmal ist die Implementierung zu aufwendig, manchmal würde das vorhandene Projekt zerstört oder es kommt zu einer schwachen Kreaturitis oder einer Reihe anderer Gründe. Aber letztendlich heißt es: "Scheiß auf dich, tu es nicht". In meinen Augen ist dies in gewisser Weise ein Verstoß gegen diesen unausgesprochenen Vertrag.

Es gibt verschiedene Möglichkeiten, dies zu tun.

• Feature-Vorschlag und Abstimmung. aber das braucht Zeit.

• Lassen Sie sich von einer Firma einstellen, die das Patch benötigt. Dies ist natürlich die beste Lösung, aber machen Sie sich bereit, mit demjenigen zusammenzuarbeiten, der die Open Source-Software herstellt, die Sie aktualisieren möchten.

• Es ist auch wichtig herauszufinden, warum die Funktion überhaupt nicht implementiert ist. Oft ist die Funktion nicht in der Linie des Softwareprojekts: Das Team möchte diese Funktion nicht, fühlt sich nicht notwendig oder denkt nur, dass dies nicht der richtige Weg ist, etwas zu tun. In diesem Fall sollten Sie das Projekt einfach teilen und selbst erstellen.

• Verwenden Sie proprietäre Software, die genau das tut, was Sie wollen.

• Denken Sie daran, dass OOP-Software die Integration eines Features häufig vereinfacht.

• Jammern auf einer Mailingliste, im Internet oder in einem Forum wird nur Programmierer verärgern und OSS-Befürwortern Munition geben.

Sie können nichts sagen, was ihn dazu bringt , es zu tun. Warum sollte er schließlich? Aufgrund der Wünsche eines Benutzers? Es ist nicht gut genug, ein Grund.

Aber wenn Sie eine vernünftige Anzahl von Benutzern sammeln und vernünftige Gründe angeben können ("Ich will es" ist kein vernünftiger Grund), warum diese Funktion im Allgemeinen nützlich sein könnte, und für Sie und die Anzahl anderer könnte er einfach seine Meinung ändern .

Es gibt jedoch auch einen Sonderfall, der berücksichtigt werden muss. Das ist ein Entwickler. Es ist ihm leid, die App zu entwickeln, und er möchte sie langsam verlassen (es gibt noch andere Dinge zu tun). Daher setzt er Feature-Anforderungen langsam außer Kraft. Abgesehen davon, dass er versucht, ihn davon zu überzeugen, den Code freizugeben, gibt es in diesem Fall praktisch nichts, was Sie tun können, selbst in Bezug auf das oben Gesagte.

Insbesondere Open-Source-Projekte sind für die Entwicklung eines bestimmten Features oder für die Finanzierung derselben freundlich, auch wenn das neue Feature es nicht bis zu den offiziellen Releases schafft.

Ja, eine der Ideen, die hinter dem Veröffentlichen von Open Source stehen, ist, dass jeder und jede das Recht und die Verantwortung hat, seine eigenen Beiträge zu leisten.

Bei geschlossenen Quellen besteht Ihre beste Ressource darin, eine statistisch wichtige Gruppe aus der Benutzerbasis zusammenzustellen, die nach Lösungen sucht, die Ihren Vorstellungen entsprechen.

Nach meiner Erfahrung wird diese Antwort normalerweise gegeben, wenn die Benutzeranforderung nicht zum Projektziel passt. Es passiert, wenn die Leute denken, dass Sie alles umsetzen werden, was sie Ihnen vorschlagen, und ein bisschen mehr - kostenlos, Open Source und eine großartige und glückliche Zukunft.

Das Einreichen eines Patches ist eine relativ unhöfliche Antwort (und sollte natürlich vermieden werden. Besonders in dieser präzisen und scharfen Form. Es gibt viele Möglichkeiten, ungefähr die gleiche Nachricht auszudrücken - zum Beispiel, die Benutzer zu Hilfe einzuladen, weil Sie helfen Ich habe keine Zeit, es selbst zu implementieren. Aber so wie es ist, ist es ein klarer Indikator dafür, dass ich keine Zeit verschwenden muss. Daher kann man nicht viel dagegen tun, und es gibt auch keine „kanonische“ Reaktion.

Die beste Antwort, die ich mir vorstellen kann, ist, tatsächlich einen Patch zu präsentieren . Angenommen, Ihr Patch funktioniert, haben Sie zumindest bewiesen, dass die Idee nicht völlig unrealistisch ist. In der Regel bedeutet dies, dass die für das Projekt Verantwortlichen den Vorschlag erneut prüfen.

"Submit a Patch" ist eine legitime Lösung für Ideen, die nicht in die Ziele des Projekts passen. Auf lange Sicht ist es wahrscheinlich besser, Ihnen zu sagen, dass die Idee scheiße ist, oder dass Sie versuchen, das Projekt für etwas zu verwenden, das weit über den beabsichtigten Umfang hinausgeht. t Sie versuchen, es in unsere vorhandene Codebasis einzupassen "ist manchmal angemessen.

Wenn es geringfügig ist und für die beabsichtigten Benutzer des Projekts wirklich von Nutzen ist, reichen Sie einfach den Fehlerbericht ein, beschreiben Sie das Problem klar, geben Sie Schritte zur Reproduktion an, geben Sie an, dass Sie den aktuellen nächtlichen Build verwenden, und belassen Sie ihn dabei.

Was wie eine kleine einfache Änderung scheint, die Tonnen von Benutzern helfen würde, kann tatsächlich ein großer Schmerz im Arsch sein, den niemand außer Ihnen verwenden würde. Das ist der beste Fall für "Submit a Patch".

Es ist auch möglich, dass Sie auf einen Fall wie den notorischen Glibc-Betreuer gestoßen sind, der den Eindruck zu haben scheint, sein System sei das Universum, seine Interpretation von Spezifikationen sei das Wort Gottes, und das ist alles, was es dafür gibt von wievielen Leuten würde es anders bevorzugen.

Ich würde vorschlagen, ein Projekt für die Implementierung der Funktion auf Websites wie RentACoder / ELance / etc zu erstellen und darüber im Forum des ursprünglichen Open Source-Projekts zu posten. Alle Programmierer der Open Source-Projekte, einschließlich des Autors, haben jetzt einen finanziellen Anreiz, Ihre Anfrage zu prüfen.

Ich habe mich angemeldet, um diese Frage zu beantworten.

Ist eine Retorte erforderlich? Diese Antwort wird normalerweise verwendet, wenn der Entwickler das Problem kennt, es aber nicht für wichtig hält.

Ich werde Ihnen ein lebendes Beispiel geben. ubuntu hat die Systray-Unterstützung eingestellt (kann aber durch das Auflisten einer App umgangen werden) und neue App-Indikatoren hinzugefügt. Einige Apps wie Jupiter verließen sich auf Systray-Unterstützung, sodass der Entwickler über die Arbeit berichtete. Statt Unterstützung für App-Indikatoren hinzuzufügen, bat ich den Entwickler, die App-Indikator-Unterstützung hinzuzufügen. Die Antwort lautete "Senden Sie uns Patches". auf die Frage, warum sie sich entschieden haben, dies nicht umzusetzen. da war das

Ich habe kein Interesse daran, meine Zeit damit zu verbringen, Unterstützung für eine Bibliothek aufzubauen, die ich niemals nutzen werde, nur weil es jemand mit viel Geld verlangt, indem er die Fähigkeit meiner Anwendungen, auf seiner Linux-Distribution ordnungsgemäß zu funktionieren, auf eine schwarze Liste setzt, nur weil er es kann.

Wenn es ein echtes technisches Problem wäre, würde ich wahrscheinlich Maßnahmen ergreifen, aber dies ist nur ein politisches Manöver, also nein, ich glaube nicht.

Nein, ich werde es nur auf die Whitelist setzen

Fair genug. Der Entwickler hat Grund, ein Feature nicht zu implementieren, ist aber bereit, Patches zu akzeptieren. Dies ist nicht wirklich unhöflich und beleidigend, so dass es keiner Retorte bedurfte.

Fazit: Die kanonische Retorte besteht darin, den Patch einzureichen. Wenn dies nicht möglich ist, ist keine Retorte erforderlich

Starten Sie ein Kopfgeld für die gewünschte Funktion.

Oder kaufen Sie das Produkt, das behauptet, genau das zu tun, was Sie wollen, und missbrauchen Sie das Support-Personal, wenn Sie feststellen, dass das Marketing nicht Ihren Erwartungen entspricht.

Das Beste, was mir einfällt, ist "du saugst".

Tut mir leid, das ist offensichtlich nicht sehr hilfreich, aber ich denke, dies ist nur eine der unglücklichen Situationen, in denen der Benutzer komplett durchgeknallt ist. Ein brutal ehrlicher Appell an das Gewissen des Entwicklers ist eine letzte Anstrengung.

Sie könnten versuchen, "Spenden" anzubieten ( Husten ), um Ihr Problem anzugehen, aber ich befürchte, dass eine solche Praxis, wenn sie verbreitet wird, zu einem wirklich schlimmen Integritätsverlust in der Branche führen würde, da Bugfixes niemals rentabel gemacht werden sollten, auch nicht für "Freie" oder kommerzielle Software.