Penso che ci siano due tipi di riproducibilità:

1. La capacità di qualcun altro di eseguire il tuo codice e ottenere lo stesso output.
2. La capacità di qualcun altro di scrivere il proprio codice che fa la stessa cosa del tuo in base alla tua descrizione e all'esame del tuo codice (riproduzione da zero).

Il secondo tipo di riproducibilità è molto più convincente, poiché il punto principale della riproducibilità scientifica è verificare la correttezza del risultato. Per la scienza che si basa sul codice, di solito è impossibile includere ogni dettaglio del codice nel documento, quindi la verifica richiede un esame del codice.

Se utilizzi software proprietario, il tuo codice probabilmente fa uso di codice sorgente chiuso e quindi non può essere verificato o riprodotto da zero. Se utilizzi software open source, tutto il codice che il tuo codice chiama è probabilmente open source, quindi tutto può essere verificato o riprodotto da qualcun altro da zero.

Al momento, è probabilmente vero che il primo tipo di riproducibilità è più ottenibile con software proprietario ampiamente utilizzato. Sono ottimista sul fatto che l'attuale tendenza porterà al recupero del software open source in termini di ampio utilizzo (si consideri SAGE, ad esempio).

Addendum, in light della risposta di Epigrad di seguito, con la quale sono principalmente d'accordo: il problema di fare affidamento su codice sorgente chiuso non è che qualcun altro non sappia cosa ci si aspetta da quel codice sorgente chiuso .

Il problema è che se hai due implementazioni closed-source dello stesso algoritmo e danno risultati diversi (credimi , di solito lo faranno), quindi non hai modo di determinare quale (se uno dei due) è corretto .

In altre parole, il codice closed-source andrebbe bene per la riproducibilità se fosse erano privi di bug. Ma non lo è.

Per integrare la risposta di @David Ketcheson con un "Sì, ma ..."

Sono d'accordo sul fatto che ci sono due tipi di riproducibilità - CrossValidated li discute con un certo grado di frequenza. C'è, come è stato accennato, "Posso fare clic su" Esegui "e ottenere la stessa risposta che hai ottenuto tu" riproducibilità, che in genere non trovo molto convincente.

C'è anche "Potrei ripetere la tua analisi da ciò che hai fornito dal passaggio 1 al passaggio finale e ottieni la stessa o una risposta simile? Penso che questo sia quello a cui dovremmo mirare.

Questo è spesso aiutato dall'utilizzo di codice accessibile e non proprietario, ma non sempre. Considera il seguente esempio di un modello di dinamica delle malattie infettive, espresso come un sistema di ODE:

Qui, per replicare (o non replicare) i miei risultati, il software che ho usato non ha importanza. Ciò che conta sono le equazioni e i valori dei parametri che ho scelto. Se li fornisco, l'unico motivo per cui è necessario il codice è perché qualcuno non vuole implementare lo studio da zero e vuole semplicemente eseguire il codice e vedere se i risultati corrispondono, armeggiare con le ipotesi un po ', ecc. In tal caso, tutti traggono vantaggio dal fatto che il codice sia in una forma utilizzata dalle persone.

Penso che lo stesso sia spesso vero per l'analisi statistica che non utilizza nuovi metodi. A questo punto, ciò che conta è che i dati siano disponibili e che il codice sia implementato in un linguaggio che le persone comprendono e usano. Se il 95% delle persone utilizza SAS, anche se è proprietario, il modo per rendere i risultati più accessibili e più facili da replicare è disporre di un'implementazione in SAS. Perché se scegli un linguaggio oscuro ma libero, ciò che hai fatto è stato sostituito dalla barriera "Denaro" con una barriera "Tempo per capire", che per la maggior parte delle persone equivale alla stessa cosa.

Il riassunto è questo: non penso che "Libero / Aperto" e "Proprietario / Chiuso" sia necessariamente la distinzione decisiva. Penso che la distinzione sia l'accessibilità e cerco di massimizzarla. Se viene utilizzato un pacchetto software aperto, gratuito e popolare (R per esempio), allora fantastico! - usa quello. Ma se il campo utilizza principalmente un pacchetto commerciale, scegliendo un'alternativa oscura solo perché la sua gratuità non risolve l'accessibilità, sposta semplicemente il peso.

Cominciamo con un disclaimer. In genere mi associo alla prospettiva della comunità del software libero secondo cui il software proprietario è eticamente discutibile e, se possibile, è meglio evitarlo. Mi rendo conto che questa prospettiva non è comunemente sostenuta nei circoli scientifici. Detto questo, a volte il software proprietario è un male necessario, o almeno non facilmente evitabile, e sono generalmente pragmatico sull'utilizzo di software proprietario quando non esistono buone alternative. Ho utilizzato software proprietario in passato, anche se attualmente l'unico software proprietario che sto utilizzando (sporadicamente) è Skype, per il quale non esistono buone alternative gratuite.

