it-swarm-eu.dev

Was ist die kanonische Antwort auf "Es ist Open Source, einen Patch einreichen"?

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

Das ist gültig und es ist cool, dass Sie die Änderung selbst vornehmen können. Wir wissen jedoch praktisch, dass sich Produkte häufig verbessern, wenn Programmierer auf die Stimme der Benutzer hören - selbst wenn diese Benutzer andere Programmierer sind. Zu den effizienten Methoden, um diese Änderungen vorzunehmen, kann jemand gehören, der bereits an dem Projekt arbeitet, das die Idee aufgreift und umsetzt.

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

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

217
Vincent Scheib

Es ist ein schwieriger Punkt: Da der Benutzer nicht direkt oder indirekt für ein Produkt bezahlt, kann er nicht verlangen, dass eine Funktion implementiert wird. Es ist nicht so, als wären Sie ein Stakeholder oder ein direkter Kunde, der das Produkt bestellt hat, und nicht einmal ein Endbenutzer eines kommerziellen Produkts.

Dies wird gesagt: "Patch einreichen" ist keine gültige Antwort. Es ist nicht höflich. Es ist nicht korrekt. Selbst für ein Open Source-Produkt. "Patch einreichen" ist die Kurzversion von:

"Es ist uns egal, ob Ihnen unser Produkt gefällt oder nicht. Ändern Sie es, wenn Sie möchten, aber stören Sie uns nicht an Ihren Kundenwünschen."

Was ist mit dem Einreichen eines Patches?

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

  • Sie müssen die im Open Source-Projekt verwendeten Sprachen kennen.

  • 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 aller 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, können Sie mutig sein, nach der Quelle dieser Fehler zu suchen.

  • Sie sollten sehr gut verstehen, wie das Projekt durchgeführt wird, welcher Codierungsstil ist gegebenenfalls zu verwenden, wie Unit-Tests ausgeführt werden usw. Wenn das Projekt keine anständige Dokumentation hat (was ist) oft der Fall bei Open Source-Projekten), kann es sehr schwierig sein.

  • Sie müssen sich an das Projekt und an die Gewohnheiten der Entwickler anpassen, die aktiv am Projekt teilnehmen. 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 aktiv am Projekt teilnehmen möchten, können Sie all diese Dinge tun und Ihre Zeit dafür investieren. Wenn andererseits nur ein nerviger kleiner Fehler oder eine einfache Funktion fehlt, die Tage, Wochen oder Monate damit verbringen, 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 auf "Es ist Open Source, einen Patch einreichen"? Das glaube ich nicht. Entweder erklärst du der Person, dass sie unhöflich ist, oder du hörst einfach auf, mit ihr zu reden.

116

Die kanonische Retorte besteht darin, einen Patch einzureichen.

79
wnoise

Dies ist die Standardantwort, wenn Entwickler nicht glauben, dass sie in einem angemessenen Zeitrahmen etwas unternehmen können, aber es wurde wiederholt darauf hingewiesen.

Es ist am unfairsten, wenn es wiederholt erwähnt wird, aber die Person, die es zuletzt erwähnt hat, weiß das nicht und bekommt sofort "wir nehmen Patches dafür". In diesem Fall hat der Betreuer die Diskussion satt, aber der Benutzer hält es für ein neues Thema. Auf jeden Fall sollten Sie, wenn Sie sofort "Patches nehmen", diese nicht persönlich nehmen, sondern die Archive und den Bug-Tracker lesen, um weitere Informationen zu diesem Problem zu erhalten.

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

Und dann gibt es natürlich unhöfliche Betreuer, die sagen, dass sie "Patches nehmen", 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 gepflegt haben, wissen Sie, dass es 100x mehr Anfragen gibt, als die Betreuer jemals erhalten könnten, und viele dieser Anfragen sind für den Anforderer wichtig, aber äußerst schwierig. oder würde viele andere Benutzer stören oder einen anderen Fehler aufweisen, der nur bei einem globalen Verständnis des Projekts und der Codebasis sichtbar ist. Oder manchmal gibt es nur Urteilsforderungen, und es dauert zu lange, um sich immer wieder zu streiten.

