 Hi, everybody. My name is Gretchen Curtis. I'm a co-founder and CMO of Piston Cloud Computing. This is the Media and Analyst Panel. This is my sixth or maybe seventh summit at this point. A lot of these people on stage have done this panel and have been in the open-sat community for many years. So hopefully we'll learn a lot. So why don't you guys just go down the line and introduce yourselves? Sure. Hi, I'm Lauren Nelson. I'm an analyst at Forrester Research. This is my fifth summit. I write on private cloud and hosted private cloud environments. And I've done a few reports recently on OpenStack. We see an increasing number of enterprise questions on OpenStack. I'm Al Sidowski. I'm a research director at 451 Research. The channel I cover is mainly the service providers. So my interest in OpenStack is obviously how the different service providers are involved. We track a lot of the market sizing. We do a lot of insight on OpenStack and involve for a number of years now. I'm Stephen Elgradian, the co-founder of Redmunk. Redmunk is a developer-focused industry analyst firm. So not surprisingly, my interest is more on the developer side of the equation in terms of how OpenStack is developed, how it's adopted by developers within organizations, how it competes with other developer-focused initiatives, and so on. I'm Sean Michael Kerner. I'm a senior editor at eWeek and Internet News. I write about Linux, OpenSource, and OpenStack. And thanks to Gretchen, I've been on the panel like this three times now. So we'll see how much excitement we can generate this time around. Great. All right, so I have a few questions prepared. And we'll probably go through those. And then around 1130, 1145 or so, we will open the panel up to questions from the audience. OK, so my first question. The topic of a benevolent dictator versus a technical meritocracy has been a hot topic since the beginning of the OpenStack project. And in fact, it came up again this morning in Troy Tomin's talk. So many people have voiced concern that OpenStack is lacking a benevolent dictator. Is this concern valid? And if the process is working and getting better over time, why do some people still think OpenStack can't make it without its own Linus Torvalds? I think this is a question that keeps coming up again and again because in the media, most people don't understand how Linux actually works, which is the bottom line. Mr. Torvalds is not even the maintainer of Linux necessarily. At this time, he issues the releases. He's very vocal on mailing lists, but it's not like it's a go or no go decision on something coming in. If it passes through the code, it's fine. But there's the cult of the founder in the technology world, and that's why it occurs. I think in OpenStack, we have Jonathan Brice at the top level. At the release level, there's Terry who does the same role as Torvalds, essentially. So clinically speaking, we do have a benevolent dictator that pushes things through at the same level. Well, I would also say that I think, frankly, from an open source perspective, one of the things you see over and over is a desire to replicate models that we've seen previously. And as Sean said, the idea that Linux is a benevolent dictatorship is a little bit questionable on substance. But that's the assumption, and we've seen this for years, that the GPL was the most popular license by an order of magnitude for years. And you'd go out and talk to developers and say, why is this? Hey, did you choose this license on its merits? And they'd say, more often than not, well, it's the one that Linux and MySQL use. I'm assuming it's the right one, as opposed to putting a lot of thought into it. So it's not terribly surprising that people look at, hey, this is a different model. There are questions about this. So let's go with something that we think has worked before. The new is always scarier than the old. Actually, to take a little different slant. So I think the question that ultimately is being asked is, can the community-driven model work and the way the foundation is set up with technical leads and PTLs and having elections every release prevent somebody from hijacking the agenda. But what probably needs to be thought about is, as more companies make more money within OpenStack, they obviously have interest beyond possibly just what the community wants. So just as long as the model continues where PTLs and technical community and the board continues like that, it potentially has the ability to succeed without having that one person on the top. But it still remains to be seen if a business that doesn't agree with, do we need to add features or do we need to add stability potentially goes off and does their own thing. But there is a foundation in place to prevent something like that from happening. Yeah, and I'd echo those thoughts. In terms of the foundation today, there's a lot of assurances in place to essentially avoid having one voice carry out across the entire community. But in the same way, a lot of the actual contributions itself are very much slanted on, essentially, some voices are heard more strongly than others. And you definitely get more slants. There's definitely advantages of doing more focuses on essentially hardening of resources versus creating net new projects. So I think there's a good mix today. I don't necessarily think that it's a lacking by seeing a benevolent leader versus meritocracy. But I don't think that it's just a different model. OK. All right, so this next question is near and dear to my heart. So we keep seeing stories, blog posts, and reports bemoaning the lack of large-scale production deployments of OpenStack. Yet the rumor mill and insider gossip tell us that several vendors have a growing number of large deployments either running in production or headed that way. And this, I can confirm to be true. Unfortunately, many of these customers have us vendors under strict NDA. Is this reluctance to talk about large-scale deployments of OpenStack hurting the community? Why are customers so reticent to disclose the details? And how can we break the cone of silence? Well, the thing you hear today about the top question at the last few summits have been, is OpenStack Enterprise ready? There's even a session on it right now. But it's kind of this question of, are you going to be able to run your full production-sized workloads in an OpenStack environment? And if we're not talking about how this is already being done today, is it hurting the community with folks not believing in the initiative itself? Even last week, we had a talk within Forrester on our developer, Mindshare, versus those focusing more on the infrastructure service side, on how prominent OpenStack really is. And there's this kind of debate about, essentially, how pervasive it's going to be, whether it's going to actually extend past just a test-to-ev environment, where it's a fun thing for developers to play around with for a specific application or specific set of resources, but will never carry across over essentially that systems of record, rather than just being a place for those new systems of engagement resources. In a way, it would benefit the movement by having more case studies, more examples. But I think there already are quite a few. There's a number of very large enterprises that have told this story. There's also some public ones that have used vendors to get to this position. I think what's more lacking in the market and hurting the community more is just this kind of lack of information and kind of this need of, well, if OpenStack is going to be enterprise ready, it needs to be a direct distribution that you're using of OpenStack and not through a vendor that, essentially, makes it more consumable. Right now, the biggest thing we hear when we're talking about customers is they want to go to OpenStack, but there's a lack of knowledge on what that will take, essentially. How much engineering power they're going to have to put behind that in order to get an enterprise ready deployment up and going without having vendor expertise or a partner that has gone that journey already. So that's the number one thing I think that is essentially holding back in terms of larger, large scale enterprise adoption. I don't think it's the lack of those coming forward and telling their story. It's more the details behind that. So the short answer to the question is, yes, there needs to be more examples. When people are drawn to OpenStack, what they've told us is that the community, the number of vendors involved and the big names involved and people putting money behind it, that's kind of what has drawn them and created the interest. But they need to see more examples in the wild. There's tons of POCs going on. A lot of people kicking the tires and doing things like test and dev, but to have more at scale production examples from the enterprise community. Everybody knows about PayPal and Mercado Libre and Cisco Webex and the classic examples Comcast presented in a Portland and there's a number of Asian companies at the Hong Kong Summit that presented at scale. The more that can be done with that, where peers can see their competition, Fidelity decides to use OpenStack, Wells Fargo is using OpenStack, so to see more of that will make things easier. Making it easier to consume will obviously make it a lot better as well. Well, and as to the portion of the question that sort of got to why this happens, I think the answer to me is pretty simple. You talk to businesses and most of the businesses that we speak with who are using OpenStack and other technologies, somehow assume that not talking about this is some huge competitive advantage for them, as if by not telling somebody what you're doing, you're stealing some leg up in spite of the fact that this is a publicly available technology. And the irony of that sort of, that fact is that all these companies end up talking to us, the analysts, and then we end up selling them back that information because they didn't wanna talk about it publicly in their first place. So it ends up being this very ironic situation. As to the impact for OpenStack, it certainly has an impact, more of it you can talk about public use cases, the more comfortable customers are. That being said, from my standpoint, the impact is relatively marginal. You have sort of a level of commitment across the board from startups to very, very large incumbents, people who are spinning up very, very large investments on the technology, which tends to give enterprise buyers a fair degree of confidence. So is there an impact? Sure, is it a huge impact? Probably not. From my perspective, just dipping into the historical time banks, the first time I saw Werner Vogels was probably 2003 at a Linux world event in San Francisco. Same time, this is 11 years ago now, people were asking the same exact questions about Amazon. But Werner is an interesting guy, he just doesn't care, right? So with Amazon, I think it was a three to five year timeframe, I think once Netflix flipped it over what 2008 give or take, so we'll call it five years, other people started to jump on, and I know numbers aren't public for Amazon in terms of their financial contributions, but I think it was a three to five year timeframe. When we're talking OpenStack, we're talking now what were three and a half years out from its creation. These are still baby steps. I think the sweet spot is three to five years. So for me, it's just a functional question of time. Large organizations take time to disclose. If we look from the example of Amazon, I think OpenStack is accelerating quicker than Amazon, thanks to the Amazon example. One of you remarked that at every OpenStack summit, you see more and more vendors, and if any of you have been down to the marketplace, I think you'll notice it looks like a real show now. In your opinion, is this a good thing or a bad thing, and is there such thing as too many vendors? Well, I was talking to a colleague this morning and we agreed that the perfect number is probably 42 vendors. Always 42. The hitchhiker's guide to the galaxy, the ultimate question, the answer was 42, so we decided 42 is the right amount. But I think ultimately the market will decide, which is quite simply remains to be seen. To me, I would actually say that it's more vendors is more better, honestly. If you look at historical strength of platform, a lot of that strength has less to do with the actual quality and underlying technology, more to do with the size of the ecosystem that's built on top of it and around it. So it's not to say that more vendors is a sort of unmitigated good in the sense that it becomes more difficult to navigate. It does pose challenges, but the larger the ecosystem historically speaking, the better off the underlying platform has been. Again, just because I think from historical perspective, and you know, open source licensing better than I just do, but there was a period of time about 10 years ago where there was a vast proliferation of open source licenses. Every company and their brother made their own open source license, which was basically a derivative of Apache with attribution or this, that or not attribution, et cetera. There was also a wide explosion of Linux distributions, there still are. What tends to happen though is, you know, the cream rises to the top, et cetera, and there'll be a lot of secondary tertiary vendors and there'll be a core of three vendors, just like there's a core of three licenses and a core of three to five Linux distributions and that'll be it. The other ones will be on the periphery, just like there's the periphery of open source license and the periphery of Linux distributions. I don't think it's necessary, a bad thing, as you mentioned. The market will filter out those that aren't successful at meeting a need within OpenStack. I think the bigger question is making sure that that core is strong and that those that carry the OpenStack label meet a certain certification level. As I mentioned in the keynote today, that is gonna be a key component of moving forward. If everybody's using OpenStack to a certain level and it's very different, it's gonna be very difficult to get to that next stage of having some level of interoperability. So now if you carry that OpenStack label, you need to be able to write to sort of an API connectivity to other resources that are within that OpenStack community. A lot of folks are struggling today in terms of the interoperability question and whether the fact that we have such a huge ecosystem but no two are interoperable and as this label gets more developed, it's going to be a much more connected world where you're going to see that next iteration where it will be a more open space. But I don't think the number of vendors is going to influence whether that's successful or not. What are the top pet peeves of media and analysts? What are the top pet peeves you have when talking to vendors and users of OpenStack? What do you wish we'd stop saying and what do you wish you heard more of? Be nice. Honestly I think, and I'm sure that vendors have their own list of pet peeves in terms of their conversation with analysts, but for me, one of the sort of stupidest and most superficial ones is, everybody wants to come out and say, I'm the market leading this and I'm the best in the world at that, where from our perspective, let the market tell us that. I would much prefer vendors show up and tell us what you can and can't, what you believe you can and can't do, give us use cases and so on. But as far as the world beating and fastest it's just let the, it's kind of like saying, I'm funny, you can't really claim that, you let other people say that about you and I think from a vendor standpoint, I think it's very much the same. My perspective, same thing, like in my inbox this morning, I had I think 21 pitches from PR people saying that they were the first or only in the OpenStack marketplace and it made it seem like it was just them, so that's kind of funny. But my biggest pet peeve when I talk with vendors is in many cases, not in the case of Piston, of course, but a true lack of understanding of how OpenStack works, that there's the various layers and that how there's an upstream and then there's open core and open source. So I think there are some core vendors, I hate using the word core, but there's some core vendors in OpenStack that are core Linux vendors that understand, but then there's a lot of secondary and tertiary vendors who have no clue how OpenSource model works, no clue about licensing and they think just because their API compatible means that they're actually contributing upstream. So that understanding between upstream and this whole marketplace is a definition that certain marketing organizations probably need to learn better. Sure, my big ones on the first or only in one category or another where they've created this very niche market on them being the first and only. The other big frustration is just when they've talked about interoperability as being a key down point of OpenStack, as I mentioned before, as it being whether the actual project itself will be successful and I think that comes from a lack of education on where the initiative, the progress it's come from and where it's going and those are probably my biggest views. So a couple of things, one, everybody should stop using the word ecosystem because it's like way, way overused and it's pretty much meaningless at this point. The second one is using hybrid cloud incorrectly and everybody markets something with hybrid cloud. I think last year at the summit, everybody used software-defined networking like that was the big, every piece of cloud role in Portland had SDN on it and I think I would venture to guess that everybody's cloud role this time has hybrid cloud on it or pretty close. We actually had a briefing once and a vendor suggested that co-location and shadow IT for two completely random separate business functions was hybrid cloud and that is not hybrid cloud but it's, yeah, we did a lot of work around this, got input from a lot of vendors, including Piston Cloud and InterNaps in the audience, a number of people and came, it starts with the NIST definition but it didn't go far enough but it's to deliver business processes seamlessly. It's not just because you have two things. And then finally, the other thing I'd mention is that vendors when they talk about what they have, don't talk about what the product is in the features, but what business problems is it going to solve? It's, you got a distro or you got a turnkey, opens that product okay, but a lot of other people do but what business problems are you trying to solve with that? So I think hybrid cloud opens a big can of worms on what that is because essentially cloud plus anything else. So essentially if you have some sort of SaaS usage and then you use on-premise applications, that is a hybrid cloud of sorts, whether they interact, whether they're connected, push to say that I would say that hybrid cloud is a pet peeve and that it doesn't describe anything because there are so many different definitions on where folks draw the lines on hybrid and not hybrid today. Some folks when they're talking about hybrid cloud, that's fully connected to environments where you can essentially do load balancing between these environments and bursting from one environment to another. Others look at it as unified management, others look at it as two isolated environments that aren't connected but they have the presence of public and private. It just is such a nebulous term that doesn't really quantify to anything yet today. So I'd say that that is a pet peeve and myself just said it is so nebulous and varies so much today. Yeah, I completely agree and most of my confusion is because of VMware's vCloud hybrid service which is kind of sort of both and everything in between. Okay, so this is probably our final question before we open it up to the floor. This is a two-part question, so I'd like each panelist to answer individually and it's okay if there's repetition and overlap. So question one, what is the top reason enterprise customers are drawn to open stack? And the second question, what is the main thing preventing greater adoption? Both together or one at a time? Yeah, I'll go first. First reason is momentum, everybody wants to be on the bandwagon, that's easy. The greatest barrier is a lack of understanding of how it fits in with existing proper enterprise IT systems. Some people are just using it as an overlay but there is more legacy than there is cloud and that transition is something that is a challenge for anybody whether it's open stack or otherwise. Yeah, I would say my answer to the first, I think would be really the open source nature of the platform in the sense that a lot of vendors who originally said they weren't gonna get locked into an operating system, got locked into an operating system, the same customers that said they weren't gonna get locked into a virtualization layer, got locked into a virtualization layer and once you get to the cloud platform layer, they would like to in many cases make different choices. So that to me I think is one of the, when we have these conversations, that's one of the big factors, that combined availability. As far as sort of the biggest, I don't know, what was it the exact wording? The main thing preventing greater adoption. Preventing greater adoption, honestly to me it's questions around compatibility. I came up in the keynotes this morning, it's come up I think every time I sat on this panel, the question of what is open stack? Which pieces do you have to implement? Which pieces can be substituted out? What version compatibility do I need to have to be using the open stack label? That's one of the primary concerns that we hear from folks looking to invest in this over the longer term because if open stack ceases to mean open stack and ceases to mean one thing and you don't have that compatibility, then you're right back down the path of locking that I talked about in the first part of the question. As far as the first part regarding momentum, all the enterprises that we talked to, everybody is drawn to the open stack community based on other people being involved, the ecosystem, the snowball effect of people being involved. Clearly that is why they're drawn, they want to avoid vendor locking the same things that Sean and Stephen talked about. And as far as what's preventing them, I guess so I see open stack kind of like old school oatmeal and bear with me for a second, but in the old days when you made oatmeal, you take that big cardboard canister, you've got to boil water, you put it in the pot, if you cook it too long it burns, it's a mess, you got to add your own stuff to it. What open stack needs to get to is instant oatmeal. You rip open the bag, you throw in some water, it's ready to go. But doesn't the original taste better? The original does taste better but it's a pain in the ass to clean up at the end. So true. So it needs to get like that, orchestration, automation, deployment, it just needs to work a lot easier. People see how many developers it takes to go and build it on their own and I think with Icehouse there's 1200 different parameters now that can be configured, it just needs to be easier to consume. Rip it open, throw in some boiling water and it works. In terms of top reasons for adoption, they've hit on all the major ones, momentum, excitement within the development group of being involved in this large community and ecosystem. And essentially this, avoiding vendor lock in. In terms of barriers. So it's how you look at open stack adoption. So in terms of enterprise adoption through a vendor partner, there's far fewer barriers to that. They make it a lot more consumable, ready right out of the box. I'd say that the main barrier on that side is in terms of support and compatibility of different hypervisors and a lot of those vendors have worked on that to improve that experience as well. If you look at adopting open stack directly, I think it's a use case. So when I look at the private cloud market, I see different types of private clouds. I see those are these pervasive transformational clouds that bridge across their systems of engagement and systems of record. And I see the biggest challenge there is open stack is slow to start up and those initiatives already very slow in moving. So essentially these environments take three to five years to start up using a vendor directly. They're substantial efforts, they have to do policy process, standardization and optimization and adding open stack to the mix makes it very difficult to be able to achieve the timelines they're looking for. If it's a much more targeted open stack adoption, a much more targeted private cloud, one that's more focused on systems of engagement, that's where we see the most and the most targeted usage of open stack today. Where we look at those that are using or trying to build an enhanced virtualization environment where it's all about improvement of IT for virtual machine management, then that's when we start to see those where open stack is not a fit at all. They're looking for just improved management tools where they can look how their resources are acting and looking how they can better load balance and consolidate resources throughout their environment. So I think expansion across use cases, not necessarily to enhance virtualization, but expansion to be more consumable to target that transformational cloud would increase its ability to have greater adoption. And until that time, vendors have made that a lot easier. All right, thanks guys. We're gonna open the panelists up here for questions from the audience. So I believe there's a mic out there in the middle. So if you have a question, I think you can go up to the mic or... Hello, I'm Rania Moser. I am a development manager at Rackspace over in our public cloud shared services division. And I wasn't able to go to Hong Kong. I was at San Diego and Portland prior to that, but this is actually the first summit where I have heard ecosystem being overused. So as much as you guys are like rolling your eyes at it, I would really like to hear more in the development world, the active technical contributors are actually coming and saying, hey, we don't wanna ruin the ecosystem with all this corporation stuff and all this trying to make money and actually be profitable. So if you could expand more on where you're seeing that overused and areas where it absolutely is kind of already been overdone to death, I would appreciate it as a deaf manager. I'll start first. I like the frontier shirt, that's cool. I don't really know HTML, but I figured that one out. Yes. This is part of one of our diversity initiatives at Rackspace. So I was kind of saying it a little jokingly, but just in terms of marketing, it just seems to be a word that is just so overused, but as far as OpenStack's concerned, I think a lot of people can confuse it thinking OpenStack is a product. And it's not really a product. It's a series of projects that come together to build whatever somebody's looking to build and whether that's an ecosystem or not, but I just was saying in terms of, just from a marketing standpoint, just a word that just everybody uses to describe everything nowadays. I think Amazon was the first vendor that really showed how powerful ecosystem could really be, where their marketplace, their ecosystem provides such additional capability and independent growth beyond what they work on themselves that it all suddenly became a focus for a lot of vendors in this space, where ecosystem can essentially provide added value to their customers that they may not have realized otherwise. And OpenStack, I personally don't think ecosystem's overused, where I kind of wonder the boundaries of that is where essentially you're part of the ecosystem in that you support certain projects or support different APIs, the boundaries of that. So are you providing additional functionality? What is that service that you add on that you can't get from the core system itself? And what base level of compatibility do you need to have in order to fit within that ecosystem? But I personally like that organizations are starting to focus more on this ecosystem rather than how much money they can throw at a certain initiative themselves and looking at this innovation that's outside of their own organization. I'm actually gonna introduce some tension into the panel and this is what you're supposed to shoot for as a moderator, right? People arguing with each other. I don't agree that the term is overused and I don't agree that Amazon was the first. I actually like the term ecosystem. I think, certainly in some cases, it's used a little vaguely and non-specifically and that can be a problem. But I think in general, the wider sort of the, as I said before, the collection of projects, both as distributions, but built in and around the platform itself is indicative of success. And to me, it's not, I mean, Amazon certainly is a good example in the cloud world, but as far as I'm concerned, everybody here is still borrowing from Windows, right? All of the lessons in terms of how these platforms play out and the aggregate value of the applications that get built in on top of around the underlying platform. To me, everything is falling from Windows where that was a, it was very, very difficult to compete with Windows for years because you weren't just competing with Windows. You're competing with Windows and all of the applications that went along with it. So even as Linux became more and more technically capable and more and more competitive from a technology perspective, it was still difficult to compete because there'd always be, hey, that's great, but you don't run these five things that I need. You know, they're Windows only. So obviously we don't want an environment in which things are open stack only or AWS only or VMR only or what have you. But by and large, the ecosystem lessons that you're seeing most of these platforms absorb have come from previous iterations of previous platforms. I don't like the word ecosystem because from an open source background, I like the words upstream and I like community because they have real meaning. So if we have an ecosystem partner that is not necessarily open source and is not contributing upstream, are they still really part of the community? The answer is there may be part of the wider ecosystem, but from an active technical contributor perspective, community and upstream are two different things than ecosystem and the technical contributor is absolutely right when they say, hey, that's infecting business and commercial because the ecosystem partners are not always contributing upstream that are always technically part of that open source community. So there's a definitional difference that people need to think about when they're using the words. I'd like to ask, it seems like there's many small camps, small groups of users developing and certainly to implement some of these deployments that I hear about in open stack and I'm kind of curious, does Red Hat's emergence to you help to kind of make this a little bit more of a plain vanilla for folks to kind of more and more folks to really start to use and implement in a broader way? Kind of how do you think about to what degree is the initial adoption kind of fractured little camps and kind of what does it take? Do we need to have something that's more plain vanilla so that you get larger adoption? I'll take a stab at that. I don't necessarily know any plain vanilla, but as I said before, the most important thing to me is, and again it came up in the keynotes this morning, to come up, well hell every five minutes in an open stack conversation that you have, to me comes back to defining what is core, right? Because basically you're gonna want to see different people implementing open stack. They're gonna wanna have their differentiation, they're gonna wanna be different in some way, whether it's services they layer on top or the services they layer on side, but you have to have that confidence to me and this is maybe what you're getting at with a vanilla which basically says, all right, this is open stack. This is the core of open stack. If you implement this, you can use the open stack trademark. This is, you should have some confidence that if vendor A, vendor B and vendor C are running something that they call open stack, that you should have a core set of services and a core level of compatibility that is consistent from vendor to vendor to vendor. And like I said, Red Hat certainly will play a part in that, but all the vendors need to play a part in that in terms of defining, all right, here's the core, all right, everything else, there may be some variability, there may be things that don't necessarily work exactly the same from platform to platform. You look at Java as a classic example here where Sun for vendors to carry the Java trademark had to pass a TCK, a very, very complicated set of test cases and there were things that everybody, WebLogic, WebSphere, everybody else built around it that were different and offered some differentiation from platform to platform, but you had theoretically in some level of compatibility from vendor A to vendor B to vendor C and that's absolutely, in my opinion, what we need to see for open stack over time. It's one of the reasons that we've been pushing for something like a closely defined core for a while. I think where we're gonna see camps emerge is the Red Hat guys have their own world view of how orchestration works. That's why they're talking this morning about CloudForms. If you're a Red Hat enterprise Linux guy you're used to RPM and those kinds of packaging, the Ubuntu's of the world use Juju and Charms and other things, Piston has its own system so I think there's gonna be a couple core systems where people will gravitate based on the tooling that they like. The definitions are all important, but as a user it's the tools that you're used to if you're used to using Red Hat, if you're used to RPM based building tools, you're probably gonna stick with Red Hat. If you're used to Ubuntu and you love Juju Charms which are not a frosty cereal but a really interesting kind of magical treat, then you'll stick with a canonical based distribution and then there's other people that will filter around that. Ultimately the foundation is the one that decides who has a distro. They have a definition, it needs Nova, it needs Swift and some other pieces before it'll bless it as a distro. I think there's eight or nine, the latest being HP Helion last week and they're all a little different. Piston has a turnkey software platform that has some secret sauce in it, it's not 100% open stack. Red Hat says and Mirantis say that they're 100%, but they all at the end of the day fulfill a need for an end user and they want a easier to consume supported version of open stack. So whether it's all vanilla, if that means 100% open stack or not, I think there's a place for everybody and again going back to a question we answered earlier, the marketplace will decide which ones will still be around. Dan Pasek from Red Hat, just an observation because I try to take a real holistic view to the whole space. Given what we've heard from IBM pushing KVM and on Power and KVM on Z and now we have open stack on Solaris, how tightly coupled do you see going forward and don't forget arm and the arm stuff. So how tightly coupled do you think open stack is gonna remain to the x86 architecture and how successful do you think the other architectures may or may not be going forward? My answer to that would be, I think a lot depends on the hardware side as opposed to the software side. And what I mean by that is that arm obviously is progressing towards legit 64 bit chipsets that consume a lot less power than x86 and your sacrificing some performance. IBM touted at, what was your show? Week ago, two weeks ago, Googles come out and made their own power, motherboards and so on. So to me, in other words, I think like virtually every other cloud computing effort, both public, private, open source, proprietary, what have you, it's been all x86 all the time, but that's largely been a function of the success and the performance characteristics and cost characteristics and underlying hardware platforms. So in other words, to give you just an example, if arm is successful at achieving good 64 bit compatibility that can assume reasonable workloads, I think you could expect to see over time, OpenStack move to embrace that, right? Because as more people want to run arm in the data center, I can't see OpenStack saying, the hell with you guys, we're just gonna run x86 forever, right, it's not realistic. But again, I don't think it's, you're not gonna make those decisions in advance of widespread adoption and more importantly, evolution from the hardware side of the equation. That has to happen first, everything follows from there. I think arm in the data center is interesting, but simple reality is Calzada, who is one of the most hyped and probably the most promising, in my opinion. Arm server vendors is now bankrupt, so it's interesting to talk about, but the practical reality is probably somewhat less interesting. I think that might be a function of time though. I think that may have been too early. Unless anyone else has any final questions, going once, going twice, okay, I think that, oh, one more, on down. What is the meaning of life? Hi, Louie de Palma from William Blair. Can you talk about the third party hardware certification process and how that relates to OpenStack? There was something in the news, I think it was three weeks ago, by how Morantis wanted to make the third party process open for the OpenStack community as a whole, to certify third party vendors and I think Red Hat and Rack Space were opposed to having the community as a whole certified because they wanted their individual distributions to certify select hardware. Can you discuss your thoughts on that and how you think that's going to evolve? I'll just give you my two cents. Morantis has their driver log project, which is announced this morning as part of OpenStack Marketplace Driver, so there's third party compatibility for some things and that's open, but you have to remember at the end of the day, OpenStack has to run on top of an operating system, that operating system is either Linux and now possibly Solaris. That operating system should be certified by the operating system vendor on a given hardware, the same as Linux has been certified by the last 10 years. There's no difference, in my opinion, between how Linux has been certified and how OpenStack on hardware should be certified because it's still the same set of distributions. William, that's probably a question more for the foundation to answer. I don't think as media and press where spokespeople for the foundation, but what I would say, though, is that projects that Troy referenced this morning about RefStack and having the ability to have these tests and ability to do better certification on whether it's an API or physical hardware, things like that will help, especially as people look to do federation and be able to use any kind of hardware with OpenStack. I think things like that need to help in, help need to be there and will help the momentum even further. But as far as how it works, that's not really something I can answer. Yeah, and just how the labeling with the certifications go along with that to avoid confusion in the market. I'd say that's the biggest component for those that play in multiple spaces, making sure the certification at each level is clear. Okay, I think that's a wrap. Thank you very much to our panelists and probably see you next OpenStack Summit for another media and analyst panel. Thanks guys. Thank you. Thank you.