Udostępnij za pośrednictwem


Open Source is Caring and Sharing – Sometimes.

James Governor’s (@monkchips) observations (Red Hat’s entirely rational position on OpenStack) on recent moves by Red Hat to put additional processes in place to restrict the support they offer is very interesting. It’s an almost fly-on-the-wall observation of what is happening at Red Hat, what is happening with OpenStack and what is happening in Open Source generally.

I have to say, having worked for Microsoft for just over 20 years that I have some sympathy with Red Hat’s position, which is this: they will only support your Red Hat Linux running on OpenStack if it’s running on Red Hat’s very own implementation of Open Stack. On the surface it sounds like the kind of lock-in that enterprise vendors were (and are) accused of years back when systems didn’t inter-operate quite as well as they do now. But to test 8+ configurations of Open Stack with Red Hat?

Red Hat’s Paul Cormier, President of Product and Technology said, of the move:

Enterprise -class open source requires quality assurance. It requires standards. It requires security. OpenStack is no different. To cavalierly ‘compile and ship’ untested OpenStack offerings would be reckless. It would not deliver open source products that are ready for mission critical operations and we would never put our customers in that position or at risk”.

I understand Red Hat’s situation – because the testing matrix of compatible hardware/software just gets bigger and bigger over time and that just got multiplied by 8 or more OpenStack implementations. The move though does push Red Hat up against the central tennet of Open Source – that it’s Open. But that can’t be the case when as Mirantis points out:

“Let’s face it, with 64% share in the enterprise Linux market, Red Hat is in a position to dramatically stifle healthy competition in open source ecosystems tied to Linux. OpenStack is one of the most prominent examples of such an ecosystem. When you come to dominate a particular market, you automatically inherit certain obligations, whether you like it not”.

I can’t see anything wrong with a position that says they can exit a world where the testing regime is so expansive they can’t make any money. Let’s not forget, Red Hat is a business, not a charity. They can just simply make a statement that they’ll only support this or that configuration and if you don’t like it – well, go to another Open Source vendor – the beauty of Open Source. So I like James Governor’s appraisal – what they are doing is entirely rational. He also points out that Open Source isn’t always “caring and sharing”:

“Open source is caring and sharing? Sometimes – but it can also be nasty, brutish and short. Red Hat wasn’t founded on altruism- it was founded on pragmatism, doing the best job of packaging Linux for the enterprise, making it certifiable and above all trusted as a deployment platform for enterprise apps.
Read more:
https://redmonk.com/jgovernor/2014/06/10/red-hats-entirely-rational-position-on-openstack/#ixzz34KCatv6t”.

I guess my issue is that the further they move themselves away from the Open Source movement with entirely rational product restrictions, the less of an Open Source vendor they are. Like Microsoft – which is a company that supports Open Source Software but certainly doesn’t claim to be an Open Source Company.

Planky -- @plankytronixx – GBR-257

Comments

  • Anonymous
    June 10, 2014
    The comment has been removed
  • Anonymous
    June 17, 2014
    You can run RHEL on any hypervisor managed by any OpenStack, well any management platform for that matter. There is NOTHING in Red Hat's policies, license agreements, etc to prevent this. Red Hat has a certification program for hypervisor vendors, but even if a customer deploys RHEL on an un-certified  hypervisor and encounters an issue and calls Red Hat they still are supported Quoting from the kbase article "Red Hat will provide commercially reasonable support efforts and refer you to the third-party software or hardware/hypervisor vendor if required" access.redhat.com/.../1067 I fail to see what the problem is here? I admit there's much fun to have in mis-stating the policies and trying to spin this, but look at the facts - look at the long published policies on Red Hat's site and then make comments.