Software sostenible, comunidades sostenibles

Aprendizajes desde rOpenSci

Yanina Bellini Saibene

De qué habla esta charla

Resumen

Mantener software de investigación es un desafío que trasciende el código.

Documentación, incorporación de nuevas personas colaboradoras, gobernanza, mentoría y construcción de comunidad son tan importantes como el código mismo.

Hoy vamos a recorrer el ciclo de vida del software de investigación y ver, con ejemplos concretos de rOpenSci, cómo se puede apoyar cada etapa desde una perspectiva centrada en las personas.

Esta no es una charla técnica sobre cómo escribir mejor código R, sino sobre la infraestructura social y organizativa que hace que ese código sobreviva.

El desafío

Software de investigación: la parte invisible de la ciencia

• Se escribe bajo presión de tiempo, financiamiento acotado y poco reconocimiento académico
• Quien lo crea muchas veces no es quien lo mantiene después
• El conocimiento crítico vive en la cabeza de una sola persona
• El “éxito” de un paquete no es publicarlo: es que siga vivo dentro de tres, cinco, diez años

Anclar el problema en la experiencia de la audiencia (research software engineers): todos conocen un paquete abandonado, un mantenedor que no pudo mas, un proyecto sin documentación.

La sostenibilidad no es (sólo) un problema “técnico”

Lo técnico

• Tests
• CI/CD
• Estándares de código
• Arquitectura
• Diseño

Lo humano

• Documentación pensada para otras personas
• Onboarding de personas colaboradoras
• Gobernanza y toma de decisiones
• Mentoría
• Comunicación

Ambos aspectos son necesarios. Hoy nos enfocamos en el segundo.

¿Qué es rOpenSci?

Una comunidad global que impulsa software abierto y reproducible para la investigación.

• Nace en 2011 en torno a paquetes de R para ciencia abierta
• Hoy combina: revisión de software, infraestructura (r-universe), formación, mentoría y construcción de comunidad
• No es solo “un catálogo de paquetes”: es una red de apoyo para quienes los crean y mantienen

rOpenSci funciona como estudio de caso porque aborda explícitamente las dimensiones no técnicas de la sostenibilidad, no solo la calidad del código.

El ciclo de vida del software de investigación

Ocho etapas, un ciclo continuo

Ocho etapas, un ciclo continuo

No es lineal: es un ciclo que se retroalimenta — adopción y mantenimiento genera nuevas ideas.

Etapa 1 · Idea y necesidad

Qué implica

• Identificar un problema real en la investigación
• Revisar si ya existen herramientas

Cómo apoya rOpenSci

• Slack para validar ideas con otras personas
• Community Calls abiertas donde se presentan necesidades y proyectos en curso
• Listado de Paquetes y Casos de Uso
• Dashboard de “salud” de paquetes
• R-Universe: para descubrir paquetes (CRAN, Bioconductor, R-Multiverse, etc)

Etapa 2 · Diseño y planificación

Qué implica

• Definir alcance y usuarios
• Diseñar funcionalidades
• Planificar el desarrollo

Cómo apoya rOpenSci

• Guía de desarrollo de paquetes y buenas prácticas desde el diseño, mantenimiento
• Blog post tematicos
• Newsletter: “developer corner”

Etapa 3 · Desarrollo

Qué implica

• Escribir código
• Pruebas unitarias
• Documentar sobre la marcha

Cómo apoya rOpenSci

• Todo lo anterior y …
• Blog y tutoriales con aprendizaje entre pares
• Mentoría informal vía Slack
• Sesiones de co-working y otros eventos

Etapa 4 · Pruebas y aseguramiento de calidad

Qué implica

• Revisión de código
• Pruebas automatizadas
• Mejora continua

Cómo apoya rOpenSci

• Todo lo anterior y …
• Software Peer Review: revisión por pares abierta, constructiva y no adversarial
• pkgcheck: chequeos automáticos al momento de someter un paquete

Etapa 5 · Documentación y ejemplos

Qué implica

• Documentar el uso
• Crear ejemplos y tutoriales
• Vignettes
• Videos/tutoriales

Cómo apoya rOpenSci

• Todo lo anterior y …

• Estándares de documentación exigidos durante la revisión

• Guías de mejores prácticas de documentación en el devguide

• Guía para traducir contenido

Etapa 6 · Publicación y liberación

Qué implica

• Preparar para CRAN
• Liberar versión estable
• Anunciar al mundo: asistir/organizar eventos, dar charlas.

Cómo apoya rOpenSci

• R-Universe: infraestructura para publicar y descubrir paquetes, con o sin CRAN
• Ayuda con el proceso de CRAN y difusión en el blog/boletín de rOpenSci
• Guía de organización de eventos
• Guía para escribir blog post
• Entrenamiento en estas habilidades

Etapa 7 · Adopción y comunidad

Qué implica

• Recibir feedback
• Dar soporte a usuarios/as
• Construir comunidad

