This model works very well for us, but I appreciate that it can be hard to replicate.
In fact Red Hat deploys specific obsfucation techniques to make it harder for competitors to redistribute RHEL, while technically respecting the OSI definition of “open-source” [1]. I understand the business motivation for playing these sorts of games... but it kind of deflates the notion that Red Hat’s model is anything special or worth emulating.
Assuming Redis Labs will accept pull requests and generally follow the process of collaboration casually known as “open source” for their proprietary modules, even if it doesn’t meet the OSI’s technical definition of open source... Then as far as I’m concerned the Redis Labs model is more open, in practice, than RHEL’s.
I'm very familiar[1] with the "obfuscation" you linked to, and I think you are missing context. Red Hat used to ship their Linux kernel source RPMs as vanilla Linux kernels plus a series of patches. They switched to releasing the source RPMs as a fully patched kernel tree. They did this because Oracle started providing commercial support for RHEL (not just Oracle Linux), which is how Red Hat makes money. This had no impact on open source redistributions of RHEL, like CentOS, because they just compile the kernel source without modifying it. AFAIK the kernel is the only package they do that with.
[1] There was a kernel bug between RHEL 6 RC and GA, the RCs had individual patches, the GA kernel source RPM was pre-patched. Lack of patches made it harder to track down, but it was still possible by applying the patches to the RC kernel, then diffing the patched RC source against the GA source.
IMO distributing only the pre-patched source of the kernel is the same kind of violation. The preferred form for making modifications is the original source plus separate patches, that's what the people who are working on that code use.
So maybe their lawyers disagree with us? Or maybe they're institutionally allergic to being a GPL enforcement plaintiff, even in their own strategic interest.
Patches are useful, of course. They are useful to understand the evolution of the software, to support it, etc. But they are not necessary in order to make modifications to the software. Ten-fifteen years ago it was actually the norm that open source software had private source control repositories and only made periodic releases as tarballs.
If you have the Perl script that generates C code, you get a benefit from being able to modify the Perl script rather than the C code. So the Perl script is the preferred form for making modifications.
If you have the history, you don't get any benefit from modifying the history. In this sense, having the history is not relevant to making modifications, only to studying the code (for example to make the same modifications on another branch/fork of the code, like I do with upstream patches, or like Oracle could do if they had the Red Hat patches).
Your could say that this phrasing is shortsighted, but note that neither Red Hat not Debian or anyone else has ever given the complete history to Linux or any other piece of software they distribute, but they had to give the complete base source tarball as distributed by the upstream project.
Studying the code is the first step in making modifications. I would always want to have a working "git blame" before trying to modify a codebase, so that I could understand lines in the context of the changes they were part of before I modified those lines. I consider it considerably harder to modify a codebase when I don't have proper version control history available.