RealTime IT News

Brian Stevens, CTO, Red Hat - Page 2

Brian StevensQ: What's your strategy on integrating traditionally non-standard OS items, such as Real Time, into Red Hat's products? Why not have standalone versions specifically for different verticals?

We believe that it's critical to deliver a unified platform, and that's what Enterprise Linux was all about.

When we did a survey, we found that Morgan Stanley was using 18 different versions of Red Hat Linux, all modified because the out-of-the-box didn't give them what they needed.

Enterprise Linux is really a process of how do we actually standardize single versions of Linux that can be used pervasively?

So the approach we had with SELinux was not to build a Trusted Solaris knockoff. Our approach was let's develop the technology and then as the technology matures lets integrate it into the unified platform instead of a separate stove-pipe offering.

Same thing is happening with telco. There were a lot of things we could have done to approach the Nokias and Alcatels earlier, but it would have caused us to go down a path of forking, in a very dramatic way, what is unified in Linux capability today.

We chose to wait and invest in the technology. As we can actually get the technology matured and integrate the telco requirements into a standard platform, then we approach the market.

In Enterprise Linux 4 the capabilities for telco have arrived.

Real Time is very much around predictability and has very good response time. I'd argue that you could talk to just about any customer in any vertical and they'd care about faster response time and predictability.

I don't think that Real Time any longer is a class of an OS. In the old days you were either Real Time or you were not.

Q: In terms of adoption of Red Hat, what are the obstacles you still face in getting further penetration into the enterprise?

We've always been adamant believer that open source is a participatory process that allows communities of use, collaboration. And the end result is better software.

We've always been adamant that would apply to other areas beyond the Linux kernel. I think that JBoss is a testament that the process works for what was traditionally left to higher-value, non-commoditized components.

What we're looking at is how do we actually create that collaborative process in other areas and allow communities of use to form.

It's no longer about the challenge of Linux. I don't see the obstacle with Linux other than just continued execution on our part.

Q: What are your biggest technology challenges as CTO?

It's less around JBoss right now; it's really around the fact that Red Hat is investing in much more than just its enterprise roadmap.

Everything from OLPC [one laptop per child] to software-as-a-service-based architectures.

Looking out and saying how do we continue to provide more value to customers and I think in many cases that may mean disrupting ourselves even.

What's the path for delivering enterprise software? We've certainly proved that there is value there but it's my opinion that there are still ways that we can improve that greatly.

I think there are opportunities to talk about the role of services and service-managed software inside of an enterprise at a level they've never seen before, perhaps even moving away from how we deliver subscriptions today.

It's beyond technology. It's all the way through changing relationships with partners. Time between releases -- it's still a very archaic 18-month grind.

I think that there are other ways that we can actually develop software more collaboratively at a faster stride that doesn't compromise on quality and acceptance.

Q: What's the big challenge that is left for Red Hat and Linux in general to solve?

There is innovation happening all over the world. Our role should be a catalyst for all of that to happen. The way everybody is doing this is still very much a vendor-led direction.

We need to look instead at how do we broaden the infrastructure and the process to allow collaboration and solutions to happen on a path that we haven't even foreseen.