I can totally sympathize with your feelings, but I believe that it depends a lot on how the Redis project will set the tone about this feature. Example of thing

I can totally sympathize with your feelings, but I believe that it depends a lot on how the Redis project will set the tone about this feature. Example of things that will make, in my opinion, the difference: 1. There will never be a way to install modules automatically provided by the Redis OSS project. The use case is to grab a few modules you may need for vertical use cases that are otherwise not cover, so you just don't install a number of modules depending on other modules and so forth. 2. I'll not write modules but will care about exporting a good modules interface. What I believe has to be done, will be implemented inside the Redis core, not outside. SO it's totally a community thing. For the project itself is like: "we are going to give you this possibility, so that the fact the core is conservative about what functions to add, does not block you". But the model for Redis does not change, Redis is what we provide in the core. I work only on core stuff. The site only documents what we have in the core. 3. I'm not going to debug for hours or days crashes happening with modules loaded. On crash the list of modules installed will be reported in the crash trace. So modules are going to be a good addition and there will be use cases that can be solved very well with modules, but are not going to change what Redis is. It's up to the user if to use Redis "core", or if to leverage modules. Wise users will pick modules when needed, and will inspect modules for quality and fit. Unwise users will install a lot of garbage, then eventually say Redis is a shit. But this is how the world works :-)