Redict 7.3.0 ya fue liberado

Logo de Redict

Poco después de que Redis anunciara un cambio en las licencias de sus productos, comenzó a darse el movimiento por crear una alternativa a este, debido a que las nuevas licencias implementadas son incompatibles con otros productos de código abierto, por ejemplo Fedora y de ese movimiento conocimos el nacimiento de Valkey el cual es un proyecto de la fundación Linux, asi como también de Redict una bifurcación de Redis creada por Drew DeVault, conocido por sus proyectos como el entorno de usuario Sway, el lenguaje de programación Hare, el cliente de correo electrónico Aerc y la plataforma de desarrollo colaborativo SourceHut.

Sobre esta última, Drew DeVault anuncio hace poco el lanzamiento de Redict 7.3.0, siendo esta la primera versión independiente de este proyecto y trae consigo cambios mínimos, como la modificación de nombres de utilidades y archivos de configuración, manteniendo así la compatibilidad con Redis 7.2.4. Aunque Redict es compatible con esta versión, no guarda relación ni es compatible con la rama de desarrollo de Redis 7.3.0.

Además, el equipo de Redict tiene planes de invertir en la documentación de Redict, con el objetivo de convertirse en la referencia principal para todos los participantes en el ecosistema. También están trabajando en mejoras para Hiredict (la bifurcación de la biblioteca cliente oficial de Redis C), incluyendo mejoras en el sistema de compilación y un mayor cumplimiento de los estándares Unix.

A diferencia de otras bifurcaciones como Valkey, creada por grandes empresas, Redict tiene como objetivo principal mantener la estabilidad y conservatismo en el código en lugar de impulsar cambios radicales e innovaciones. Los desarrolladores de Redict consideran que Redis, en su estado actual, es un proyecto maduro y completo, enfocándose en asegurar la corrección de errores y vulnerabilidades en lugar de añadir más funcionalidades. Este enfoque valora la estabilidad para los usuarios antes que las nuevas funciones, priorizando la relación con las distribuciones y tareas como la desventaja de Lua y jemalloc.

Hemos tomado estas decisiones porque creemos que son esenciales para garantizar un futuro basado en el software libre, y en el que nuestros usuarios y contribuyentes ya no puedan quitarles la alfombra de debajo de los pies. Creemos que es fundamental tomar estas decisiones ahora, al comienzo de nuestra bifurcación, especialmente en respuesta a la crisis que enfrenta la comunidad Redis® por parte de sus gerentes comerciales. Si no desea que su inversión en este software corra el riesgo de otra crisis artificial en nombre de las ganancias, si desea beneficiarse de la protección copyleft y una garantía de que su software seguirá siendo gratuito, le recomendamos que adopte Redict para sus necesidades.

Redict busca una construcción independiente y comunitaria de su software, sin estar influenciado por intereses empresariales limitados. La elección de la licencia LGPL en lugar de BSD para los cambios en Redict se basa en proteger contra posibles intentos de crear distribuciones propietarias de Redict y evitar el bloqueo de la transferencia de código al proyecto ahora propietario, Redis. Al mismo tiempo, la licencia LGPL permite que los desarrolladores de productos comerciales y sistemas en la nube utilicen Redict en sus servicios y proyectos. Redict se desarrollará exclusivamente por la comunidad y en beneficio de la misma, en contraposición a ser impulsado por un grupo reducido de empresas con intereses específicos. Las decisiones de desarrollo se tomarán mediante consenso entre los participantes del proyecto.

Los planes futuros incluyen la modernización del sistema de compilación, la creación de bifurcaciones de bibliotecas cliente (como Hiredict, una bifurcación de una biblioteca con una implementación de cliente para Redis en lenguaje C) y la eliminación de opciones integradas para Lua y jemalloc en favor de conectar dependencias externas. Esto simplificará el mantenimiento de paquetes en las distribuciones. Además, se considera la posibilidad de transferir cambios útiles y no radicales desde la base del código de Valkey.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.