Tuttavia, considerazioni speciali si applicano in un contesto scientifico contesto. Uno di questi è già stato trattato da @David, vale a dire che in generale non è possibile "vedere all'interno" del software proprietario per vedere come viene implementato qualcosa. Detto questo, a volte il software proprietario è scritto in un linguaggio interpretato, come in Splus, e si può essere in grado di vedere parte o tutta l'implementazione di un algoritmo. Indipendentemente da ciò, il punto è generalmente valido.

Un problema separato e ovvio, che non penso nessuno abbia sollevato, è che l'uso di software proprietario costringe gli altri che desiderano utilizzare il tuo software ad acquistare il prodotto proprietario che utilizzi . Questi prodotti possono essere piuttosto costosi, soprattutto per le persone provenienti da paesi poveri. Ad esempio, Matlab, che è stato menzionato in questo thread, costa migliaia di dollari se si deve pagare una licenza da soli. Le istituzioni accademiche occidentali hanno spesso licenze di sito per software così diffusi, quindi i ricercatori non devono pagarli da soli. Personalmente sono piuttosto infelice quando dovrei utilizzare un software scritto utilizzando un linguaggio proprietario o un pacchetto che deve essere acquistato.

Una questione correlata è che gran parte, se non la maggior parte della ricerca, viene svolta utilizzando finanziamenti pubblici, ad esempio il denaro dei contribuenti. Non mi sembra desiderabile utilizzare tali fondi per acquistare software proprietario, aumentando così il profitto di alcune società. In generale, c'è qualche movimento per rendere gratuito il lavoro accademico svolto utilizzando finanziamenti pubblici. E si può facilmente sostenere che l'uso di software proprietario rende i propri prodotti scientifici meno liberi. Ad esempio, credo che ora i NIH dispongano di alcune di queste politiche. Argomenti simili potrebbero essere applicati all'uso di strumenti software.

Un problema tecnico tangenziale è che spesso è difficile far funzionare bene il software proprietario su piattaforme software libere come i sistemi gratuiti simili a Unix attualmente popolari nei circoli scientifici, ad es i sistemi basati su Linux e i sistemi BSD. Queste difficoltà includono, ma non sono limitate a

a) problemi ABI. Se si desidera compilare un'estensione C / C ++ per Matlab, ad esempio, è necessario utilizzare esattamente la versione del compilatore con cui è stato compilato il programma Matlab

b) Il programma richiede librerie obsolete o richiede librerie di essere in posti non standard.

Cito questo problema in parte perché la mia comprensione della domanda è che si tratta di chiedere informazioni proprietarie vs libere nel contesto di un utilizzo pragmatico.

Quindi, per rispondere direttamente alla domanda:

Supponendo che sto iniziando un nuovo progetto e desidero renderlo il più riproducibile possibile. Dovrei usare software libero relativamente impopolare o software proprietario estremamente popolare?

Non credo che ci sia una risposta chiara. Se non ci sono alternative valide, allora si dovrebbe usare il software proprietario, come faccio con Skype. Se esiste una versione gratuita praticabile, la userei. Tieni presente che se più persone iniziano a utilizzare il "software libero relativamente impopolare", diventerà più popolare. :-)

Concordando con la maggior parte di quanto è stato detto da EnergyNumbers e David Ketcheson, vorrei aggiungere alcuni punti leggermente diversi:

• il fatto che il codice è scritto in una particolare lingua (Matlab) non lo rende closed source di per sé.
  Proprio come l'utilizzo di Scilab su Windows closed source (o l'utilizzo di un BLAS closed source) non rende Scilab closed source.
  Ci sono riviste che richiedono ricerche riproducibili e apri il codice e accetta il codice Matlab.

• allo stesso modo, popolare e gratuito non si escludono a vicenda, né il proprietario implica che sia popolare

• nessuno dei due implica che il rispettivo software sia adatto per l'analisi dei dati riproducibili.

