¿Programa propietario popular u oscuro sustituto de código abierto para la investigación reproducible?

Creo que hay dos tipos de reproducibilidad:

1. La capacidad de otra persona para ejecutar su código y obtener el mismo resultado.
2. La capacidad de otra persona para escribir su propio código que hace lo mismo que el suyo según su descripción y el examen de su código (reproducción desde cero).

El segundo tipo de reproducibilidad es mucho más convincente, ya que el punto principal de la reproducibilidad científica es verificar la corrección del resultado. Para la ciencia que se basa en el código, normalmente es imposible incluir todos los detalles del código en el documento, por lo que la verificación requiere el examen del código.

Si utiliza software propietario, es probable que su código utilice un código fuente cerrado y, por lo tanto, no se puede verificar ni reproducir desde cero. Si usa software de código abierto, entonces todo el código al que llama su código probablemente sea de código abierto, por lo que otra persona puede verificarlo o reproducirlo desde cero.

En la actualidad, probablemente sea cierto que el primer tipo de reproducibilidad es más alcanzable con software patentado y ampliamente utilizado. Soy optimista de que la tendencia actual conducirá a que el software de código abierto se ponga al día en términos de uso generalizado (considere SAGE , por ejemplo).

Anexo, a la luz de la respuesta de Epigrad a continuación, con la que estoy principalmente de acuerdo: el problema de confiar en el código de fuente cerrada no es que alguien más no sepa qué se espera que haga ese código de fuente cerrada .

El problema es que si tiene dos implementaciones de código cerrado del mismo algoritmo y dan resultados diferentes (créame, por lo general lo harán), entonces no tiene forma de determinar cuál (si es que alguna) es la correcta .

En otras palabras, el código de fuente cerrada estaría bien para la reproducibilidad si no tuviera errores. Pero no lo es.

Para complementar la respuesta de @David Ketcheson con un "Sí, pero..."

Estoy de acuerdo en que hay dos tipos de reproducibilidad: CrossValidated los analiza con cierta frecuencia. Existe, como se ha mencionado, la reproducibilidad "¿Puedo hacer clic en 'Ejecutar' y obtener la misma respuesta que obtuvo?", que generalmente no encuentro muy convincente.

También está "¿Podría repetir su análisis de lo que proporcionó desde el Paso 1 hasta el Paso final y obtener la misma respuesta o una similar?" Creo que este es el objetivo al que deberíamos apuntar.

Eso a menudo se ayuda mediante el uso de código accesible y no propietario, pero no siempre. Considere el siguiente ejemplo de un modelo de dinámica de enfermedades infecciosas, expresado como un sistema de EDO:

Aquí, para replicar (o dejar de replicar) mis hallazgos, el software que utilicé no importa. Lo que importa son las ecuaciones y los valores de los parámetros que elegí. Si los proporciono, entonces la única razón por la que se necesita el código es porque alguien no quiere implementar el estudio desde cero y simplemente quiere ejecutar el código y ver si los resultados coinciden, modificar un poco las suposiciones, etc. En ese caso, todos se benefician de que el código esté en una forma que la gente usa.

Creo que lo mismo suele ser cierto para el análisis estadístico que no utiliza métodos novedosos. En este punto, lo que importa es que los datos estén disponibles y que el código se implemente en un lenguaje que la gente entienda y use. Si el 95% de las personas usa SAS, incluso si es propietario, entonces la forma de hacer que sus resultados sean más accesibles y más fáciles de replicar es tener una implementación en SAS. Porque si elige un idioma oscuro pero libre, lo que ha hecho es reemplazar la barrera del "Dinero" con la barrera del "Tiempo para entender", que para la mayoría de las personas equivale a lo mismo.

El resumen es este: no creo que "Libre/Abierto" versus "Propietario/Cerrado" sea necesariamente la distinción decisiva. Creo que esa distinción es la accesibilidad, y tratar de maximizar eso. Si se utiliza un paquete de software abierto, gratuito y popular (por ejemplo, R), ¡genial! - usa eso. Pero si el campo usa principalmente un paquete comercial, escogiendo una alternativa oscura solo porque su gratuidad no soluciona la accesibilidad, simplemente cambia la carga.

