Deuda técnica: mi biblioteca Rust ahora es un CDO
La deuda técnica como metáfora de derivado / CDO
- A muchos les gusta encuadrar la deuda técnica como un derivado y no solo como “deuda”: su perfil de riesgo depende de las dependencias en capas y de quién lo “dispara” en producción.
- La analogía con los CDO se usa para ilustrar el riesgo sistémico: agrupar muchos componentes frágiles en paquetes aparentemente “seguros” puede ocultar la fragilidad subyacente.
- Algunos creen que la analogía solo funciona parcialmente: a diferencia de los CDO de 2008, los mantenedores que hacen vendoring o bifurcan código a menudo aún pueden cambiar los fundamentos y mejorar el activo.
Vendoring, bifurcación y riesgo de dependencias
- Para algunos, hacer vendoring de dependencias abandonadas es una victoria clara: sin cambios inesperados aguas arriba, menos riesgo de cadena de suministro y más facilidad para podar rutas de código no usadas.
- Otros lo ven como “teatro de dependencias” si simplemente fijas versiones y haces vendoring sin revisar ni modificar realmente el código.
- Hay debate sobre la etiqueta: informar errores y ofrecer correcciones primero, luego bifurcar si los mantenedores no responden; las bifurcaciones no tienen por qué ser permanentes.
Crates de YAML y secuelas de RustSec
- El desencadenante específico fue un aviso contra un crate de YAML muy usado y otro gran crate de YAML marcado como sin mantenimiento.
- Las herramientas ahora señalan estos crates, encendiendo CI para miles de dependientes; algunos argumentan que esto expone correctamente el riesgo latente, otros dicen que se trata como algo excesivamente urgente.
- Hacer vendoring del código YAML en una biblioteca consumidora elimina el ruido del aviso, pero traslada la carga de mantenimiento y reduce la visibilidad compartida de problemas futuros.
Ecosistema de Rust, tamaño de la stdlib y explosión de dependencias
- Varios comentarios critican la pequeña biblioteca estándar de Rust y su fuerte dependencia de crates de terceros, especialmente para aspectos básicos como async, RNG, hashing y YAML/JSON/SSL.
- Otros defienden el diseño: mantener pequeña la std preserva la mantenibilidad a largo plazo y permite iterar más rápido fuera del árbol.
- Quejas sobre crates.io: crecimiento sin moderación, muchas utilidades pequeñas, múltiples versiones de los mismos crates básicos y grandes grafos transitivos incluso para proyectos pequeños.
Herramientas de seguridad, gobernanza y financiación
- Los escáneres de seguridad y las políticas corporativas suelen tratar “sin mantenimiento” como algo igual de malo que las vulnerabilidades activas, provocando alertas ruidosas.
- Algunos quieren señales más ricas (severidad, explotabilidad, solo dev frente a runtime, completo pero estable frente a realmente abandonado).
- Las propuestas incluyen: listas de crates “bendecidos”, agencias de calificación de paquetes, mecanismos legales para adquisiciones de registros de paquetes críticos abandonados y una financiación más directa de los mantenedores.
- Otros responden que el software libre no viene con garantías de mantenimiento; esperar soporte gratuito perpetuo se ve como una actitud de derecho adquirido.