Why Snap Was Willing to Fork, and Why They Still Came Back

Snap's experience with forking KeyDB from Redis illustrates both the potential benefits and the eventual drawbacks of diverging from an established software project. Initially, Snap forked KeyDB to address Redis's limitations in handling multithreaded operations, allowing them to optimize their caching infrastructure. This decision stemmed from a need to push the capabilities of a single node further than Redis's architecture allowed. While the fork provided immediate advantages such as multithreaded command execution and zone-aware read routing, Snap eventually faced challenges in maintaining compatibility and keeping up with Redis's updates. The subsequent change in Redis's licensing and the emergence of Valkey, a new project with open governance, prompted Snap to reconsider its strategy. Valkey offered features Snap had previously developed independently, along with a collaborative development environment under the Linux Foundation. This shift, combined with internal changes and the departure of KeyDB's original creator, led Snap to migrate back to Valkey, emphasizing the importance of assessing the long-term costs and benefits of maintaining a software fork.