Cómo apoya rOpenSci

• Champions Program: acompañamiento estructurado de 12 meses
• Community Calls y foros para sostener soporte continuo e inclusivo
• “Help Wanted” issues
• Eventos especiales como mini-hackathons

Etapa 8 · Mantenimiento y evolución

Qué implica

• Corregir errores
• Añadir funcionalidades
• Adaptarse a cambios (del lenguaje, de CRAN, del equipo)

Cómo apoya rOpenSci

• Orientación sobre gobernanza, financiamiento y transición de mantenimiento
• Reconocimiento explícito a mantenedores/as (p. ej. “Maintainers Month”)
• Apoyo a maintainers: encuesta anual, ayuda buscando personas que contribuyan, marketing del paquete/equipo
• Dashboard de salud del paquete

Programas concretos de rOpenSci

Aprendizajes

• Software Peer Review tiene onboarding con calidad. El proceso completo ocurre en GitHub, en abierto, de punta a punta.

Aprendizaje: autores/as, revisores/as y editores/as se conocen entre sí y conversan directamente. Es revisión transparente y con mentoría incorporada, no un filtro anónimo.

• De paquetes a algoritmos con el Statistical Software Peer Review: extensión del proceso de revisión a software estadístico

Aprendizaje: ampliar el alcance de un programa de calidad requiere gobernanza, documentación propias e involucramiento de la comunidad.

Aprendizajes

• R-Universe es infraestructura para ahorrate tiempo y que te encuentren: permite publicar y distribuir paquetes directamente desde GitHub, con métricas y documentación automática. Hoy lo usan otras iniciativas: Bioconductor, R-Multiverse.

Aprendizaje: la sostenibilidad también es visibilidad e instalacion sencilla: un paquete que nadie encuentra o es dificil de configurar no sobrevive.

• El Programa de Campeon(a|e) ofrece mentoría (que se entrena) con estructura

Aprendizaje: la mentoría sostenible no es “buena voluntad espontánea”: es un rol con guía, formación y reconocimiento.

Aprendizajes

• Community Calls, co-working sessions y otros eventos: encuentros abiertos y regulares donde la comunidad presenta proyectos, herramientas e iniciativas, donde trabajan y aprenden en grupo. El Slack sostienen ese vínculo entre eventos

Aprendizaje: los eventos presenciales/sincrónicos generan capital social que después sostiene la colaboración a distancia.

• Gobernanza y Código de Conducta: CoC vigente para todos los espacios y valores explícitos.

Aprendizaje: la gobernanza explícita no es burocracia, es lo que permite que una comunidad diversa se sienta segura para participar.

Aprendizajes

• Documentación como infraestructura: todas las guias y libros que comparti son libros vivos, versionados y abiertos a contribución. Todo el contenido y sus traducciones se mantienen con el mismo espíritu que el software, que sirvan para otras comunidades tambien.

Aprendizaje: documentar los procesos (cómo se revisa, cómo se contribuye) es tan importante como documentar el código.

El hilo común

Sostenibilidad = personas en el centro

Lo que vimos

• Revisión por pares con mentoría incorporada
• Infraestructura para publicar y que te encuentren (r-universe)
• Programa de Campeon(a|e)s: mentoría estructurada
• Código de Conducta y gobernanza explícita
• Documentación de procesos, no solo de código

El patrón

Cada programa resuelve un problema social u organizativo, no (solo) uno técnico.

rOpenSci no “arregla” la sostenibilidad: crea condiciones para que las personas puedan sostenerla.

Aprendizajes para tu propio proyecto

1. Documentar es cuidar
2. La incorporación de colaboradores/as se diseña, no se improvisa
3. La gobernanza clara previene (muchos) conflictos
4. La mentoría sostenible necesita estructura y reconocimiento
5. La comunidad sostiene lo que el código no puede sostener solo

Para empezar hoy

• Chequea tu README, asegurate de tener Licencia.
  
• Escribí una guía de contribución, aunque tu proyecto sea chico
• Definí (por escrito) cómo se toman decisiones y cómo se resuelven conflictos
• La revision de Pull Request o la contestacion de issues es un espacio de mentoría
• Reconocé públicamente a quienes ayudan con tu software, mas alla del codigo.
• Sumate a una comunidad existente antes de crear una nueva desde cero

Recursos

• ropensci.org — sitio principal
• devguide.ropensci.org — guía de desarrollo y revisión por pares
• stats-devguide.ropensci.org — revisión de software estadístico
• contributing.ropensci.org — guía de contribución a la comunidad
• mentors.ropensci.org — formación de mentoras/es
• ropensci.org/champions — Champions Program
• ropensci.org/r-universe — r-universe
• ropensci.org/code-of-conduct — Código de Conducta

¡Gracias!

Yanina Bellini Saibene

Community Manager, rOpenSci

Sovereign Tech Fellow

yabellini@ropensci.org

@yabellini (en BlueSky, Mastodon, LinkedIn)