 You guys ready? How you guys doing? Thanks for hanging in there. I know it's late in the day. You guys are probably eager to get to your beers. My name's Gretchen Curtis. I'm a co-founder and chief marketing officer of Piston Cloud. And this is the press and analyst industry perspectives on OpenStack. So we did this panel about six months ago at the last summit. A couple of the panelists here are old-timers. So why don't you guys go ahead and introduce yourselves? You want me to start? Yep. Hi, I'm Gary Chen. I'm a research manager at IDC. And I cover server virtualization software and cloud system software, which is what we call stuff like OpenStack. I'm Sean McArna, I'm a senior editor of internet news, which is part of the Quinn Street Enterprise Network. Right for a pile of publications under that name and write cloud application development, Linux, open source, networking, and security stuff. I'm Stephen O'Grady. I'm the co-founder of RedBunk. And probably on the panel because I cover cloud and I know the things. I'm Alex Williams. I write tech crunch. I cover the enterprise and a lot of cloud stuff. So before we get started, can I see a show of hands, how many developers we have in the audience? OK, a few. How about users? People who are here, OK. How about vendors? Vendors, all right. OK, so the last time we did this about six months ago in San Diego, we covered a number of hot topics at the time, including governance. We had a newly formed foundation at the time. We talked about the hype of OpenStack, specifically the high degree of marketing maturity relative to the technical maturity of OpenStack. I believe the saying was the proof is in the pudding. Now where the hell is the pudding? So we also talked about concerns about community infighting, concerns about the involvement of large corporate players with competing interests getting involved too early in the project. But mostly we talked about two things, which was the lack of users and customer stories and the immaturity of the technology. So six months later, Grizzly is out. The foundation is strong. Community is thriving. Governance is working. Hype is still high. But as we saw this morning, we now have a large number of customers using OpenStack in production in lots of interesting ways. So if the proof is in the pudding, I think we can agree we've seen a lot of pudding. So now what? I want to ask you guys, what's the buzz you guys are seeing now overall? Positive, negative, a mix? The buzz is, I think it's still pretty great for OpenStack. There's not a lot to lose at this point. I think just from my observations, it's going, we're moving closer to what will become, I guess, somewhat of a horse race. But there's going to be so many different kinds of clouds up there. I'm not sure what kind of horse race it's going to be. Much more focus on money and how VMware is going to get this place. So I think I would agree with most of what Alex just said. I think from my perspective, I think that the buzz, or at least the important buzz, is on the continuum of the project. And certainly we've heard from some users this time around, or at least more users, which is a good thing. I think the really the question, or the buzz around the question that I hear, still concerns fragmentations, still concerns the number of competing interests and agendas. Because one of the things that's beginning to happen that you see is that a lot of vendors, and even a lot of their customers, are beginning to understand the stakes involved. Which is, look, if you do not have a credible strategy, you do not have a credible vision of where things are going from a cloud perspective. And more importantly, you're poised to get there. You have a serious problem. And therefore, we're seeing vendors scramble to find their footing. And that will make for a very interesting environment in the OpenStack community moving forward. I see the buzz, and I agree with everything that's been said so far, so no arguments yet. I think the buzz is even greater now. Six months out, if we did a Google Zoom case and somebody in here probably can in the next five seconds. The volume of OpenStack stories that I've seen in the last six months increased. I have not spoken to anybody about cloud in the last 180 days in which OpenStack was not part of the conversation before it might only have been 80%. And the risk that I see as people talk, and I know we might talk about interoperability or security or other things, but the standard risks that are associated with any cloud, not necessarily OpenStack. And that's what I hear on the buzz side. Yeah, I think I agree with everyone. I mean, in terms of community, the software itself, the foundation, all of that momentum has continued at an extremely fast pace. I think we have seen more users. I think it's still confined to certain use cases, certain segments of the market. I think a lot of the focus this year is kind of how do I take it commercial? A lot of vendors coming out with products. How do I get into enterprise? I find that there is a lot of recognition of OpenStack within the enterprise. And so they are interested in the platform. I think the majority don't know that much about it yet. But I think that's likely to change. And I also think the private cloud, I think everyone's going there, but I think what I've seen from enterprise is that I think people are expecting it's going to happen within the crash of the market is coming. So they have to be patient. In your view, what are the most exciting new technology developments happening at OpenStack right now? And six months ago, we talked about what's there versus what's still missing. So what's still missing? Well, I guess the things that I hear, I don't really actually hear too much about things that are missing. I mean, there are things that are missing, but I don't know if it's something that's just not solvable over time. So there's cool networking stuff that's going on, cool storage things. I talk more to enterprises than a lot of service providers. And enterprises are kind of more or less asking for some of the VMware features that they've been used to. So shared storage, fiber channel sands, and live migration. Some of that's starting to get built in. You know, that's for like VMware style HA, you know. So, you know, I think they're coming from kind of a different expectation from features. But, you know, I think the really the biggest thing now is really not that features are going to be the big blocker, but that what you really need is to make it accessible to a wider market. And that's really making it easier to consume, easier to install, get skills and training and documentation. I think that's really the big thing on features, but features are always nice. For me, last time we were here, we talked about, you know, Quantum that just came in as a project. And now I know that Foundation wants to just rebrand it as open stack networking. Good luck, because everybody knows the name already. But in the last six months now, Quantum has gone from being an idea to something that every major networking vendor is now basing their plans upon. Even, you know, this week, Juniper and Juniper six months ago, they were in the cloud stack camp and there's no cloud stack people in here. And there won't be in six months either, because it's going away, because that's one thing. That's a thought. And then there's everything else that's associated with that. And I've had the chance to sit in a few of these design sessions this week, but load balancing as a service, which I know is in Grizzly, firewalls as a service is remarkably a brilliant idea. How it gets implemented I think will be very tricky. DNS as a service is incredibly interesting. And then some of these other emerging ideas that I see, I think tomorrow morning we're going to hear about Red Dwarf Database as a service from the HP people. There's a spoiler alert for those of you in the audience. Brian Acker is going to be talking about that, the guy who helped create my sequel. So I think there's a lot of excitement to come. You know, I think for my part, you know, the difficulty of the question is that, and this is going to sound funny, coming from an analyst, but I say this all the time, is that in the technology space we spend way too much time talking about technology, period. You know, and I think in the case of, you know, sort of open stack, I mean, you know, many of you in the room think back to the first couple releases. I mean, you remember what that project was like? It was terrible. You could not, you know, you couldn't upgrade from one version to another. Things didn't work. You know, pieces that were completely absent. You know, and yet we're all still here. We're all still in this room. So, you know, to me, I think, you know, Gary raised a great point, which is, when we look at the sort of list of, you know, sort of technically inferior solutions that have triumphed over technically superior solutions, that's a really damn long list. All right, so, you know, yes, there are sort of important technology considerations here, but the most important thing to me is going to come down to packaging, you know, essentially the, you know, streamlining the install, sort of upgrade maintenance, et cetera, process. Because, you know, so much of adoption, so much of usage comes down to convenience, not features. I guess, you know, one of the things that I'm looking at through is the perception of what the customer is thinking about right now, and, you know, just in talking with vendors and analysts and listening to some of the customer conversations is, you know, they're fully virtualized, they're up to like almost 80%, and now they're trying to figure out what to do next, and there are some that are going towards, you know, target adopting, be cloud director, but that's a, that gets very, very expensive. And so now they're starting to look at alternatives, and still there's that issue about OpenStack and its complexity, and how do you really adapt it to your particular needs, but they're just trying to weigh what to do, because in the meantime, all their product groups are starting to continue to use the public cloud, Amazon Web Services and stuff. And so I, you know, and I said, I think there is lots of exciting talk about what is the next generation of technology, but again, it's always the customers who are trying to figure out, well, you know, how do I transition, you know, from what I have right now, which is pretty complex and pretty, pretty expensive, you know, into something that is, you know, more adaptable and something I can federate to some extent. Switching gears here really quickly. Interoperability is something that's received a lot of press recently. A couple of our articles have come out just in the last few weeks criticizing OpenStack for lack of interoperability. So I want to ask you guys two questions. One, what does interoperability mean to you? And two, does it matter? Is this Steve, since you think that's funny, why don't you start? I guess that's fair. You know, I think with respect to OpenStack, the definitions of interoperability are all over the map. It really depends on what we're talking about. In the context of OpenStack, to me, there are two primary considerations, which is, you know, the first, in terms of the components themselves, are they compatible from vendor to vendor from implementer to implementer? All right, in other words, you know, is, you know, sort of core compute, storage, networking, et cetera, are they compatible? Are they essentially the same in a sort of version of the asset? You know, so that's question one. Question two, you know, and this sort of actually begs the question of what is the OpenStack project and what constitutes the OpenStack project is, well, which components are we talking about? Right, because in other words, you have implementers now who are picking different storage components. So if, you know, the compute interrupts but we're using different storage components, is that interoperable? I don't know. I mean, you know, it depends on sort of what customers talk to us about. So, you know, really, I think when we talk about interoperability in the case of OpenStack, those are the two dimensions you need to look at. And frankly, I think from users yet, we don't have enough feedback to say, hey, this is what a, you know, sort of a interoperable definition equates to. This is where it gets outside of my domain and I want to ask you guys some questions. Isn't it the benefit of OpenStack that it does have that modularity and you can, you know, fit these different pieces together if you do have that expertise? Yeah, I mean, I think the, you know, I mean, interop, I think, you know, if you look at it from a customer, right, and you're either doing private or doing public cloud or whatever, you know, what you really care about is, you know, if you're doing private cloud, if I switch vendors, you know, how painful is that experience? Or if you're looking at, you know, if I source from a public cloud provider, if I want to switch, you know, what's the time and cost involved in that, right? And so it's like what Stephen said, you know, there's, you know, how assets implemented, it's APIs and there's a lot of things, but you know, I think that's what you're really trying to accomplish if you have interop and you want choice of, you know, accessory items and stuff like that, right? Stuff that goes on top of OpenStack, is it, you know, is it all gonna work with all the various flavors of OpenStack? And so, I mean, I think OpenStack has brought some level of standardization to, you know, to the market, but I think the question is, is like, you know, so it'll make it better, but how much better? Is it a little better or a lot better? Like in practicality, like how much is that gonna matter when you factor in all this other stuff that is not standardized or interoperable? And that's the thing, I just don't think we know yet because no one's really tried to do it and no one's really tested it. And I think that is something that the foundation maybe could take a legal on, right? So, you know, enforcing and testing, you know, to put stamps on minimum levels and for public cloud providers too. And the public cloud is not just a technical thing. I think there's a business interop too because if you want to move to a cloud, there's a kind of business integration has to be done building another, federation and other things that could create headaches. Well, and just for the record, you know, on the point of the foundation, I think the foundation has to take initiative. I think they're the only ones who can. I'll just argue Devils advocate here on interoperability for the developers and the network guys and the server guys in the audience. Everybody, you guys will know what POSIX compliance means. POSIX was supposed to be a standard for interoperability across UNIX. Can you run a workload or is HPUX compliant and interoperable with IBM, AIX, Linux and Max, which are theoretically all POSIX compliant? The answer is no. So what does interoperability mean? Interoperability is something, a myth that, you know, vendors can perpetrate and POSIX compliance means a certain thing at a very baseline level. Now, the higher level we have on the web world, which all of us are also familiar with. You have a web browser through kind of sort of standard station, ML5. Everything is interoperability, interoperable through the browser. So bringing that back to open stack. At the barest level, if you're using a standard OVF image file or AMI image file or as an image file or KVM image file, if you're using the same hypervisor in another open stack cloud, I don't care if you're certified interoperability or not, it's the same hypervisor and theoretically it should run. There may be some other levels of abstraction. The other layer of abstraction that exists today is there's the glance image service, which I'm not mistaken, kind of sort of is backwards compatible from Grizzly to Folsom. So if you take an image, it goes back and forth. Where there is no compatibility in interoperability today, which is where I think the foundation needs to take a giant leap, is where VMware has a massive lead and this massive idea of VM motion across the cloud compliant data centers so I can migrate an entire workload with its whole stack across the data center. Can't do that, but if there's any VMware customers in the audience, you tell me how you can do that without significant hardware to accelerate that workload anyway. So the idea of interoperability in the cloud today is nice, but it's still a work in progress. Okay, so just a couple more questions and then we'll open it up for audience. So in your view, what is the biggest challenge OpenStack will face in the next six months? Alex, do you wanna start us off? The biggest challenge OpenStack will face in the next six months. I think it was expressed a little bit today when Jonathan was giving this keynote and he was saying, and he was addressing some of the complaints that there weren't enough examples of providers a few, when OpenStack was in its earliest days but now that there's complaints about that there's too many providers and that seems to me get to the heart of where the direction of OpenStack goes and what role those providers will play. What role will IBM play? What role will these big vendors play and how will that be reflected in OpenStack overall especially when we're talking about such issues as their operability? Yeah, I think for my money, the biggest challenge that OpenStack faces is basically figuring out what OpenStack is. What constitutes OpenStack? What is sort of an OpenStack implementation? What does that look like? What components does it need to include if it needs to include any? These are the kinds of questions to me that need to be answered because the alternative is that you have differing implementations and then from that standpoint, you have customers who are theoretically implementing OpenStack in many cases to free themselves from lock-in only to find themselves locked into a different vendor because the underlying componentry is different. Doesn't that go to the heart of the organizational structure behind OpenStack? Does that make sense? Well, that's what I said. To me, the foundation sort of needs to play a meeting role in terms of determining, hey, this is what OpenStack is. This is when you can use the term OpenStack. They need to monitor the trademark. These are the levers that we've seen work historically. And I think without some guidance, the danger is that you get down a line. And as I said, you have a whole bunch of different OpenStacks that don't look like OpenStack. I'll agree with you. And I know we kind of talked about this a little bit six months ago because fragmentation is something that's kind of messed up with Android, but I see it in a technical sense because of the rapid rate of innovation every six months, public clouds may be able to migrate. I know the rack space guys are calling from trunk, whatever day, whatever, so they can migrate quickly. Private clouds are not gonna migrate quickly. So we're gonna have enterprises stuck on a certain release. And let's worry about the vendors that that will happen. And then you may have to deal with compatibility cross releases. So I think the biggest challenge for OpenStack is to come to a Linux type model on enterprise long-term support releases from a foundation level, such that you're not gonna be supporting all releases, but there'll be an N plus one or N plus two for 18 months or three months or whatever, knowing that the foundation and the core development team is supporting a release for a period of time. And then the vendors will backport there, but that's where I see a challenge. The model has to change because three years, two, three years, new releases every six months is great. It's sustainable, there needs to be an enterprise support model built into the development. But do you really see it changing? Yes, because it worked in Linux and we had the same thing. We have now Linux kernels out every 10 to 12 weeks. Greg Crow Hartman, who's a fellow of the Linux Foundation, he maintains stable kernels. And then when he doesn't need to maintain those stable kernels, and the individuals do, but there has to be somebody who steps up and says, hey, look, this kernel, I'm gonna be supporting and doing it in this kernel. This open stack release, such as, and I'm gonna be supporting it upstream and get for a period of time, and then people won't have to worry about fragmentation. That can happen. There are historical precedences. Yeah, I think interop is that huge issue. Because I mean, I think that's a big, a big differentiating value proposition for open stack, right, to have this kind of interop between public and private and public and all of that. And I think like what Stephen said, a lot of that comes down to standardization, right? How do you prevent these annoying little flavors that will cause you a lot of headache down the road and you're just trading one vendor for another? So I think there's a value prop that customers and open stack is really put out as one of its main things. So I think they have to deliver on that. I think if they don't, the project loses a lot of appeal for a lot of people. I think the other part is really just making this software consumable. I think if I just talk about before, just making it easier and more convenient for people to use, and that'll get it to kind of more segments of the market. And I think the other challenge is, maybe not a challenge for open stack, but I think indirectly, I think a lot of people are expecting and looking at fast commercialization and success, right? Where's the money coming in? And I don't think in six months that if it doesn't, there's an ability, ability to help market doesn't appear. Now I would consider that failure, but I think there's a lot of people that expect fast results and maybe faster than what was really realistic. So I think there's always the danger of that kind of hype and people saying, well, it's been sold six months after six months and there's not a lot of money, but six months is six months. I mean, I don't expect these markets to develop over there. I always get constant questions about it. Where's the money for open stack? I'm like, you know, this thing's only been out for a couple of years and it's just starting out. I was like, you gotta kind of relax a little bit. Be patient. Gary, is open stack a sure thing? Depends what you call a sure thing. I think open stack as a technology has probably gotten to the point where the train can't be stopped and I think that the technology is going to work its way into a lot of stuff. But exactly kind of what the model is, who the players are or what kind of distribution model and products, what the products actually look like and that sort of thing, it's probably kind of up in the air, but at this point with the community, with the code that it has, I think I would count that as a success. It's an open source success already. And I do believe that if the community's code is good that somehow the industry will find a way to turn it into something viable. So I just don't think maybe we know what that is gonna look like, but I think at this point, the technology is gonna be widely available in some form or another. And I would agree, you know, the train can't be stopped. Well, maybe it could be, but the core trajectory now is in the right direction. The vendor momentum is in the right direction, was the word that Jonathan used this morning. There's a gravity that's pulling things and the nature of all of our enterprises and vendors are such that we, once you get started, there's a certain amount of operational inertia and Newton's was at second law of thermodynamics and object of motion is gonna remain emotional and it's acted upon by an equal and opposite force. So unless there is an equal and opposite force equal to this operational inertia, then it'll keep going. You know, at Red Monk, we tend to believe that the biggest community wins. There are exceptions, but by and large, sort of the largest collective, you know, tends to have the inertia, tends to have the momentum, tends to have, you know, essentially the energy needed to sustain itself and certainly grow over time. You know, I think that the one wild card, I think with OpenStack is that, assuming that it remains the same community moving forward, yes, I would say that the viability of the project is relatively projectable for, I don't know, for the foreseeable future anyhow. The difficulty, and like I said, the wild card here is, if the community ends up fragmenting itself into multiple communities, then all bets are off. If it becomes not OpenStack, but you know, IBM OpenStack or Red Hat OpenStack or HP OpenStack, you know, et cetera, that's a completely different question. And then, you know, I think the ongoing viability of the community is very much in question. So I guess the question I ask as a reporter is, if there is momentum for OpenStack, then what is it displacing? So I guess that's my question that, you know, that I happen to think about where OpenStack is actually going. And if it is then fragmented, as Stephen says, then who's the beneficiary of that fragmentation? Is it the larger vendors? And will that then just play to their camp? So that's a question that I'm curious about. If there really is that momentum for OpenStack, what are the dynamics there that are impacting the other aspects of the market? So does that mean that VMware is losing momentum with something like BCloud Director? Or does it mean that AWS is gaining momentum in other ways? I think those are kind of the questions that I'm really curious about. If I was just going on from your thread, if I was trying to figure that out, I would look and see what the workloads are and what the net new workloads are that are growing, then ask a guy like, Gary over here and his IDC quarterly tracker, and I know you gotta do one eventually. And then we could see whether it's growing or displacing, again, because I have a background in Linux. Linux did displace UNIX, that was pretty clear, and it's displacing Windows. So is OpenStack displacing VMware? Or is it net new growth? I think it's a combination of the two, and then a combination of just bare metal. I don't think server volumes, server volumes haven't declined necessarily, but five years ago, when we were all talking about virtualization, people thought server volumes would go down because utilization would go up, but that didn't necessarily happen. So I don't know that there has to be a displacement either, but that's something that's we should all pursue. I mean, if you look at the growth of physical server, I mean, it hasn't been super impressive, but you look at the line for logical servers. I mean, it's a total gap between those two. So some of it has to do the way we count it, right? Units of servers, one box is a box, but the boxes, it could mean a lot of things. Like it could be a really small box or a big box, and I really do think that what Sean mentioned, workloads are key because if you look at the competitors, a lot of them have really different workload profiles. VMware was made to be totally backwards compatible, and that's the reason why they had such success because it wasn't really disrupted, that you didn't take whatever you had and put it on there, and then you look at something like Amazon, you look at kind of, I think most open stack implementations, it wasn't really made to run that kind of workload, right? I mean, it was just like, you know, you could, but you wouldn't really be guaranteed any great uptime or anything like that. It was really meant for a new application that was developed for cloud. So, you know, I don't think we will see a lot of displacement as in, I'm taking your workload that was running this hypervisor, this platform, and then I'm gonna move it. I think that's, you know, it's not easy to do, and I don't know if there's a lot of reason for customers that they really want to do it, and I mean, we do see migrations in some cases, right? But I think for the most part, people try to avoid that. It's not something that makes a lot of sense. So I think when you look at new workloads, you have to look at what's really being generated. Just a lot of the old stuff being sold and implemented, and a lot of that's gonna go on what we know today, just, you know, kind of standard server virtualization, and then there's new apps that really fit more for cloud. And granted, both platforms are kind of going both ways, right? VMware's trying to get into the Amazon space, and OpenStack's becoming more kind of with enterprise features. But, you know, I think at this point, there's still a pretty different workload profile between OpenStack and VMware. So I think it's really about, you know, if someone's deploying a new workload, can you convince them to do it one way or another? Or, you know, the ISVs, what are they, what are they? Steven, in terms of developer, you know, the developer component there, how would you judge this if you're looking at, you know, this kind of comparison across different kinds of workloads? You know, where do you see the development focus as it relates to OpenStack versus, you know, VMware type of environments? Well, you know, to me, I think the simplest way to look at that is, you know, when you talk to customers, you know, users sort of have all shapes and sizes, right? The question there is, you know, how many of them sort of prior to an OpenStack, prior to CloudStack, prior to Eucalyptus, prior to all of these sort of would be, you know, sort of, you know, cloud layers? You know, how many of them look like Amazon? How many of them look like a private cloud? And the answer in most cases is zero. You know, which means that from a technology perspective, you know, OpenStack's penetration is largely additive. You know, certainly in some places it overlaps into places, technology is like VMware. But, you know, by and large, you know, most people are trying to make their infrastructure to look more like a public cloud for the first time, right? In terms of sort of what that means in terms of the developer perspective, you know, as I said before, we tend to bet on the larger community. And, you know, sort of one of the other factors from the developer perspective is basically that the simplest technology to acquire, install, and implement usually wins. And, you know, it's a lesson that's lost, you know, and, you know, we talk to vendors sort of of all shapes and sizes. And they all come back to us again, you know, as I said before, they all want to talk about technology. They all want to talk speeds and feeds and performance and features and knobs and bells and whistles and so on. And at the end of the day, that's all great. And, you know, technology's a wonderful thing. But, you know, really the technology that's easiest to implement, the easiest to obtain is likely to be the one that wins. And, you know, right now I think OpenStack does an okay job of that. You know, certainly I think there's been a focus in the last couple of releases on that. There's been a lot of work, you know, sort of in that space. But there's a long way to go before we know one way or another that this is going to be, you know, sort of the simplest technology to implement and use. Okay, I'd like to open the panel up to questions. Anyone have any questions? Can't see very well. Yeah, yes, you want to come up to the mic? Does the mic work? No? Okay, you already could just shout. I'm just not that big. So my question is related to, we talked about interop, right? And we talk about interop means many things to many people, right? There is never so easy as bursting or just moving both those between different clouds, right? Think of two clouds as two different clouds as two different data centers with that. So my question is there have been companies who come into this, like there was Cloud Switch got acquired by Terramar, Verizon, there is Racimi, they do image provisioning and stuff like that, you know. So forget the data for a second. Do you see more of that? Do you see the open start community kind of doing that? Data in workload in workload out should be all done by open start. Interop with VMware, interop with maybe something else, interop with Amazon. Should that be part of the open start foundation? In and out, basically? So interoperability not just with an open start but with another environment? Yeah, yeah. From the very beginning, and I remember talking to Jonathan Bryce about this more than once, open start supports Amazon API. So there is interoperability for AMI images coming in. So that's important. What I think should also happen though, and this is an emerging layer, is at the network layer with software-defined networking and this is not such that I can have the same when we're talking a layer, three domain, I guess, and extend it out so that it's all one piece. That's kind of magic. But yeah, I think it's absolutely important because the other thing is with fragmentation, nobody wants to have silo workloads, right? So with open stack, I think you're reasonably sure that you're not going, well, if you have standardized hypervisors, you're reasonably sure you're okay. Yeah, I think the project's built-in API compatibility and I think there's a layer above that, right? You come up with the management tools to let you burst and move from cloud to cloud. And maybe that should be part of the open stack project. Maybe that'll be handled by the ecosystem. But I think if open stack really wants to be a true open cloud, I think they really should interoperate with all these other clouds if they're not on the platform. Otherwise, you're just like the thing that you're kind of going up against and you're saying, well, there's lock in there. I mean, maybe, if open stack only works with other open stacks, maybe that's still lock in. You're locking to open it. Maybe it's like a larger selection of vendors and stuff like that, but you still have some lock in. So I mean, I think if you can, and I think some of this depends on the other side too, but it's technically possible. Yes, I think you should do it. And, but I think it just depends whether that project should be hampered by foundation. Is it part of the core thing? Is it, I mean, that's maybe a product technical thing, but I think it's philosophically, yes. Yeah, the sort of, the flying that or even, in many cases is gonna be IP terms. So in other words, when you look at the Amazon API, Amazon has not said sort of one way or another what the terms are, the intellectual property terms are with respect to their API. So you can implement it, and a lot of people have, but are you legally able to do that? Frankly, it's an open question. There's a reason, for example, that Eucalyptus went out and sort of partnered with Amazon to try to get those terms sort of down on paper that they were legally able to do that. So the difficulty here is that philosophically, I think all of us would probably agree that, yes, everything should interoperate and it's in the best interest of customers to have the ability to sort of move your workloads around with impunity. The difficulty is that sort of the vendor agendas, they may argue differently. The other thing I would add in there, just think about from a networking perspective, we've all been using Ethernet for X number of years, but it's only recently, and by recently I mean the last three months, that there's been a standard for interoperability across carrier grade Ethernet for quality of service. So if I was handing off from in a carrier hotel between one backbone and another, there was no standard that would guarantee that I'd have the same quality on both sides. Ethernet is what, 30 years old, give or take now? So we talked about interoperability workloads, but when you're talking about production grade workloads and we want to interoperate bursts and everything else, quality of service and other higher level abstractions are also going to be very important and nobody's even talking about quality of service or interoperability because that's so far up the chain, but these things take time. I'm always starting to see the spaces fill in a little bit, for instance, with platform as a service and using service like Cloud Foundry as a gateway into these cloud environments. That seems like that's a trend that I'm seeing at least when I look across the market. There's also lots of other vendors who are trying to do things like make the code more portable by creating that orchestration between, for instance, GitHub and integrating with Chef so you can port that code to multiple clouds. So is this a matter of where the vendors are really just trying to, are taking the lead and that's just gonna make this balkanization even more pronounced? Well, with respect to the pass front, at least, I mean, I think the ambition, at least of many of those projects, and I think certainly the hope for at least some subset of the technical population is that pass can serve essentially as a container. Very much like, for all of that, it gets a bad rap and I certainly hated it myself, but J2E Middleware did guarantee the opportunity to effectively move from operating system to operating system hardware to hardware and so on with a minimum of complications. It certainly wasn't right once, running anywhere as it was claimed to be. I think there is hope that over time, pass would represent that, but frankly, that's a long way off. We're not there yet. I think we're out of time, guys. Thank you. Thanks, guys.