Qual è la risposta canonica a "è open source, invia una patch"? [chiuso]

È un punto difficile: poiché l'utente non paga direttamente o indirettamente un prodotto, non può chiedere che una funzionalità venga implementata. Non è come se tu fossi uno stakeholder o un cliente diretto che ha ordinato il prodotto, e nemmeno un utente finale di un prodotto commerciale.

Detto questo, "invia una patch" non è una risposta valida. Non è educato. Non è corretto Anche per un prodotto open source. "Submit a patch" è la versione breve di:

"we don't care if you like our product or not. Go and modify it if you want, but don't bother us with your customer requests."

Che ne dici di inviare una patch?

Beh, non è così facile. Per farlo:

• Devi conoscere la lingua o le lingue utilizzate nel progetto open source.

• Devi essere in grado di caricare il codice sorgente dal controllo di versione per poterlo modificare.

• Devi avere tutte le versioni corrette di tutte le dipendenze di build installate (incluse sia le librerie di runtime che gli strumenti di compilazione).

• Devi essere in grado di compilare questo codice sorgente , che in alcuni casi non è così ovvio. In particolare, quando un enorme progetto richiede alcune ore per compilare e visualizza 482 errori e migliaia di avvisi, potresti essere coraggioso e cercare l'origine di tali errori.

• Dovresti capire molto bene come è fatto il progetto , quali sono lo stile di codifica da usare, se esiste, come eseguire i test unitari, ecc. Se il progetto non ha una documentazione decente (che è spesso il caso per i progetti open source), potrebbe essere davvero difficile.

• Devi adattarti al progetto e alle abitudini degli sviluppatori che partecipano attivamente al progetto. Ad esempio, se si utilizza .NET Framework 4 tutti i giorni, ma il progetto utilizza .NET Framework 2.0, non è possibile utilizzare LINQ, né Contratti di codice né altre migliaia di nuove funzionalità delle ultime versioni del framework.