Die meisten Nicht-Open-Source-Unternehmen gewähren Ihnen überhaupt keinen Zugriff auf die Entwickler, und Sie erhalten nur die stille Behandlung oder eine höfliche, aber falsche Geschichte vom Kundensupport. Zumindest in Open Source haben Sie also einige Optionen (zahlen Sie jemanden, der die Funktion codiert usw.), und während Entwickler möglicherweise 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 harten Job und eine Debatte darüber, wer das letzte Wort hat, führt nirgendwo hin. Das Beste, was Sie tun können, ist, einen Beitrag zu leisten und zu versuchen, konstruktiv zu sein.

Vielleicht ist es kein Code, aber möglicherweise gibt es eine Menge Analyse- und Dokumentationsszenarien, die Sie durchführen können. Als ich den GNOME-Fenstermanager gewartet habe, wäre es oft hilfreich gewesen, ein Problem global zu analysieren und dabei alle Benutzer zu berücksichtigen und die Probleme und Vor- und Nachteile sowie das, was passieren sollte, wirklich aufzuschreiben aus einer globalen Perspektive.

(Stattdessen war es üblich, zu flammen, als ob sie der einzige Benutzer wären, der wichtig wäre, 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 irgendwann sogar zu lösen. Das Flammen lässt nichts schneller passieren. Es verwirrt nur die Emotionen in das Thema und verschwendet die Zeit aller.)

67
Havoc P

Der Grund, warum Sie diese Antwort erhalten, ist nicht, dass die Betreuer Idioten sind, sondern dass Sie sie nicht ausreichend von dem Wertversprechen überzeugt haben, mit dem sie arbeiten Ihre Funktion für Sie .

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 vielleicht auch nicht.

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

43
Rein Henrichs

Was ist die kanonische Antwort auf "Es ist Open Source, einen Patch einreichen"?

Es gibt keine vernünftige Retorte, die wahrscheinlich einen Unterschied macht. Der Versuch, Freiwillige zu etwas zu überreden, von dem sie nicht beabsichtigen, ist Zeitverschwendung ... oder noch schlimmer.

Ihre Optionen sind:

  • Tun Sie, was die Antwort vorschlägt. d.h. die Funktion implementieren und als Patch einreichen. Es heißt "etwas zurückgeben".

  • Finden Sie jemanden, der bereit wäre, die Funktion für echtes Geld für Sie zu implementieren. Es kann sich um das Projekt selbst handeln (z. B. als Gegenleistung für Sponsoring), um jemanden, der mit dem Projekt verbunden ist, oder um einen zufälligen "Codierer zum Mieten".

  • 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 zum Beispiel reagieren, wenn Sie der Meinung wären, dass der Vorschlag nicht lohnenswert/durchdacht/verständlich/usw. ist, aber nicht die Zeit oder Geduld hat, sich auf eine langwierige Debatte einzulassen?


Ich war an einem langjährigen Open-Source-OS-Projekt beteiligt, und eines der nervigsten Dinge sind Leute, die in der "Erdnussgalerie" sitzen und Sie mit einer Reihe von Vorschlägen über "bessere" Dinge überraschen:

  • unvollständig, unverständlich oder geradezu unsinnig sind,
  • sind unerprobte Ideen mit einer objektiv geringen Erfolgschance,
  • würde einen enormen Aufwand erfordern, um zu implementieren, und/oder
  • widersprechen den erklärten Zielen des Projekts.

Oft ist die beste Antwort, die Person gezielt herauszufordern, sich an dem Projekt zu beteiligen ... und zu hoffen, dass sie den Hinweis versteht ... "die Klappe zu halten oder die Klappe zu halten". Leider nehmen die nervigsten nicht einmal einen Hinweis.

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

31
Stephen C

