Qual è la replica canonica di "è open source, invia una patch"? [chiuso]

Il pericolo di suggerire mai qualche funzionalità su un prodotto, in particolare open source, è che otterrai la risposta "perché non lo fai?".

È valido ed è bello poter apportare le modifiche da soli. Ma sappiamo praticamente che i prodotti spesso migliorano quando i programmatori ascoltano la voce degli utenti, anche se tali utenti sono altri programmatori. Inoltre, il modo efficace per apportare tali modifiche può includere qualcuno che sta già lavorando al progetto, accettando l'idea e implementandola.

Ci sono alcuni termini comuni usati per riferirsi a problemi di sviluppo del software. ad esempio Bikeshedding . Esiste un termine comune che essenzialmente risponde: "Sì, lo so che posso cambiare praticamente qualsiasi cosa nel mondo - anche a fonte chiusa. Potrei essere assunto e andare a scrivere quel codice. Ma in questo caso sto solo facendo un'osservazione che potrebbe in effetti essere utile per un altro programmatore già adatto per apportare facilmente quel cambiamento - o semplicemente per discutere delle possibilità ".

[ps (tra qualche giorno) - Avrei dovuto sottolineare che "inviare una patch" è spesso detto con ironia ironica e sto cercando una risposta spiritosa appropriata.]

È un punto difficile: poiché l'utente non paga direttamente o indirettamente un prodotto, non può chiedere l'implementazione di una funzione. Non è come se tu fossi un 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. "Invia una patch" è la versione breve di:

"Non ci importa se ti piace il nostro prodotto o no. Vai e modificalo se vuoi, ma non disturbarci con le tue richieste dei clienti."

Che ne dici di inviare una patch?

Bene, non è così facile. Per farlo:

• Devi conoscere le lingue utilizzate nel progetto open source.

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

• È necessario disporre di tutte le versioni corrette di eventuali 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. Soprattutto, quando un enorme progetto richiede alcune ore per la compilazione e visualizza 482 errori e migliaia di avvisi, potresti essere coraggioso di andare a cercare la fonte di quegli errori.

