3. Software de investigación abierto y Código Abierto (Open Source)

¿Qué es?

El software de investigación abierto o software de investigación de Código Abierto se refiere al uso y al desarrollo de software para el análisis, la simulación y la visualización (entre otras cosas) cuyo código fuente completo está disponible. Además, de acuerdo a la Definición de Código Abierto, el software de Código Abierto debe distribuirse en forma de código y/o compilado (con el código fuente disponible en el último caso), y debe compartirse con una licencia que permita su modificación, creación de obras derivadas y su redistribución.

Justificación

La investigación moderna depende del software, para la recreación y la reprodubilidad de dicha investigación se requiere el acceso al código fuente de dicho software (Barnes, 2010; Morin et al., 2012; Ince et al., 2012; Prins et al. 2015; Lowndes et al., 2018). Como dicen Buckheit y Donoho, parafraseando a Jon Claerbout, "Un artículo acerca de un resultado computacional es publicidad, no investigación académica. Lo realmente académico es el software completo, el código y los datos que dieron esos resultados" (Buckheit & Donoho, 1995). El acceso abierto al código fuente del software de investigación también ayuda a mejorar el impacto de la investigación (Vandewalle, 2012).

Compartir el software utilizado en la investigación (ya sea que esta posea naturaleza computacional o dependa del análisis/interpretación basado/a en software) es una condición necesaria, aunque no suficiente, para la reproducibilidad. Esto se debe a la inevitable ambigüedad que surge cuando se trata de describir software utilizando el lenguaje natural, por ejemplo, en un artículo científico (Ince et al., 2012). Además, muchos (sino la mayoría) de los programas de software pueden contener errores no detectados (Soergel, 2015). Por tanto, incluso una descripción escrita "perfecta" de un software podría no dar cuenta de todos los resultados.

Ademas de la reproducibilidad, compartir software de manera abierta permite a los desarrolladores el reconocimiento por su trabajo, ya sea a través de cita directa (Smith et al., 2016) o a través de meta-artículos publicados sobre software, por ejemplo, en el Journal of Open Research Software o el Journal of Open Source Software (Smith et al., 2018). Neil Chue Hong mantiene una lista de muchas revistas de dominio específico que publican artículos sobre software.

Objetivos del aprendizaje

  1. Aprender las características del software abierto; entender los argumentos éticos, legales, económicos y de impacto de la investigación en apoyo y en contra del software abierto, y entender mejor los criterios de calidad del Código Abierto.

  2. Aprender como usar software de acceso abierto existente y reconocerlo (citarlo) de manera apropiada.

  3. Aprender como utilizar herramientas y servicios comunes para compartir código de investigación de manera abierta.

  4. Ser capaz de elegir la licencia apropiada para software, y entender las diferencias entre licencias permisivas y no permisivas.

Componentes principales

Conocimiento

Existen distintas plataformas que apoyan la colaboración y el intercambio de software de manera abierta. Primero que nada, puedes utilizar esta lista para evaluar el nivel de apertura de un software de investigación existente:

  • ¿Está el software disponible para descargar e instalar?

  • ¿Puede el software ser instalado fácilmente en distintas plataformas?

  • ¿Tiene el software condiciones de uso?

  • ¿Está disponible el código fuente para su inspección?

  • ¿Está disponible la historia completa del código fuente para su inspección a través de un historial público de versiones anteriores?

  • ¿Están descritas correctamente las dependencias del software (hardware y software)? ¿pueden obtenerse estas dependencias de forma sencilla y ser utilizadas?

Estas cualidades se relacionan y se basan en la Definición de Código Abierto.

GitHub es una herramienta popular que permite el control de versiones: la gestión y el seguimiento de los cambios de un software particular. Los servicios como GitHub, GitLab, Bitbucket y otros proveen de una interfaz a la herramienta como también un sistema de almacenamiento remoto que puede ser utilizado para mantener, compartir y colaborar sobre software de investigación. Se trata de una herramienta cuyo uso es bastante generalizado y que, si bien posee requiere un aprendizaje inicial, ha demostrado ser de un valor inestimable para el establecimiento de un flujo de trabajo abierto y reproducible.

