More fallout of Red Hat's discontinuation of easily accessible RHEL source code. Previously Jeff Geerling made a blog post which can be best described by its title, "Dear Red Hat, are you dumb?",...
Exemplary
More fallout of Red Hat's discontinuation of easily accessible RHEL source code. Previously Jeff Geerling made a blog post which can be best described by its title, "Dear Red Hat, are you dumb?", followed by dropping his Ansible roles for RHEL, and his decision is now definitely set on stone as he describes why he cannot trust Red Hat to listen to the community and how the requirements to attempt to support RHEL is too significant to make its worth while for him when alternatives have no barrier of entry at all.
Jeff Geerling is known for his involvement in Ansible, Linux, Raspberry Pi, and Drupal communities.. His thoughts are also available in video.
Unfortunately, even if this move ends up being good for the Enterprise Linux ecosystem (or at least, salvageable) in the long run, this is proof that Red Hat is burning a lot of acquired goodwill over the years for no apparent reason. It's a classic example of mishandling as even core Red Hat employees involved with the community were caught off-guard by this change, leaving communication confusing and attempts to talk the controversy down as cheap talk. I used to consider myself a big fan of Red Hat's work, but now I am not so sure if letting them lead the Linux ecosystem alone will be good for its long-term health.
I think the move is moderately damaging to the Red Hat stack brand. They are pushing really hard for IT infrastructure to adopt their suite of products. Namely, Podman, Ansible/Ansible Galaxy,...
I think the move is moderately damaging to the Red Hat stack brand. They are pushing really hard for IT infrastructure to adopt their suite of products. Namely, Podman, Ansible/Ansible Galaxy, RHEL, etc. However, a lot of their products benefit from what the community puts into them. Why use RHEL if Ansible role authors cannot test against it?
Sounds like Red Hat should step up and qualify if Ansible et al works on RHEL. Perhaps this is an opportunity for upstream projects to shed support/test work for RHEL. After all, they want more...
Sounds like Red Hat should step up and qualify if Ansible et al works on RHEL.
Perhaps this is an opportunity for upstream projects to shed support/test work for RHEL.
More fallout of Red Hat's discontinuation of easily accessible RHEL source code. Previously Jeff Geerling made a blog post which can be best described by its title, "Dear Red Hat, are you dumb?", followed by dropping his Ansible roles for RHEL, and his decision is now definitely set on stone as he describes why he cannot trust Red Hat to listen to the community and how the requirements to attempt to support RHEL is too significant to make its worth while for him when alternatives have no barrier of entry at all.
Jeff Geerling is known for his involvement in Ansible, Linux, Raspberry Pi, and Drupal communities.. His thoughts are also available in video.
Unfortunately, even if this move ends up being good for the Enterprise Linux ecosystem (or at least, salvageable) in the long run, this is proof that Red Hat is burning a lot of acquired goodwill over the years for no apparent reason. It's a classic example of mishandling as even core Red Hat employees involved with the community were caught off-guard by this change, leaving communication confusing and attempts to talk the controversy down as cheap talk. I used to consider myself a big fan of Red Hat's work, but now I am not so sure if letting them lead the Linux ecosystem alone will be good for its long-term health.
I think the move is moderately damaging to the Red Hat stack brand. They are pushing really hard for IT infrastructure to adopt their suite of products. Namely, Podman, Ansible/Ansible Galaxy, RHEL, etc. However, a lot of their products benefit from what the community puts into them. Why use RHEL if Ansible role authors cannot test against it?
Sounds like Red Hat should step up and qualify if Ansible et al works on RHEL.
Perhaps this is an opportunity for upstream projects to shed support/test work for RHEL.
After all, they want more control.