• Dovresti capire molto bene come viene fatto il progetto , quali sono gli stili di codifica da usare, se ce ne sono, come eseguire unit test, ecc. Se il progetto non ha una documentazione decente (come spesso accade 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 quotidianamente, 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'intenzione di condividerla con la community).

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

Quindi esiste una replica canonica per "è open source, inviare 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 che riusciranno a fare qualcosa in tempi ragionevoli, ma è stato ripetutamente sollevato.

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

Se stai ripetutamente presentando una richiesta da solo, "prendere le patch" è potenzialmente inteso come un pennello relativamente educato, rispetto ad alcune alternative meno educate ...

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

Se hai mai gestito un progetto open source con molti utenti, saprai che ci sono 100 volte più richieste di quelle che i manutentori potrebbero mai arrivare e che molte di queste richieste sono importanti per il richiedente ma sarebbero eccessivamente difficili, o interromperebbe molti altri utenti o presenterebbe qualche altro difetto visibile solo con una comprensione globale del progetto e della base di codice. O a volte ci sono solo richieste di giudizio, e ci vuole troppo tempo per litigare ancora e ancora.

La maggior parte delle aziende non open source non ti darà accesso agli sviluppatori e otterrai solo un trattamento silenzioso o una storia educata ma fasulla dall'assistenza clienti. Quindi, almeno in open source hai alcune opzioni (paga qualcuno per codificare la funzionalità, ecc.) E mentre gli sviluppatori potrebbero essere scortesi, almeno danno risposte dirette. Preferirei avere "no" del solito "è sulla nostra tabella di marcia ... [2 anni dopo] ... è ancora sulla nostra tabella di marcia" tipo di cose che ho ottenuto da un numero di fornitori ...

Quindi non penso che ci sia una replica. Forse il manutentore dell'open source è davvero impegnato, forse è un idiota, ma in entrambi i casi, probabilmente hanno un lavoro duro e entrare in un dibattito che ha l'ultima parola non sta andando da nessuna parte. Il meglio che puoi fare è contribuire in qualche modo e cercare di essere costruttivo.

Forse non è un codice, ma forse ci sono molte analisi e documentare scenari utente che potresti fare. Quando stavo mantenendo il window manager di GNOME, molte volte sarebbe stato utile per le persone analizzare un problema a livello globale considerando tutti gli utenti e scrivere davvero i problemi, i pro ei contro e cosa dovrebbe accadere da una prospettiva globale.

(Invece, la solita cosa era iniziare a fiammeggiare come se fossero gli unici utenti che contano e non ci sono stati compromessi. E mentre è fantastico, ed è un punto dati, e spesso sono riuscito a rimanere educato o persino a risolvere il loro problema alla fine .. Il flaming non fa accadere nulla più rapidamente, confonde semplicemente le emozioni nel problema e fa perdere tempo a tutti.)

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

La risposta migliore è avviare un dialogo sul valore della tua funzione per la loro comunità nel suo insieme , per vedere se riesci a convincerli a cambiare idea. Forse hanno ragione e sanno più dei bisogni della propria comunità di te, ma, forse, forse no.

Se la funzione è preziosa solo per te e di scarso valore per la comunità, trovo che il denaro sia un eccellente motivatore, mentre lamentarsi del loro atteggiamento non lo è.

Qual è la replica canonica di "è open source, invia una patch"?

Non esiste una replica ragionevole che possa fare la differenza. Cercare di persuadere i volontari a fare qualcosa che non hanno intenzione di fare è una perdita di tempo ... o peggio.

Le tue opzioni sono:

• Fai ciò che la risposta suggerisce; cioè implementare la funzione e inviarla come patch. Si chiama "dare qualcosa in cambio".

• Trova qualcuno che sia disposto a implementare la funzionalità per te con soldi veri. Potrebbe essere il progetto stesso (ad esempio in cambio di sponsorizzazioni), qualcuno associato al progetto o qualche "programmatore a noleggio" casuale.

• Trova un prodotto alternativo.

Se hai ricevuto questa risposta quando hai fatto un suggerimento "utile", considera come potresti aver risposto se fossi nei suoi panni. Ad esempio, come risponderesti se pensassi che il suggerimento non sia utile / ben ponderato / intelligibile / ecc., Ma non abbia il tempo o la pazienza di impegnarsi in un dibattito prolungato?

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 aggiungono un flusso di suggerimenti su come fare le cose "meglio" che:

• sono incomplete, incomprensibili o assolutamente insensate,
• sono idee non sperimentate con una probabilità obiettivamente bassa di successo,
• richiederebbe un grande sforzo per implementare, e / o
• sono in contrasto con gli obiettivi dichiarati del progetto.

Spesso la risposta migliore è sfidare in modo mirato la persona ad essere coinvolta nel progetto ... e sperare che prendano il suggerimento ... di "mettere su o stare zitti". Sfortunatamente, i più fastidiosi non danno nemmeno un suggerimento.

Naturalmente, 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 fossimo uguali e sapessimo lo stesso della base di codice, della lingua e di tutte le altre cose rilevanti per questa particolare cosa che stai sottolineando.

Non sei uguale (o probabilmente lo avresti fatto), quindi suggerirei una risposta appropriata per essere:

"Non posso assolutamente farlo nel modo più veloce e buono possibile, motivo per cui ti ho chiesto di aiutarmi in primo luogo. Per favore!"

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

La storta canonica è di rovesciare il progetto.

La risposta canonica per "inviare una patch" è:

"Non ho le competenze, l'esperienza o il tempo necessari, quindi puoi dirmi dove spedire le casse di birra al ragazzo che può farlo per me"

Invia un test case completo .

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

Se non si è in grado di eseguire il lavoro per un motivo o per l'altro, spiegare le circostanze al responsabile del progetto in privato.

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

"Grazie per la risposta."

Perché:

• A prezzo zero, la domanda (richieste di funzionalità) supera l'offerta (programmatori disponibili per implementare tali funzionalità).
• Ragging su tutto ciò che viene fornito gratuitamente manca di classe IMHO.
• Questo è il punto centrale di FOSS: le persone che portano verdure e carne per aggiungere nutrimento alla zuppa di pietra. Se non posso contribuire con qualcosa, dovrei essere grato di poter mangiare del tutto e non lamentarmi di non mangiare meglio.

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

Alla fine della giornata, nulla 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 insieme. Il modo più rapido per mettere in atto la tua funzionalità è comunque di inviarci una patch. Periodo ... niente da fare.

Personalmente, preferirei ricevere una risposta di "Questo è un problema noto, ma sfortunatamente non si tratta di un problema che verrà affrontato presto. Gli sviluppatori stanno lavorando su altri problemi. Al momento non esiste ETA".

La risposta "submit a patch" è molto scortese, dato che presuppone una serie di cose:

1. Tutti gli utenti del programma sono programmatori o tutti i reporter 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 supponiamo che il creatore della risposta "invia una patch" sappia tutto quanto sopra, ciò fa semplicemente sembrare che la frase "X ore del mio tempo vale più degli ordini di grandezza più delle ore del tuo tempo che dovresti alzare per velocizzare e risolvere il problema ".

In genere, quando ricevo una risposta scortese da uno sviluppatore quando chiedo un problema che ho o invio un bug, smetto di usare quel programma. Non uso più uTorrent (non open source, ma il punto rimane) per esempio, perché le risposte che ho ricevuto sul loro forum di "supporto" sono state così scortesi. Ho presentato un problema che ho avuto nel forum Bug Reports. Il thread è stato immediatamente bloccato con un collegamento a un altro thread su 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 sul forum è stato bandito per un comportamento dirompente. Ho disinstallato uTorrent e non sono più tornato da allora.

Basta rispondere "invia una patch" è scortese IMO, ma comunque ... se usi un software open source per qualsiasi cosa seria, devi essere pronto a prenderti cura di essa in caso di necessità.

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

Se qualcosa non funziona per te, hai diverse opzioni:

• Questo è open source: puoi risolverlo da solo.
• Se non riesci a risolverlo da solo, puoi aspettare che qualcuno abbia tempo libero e pensi che sia divertente da implementare.
• Se ciò non accade, puoi trovare o assumere qualcuno che lo faccia per te.

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

Ogni volta che vedo questo inizio immediatamente a cercare un prodotto alternativo. Per me questo è un segnale pericoloso che i manutentori non si preoccupano dei loro utenti (male se il tuo progetto viene utilizzato ovunque) o hanno perso interesse nel progetto. Entrambi di solito significano che il progetto morirà presto o sarà afflitto dalla stagnazione poiché gli sviluppatori si rifiutano di portare avanti il ​​progetto

(Nota che non sto dicendo che il primissimo bug report che vedi con questo tipo di risposta che esegui. Devi guardare una tendenza generale. Se la maggior parte dei bug report termina con questo tipo di risposta, segui questo consiglio. sono solo alcune, quindi quelle sono molto probabilmente richieste di funzionalità che non si adattano agli obiettivi del progetto o sono estremamente specifiche per l'uso)

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

Di tanto in tanto scherzo sul fatto che il software libero può essere gratuito come nella birra, gratuito come nel parlato o gratuito come in te ottenere ciò per cui paghi.

Mentre lo dico scherzosamente (lavoro per un'azienda che usa molto OSS) ma penso che ci sia una verità lì - se vuoi un supporto a livello commerciale, allora devi usare un software commerciale con un accordo di supporto adeguato, o trovare un soluzione software open source che ti consente quel livello di supporto (di solito attraverso qualcuno che viene pagato per fornirlo, ma potenzialmente attraverso la tua organizzazione che impiega o assegna risorse di sviluppo per lavorarci).

"Invia una patch" è esasperante ma evidenzia qualcosa sull'OSS e forse dovrebbe essere un promemoria per ricordare che l'OSS non è adatto a tutti in ogni situazione, almeno non assicurandosi di avere un solido framework di supporto ( in-house, pagato per o attraverso la comunità).

Spesso pensiamo a software gratuiti come nella birra ma non come nei discorsi (ovvero freeware non aperto). Forse questo è un caso in cui dovremmo pensare al software gratuitamente come nel parlato ma non come nella birra.

Passa a un'alternativa ben mantenuta.

Secondo la mia esperienza con progetti open source ben mantenuti, se si creano segnalazioni di bug o richieste di funzionalità ben definite, si hanno molte probabilità di essere implementate.

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

Ritengo che quando si sta lavorando a un progetto, fornendo rilasci e supporto, nasce un contratto di supporto non detto, implicito, tra dev e utente. Lo sviluppatore ha assunto la responsabilità implicita di supportare la base di codice per i suoi utenti, inclusa l'aggiunta di funzionalità su richiesta.

"Inoltra una patch" sta fondamentalmente dando il dito agli utenti, secondo me. Questo è contestuale - a volte è solo uno sforzo eccessivo da implementare, a volte rovinerebbe il progetto esistente o incorrerebbe in una creaturite temibile, o in una qualsiasi delle altre ragioni. Ma, in definitiva, sta dicendo "fottiti, non farlo". Il che, a mio avviso, è, in qualche modo, una violazione di quel contratto non detto.

Esistono diversi modi per farlo.

• Proposta di funzionalità e votazione. ma questo richiede tempo.

• Fatti assumere da un'azienda che ne ha bisogno per realizzare la patch. Ovviamente questa è la soluzione migliore, ma preparati a collaborare con il ragazzo che crea il software open source che desideri aggiornare.

• Scoprire perché la funzionalità non è implementata in primo luogo è anche importante. 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 fork il progetto e realizzarlo da solo.

• Usa un software proprietario che fa quello che vuoi.

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

• Piagnucolare su una mailing list, su irc o in un forum farà incazzare i programmatori e darà munizioni ai sostenitori dell'OSS.

Non c'è niente che tu possa dire che lo farà fare. Dopo tutto, perché dovrebbe? Per i desideri di un utente? Non è abbastanza buono un motivo.

Ma , se riesci a raccogliere un numero ragionevole di utenti e fornire ragioni razionali ("Lo voglio" non è un motivo razionale). Perché quella caratteristica potrebbe essere utile, in generale, a te e al numero di altri, potrebbe semplicemente cambiare idea .

Tuttavia, c'è anche un caso speciale che deve essere considerato. Che dev. è stanco di sviluppare l'app, desiderando lentamente abbandonarla (ha altre cose da fare) e quindi sta lentamente abbandonando le richieste di funzionalità. A parte 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 ai doni o al finanziamento dello sviluppo di una particolare funzionalità, anche se la nuova funzionalità non arriva alle versioni ufficiali.

Inoltre, sì, una delle idee alla base della pubblicazione dell'open source è che chiunque abbia il diritto e la responsabilità di dare il proprio contributo.

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

Nella mia esperienza, questa risposta viene generalmente fornita se la richiesta dell'utente non soddisfa l'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 fantastico e felice.

"Invia una patch" è una risposta relativamente scortese (e dovrebbe essere evitato, ovviamente. Soprattutto in questa forma concisa e nitida. Esistono molti modi per esprimere approssimativamente lo stesso messaggio, ad esempio "invita" gli utenti ad aiutarti perché non hai il tempo di implementarlo da solo). Ma com'è, è un chiaro indicatore "smettere di perdere tempo". Pertanto, non c'è molto che tu possa fare al riguardo, né c'è una risposta "canonica".

La migliore risposta che mi viene in mente è quella di presentare effettivamente una patch . Supponendo che la tua patch funzioni, hai almeno provato che l'idea non è del tutto irrealistica. Di solito, ciò significa che i responsabili del progetto riconsidereranno la proposta.

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

Se è minore e davvero utile per gli utenti previsti del progetto, invia semplicemente la segnalazione di bug, descrivi chiaramente il problema, fornisci passaggi per riprodurlo, indica che stai utilizzando l'attuale build notturna e lascialo a quello.

Quello che potrebbe sembrare un semplice piccolo cambiamento che potrebbe aiutare tonnellate di utenti potrebbe effettivamente essere un enorme dolore nel culo che nessuno userebbe oltre a te. Questo è il caso migliore per "invia una patch".

È anche possibile che ti sia imbattuto in un caso come il famigerato manutentore glibc che sembra avere una sola idea che il suo sistema è l'universo, la sua interpretazione delle specifiche è la parola di dio, e questo è tutto ciò che c'è da fare, indipendentemente di quante persone preferirebbero altrimenti.

Suggerirei di creare un progetto per l'implementazione della funzione su siti come RentACoder / ELance / etc e di pubblicarlo sul forum del progetto open source originale. Tutti i programmatori dei progetti open source, incluso l'autore, ora hanno un incentivo finanziario per prendere in considerazione la tua richiesta.

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

C'è bisogno di una replica? questa risposta viene generalmente utilizzata quando lo sviluppatore è a conoscenza del problema ma non lo ritiene importante.

Ti darò un esempio dal vivo. ubuntu ha eliminato il supporto per systray (ma può essere risolto inserendo in bianco un'app) e ha aggiunto nuovi indicatori per l'app. alcune app come Jupiter si sono affidate al supporto di systray, quindi lo sviluppatore ha parlato del workaournd invece di aggiungere il supporto per gli indicatori delle app, quindi ho chiesto allo sviluppatore di aggiungere la supposizione degli indicatori delle app, la risposta è stata "Inviaci patch". chiedendo il motivo per cui hanno scelto di non implementarlo. c'era questo

Non mi interessa passare il tempo a costruire il supporto per un libra1ry che non userò mai solo perché qualcuno con un sacco di soldi lo richiede inserendo nella lista nera la capacità delle mie applicazioni di funzionare correttamente sulla sua distribuzione Linux semplicemente perché può farlo.

Se fosse un vero problema tecnico, probabilmente prenderei provvedimenti, ma questa è puramente una manovra politica, quindi no, non credo.

No, lo inserirò nella whitelist

Giusto. lo sviluppatore ha motivo di non implementare una funzione ma è disposto ad accettare patch. questo non è davvero maleducato e offensivo, quindi non c'era bisogno di una replica.

linea di fondo: la replica canonica sarebbe quella di inviare la patch, ma se non è possibile non è necessario per una replica

Inizia una taglia per la funzione che desideri.

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

Il meglio che mi viene in mente è "fai schifo".

Mi dispiace, 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 disperato sforzo.

Potresti provare a offrire ( tosse ) "donazioni" per affrontare il tuo problema, ma temo che tale pratica, se resa comune, porterebbe a una brutta perdita di integrità nel settore, poiché le correzioni di bug non dovrebbero mai essere rese redditizie, neanche per Software "gratuito" o commerciale.