It's not an error at all, Simon! Because different setups in the past lead exactly to the scenario that you depicted. Examples: projects that requested signed copyright transfer for each patch (even GNU projects required this). But also what is more insidious is that very complex projects, while sometimes BSD or similarly licensed, were made completely proprietary (and not under the MongoDB / Redis circumstances, but just to turn proprietary for other reasons) but they were so complex internally that basically you can't do anything with the code, without paying like... 50 engineers to study it for six months. So it is an actual danger, but not in the case of BSD + projects that have an acceptable barrier to entry to be understood, fixed, modified, ...

Note though, the code is not Music, it rots quickly without maintenance. The "social contract" of contributing the code is what it will be maintained by collective community, otherwise many companies would just keep it as private forks.

It is wonderful thing though, with Open Source, people can band together and "pull Valkey" to create well maintained fork based on all those past contributions

That may be true of node.js codebases, but last time I checked Redis was written in C and only depends on ISO and POSIX standardized stuff. I doubt there's been any leftpads that have broken the old versions by now.

It is not just compatibility, there are bugs, but most important security issues which are constantly being discovered.

Which makes rot a good metaphor actually. The DNA of a tree which becomes infected with a new mutation of a fungus didn't change, the fungus did.

Code in which a vulnerability is discovered is in the same position. It's developed a susceptibility to a new force malevolent to its purpose. It doesn't have to change to rot, it suffices for the world to change around it.