Red Hat Looks Beyond Linux For Its Next Decade Of Growth

[ReadWrite]

Ten years ago, Red Hat went "all in" on the enterprise. While the open-source software vendor had been selling distributions and support for Linux since 1993, it wasn't until 2003 that Red Hat completely dedicated its brand to the enterprise. While the move made Red Hat some enemies, it has also proved profitable, allowing the company to commit fully to open source without also committing itself to poverty.

In his opening Red Hat Summit keynote, Red Hat Executive VP Paul Cormier suggested that "Today's problems can't be solved by one company," requiring open-source communities to tackle thorny infrastructure problems. In a ReadWrite interview this week at the event, however, Cormier made it clear that Red Hat definitely doesn't see itself as a passive bystander to this open development.

ReadWrite: Red Hat's first 10+ years were largely spent making Linux a default enterprise standard; something safe for enterprise consumption. What will Red Hat spend the next 10 years doing?

Cormier: You'll remember that roughly 10 years ago we stopped shipping consumer-oriented Red Hat Linux, introducing Red Hat Enterprise Linux (RHEL, previously Red Hat Advanced Server). The reason? We found that our split personality on Linux - shipping Linux distributions for both enterprise and personal use - didn't "make Linux safe for the enterprise," to use your terminology. The first five years of our history saw Bob Young selling Red Hat CDs out of the trunk of his car at flea markets. Those first few years weren't really about making Linux part of the enterprise.

Our next 10 years will be spent building out other essential infrastructure for the enterprise, while continuing to improve RHEL. A significant part of this involves our hybrid cloud initiative. We've been talking about cloud for a long time, and while Amazon would have us believe that enterprises are moving their workloads to the public cloud tomorrow, it's simply not going to happen. This shift will take a 10 years or longer. I've been in technology for decades: the enterprise moves slowly.

ReadWrite: So what is Red Hat building for this enterprise of the future?

Cormier: The infrastructure we're building has several components. OpenStack is one cog in the wheel, as is Linux. I see OpenShift, another piece, as how you "cloudify" middleware, something we get asked to do all the time as enterprises want us to move more JBoss services to the cloud.

But this won't happen overnight. After all, when we acquired JBoss, enterprises tended to use it in development, not production. Now they use it in serious production deployments. We've invested hundreds of millions of dollars to get it to this stage.

We will continue to invest to ensure that enterprises have the choice of running on a completely open platform, with the option to run the same app across bare metal, public cloud, hybrid cloud, etc. So you need to be able to support workloads across these different targets. That's what we're building.

ReadWrite: Okay, but how does this differ from others' cloud strategies?

Cormier: The problem with the other PaaS providers is that if you build on any of the other PaaS solutions, whether it comes from Google or someone else, you're not getting the application out of their network. Ever. The app is only going to run on their network. Customers don't want this. They want to own the future of their application. Red Hat gives customers this ability by providing a consistent platform across different deployment targets.

ReadWrite: As strong as Red Hat is within enterprise computing, you haven't really made a dent in the developer community. Given the importance of developers to enterprise IT adoption today, how will Red Hat evolve to embrace developers?

Cormier: Over the last 10 or 11 years we've had three pivotal moments as regards developers. The move to RHEL was the first. Next came JBoss, which was initiated by developer demand. Our customers started asking us, "How do I not go to .Net?" We acquired JBoss, building out our entire stack, and spending hundreds of millions of dollars in the process.

We did this for one reason: we wanted a strong community for developers: built for, and by, developers. We didn't acquire it and lock it up. Here at Red Hat, development always goes back to the community. It's in our DNA.

 

The third pivotal moment is OpenShift, starting with OpenShift Online. We did this purely for the developer. Atypically for Red Hat, we didn't even have a business model for it when we introduced it. We just knew we needed it for our developer community. Later, customers started asking us for an enterprise version.

I don't think people appreciate just how much of a fundamental change OpenShift is for Red Hat: it has introduced a new business model for us. This is a big deal for us. It has required that we introduce a new accounting model and a range of other things.

Importantly, OpenShift is helping us reach a new developer audience. If you look at the OpenShift Application Gallery, you'll see developers that we simply weren't reaching through RHEL or JBoss.

Going forward, we want to give the developer a consistent platform whether they want it in the cloud, on a traditional middleware platform, etc.

ReadWrite: How does OpenStack factor into all this?

Cormier: OpenStack is Linux all over again. Look at how Linux started. In the early days there were 15-plus distributions and applications didn't work across them. Even end-users like large banks were building their own Linux distributions. RHEL normalized all this and made Linux consummable by the masses. KVM came along and we melded it into the operating system.

OpenStack is doing the same thing. There are a lot of common needs/elements between OpenStack and the operating system. We're making the cloud consistent by merging the different pieces into one platform. We're going to bring OpenStack into the enterprise just as we did with Linux, by committing to be truly open.

There are two ways to displace proprietary incumbents, either through commoditization or innovation. We're doing both.

ReadWrite

[ReadWrite]