Non la considero una domanda specifica per R. La vera domanda è: puoi fidarti del codice di altre persone ? Oppure, prendendo l'altra prospettiva: pensi di poter fare di meglio ? (nel tempo che sei disposto / in grado di spendere)

Se il software è open source o closed source, non ha molta importanza. L'affidabilità dell'open source rispetto al software commerciale è un argomento molto dibattuto. Esistono argomenti a favore di entrambi i lati della discussione. Nessuno può negare che entrambi possono (e contengono) bug di varia natura, alcuni più insidiosi di altri.

TL; DR : secondo me: sì, va bene usare pacchetti esistenti se coprono le tue esigenze.

Il mio motto, in generale, è provare a implementare le cose da solo se una serie di seguenti sono vere:

1. Lo so esattamente cosa voglio e come farlo (questo è tutt'altro che banale per molti modelli pratici).
2. Vale la pena il tempo necessario per implementare e testare il mio codice rispetto a quanto già esiste. In altre parole: lo userò spesso o solo una volta?
3. Ciò che già esiste non offre tutte le funzionalità di cui ho bisogno.
4. Ho una buona ragione per non fidarmi delle implementazioni esistenti ( come un comportamento inaspettato quando lo si utilizza).

Personalmente, mi piace, utilizzo e sviluppo molto open source perché credo che sia importante, specialmente in un contesto accademico. In pratica, molte persone considerano l'utilizzo di un determinato algoritmo solo se è disponibile un'implementazione. Nessuno trae vantaggio da un ampio insieme di implementazioni della stessa cosa. È molto meglio disporre di un'implementazione efficiente, accuratamente testata e verificata di un determinato metodo.

Alla gente piace credere che se lo faccio da solo, so che è fatto correttamente . La pratica contraddice questo su base regolare.

Non tutti i pacchetti di R sono stati creati in un ambiente accademico

Non so il motivo per cui ci si sente che i pacchetti creati dagli accademici sono superiori. Certo, il metodo stesso potrebbe essere più complesso / nuovo, ma tutte le scommesse sono sbagliate sull'implementazione. I ricercatori non sono necessariamente i migliori programmatori (in effetti, dato che di solito non è la loro specialità, direi che è più probabile il contrario).

In pratica, i ricercatori hackerano regolarmente soluzioni insieme, a volte senza test approfonditi. Naturalmente, questo può portare a tutti i tipi di cattivi risultati (in particolare i fallimenti silenziosi). Personalmente, credo che una delle ragioni di questo comportamento sia il fatto che l'output del software è sottovalutato nelle impostazioni di ricerca. Alcuni ricercatori si affrettano semplicemente verso la prossima pubblicazione. La pubblicazione dei risultati è importante, il software utilizzato per ottenerli in realtà non lo è. Questo porta a software che non è stato testato correttamente quando le persone reinventano la ruota per un uso singolo.

Come possiamo usare l'open source senza rischiare di fallire nel risultato?

Non puoi. Questo vale anche per il software commerciale e il software che scrivi tu stesso con molta cura e amore. Se ti capita di trovare un modo per assicurarti che il software non abbia bug o avvertenze, dovresti fissare immediatamente un appuntamento con Bill Gates (o meglio ancora, parlamene).

L'unica soluzione è valutare criticamente risultati in ogni fase del processo. Mai software fiducia incondizionata, non importa quale sia il software che è.

Esistono determinati indicatori di qualità per i pacchetti in generale e per R?

Di solito, i pacchetti che vengono resi disponibili pubblicamente, ad esempio su CRAN, sono stati sottoposti a test rigorosi, soprattutto quelli che vengono utilizzati spesso. Le persone ci penseranno due volte prima di rendere pubblicamente disponibile spazzatura non testata quando è in gioco la loro credibilità. Il numero di citazioni può essere considerato anche un indicatore di qualità oltre a una comunità attiva in via di sviluppo.