"My thought process was simply that there is a big need here and Redis had for some reason decided not to serve it. If they won’t then we will."
I feel like this and the general tone of the article are needlessly antagonistic toward Redis. KeyDB is building their entire business off of it after all.
There may very well be a need for multi-threaded Redis, but Redis as it stands today is an amazing project and there's something to keeping it simple along the lines of the project philosophy.
I’ve learned to appreciate Salvatore’s stance on simplicity the longer we’ve gone on with KeyDB. But when I first made KeyDB two years ago I was really perplexed at the decisions he made with respect to threading.
It’s not my intention to be antagonistic. I’ve had a lot of projects over the years that went nowhere and a part of me is sad that the one with the most traction is a fork.
I am aware. Community management is different from what is legally possible. Were a project owner start to act in a self-interested or malicious manner, then I think proudly and aggressively forking a project is a great idea. That's not Redis. Like I said, it may be a good idea to have a multi-threaded Redis, but Redis users tend to love Redis. I would probably lean into that goodwill instead of against it.
I don't see forking as being aggressive. It's the natural thing to do if you want to take the project in a different direction to its stewards. Often lessons are learned from that process and the learnings integrated back into the main project.
I feel like this and the general tone of the article are needlessly antagonistic toward Redis. KeyDB is building their entire business off of it after all.
There may very well be a need for multi-threaded Redis, but Redis as it stands today is an amazing project and there's something to keeping it simple along the lines of the project philosophy.