• La scelta della lingua dovrebbe essere basata su diversi fattori

  • quanto è adatta al problema in questione
  • anche qui: quanto è adatto per l'analisi dei dati riproducibili (sono uno scienziato sperimentale, quindi la riproduzione di un'analisi dei dati è solo una parte della ricerca riproducibile per me)
  • in particolare se si parla di condivisione del codice: considerazioni sull'infrastruttura (il codice può essere impacchettato nelle librerie? Come possono i dati, il codice e il testo essere raggruppati in un documento riproducibile?)
  • popolarità = dimensione del gruppo di pari che utilizza questo software (che in qualche modo include il costo di una licenza)
  • potresti anche prendere in considerazione ciò che utilizza il gruppo di pari interessato alla ricerca riproducibile (nel mio campo (i), il gruppo di ricerca riproducibile coincide molto di più con il gruppo di open source (R), mentre del gruppo di pari che lavora sullo stesso tipo di problema probabilmente la maggioranza usa Matlab)

• Il mio vecchio supervisore diceva che il costo di una licenza è n o argomento scientifico.
  Ma ovviamente potresti doverlo prendere in considerazione.

• Allo stesso modo, la popolarità non è un argomento scientifico, ma dovresti esaminare criticamente se la propolarità indica effettivamente che i lotti esistono buone ragioni per utilizzare quel software.

Esempi:

• Nel mio campo, R è sempre più popolare (ormai abbastanza popolare da pubblicare in R) e in una certa misura sostituisce Matlab.

  • Quindi R è sia gratuito che popolare (eppure la maggior parte delle persone del mio campo non fa uso del fatto che puoi esaminare la fonte di R se discutono di analisi dei dati riproducibili)

• Motivi che IMHO includono

  • soprattutto: R è adatto al nostro tipo di problemi (penso che sia più adatto di Matlab, altri differiscono leggermente nella loro opinione e usano Matlab. Anche altri pensano che potrebbe effettivamente essere più adatto, ma non tanto da superare l'apprendimento R in questo momento)
  • Essere ben adattati include la disponibilità di metodi che usiamo in CRAN vs. toolbox Matlab commerciali e repository di file Matlab
  • Essere più adatti include il fatto che non posso adattare il codice dei toolbox Matlab proprietari (file p) a particolari esigenze.
  • Essere adatti include la facilità di generazione di report
  • infrastruttura: ad es Il concetto di pacchetto di R che applica uno standard minimo e consente di fare affidamento su esempi e test effettivamente eseguibili rispetto a una cartella piena di file .m (ho sentito che recentemente è stato introdotto un concetto più simile a un pacchetto). Questo aiuta molto con la condivisione del codice (sia per riprodurre i tuoi risultati o per usarlo sui propri dati)
  • i costi di licenza arrivano indirettamente: è più che non devi preoccuparti se installi anche sul tuo computer privato e puoi dire agli studenti di installarlo sui loro laptop piuttosto che preoccuparsi del costo di alcune licenze per computer al lavoro.
  • probabilmente molto più costoso dei canoni di licenza stessi è il tempo per far funzionare il gestore delle licenze o per trasferire le licenze tra computer, e se vuoi solo provare una cassetta degli attrezzi prima di decidere se acquistarla o meno , la seccatura di a) chiedere al venditore una versione demo e successivamente b) compilare moduli d'ordine e scrivere giustificazioni sul motivo per cui è necessario spendere soldi per quella licenza.

Nota quanti di questi argomenti sono "morbidi" e in effetti hanno più a che fare con l'essere usati per un sistema o per l'altro o per usare una caratteristica è più facile, più ovvio o più comune tra i gruppi di pari degli utenti di quel software: noweb può lavorare con Matlab, la documentazione dei file m è possibile e incoraggiata (sebbene non realmente applicata), i test unitari sono possibili in Matlab, Matlab Central ha molto codice libero, ecc. . Solo gli utenti R sanno sempre di CRAN, mentre non tutti gli utenti Matlab conoscono Matlab Central, c'è una buona cultura di citare articoli scientifici sul metodo implementato nei file di aiuto di R, spedire codice insieme a set di dati di esempio e / o dare esempi effettivamente in esecuzione codice.

Esempi di argomenti non validi:

• se i miei colleghi non usassero il controllo della versione per la codifica, non lo considererei un argomento contro usando il controllo della versione (poiché ci sono molte buone ragioni per usarlo)

• Oppure, se quelli che si rifiutano di usare il controllo della versione fossero professionisti grammatura in Matlab, né questo sarebbe un argomento contro Matlab, ma verificherei se c'è qualche motivo che proibisce l'uso del controllo della versione per il codice Matlab.

Ascolta i tuoi colleghi & coetanei.

Ti hanno già detto cosa è più adatto a loro, in modo che possano riprodurre i tuoi risultati.

Che la risposta, nel tuo caso particolare, è Matlab.