Tener el software en GitHub es sólo la primera parte; es igualmente importante tener un identificador persistente publicado asociado con él, como un DOI. Hay distintas formas de asociar un DOI con un repositorio de GitHub. La forma más fácil es utilizar Zenodo (un repositorio gratuito y abierto general creado por OpenAIRE y CERN) para hacer la asignación, aunque existen otros repositorios para archivar software y obtener un DOI, como por ejemplo Figshare. Zenodo se integra con GitHub para archivar el software y le asigna un DOI cuando los desarrolladores hacen un nuevo lanzamiento formal en GitHub.

El software compartido públicamente no es de Código Abierto a menos que esté acompañado de una licencia adecuada porque, por defecto, el software (así como cualquier otro trabajo creativo) posee derechos de autor exclusivos para los creadores, lo que significa que nadie lo puede usar, copiar, distribuir o modificar (choosealicense.com). (Si realmente quieres compartir el código sin ningún tipo de restricciones, puede ser incluido en el dominio público.) En lugar de ello, puedes elegir una licencia apropiada para tu software en función de lo que desees que otros puedan hacer con tu código (o impedir que hagan ); el sitio choosealicense.org es un recurso útil para diferenciar entre distintas licencias, aunque no incluye todas las licencias de Código Abierto disponibles o populares. Una vez que selecciones una licencia, pon el texto -editado para incluir el nombre del o los autor(es) y el año- en el repositorio de software como un archivo de texto con el nombre LICENSE.

Aunque compartir software en cualquier forma es mejor que no compartirlo, tu software tendrá más impacto y podrá ser más fácilmente utilizado por otros -y por ti mismo en el futuro!-, si incluyes documentación. Esto puede incluir comentarios útiles en el código que expliquen por qué hiciste algo (en vez de sólo lo que hiciste, que debería ser evidente), un archivo README informativo que describa lo que hace tu software y brinde información útil (e.g., cómo instalar, cómo citar, cómo ejecutar el software, dependencias importantes), tutoriales/ejemplos, y/o documentación de API (que puede ser automáticamente generada a partir de comentarios apropiadamente formateados en el código).

Las dependencias perdidas o inaccesibles o una documentación insuficiente sobre el entorno computacional son barreras muy comunes en contra de la reutilización y la reproducibilidad. Una forma de abordar estas barreras es compartir tu código en un entorno computacional usando tecnología de contenedores (container technology). Los contenedores empacan el código con las dependencias y el entorno computacional para que otros pueden ejecutar más fácilmente tu análisis. Los siguientes son ejemplos de la implementación de contenedores en investigación: Rocker, Binder, y Code Ocean.

Cuando usas software -ya sea software que creaste o que alguien más lo hizo y lo compartió-, citarlo de manera apropiada es importante para la reproducibilidad (esto se discute en más detalle en la Sección 4; brevemente, la versión usada puede cambiar tus resultados o interpretación) y para dar crédito a los desarrolladores del software (Niemeyer 2016, Smith 2016). La decisión de cuándo citar software depende de ti como investigador, pero recomendamos citar siempre que el software utilizado haya contribuido de manera integral a tus resultados, interpretación o conclusiones. La mejor manera de hacer que tu código sea fácilmente citable es usar la integración de GitHub–Zenodo descrita antes y mencionar el DOI en el lugar adecuado, como en el fichero README, junto con la sugerencia de cómo citarlo. Cuando se cita cualquier software debes incluir, al menos, el nombre de los autores, el título del software, el número de la versión, y un identificador o localizador único (Smith 2016). Si usas el software de alguien y dispone de DOI, lo puedes utilizar fácilmente para identificar y citar el software; si el software no se encuentra archivado, entonces debes incluir el URL donde localizarlo y el número de versión o (e.g.) el hash de un commit (por ej., en GitHub).

Adicionalmente, existen conceptos más complejos como el test automático y la integración continua del software, el empaquetado de software en formatos binarios, y la gobernanza y la gestión de proyectos de Código Abierto multi-persona (esto es, códigos de conducta, guías de contribución y autoría). Algunos de estos temas han sido descritos por Scopatz y Huff (2015). Wilson et al. (2017) que también han creado una guía práctica de las mejores prácticas de computación científica que incluye consejos específicos para el desarrollo de software para la investigación.