Permítanme comenzar con un descargo de responsabilidad. Generalmente suscribo la perspectiva de la comunidad de software libre de que el software propietario es cuestionable éticamente y es mejor evitarlo si es posible. Me doy cuenta de que esta perspectiva no se mantiene comúnmente en los círculos científicos. Habiendo dicho eso, a veces el software propietario es un mal necesario, o al menos no fácil de evitar, y generalmente soy pragmático sobre el uso de software propietario cuando no existen buenas alternativas. He usado software propietario en el pasado, aunque actualmente el único software propietario que uso actualmente (esporádicamente) es Skype, para el cual no existen buenas alternativas gratuitas.

Sin embargo, se aplican consideraciones especiales en un contexto científico. Uno de estos ya ha sido cubierto por @David, a saber, que en general no se puede "ver dentro" del software propietario para ver cómo se implementa algo. Habiendo dicho eso, a veces el software propietario está escrito en un lenguaje interpretado, como en Splus, y uno puede ver parte o la totalidad de la implementación de un algoritmo. Independientemente, el punto se mantiene en general.

Un tema separado y obvio, que no creo que nadie haya planteado, es que el uso de software propietario obliga a otros que quieren usar su software a comprar el producto propietario que usted usa. Estos productos pueden ser bastante caros, especialmente para personas de países pobres. Por ejemplo, Matlab, que se ha mencionado en este hilo, cuesta miles de dólares si uno mismo tiene que pagar una licencia. Las instituciones académicas occidentales a menudo tienen licencias de sitio para software tan popular, por lo que los investigadores no tienen que pagarlo ellos mismos. Personalmente, me siento bastante descontento cuando se espera que use una pieza de software escrita con algún lenguaje propietario o paquete que deba comprarse.

Una cuestión relacionada es que gran parte de la investigación, si no la mayoría, se realiza con fondos públicos, es decir, dinero de los contribuyentes. Me parece indeseable usar tales fondos para comprar software propietario, aumentando así las ganancias de alguna corporación. En general, existe cierto movimiento para que el trabajo académico que se realiza con fondos públicos sea gratuito. Y uno puede argumentar fácilmente que el uso de software propietario hace que el producto científico sea menos libre. Por ejemplo, creo que el NIH ahora tiene algunas políticas de este tipo. Se podrían aplicar argumentos similares al uso de herramientas de software.

Un problema técnico tangencial es que a menudo es difícil hacer que el software propietario funcione bien en plataformas de software libre como los sistemas libres tipo Unix actualmente populares en los círculos científicos, por ejemplo, los sistemas basados ​​en Linux y los sistemas BSD. Estas dificultades incluyen, pero no se limitan a

a) Problemas del ITB. Si uno quiere compilar una extensión C/C++ para Matlab, por ejemplo, tiene que usar exactamente la versión del compilador con la que se ha compilado el programa Matlab.

b) El programa requiere bibliotecas obsoletas o requiere que las bibliotecas estén en lugares no estándar.

Menciono este problema en parte porque mi comprensión de la pregunta es que se trata de propietario frente a libre en el contexto del uso pragmático.

Entonces, para responder a la pregunta directamente:

Suponiendo que estoy comenzando un nuevo proyecto y deseo hacerlo lo más reproducible posible. ¿Debería usar software gratuito relativamente impopular o propietario extremadamente popular?

No creo que haya una respuesta clara. Si no hay una alternativa viable, habría que usar el software propietario, como hago con Skype. Si hubiera una versión gratuita viable, la usaría. Tenga en cuenta que si más personas comienzan a usar el "software libre relativamente impopular", se volverá más popular. :-)

De acuerdo con la mayoría de lo dicho por EnergyNumbers y David Ketcheson, me gustaría agregar algunos puntos ligeramente diferentes:

• el hecho de que el código esté escrito en un lenguaje particular (Matlab) no lo convierte en fuente cerrada per se.
  Al igual que usar Scilab en Windows de código cerrado (o usar un BLAS de código cerrado) no hace que Scilab sea de código cerrado.
  Hay revistas que requieren investigación reproducible y código abierto y aceptan código Matlab.

• asimismo, popular y libre no se excluyen, ni propietario implica que sea popular

• ninguno de los dos implica que el software respectivo sea adecuado para el análisis de datos reproducibles.