Die Antwort wäre vernünftig, wenn Sie und der betreffende Programmierer gleich wären und genau das Gleiche über die Codebasis und die Sprache sowie alle anderen Dinge wüssten, die für diese bestimmte Sache relevant sind, auf die Sie hinweisen.

Sie sind nicht gleich (oder Sie hätten es wahrscheinlich einfach getan), also würde ich eine richtige Retorte vorschlagen:

"Auf keinen Fall kann ich es so schnell und gut wie möglich machen, deshalb habe ich dich gebeten, mir überhaupt zu helfen. Bitte!"

Ich glaube, dass es gegen die grundlegende menschliche Natur verstößt, dann zu sagen: "Oh ja, diese Sache, an der ich lange gearbeitet habe und die ich wirklich gut kann, ist so einfach, dass jeder von der Straße kommen und so gute Arbeit leisten kann wie." [~ # ~] i [~ # ~] kann ".

20
user1249

Die kanonische Retorte besteht darin, das Projekt zu teilen.

16
user16764

Die kanonische Antwort auf "Einreichen eines Patches" lautet:

"Ich habe nicht die Fähigkeiten, Erfahrung oder Zeit, die erforderlich sind. Können Sie mir bitte sagen, wohin ich die Bierkisten an den Mann schicken soll, der das für mich tun kann?"

15
gbjbaanb

Senden Sie ein umfassendes Testfall.

13
alecco

"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 dem Projektbetreuer den Umstand privat.

Wenn Sie nicht bereit sind, einen Beitrag zu einem Open-Source-Projekt zu leisten, das Sie verwenden möchten, sollten Sie stattdessen nach kommerziellem Support oder einem anderen kommerziellen Produkt suchen.

11
yfeldblum

"Danke für die Antwort."

Weil:

  • Bei einem Preis von Null übersteigt die Nachfrage (Anforderungen für Funktionen) das Angebot (verfügbare Codierer zur Implementierung dieser Funktionen).
  • Ragging auf alles, was kostenlos zur Verfügung gestellt wird, fehlt Klasse IMHO.
  • Das ist der springende Punkt von FOSS: Menschen, die eigenes Gemüse und Fleisch mitbringen, um die Steinsuppe mit Nährstoffen zu versorgen. Wenn ich nichts beitragen kann, sollte ich dankbar sein, dass ich überhaupt essen kann, und mich nicht beschweren, dass ich nicht besser esse.
10
John

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.

Am Ende des Tages wird nichts, was Sie sagen, den Entwickler davon überzeugen, für Sie zu arbeiten, wenn er nicht möchte.

9
Dean Harding

Ein gutes Open-Source-Projekt verfügt über ein Fehler-/Funktionsanforderungssystem, in dem Benutzer Fehler/Funktionen einreichen und andere darüber abstimmen können, damit die Betreuer erkennen können, was für die gesamte Community wichtig ist. Der schnellste Weg, um Ihre Funktion einzurichten, besteht darin, einen Patch dafür einzureichen. Punkt ... kein Weg daran vorbei.

9
Michael Brown

Nur auf "Submit a Patch" zu antworten, ist unhöflich, IMO, 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 für Sie 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 Freizeit 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 Antwort "Patch einreichen".

8

Persönlich würde ich lieber die Antwort erhalten: "Dies ist ein bekanntes Problem, aber leider wird es nicht in Kürze behoben. 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 Fehlerreporter sind Programmierer.
  2. Alle Programmierer kennen die Sprache, in der sich das Programm befindet.
  3. Alle Programmierer kennen alle Arten von Problemen, die ein Programm jeglicher Art haben könnte.
  4. Alle Programmierer haben freie Zeit, um an einem Open Source-Projekt zu arbeiten.

Selbst wenn wir davon ausgehen, dass der Antwortgeber "Patch einreichen" alles oben Genannte weiß, klingt die Aussage einfach so: "X Stunden meiner Zeit sind mehr wert als die Größenordnungen mehr Stunden Ihrer Zeit, die Sie aufstehen würden um 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, benutze dieses Programm nicht mehr. Ich verwende uTorrent zum Beispiel nicht mehr (nicht Open Source, aber der Punkt bleibt), weil die Antworten, die ich in ihrem "Support" -Forum erhalten habe, so unhöflich waren. Ich habe ein Problem im Bug Reports-Forum eingereicht. Der Thread wurde sofort mit einem Link zu einem anderen Thread über ein ähnliches, aber anderes Problem in einem Thread gesperrt (das natürlich auch gesperrt war). In der Zwischenzeit habe ich im Forum für allgemeine Diskussionen einen Thread geöffnet, in dem ich gefragt wurde, ob jemand eine Problemumgehung für das Problem gefunden hat. In der Zeit, die benötigt wurde, um diesen Thread zu speichern und zurück zu gehen und festzustellen, dass mein erster Thread gesperrt war, wurde mein Thread im Allgemeinen gesperrt und mein Forenkonto wegen störenden Verhaltens gesperrt. Ich habe uTorrent deinstalliert und bin seitdem nicht mehr zurück.

8
Bacon Bits

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 stirbt oder von Stagnation geplagt wird, da Entwickler sich weigern, das Projekt voranzutreiben

(Beachten Sie, dass ich nicht sage, dass der allererste Fehlerbericht, den Sie mit dieser Art von Antwort sehen, ausgeführt wird. Sie müssen sich einen allgemeinen Trend ansehen. Wenn die meisten Fehlerberichte mit dieser Art von Antwort enden, befolgen Sie diese Ratschläge Es sind nur einige wenige, dann sind dies höchstwahrscheinlich Feature-Anfragen, die nicht den Projektzielen entsprechen oder extrem nutzungsspezifisch sind.

Wie @MainMa sagte, ist es sehr schwierig, zu einem brandneuen Projekt beizutragen. 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.

6
TheLQ

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 scherzhaft (ich arbeite für ein Unternehmen, das viel OSS verwendet), aber ich denke, dass es eine Wahrheit gibt - wenn Sie Support auf kommerzieller Ebene wünschen, müssen Sie entweder kommerzielle Software mit einem geeigneten Support-Deal verwenden oder einen finden Open-Source-Softwarelösung, die Ihnen dieses Maß an Support ermöglicht (normalerweise durch jemanden, der dafür bezahlt wird, aber möglicherweise durch Ihr Unternehmen, das Entwicklungsressourcen einsetzt oder zuweist, um daran zu arbeiten).

"Einreichen eines Patches" ist ärgerlich, hebt jedoch etwas über OSS hervor und sollte möglicherweise 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) intern, bezahlt für oder durch die Gemeinde).

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 Sprache nachdenken sollten, aber nicht wie in Bier.

