Aviso: Este es un post antiguo, puede que su información esté desactualizada. Si está buscando algo sobre un evento actual, tenga en cuenta que puede que este no sea el que busca.
Ya dimos nuestras razones, pero Slashdot nos da unas cuantas más, apuntando a éste artículo de Darrel Ince a propósito del fiasco de los emails de la Unidad de Investigación del Clima, donde también se encontraron una serie de ficheros README en los que se hablaba de los trucos que se habían hecho para que las gráficas salieran como tenían que salir.
Ojo, esta historia es posiblemente totalmente justificable: los datos vienen en muchos formatos, algunos tienes errores, y muchas veces hay que incluir suposiciones en el programa que serían difíciles de explicar en un trabajo. El problema, siempre, es que pueden aparecen errores que se descubren una vez publicado el trabajo, y, casi siempre, que el software creado con prisa y sin seguir ninguna metodología (ni siquiera ágil o extrema) es lento, poco eficiente, y poco configurable o flexible.
Por eso pedimos desde aquí que, simplemente para que la ciencia que uno haga sea reproducible, libera siempre tu trabajo antes de publicarlo. Saldrás ganando.
Pingback: Software Libre, Recuperación Económica y Economía Sostenible. | Blog de Luis Casas Luengo
Pingback: Software Libre, Recuperación Económica y Economía Sostenible. | Blog de Luis Casas Luengo
Pingback: Tweets that mention La buena ciencia empieza por la liberación del código – Oficina de Software Libre de la Universidad de Granada -- Topsy.com
Pingback: Tweets that mention La buena ciencia empieza por la liberación del código – Oficina de Software Libre de la Universidad de Granada -- Topsy.com
Si es abierto, es mucho mas facil detectar errores, y porque no se añade que creo que es donde esta su potencial. MEJORARLO Y REUTILIZARLO