@ngn Thanks for elaborating on this topic.
Im still not sure about #fedora being testing ground for #rhel, they surely have really formal way of introducing and documenting changes with their change proposals https://docs.fedoraproject.org/en-US/program_management/changes_guide/ which to my knowledge from one of episodes of #techovertea by @BrodieOnLinux are later reviewed by #rhel and merged/notmerged into it. Some people asked about #fedora and #rhel relationship in the past https://discussion.fedoraproject.org/t/request-for-a-detailed-breakdown-of-the-relationship-between-fedora-and-red-hat/86775
For the source code availability, even with #gpl #license you are only required to share the source code to the recipients of the application/whatever you are distributing/selling, just because most #gitforge services allow everyone to view the projects stored on their servers, it doesn't mean it has to be like that - though, for open development process, maybe it should be? But that doesn't change that if #redhat called their #downstream #distro "freeloaders", its really rude.
They are doing it for profit, I guess. Not caring about their potential customers will get them eventually. But besides that, everyone has to earn money somehow, and having #foss product doesn't make it easy.
> best you can do is to put new tech and software into your repos, and encourage users to test and use it, which is what most rolling distros do
I disagree, although its good to have unstable features as opt-in, it introduces bias where the new features are only used by people that know about them, and know how to enable/switch to them. This way, you are severely reducing amount of useful bug reports that are crucial to know what are your users even doing.
Ideally you would perform AB tests, with ever increasing number of real users, and in case of issues you would simply #rollback the update to the latest stable version. Sadly, it would require that rollback feature, and prefill all system information in the bug report.