3
Jon Hopkins

Wechseln Sie zu einer gepflegten Alternative.

Nach meiner Erfahrung mit gut gepflegten Open-Source-Projekten besteht eine sehr hohe Wahrscheinlichkeit, dass sie implementiert werden, wenn Sie einen genau definierten Fehlerbericht oder eine Feature-Anfrage erstellen.

2
vartec

Es gibt verschiedene Möglichkeiten, dies zu tun.

  • Feature Vorschlag und Abstimmung. aber das braucht Zeit.

  • Lassen Sie sich von einem Unternehmen einstellen, das es für die Erstellung des Patches benötigt. Natürlich ist dies 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 im Rahmen des Softwareprojekts enthalten: Das Team möchte diese Funktion nicht, fühlt sich nicht notwendig oder denkt nur, dass dies nicht der gute Weg ist, etwas zu tun. In diesem Fall sollten Sie das Projekt einfach abspalten und selbst erstellen.

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

  • Denken Sie daran, dass OOP Software die Integration einer Funktion häufig vereinfacht.

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

1
jokoon

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

1
Vincent Scheib

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

"Einen Patch einreichen" gibt meiner Meinung nach den Benutzern den Finger. Dies ist kontextabhängig - manchmal ist es einfach zu aufwendig, es umzusetzen, manchmal würde es das bestehende Projekt ruinieren oder eine feeping-Kreaturitis oder einen Host aus anderen Gründen verursachen. Aber letztendlich heißt es: "Scheiß auf dich, tu es nicht". Was meiner Meinung nach in gewisser Weise einen Verstoß gegen diesen unausgesprochenen Vertrag darstellt.