• La elección del idioma debe basarse en varios factores

  • ¿Qué tan adecuado es para el problema en cuestión?
  • aquí también: qué tan adecuado es para el análisis de datos reproducibles (soy científico experimental, por lo que reproducir un análisis de datos es solo una parte de la investigación reproducible para mí)
  • particularmente si se habla de compartir código: consideraciones de infraestructura (¿se puede empaquetar el código en bibliotecas? ¿Cómo se pueden empaquetar los datos, el código y el texto en un documento reproducible?)
  • popularidad = tamaño del grupo de pares que usa este software (que de alguna manera incluye el costo de una licencia)
  • también puede considerar qué está usando el grupo de pares que está interesado en la investigación reproducible (en mi(s) campo(s), la multitud de investigación reproducible coincide mucho más con la multitud de fuente abierta (R), mientras que el grupo de pares que trabaja en el mismo tipo de problema probablemente la mayoría usa Matlab)

• Mi antiguo supervisor solía decir que el costo de una licencia no es un argumento científico.
  Pero, por supuesto, es posible que deba considerarlo.

• Del mismo modo, la popularidad no es un argumento científico, pero debe examinar críticamente si la popularidad realmente indica que existen muchas buenas razones para usar ese software.

Ejemplos:

• En mi campo, R es cada vez más popular (ahora lo suficientemente popular como para publicar en R) y hasta cierto punto reemplaza a Matlab.

  • Entonces, R es gratuito y popular (sin embargo, la mayoría de las personas de mi campo no aprovechan el hecho de que puede buscar en la fuente de R si discuten el análisis de datos reproducibles)

• Razones en mi humilde opinión incluyen

  • lo más importante: R es muy adecuado para nuestro tipo de problemas (creo que es más adecuado que Matlab, otros difieren ligeramente en su opinión y usan Matlab. Incluso otros piensan que en realidad puede ser más adecuado, pero no tanto como para compensar el aprendizaje ahora mismo)
  • Ser adecuado incluye la disponibilidad de los métodos que usamos en CRAN frente a las cajas de herramientas comerciales de Matlab y el repositorio de archivos de Matlab.
  • Ser más adecuado incluye el hecho de que no puedo adaptar el código de las cajas de herramientas patentadas de Matlab (archivos p) a necesidades particulares.
  • Ser adecuado incluye la facilidad de generación de informes
  • infraestructura: por ejemplo, el concepto de paquete de R que impone un estándar mínimo y permite confiar en ejemplos y pruebas que realmente se pueden ejecutar frente a una carpeta llena de archivos .m (escuché que recientemente se introdujo un concepto más parecido a un paquete). Esto ayuda mucho a compartir el código (ya sea para reproducir sus hallazgos o usarlo en sus propios datos)
  • los costos de las licencias son indirectos: es más importante que no tenga que preocuparse si lo instala en su computadora privada también y puede decirles a los estudiantes que lo instalen en sus computadoras portátiles que preocuparse por el costo de algunas licencias para computadoras en trabajar.
  • probablemente mucho más costoso que las tarifas de licencia en sí mismas es el momento de hacer que el administrador de licencias funcione o de transferir licencias entre computadoras, y si solo desea probar una caja de herramientas antes de decidir si comprarla o no, la molestia de a) preguntar al proveedor para obtener una versión de demostración y más adelante b) de completar formularios de pedido y escribir justificaciones de por qué necesita gastar dinero en esa licencia.

Tenga en cuenta cuántos de estos argumentos son "suaves" y, de hecho, tienen más que ver con estar acostumbrado a un sistema u otro o usar una función es más fácil, más obvio o más común entre el grupo de pares de usuarios de ese software: noweb puede trabajar con Matlab, la documentación de m-files es posible y se recomienda (aunque no se aplica realmente), las pruebas unitarias son posibles en Matlab, Matlab Central tiene mucho código libre, etc. Solo los usuarios de R siempre conocen CRAN, mientras que no todos los usuarios de Matlab sabe de Matlab Central, existe una buena cultura de citar artículos científicos sobre el método implementado en los archivos de ayuda de R, enviar código junto con conjuntos de datos de ejemplo y/o proporcionar código de ejemplo en ejecución.

Ejemplos de argumentos inválidos:

• si mis compañeros no usaran el control de versiones para la codificación, no lo consideraría un argumento en contra del uso del control de versiones (ya que hay muchas buenas razones para usarlo)

• O, si los que se niegan a usar el control de versiones estuvieran programando en Matlab, tampoco sería un argumento en contra de Matlab, pero verificaría si hay alguna razón que prohíba el uso del control de versiones para el código de Matlab.

Escuche a sus colegas y compañeros.

Ya te han dicho qué es lo más adecuado para ellos, para que puedan reproducir tus resultados.

