James M. Whitehurst - Chief Executive Officer, President and Director
Brian Stevens - Chief Technology Officer and Vice President of Engineering
Paul J. Cormier - Executive Vice President of Engineering and President of Products & Technologies
Charles E. Peters - Chief Financial Officer and Executive Vice President
Mark R. Murphy - Piper Jaffray Companies, Research Division
Stewart Materne - Evercore Partners Inc., Research Division
Ross MacMillan - Jefferies & Company, Inc., Research Division
Kash G. Rangan - BofA Merrill Lynch, Research Division
Edward Maguire - Credit Agricole Securities (USA) Inc., Research Division
Matthew Hedberg - RBC Capital Markets, LLC, Research Division
Scott Zeller - Needham & Company, LLC, Research Division
Steven M. Ashley - Robert W. Baird & Co. Incorporated, Research Division
Raimo Lenschow - Barclays Capital, Research Division
Abhey Lamba - Mizuho Securities USA Inc., Research Division
Red Hat, Inc. (RHT) 2013 Financial Analyst Meeting June 25, 2013 8:50 AM ET
Good morning, everyone. Please take your seats, and let's queue the video please.
Great. Hello, everyone, here in New York at the NYC, as well as those on our webcast today. Welcome to Red Hat's 2013 Financial Analyst Meeting. I'm Tom McCallum. I'm the Vice President of Investor Relations. We appreciate you committing your time today to support Red Hat.
Before bringing up the first presenter, let me walk through a few housekeeping items. First, the presentation materials for today along with the GAAP to non-GAAP reconciliation is available at redhat.com under the Investor Relations tab in the Events section. There is wireless service here in the room. Three's a card that has a password on it and you can access those materials now.
I'd like to introduce some of the other associates from Red Hat here in addition to the presenters. I'd like to ask each one to stand for just briefly. First, Michael Cunningham, Red Hat's EVP and General Counsel; Mark Cook, our VP of Finance and Controller; Paul Argiry, our VP of Finance and Treasurer. A number of you have met Paul and Mark, who've presented investor conferences as well as on callbacks. We also have from the Investor Relations team, Sarah Wallace, [ph]the Manager of IR. And from the events team in the back here, we have Mary Catherine Cornick, who's going through the logistics for this event. So if you need to reach out to her, feel free.
Next is our Safe Harbor. I highly recommend that you all familiarize yourself with this. It's our Safe Harbor statement and it includes risk factors that are found here, as well as in our annual report on Form 10-K filed with the SEC. In addition, any forward-looking statements made today represent our estimates or views as of today, June 25, 2013, and these views and estimates may change. We specifically disclaim any obligation to update even if our estimates, reviews do change. And therefore, you should not rely on these forward-looking statements beyond today.
Now let me review the agenda real fast. First up, we'll have Jim Whitehurst, our President and CEO, who will present a strategic overview. Jim will be a followed by Brian Stevens, our CTO, who will discuss Red Hat's engineering overview. We'll take about a short 20 minute break. We'll start the next section with a couple of customer videos. One is kind of interesting, so I recommend coming back to hear it. We'll then bring up Paul Cormier, our EVP and President of Products and Technology, who will present a technology overview. Paul will be followed with a financial strategic overview from Charlie Peters, our EVP and CFO. And we'll end this event with a Q&A hosted by Jim, Brian, Charlie and Paul. I'm going to ask you to please hold your question until that section. We'll have mics that will go around the room. And with that, let me bring up Jim Whitehurst. Thank you.
James M. Whitehurst
All right. Thanks, Tom. You have my welcome to everyone here today. Appreciate you all coming down town. I've heard a lot of feedback. Apparently, it's a long way for a lot of you guys to actually come, so I appreciate you coming this far to join us down here. So I think we get the use of the room for free, so we are being good stewards of shareholder dollars by holding it here. Is it okay if I walk? I'm not going to get in the shadow of this. Good. Because I'm not very good at standing still. But you guys hear from me a lot, so I do want to spend a few minutes just giving you kind of a very 50,000-foot strategic overview of Red Hat. Really the whys behind what we're doing. But this really is an opportunity for you to get to grill -- well, hear from and grill Brian and Paul, who are driving really the technology and product direction of the company, so the core of what we do. So I don't want to steal too much time from them. I think it's a great opportunity for you guys to hear in much more detail from them, and you'll get the chance to grill all of us towards the end.
Yes, to kick off, I only have a few slides, so I'll tell you upfront, I'm going to spend a long time on this one, and so don't worry, I promise I'm not going to take too much of your time. For any company in any industry, one of the most important things to understand is how you're competitively advantaged and why that competitive advantage is durable.
So it's my first -- fifth year at Red Hat. So fifth time we've been done these things. And I have to say, for the first couple of years, one of the things that worried me most about Red Hat was whether our model was durable, right? But [indiscernible] objective measure, especially if you look at cash returns, we make a lot of money for what we do, right? So fairly significant profit pool when you look at the cash returns coming out of the business.
So -- well, whenever you have relatively good returns you wonder about, well, who's going to come take it away, and what makes that durable? So let me spend a few minutes on that thing. If you walk away with nothing else, at least, from my part before we get into the details, really what kind of contextualized and define what makes Red Hat Red Hat and how we make money and why I think that's defensible.
So our worry for a couple of years, is this really defensible? With Oracle, Linux is going to be able come in and take significant share from us, how will we relatively going to defend against others and other sectors, et cetera, et cetera, et cetera?
And so let me back up and let me get to the end. It turns out it is defensible. Let me kind of get through that story a little bit. So I would start off saying, for Red Hat, when you say what is our competitively advantaged position and why is that durable? Let me talk to what's our competitively advantaged position.
Unlike a lot of other companies, Red Hat position is really built around a production system not around a product. So you have a couple of other highly successful companies as examples, so not saying anything wrong with these companies. They're great companies. VMware, right? VMware's competitive position is around a strong position in virtualization from which they want to try to do other things. Salesforce.com, right? Built around a product position of SaaS, CRM. And they're using that to try to obviously branch out and do other things.
I would actually argue unlike those companies, our position is more defined by a production system that we're applying to product categories, right? And if I take kind of a nontechnology analogy, I would say an analogy would be Toyota motor, right? Toyota, their source of competitive advantage and what defines the company is a production system around Kaizen present, lean manufacturing, Toyota production system that allow them to build cars with much lower defects rates that have slightly lower cost. Started with small cars, moved into larger cars. They actually now have a JV around airplanes.
But what made Toyota their source of competitive advantage and successful was applying a production system to different categories, which is different. So when I think about Red Hat and when we talk about and you hear about the things we're doing, certainly, we think about our ties back to Linux, which is our core franchise. But we are less defined in terms of a competitive position by Linux than we are by our mastery of the business model around our production system, right? And so when we think about, strategically, what are we doing, certainly we think about how do we leverage our existing customer relationships or our other points. But the core that drives us is where can this production system be applied, right, profitably?
And it's not every category. I think one of the real magics of Red Hat is because we know the production system, we know where it does add value, where it doesn't add value. There's a reason we don't do a SQL database, and that can be a long Q&A answer we can get into, right? There's a reason we love OpenStack and OpenShift and some of the new categories we're going and what we're doing in storage. And so we can certainly talk in the details about that.
But again, it's because we already have this, call it, hammer, we look for nails not screws, right? We have a production system that works in certain categories that we apply.
Now why is it defensible? Well, let me spend a little -- just a couple of minutes with a couple of the windows into the production system itself. Hopefully it will become clear why we feel like it's kind of uniquely defensible.
There are 2 components of our business model or production system, right? The first is we call it kind of catalyzing communities. So how do you get these big, broad communities with thousands or tens of thousands of participants to move into the direction you want to go, right? So that's part one. And then the second part is, well, how do you take something that's free and get people to pay for it, right?
Now the magic of Red Hat is we've married those 2 things together, right? We have deeply built in our DNA how you catalyze the community to get it to move in the direction you want.
And I can spend an hour talking about catalyzing communities, but let me just use a couple examples because I really -- I don't want to monopolize our time. I really want to make sure that you get a chance to hear from Paul and Brian.
When you have an open source product out in the market and let me -- and I've used this examples with a couple of telcos, with OpenStack, so I'll pick a new one, something different than Linux, right? And you have it up in production, you have a customer running applications on it. And there's a problem and it goes down. My first question now is, are you going to fix the problem? Well, of course, you're going to have to patch it, you've to get it up and running. Okay, that's great. You put in the patch, it's working. Here's the key question, do you have the capability to get that patch upstream? Because if you do not -- if you don't, you're no longer running OpenStack. You're running Joe's telcos OpenStack. And you get 20 of those patches or 50 of those patches or, overtime, 100 of those patches, what happens when the next release comes out if you don't have the capability to get those upstream? Can you even do the next release? So you better have a big engineering team to take that whole patch set and apply that to the new version and the engineering capabilities to be able to do that. And the longer you do that, the further you're branching off from the core, and then [indiscernible]applications written on a more pure OpenStack work on this thing, et cetera, et cetera, et cetera, right?
This is the world we live in, and I'll take you back to Linux. We have a lot of experience with that. When a customer goes down and we put in a patch, we have to be pretty damn sure we can get that patch upstream, right? And because we are the largest contributor to Linux, because we invest in areas that has nothing to do with the core of our products but are good for the community, we generally have more credibility with the communities in which we operate, right? We are the large contributor to Linux partly because that allows us to get changes that don't relate to us back end because we're seen as good stewards.
These type of things, we created metrically equivalent open fonts because we're the true pure at heart having fonts that have no copyright issues or important to a certain group. So us, releasing, investing and building open fonts has nothing to do with our core -- what we're trying to do in production on Linux or JBoss, et cetera. But when we put a patch in and we need to get it upstream, we have more capabilities than anyone else to do that, right? So the issue where others say, well, open source is [indiscernible]. We're just providing support. It's not what you're doing. Providing support, if you can't get your customer up and running but confidently doing it the way that keeps it true to the core of the product -- project is basically working and creating your own proprietary something off to the side, right? And so many companies have gotten that wrong so many times. And let me tell you, it's hard. I wonder, so why can't other people really do this? And very simply, exactly where the open source communities and culture in and Red Hat begin is a really blurry line. And certainly Brian and Paul are much deeper in this than I am. I've kind of had a chance to watch it for 5 years from the outside. It is deeply embedded in our culture, in our DNA, and that, I would actually argue, is probably the single most difficult part of our business model and the single reason why it is so defensible.
I cannot imagine other software company building a culture that can catalyze communities and work with an influence and just having at DNA the things that we need to do to make that work, right? So when we talk about some of these other projects, like OpenStack, the reason I feel confident we'll be successful is, again, we know how to work with these communities. So ultimately when we're supporting our customers, we can build that whole lifecycle of getting those patch sets back upstream, so we never fork our customers. And we are religious about everything goes upstream. And people think that's an interesting little oddity. It is core to our business model and core to really being able to offer production level support on something that's really open source.
Now that's the catalyze community component and why it ultimately is important for our business. It's also important because when a customer, a big customer says we want this feature -- helpful if you can ultimately deliver the future, and you obviously have to do that through these open committees as well. But a lot of this is just a pure down, too. I put in a patch. I need to make sure I'm not forcing my customer in all of the work and effort required to do that.
Now if we just did that, that's not enough in the business model. So great, we can actually offer a piece of open source software. But frankly, the software ultimately is still free. Why are you paying us? So the other thing we do is we deconstructed the software or the enterprise software value proposition. So this is creating open -- enterprise open source software, right. And so yes, the code's free, but everything around that has value. So the long life, the stability, the single biggest thing when I talk to customers, who don't get the subtlety of we can get a patch and we can get it upstream. The single biggest thing we offer is stability. And when I say stability, I don't mean uptime to failure. I mean a defined long life with a defined feature release stream coming out of that. So we can get to a customer and say you put a $15 million application on top of this very inexpensive operating system or on top of this very inexpensive application server or virtualization platform, which was ever the infrastructure products are that we're selling underneath that, we can confidently say you're going to be able to run that application for 10 years, right?
The open source community and the whole upstream catalyzing community and breaking problems in the small parts and all the stuff we can talk about the power of the open source development model is great for building software. It's awful for production.
There's a thing in open source, right? You never fix a bug. You fix it in the next release, but you release early, you release often. And that's great for eradicating bugs. But if you're the New York Stock Exchange running a trading platform, you never want to break binary compatibility, right? So one of the core things we do across all of our products, and I'll talk for a second about Linux, right, we have to track every single bug, every single security updates, patches, et cetera, et cetera, they're happening upstream in the new kernel. And if those are relevant to the old kernel, we've got to back all of them, right? Because we -- so we have buildings of people, primarily in the Czech Republic but -- and other places around the world as well, who habe to track every single package to make sure that we fix every bug, we do every -- fix every security hole in the old kernel. There's nobody in the open source community cares about a 5-year old kernel, but for a telco, a bank, a stock exchange that's running a trading platform, the 5-year old kernel, they need that kernel fixed, right? So that long life and all the engineering that goes into that drives a huge amount of relative cost in our model, right.
If you actually look at our R&D as a percentage of revenue, it's not substantially different than other software companies of our size. In our cases, so much of that is all the residual engineering associated with keeping products going. This, by the way, is the reason there's so few successful open source software companies. Because so many companies come in and they say, we want to be the Red Hat of this, we're going to be the Red Hat at that. And I'm always happy to talk to them and talk about our business model. But you look at them and you say, well, here's our model. So what you need to do is take, if it's a small project, 30 engineers and freeze the spec and commit those people to staying with that for 10 years. And they're looking and like, we only have 32 engineers. I can't do that, right? Our model is actually relatively expensive. The free thing one life has tremendous value to customers. So again back to, aren't we just providing support on top of open bits? That is not true. The engineering that we have to do to keep these projects going for a long periods of time is huge. At the same time, imagine putting something into production when it's going to continue to change over and over and over. So our commitment to never breaking ABI, so application binary interface compatibility is massively expensive for us but a huge source of value.
[indiscernible] as examples around JBoss and the engineering we put, et cetera, et cetera, et cetera, around our projects.
So again, the reason that we exist, the reason we've been successful is we put together a business model that, a, allows us to deliver what enterprise customers want in open source. This whole catalyzing community is driving directions, getting patches back and upstream. And then deconstructing the value proposition around Enterprise Software saying, "Yes, the functionality may be free, but everything else around it, so the certifications, the long life, the training, the obviously support, all those other components are still things that need to be provided that we're able to provide. And it's durable because nobody -- a lot of people could if they wanted to invest, could do the latter, but the former I would actually argue is really, really, really hard, and I'm not sure how many companies could actually do that. And I would actually argue, if any company can do it, it's one that's going to start from scratch and build because anybody who's been in the business and tried to be involved in a culture change, transformation effort, cultures are really hard to change and traditional engineering company. Just think of it real differently. The importance of control, I think, is different. [ph]
So I'll now spend a lot of time on the concept. I think it's really important in terms of when we think about Red Hat, it's tied to a production system that we look to apply to categories. In the same way Toyota to Kaizen, it applies to small cars and large cars and trucks, now JV-ing for airplanes, which is also, by the way, I should say, why I think that our relative financial performance has been smooth versus competitors. And Charlie will wax on, right, about the importance of our subscription model. But conceptually, because we're not directly tied to a category, the business model is about taking share in established categories, right? So one of the reason I would argue that we see as seeing stable performance is I honestly don't care what server growth rates are this year. I don't really care if the middleware market growing a lot or not because what drives our economics is how many share points we take, right? If that market is $10 billion versus $11 billion, so 10%, it's still doesn't matter that much. Now we generally get a higher share of new product -- projects. And so I prefer high growth rates just because we get a very high share of new application workloads. So I'm not saying I don't love growth, but even when IT budgets aren't growing, because we're taking share, we can continue to grow and grow quite nicely and that's kind of -- and also by the way, we have a lot of visibility, so we can look at our pipeline of customers over the next year. We know where they in their relative lifecycle of whether it's unique to Linux or proprietary middleware to JBoss, et cetera, et cetera in those conversions, and it gives us a nice kind of visibility and steadiness that goes along with the business. So unlike -- I'm not trying to pick on anybody who[indiscernible]. VMware, right, kind of grew really, really fast, and then in the Great Recession didn't grow and then started growing really, really fast again and it slowed down because they grow with the server at the virtualization market and how fast that's growing. We had steady growth throughout, again, because we're taking share in categories versus growing or shrinking with a category. So conceptually, I think it's important to recognize we're applying a business model. Again, we're applying that to categories and taking share in those categories versus necessarily growing with a category.
So we have this production system, where do we apply it? So we look for markets where -- and I won't get into the gory, gory detail. We can spend more time on it -- where frankly innovation has slowed down. This is part one, I'll get to part two. Where innovation has slowed down, where there's a general sense that vendors are overcharging their customers. Also, where there is a viable open source alternative that has benefits beyond just price, right? So we obviously started with Linux. So this is, okay, a build up our total addressable market, where it will be here in a couple of years.
So we started off, you look at 2005, server operating systems, $8 billion market. That was our TAM. Obviously, that's a growing market. It's about 2016. I think -- I can't remember which analyst it was. It was one of the analysts, so $15 billion just in the operating system category. Well, we started to do the same thing in middleware, right? We started off with the applications server JBoss, and we've worked to build an entire portfolio. You will mainly hear today about all the new cool stuff, which I will get to. But if you look at even like our acquisitions last year, a lot of our work continues to take existing categories and offer open source alternative to that infrastructure. And so whether it was an acquisition of Polymita or FuseSource, those aren't super, super sexy, but those are large categories where -- with very high price points, where there's real dissatisfaction with the existing legacy players and a real demand in thirst by our customers to offer alternatives.
So we continue to look for opportunities to take open source projects like Camel, which is part of Fuse. It's an Apache project, the lightweight ESB, a lot of interest in the market, acquire that, bring that to market and a bigger way than Fuse could do it its own because the size. Let's commoditize this category.
In the traditional data center, middleware is a $17 billion market or projected to be about 2016. So significant opportunity for us to continue to take share in these traditional categories. And again, we never do a category, we also don't have advantage beyond price. So obviously with Linux, all kind of Marriott feature functionality, but certainly the power of X86.
The application server, we have tons of examples about those dramatically lighter weight, faster, but developer productivity because it was written by developers, right? And we can go category by category talking about our advantages not just around price but around modern architecture across the categories.
Virtualization. Obviously, it's something that has kind of gone from a kind of new growing thing to something that slowed down and there is, obviously, a growing dissatisfaction around kind of price, especially and an inflexibility with the current leader in that category is right for commoditizations overtime.
Storage. We are -- have entered a small part of the storage space. We'll see where that goes over time. But we think about scale-out storage, the explosion of unstructured data. But for us, very importantly, hybrid cloud environments, where exactly where the data is, needs to be abstracted from the application, having a software-based solution, so customers can flex up on Amazon for their storage needs is an area where we think that not only can we bring the cost of commodity hardware and commodity economics to storage in a traditional scale out, unstructured data sense, but there's also a whole set of features and flexibility associated with the fact that it's software-based.
Finally, threw in cloud here. No analyst has a clue how big cloud is going to be in 2016 and neither do we. So there's a wedge on the pie chart, but who the hell knows? It's probably going to be pretty big, and we obviously have a number of things that we're doing there.
So let me pause there for a second before I do this slide. So much of our business and much of our go-to-market still is around -- I can go back -- the $43.5 billion, excluding cloud, traditional data center still is a massive amount of legacy software there that over time needs to be modernized. Certainly, needs to drive a ton of cost out of that and that continues to be a significant market for us. You hear us talk less about that today, but we really think about our go-to-market motion. It's a big part of what we do, and there's other areas beyond that, that over time we'll continue to look at other areas, so we can continue to come in, offer our value proposition, and take share over time. And by the way, because we've already done it with Linux and pretty ubiquitous around Linux, our customers are very open. They're talking about all kind of categories with us in those areas.
But there's a second going on now. I didn't have a single picture of a cloud. I just want to say so far, it's a CEO in a technology company not have a picture. There is this thing going on around cloud big data, et cetera. But the interesting thing about what's happening in some of these newer areas whether it's SDN, big data, cloud computing, virtually all of the innovation is happening first in open source, right?
Name a significant big data product that's proprietary, right? Almost all of these things are happening first in open source. And it's certainly not because of us, right? It's because of a whole set of dynamics. First off, you get these massive Web 2.0 companies. And even just really large enterprise customers who now have this large engineering teams who have the capacity to actually drive innovation on their own, right? So the whole Hadoop phenomenon really started off a set of needs that Google had and Yahoo! and starting the project and other people kind of jumping on, right? This is a problem that the vendors didn't know existed until after users solved it themselves. And I don't exactly where we are on that timeline, but I'll tell you, if you look at whether it's SDN, big data, all things going on around cloud, to me, I think we're further to the right than people imagine when we started saying how much of the new innovation is happening first around open source.
Now for us this offers a whole new opportunity for us. So it's no longer just how do I look at the existing work? How do I commoditize it? Bring the value proposition of our production system to that market, right? So the first time, we actually have an opportunity to lead in emerging categories. It's actually quite interesting, and Brian and Paul can give you a lot more color as to where our talk [indiscernible] to customers around it. Obviously, we're the large contributor to OpenStack. We made a lot of announcements on OpenStack. I don't want to go into the details of OpenStack or OpenShift. Brian will talk more about those. But let me just say, for the first time, we've moved from what I'd say having conversations about how we bring value and help customers save money and talk about flexibility, et cetera, et cetera, the data center consolidation to really moving to the front of the house for how we're really offering broad next-generation solution, how we're driving architecture for our customers. So it used to be the technically sophisticated customer, so the investment banks, the stock exchange, the telcos, we had great CIO-level relationships with, but the traditional retailer or airline et cetera, et cetera. Yes, we've sold to them in their data center, but we weren't really strategic. All of a sudden, we're finding ourselves more strategic to more customers because these things are becoming much, much, much more strategic.
I'll be the first to say, and I think we try to be conservative, we're not ascribing or building a lot of revenue in now. We got to see how these things work forward. I'll pick on OpenShift as a great example. I think PayPal talked a little bit about their use of OpenShift. We have a lot of great customers using OpenShift, very different sources of value associated with it. But what's interesting for us is traditionally we go into category optic like SOLA. So we decide we want to enter the SOA space. You know the size of the market. You know who the competitors are. You know who -- what their price point is. You know how long the development or the sales cycle is associated with it. You know who the buyer is. As a matter fact, we just go out and hire sales people from our competitor who do that, but they know how to go out and sell the thing. And then we go out, we work to commoditize. It's a very known thing. Why take something like OpenShift, which to me is more exciting than OpenStack because how transformational our customers who are working with it talk about it being.
Who's the buyer? Is somebody in operations? Is it somebody in development? What exactly is the value proposition? So how do you charge for it? What's the sales cycle, right? Is it a long one? Is it a short one? So what -- so how do we think about pricing it, et cetera, et cetera? Right? So all of a sudden for Red Hat, it's actually quite interesting because it's stretching our capabilities because there's a whole new set of things that we need to think about that are very different than our traditional go-to-market. At the same time, CIOs are the most traditional of traditional companies, all of a sudden want to talk to us, right? So we've gone from being the thing that certainly technically sophisticated customers, again, the banks and people hire A-plus computer science student, knew us well, wanted to meet with us, but we were a mystery to the majority of IT.
Now all of a sudden, all these people want to talk to us as well. So if positioning is not only around new products like OpenShift and OpenStack, but the residual drag into application, modernization, right, data center consolidation, which ultimately ends up UNIX and Windows to Linux or as proprietary middleware to JBoss, et cetera, et cetera, continues to accelerate is there's more synergies across these things, and we think about it from a go-to-market perspective.
And we're also finding that as customers look around cloud, our value proposition actually gets much stronger because when you start thinking about, from a enterprise customer's perspective, I want to move things to cloud, how do I do that? Right? The importance of a common infrastructure that you can run in your data center and across cloud around hybrid cloud which certainly looks like it's investing only gets stronger. I know we'll have some questions about it, so I'll hold off spending a lot more time on this because, again, I want to make sure Brian and Paul get their full time.
But as we continue to move forward, as we get more strategic, we're actually finding the hybrid cloud discussion elevates us to a fundamentally new, more strategic level with our customers. So the Wayne Gretzky expression, "I just want to skate to where the puck is going to be." We don't have to skate. We're standing to where the puck's coming in terms of the architectures that people are looking for and the infrastructure they want across those architectures. And it's fascinating to watch us just get in more and more strategic to a large and larger set of customers over time.
Again, just to wrap up, we continue to expand our addressable market. Again, sort of to find our production system. We take that production system and continue to apply it to categories. You've seen us do it to date across categories, and we'll look to continue to do it. We have these new emerging categories that all of a sudden we've gone from commoditizing existing to being truly a leader in. And finally, as enterprises look to on-ramp to cloud and are looking for strategic partners who can provide them not only the cloud infrastructure or OpenStack, OpenShift, but the underlying infrastructure that can be common across cloud providers. So the Red Hat-certified cloud provider program, so you can run workloads, certified in clouds, running RHEL and all the components that go into that together just continues to make us more strategic, which gives us larger and larger wallet share back with our customers.
I think that was my last thing. I also get the pleasure, since I'm right on time here, to introduce Brian Stevens, who may come up here and disagree with everything I just said. I hope not. But he can really give you much better sense not only of how the general strategic direction is driving itself into the technology that we're doing and also a lot of richness around our customers and now they're using some of these technologies. Brian?
Thanks, Jim. Good morning. Okay. So I wanted -- this is definitely going to be centric on some of the technology we're doing and sort of, as Jim said, why we're sort of investing in OpenStack and OpenShift and actually going to spend a little time on demystifying that a little bit, sort of what they are and why they are interesting? But in our opinion it always starts here, right? Sort of the dialogue that you always have at the senior level whether it's -- it doesn't really matter whether it's just admin or the CIO or the CTO and some of that -- our existing enterprise customers. They never have enough dollar to do what they need to do, right? So and to us, that's actually a good thing. So in best case, their budgets are flat, right, but the list of what they have to invest in is huge. So big part of their struggle is sort of how do they sort of navigate the waters, and how do they make these incremental investments. Jim just mentioned to you a handful of technologies from cloud technology to big data and look at mobile, right? And sort of just those 3 categories alone means there's a massive sort of pivot that a lot of the IT organizations need to take to really sort of serve. And I'll talk about a couple of those right now. So just from a developer lens and sort of when we sort of -- we actually always sort of step back and say sort of what problem are we solving? We did go from that world of sort of fitting in the category of others like the early days [indiscernible] started here. It's easy to come in and compete with Solaris and SPARC and bring in Linux, bring in Red Hat Linux and Intel and have 200 times the performance at a fraction of the cost, right? And so that market is still alive and well. But what we're sort of looking at is there's these new opportunities which is just sort of find that category that already exist and to commoditize it. That still happens across a large part of Red Hat. We actually tried to really understand and address some of the new problems and the new issues that from a big data solution we're not replacing any of the big data solutions, right? We're bringing new capability IT, and that's actually really exacting.
On the developer front, the way people -- developers are right now are different, right? Even from 5 years ago. We look at it just even inside of Red Hat it used to be that you wrote your app on your workstation and you deployed it on a server and you -- all the resources you ever need from a developer standpoint sat under your desk. And now you look at developers -- our owner actually -- for procurement are looking at. Their apps now had to scale it, run publicly on the cloud, and then they have to scale. So developers now need these resources that stretch into the 100s, and they need it not constant -- when they need it, they need to scale, but then you can't justify it just for that one app, right, from a utilization standpoint. When you look at the stack they're using, like the stacks are very different. An app that doesn't have a mobile front end really doesn't exist really when you think about it, right? How many times do you use a public service and you can't use that same application? It can't just be a Web browser. So the stacks that these developers are using from mobile frameworks, these new databases, they're not gravitating -- developers aren't building around Oracle anymore, right? They're building out some of these. Either lightweight SQL databases, cloud databases, no SQL Mongo Cassandra otherwise. And so they're using stacks of software that don't even -- aren't even blessed by IT organizations. But they need scale that IT can't give them, and they need these application stacks that have not been blessed by IT, so it's really what we call sort of a shadow IT effect, and open source is really good at sort of how does actually new technology bleed its way into IT, and it starts in a very unwise manner. I mean you look at sort of line of business. I had this conversation in Europe last week and then also last night at dinner, it seems to be the same pattern is that you hear a lot of the competitive advantage of businesses is turning to customer engagement, application driven like creating customer engagement across mobile and online. But the phenomenon around it is that it used to be this whole world is sort of that -- because now I think technology has flattened everything out that you own a competitive advantage. So now we're seeing it from our customers is that the time they actually deploy new apps to sort of to compete and drive engagement really has this bounded 2- to 6-month window around that, right? So when you start to think about it, they can only enjoy it 2 to 6 months advantage. The time they actually take to get their apps deployed really matter from the time they're done being developed.
And so that's sort of the world that IT is living in. So they are not able to [indiscernible] the needs of the developers from resources, stats, and then they get the lines of business that are pushing on them all the while, that's why you're seeing things like Amazon, right? You see these external IT departments, you see these external IT departments that are able to service customers better than the online IT organizations. So that's our mission, right? Our mission is to sort of bring IT back, right, to sort of be the center of this, to be the hero not just providing these stacks and agile development but also this world that continues deployment. And that's really why open source is good. So open source is driving all the shadow IT that's coming into IT organizations already. We did it with Linux. We think we can do it in sort of this new vector. We started talking about this sort of last year, and just sort of I think everybody expects -- everybody accepts the world of commodity, computing has landed at the application tier. So you're looking at Red Hat Enterprise Linux and Intel. What we're actually seeing is that the core of hardware, right, is less differentiated, used to be that from a hardware perspective, it's all about differentiation. And now what we're seeing is that there's still an incredible amount of innovation that's happening within hardware, but when it reaches customers, it's reaching not in a differentiated solution but inside of a standardized package, right? [indiscernible]. So you're seeing extensions to that with what you're seeing in sort of caching and whatnot in the Fusion-ios. But the building block that enterprises are building on is staying consistent. And so the only sort of up-and-comer to that right now that we're seeing at all, to be honest, is around our technology. And now what we're seeing in sort of that inner core that we accept for applications is now actually driving and replatforming how customers and enterprises think about like managing data and storage and then also even farther out around networking. So what we're really starting to see is sort of this commoditized from an inner core across enterprise. We're dealing with compute, network and storage. And the difficulty we have -- and while that's all great -- so that's a great position for Red Hat because all of these things are powered by Linux and increasing the Red Hat Enterprise Linux. What we never had the answer to is how do you actually take the worlds of compute, storage and networking and knit them together, right? And that was really why -- so with OpenStack coming along, it was really a blessing for us, right, because that's really what OpenStack is about. It's really around IT architecture, right, and sort of how do you actually integrate compute, storage and network into enterprise environment or a service provider cloud, right, in a way to actually orchestrate that.
And I'm going to sort of -- a lot of this is going to be talking through what OpenStack is and why it's good for Red Hat and how we actually get there. But the -- a big part of -- so when we started talking a couple of years ago on compute, storage and network and commoditizing that and driving value to IT, OpenStack maps exactly well on this, so OpenStack mission. So right now, missions can change, but its mission for the last 3 years is really about how do we build infrastructure as a service cloud, right? And so there's been a lot of sort of debate on extending that mission and getting broader in the platform clouds and other things, but right now, the mission is really around focusing on building these large-scale infrastructure clouds. And it's actually a collection of projects that are integrated, autonomously integrated, right, on how they're managed and actually come together to build these infrastructure clouds. It's really kind of interesting for all the buzz and mind show that OpenStack has. I think it's true, that a lot of people don't really understand exactly what it is. But it's really only been around for not even 3 years, right, so a little less than 3 years, which is kind of surprising. So the first is started by Rackspace. I think people understand that. And it was some code from Rackspace that came into Rackspace by acquisition and then some newer code that was written by NASA. And we took a path. So we spend a year sitting on the sideline of it because as much as we get approached all the time by companies that are going to be there, create a new project or take some proprietary stuff in open source and then great things happen. But I think we've got off of an appreciation of how hard it is to really build community around open source. It's something that we think we're the best at but we learn every day. And so we sort of watch OpenStack for probably about 10 months, and then -- but everything that Rackspace said was actually starting to happen from 2 key points. One is, they're creating this brand that was maybe not completely understood but well-known globally, right? There's not a customer that doesn't want to talk to you about OpenStack today. And then the other part was, I think, even just as important was that they actually had created a equal enough platform that developers around the world and even that competitive company were coming together and working on the same code base. That's a hard thing to do, right? It's easy for a company to come out, IBM, using them as an example, and say, "Here's an open source project," and then hoping that other people are going to come and contribute to it. Really hard to get others and your competitors to sort of collaborate with you, but they had done it even though Rackspace was still owning this project from a branding perspective and copyright. They had done it and it started to grow.
So 10 to 12 months later, we decided we're going to pivot on OpenStack, right? So in 2011, we decided that we're going to actually relook at all of our product strategy and technology strategy that fit in that sort of area, right, because we had our own investment, sort of trying to realize doing a cloud. And we decided, "You know what? We're going to start to operate on the OpenStack canvas from a community perspective and a product perspective."
And then -- so we signed just our first developer, to be honest, in 2011. I think it just sort of comes to the strength of sort of our model, and we know how to actually participate in these communities. First developer in 2011 and the goal was pretty modest, which is like how do we get OpenStack package into Fedora, which is our community release of Linux. About 9 months later, we became the #3 developer of OpenStack. 6 months after that, the end of 2012, the teams just continue to build. We became the #2. And then most recently, with the April release -- so OpenStack, the community releases come out every 6 months. And with the April release, we're now the #1 developer, right? But as Jim said, the goal was like we got to become the #1 developer. The goal was like we need to know every line of code that's in this thing. We need to be able to advance it. We need to be able to have great customer engagement. When you're talking to a customer, you can't just come in with a body of code and then, say, wait for them to call you from a support point of view. You got to come in from a consultancy standpoint, be able to discuss it, talk about how to integrate it. And so by solving that problem, if you're serious about it, naturally, you're going to become a large community contributor.
And then Rackspace said one more thing, is that they actually -- they had a tiger by the tail from the ownership of this brand, but they decided -- even though this development was happening, they decided to actually federate the brand. They actually spun out completely the brand and the ownership of the governance of the project into a foundation. So now -- so Red Hat is part of the foundation, IBM and HP. A lot -- basically, these competitive companies and partners, in some cases, all came together and says, "We're going to steward this thing together." And so that comes with both a dollars funding, as well as developers.
Now the brand is completely separate and governed into an OpenStack foundation. And what we try to do is we have the notion of a technical board and then a overhead board, if you will, for the foundation, right? So -- and sort of our mission on the -- on participating in the OpenStack foundation is, in a way, to sort of make sure that the right dollars pour into the right areas, but more importantly, stay out of the way of the developers, to be honest, because the developers need far less guidance than people would realize, just like Linux. So it maps really well. And when we're talking about that open share of compute, storage and network, OpenStack maps really well on top of that. And from a compute perspective, it's really shockingly simple. This is the piece. It's -- Nova is the compute piece. That's the piece that NASA contributed. So that technology just started getting written in the last 4 years, probably. And so what that's about is from an infrastructure perspective, the whole goal is just to be able to -- when a user wants a virtual machine, you hand them one, right? So everything around Nova is just user comes in and they -- all of these have not just GUIs but they all have APIs. Everything around OpenStack has what's called the REST service API, the web-centric API. And what that allows us -- that why you're going to see all these other software that's going to come in and integrate with each of these services, whether that's high-level management solutions or it stores some developer tooling. So Nova is all about like -- you need a VM, then Nova is actually about like how do I service, just like an Amazon cloud would be, how do I -- where do I actually provision, understand the utilization of the hardware footprint of the OpenStack deployment? And where does it make sense to match what that user request is from a virtual machine perspective onto your existing infrastructure? And then also the notion because this is cloud and not virtualization. You have to deal with the case that a lot of these VMs are ephemeral and have short life, right? So you want to be able to actually deal with releasing it. So it's a very -- there's subtle but very important differences when -- from a cloud perspective where these virtual machines are coming and going. And then the size of the Nova compute tier itself has to be able to grow. And so what you'll see is that a lot of the vendors today, early on, are all like focused on like how do we actually install and deploy OpenStack. You'll see the vendors sort of competing a lot on I can install OpenStack in 5 minutes or I can install it in an hour, which isn't really what it's all about, right? Really, it's really around -- from a customer value point, it's really around all the operational and management tooling that you can bring to them around OpenStack and less around how quickly you can deploy it.
It's what actually, I think, is kind of interesting is the foundation commissioned to user survey. And I think the numbers -- this is publicly available. I didn't have the [indiscernible] out here, this user survey. It's actually pretty interesting. And I think it was about 200 users -- end users of OpenStack, and they ask them which hypervisor you're running on. So OpenStack takes great care to be hypervisor-agnostic but only to the extent that there's a developer out there that cares. So it's not like it's a mission that says, "Okay. The foundation owns and keeps it hypervisor-agnostic." If Microsoft cares to make sure that OpenStack works with Hyper-V, they got to shell off, right? And so they shell off and they make it work and they show up in a development list. So this is the fixed hypervisors, I think, that came out back in a survey that people are running OpenStack on and KVM was far and away the default. And I think in that -- I think what that speaks to is a couple of things. One is that a lot of these OpenStack clouds are greenfield, like it's going to be really hard for Amazon to like turn the corner from Xen just because you think of sort of all the inertia and legacies that you have. They don't have that opportunity to sort of -- to move. But from an OpenStack cloud, they get the choice of which hypervisor they're allowed to deploy on because they have no legacy. And so far and away, KVM is the default choice. And I think why is because it really exists, right? Everything about KVM builds on Linux, right? So the way -- we had looked -- our early days of Xen when we had -- we're supporting Xen, we had separate even development teams and separate product stacks. So we had our Xen hypervisor team and our Xen hypervisor over here and then we had the Linux team over here. And there wasn't a lot of sort of synergy between those 2, other than the fact they were both open source and maybe there are some subroutines that were shared. KVM is different. Our KVM team is in the Linux team because KVM is actually just a kernel module that [indiscernible] as a driver. You have RHEL. You can install RHEL on a system, then down the road, you can decide you just load the driver, and all of a sudden now, you can start running VMs. So it's really -- that was sort of the genius of the developer that started KVM was the simplicity in it. And the -- and so what that means is that all the best parts of Red Hat Enterprise Linux accrue to the hypervisor world. So everything around like hardware, support, performance, scale, manageability, the security models, is identical.
We talk about this one a lot. I think this is sort of like -- because you talk about Linux, Linux is now 22 years old. Some of it still feel like the new kid on the block at 22 years old, but yet the reliability of it is so well-trusted. So over half of the world's trade -- equity trades actually happen on Red Hat Enterprise Linux. So we'd expect it at that point in a technology cycle, right, as you sort of see all that. Now you're in a maturity phase. And so probably, the innovation is coming less. It's actually the opposite on Linux. The innovation and then the development that's happening inside of the Linux kernels, specifically, has never been greater. So [indiscernible] is still sort of the benevolent dictator that sits on top of the blesses the patches that come in. And recently, the current kernels under development, they had a 12-day merge window. And so that window is when he actually accepts new changes. And that 12-day merge window, over 12,000 independent changes, features were added to Linux. So that rate is like -- it's unparallel in the proprietary world, but it's also never -- has never had Linux sort of gone down that path.
And then on the storage side is sort of -- when we -- from -- there's 2 core storage services that are part of OpenStack today, and then there's a third which is a piece of sort of Red -- it's a community project but then the basis for Red Hat storage. And so typically, we combine them all together from a customer deployment standpoint. And what they are, so when you look back on the -- and there -- because there are 3 distinct sort of models. The first model is a notion of sort of an object storage or a block storage, and why that matters from a cloud architecture is that -- because if you think back around infrastructure clouds, they're all about like running a virtual machine. So basically, a virtual machine is nothing more than a copy of your operating system or your applications wrapped up into an image. So just like with Amazon's cloud, the first thing -- if you want to actually start a virtual machine on Amazon, the first thing you do is you load your virtual machine, your image, you upload it into REST 3 service, their object service. So OpenStack has now the analogous of S3 in this thing called Swift. This was the piece that came into Rackspace through acquisition. So your first part is where do I store my virtual machines that I'm actually going to lodge on the infrastructure cloud. And then people are using them for other things as well. You can use these image -- these object storage services for things like your backups or video files or otherwise. But the primary use case is for a place to keep the virtual machine that you're going to launch.
The second piece is I think called Cinder. It used to be a part of the compute tier announcement split out. And so OpenStack is going through these ads that's being developed that also gets rearchitected along the way. And it's being made more sort of from a model of higher granularity and pluggability. So Cinder is the other piece which is the volume service. So if you start to think about like [indiscernible] or a volume service or what a Sands would present back, that's what Cinder is. And -- because once a virtual machine is up and running, an operating system needs its local filesystems. And local filesystems are usually always modeled in a block device or a volume service. And that's the Cinder piece. The difference in the early days is Amazon only had an ephemeral storage. So if you had a VM running up on Amazon and you rebooted or recycled it, you will lose your state because all these filesystems were just kept in memory. Now Amazon has moved past that, as well as OpenStack has with known as -- it's a persistent volume service.
And then the third piece is the piece that we -- which is a community project, Gluster, and it's a basis for Red Hat storage. And that is more around addressing what the apps need that are running on an OpenStack cloud because a lot of apps, they either want to talk 1 or 2 things, right? They want to either talk to a database or they want to talk to files, right? And so -- and then when you start to think about like from a cloud perspective, it's not usually about one instance of an app anymore, it's usually around for elasticity and scale, if all of a sudden that application is heavily in use, you create more instances on the cloud dynamically. And so each of those instances wants to have a common view of the filename space of the same file. That's what Gluster really does. Gluster comes in and offers both [indiscernible] compatible file format, as well as POSIX in UNIX file formats. And it does -- and it deals with -- redesigning deals with replication so that if you file with them in more than one place, right? So this is all built on standardized RHEL across [indiscernible] you're basically taking what you used to only be able to do in Sands in the hardware and now you're able to do that in the cloud or on-premise by running on RHEL. And it deals with -- so now more data growth is as simple as just adding more RHEL servers to a Gluster storage service, and you get all the local data that was in those. So what it does is it takes a lot of cheap parts, right, actually, 6 parts, and turns into a reliable, resilient storage care because it does that to replication, just like the Amazons and the Twitters that they do inside this because they're running out of Sands. And it does that because it just replicates files. So if you need -- if that file is actually -- access a lot, it just replicates it, right, and then it [indiscernible] the load on that file. And then that replication of those files is also what gives it resiliency. [indiscernible] one actually fails, you have copies somewhere else. And so we're doing a couple of things to it. We're actually integrating very deeply into OpenStack. Not only can it speak file but it also can speak the object storage and the block storage that we just talked about. So you can see people just use Gluster alone as the file -- as the unified file storage service for OpenStack or they can use it in concert with the other 2 services that I just talked about.
And the last piece that we're doing is we're making it work well for Hadoop. So Hadoop actually -- and especially like [indiscernible] reduce, it puts that particularly sort of workload on our filesystem. And that's why it had a special purpose. Hadoop has a special -- it has a special purpose file called HDFS. And so what we've been doing is teaching Gluster all about map reduce so that way -- customers have standardized on this unified storage tier. They shouldn't have to go build up a whole another silo just to run [indiscernible] applications. And so it's really all about performance.
And then we got a video of Intuit. So Intuit is a particular customer. It's great to have -- it's awesome to have customers talk about your technology, but usually, when you're doing a deployment with a customer, you have a set sort of schedule. Intuit is a great example because their schedule is set by the federal government. April 15 is when your taxes are due. And so we actually live the world within -- for the past 9 months, really, on -- and even some new capability that they needed inside to support this last tax season, things like -- and it's all based on Gluster. They needed things like -- not just geo-replication, but they need it. So every time you save your tax file, it had to be -- I think the isolated way to design with them. Every time you save your tax file, any change you made had to be on a different server, certain distance away within 3 minutes. And so that was actually designed over the winter in preparation for their tax season. So I'll show you a video.
Interesting v-roll. Back to the -- okay. So then -- and then the last piece of sort of the third [indiscernible] OpenStack is all around network, right, because the -- and what that is a project called Quantum, and it's actually renamed OpenStack networking. And now it's going to have a new name after that because there's a company called Quantum out there that wants to keep their trademark. But you'll still hear us represent Quantum, and then slowly, we'll sort of edge away from that. But Quantum is really around how do we build a common API, a consistent API, because remember, OpenStack, all these services are about an API because we want software-defined storage, software-defined compute and software-defined networking. So Quantum exposes what that networking API that you need to actually build SDN software-defined networking applications on top of, right? And the -- and then what's nice about Quantum is that -- like a lot of the OpenStack services -- all of these services don't try to necessarily do everything themselves. Often, what they had tried to do is they might have some default capability, but they have plug-in architectures. So underneath Quantum is Cisco. So Cisco shows up, they've got physical switches and then they write software to actually bridge their physical -- the orchestration of their physical switches into Quantum, right? NTT shows up with their software-based network controller. So the whole ecosystem was sort of networking partners. Hardware and software shows up in OpenStack to make sure that anybody that's using OpenStack and then that Quantum API can orchestrate their world. And it's simple what they're trying to do is because the -- you want a programmatic way to reconfigure the network to support what you do with your applications in your data because now, [indiscernible] cloud, we're creating the data, sort of doing -- laying out networking first. And the data center is always very static, right, even in your Rack -- top Rack switches, everything is wired and it was always usually 1 OS and 1 app per physical server, right? Now all of a sudden, every server is -- slides up in the virtual machines and you don't even know sort of who the tenant of that virtual machine is, right? It might be different users and different businesses, even, that are sharing the same hardware through virtualization. So you need to be able to actually -- be able to configure the network from a security and a connectivity point of view. The world -- what we try to do is called VLANs, right, so how we virtually wire, but even that has too many dependencies on an underlying hardware. The whole world of software-defined networking is trying to say, "How do we create this virtual network overlay independent of the physical overlay, just like what we've done with virtualization, right, physical hardware, virtual machines?" The same thing is now happening on the networking side.
And there's a couple of key projects in that. There's a couple of key parts. One part of that is really centric to Linux in that because even inside of Linux now, there's a capability that we're bringing out in our new OpenStack platform that actually brings the notion of virtual switching right inside of the operating system in the hypervisor, right, because the notion of sort of anybody sort of how even IP addresses, right? If you're able to true some of the virtualization capability we're bringing into this new version of Linux, you can have the notion of 2 applications actually having the same IP address, even, on the same operating system because the virtual switching actually is going to separate them. And that's what end users want. They don't want to have to worry about collision of IP address bases with other customers or other apps, right? And so the virtual switching that's happening inside of Linux, which is probably called OVS, is a big part of that.
And then on top of that, there's a thing called these independent software-defined network controllers. This is -- [indiscernible] was obviously very popular, with a really strong exit example of one of those. And what's happening is as customers are building these really large thousand -- 10,000 compute zones, they actually want a more distributed software-based orchestrator that understands my complete networking address space across the enterprise or service provider. [indiscernible] was very -- is a very popular one from a proprietary standpoint. And what the industry did is they got together and said, "You know what? Let's collaborate on this thing." So they took a page kind of out of the OpenStack playbook and said, "Let's get the industry together. Let's build an open source version of a distributed software-based network controller." And so it's Red Hat, IBM, Juniper, HP, Cisco, I mean, even a company that tends to be disrupted by that, like Cisco, who just says, "We got to be here because this is the way of the future." And they actually led -- the initial code donation actually even comes from Cisco.
And the networking side -- and then OpenStack from a governance point of view has a way. It's evolving really quickly. So we've set up a structure of sort of how the new projects find their way in to become part of OpenStack, and there are sort of a graduating tiers of projects, again, become an OpenStack project, which is being used in the infrastructure in the community model to build your project. And then above that though, the real blessing is when a technical committee says, "You are now an official OpenStack project." You are now what they call integrated, which means the technical board has decided that there's enough robustness in that project and developers to sustain it and it has enough value that they're going to actually make it part of every community release of OpenStack. And 2 new projects are Ceilometer and Heat that just graduated into becoming blessed OpenStack integrated projects. And Ceilometer is really around [indiscernible] infrastructure cloud but how do you manage it. So Ceilometer is integrating all of the metrics and statistics and analytics that you need in the infrastructure cloud so that you know what's going on and you can manage it. And then Heat is actually -- was actually started by a Red Hat developer. And what Heat is, is it's a way to sort of express composite applications because people aren't just deploying a single instance of an app, they want to build composite applications that has web tiers, load balancers, databases, they're going to stretch across a number of VMs. And so Heat allows you to express that metadata logic, as well as how do you configure all the resources you need in the infrastructure cloud to play that app. So with Heat, you build this sort of recipe file and you just throw it at OpenStack, and OpenStack does the rest by actually standing up the app. And so we decided -- so what we decided to do is, originally, we're thinking of having an OpenStack on bundle release, right, à la carte, Chinese menu, you can buy Red Hat OpenStack. But what we've sort of learned over the last 2 years is that OpenStack is really driving its -- the innovation of OpenStack is actually driving technical capability that didn't even exist in Linux, like some of these virtual switching that I'm talking about. There are other things that are happening in KVM and storage. And so we -- what we decided was that we want to allow OpenStack to sort of drive the cadence of some of these aggressive innovative features in Linux. So we put it together as a unified solution, a unified product. So we've extended the Red Hat Enterprise Linux with a new variant called the OpenStack platform, right, and that's how from Red Hat you actually consume OpenStack.
I know that's awesome. And as Jim was saying, I think I agree with him on sort of the enthusiasm. There's a lot of enthusiasm about OpenStack. But all that's really done for developers, it means they don't have to wait on virtual machines anymore, right? So developers still say, "Okay, I'm not waiting on IT to get me a hardware. It's instantly available at my fingertips." But it hasn't changed a bit. Now I can actually say the name behind this conversation, which is PayPal. So the PayPal conversation started last year with them. They actually had done this audit. They had new -- relatively new developer, and they gave her an assignment, it was to write the most simple application, which was called [indiscernible] example. And then she had to deploy it, get it deployed through the processes to PayPal to get it deployed on [indiscernible] infrastructure, right? And they seem like a simple task because it's -- an application living inside isn't that useful, it's got to be hosted so you can drive customer engagement. And it took over 60 days to get an app deployed, publicly phasing from the time it was finished being developed. And that's not -- I think they're better at it than anybody else, right? And so that's sort of -- that's actually a shining star case. But that's problematic because what you really want is this, what you really want is you want it from a competitive advantage. If you only have 2 to 6 months off from enjoying a competitive advantage or your competitors are already ahead of you, right, you want to actually have the -- you want to get to a world of continuous deployment. So in a continuous deployment model is, really, as the application is written, it's actually being developed on the infrastructure that is actually used by IT to deploy it, right? And that was really -- and then if you can get there, there often is a huge business advantage. And that's really what we started OpenShift about -- it must be almost 4 years ago when we started working on it. There really wasn't a category called Platform-as-a-Service back then, but we knew that IT organizations had this problem. We knew that we would show up with software and then -- and that why customers thank us, I mean, while they're spending the next 6 months trying to get that software and new apps in production. So OpenShift was all about how do we really look at developers and make them extremely productive and be able to take advantage of internal clouds, as well as Amazon clouds, because our guys were still becoming virtual machine guys on Amazon and they're still becoming just running apps OS guys. They had to deal with all these things just to get their app deployed. So OpenShift sort of bridges that GAAP both on -- we have obviously a public instance that runs on top of Amazon, and then we have a private instance that we sell under subscription to customers. And then we have a community version. And these are the steps that Jim showed you. So on the OpenShift cloud on Amazon, like right this minute, there's over 0.25 million apps live running, right, that are using that service. So you can imagine sort of what that does in terms of sort of both hardening and validating the model.
And then this was a throw into the stats just from May. So in May, those apps -- those 0.25 million apps consumed over 13 million Amazon minutes. And on average is the average that 2,032 is -- on average, each and every day for the month of May, upwards of 2,000 new apps were created, right? So that's a problem-solving, right? So in that model, developers are actually just developing remotely on their system. They're not dealing -- they don't know what NoS is, they don't know what VMs are, they don't even know what the Amazon interface is. They're working other local dev sandbox, and then they basically press a button by running one command. And then that deals all the deployment of their app, brings their app up onto VM on the OpenShift cloud that deals with testing, that deals with packaging it, they can deal with any sort of life cycle that the customer wants to put in. It deploys from the DNS. It deals with auto scaling. All of that, all the security models, they don't even have to know. They just know that as soon as they -- within -- usually about 10 seconds of they make a change to their app, it's up and running on a public cloud. So that's the advantage to give the IT organization, is not only they have application agility, developers aren't worried about all these infrastructure clouds and they are always continuously deployed. And now IT is actually using the same platform that developers are using to manage the apps and manage the life cycle of the apps.
And then the last sort of thing is on CloudForms. So CloudForms was really around our model of going the last mile saying that the world is going to be heterogeneous, right, from a hybrid cloud perspective. Amazon and other clouds are going to obviously continue to exist and solve each problems. Customers are going to VMware inside their own environments. They're now going to use Red Hat Enterprise Virtualization. And they're going to use OpenStack, both publicly and privately. So CloudForms is the product that actually drives the integration above all of those and goes the last mile. So it deals with -- in a cross cloud way, in a hybrid cloud way, it deals with things like how do you actually have a set of users that actually want to have -- that you want to use the infrastructure? How do you give them permissions of what they can do? So IT is running this. They're taking a thousand cores from Amazon, a thousand cores from RHEV, putting it together, and then they assign what developers and end users get, right? So -- and not only do they assign the privileges that you get. So when you actually ask for virtual machines, then they also moderate, they deal with chargeback, they deal with utilization, all in a hypervisor- and cloud-agnostic way. So it really allows -- otherwise because IT, what you're seeing is they're building around VMware, they're building around RHEV, they're building around Amazon. They got 3 completely bespoke models for how they manage all that. And so CloudForms knit all that together in a really unified fashion.
And I think that's it. So that's really sort of the -- that's really the -- it really is moving Red Hat out of that category between OpenStack because customers don't have the ability to build on-premise cloud today without it and things like OpenShift. It's really sort of putting Red Hat in a position where we're not just replacing and driving costs down for a category that customers already had. We're giving them the capability that actually allows them to fundamentally change sort of their OpEx and their CapEx structure and give them the ability to compete.
So I think that's it. I think I'm calling Tom up to transition us to a break.
Great. We're going to take about a 20-minute break. There will be some music across the webcast. And we'll come back in here when the video starts up. Thank you very much. About 10:35.
James M. Whitehurst
Let's start the video, please.
James M. Whitehurst
Great. I'm sure you've generated a few questions with that last video, so if you could hold those until the Q&A session. I want to bring up Paul Cormier, our EVP and President of Product & Technology, please.
Paul J. Cormier
What we'll talk about this morning is -- I'll talk about the developing dynamic, what's really going on in the developing world, in the whole -- in the Red Hat development world. I'll run you through our portfolio strategy at a high level. What are we really trying to accomplish? What problems are we trying to solve? Et cetera.
I'll talk a bit about open hybrid cloud. We launched that last year and that really is our guiding umbrella strategy, our guiding umbrella product marketing strategy in, really, how we build our products and really defines the problem we're trying to solve. Each of our products has their own role within that overall architecture to help our customers deploy, truly, open hybrid cloud. So we'll talk about that. And then we had our Summit in Boston 2 weeks ago where we made a series of really big announcements. So I'll walk you through those product announcements that we did at the Summit and hopefully bring it all back and how it all fits together.
So just to really set the context here. We started on this journey, well, about 11 or so years ago. Back then, I think there were about 30 engineers in the company. And if you look at it, right now, we're 2,000 strong, all doing open source technologies across a wide portfolio of products. Everything from design, development to upstream participation, to integrate quality control, maintain, et cetera, spread across multiple continents across the world. In fact, our biggest development site is in Brno, Czech Republic. We have a great talent pool out there. I think the thing to look at this, as well, is we don't have a part of the engineering team that's off doing products over here and then upstream work over here. Certainly, there are some engineers that focus in one area more than the other, but our engineers really work across the whole spectrum of our product. Everything we do goes back upstream, so all of our engineers are involved in upstream development. I mean when we opened the Czech Republic facility, about 6 years ago, that was one of the real guiding tenets that we use coming in. We worked with the universities there in order to bring talent in. This was not going to be a maintenance site, this was going to be a way that we are really going to foster open source development and people there would be working on new development. That, alone, makes us very unusual and very unique in that part of the world and that is one of the ways that the we attract the best and the brightest there.
We're the leading contributor, and I'll talk more about this to the vital components of the stack, at all layers of the stack, I'll talk about that a little bit. You've heard Brian talk about that as well. As you saw from both Jim and Brian, there's hundreds of thousands of open source projects out there. Obviously, we don't participate in every single one of them. We like -- we participate in the ones that we think are significant and core to driving the overall stack. So we'll talk about that. And one of the things that we bring to our partners and customers, I think Brian talked about this as well, not -- I don't want to say consultancy because I don't want -- we do have a services organization, but almost some -- a type of consultancy model working with both our partners and our customers in trying to understand their problems, the pain points for them with our engineers so we can bring that all the way to upstream development.
Just to illustrate that, I mean, this is still the Linux kernel core commit. As you can see, we're still the #1 developer in the Linux kernel, it's very important. As Brian said, we don't set out to say, "We're going to take this hill and we're going to go be the #1 contributor in this particular project." When we work on a piece that we think is important, we spent -- over the years, we spent a lot of time and hired the right people to be able to effect these projects. So from Linux to just recent release of OpenStack, we're the #1 contributor in these 2 places because we think they're 2 very, very core and important things. You'll see -- one of the things that happened with open source, over the years, is, as I was just saying to someone at the break, when we started this 11 years ago, we had to go convince the world that open source was real and secure and enterprise-ready and all of that. And -- the same for Linux, we don't have to do that anymore, it's all mainstream. So you see a lot of other companies out there trying to get on the bandwagon, "Oh, we're going to participate in open source, we're going to participate in this." It's not about the numbers of engineers that you necessarily have working in these spaces, it's about the effectiveness of them, and that's what these 2 things show. I mean, there may be other companies that have more physical people working in one of these places, but there's none that have more effectiveness. And that's what's important and that's what comes from open source, being in the DNA.
What are we trying to accomplish with our portfolio? Now we've really been building this portfolio for a number of years. When I talked at the Summit, a couple of weeks ago, I really talked about 3 things in the last 10 or 11 years that, really, I think, were the defining moments and were really big bets for us. The first was RHEL, right? We took a big bet with RHEL, we changed the model, we changed the open source development model, we changed the technical model of the company. We changed the business model of the company. It's what the world needed to really consume Linux at that time. At that time, there were 15 different distributions of Linux out there, it was tough to get traction in the enterprise because enterprises needed -- they needed a life cycle management, they needed an ecosystem around it, they needed predictability around it and they needed a partner to work with to get their voices heard in upstream. That's what we did for RHEL. The second thing that happened that's now a big part of the portfolio, and we will talk more about, was as we started to get successful with RHEL, some of our customer started to ask us, "Well, this is all great, I'm starting to standardize on Linux and RHEL. But what do I do for my developers, how do I not go to .NET? And so we acquired JBoss at that time.
So it's another big bet for us, it was in the middleware space, a little -- a lot outside of the operating system space. We've built that up into a thriving business and it's a very, very important part of the next generation of computing that we're all calling cloud. It's where the applications -- it's one of the places where the application rides and cloud computing is all about where to run your application.
Hybrid cloud computing is all about the ability to run your application in the appropriate footprint, whether the footprint is bare metal, traditional virtualized, private cloud or public cloud, the ability to run that application across that, with consistent results and consistent behavior for that application across that, can only happen with a consistent stack. Consistent stack, now being the virtualization layer. The operating system and now the middleware layer. That was big bet, as well.
And then the third one was virtualization in KVM and [indiscernible]. And that was -- that's an important part of the current portfolio, as well. The reason why that was a big bet, it wasn't -- we were a large enough company at that time to know we could afford it, it wasn't monetarily a big bet. It was to some extent, but not like JBoss was, compared to our size. It was a big bet because we started as a better technology, a better architecture and we sort of took -- the world was going in a different direction with them, and we sort of backed KVM as that moved into Linux. And some people said we were crazy. But that's what we felt was the right thing to do. We acquired the company. So we could invest in it and could drive it, and KVM is now the virtualization standard for Linux, not just Red Hat Enterprise Linux, but all of Linux. So I also think that was the point where Linux and open source moved from a commodity play to a real innovation play. Now that there was a full stack, out there, from the virtualization layer through the operating system, it gave the development community a real platform to start to build that innovation on. And it's all built -- the innovation and the infrastructure stack today is built on open source. Just look at it. From cloud to big data to OpenDaylight with networking, to OpenStack, it's all built on Linux. Cloud would not exist without Linux. And I think both Linux and virtualization are the pivot points for that.
So what are we trying to do with this portfolio now? We're trying to help our customers build this open hybrid cloud environment. And what that means is, I just said it a minute ago, the ability to run the app across bare metal, traditional virtualized private and public cloud. That, to us, is an open hybrid cloud. We're also taking it to the next level with Infrastructure-as-a-Service and Platform-as-a-Service, and I'll talk more about that.
Jim used most of this slide, about 75% of the slide, on how we build our products. And we build our products from, as I said, hundreds of thousands of open-source projects out there. We get involve with the projects that we think are the right projects to be core of what we're trying to accomplish. We then stabilize those projects and bring those into a development platform, whether it's Fedora or RDO or Overt [ph] or Gluster we're bringing into a platform for developers to build upon. And then we bring that platform into our products. And our products that go into production, where customers want an ecosystem stability, they want a road map, they want a life cycle, they want a company to work with to take it forward.
As we are moving out to cloud computing, we have a very, very interesting portfolio now because there's 2 platforms that are really emerging and are really the heart of cloud computing, Infrastructure-as-a-Service and Platform-as-a-Service. As Brian talked extensively about with OpenStack, with Infrastructure-as-a-Service, it's all about the ability to manage even inside the firewall, it's all about the ability to manage and give parts of your infrastructure to developers as a service. So I want some quantity of compute, I want some quantity of storage, to be able to do that as a service, as opposed to even a virtual machine as a service, that's what Infrastructure-as-a-Service is.
Infrastructure-as-a-Service is made up of technologies like virtualization, guest operating systems and OpenStack, which is the actual services. They are very much tied together, and those are the components that make up Infrastructure-as-a-Service, it's also a component that make up our products as well.
Platform-as-a-Service, that both Brian and Jim talked a bit about, with OpenShift as our version of Platform-as-a-Service, or it's the ability to give developers a platform to go to build to. Whether that platform sits on the other side of their firewall, out in the cloud or whether that platform sits behind that firewall, it's a platform for developers to go to, where they have all the pieces and tools that it takes to build their application. And those pieces and tools are things like app servers that they want to build in, build on top of operating systems, other tools from other vendors like some of the NoSQL databases, other services like that. The ability to build that into an application and a workload that now runs on a virtual -- in a virtual environment. Platform-as-a-Service is very dependent on things like virtualization, the operating system and app servers, which are part of the JBoss portfolio.
The other thing that we're seeing as we've been out with an enterprise-class Platform-as-a-Service offering, we're starting to see customers ask us for more of the JBoss services to be built into this platform, as well. Remember, just like they're doing -- just like customers were doing with the JBoss stack and building applications, they're now using that same technology to build on a complete platform. We'll start to migrate more of those are JBoss services to that Platform-as-a-Service, over time. So we almost take this model to the next level and the next building blocks. And why are we doing this? We're doing this -- somebody just said this to me at the break that with things like OpenStack, with this raw OpenStack right now coming off the trunk, we almost have to be rocket scientists to get it working.
The same as was the case 10 or 11 years ago with Linux. A lot of the first commercial Linux customers are right on the street, right on Wall Street. They had a whole bunch of rocket scientists on their payroll that we're able to piece it together. What we did with RHEL we made it consumable, what we did with JBoss, we made middleware consumable. We're now taking it to the next level with these platforms and making it consumable from the products that we already have, as those building blocks.
So I think that's an important concept of what's happening right now.
Some of the progress in what we've done across these initiatives over the last year or so, I talked at the Summit about the 3 things that I talked about; RHEL, middleware and virtualization over the last 10 or 11 years, which are pretty some of the defining things that we did. For the last 12 months, we had a busy year. And a lot of what we did over the last 12 months, were enabled, both, by those 3 things that I talked about. We launched open hybrid cloud. And as I said, for us, this is really a roadmap of how we build our products, how our products fit into higher-level solutions to solve those real problems, such as problems that are solved with Infrastructure and Platform-as-a-Service, such as the management of open hybrid cloud to be able to traverse applications across those 4 footprints, et cetera.
We not only launched it, we backed it up and acquired a company called the ManageIQ. ManageIQ was a small company that we're building some of the aspects of managing those hybrid clouds as we were. The good news is, we were concentrating in one area. They were concentrating in another area, we're completely complementary. We brought those -- we brought that small company into Red Hat, and their technology is what makes up a lot of the second generation of our CloudForms product, CloudForms V2.0 that we also launched recently.
FuseSource and Polymita, as Jim talked about, this strengthened our current middleware portfolio. Our current middleware portfolio is still growing very rapidly and solving a lot of our customer problems. This is the same middleware that's going to find its way to our PaaS platform over time. So we acquired 2 small companies out there to strengthen that portfolio, to fill in some holes that we had.
Gluster. We launched our storage product last year into the enterprise market. Previous year, we acquired the company of Gluster, again, a small company, a storage company that both Brian and Jim talked about. When we acquired the company, it's a very small company, we spent the first year building it up, beefing it up on the engineering side, beefing it up on the go-to-market side. Last year, we launched a product out there with specific use cases. We're mainly focusing around storage for big data and storage around an OpenStack environment. Specific use cases out there, we're not trying with Gluster to be a full complete storage vendor. We're concentrating on the use cases that really, really complement the storage side of what it takes to be in a hybrid cloud environment. That's where our focus is on that.
And we launched OpenShift, on-premise OpenShift. The prior year, we had put a free service out of OpenShift out into the cloud for developers to work upon. When we first did that we had really had no intention of building a product out of that. That was for developers out in the cloud. We had so much demand from developers and from our IT customers to bring this on their premise. We launched it as an on-premise product last year, as well. And I'll talk about a bit about more about that, what we did at the Summit.
One of the major, major things I use, I think you should go back. Back here, I talked about our products here in the Red Hat Enterprise, Linux, middleware, et cetera, and where ecosystem is so important. This is the growth of that ecosystem with ISVs and with applications. Having a platform for partners to build upon and know that they have a stable platform, that's going to have a life cycle around it, that won't break their applications or their hardware as they move forward, that they know that as they new -- as they pull a new hardware box, out of the box, the operating system, the other pieces that work on top of it, will just work. That's the ecosystem.
That's what's not only important to partners, its really important to the end user customer. That ecosystem has grown tremendously, as you can see here and I'll talk about that as well. That is one of the key elements of the -- that differentiates our products from either the community platform that we talked about? Or just the raw open source site.
That's one of the things, not the only thing, but one of the things that really makes these open-source products consumable by the masses. I mean with RHEL, right now, we see it -- we have customers in Asia that are asking us to extend our 10-year life cycle to 12- and 14-year life cycle, because once they get applications on, they want it to work. That's one of the things that people pay us for, is the ability to do that.
As we start to bring it all together, what open hybrid cloud means is, and Brian also talked a bit about this, is to focus on the needs of the IT operations people, the developer and the business leader. They're all starting to come together. The business leader has a problem to solve and they need to solve it, and the window to solve it becomes smaller and smaller every time. The developer is under an immense amount of pressure to get an application built, tested and deployed in order to solve that problem. And the IT operations manager has to make it all work, has to manage it and has to take all the risks.
So when we all started talking about cloud a few years ago, and even today, some of the cloud providers will have you think that the whole world is going to move out and be running a public cloud. There might be some cases where that's the case, but at the end of the day, the friction that was starting to really be evident there was between the developer and the IT folks. The developer wants to run cloud because they want to spin up and build their application as quickly as possible, the IT developer, they're on the hook. If they get a security breach, even if that application is running on -- out in the cloud, it's the IT guy that's on the hook for that security breach.
These are the people that we're building our tools to, to manage this open hybrid cloud. These are the people that have to build and manage those workloads. And I talked earlier about our Platform-as-a-Service and Infrastructure-as-a-Service platforms, these are the people that those platforms bring together.
Our Platform-as-a-Service, for example, with OpenShift. When we first -- when our guys first started went out and talking to some of the customers around OpenShift, one of the things that they came back, and I remember this well, they came back and said, "It was a wonderful thing because we had -- for the first time, we had the developers and the IT folks in one room." The IT guys were saying, "Well, yes, RHEL is at the heart of it, I've been running our RHEL infrastructure for some time, I know how to administer it, I know the security hooks in it, I know how to manipulate the security hooks for security." The platform -- I mean, the developers were saying, "It's on -- if JBoss is inside as well, we know how to develop on JBoss, we're familiar with it, it all just works together." That's why coming together like that, with these products and Platform-as-a-Service, that's what we mean by bringing these 2 constituencies together to build better applications in a more secure, faster, more reliable way. That's what we're building around with open hybrid cloud. The ability to build these applications and be able to run them across the 4 footprints that I keep talking about.
So I'll quickly run through, and we can hit more in Q&A, if you like, the announcements we made at the Summit 2 weeks ago. So the first announcement was a dot release of our virtualization platform. And the dot release where we added new features for NetApp support, Symantec support, HP management support, other things. The reason why this is important because this -- the RHEV stack of which this is, the next release of the RHEV stack becomes even more important as we move forward in how we go out to cloud computing, and I'll talk more about that.
The second announcement, and this was a big one because we see this as a way to really get OpenStack, as I keep talking about, consumable by the masses. We essentially extended the RHEL product family. And so we look at RHEL now being consumed in 3 broad ways: bare metal, which is a bulk of what's consumed out there; as high-density with virtual guests; and now as cloud services from a platform perspective.
So we announced the Red Hat Enterprise Linux OpenStack platform where, just as we've done with KVM and integrated KVM, not just us but Linux community, as well, integrated KVM with the operating system, we really see the OpenStack services starting to fall into that same category. We're seeing much more dependency as people want new function in OpenStack that's requiring function at the operating system.
And in order to keep a stable platform for our customers and a life cycle for our customers, doing that together as one integrated platform, as we've all done with KVM, is the right way to do it. So we announced that as an extension to the RHEL platform to again get this out there and consumable by the masses.
The interesting thing about this, Brian talked a bit about the touch points within OpenStack. And those touch points are where we're also building certification programs around those touch points. So we can assure that our partners have a stable product in the customer's environment to bring their products to market as well.
Because it's integrated with RHEL right now, on the compute side of that certification, we can now inherit all the certifications in all the ecosystem that we've been building on RHEL for the last 11 or so years. So that's a very important aspect of this. So now customers can start to consume an OpenStack platform and not have to worry of it just working with out-of-the-box hardware just like RHEL works, for example. And I think that's one of these key attributes, not just the hardware side, but that ecosystem, in general, I think that's one of the secret sauce things of making it work across the masses.
The third thing we announced at the Summit was a Red Hat Cloud Infrastructure product. And what we're doing here is we really see 2 types of virtualization computing really emerging or coming to play. If you look at, for example, VMware, vSphere, our RHEV product competes with vSphere pretty much feature-for-feature. I mean, in some cases, they have a feature that we don't have and the next release we have a feature that they don't have, typical. But that's where we compete, frankly, that's where VMware has the market share, in that type of virtualization architecture. So the type of virtualization architecture where customers are managing by virtual machine, not by service.
So what we've done with RHCI is we've added that stack, the ability to manage by virtual machine. I'm almost calling that -- even though it's not that far down the road since it's been introduced, I'm almost calling that legacy virtualization. But there's still a ton of applications that run in that mode. There's still a ton more that are going to run in that mode. What we heard from our customers early on when we went in alone with RHEV, in some cases, we heard from our customers, "I have a site license from VMware so why would I look at RHEV? But I'd like to look at OpenStack for some of my future applications." That's what we're giving them right here. We're giving them the ability to run that legacy-type virtualization stack with an OpenStack stack, all managed under one pane of glass. And so we've done that for a couple of reasons. The first reason is we think as customers migrate to an OpenStack style of computing, they will still have a lot of that, what I'm calling legacy virtualization type applications to run. We also think, not only from a migration perspective but from even moving forward, I think they'll always have those 2 types of environments to run. Some applications just won't move to an OpenStack type of environment. So now, giving customers the ability to run that as one infrastructure with one pane-of-glass management with unlimited RHEL guest to ride on top of for one subscription price is part of making it all consumable by the masses. And so that's what we've done with this product announcement that we did at the Summit.
The next one was the expansion of that ecosystem on OpenStack that we talked about. Even before we announced the product 2 weeks ago, we've been working on a partner network for OpenStack. Have various levels at that partner network from alliance to premiere to advance to ready. With various aspects to each of the levels, from developer code access, to certification, to joint marketing, et cetera. And from day 1 of the announcement of not only the product line but the ecosystem, we had over 100 partners that are already signed up and in the certification process for these things. So we announced that, that network, partner network at the Summit, and this is something that we're going to grow upon as we go on. This is really, really an expansion of the ecosystem that we've put together over the last 12 or so years with RHEL to cross all the products as they start to now come together in this open hybrid cloud deployment model.
And then the last thing we announced was OpenShift Online public Platform-as-a-Service. I talked, I think, 2 years ago or 1.5 or so ago, we put OpenShift our PaaS platform out in the public cloud as a free service. We then, with customer demand, brought it in as a product behind the firewall. What we announced 2 weeks ago now is this -- is a PaaS service out in the cloud with a business model around it, the business model changed, it's different than what we've done in the past in the ability for customers to start to use these out in the cloud with more advanced services in a business model that -- to pay us for those more advanced services. So still having the free service out there for the base-type development, the things that are needed. But now advanced services and the ability to consume those in a revenue model to match from our perspective.
So this one was really a big one for us because of not only the change in the technology model out there, out in the cloud, but also the change in the business model for us, from an on-premise-only type business model.
And lastly, along with this, we're ready from day 1 with our training, our certification and our services that go with these new products. So someone asked me at the break, or mentioned to me at the break, we now have more to talk about with our customers. We can now go in, in day 1 with these new products and offer all these types of services on the new product for our customers to get started with these. So these have been -- from training and services certification, these have been in development along with the products as we've been on these for some time.
So that was the summary of our announcement. I, sort of, skimmed through this. This took a week and we had great response from the analysts and the partners that were there. But that was the summary of what we did at the Summit 2 weeks ago, really based on a culmination of a lot of the things we've not only done over the last year, but over the last 10 or 11 years since the beginning of RHEL.
So that's all I have, and I think we're going to Charlie, next. Thanks.
Charles E. Peters
Thanks, Paul. It's great to be back in the New York Stock Exchange again. I would note that we look on the stock exchange, I think it's about 7 years ago, it's good to see some other technology companies begin to come to the exchange.
So I'm going to cover several things here, this is sort of an outline. First, I'm going to talk about the business model. The second thing I will talk about, bookings and billings. And I know that some of you have been with us for a while, you know all about bookings and billings. I'm going to say last time we had our meeting here, we had 120 people in the room, today it's almost 200 people. There's a lot of investors who are still new to the story and we actually have some sell side analysts who are relatively new to the story. So if you know all these about bookings and billings 101, bear with me, I'm going to go through bookings, billings, deferred revenue and backlog, we don't want to ground you on that topic. I'm going to talk about growth drivers and then, lastly, I'm going to talk about increased leverage and investment and talk about what we're doing there. You've heard a lot about the investment this morning.
So the business model, Jim talked a little bit about the development model, and Brian and Paul talked about the development model, the open source development model, so don't be confused, that's the development model. The business model is a subscription business model. And as you know, we were one of the early adopters of the subscription business model and software, and it has been a beautiful model that leads to consistent, predictable results. And so I would be a failure if I didn't show you some of these beautiful upward into the right slides which I always want to do.
So these -- you're looking at 3-year growth slides here for revenue, operating cash flow and non-GAAP operating income. It looks like that each of the years, and were talking 21% compounded growth, 22% compounded growth. It looks like it's the same way by quarter. So if you look at the subscription revenue growth, over a long period of time, this goes through some up-and-down cycles. From an economic perspective, we've had strong subscription revenue growth. Just last quarter, we reported 16% growth in dollars, 18% growth in constant currency for subscription revenue. So an outstanding growth rate in a period of time that other people are reporting no growth to negative growth. I would also point out, although we don't have a slide about this, those 2 components to our revenue: one is the subscription, which is today about 86%, 87% of revenue, its a recurring revenue stream, so we focus on renewals and go back after the same customers in the following year; the rest of the revenue is coming from the services business, both consulting and training. And what we have been saying is, over the last year or so, is we have been enabling partners on the consulting side to help us get a broader footprint and sell subscriptions. And so that services businesses has been a lower-growth business than the subscription side.
Typically, in the high-single digits on an annual basis, this last quarter a little bit better than that. But high-single digits services growth rate is what we're aiming for. And so that services growth rate does bring down the overall growth rate. I would tell you, focused on the subscriptions, 94% gross margin on the subscriptions year-after-year and a very solid growth rate.
I love this slide. 45 straight quarters of growth, right through the great recession. We actually highlighted the great recession in there. It's a relatively flat little plateau in the middle of that graph. But every single one of those quarters was higher than the previous quarter. So that is the beauty of the subscription model.
So let me -- I'm going to segue now into bookings and billings 101, there's been a lot of confusion about it, I can tell you there is no GAAP definition of bookings, different companies talk about bookings, they mean different things by it. When I talk to you, some of you mean different things by it. Even billings, in our case, we use a billings proxy. And I'm going to explain to you what that is all about.
So here is the basic set of definitions. Bookings, for us, when we say the word bookings, we mean the total value of the deal. Regardless of the term of the deal, the total value of that deal with that customer. Billings, in this case, our billings proxy. It's revenue plus the change in deferred revenue from the cash flow statement. I get asked all the time, why -- what's the difference between the number on the cash flow statement versus the change in deferred revenue if I just do the math from the 2 balance sheets? The difference is foreign currency variation. The cash flow statement number takes the foreign currency variation out of it, which is why we use it. Sometimes, in periods of extreme currency volatility, we also currency-adjust the revenue, like we did last quarter. But when we talk about billings, we're talking about billings proxy, revenue plus the change in deferred revenue from the cash flow statement, short-term deferred revenue or deferred revenue, generally.
The only way something gets into the deferred revenue is if we bill it. If we haven't billed it, it's not in deferred revenue. So short-term deferred revenue is something that we've billed to the customer, it's going to turn to revenue in the next 12 months. Long-term deferred revenue, we've billed the customer, but its going to turn into revenue sometime after 12 months.
Off balance sheet backlog. It's a portion of the booking that we haven't yet billed, it's off balance sheet backlog.
Total backlog. I threw this in there because SEC definition is a little different. And we -- in our 10-K, you'll see total backlog, it's the total value to be delivered to customers, it's the short-term deferred revenue which we've billed, the long-term deferred revenue, which has been billed, and it's the off balance sheet backlog which has not yet been billed. All that together constitutes the total backlog.
And then, finally, revenue. It probably goes without saying that I need to remind you from time-to-time, we're a subscription revenue company. So the subscriptions we take revenue on a daily basis, starting from the day the subscription begins, and we've delivered to the customer, to the day that it end. And then services revenue, you take the revenue at the time you deliver the service, the training course, for example or consulting, you take the revenue and you deliver the service and you bill it generally approximately the same time that you deliver that service.
So that's the vocabulary. A couple of examples. A 3-year, $3 million deal, I would call that a $3 million booking. So think of it as the customer is consuming $1 million a year in subscription. So that deal is billed upfront, it's all billed upfront. One, you have a $3 million billing, you have $1 million that's going into short-term deferred revenue, $2 million is going into long-term deferred revenue and then, beginning on that first day, it starts ticking away, one day at a time, into revenue.
Same $3 million booking, but billed annually. You have a different scenario. Only the first $1 million is billed, it goes into short-term deferred revenue. The next 2 anniversary payments aren't going to be billed until those anniversaries, so it goes into off balance sheet backlog. At the end of the first anniversary, the next $1 million is billed, it also goes in the short-term deferred revenue. And on the last anniversary, the next $1 million is billed, it goes in the short-term deferred revenue. Long-term deferred revenue never comes into play. So if you want to get a sense of what's happening relative to that mix, look at our balance sheet. So for example, short-term deferred revenue at the end of the quarter we just finished grew by 17% year-over-year, forget currency, but 17% year-over-year. Long-term deferred revenue grew 12% year-over-year, that meant there was more of a mix towards billing upfront and less of a mix towards billing years 2 and 3 in advance. Doesn't say anything about the strength of the business. The bookings could be great, we might have more off balance sheet backlog, which, in fact, we did at the end of the year.
So at the end of February, this is a picture of the total backlog, and you could find these numbers -- they may not be in this tabular form, but you can find these numbers in our 10-K. So at the end of each of the years here, the total deferred revenue is the top line on this chart, below it is the off balance sheet backlog. I usually express that by saying it's in excess of a number, in excess of $190 million, in excess of $200 million, in excess of $280 million, those were the numbers, [indiscernible], each years. You add them together you get the total backlog.
And then below that, I always breakdown on that end-of-year earnings call the portion of off balance sheet backlog that's going to be billed in the next 12 months. And you can see that on the fourth line down in this chart. So, for example, at the end of February, I said $180 million of the off balance sheet backlog at that time is to be billed in this current fiscal year. So if you take that number of total backlog, if you'll go to the bottom chart, then you'll see the growth of deferred, growth of off balance sheet backlog, if you add them together, you see the total backlog number over these 3 years, have been relatively consistent, 15% growth, 19% growth, 19% growth.
So that was bookings, billings and backlog 101, and I'll move on, and hopefully you won't have too many questions on bookings, billings and backlog, at least how the mechanics work.
The next chart here is in terms of bookings by sales channel, how the business is moving through the channels. What you can see here is 2 pie charts, 2008, 2013, the quick method is this, we have been focusing on channel business. We have a pretty good-sized sales force, in order to cover the globe, we engaged channel partners at all level. OEMs, disties, SIs, value-added distributors, a lot of different types of channel partners and we've been focusing on billing those channels. And so we've gone from 53% channel business in 2008 to 62% at the end of fiscal '13. Those numbers vary by quarter. At the end of the first quarter, we just reported, you heard a number of 68%, don't be misled, it's a -- I think it's a temporary variation. You'll find that, for the year, we're probably going to be something about 60%. But generally, we're pushing our business to get more towards channel distribution.
The second item here is the amount of business we do with the OEMs. I've been showing this slide for Analyst Day now for 4 or 5 years. And what you can see is the OEMs, and I'll tell you this, the 7 big ones, it's HP, IBM, Dell, Cisco, and then in Japan, Fujitsu, NEC and Hitachi. Too good business, but well it's an, I think, an overrated concern some years ago that was really, really substantial part of the business. And what you can see is it's been fairly consistent, it's 9% of our total billings proxy for the fiscal '13 year.
So growth drivers, let's move on to the list of growth drivers. I guess, to start with, I'd say the growth drivers today haven't really changed much for the last several years. There's a lot of new things coming, as Brian and Paul told you, which I think are growth drivers for the future, but, overall, the growth drivers have been very consistent. First one, Linux is the fastest growing operating system out there. And we hear a lot and we've get a lot of questions about the UNIX to Linux and what the pace of that migration. What people continue to miss, I think, there's also a Microsoft-to-Linux migration going on. Microsoft has got a far bigger share of that market. And just like in the other products that we sell, we're looking to take share from others. So I'm going to give you some more detail on that.
The second growth driver is middleware. Continues to grow faster than the rest of the business and is doing quite well.
I am going to share with you some more large-deal statistics. The deals keep getting larger. I get asked, why did it keep getting larger? And it's because we keep delivering value to the customers. We keep having new things that the customers can consume. So I'm going to share those statistics with you. The customer base continues to get more diverse. We've -- about 3 or 4 years ago, we began pushing a mainstream adoption initiative inside the company with our salespeople, and what you can see is the types of industries and verticals we're selling to continue to get broader and broader. Free to pay still exists. So most other businesses don't have this opportunity, but we have basically free software in the various categories that we're in that are being used, tested, sampled by customers around the globe. And when they come to a point when they need support, when they reach a certain size or criticality, we get the call and so there's an opportunity for us to get an instant subscription at that point. And we also have been focusing on renewals, both internally and using third parties to help with renewals year after year.
Jim touched on the expanding total addressable market and then both Brian and Paul talked about the various product categories within those markets, also driving the growth. In cloud computing, I want to address -- because I've heard this question probably for the last at least couple of quarters here about, with the public cloud computing, what's going to happen to all the various infrastructure players. And for us, I think, it's a great opportunity.
So let me tell you about that. So here's just a couple of quotes in terms of the Linux trend. The first one's from IBM and I think it's very interesting. Their view is they're beginning to push a lot more with Linux. They believe it's a faster-growing opportunity and we would agree with that. The second one is from IDC, basically saying that UNIX to Linux migration trend remains very strong. There is a lot of installed UNIX still out there today and a lot of installed UNIX to be replaced over the coming years.
This slide shows a couple of things. In the pie chart there, what you're looking at is the view by Gartner of market share. I think this is the dollar market share. You can see the biggest chunk there is, in the blue, is Windows in dollars. UNIX still has a sizable chunk. A more important graph on this page, I would submit, is the line chart on the side there that's showing that Linux is materially outgrowing Windows and our expectation is that that's going to continue. There's another slide I'm going to follow with that's going to -- will highlight that a bit more.
So this slide is actually coming from IDC. And on the bars over there, what it is showing is market share in 2012 and then on the right-hand side is their prediction of market share in 2016. And probably the most important piece of that slide is the gray bar on the bottom showing Microsoft losing 5 points a share over that period of time. UNIX is a very small bar at the top, you almost can't see the numbers, but what you see overall here is Linux, both paid and unpaid Linux, gaining share at the expense of both Windows and at the expense of UNIX.
So let's talk about middleware for a minute. As I said, middleware, from the time we acquired JBoss, which goes back to 2006 until present, continues to grow faster than the base business. We've done a lot to improve our selling. We've done a lot to improve our marketing and frankly, as Paul described, we've done a lot to add functionality to the product to have a full suite of middleware products. And what we're seeing is that the cross-selling of our sales team has really picked up. So this graph is showing and I talk every quarter about the top 30 deals in the quarter. So if you take the top 120 deals in the year and you look at the cross-selling, what cross-selling went on in the portion of those deals that had a middleware component, that's what you're seeing in the red line here.
So roughly 40% of those deals generally have a middleware component. Last quarter, the quarter we just reported, we really had an outstanding quarter. We had 60% of those top deals had a middleware component and 5 of them were standalone middleware deals. So middleware is becoming increasingly represented in those big deals.
Another picture here is of the largest deals. So this the top 20 -- 120 deals that we reported each of those 3 years. And the part of this graph I think that sticks out to me is the light gray bar at the bottom, the declining light gray bar. What that is, is deals that are less than $1 million. So if you went back just 2 years ago to 2011, half of the deals in the top 120 deals were less than $1 million. And you can see in the year that we just reported, only 8% of them were less than $1 million. So our customers keep coming back, they keep growing. We're now seeing $5 million deals, $5 million in up deals. We're seeing $10 million in up deals and they're broadening the categories and the list of things that they're actually buying from us.
Just some more stats on the same top deals from last year. So on the gray bar there, what you're seeing is the numbers of deals in the various categories. Over on the right side, we also talk about, for those deals that are renewals -- for these large deals, they're almost always going to be renewals because they can start small and grow, grow, grow. That renewal rate has consistently been better 120% more than the year before. 40%, as I already said, included a middleware component and the top vertical in those deals last year was financial services. That may come as a surprise. I know that I've seen some reports talking about financial services being weak. That definitely has not been weak for Red Hat. It's -- even last quarter, we had good financial services business.
So a little bit more focused on the top deals, the ones over $10 million. I've got some statistics here in the blue bar. I also have 6 case studies or case studies for each one of the 6 deals that were over $10 million last year that I want to describe for you. But for those deals, there were 6 deals last year over $10 million, the average deal length was 3 years. All of them had RHEL or Red Hat Enterprise Linux, 5 of the 6 deals had some middleware. And for those big deals, they even beat the 120%. It was 130% plus of the prior year. And the other products sold, which was the virtualization satellite, consulting and training.
But this next slide actually has some more specifics. These are the case studies of the top 6 deals. So what you can see here is, just across the top, you have 2 global investment banks and a healthcare provider. At the bottom, you got logistics company, another global investment bank and a SaaS provider. So what I thought was interesting in these 6 case studies of what they bought is that 4 of them involve a UNIX to Linux takeout, 2 involve Windows to RHEL takeout. I don't want to say Linux anymore. It's too general. This is UNIX to RHEL takeout and Windows to RHEL takeout. Two of them took out Windows, 5 of them, as I said, had JBoss. One of them was a SUSE take out. So we're still very competitive against the other variations and, small as they are, the other variations of Linux to paid Linux.
In terms of the customer base, we said for a long time that the big verticals have been financial services, government, telecom and then tech and media and those 4 verticals year in, year out always been in the top 4. And generally, it's been financial services and government in the top 2 spots that's kind of been a horse race. One quarter, one would be ahead. The next quarter, somebody else would be ahead. You can see from this, this is for the total statistics for fiscal year '13. Last year, the top vertical was tech and media, next was financial services, government was third, probably the first time they've been in third place in quite a while and we can talk about that in Q&A, if you want. And then lastly, telecom. In telecom, I would now put -- you probably heard me say on the last call, telecom/hosting/public cloud provider, because it's going to be kind of a munged vertical there but those are the top 4. But in addition, you now see manufacturing, retail, health care, energy, services, logistics and transportation. It's getting to be a long list of other types of industries and companies that are buying our products and services.
Now let me get to the question about the cloud. How does Red Hat make money in the cloud? Is it an opportunity or is it a threat? And let me tell you, I think, it's clearly an opportunity that in each of the things that we do, we are offering something that is useful to either private companies that are running a private cloud or public cloud providers. I mean, an interesting statistic which I believe I mentioned on the last call is that 2 of the top 30 deals last quarter was involved selling infrastructure to public cloud providers. And so that was good.
So in this particular slide here over on the left-hand slide in terms of private cloud infrastructure and management, we sell the entire portfolio to people who are building private cloud. This is a basic enterprise. And you heard Brian talk about PayPal. Just last week, stood up and talk about their use of OpenShift to add sort of one of the newer technologies to that list. We also have something called the cloud access program, which is, buy a subscription from us, run it in your own data center if you want to, that same subscription, move it to the cloud. We've got examples of at least a couple of customers bought a thousand subscriptions and moved into a public cloud. We don't really care where you run it, but we do want you to have a subscription. The third one here is the public cloud infrastructure. We sell infrastructure to public cloud providers. The 2 of the top 30 deals last quarter were in that category.
And then lastly, in terms of the certified cloud providers, we have over 30 certified Public Cloud providers, why? For the same reason Paul talked about the certified ecosystem on RHEL, it's important to have a certified cloud provider knowing that your applications are going to run in whichever public cloud you choose the same way it would run in another one, if it's certified, or in your own infrastructure, if it's certified. And for these certified public cloud providers, we've got a good relationship. They may be selling instances, virtual instances of Red Hat in those clouds. And generally, the arrangement there is that we're paid by those providers on a monthly basis for instances that they run in the cloud. I have said recently that if you took the payments from just one of those cloud providers, those monthly payments and annualized them, every quarter, they would be in the top 5 or 10 of our top 30 deals for the quarter. We don't do that, they pay us monthly. We don't include them in the big deals. But that's where they would stack up if we actually did it that way.
So the cloud for us, we view as a great opportunity. One in which we can sell to existing customers to build out their existing infrastructure so they can build private cloud. We can sell types of our technology to the public cloud providers for their infrastructure and we can also benefit from their sales of Red Hat in the cloud to their third-party customers.
So the last part here is just increased leverage and investment. And what I want to say is there's a trade-off between leverage, meaning going higher in operating margin and investment. And what you heard that morning is a lot about investment, investing in things that probably none of you knew we're investing until recently. Our work in OpenStack was sort of under wraps for a long time before it even became public that we're working on OpenStack. But our choice is to invest both in engineering and in sales because we see growth opportunity. We think we've got a lot of leverage to our model that there's plenty of time for us to increase operating margin when we think that's the right course of action. But in terms of -- here are some things we're doing this year, investing this year. Our plan is to add about 150 people a quarter this year globally. There's no one particular spot where that's going to happen. In terms of functions, however, it's pretty carefully focused, it's engineering, it's sales and then it's support. You'll find, as you did in the first quarter, that G&A is going to be a very small percentage growth all year long, while we fund these other areas.
We continue to invest in OpenStack with engineering and eventually sales and marketing. And we're continuing investments in storage, cloud and the basic and I would say sort of the core of the Red Hat Enterprise, Linux and our middleware. I will also add that international expansion continues even today. We've been talking about for the last several years adding offices in about 4 new countries a year. And this year, this past year, we added new locations, new subsidiaries, new Red Hat presence in 3 countries. Today, we have approximately 80 offices, we're in more than 30 countries. We are well-represented globally. We certainly aren't as broadly represented as some of the really larger companies, which is why we're investing in our Channel business. But this is another form of investment, which really shows up in the sales and marketing line generally.
And to wrap it up, first of all, I think it should be apparent from the results that we have been reporting quarter after quarter after quarter that we have a proven recurring business model. Our customers don't consider us any longer an acceptable alternative. Businesses are looking to us and open source as the default choice. The growth that we have continued to put up and the disciplined investment we have chosen when to invest in R&D, when to invest in international sales, when to add more salespeople. That has been a plan and it's lead to consistent growth.
The innovation that we're showing I think should be pretty clear from all that Brian and Paul talked about. The strategic position we have in the data center at this point in time is also clear. The multiple growth drivers that I've talked about, as I said, have been consistent. Really for the last 4 or 5 years, I don't see that changing and we are continuing to invest.
So with that, I would like to call the other guys back to the front here and I think we're going to turn this open for Q&A. Okay. And we have about 30 minutes according to Tom.
These chairs are much more comfortable than those.
Mark R. Murphy - Piper Jaffray Companies, Research Division
Thank you very much. Mark Murphy, with Piper Jaffray. Paul, I wanted to start by asking you, you said, you have 2,000 engineers. Can you approximate how many of those are dedicated to OpenStack at this point? Or if not a fair way to look at it, perhaps what percentage of your total R&D budget at this point is directed to OpenStack? And I have a follow-up.
Paul J. Cormier
Yes, we probably don't want to go down that path. You got to look at -- it's kind of irrelevant, I mean, because as I've said, it's really about the effectiveness. And I'm not trying to be cagey, it is a significant amount of engineering talent that goes across engineering, test and development, content development, support, across all of that. It's -- I think the most significant thing is we're the number 1 contributor to OpenStack. And I think inheriting a lot of what the ecosystem, all of the ecosystem we're getting from RHEL, that's wrapped up in it as well. Because if another OpenStack provider comes out, they're going have to try to re-create that. We spent 11 years. So to just give you the number -- I just don't.
Charles E. Peters
I'll be more direct. That's not a number we're going to give. There's a sizable number of engineers. But that's not going break it down like that.
Paul J. Cormier
That's a good point. I don't really want Charlie to know.
Mark R. Murphy - Piper Jaffray Companies, Research Division
The more important part of the question, Jim, I was wondering you could address this. Given that Red Hat now is surprisingly the number 1 contributor to OpenStack, does this fundamentally give you the ability to steer the future direction of OpenStack in the way that you can do that with Linux, with KVM and with other areas that you're in? And if so, what direction do you want to take it? Do you want to take it more towards storage? More towards compute? More toward networking, so on and so forth? And then the part for you that, just if you look 5 years down the road, where do you think the biggest profit pools around OpenStack will exist? Do you think -- could we fundamentally look at Red Hat and say, we associate OpenStack with Red Hat more than any other organization in the world?
James M. Whitehurst
I'll start and then actually I'm going to pass it over to Brian who can talk a little more. I think steer is too strong a word. I would say influence is a better word. I would think, given that OpenStack in what people want to do with OpenStack and the fact that we'll be working with enterprise customers in cloud providers on OpenStack, the direction we would like to see it go is the direction the community would like to see it go. So we'll clearly influence some direction, but I think there's going to be general kind of movement of direction where customers want to take, whether that's from us or others. Yes, I don't think we'll see a lot of conflict. I think we influence the direction of Linux, but I don't think they're generally -- [indiscernible] technical conflicts here and there amongst engineers. But the general direction, I think everybody's going to want to go in a pretty similar direction. In terms of exactly how we will make money off of it obviously, we think that for projects like this, we have a massive architecture participation around it. There's a clear need for a Red Hat to create those long-lived stable versions and all the other things that we do around Linux for others to plug into and help enable the broader ecosystem around it. And so the business model around OpenStack will look very similar to the business model it for us around Linux. Exactly kind of how that and what direction that goes, this is part of being in an open source community. We don't fully control that.
Let's go to the next question because we got a lot. We only have 25 minutes and lots of questions.
James M. Whitehurst
[indiscernible] 30 seconds.
To be honest, operational reliability is probably -- computing storage is sort of mandatory. Network will follow over the coming years. So we're not trying to accelerate that. And that only really matters if they really get to a larger scale. And right now, [indiscernible] it's early. So you're not into the 10,000 scale yet. But our focus is not really around influencing all the operational reliability aspects across every project.
Stewart Materne - Evercore Partners Inc., Research Division
Charlie, Kirk Materne with Evercore Partners. Just really quickly. Based on your comments around billings, it seems that the long-term deferred number is starting to become a little bit less relevant in your view in terms of being a proxy for bookings to a certain degree? I guess if that's the case and you don't want to get bookings on a quarterly basis, should we be looking at short-term billings as a better metric just using the short-term change versus the total deferred change as a better metric for trying to gauge the health of the business? And then just if I can ask one really quick one for Paul, when people talk about sort of the public cloud for you all and the risk around that, there's this idea that, as they develop net new applications, they might choose free versions of Linux for the Public Cloud. But could you just talk about the importance of sort of application consistency and the consistency of the OS? If people are thinking about both a hybrid cloud having a consistent OS and [indiscernible] those apps.
Paul J. Cormier
Want me to do that one first? You want to do this?
Charles E. Peters
In terms of the bookings and billings question, I've never believed that bookings is a good useful metric, which is why I don't ever provide booking statistics, and we only talk about the off balance sheet backlog at the end of the year. And I do think that to your point though that long-term deferred revenue is becoming less relevant, we like to see growth in long-term deferred revenue. We don't mind if customers want to pay us years 2 and 3 in advance, but I do think focusing on the short-term portion of deferred revenue probably is more useful for what you do. A lot of people do just that. So I think that's probably okay.
Paul J. Cormier
And to follow-up on the second. The hybrid cloud is shaping up to be deployment model that's most likely the one that's going to happen, and you hear that from not only us. You'll hear it from Gartner and IDC and even the other vendors as well. Applications run on operating systems and app servers. And it only makes sense that if you want that consistency across those 4 footprints that I keep up talking about, virtual, virtual -- I mean physical, virtual private and public cloud, you have to have a consistent stack. And that's where that theory comes in and that's why people want to run RHEL in the cloud just like they run it on-premise, because they can afford to move their application there and have 50% performance degradation, or have it not work at all maybe. So that hybrid cloud is the key to that and that's how it seems to be shaping up.
Ross MacMillan - Jefferies & Company, Inc., Research Division
Ross MacMillan from Jefferies. Jim, you started at the beginning saying that Red Hat really thrives in areas where there's incumbent technology and there's incumbent charge of premium. OpenStack and the whole cloud movement is very different from that. And it's a 3-year project and things are changing very quickly. How do we reconcile the 2? It sounds like it's a long way from monetization for Red Hat on OpenStack. That's number 1. And then number 2, Charlie, how confident are you in the fact that OpenStack does seem a ways off from monetization that the core assets, RHEL, middleware and so forth can sustain rates of growth that you think are analogous to what we've seen, let's say, over the last 3, 4 years?
James M. Whitehurst
Well, I do think we have a foot in 2 worlds, right? We commoditize the old world, $40-something billion TAM. Even if it's not growing, it's a $40-something billion TAM between the operating system, middleware, and the component of the stores that we play in and management areas [ph] that we're currently and virtualization. So areas that we're currently in are large and we work to commoditize those. However, this new world is generally built around open source and so obviously, enterprises who built their entire infrastructure on us or coming to us and saying deliver this to us. And so we think there's developer infinity, and so kind of top-down from developers with the OpenStack -- or OpenShift and what we're doing there and kind of bottom-up from the operators looking for a Red Hat as OpenStack. We're obviously the logical people to play that role. And so those are newer areas and so less visibility on -- is it 1 year, is it 18 months when the OpenStack start to turn into real dollars? So no, it's very different than we go into the distributed data caching product that we did which competes with Coherence [ph]. And you know kind of what that sales cycle looks like. These are some of the things that are a little bit newer but inherently our model works just as well.
Charles E. Peters
So in terms of the growth rate, as I said, at sort of the end of my presentation, I think the growth drivers remain intact. So we feel good about that. Things like OpenStack, OpenShift they're coming down the road. We've been trying to intentionally make sure people keep their expectations appropriately low in that regard. We think it's going to be great stuff, but not any -- not this year. The overall growth drivers look solid.
Paul J. Cormier
To just to add, just to emphasize, the new platforms, we talked about whether the infrastructure platform is a service or OpenStack. They're built from the core components to fit the core component that live in their own world, as Jim said. I mean, our middleware offering is a huge part of the PaaS platform but the biggest driver of that is taking out the entrenched proprietary guys in the middleware stock scenario.
Kash G. Rangan - BofA Merrill Lynch, Research Division
Kash Rangan with Merrill Lynch. One question that I get those is, is Red Hat still a growth company or is the growth maturing? And I'm wondering if you could talk to the RHEL 6 cycle. You surprised us with your billing's acceleration as the cycle really got going. And there were fewer things that helped you. You got an ASP uptick, you got the JBoss attached, you got the RHEV working for you. So we look at the cycle ahead, where do we think -- if you're going to be surprising us, where do you think you're going to be surprising? Is it going to be in the RHEL stack or things outside the RHEL stack? And how do you handicap your chances doing more what you've done before, which is deepening your RHEL business versus getting into new opportunities? What are the risks and challenges?
James M. Whitehurst
I'll start. So RHEL continues to grow nicely. And we've talked about there are a lot of drivers there. Without a doubt, the JBoss portfolio is growing faster. And even off of a substantially larger number than it was last year and the year before, it continues to grow very, very nicely. So when you start trying to thinking about the relative contribution to growth in absolute dollars, the middleware portfolio continues to become a larger and larger because the growth rates continue to stay substantially higher and it's a bigger number, right? That said, there's RHEL continues to grow very, very nicely. I will tell you, it's a more balanced growth. When JBoss was sub-$100 million, even at high growth rate, the absolute dollars wasn't enough to move our growth rate substantially. Now that it's bigger than that, right, all of a sudden it really is the second leg of the stool in helping drive growth. And then obviously, things like storage and virtualization for us are newer so the growth rates look astronomical but they're on such tiny basis, they don't move the number overall. So say, there's still a lot in RHEL, but it's a much more balanced growth if you looked in absolute dollars across the components of the portfolio.
Edward Maguire - Credit Agricole Securities (USA) Inc., Research Division
Ed Maguire from CLSA. A business model question. Paul had reference that with OpenShift, you're starting to employ a slightly different business model. I wanted to ask if there were any other areas in the portfolio where you were considering pursuing different models. And Charlie had also provided some color around the revenues that you're getting from cloud service providers. Would there be a point where you provide a little bit more granularity around this?
Charles E. Peters
So in terms of business model, I think Paul has common about -- we now allow developers to buy it with a credit card. It's for the online version. That is different. And at the moment, I'm not anticipating anything else by credit card like that.
James M. Whitehurst
Well, for us, Platform-as-a-Service is our software-as-a-service. So yes, that's a SaaS model, right? People are paying us and we're providing that infrastructure as a service. We get asked by customers a lot whether it is performance data monitoring other things. We'd like to see that as a service. I mean technically, satellite, we sold it as a subscription, but a lot of that is as software-as-a-service. Are there other options to continue to expand that? Maybe. As we add features and functionality to satellite and platforms and those things, will some of that be consumed as a service the way OpenShift? Yes, maybe, but it's not -- I wouldn't say it's a major.
Paul J. Cormier
Maybe not such a drastic space, but each of the -- the product lines have slightly different pricing models. One is by core, the other is by socket, right? And so because we're competing in -- as we talk about the earlier question, we're competing in each of its own markets and so we price it to compete there. But as we start to bring them together, we have to blend that as well. So OpenShift is a perfect example. One was by [indiscernible] was by socket. We blended it together as 1 price. So you'll see some of that as our products are really put together to make more solutions so we can make it easier for our customer base to consume.
Charles E. Peters
Second part of your question, I don't see us providing any breakdown about cloud anytime soon.
Matthew Hedberg - RBC Capital Markets, LLC, Research Division
Matt Hedberg, RBC Capital Markets. As a follow-up to Kash's question on RHEL 6. Obviously, it was a very strong release for you guys. I guess I'm wondering, with the pending beta of RHEL 7 later this year, what percentage of your install base is currently on RHEL 6? What type of customers, are they bigger, smaller? And then how you do think about the adoption on the RHEL 6 with the pending release of RHEL 7?
Charles E. Peters
I don't have it. I have some rough. I mean less than 50% of RHEL is on RHEL 6 today and we still have customers on RHEL 5. We have customers on RHEL 4. And as -- I don't know if it was Brian or Paul, one of them said we have customers in Asia asking for 13-, 14-year support on some of the product. So the nice thing about a subscription is that as long as you're a paying subscriber, you can move to the next version whenever you want. So the fact that someone may be on RHEL 5 today, not RHEL 6, when RHEL 7 comes out, if they want to move, they could either move to RHEL 6 or RHEL 7 at that point.
James M. Whitehurst
One just quick comment, one of the big value that customers see is, because we don't charge you differently to upgrade, if you're a subscriber, you're subscriber. We don't stop providing features and older releases. So the big difference between RHEL 5, RHEL 6 and ultimately RHEL 7 is we re-baseline on the new kernel, right? So we break binary compatibility basically. And so for a lot of customers who are fearing RHEL 5, it's not like we're not adding features as we get to 5 2, 5 3, 5 4 or now 3 4 5. We'll continue to add features. So there are some features you can't add until you put in a new kernel. But for most customers, they're still getting a new feature stream in a way that software companies typically don't do because when you sell upgrades, you don't put new features in the old release. You put them in the new release. For us, we're happy to put features in the old release as far as they don't break binary compatibility. So we get it much more distributed across the various versions because customers, if you don't need a specific thing associated with re-base-lining a new kernel, why go through the hassle of upgrading?
And we're actually seeing the same patterns to moving sort of like at RHEL 6 compared to RHEL 5. The same new release [indiscernible] moves through the middle. And so we're seeing RHEL 5 still dominant and we're seeing that same sort of adoption rate RHEL 6 is 2 years in, right? So we're starting to see usually around 3 years in, it becomes the majority of the deployment style. And we sort of see the same thing with RHEL 7.
I'll take the bait and address the gorilla in the room. Perhaps you could talk about the incongruity between your video and the announcement between Oracle and Salesforce.com. [indiscernible] we saw this morning in terms of Salesforce saying they're going to use Oracle. Next they're going to use their engineered systems. How does that fit what we saw on that video.
Charles E. Peters
I would say, I was taught early in my career not to believe everything you read and always question the source. The source of that was 1 company. They talked about ExaData. We are aware that in a transaction there with Salesforce that there was an agreement that they would try out some ExaData, which of course runs Oracle, Linux. So I think that's the -- that is the understanding we have, that they run Oracle, Linux on ExaData, which is accurate. I would also say, if you have a question you probably ought to call directly to Salesforce and ask them.
Scott Zeller - Needham & Company, LLC, Research Division
Scott Zeller, Needham & Co. I wanted to ask about the way you look at your guidance and taking share, as you said earlier in the presentation. So most of us are -- talk quite a bit about UNIX to Linux. But when you talk about Microsoft, when you think about your guidance, how much of the taking share from Microsoft factors into your guidance? And can you talk about how that has changed in the past few quarters.
Paul J. Cormier
It's very hard to be precise about how much of the guidance relates to it. But what I can tell you is that if we look at the deal statistics quarter after quarter, most quarters we have had a couple of sizable deals that have some portion of a Microsoft takeout. You saw in the statistics I put up of the $10 million deals that 2 of them had a Microsoft takeout. They're the largest deal we did in the first quarter a year ago. It was a complete rip and replace. This was more than a -- it's an 8-figure deal, a complete global Microsoft takeout. So it's going on. Sometimes it's a lot. I just mentioned those the big ones but a lot of times the smaller instance than that. It's built into the overall sales pipeline. So I can't -- until the deals are done, I don't -- specifically, when I'm doing a forecast or guidance, say this much came from this piece or that piece. I can just tell you it is happening and it's happening more frequently now than it has been and we're encouraged by IDC's forecast. We believe it's probably accurate that they're going to lose 5% share over the next -- I think they were showing 4, 5 years from 2012 to '16 or '17.
James M. Whitehurst
And just one quick comment, most of our share take versus Microsoft isn't now, and won't be in the future, rip and replace Microsoft. It is winning the new workloads. I think if you ask almost any customer where your net new workloads go, the vast majority are going to Linux, and that's really where the share take happens. When we do get, and we have a lot of big customers and they end up being big deals because there's a lot of windows out there of the share literally rip and replace. But the vast majority of this is, we just win the new workflows.
Steven M. Ashley - Robert W. Baird & Co. Incorporated, Research Division
Steve Ashley, Robert Baird. I wanted to ask about the middleware business. Just wondering if you could give us some maybe subjective commentary around the mix of that business between new deployments and what might be replacement business. And if you're saying that change, are you doing more replacements as a percentage or part of that business? And just would love to hear more about that.
Paul J. Cormier
Yes, I mean, I would say that the bulk of it, I mean the bulk is somewhere over 50%, is new business, but more and more we're seeing replacement. We see bulk with a leaning towards new business, but even as we interview candidates from some of the other companies' middleware businesses, they always tell us that we see you guys everywhere. So it's a much easier decision on the new project to go with a different stack. It is a longer decision to rip and replace. But what I can tell you, it's getting to be more and more significant. The typical life cycle is the company will say, "I am going to use JBoss for some departmental deployment to make sure it works." So I didn't say, "I'm going to use JBoss for all my new work loads." And then they will often say, okay, let me, as I march forward slowly, kind of do the rip and replace of the proprietary alternatives out there. It rarely starts with a rip and replace, and so that kind of -- so when you do these deals and they're growing, it's hard for us to exactly say how much of that's replacement versus new, but that would be the normal life cycle. And those, by the way, can start to become really big deals.
Raimo Lenschow - Barclays Capital, Research Division
Raimo Lenschow from Barclays. Just going back to the public cloud service providers, can you talk a little bit about what you see in terms of supported Linux by you and unsupported Linux by them. And what are you seeing what was driving the dynamic in terms -- at the moment, is it the customer kind of forcing the service provider to kind of be on a supported Linux edition? And do you see that going forward as more and more workloads are moving over to the public cloud.
James M. Whitehurst
I'll start. And Brian, you may want to -- I can't imagine any random developer going to Amazon in day 1 saying report [ph] my credit card and pay for RHEL. So the vast majority of the usage on Amazon for somebody going there and using our workload is going to be some free variety. Is it going to be Ubuntu, Sintoc [ph]. I don't know, I really don't care. It's not the world we play in. Where we play is when enterprises start to say, "I want to run workloads in the cloud." And most enterprises don't want to be ultimately locked into anybody anywhere. And so they want to run a common infrastructure often what they're running in their own data center. Now cloud providers, in general, are looking at enterprises saying, I want take share from the traditional data center. But in order to do that, they need to have RHEL certified on the cloud. Because there's a lot of work to be done and push up dates and other things to actually certify it on the cloud. It's not just a commercial agreement. There's engineering that goes along with it to make sure we feel comfortable certifying it. So -- but generally, cloud providers really want it because they look at that as a vehicle to take real production workloads from enterprises and bring them in. So the dynamic is much more -- as enterprises want to use cloud, they want to use RHEL and pull it in. It's almost never what you have, what you think of as the bulk of Amazon today, where developers go and develop something. I'd say almost never they're going to use Red Hat. But you wouldn't expect that in a developer in a traditional enterprise unless they have any [indiscernible] do that either.
Abhey Lamba - Mizuho Securities USA Inc., Research Division
Abhey Lamba with Mizuho. Charlie, you mentioned about the government vertical, is there a pent-up demand in that vertical, given that we've seen some slow down over the next few quarters? Is that kind of business not going to come back? And then -- we were talking about OpenStack. Clearly, that part of the technology is going to be forked [ph] at some point. What is going to be that hedge strategy in case of forking [ph] of OpenStack.
Charles E. Peters
First part of the question about the government vertical. Yes, Q4 and Q1, the government business that we saw was fairly weak compared to our expectations. In hindsight, looks like it's pretty consistent with what everyone has been seeing in that vertical. I did say on the most recent call, however, that the pipeline, the government pipeline for us at least for the quarter right now and it's considerably better than what it was last quarter. So whether that's pent-up demand or just the normal seasonality I'm not sure if the U.S. federal government businesses should come back pretty considerably in second quarter. I think there probably is some pent-up demand. What has been going on, as you know, most departments have been not sure if they're going to spend, some confusion around budget. They're coming now to the budget year end, end of September. What they have has been -- it's pretty darn clear and they all worked hard to spend whatever they can spend by the end of September. So for us, we'll have some bump in the August quarter and maybe some positive spillover into the month of September.
James M. Whitehurst
Yes, I mean [indiscernible]. I think the opportunity out there is large enough where you should expect, right, that there's going to be many people competing for OpenStack dollars. Even at a distribution level, it can only make sense. And I think some of the FX had a good world for us to play in, right? I mean I think that was really to land [ph] the Linux and kind of -- still is that hundreds of Linux distributions in the early days. It's hard to sort of top to 100s any more. But sort of -- that's sort of the natural state of open source adoption is that big spaces get fragmented and then they consolidate because there's really not a value in a lot of one-off distribution. So I think we sort of remain as probably the single largest independent ISV that's behind open tech today that is swift enough to bring a really balanced ecosystem. So I think that's going to be our strength.
One more question?
Another big question aside from the Oracle announcement that came out today. Just has to do with the fact that everyone's really scared about infrastructure software providers today. And just the concern over the move to hybrid and public cloud and the impact that could have on pricing and AWS. People can go out and look to see what it might cost to do a CentOS distribution or a RHEL distribution. Can you guys kind of share with us what your thoughts are on the impact of the movement to public and hybrid clouds as to what that does to infrastructure software company pricing going forward?
Charles E. Peters
I would say that, at least from a pricing perspective, you should be able to see from my numbers to this point that it's been very consistent. 94% gross margin quarter after quarter and...
Paul J. Cormier
I'll start. I think this is a big negative for enterprise software companies in general. But frankly, Red Hat entering a category is a big negative for them anyway. In the same way, we work to commoditize categories. I think you'll see clouds work to commoditize whole services, right? And so what does that imply for our pricing long-term? And frankly, we've been commoditizer going forward. We brought price points down a lot. I don't know, it could bring that down further maybe, maybe not. I think we've already kind of set that low bar across the categories that we play in. So when we kind of look and we look at the economics around it, we haven't seen a lot of pressure from our customers saying, "Ooh, this price looks out of whack with that in a way I'm sure a traditional licensed software company would." I think over time, certainly it will. I think the biggest though pressure comes from generally assets they're going to move to a cloud are going to be modernized. And when they're modernized, they're going to move off of some of the legacy expensive proprietary stuff anyway. And that's going to be kind of a key driver. Obviously that's a positive for us. But yes, I think overall, for infrastructure software. It's going to put a lot of pressure.
James M. Whitehurst
I also think that hybrid's the key, right? I mean, it's impractical to think people are going to turn the switch and move the entire workload to the public cloud. And the fact that it's going to be a hybrid approach in some applications just will never go there. I think the 2 keys are, it's a hybrid approach. I think the other key is that the IT department wants to keep control even if it's sitting out there. So things like cloud forms are going to help them keep control. And things like stack With RHEL and the app server, things like that are going to help them keep that consistency across the hybrid environment.
Well, thank you, everyone, for attending. Thank you to our panel and thank you to the NYC for hosting us. We will have another Analyst Day at Summit next year. This will be in April in San Francisco at the Bastoni Center [ph]. Thank you.
James M. Whitehurst
Copyright policy: All transcripts on this site are the copyright of Seeking Alpha. However, we view them as an important resource for bloggers and journalists, and are excited to contribute to the democratization of financial information on the Internet. (Until now investors have had to pay thousands of dollars in subscription fees for transcripts.) So our reproduction policy is as follows: You may quote up to 400 words of any transcript on the condition that you attribute the transcript to Seeking Alpha and either link to the original transcript or to www.SeekingAlpha.com. All other use is prohibited.
THE INFORMATION CONTAINED HERE IS A TEXTUAL REPRESENTATION OF THE APPLICABLE COMPANY'S CONFERENCE CALL, CONFERENCE PRESENTATION OR OTHER AUDIO PRESENTATION, AND WHILE EFFORTS ARE MADE TO PROVIDE AN ACCURATE TRANSCRIPTION, THERE MAY BE MATERIAL ERRORS, OMISSIONS, OR INACCURACIES IN THE REPORTING OF THE SUBSTANCE OF THE AUDIO PRESENTATIONS. IN NO WAY DOES SEEKING ALPHA ASSUME ANY RESPONSIBILITY FOR ANY INVESTMENT OR OTHER DECISIONS MADE BASED UPON THE INFORMATION PROVIDED ON THIS WEB SITE OR IN ANY TRANSCRIPT. USERS ARE ADVISED TO REVIEW THE APPLICABLE COMPANY'S AUDIO PRESENTATION ITSELF AND THE APPLICABLE COMPANY'S SEC FILINGS BEFORE MAKING ANY INVESTMENT OR OTHER DECISIONS.
If you have any additional questions about our online transcripts, please contact us at: email@example.com. Thank you!