Mantener un proyecto de código abierto puede ser una gran responsabilidad. Sin embargo, no es una carga que se deba llevar indefinidamente. A veces, la demanda de un proyecto disminuye debido a la aparición de soluciones mejores o a la evolución tecnológica, que a menudo justifica comenzar de nuevo en lugar de adaptar un proyecto antiguo. En ocasiones, la decisión correcta es avanzar, incluso si eso significa retirar un proyecto.
Brett Terpstra, desarrollador front-end, gestiona más de 100 repositorios en GitHub y ha tenido que retirar varios de ellos. “Los proyectos que dependen de APIs y otras aplicaciones externas a menudo requieren más trabajo del que vale la pena cuando las cosas empiezan a fallar,” explicó en una entrevista. “Históricamente, esos son los proyectos que se retiran más rápido”.
Cualquiera que sea la razón para deprecar un proyecto, es importante hacerlo de manera cuidadosa para proteger la reputación del desarrollador y considerar a los usuarios. Entre las recomendaciones de los expertos en la materia, se enfatiza no mantener un proyecto durante más tiempo del necesario.
Olga Botvinnik, bióloga computacional, deseaba haber retirado su paquete de visualización de datos en Python, prettyplotlib, previamente. Aunque no quería abandonar el proyecto, este se originó como parte de su trabajo de doctorado y actualizarlo para soportar Python 3 le resultaba desalentador, mientras que su interés se dirigía hacia nuevos proyectos. Además, otra biblioteca de visualización en Python llamada Seaborn ganaba popularidad. Botvinnik consideraba que Seaborn era mejor y más pulida, por lo que decidió deprecar prettyplotlib y centrar sus esfuerzos en contribuir a Seaborn en su lugar. Esta decisión fue respaldada por el consejo de uno de sus mentores, quien le enseñó que saber cuándo terminar un proyecto es tan valioso como completarlo.
Otra clave es dejar la puerta abierta para que otros continúen con el proyecto. Terpstra siempre busca a alguien que pueda asumir sus proyectos antes de cerrarlos. Existen varios grados al retirar un proyecto, y en algunos casos basta con indicar que no se actualiza frecuentemente, permitiendo nuevas contribuciones. Sin embargo, no siempre es adecuado transferir un proyecto. Ben Johnson, mantenedor de la herramienta de recuperación de SQLite Litestream, optó por retirar BoltDB y recomendar una bifurcación llamada BBolt en vez de transferir el proyecto original, preservando así su reputación.
Es crucial anunciar la retirada de un proyecto con antelación. Terpstra da aviso con al menos un mes de anticipación, dejando un margen para resolver problemas y ayudar a los usuarios a hacer la transición. Una vez decidido el retiro, se debe informar a los usuarios y, si es posible, sugerir alternativas.
Mantener el código online es otra recomendación importante. En lugar de eliminar el proyecto, archivarlo es una opción que lo deja en modo lectura, comunicando así a los usuarios que ya no se mantiene. Esto permite que otros puedan encontrar algo útil o continuar desarrollándolo más adelante. Sin embargo, si el código es potencialmente dañino, especialmente por vulnerabilidades de seguridad, es recomendable eliminarlo.
Al final, reconocer cuándo y cómo dejar ir un proyecto de código abierto es no solo una buena práctica, sino una parte esencial del ciclo de vida en este ámbito.
vÃa: Github Open Source
