Red Hat potentially opened a new front in the long-running “cloud wars” this week, and one that could have massive implications for customers down the road. Rumor has it that Red Hat is about to start ‘strong-arming’ companies into using its own, personal flavor of OpenStack. Red Hat has since tried to deny these allegations, though its comments were somewhat ambiguous and have left many scratching their heads.

The Wall Street Journal’s claims were based on internal documents from Red Hat, which stated it’s “chosen not to provide support for its commercial Linux to customers if they use rival versions of OpenStack”. The WSJ goes further, quoting an HP executive as saying that Red Hat’s “taken the art form of closed open-source to a new level”.

Red Hat’s Paul Cormier later responded to those allegations in a blog post. He insisted that, “Users are free to deploy Red Hat Enterprise Linux with any OpenStack offering, and there is no requirement to use our OpenStack technologies to get a Red Hat Enterprise Linux subscription.”

However, Cormier did note that uncertified versions of OpenStack might be problematic:

“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.”

If this seems like a contradiction, well, that’s because its contradictory. Cormier is saying Red Hat will still support RHEL users no matter what version of OpenStack they use (in contrast to the WSJ’s allegations). However, what Red Hat won’t support is OpenStack distros made by its competitors.

How much support should we expect anyway?

It could be argued that it’s quite unreasonable for customers to expect Red Hat to support non-Red Hat OpenStack software in any case. Red Hat certainly doesn’t have any obligation to do so – after all, does anyone expect it to support third-party software from other vendors? Of course not.

From time to time vendors may provide support for third-party products used by their customers, depending on how important that customer is to them. Red Hat’s support page says it will try to resolve issues where third-party software is causing problems, but customers are often required to replicate the issue themselves. If not, Red Hat says it will make “reasonable support efforts”, before referring customers to the third-party responsible. These are common enough restrictions – Oracle does much the same thing, though of course it will sometimes bend the rules for its most important customers.

Speaking to SiliconANGLE founder John Furrier on theCUBE at OpenStack Summit 2014 yesterday, Red Hat’s Joe Fitzgerald, General Manager for Cloud Management, attempted to clarify the company’s position on what support its customers can expect.

“Red Hat’s very responsible in what we do in terms of support,” stated Fitzgerald. “There’s two issues here, and one is our openness in terms of interoperability. We support RHEL running on VMware and Microsoft for example. With platforms, we support Microsoft, OpenStack, Amazon, VMware, all kinds of different cloud providers and technologies.”

However, Fitzgerald was keen to point out that Red Hat also doesn’t take certification casually, likening the business to a start up insurance company. “It’s all fine until the claims come in, and then you have to deliver on that support,” he notes. “We’re not going to casually take on support for different combinations of things. It would be irresponsible, unless we have a technical relationship and we’re sure that things are going to work.”

***Watch Fitzgerald’s interview here***

Fitzgerald’s comments suggest that Red Hat’s support strategy leaves them with a lot of room for maneuver – if Red Hat doesn’t think it can, or thinks it’s counter-productive to support certain issues where third-party vendor’s products are involved, it doesn’t have to do so. It’s a complex situation in other words, and that means confusion and anguish will surely arise at some point down the line.

Locked in the cloud?

What’s really at stake here is a return to the days of vendor lock-in during the client server era, something that enterprises thought they’d seen the last of when OpenStack first emerged. If Red Hat tightly integrates its offerings – be it the operating system, cloud framework or whatever – that’s great for Red Hat, but it’s somewhat ominous for customers who appreciate a little more flexibility. But then again, that’s the trade off companies will have to make – by choosing Red Hat’s distro they get open-source software with all the benefits of proprietary software, including support.

Alternatively companies can download OpenStack themselves entirely free, but they’ll need to put in an awful lot of effort to actually build themselves a cloud that works. Red Hat does the hard work for you, but in return it wants some kind of commitment.

Problems will arise as OpenStack continues to mature, and some enterprises may find different distributions are more appealing than others. For example, a customer running RHEL may decide that HP or Canonical’s flavor of OpenStack works best for them, but if Red Hat refuses to support that combination, it could cause them to have a rethink.

Gartner’s Lydia Leong warned enterprises about the dangers of adopting OpenStack last year, saying “OpenStack is dominated by commercial interests, as it is a business strategy for the vendors involved, not the effort of a community of altruistic individual contributors”. What she meant is that customers shouldn’t just assume that OpenStack equates to an escape from vendor lock-in.

Even so, it’s still a more flexible option than running your business on client-server hardware. OpenStack provides something of an escape route from vendor lock-in, but with Red Hat and others moving towards tighter integration with the rest of their products, don’t be surprised if that door is one day slammed shut.

photo credits: Funky64 (www.lucarossato.com) via photopin cc; kevin dooley via photopin cc