Por favor, no preguntes si un proyecto de código abierto está muerto
La tensión entre mantenedores y usuarios de código abierto surge cuando la gente pregunta si un proyecto está “muerto”, especialmente en repositorios que parecen quietos o tienen incidencias sin resolver. Los comentaristas sostienen que los usuarios necesitan razonablemente saber si un software se mantiene antes de depender de él, mientras que los mantenedores recalcan que no deben soporte continuo y pueden sentirse presionados o desanimados por esas preguntas. Muchos proponen señales de estado más claras en los README, mejor tooling de GitHub (archivo, insignias, rutas de sucesión) y una formulación más considerada para que las expectativas de ambas partes estén mejor alineadas.
Si preguntar “¿Está muerto este proyecto?” es de mala educación
- Muchos sostienen que es una pregunta perfectamente razonable, incluso necesaria: los usuarios deben saber si es seguro depender de una biblioteca, especialmente por los parches de seguridad y los cambios incompatibles aguas arriba.
- Otros dicen que expresiones como “muerto/abandonado” tienen una carga emocional y suenan acusatorias; sugieren una formulación neutral como “estado actual de mantenimiento” o “¿se mantiene activamente?”
- Varios comentaristas creen que el ejemplo concreto del problema en el artículo fue educado, y que calificarlo de “presión” o “mala educación” fue una sobrerreacción nacida del estrés y el agotamiento.
Mantenimiento, ecosistemas y software “terminado”
- Algunos dicen que el software puede estar “terminado” y no necesitar commits frecuentes; la falta de actividad no es inherentemente un problema.
- Otros replican que en ecosistemas como Node/npm o APIs que cambian rápidamente, la degradación y los problemas de seguridad de dependencias hacen que el mantenimiento continuo sea esencial.
- Debate sobre la “degradación del código”: algunos culpan a las plataformas cambiantes y a la mala compatibilidad hacia atrás en lugar del código original.
Forks y sucesión de proyectos
- Muchos consideran que hacer un fork es la solución estándar cuando un mantenedor no responde o no está interesado en los PR.
- Se señalan desventajas: múltiples forks medio mantenidos, “sucesor” poco claro, fragmentación social y rebases dolorosos si el proyecto original revive más tarde.
- Otros señalan que proyectos importantes (Linux, BSD, suites ofimáticas, motores de navegadores) surgieron de forks; que la mayoría de los forks fracasen se ve como algo normal.
Expectativas, comunicación y funciones de GitHub
- Sugerencia repetida: dejar claro el estado y las expectativas en el README/CONTRIBUTING (por ejemplo, “terminado”, “solo correcciones de seguridad”, política de PR, actitud hacia los forks).
- La marca de archivo de GitHub se ve como una forma útil, aunque infrautilizada, de indicar inactividad; algunos quieren mecanismos más ricos de estado/insignias y una interfaz para destacar forks activos.
- Varios dicen que desactivar issues/PR es apropiado si no se quiere interacción.
Responsabilidades y salud mental
- Hay amplio acuerdo: los mantenedores no le deben nada a los usuarios por contrato; los usuarios y colaboradores tampoco le deben nada a los mantenedores.
- Aun así, muchos subrayan la educación básica, el agradecimiento y las ofertas de ayuda o patrocinio.
- Algunos ven el artículo como una señal de agotamiento y aconsejan dar un paso atrás en lugar de publicar reglas prescriptivas y cargadas emocionalmente de “no preguntes”.