Ci saranno altri che vorranno portarlo su Octave, SciLab, Excel, Fortran o altro. Anche questo va bene, ma se sei flessibile su quale piattaforma codifichi e la codifica in Matlab non ti renderà meno produttivo (o la piccola riduzione della produttività è un prezzo che vale la pena pagare per la maggiore riproducibilità), allora codifica in Matlab . Perché i tuoi colleghi ti hanno già detto che questo è ciò che consente loro di riprodurre il tuo lavoro, il più semplice.

Ci sono molte buone ragioni (e forse alcune cattive) per cui molti dei tuoi colleghi preferiscono Matlab. A volte le cose più economiche possono costarti di più.

Per chiunque altro legga questo, con un problema simile, il succo della risposta è lo stesso: ascolta i tuoi colleghi.

I miei due centesimi:

confronto spesso il codice con un articolo scientifico. Lo scopo di un documento è descrivere i tuoi risultati e il tuo approccio al problema in modo tale che i tuoi colleghi possano convalidare / confutare i tuoi risultati, in qualsiasi modo ritengano opportuno , in modo che possa durare uno sforzo collaborativo luogo per fare progressi sul campo.

A chi importa se l'autore dell'articolo ha usato LaTeX per scrivere il suo articolo o MS Word? A chi importa se i dati sono stati elaborati con MATLAB, Excel o Pascal? Sono le verità nel giornale che contano, non gli strumenti utilizzati per arrivarci (anche se molti sarebbero lieti di saltare qui e iniziare una feroce discussione su questo punto ... ma nella mia esperienza, gli argomenti utilizzati in tali discussioni tendono ad essere più simili alla religione che a qualsiasi altra cosa).

Ciò che è molto importante , tuttavia, è il mezzo per comunicare con i tuoi coetanei . Ad esempio, se scrivi e pubblichi un articolo in esperanto (supponendo per il momento che venga accettato), semplicemente perché pensi che sia bello ed elegante e tutti dovrebbero parlarlo. Inoltre ci sono molti libri su come trasmettere il significato in esperanto, giusto?

Non molti dei tuoi colleghi saranno in grado di capire il documento, per non parlare di ricevere il messaggio e riprodurre le tue scoperte. Dovrai aspettare che arrivi qualcuno nel tuo campo che condivida le tue opinioni sull'esperanto, il che potrebbe richiedere mezza vita. Nel complesso, questo è un modo molto povero di fare progressi nel tuo campo.

Questo credo sia il nocciolo della tua situazione: se i tuoi colleghi usano principalmente MATLAB, faresti meglio a restare fedele a MATLAB, perché raggiungerai il maggior numero di colleghi il più velocemente. Lascia che (altri) ingegneri stabilisca se MATLAB produce effettivamente risultati buoni (sufficienti) per il tuo caso e lascia che uno dei tuoi colleghi a mezzo mondo di distanza traduca il tuo codice in C ++ e verifichi i tuoi risultati.

Non è il codice che conta, è la conoscenza che è contenuta in esso.

Puoi fare qualunque cosa dannatamente bene per favore, ma ci sono alcune considerazioni:

1) Potresti avere l'obbligo di diffondere il tuo lavoro. Se sei supportato da un'agenzia di finanziamento esterna come NSF o NIH, la diffusione è un obbligo. Molte fondazioni private e altre fonti di finanziamento forniscono anche supporto con l'intento di diffusione, che sia dichiarato esplicitamente o meno.

Se hai un tale obbligo, in assenza di qualsiasi altra considerazione ciò suggerirebbe di utilizzare il più accessibile software possibile, indipendentemente dal fatto che sia proprietario o gratuito.

2) L'open source è importante per alcuni tipi di ricerca, ma per la maggior parte delle ricerche è irrilevante. A meno che tu non stia facendo ricerche sui sistemi informatici, dove è davvero importante come il computer arriva a una risposta, il metodo non importa tanto quanto la correttezza. A volte può avere importanza (ad es. Se il tuo lavoro dipende fortemente da metodi numerici), ma probabilmente non è così.

3) Le comunità stabiliscono standard di validità e integrità. Se tutti gli altri usano MATLAB, la comunità lo ha ritenuto accurato. In assenza di prove contrarie, l'utilizzo di software open source non fa sembrare i risultati più corretti o più verificabili agli occhi di nessuno.

Come nota a margine, Mathworks ha una solida reputazione nel lavorare con i ricercatori. Se pensavi davvero che MATLAB ti stesse dando risultati errati e avessi degli esempi per dimostrarlo, avrebbero bussato alla tua porta per risolvere il problema. Mathworks mi ha rilasciato una patch di supporto personalizzata lo stesso giorno in cui ho chiamato per un'oscura incompatibilità hardware che causava un comportamento errato.