Cómo vincular código a publicaciones

Los trabajos académicos en computación científica (y muchos otros campos, hoy en día) generalmente involucran cierta cantidad de código o incluso paquetes de software completos que se escribieron específicamente para ese papel o se usaron para obtener resultados en el papel. ¿Cuál es la mejor manera de ayudar a los lectores del periódico a acceder al código? Mi enfoque actual es poner un enlace a un repositorio de Github (junto con una etiqueta de versión particular) en el documento o en una cita.

Bueno, creo que tienes algunas opciones.

1. Si tiene una página estable, como una patrocinada por una universidad u otra institución sin fines de lucro que es poco probable que desaparezca pronto, podría publicarla allí.
2. Puede usar un servicio como Github o Bitbucket o SourceForge para distribuir el código.
3. Si el código tiene un valor general marginal (es un código de análisis para un conjunto específico de condiciones, etc.), puede hacer que el código esté disponible como una descarga de "información complementaria" con el documento en el que lo usa.
4. Podrías usar alguna combinación de lo anterior.

Sin embargo, en cualquiera o en todos estos casos, debe indicar el origen claramente en el artículo e indicar qué tipo de licencia es (GPL, Creative Commons, etc.), para que no haya problemas relacionados con la propiedad intelectual en el futuro.

Gran pregunta y excelentes respuestas, pero creo que ninguna aborda adecuadamente la cuestión de la persistencia, si el objetivo es lograr el mismo estándar acorde con la publicación misma. (Lo cual puede ser una tontería dadas las posibilidades de que el código aún se ejecute , pero puede ser al menos tan útil como la publicación de todos modos).

Los suplementos de revistas de sitios web universitarios no son persistentes

Es poco probable que los sitios web de las universidades proporcionen la estabilidad o la redundancia para preservar el contenido alojado. El contenido es más difícil de citar y generalmente carece de metadatos legibles por máquina.

Desafortunadamente, parece que las revistas no están haciendo mucho mejor en el mantenimiento de sus materiales suplementarios (ver Anderson et al. 2006 ), y pueden no aceptar los formatos necesarios, o incluso aceptar material suplementario (ver un ejemplo notable ).

Por estas razones, las personas preocupadas por el archivado de datos a largo plazo han recurrido unánimemente a abogar por el uso de repositorios dedicados en lugar de sitios web o materiales complementarios, y muchas revistas ahora exigen esta práctica . Parece justo que el código se cumpla con este estándar.

¿La solución de muchas copias?

Github y los sitios relacionados aún no han demostrado su longevidad a lo largo de los 100 años de escala alcanzada por las bibliotecas universitarias y las editoriales establecidas. Al facilitar la distribución generalizada, puede proporcionar una solución que otros han hecho eco en los comentarios, incluido un compañero que no pudo comentar sobre stackexchange,

... guardemos lo que queda: no con bóvedas y cerraduras que los cierren de la vista del público y utilicémoslos para consignarlos a la pérdida de tiempo, sino mediante tal multiplicación de copias, que las colocará fuera del alcance del accidente.

- Thomas Jefferson, 18 de febrero de 1791

Figshare y el estándar CLOCKSS

El único estándar de archivo que conozco es figshare , que puede aceptar repositorios de código completos (como "conjuntos de archivos" por el momento, pero creo que pronto tendrá la opción de aparecer como tipo "código"). La pieza clave de figshare no es solo el DOI citable con metadatos programáticos, sino el respaldo del servicio de archivo CLOCKSS , que mantiene copias de todo su contenido en 12 nodos distribuidos geográficamente y geopolíticamente en todo el mundo. Si se comparte el negocio o deja de existir, esto hará que todo su contenido esté disponible gratuitamente desde CLOCKSS.

En consecuencia, sugeriría usar Github para la distribución de código, pero también proporcionar una copia de archivo a figshare en el momento de la publicación.

Puede utilizar algunas técnicas de pdf sofisticadas para simplemente adjuntar el código al pdf (es decir, los archivos de código se incrustan en el pdf y se pueden "descargar" haciendo clic en algún botón en el pdf). Esto se puede lograr con el paquete attachfile , por ejemplo. Por supuesto, esto funciona con preimpresiones (aunque no sé si ya funciona con el arxiv) pero probablemente tenga problemas con los archivos de diario ...

Para guiones pequeños que son específicos de un proyecto de investigación específico, el mejor lugar para la publicación es el sitio web de la revista, como "información complementaria" del documento. Ahí es donde es más fácil encontrar a alguien que lea el artículo.

Los paquetes más importantes que sean de interés para otros proyectos también deberían publicarse mejor por separado. Lamentablemente, no hay una solución realmente buena en este momento. Idealmente, una publicación de código sería accesible permanentemente a través de un DOI, al igual que un documento, pero no conozco ningún sitio de alojamiento que distribuya DOI y garantice su permanencia. Los repositorios públicos como Github o Bitbucket son quizás la mejor apuesta por ahora.

La mejor solución sería publicar el documento empaquetado con el código y los datos que lo acompañan, pero eso aún no es técnicamente factible. Estoy trabajando en un prototipo de investigación que explora esta idea, vea este sitio para más detalles.

He tomado dos tácticas, nacidas del hecho de que anticipo cambiar de institución pronto, por lo que la URL de mi universidad no es estable en lo más mínimo.

Cuando el código es relativamente corto, he intentado incluirlo como un apéndice suplementario en el propio diario, bajo el supuesto de que probablemente harán un trabajo decente manteniendo el papel y el código aproximadamente en el mismo lugar. Esto es especialmente útil para el código donde no hay una gran cantidad de interés general, código que es algo inútil sin el documento en cuestión para proporcionar contexto.

Pero para el código fuente, el software real y los proyectos más complicados o de interés general, he seguido su táctica de vincular a un repositorio de GitHub, que al menos debería ser estable para la vida productiva promedio de mis documentos.

Echa un vistazo a http://www.runmycode.org . Alojan sitios complementarios para el código asociado con trabajos de investigación. Si el código es R, Matlab u otros, ejecutará el código por usted. Todavía no lo he probado, pero tengo la intención de hacerlo. Creo que David Donoho y sus colaboradores lo usan.

Las bibliotecas universitarias podrían ser un lugar para esto o el centro de acogida de la universidad.

Como lector, una declaración en el documento en el sentido de que el código puede obtenerse contactando directamente al autor sería efectivo. Como autor, esto podría ayudar a fomentar la colaboración y darme la oportunidad de recordarles a las personas que citen mi artículo si usan el código en su trabajo.