Deuda técnica: mi biblioteca de Rust ahora se convirtió en un CDO

Deuda técnica: mi biblioteca de Rust ahora se convirtió en un CDO

• Como broma sobre la deuda técnica, existe el chiste de que si hay deuda técnica, también deberían existir derivados para manejar esa deuda.
• El ecosistema de Rust terminó creando una solución que parece titularizar la deuda técnica.
• Por ejemplo, una biblioteca stuff depende de otra biblioteca learned-rust-this-way, pero el autor de learned-rust-this-way pierde el interés y los problemas empiezan a acumularse.

La realidad de la deuda técnica

• learned-rust-this-way se considera deuda técnica, lo que no causa un problema directo, pero sigue siendo deuda.
• En algún momento, alguien se da cuenta de que learned-rust-this-way es deuda, no logra contactar al autor original y se agrega a la base de datos de RUSTSEC.
• RUSTSEC, como agencia calificadora, evalúa esa deuda como basura, y por eso el CI (integración continua) de mucha gente empieza a fallar.

Cómo resolver la deuda

• Como mantenedor de stuff, aumenta el estrés cuando los usuarios plantean problemas por el uso de learned-rust-this-way, y te exigen tomar medidas para manejar la deuda.
• Migrar a una alternativa es una opción, pero en este caso ninguna de las alternativas resulta atractiva.
• Si haces un fork de learned-rust-this-way, te enfrentas a las mismas exigencias, y eso solo es una solución temporal, no resuelve el problema.

La solución que realmente funciona

• Si incorporas ese código dentro de tu propia biblioteca, esa deuda técnica basura de pronto recibe una calificación “AAA”.
• Si ya no tocas el código, ocultas el hecho de que lo integraste y sigues manteniendo la biblioteca como antes, el mundo sigue girando.
• Al vendorizar e integrar yaml-rust en insta, se convirtió en una combinación del código de insta y yaml-rust, y así la deuda técnica fue mejorada a categoría AAA.

La opinión de GN⁺

• Este artículo compara la deuda técnica con los derivados financieros y explica con ingenio los problemas que surgen en el desarrollo de software.
• La deuda técnica es un problema frecuente en el desarrollo de software, y este artículo propone a los desarrolladores una forma creativa de gestionarla.
• Los sistemas de evaluación del ecosistema de Rust, como RUSTSEC, pueden ayudar a los desarrolladores a evaluar la estabilidad de las bibliotecas, aunque también pueden generar estrés innecesario.
• Integrar el código como forma de resolver la deuda técnica puede ser una solución temporal, y a largo plazo hace falta una estrategia de mantenimiento sostenible.
• En situaciones como esta, conviene considerar distintas soluciones, como el mantenimiento impulsado por la comunidad, la co-mantenencia de proyectos open source o la búsqueda de versiones alternativas de la biblioteca.

[GN⁺]

Comentarios de Hacker News

• El autor del parser de YAML más popular abandonó repentinamente el proyecto y lo marcó como obsoleto (deprecated) y sin mantenimiento (unmaintained). Esto se hizo sin advertencia ni designar a otro mantenedor; el paquete sigue siendo funcional, pero como lo usan más de 4000 crates, las herramientas de auditoría y actualización automática advertirán sobre el uso de crates sin mantenimiento.
• Para quienes se confundieron con la sigla CDO, se supone que significa "collateralized debt obligation", ya que la palabra "collateralized" se usó varias veces.
• Si la ruta vulnerable del código no puede ejecutarse ni ser accesible desde una librería externa, entonces se convierte en una ruta de código segura. Hacer vendoring de una librería proporciona herramientas para atacar el código y, si tienes suficiente cobertura de pruebas para tu propia librería, puedes ejecutar herramientas de cobertura de código sobre la librería incorporada. Modificar la librería incorporada puede ser un reto, pero eliminar las partes que no necesitas puede ser relativamente fácil. Claro, depende de la estructura de la librería incorporada.
• Un exanalista cuantitativo y actual economista elogió que el autor usara correctamente el término "Collateralized Debt Obligation". Quiere escribir un artículo sobre la "deuda técnica", pero cree que la metáfora de la "deuda" no encaja con el concepto. Una expresión como "código de alta viscosidad" podría ser mejor. Se siente como si tuviera una alta inductancia, porque no se puede cambiar el código fácilmente para adaptarlo a nuevas funciones.
• Sobre que la "junk tech debt" de repente reciba una calificación "AAA", el autor parece querer decir que el mismo código no puede tener una mejor calificación de deuda antes y después de hacerle vendoring. Pero eso solo mira el valor del código en sí y pasa por alto la parte más importante de la propuesta de valor total. El mantenedor que incorpora el código ahora es dueño de él, y un mantenedor activo que incorpora código de un proyecto muerto aumenta su valor porque hay una persona que puede responder a issues, revisar pull requests y corregir bugs.
• También se ha visto el mismo patrón en el ecosistema JS de npm. npm audit suele exagerar principalmente con los problemas de seguridad y, mientras la licencia lo permita, es una de las maneras más confiables de librarse de los problemas absurdos que llegan de los usuarios.
• Fue una suerte haber hecho un fork de yaml-rust y reescribirlo en Rust puro para crear yaml-rust2. Ese fork pasa completamente la suite de pruebas de YAML y también muestra mejor rendimiento en los benchmarks. La migración también parece sencilla. Al final, el problema sigue ahí: todavía dependemos de otras personas que hoy aportan trabajo gratis, pero no hay garantía de que lo hagan para siempre.
• Si un gestor de paquetes basado en código fuente no impone el derecho legal de que el registro asuma por la fuerza el mantenimiento de los paquetes publicados, enfrentará problemas aterradores: abandono, cambios maliciosos, eliminaciones maliciosas, suplantación, etc. Para los paquetes que se consideren lo bastante importantes para la comunidad, debe existir una forma de quitar la entrada del registro de las manos del propietario original y convertirla en un fork.
• Si el código funciona y lo ha hecho durante años, ¿qué importa que no tenga mantenimiento? Si no hace falta corregirlo y conoces sus límites y capacidades, no hay problema. El código no se vuelve peor por sí solo. Hace décadas no había ningún problema en reutilizar o integrar código de muchos años.
• Hacer vendoring de las dependencias es la solución. Lo he hecho durante 20 años con casi todas las dependencias que ya están "terminadas" y cuyo desarrollo y mantenimiento se han vuelto lentos.