Esa respuesta, en su caso particular, es Matlab.

Habrá algunos otros que quieran portarlo a Octave, SciLab, Excel, Fortran o lo que sea. Eso también está bien, pero si es flexible con respecto a la plataforma en la que codifica, y la codificación en Matlab no lo hará menos productivo (o la pequeña reducción en la productividad es un precio que vale la pena pagar por la mayor reproducibilidad), entonces codifique en Matlab. . Porque tus compañeros ya te han dicho que eso es lo que les permite reproducir tu trabajo de la forma más sencilla.

Hay muchas buenas razones (y quizás algunas malas) por las que muchos de sus colegas prefieren Matlab. A veces, las cosas más baratas pueden costarle más.

Para cualquier otra persona que lea esto, con un problema similar, la esencia de la respuesta es la misma: escuche a sus compañeros.

Mis dos centavos:

A menudo comparo el código con un artículo científico. El propósito de un documento es describir sus resultados y el enfoque del problema de tal manera que sus pares puedan validar/refutar sus hallazgos, de la forma que consideren adecuada , de modo que pueda llevarse a cabo un esfuerzo de colaboración para avanzar en el campo. .

¿A quién le importa si el autor del artículo ha usado LaTeX para escribir su artículo o MS Word? ¿A quién le importa si los datos se procesaron con MATLAB, Excel o Pascal? Es la(s) verdad(es) en el artículo lo que cuenta(s), no las herramientas utilizadas para llegar allí (aunque muchos gustosamente entrarían aquí y comenzarían una feroz discusión sobre este punto... pero en mi experiencia, los argumentos utilizados en tales discusiones tienden a parecerse más a la religión que a cualquier otra cosa).

Sin embargo, lo que es muy importante son los medios para comunicarse con sus compañeros. Por ejemplo, si escribes y publicas un artículo en esperanto (suponiendo por el momento que sea aceptado), simplemente porque crees que es hermoso y elegante y que todos deberían hablarlo. Además, hay muchos libros sobre cómo transmitir significado en esperanto, ¿verdad?

No muchos de sus compañeros podrán entender el documento, y mucho menos captar el mensaje y reproducir sus hallazgos. Tendrá que esperar hasta que aparezca alguien en su campo que comparta sus puntos de vista sobre el esperanto, lo que puede llevar media vida. En conjunto, esta es una forma muy pobre de progresar en su campo.

Creo que este es el quid de su situación: si sus pares usan principalmente MATLAB, será mejor que se ciña a MATLAB, porque llegará a la mayoría de los pares más rápido. Deje que (otros) ingenieros averigüen si MATLAB realmente produce buenos (suficientes) resultados para su caso, y déjelo en manos de uno de sus pares a medio mundo de distancia para traducir su código a C++ y verificar sus hallazgos.

No es el código lo que cuenta, es el conocimiento que contiene.

Puedes hacer lo que te dé la gana, pero hay algunas consideraciones:

1) Es posible que tengas la obligación de difundir tu trabajo. Si cuenta con el apoyo de una agencia de financiación externa, como la NSF o los NIH, la difusión es una obligación. Muchas fundaciones privadas y otras fuentes de financiación también brindan apoyo con la intención de difundir, ya sea que se indique explícitamente o no.

Si tiene tal obligación, a falta de cualquier otra consideración, esto sugeriría que use el software más accesible posible, independientemente de si es propietario o gratuito.

2) El código abierto es importante para algunos tipos de investigación, pero para la mayoría de las investigaciones es irrelevante. A menos que esté investigando sistemas informáticos, donde realmente importa cómo llega la computadora a una respuesta, el método no importa tanto como la corrección. A veces puede importar (por ejemplo, si su trabajo depende en gran medida de métodos numéricos), pero probablemente no sea así.

3) Las comunidades establecen normas de validez e integridad. Si todos los demás usan MATLAB, la comunidad lo ha considerado correcto. En ausencia de evidencia de lo contrario, el uso de software de código abierto no hace que sus resultados parezcan más correctos o más verificables a los ojos de nadie.

Como nota al margen, Mathworks tiene una sólida reputación por trabajar con investigadores. Si realmente sintiera que MATLAB le estaba dando resultados incorrectos y tuviera ejemplos para demostrarlo, estarían llamando a su puerta para solucionar el problema. Mathworks me envió un parche de soporte personalizado el mismo día que llamé por una oscura incompatibilidad de hardware que estaba causando un comportamiento incorrecto.