Redict 7.3.0 is now available
Drew DeVault

April 3, 2024

The Redict community is pleased to announce the release of Redict 7.3.0, the first stable version of our copyleft fork of Redis® OSS 7.2.4.¹ You can download the release on Codeberg, or download one of our official container images from registry.redict.io.

We have written comprehensive documentation detailing our compatibility with Redis® OSS 7.2.4, which also provides detailed documentation for various migration scenarios, such as for users of the official Redis® containers on Docker Hub, downstream package maintainers, and so on.

We have tested Redict thoroughly with a variety of migration scenarios, but we may have missed a detail that pertains to your use-case. If you have any issues or questions with respect to the migration process, please join our community spaces to get help.

Why Redict? #

You may be wondering why Redict would be of interest to you, particularly when compared with Valkey, another Redis® fork that was announced on Thursday.

In technical terms, we are focusing on stability and long-term maintenance, and on achieving excellence within our current scope. We believe that Redict is near feature-complete and that it is more valuable to our users if we take a conservative stance to innovation and focus on long-term reliability instead. This is in part a choice we’ve made to distinguish ourselves from Valkey, whose commercial interests are able to invest more resources into developing more radical innovations, but also an acknowledgement of a cultural difference between our projects, in that the folks behind Redict place greater emphasis on software with a finite scope and ambitions towards long-term stability rather than focusing on long-term growth in scope and complexity.

We will happily pull useful changes from software with permissive licenses, such as Valkey, to improve Redict; such is the value of permissive software and the key advantage of free software generally. However, we will do so at a more conservative pace, so that our users can enjoy stability first and shiny new features second. We are also going to focus on establishing and maintaining a good relationship with downstream distributions, prioritizing their needs with respect to tasks such as de-vendoring Lua and jemalloc.

Redict also has social and political aims which differ from other forks. In short, we believe in an approach which is built from an independent, grassroots, and community-focused means of building our software. We are not governed by the consensus of a small group of commercial interests, but rather by an independent and community-driven consensus. Importantly, we have also chosen to protect our software from further exploitation by applying the Lesser GNU General Public License (LGPL) to our work.

Our choice of license prevents the hard work of our contributors from being incorporated into the now-proprietary Redis® software, and from any future attempts to create proprietary distributions of Redict. However, our choice of the LGPL balances this concern with the needs of commercial users – we have selected this license in part to ensure that cloud providers can continue to offer Redict to their customers without being subject to onerous compliance regimes.

Note: Check out our About the license page for more information about the license of Redict.

We’ve made these choices because we believe they are essential in providing for a future which is based on free software, and in which the rug cannot be pulled out from under our users and contributors again. We believe it is essential to make these choices now, at the onset of our fork, especially in response to the crisis that the Redis® community is faced with at the hands of its commercial stewards. If you don’t want your investment in this software to risk another artificial crisis in the name of profit, if you want to enjoy the protection of copyleft and a guarantee that your software will remain free, then we encourage you to adopt Redict for your needs.

We have also taken this opportunity to re-evaluate our infrastructure and double down on using free software. Rather than continuing to use the proprietary GitHub forge, we have elected to use the non-profit, free software Codeberg as our home, and we run our continuous integration on SourceHut, which is also free software. Moreover, rather than gathering on Discord, we have chosen instead to set up our community on Matrix and IRC. We believe that the Redis® license change provides us an opportunity to focus on our values as members of the free software community, to exercise solidarity, and to lend our strength to re-enforce the broader free software ecosystem. As such, we felt it important to choose free software solutions for our infrastructure needs.

Acknowledgements #

I’d like to extend a personal “thanks” to everyone who was involved in bringing this fork to life. In particular, Micke Nordin and Hugo, for their work on the Redict containers; Lucas Dohmen, for his extensive work on the documentation and website; and Anna, for her work forking and maintaining hiredict; as well as everyone who contributed small patches here and there, and everyone who helped with the rapid turn-around and testing of Redict’s release candidates. Shoutout to @janWilejan for designing our logo, and to everyone else who submitted their artwork for consideration.

Thanks are also due, of course, to all of the many contributors who worked on Redis® OSS, commercial contributors and independent contributors alike, whose work forms the foundation of our codebase, as well as all of those who worked on the extensive Creative Commons documentation that was adapted for Redict. We also extend our gratitude to the community downstream of Redis® OSS, including downstream distributions, cloud services, and countless users, all of whom nourished its growth as free software.

What’s next? #

We focused on a very conservative set of changes for the initial release, to maximize backwards compatibility and ease the transition for new users. Going forward, we do have some plans to make conservative improvements.

Among the planned changes are:

• Modernizing the build system (muon is the leading candidate)
• Forking the ecosystem, in particular Redis® client libraries (this is a great way for you to help!)
• De-vendoring dependencies such as Lua and jemalloc

Lucas is also planning to invest heavily in Redict’s documentation, such that we become the reference of choice for all participants in this ecosystem. Anna has some changes planned for hiredict as well (our fork of the official Redis® C client library), including build system improvements and better conformance with Unix norms.

We will also be happy to consider improvements from any community member – come join us! We will welcome you as equals – independent and commercial users alike!