1
Paul Nathan

Ich würde vorschlagen, ein Projekt zur Implementierung der Funktion auf Websites wie RentACoder/ELance/etc zu erstellen und darüber im Forum des ursprünglichen Open Source-Projekts zu posten. Jeder Programmierer in den Open Source-Projekten, einschließlich des Autors, hat jetzt einen finanziellen Anreiz, Ihre Anfrage zu prüfen.

0
Renji Panicker

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

Aber , wenn Sie eine angemessene Anzahl von Benutzern sammeln und rationale Gründe angeben können ("Ich will es" ist kein rationaler Grund.), Warum diese Funktion dies könnte Seien Sie im Allgemeinen nützlich und für Sie und eine Reihe anderer könnte er seine Meinung ändern.

Es gibt jedoch auch einen Sonderfall, der berücksichtigt werden muss. Das ist ein Entwickler. ist es leid, die App zu entwickeln, möchte sie langsam aufgeben (hat andere Dinge zu tun), und so verzichtet er langsam auf Feature-Anfragen. Abgesehen davon, dass Sie versuchen, ihn davon zu überzeugen, den Code freizugeben, können Sie in diesem Fall praktisch nichts tun, selbst in Bezug auf die oben genannten Punkte.

0
Rook

Insbesondere Open-Source-Projekte sind freundlich zu Kopfgeldern oder zur Finanzierung der Entwicklung eines bestimmten Features, auch wenn das neue Feature es nicht zu den offiziellen Releases schafft.

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

Bei Closed Source besteht Ihre beste Ressource darin, eine statistisch wichtige Gruppe aus der Benutzerbasis zusammenzustellen, die Lösungen wie die gewünschten wünscht.

0
Apalala

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

"Einen Patch einreichen" ist eine relativ unhöfliche Antwort (und sollte natürlich vermieden werden. Insbesondere in dieser prägnanten und scharfen Form. Es gibt viele Möglichkeiten, ungefähr dieselbe Nachricht auszudrücken - zum Beispiel die Benutzer "einzuladen", um Ihnen zu helfen Sie haben keine Zeit, es selbst zu implementieren. Aber so wie es ist, ist es ein klarer Indikator für "Verschwenden Sie keine Zeit mehr". Daher können Sie weder viel dagegen tun, noch gibt es eine „kanonische“ Antwort.

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 Personen den Vorschlag erneut prüfen.

0

"Submit a Patch" ist ein legitimer Pinsel für Ideen, die nicht in die Ziele des Projekts passen. Auf lange Sicht ist es wahrscheinlich besser, Ihnen nur zu sagen, dass die Idee scheiße ist, oder Sie versuchen, das Projekt für etwas zu verwenden, das weit außerhalb des beabsichtigten Umfangs liegt, aber "hey, wenn Sie denken, was Sie fragen, ist so trivial, warum nicht?" Wenn Sie versuchen, es in unsere vorhandene Codebasis zu integrieren, ist dies manchmal angemessen.

Wenn es für die beabsichtigten Benutzer des Projekts geringfügig und wirklich nützlich ist, senden Sie einfach den Fehlerbericht, 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 erscheint, 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 "Einreichen eines Patches".

Es ist auch möglich, dass Sie auf einen Fall wie den berüchtigten Glibc-Betreuer gestoßen sind, der den Eindruck zu haben scheint, sein System sei das Universum, seine Interpretation von Spezifikationen ist das Wort Gottes, und das ist alles, was dazu gehört, unabhängig davon von wie vielen Menschen würde anders bevorzugen.

0
Kevin Peterson