Hardware de Código Abierto

Los principios de Código Abierto descritos anteriormente se extienden al hardware. Los investigadores usualmente utilizan instrumental o hardware patentado en su investigación que no es de libre acceso, reusable ni adaptable. El hardware científico incluye desde herramientas de secuenciación y microscopios hasta el equipamiento de análisis especializado y colisionadores de partículas. La Comunidad de Hardware Abierto (Open Science Hardware (OScH)), por ejemplo, está luchando para que el movimiento de Código Abierto considere las herramientas científicas, el hardware, y las infraestructuras de investigación a través de su Hoja de Ruta Global de Hardware de Ciencia Abierta.

Habilidades

  • Crea un repositorio en Github, y permite la integración con Zenodo. Acuña la primera versión del software.

  • Elige una licencia de software usando, por ejemplo, choosealicense o la Iniciativa Open Source.

  • Crea la documentación necesaria para el paquete de software, incluyendo un README, comentarios y ejemplos.

  • Cita de manera apropiada el software utilizado en los artículos de investigación.

Preguntas, obstáculos e interpretaciones erróneas comunes

Q: "No puedo compartir mi software, está muy desordenado / no tiene una buena documentación / no dejé buenos comentarios"

A: Los desarrolladores de software de investigación en todo el mundo empatizan con este sentimiento. Las personas rara vez creen que su software está "listo" para ser compartido públicamente o que ya está "terminado". Sin embargo, como sostiene Barnes (2010), “si tu código es lo suficientemente bueno como para hacer su trabajo, entonces es lo suficientemente bueno o como para ser publicado, y publicarlo ayudará a tu investigación y a tu área de investigación." En otras palabras, si te sientes suficientemente conforme con tu software como para publicar un estudio o publicar resultados, entonces el código está lo suficientemente desarrollado como para compartirlo con tus colegas. (Contrariamente, si no te sientes cómodo compartiendo el código, entonces tal vez requiera un poco más de desarrollo o prueba antes de ser utilizado en una publicación). Además, compartir tu código le permite a otros mejorarlo y construir sobre el, lo que conduce a un impacto y una innovación incluso mayores (¡y a que seas citado más veces!).

Q: "¿Qué ocurre si alguien toma el código que he compartido y lo utiliza con propósitos maliciosos o dice que es de su autoría?"

A: Seleccionar una licencia apropiada para tu software te ayudará a protegerlo de los usos que puedan hacer otros de él; por ejemplo, la licencia común MIT incluye limitaciones de responsabilidad e indica que no se proveen garantías. Si alguien trata de atribuirse la autoría de tu software, puedes indicar las marcas temporales (timestamps) de tu repositorio o las versiones archivadas como prueba de la precedencia de tu trabajo.

Q: "Si comparto mi código en un repositorio online, recibiré un número excesivo de peticiones de ayuda."

A: Aunque pueden haber usuarios que podrían pedirte ayuda, ya sea vía correo electrónico o, por ejemplo, a través de mensajes en el repositorio online, no tienes ninguna obligación de atender estas demandas si no puedes o prefieres no hacerlo. Una licencia apropiada incluso, puede protegerte de hacerlo (por ejemplo, la cláusula de no garantías de la licencia MIT).

Una idea errónea muy común: la simple disposición del código en línea hace que un software sea de Código Abierto. En realidad, a menos que el software esté acompañado de una licencia que concede permiso a otros para su uso, copia, modificación y/o distribución, los desarrolladores mantienen derechos de autor exclusivos sobre el software. Para que un código sea de Código Abierto debe ir acompañado de una licencia de Código Abierto.

Resultados del aprendizaje

  1. Ser capaz de compartir software con la licencia más apropiada (esto es, tanto las herramientas como la licencia).

  2. Ser capaz de subir, crear versiones y registrar código empleando un identificador persistente.

  3. Ser capaz de citar software utilizado para un artículo de investigación.

Lecturas adicionales

results matching ""

    No results matching ""