• La tua patch deve essere accettata (a meno che tu non faccia la modifica solo per te stesso, senza l'intento di condividerlo con la community).

Se la tua intenzione è di partecipare attivamente al progetto, allora puoi fare tutte quelle cose e investire il tuo tempo per questo. Se, d'altra parte, c'è solo un fastidioso bug secondario o una caratteristica semplice che manca, trascorrendo giorni, settimane o mesi a studiare il progetto, quindi fare il lavoro stesso in pochi minuti è irragionevole, a meno che non ti piaccia.

Quindi c'è una replica canonica a "è open source, invia una patch"? Io non la penso così O spieghi alla persona che è scortese, o semplicemente smetti di parlarle.

La replica canonica è di inviare una patch.

Questa è la risposta standard quando gli sviluppatori non pensano di riuscire a fare qualcosa in tempi ragionevoli, ma è stata ripetutamente sollevata.

È molto ingiusto quando è stato ripetutamente menzionato, ma la persona che ha menzionato più di recente non lo sa, e ottiene subito "stiamo prendendo le patch per questo" immediatamente. In questo caso il maintainer è stufo della discussione ma l'utente pensa che sia un nuovo argomento. Ad ogni modo, molto probabilmente se ottieni subito "patch", non dovresti prenderlo di persona ma potresti voler leggere gli archivi e il bug tracker per maggiori dettagli sul problema.

Se stai ripetutamente sollevando una richiesta tu stesso, "prendere patch" è potenzialmente inteso come un pennello relativamente educato, rispetto ad alcune alternative meno educate ...

E poi ovviamente ci sono maleducati manutentori che diranno "prendere patch" senza alcuna spiegazione a nessuno, ma direi che è una minoranza.

Se hai mai mantenuto un progetto open source con molti utenti, saprai che ci sono 100 volte più richieste di quelle che i manutentori potrebbero mai ottenere, e molte di queste richieste sono importanti per il richiedente ma sarebbero scandalosamente difficile, o disturberebbe molti altri utenti, o ha qualche altro difetto che è visibile solo con una comprensione globale del progetto e della base di codice. O a volte ci sono solo chiamate di giudizio, e ci vuole troppo tempo per discuterne ripetutamente.

La maggior parte delle aziende non open-source non ti dà affatto accesso agli sviluppatori, e riceverai il trattamento silenzioso o una storia gentile ma fasulla da parte dell'assistenza clienti. Quindi, nell'open source almeno hai alcune opzioni (paga qualcuno per codificare la funzione, ecc.) E mentre gli sviluppatori potrebbero essere scortesi, almeno danno risposte dirette. Preferirei avere "no" rispetto al solito "è sulla nostra tabella di marcia ... [2 anni dopo] ... è ancora sulla nostra tabella di marcia" tipo di cose che ho ottenuto da un certo numero di venditori ...

Quindi non penso ci sia una risposta. Forse il manutentore open source è davvero molto impegnato, forse è un cretino, ma in ogni caso, è probabile che abbiano un lavoro difficile e che il dibattito sulla "ultima parola" non vada da nessuna parte. Il meglio che puoi fare è contribuire in qualche modo e cercare di essere costruttivo.

Forse non è un codice, ma probabilmente c'è un sacco di analisi e documentazione degli scenari utente che potresti fare. Quando gestivo il gestore di finestre di GNOME, molte volte sarebbe stato utile per le persone analizzare un problema a livello globale considerando tutti gli utenti tutti e scrivere davvero i problemi, i pro ei contro e cosa dovrebbe accadere da una prospettiva globale.

(Invece, la solita cosa era cominciare a fiammeggiare come se fossero l'unico utente che contava e non c'erano compromessi.E mentre è fantastico, ed era un punto di accesso, e spesso sono riuscito a rimanere educato o addirittura a risolvere il loro problema alla fine ... la fiammata non fa accadere nulla più velocemente, ma confonde le emozioni nel problema e fa perdere tempo a tutti.)

Il motivo per cui ottieni questa risposta non è che i manutentori sono jerks, è che non li hai convinti adeguatamente della proposta di valore di loro che lavorano sulla tua caratteristica per te .

La migliore risposta è iniziare un dialogo sul valore della tua funzione alla loro intera comunità , per vedere se riesci a convincerli a cambiare idea. Forse hanno ragione e sanno di più sulle esigenze della propria comunità rispetto a te - ma, di nuovo, forse no.

Se la funzione è preziosa per te e di poco valore per la comunità, trovo che il denaro sia un eccellente motivatore, mentre non si lamenta del loro atteggiamento.

What's the canonical retort to “it's open source, submit a patch”?

Non esiste una risposta ragionevole che possa fare alcuna differenza. Cercare di convincere i volontari a fare qualcosa che non hanno intenzione di fare è uno spreco di tempo ... o peggio.

Le tue opzioni sono:

• Fai ciò che la risposta suggerisce; Ad esempio, implementare la funzione e inviarla come patch. Si chiama "restituire qualcosa".

• Trova qualcuno disposto a implementare la funzione per te con denaro reale. Potrebbe essere il progetto stesso (ad esempio in cambio della sponsorizzazione), qualcuno associato al progetto o qualche "coder a noleggio" casuale.

• Trova un prodotto alternativo.

Se hai ricevuto questa risposta quando hai fatto un suggerimento "utile", considera come potresti aver risposto se eri nei suoi panni. Ad esempio, come risponderebbe se pensassi che il suggerimento non è stato utile / ben pensato / intelligibile / ecc., Ma non ha avuto il tempo o la pazienza di impegnarsi in un dibattito protratto?

Sono stato coinvolto in un progetto OS open source di lunga durata, e una delle cose più fastidiose sono le persone che siedono nella "galleria di arachidi" e ti stuzzicano con un flusso di suggerimenti su come fare cose "migliori" che:

• sono incomplete, incomprensibili o addirittura prive di senso,
• sono idee non sperimentate con una probabilità obiettivamente bassa di successo,
• richiederebbe un enorme sforzo da implementare e / o
• sono in contrasto con gli obiettivi dichiarati del progetto.

Spesso la migliore risposta è quella di sfidare acutamente la persona a essere coinvolta nel progetto ... e spero che prendano il suggerimento ... di "mettere su o stare zitti". Sfortunatamente, i più fastidiosi non hanno nemmeno un suggerimento.

Ovviamente, l'altra risposta a queste persone è di non rispondere affatto o di ignorarle completamente.

La risposta sarebbe ragionevole se tu e il programmatore in questione fossero uguali, e sapessi quasi la stessa cosa riguardo al codice base e alla lingua e tutte le altre cose rilevanti per questa particolare cosa che stai facendo notare.

Non sei uguale (o probabilmente lo avresti appena fatto) quindi ti suggerirei una risposta corretta per essere:

"Non c'è modo che io possa farlo nel modo più veloce e buono possibile, ecco perché ti ho chiesto di aiutarmi in primo luogo. Per favore!"

Credo che sia contrario alla natura umana fondamentale dire "oh, sì, questa cosa su cui ho trascorso molto tempo ed è davvero brava, è così semplice che chiunque può entrare dalla strada e fare altrettanto bene un lavoro come I può ".

La replica canonica è quella di imporre il progetto.

La risposta canonica a "inviare una patch" è:

"I don't have the skills, experience or time required so can you please tell me where to ship the cases of beer to the guy who can do it for me"

Invia un test case completo.

"Se lo fai, lo includerò" è molto meglio di "no".

Se non riesci a svolgere il lavoro per un motivo o per un altro, spiega la circostanza al responsabile del progetto in privato.

Se non sei disposto a contribuire in qualche modo a un progetto open source che vorresti utilizzare, dovresti cercare invece un supporto commerciale o un altro prodotto commerciale.

"Grazie per la risposta."

A causa:

• A prezzo zero, la domanda (richieste di funzionalità) supera l'offerta (i programmatori disponibili per implementare le funzionalità).
• Stracciando tutto ciò che è fornito gratuitamente manca il codice IMHO.
• Questo è il punto focale di FOSS: persone che portano verdure e carne per aggiungere nutrizione alla zuppa di pietra. Se non posso contribuire a qualcosa, allora dovrei essere grato di poter mangiare, e non lamentarmi che non sto mangiando meglio.

Non devi dire nulla. Il fatto stesso che gli sviluppatori abbiano risposto è un'indicazione sufficiente a far loro già sapere che il problema esiste e che causa dolore per (almeno alcuni) utenti.

Alla fine della giornata, niente di ciò che dici convincerà lo sviluppatore a lavorare per te se non lo desidera.

Un buon progetto open source avrà un sistema di richiesta bug / funzionalità in cui gli utenti possono inviare bug / funzionalità e altri possono votare su di loro in modo che i manutentori possano identificare ciò che è importante per la comunità nel suo complesso. Il modo più rapido per ottenere la tua funzionalità è comunque di inviare una patch per questo. Periodo ... nessun modo per aggirare questo.

Personalmente, preferirei ricevere una risposta di "Questo è un problema noto, ma sfortunatamente non è un problema che verrà affrontato in tempi brevi, gli sviluppatori stanno lavorando su altre questioni, al momento non c'è ETA".

La risposta "invia una patch" è molto scortese, in quanto presuppone un certo numero di cose:

1. Tutti gli utenti del programma sono programmatori o tutti i segnalatori di bug sono programmatori.
2. Tutti i programmatori conoscono la lingua in cui si trova il programma.
3. Tutti i programmatori conoscono ogni tipo di problema che potrebbe avere un programma di qualsiasi tipo.
4. Tutti i programmatori hanno tempo libero per lavorare su un progetto open source.

Anche se ipotizziamo che il produttore di risposte "invia una patch" sappia tutto quanto sopra, ciò fa sembrare la frase "X ore del mio tempo vale più degli ordini di grandezza di più delle ore del tuo tempo per aumentare la velocità e risolvere il problema ".

In genere, quando ottengo una risposta maleducata da uno sviluppatore quando chiedo un problema, ho o inviato un bug, smetto di usare quel programma . Non uso più uTorrent (non open source, ma il punto rimane), ad esempio, perché le risposte che ho ricevuto sul loro forum di "supporto" sono state così scortese. Ho presentato un problema che avevo nel forum Bug Reports. Il thread è stato immediatamente bloccato con un collegamento a un altro thread relativo a un problema simile, ma diverso in un thread (che era anche bloccato, ovviamente). Nel frattempo, ho aperto una discussione nel forum di discussione generale chiedendo se qualcuno avesse trovato una soluzione al problema. Nel tempo impiegato per salvare quel thread e tornare indietro e vedere che il mio primo thread era stato bloccato, il mio thread in Generale era bloccato e il mio account forum vietato per comportamento distruttivo. Ho disinstallato uTorrent e non sono più tornato da allora.

Rispondere semplicemente "inviare una patch" è scortese IMO, ma comunque ... se usi software open source per qualcosa di serio, devi essere pronto a prenderti cura di lui in caso di necessità.

Quanto segue è basato su un post di Jeremias Maerki (di Apache FOP fama):

If something doesn't work for you, you have several options:

• This is open source: you can fix it yourself.
• If you cannot fix it yourself, you can wait until someone has free time and thinks it is fun to implement.
• If that doesn't happen, you can find or hire someone to do it for you.

Penso che sia una versione completa molto valida della risposta "submit a patch".

Ogni volta che vedo questo, inizio immediatamente a cercare un prodotto alternativo. Per me questo è un segno pericoloso che i manutentori o non si preoccupano dei loro utenti (male se il tuo progetto è usato ovunque) o hanno perso interesse nel progetto. Entrambi di solito indicano che il progetto morirà presto o sarà afflitto da stagnazione mentre gli sviluppatori si rifiutano di spostare il progetto in avanti

(Si noti che non sto dicendo che la prima segnalazione di bug che si vede con questo tipo di risposta si esegue.Si deve guardare una tendenza generale.Se la maggior parte delle segnalazioni di bug terminano con questo tipo di risposta, quindi seguire questo consiglio: se sono solo alcuni, allora sono molto probabilmente richieste caratteristiche che non si adattano agli obiettivi del progetto o sono estremamente specifiche per l'uso)

Come @MainMa ha detto che iniziare a contribuire a un nuovo progetto è molto difficile. La maggior parte degli sviluppatori non lo capisce perché hanno lavorato al progetto per mesi / anni e ha senso per loro. Questo a volte può essere un errore onesto.

Di tanto in tanto scherzo che il software gratuito può essere gratuito come nella birra, gratis come in una parola o gratuito, perché ottieni quello per cui paghi.

Mentre lo dico scherzosamente (lavoro per una società che usa un sacco di OSS) ma penso che ci sia una verità lì - se si desidera il supporto a livello commerciale, allora è necessario utilizzare un software commerciale con un adeguato accordo di supporto, oppure trovare una soluzione software open source che ti permetta di raggiungere quel livello di supporto (di solito attraverso qualcuno pagato per fornirlo ma potenzialmente attraverso la tua organizzazione che impiega o assegna risorse di sviluppo per lavorarci sopra).

"Invia una patch" è esasperante ma mette in evidenza qualcosa sull'OSS e forse dovrebbe ricordare che l'OSS non è giusto per tutti in ogni situazione, almeno non senza assicurarsi di avere un solido framework di supporto per (sia in-house, pagato per o attraverso la comunità).

Spesso pensiamo al software che è gratuito come nella birra, ma non come nel parlato (che è un freeware non aperto). Forse questo è un caso in cui dovremmo pensare al software gratuitamente come nel linguaggio, ma non come nella birra.

Passa a un'alternativa ben mantenuta.

Dalla mia esperienza con progetti open source ben mantenuti, è che se si crea una segnalazione bug o una richiesta di funzionalità ben definita, allora c'è una possibilità molto alta di essere implementata.

"Posso lavorare su una sola cosa alla volta, ma posso lamentarmi di molte cose contemporaneamente. Penso che entrambe le funzioni siano utili." - akkartik su ycombinator .

Considero che quando si lavora su un progetto, fornendo release e supporto, si crea un sottotesto, implicito e implicito contratto di supporto tra dev e user. Lo sviluppatore ha assunto l'implicita responsabilità di supportare il codebase per i suoi utenti, inclusa l'aggiunta di funzionalità su richiesta.

"Invia una patch" è fondamentalmente dare il dito agli utenti, a mio parere. Questo è contestuale - a volte è solo troppo sforzo da implementare, a volte distruggerebbe il progetto esistente o incorre in creaturitis che fa capolino, o in una serie di altri motivi. Ma, alla fine, sta dicendo: "fottiti, non farlo". Il che, a mio parere, è, a un certo livello, una violazione di quel contratto non dichiarato.

Ci sono diversi modi in cui dovrebbe essere fatto.

• Proponi proposta e vota. ma questo richiede tempo.

• Essere assunti da una società che ne ha bisogno per creare la patch. Ovviamente questa è la soluzione migliore, ma preparati a collaborare con il ragazzo che crea il software open source che desideri aggiornare.

• È importante scoprire perché la funzionalità non è implementata in primo luogo. Spesso la funzionalità è fuori dalla linea del progetto software: il team non vuole questa funzionalità, non si sente necessario o pensa solo che non sia il modo migliore per fare qualcosa. In questo caso dovresti semplicemente inserire il progetto e farlo da solo.

• Usa software proprietario che fa quello che vuoi.

• Ricorda che il software OOP spesso facilita il processo di integrazione di una funzione.

• Piagnucolare su una mailing list, su irc o in un forum, faranno solo girare i programmatori e daranno munizioni ai sostenitori dell'OSS.

Non c'è nulla che tu possa dire che faccia che lo faccia. Dopo tutto, perché dovrebbe? A causa dei desideri di un utente? Non è un buon motivo.

Ma , se puoi raccogliere un numero ragionevole di utenti e dare ragioni razionali ("Lo voglio" non è un motivo razionale.) perché questa funzione potrebbe essere utile, in generale e a te e il numero degli altri potrebbe solo cambiare idea.

Sebbene, ci sia anche un caso speciale che deve essere considerato. Quello dev. è stanco di sviluppare l'app, lentamente desiderando di abbandonarlo (ha altre cose da fare), e quindi sta lentamente rinunciando alle richieste di funzionalità. Oltre a cercare di convincerlo a rilasciare il codice, in questo caso non c'è praticamente nulla che tu possa fare, anche rispetto a quanto sopra.

I progetti open source, in particolare, sono amichevoli per le ricompense o il finanziamento dello sviluppo di una caratteristica particolare, anche se la nuova funzione non arriva ai comunicati ufficiali.

Inoltre, sì, una delle idee dietro la pubblicazione di open source è che chiunque e tutti abbiano il diritto e la responsabilità di dare il proprio contributo.

Con la fonte chiusa, la tua migliore risorsa è quella di riunire un gruppo statisticamente importante dalla base di utenti che desidera soluzioni come quelle che desideri.

Nella mia esperienza, questa risposta viene solitamente fornita se la richiesta dell'utente non si adatta all'obiettivo del progetto. Succede quando le persone pensano che implementerai tutto ciò che ti propongono, e un po 'di più - gratuitamente, open source e un futuro grande e felice.

'Submit a patch' è una risposta relativamente scortese (e dovrebbe essere evitata, ovviamente. Soprattutto in questa forma concisa e nitida Ci sono molti modi per esprimere approssimativamente lo stesso messaggio - per esempio "invita" gli utenti a aiuto perché non hai il tempo di implementarlo da solo). Ma così com'è, è un chiaro indicatore di "smettere di sprecare il mio tempo". In quanto tale, non c'è molto che si possa fare a riguardo, né c'è una risposta "canonica".

La risposta migliore che riesco a pensare è presentare effettivamente una patch . Supponendo che la tua patch funzioni, hai almeno dimostrato che l'idea non è del tutto irrealistica. Di solito, questo significa che i responsabili del progetto prenderanno nuovamente in considerazione la proposta.

"inviare una patch" è una scelta legittima per idee che non rientrano negli obiettivi del progetto. Probabilmente è meglio, a lungo andare, dirti solo che l'idea fa schifo o stai cercando di usare il progetto per qualcosa di molto al di fuori del suo scopo, ma "hey, se pensi che quello che stai chiedendo sia così banale, perché non farlo" Se cerchi di adattarlo al nostro codice esistente "è talvolta appropriato.

Se è minore e davvero utile agli utenti previsti del progetto, invia semplicemente la segnalazione di bug, descrivi chiaramente il problema, fornisci i passaggi per riprodurlo, indica che stai utilizzando la build notturna corrente e lasciala a che.

Quello che può sembrare un piccolo cambiamento semplice che potrebbe aiutare tonnellate di utenti in realtà potrebbe essere un enorme rompicoglioni che nessuno userebbe oltre a te. Questo è il caso migliore per "inviare una patch".

È anche possibile che tu abbia imbattuto in un caso come il famigerato manutentore di glibc che sembra avere una mente a una sola traccia che il suo sistema è l'universo, la sua interpretazione delle specifiche è la parola di dio, e questo è tutto quello che c'è da esso, indipendentemente da quante persone preferirebbero diversamente.

Suggerirei di creare un progetto per l'implementazione della funzione su siti come RentACoder / ELance / etc e di postarlo sul forum del progetto open source originale. Qualcuno dei programmatori sui progetti open source, incluso l'autore, ora ha un incentivo finanziario a considerare la tua richiesta.

In realtà mi sono registrato solo per rispondere a questa domanda.

C'è bisogno di una replica? questa risposta viene solitamente utilizzata quando lo sviluppatore conosce il problema ma non lo ritiene importante.

Ti darò un esempio dal vivo. Ubuntu ha abbandonato il supporto per il sistema systray (ma può essere aggirato dal white listing di un'app) e ha aggiunto nuovi indicatori app. alcune app come jupiter si basavano sul supporto di systray, quindi lo sviluppatore spiegava il workaournd invece di aggiungere il supporto per l'app-indicator, così ho chiesto allo sviluppatore di aggiungere l'app-indicatore suppory la risposta era Inviami patch. " su richiesta il motivo per cui hanno scelto di non implementarlo. c'era questo

I have no interest in spending my time building support for a libra1ry that I will never use just because someone with a lot of money demands it by blacklisting my applications ability to function properly on his Linux distribution simply because he can.

If it was a real technical problem, I would probably take action but this is purely a political maneuver, so no I don't think so.

No, I'll just whitelist it

Giusto abbastanza. lo sviluppatore ha ragione di non implementare una funzionalità ma è disposto ad accettare le patch. questo non è veramente maleducato e offensivo quindi non c'era bisogno di una risposta.

bottom line: la replica canonica sarebbe di inviare la patch, ma se non ci riesci non c'è bisogno di una replica

Avvia un bounty per la funzione che desideri.

Oppure esci e acquista il prodotto che afferma di fare esattamente ciò che desideri e abusare del personale di supporto quando scopri che il marketing non corrisponde alle tue aspettative.

Il meglio che riesco a pensare è "fai schifo".

Mi spiace, ovviamente non è molto utile, ma penso che questa sia solo una delle sfortunate situazioni in cui l'utente è completamente fregato. Un appello brutalmente onesto alla coscienza dello sviluppatore è un ultimo sforzo.

Potresti provare a offrire ( tosse ) "donazioni" per far sì che il tuo problema venga affrontato, ma temo che una tale pratica, se resa comune, porterebbe a una pessima perdita di integrità nel settore, come correzioni di bug non dovrebbero mai essere rese proficue, sia per "Free" o software commerciale.