 Can you hear us? We have a hashtag. It is hashtag openstack10. You want to follow the conversation or ask questions. So we're going to talk about the next two years. We decided we can't go out farther than that. So everybody, thank you for coming. I'll tell you a little bit about how we got this channel together and what we hope to get accomplished. So when I started to set this talk up, I realized I'm not remotely qualified to predict out 10 years, which I think is the two-year comment. But I think what I wanted to do is get a different set of perspectives on the challenges and opportunities that this project faces over the coming years. And I think we're doing a lot of good conversations that are really in the details of OpenStack in this conference. But I'd like to raise some issues and things that we need to be thinking about as we all go forward as a community. So I'll introduce myself real quick. I'm Jim Curry. I run the private cloud effort at Rackspace and was involved in an OpenStack set up for us. And I want to bring on a couple of people that I'm going to let introduce themselves, but I'll spill a bit of perspective on them. I'll start at the end. So Rob Hirschfeld is from Dell and is an elected member of the OpenStack Board of Directors. And Rob has the distinction of being one of the first people to ever hear about the idea about OpenStack. So can you give some perspective? Told him not to do it. Yeah. I was going to say that. So he also has got a great history of being wrong. So basically, you can discount whatever he has to say. But I figured he would have some good perspectives to bring. And then Steve is someone that I've gotten to know through the work that we've done together at Sony. And as someone who's actually depending on this for his business, I thought it'd be good to hear his perspectives on where it goes. So I actually introduced you guys, but I'd love you to tell a little bit more. Yeah, it's just that my job depends on it. Thanks, Jim. OK, good. So tell us a little bit about what you're doing. Right. So I run the global IT group for Sony PlayStation Worldwide Studios. Part of my organization is responsible for hosting all of the game servers for the games that PlayStation develops. So we made a big decision to go with OpenStack a couple of years ago. And we've become very close personal friends with Jim and his staff. So we have a real vested interest not only in where OpenStack is today and next year, but really where this goes long term. And so I've been in cloud for 15 years, believe it or not. And I can instantiate that claim. But so I got involved with OpenStack initially when Rack Space was trying to put together this coalition. And I've had a lot of experience. I work for Dell and in the hyperscale group where we support the team I had started in was supporting the largest of the large data centers. And we had seen how these data centers were being successful. And we'd also been trying to help the next generation, next level down be successful and understanding the operational challenges and things like that. So my role at Dell has been to take big data solutions OpenStack, cloud, Hadoop, and make them accessible to our customers. And so we brought our first OpenStack solution to market over 18 months ago and started getting field experience all over the planet, all over different disciplines. You actually, I don't know if you remember, you guys rented a cattle trailer to bring our rack of servers to the first conference, which was an interesting scenario since driving down 35 with servers rambling in the back. So talking about learning how to write at the Bear Conference, we actually brought a full rack of hyper dense servers in. And it's on a cattle trailer, last minute planning. And yeah, so we know we've really invested in operationalizing OpenStack. And so Nikki is our chief evangelista at Rackspace. And she'll prevent us all from over talking to each other and hopefully get us directly in the right way. So we're going to start off with some topics, I guess. And then we'll take tweet questions. Yeah, fantastic. So the first thing I want to cover, you guys have kind of your own perspectives on how OpenStack was started and what that was like. Jim, you have the emails between you and Chris Camp. You were there at the beginning. You've kind of been under the radar a little bit. But walk us through, before we get it the next 10 years, walk us through three years ago now until today where we are at the summit. I'll start off. And then Rob, you'd be good to get your perspective on this. So when we started this project, as I said this morning, we actually didn't have a lot of code behind it. In fact, we had no code, really. We had Swift, which had been running in production. And we had probably about 1,500 lines of proof of concept compute code. And Rackspace got into it for, I think, very, initially, honestly, a little bit of a self-serving reason. We wanted to build a platform, have an open and standard platform for clouds to run on because we, as a service company, went in a world in which there are standards, a world in which customers can assume that the environment that we run in our cloud is similar to what they run on premise and what other clouds would be running. And three years ago, that was in the case, we had a cloud that we built ourselves that looked very different than any other service provider clouds and certainly didn't look like anything. Enterprises were running. And so we had this vision that actually, despite the initial statement about it being for public clouds and for private clouds, we were really focused on building something for public clouds. What I think really surprised us in what has actually become one of the defining characteristics of the project is when we launched this, enterprises appeared out of nowhere and appeared through the vendors that were involved and others who said, hey, this vision of building a public cloud standard platform is irrelevant unless it's something I can also run in-house. And we want to get involved very early in that. And in fact, Sony got involved one year into the project, if that. And so I think that really changed the nature of this project. And I think one of the things we'll probably talk a little about is where would we actually think, where do we think OpenStack is going with public and private? I'll save that for a little bit later. But we have done a tremendous job, I think, as a community trying to serve both use cases. We actually had built something that is running really well in the public cloud. I gave you some stats this morning in my keynote. It works really well. And we have a ton of user stories coming up about private cloud. And that's a momentous task given where we were. So I think we really have reached a tipping point where we've got users defining the future of this project. Those users are defined across different categories. But I think that's kind of where we got to. And Rob, what did you think were in that room? What were we going to end up doing? It was really interesting. So some of the market motivations of public cloud vendors not being willing to implement Amazon's APIs are unable legally to implement Amazon's APIs. And that really blocking the marketplace from expanding across multiple hosts. And from my position with Dell and the hyperscale data centers, we've talked to a lot of hosts and a lot of people who want to be able to interoperate. And that the competitive position was and is even more now that Amazon doesn't offer customers a choice. They don't give you the commercial protection of being able to have multiple vendors. And I know from a hardware perspective, we have a lot of customers who want multiple hardware vendors. It's a requirement for their business continuity. Cloud vendors are exactly the same thing. And so that's become a really serious thing. At the time when we were sitting down to talk, we had already in field a eucalyptus solution. We had a solution based on joints technology. And so the real question, and there was cloud stack, was up and coming as cloud.com at the time. Nebula, there was a fair number of open stack projects. And the question, and this was pivotal to me in what's happened over the last couple of years, the question was to Jim, why not use eucalyptus? Why not use one of these existing stacks? Why do you need a new stack? And it's time. The Nebula code, sorry, the NASA code wasn't even in the mix. And the answer really was we want collaboration. We want to have a code base that accepts pull requests that isn't tied up to yet another commercial entity. And so the gamble for Rackspace was can they do it in a way that doesn't make it Rackspace's technology but makes it a community technology? Because that's what was necessary. You had to convince these hosting companies to come in and share and all collaborate on the same code. It was a huge gamble. And my advice was don't do it unless you're ready to actually invest in it. Don't just tip your toe in and think that you're gonna make this successful. You had to go big and we were actually successful in getting the support to really go big and open stack and it's been great. Steve, you're nodding your head over there. And I know in our discussions earlier you mentioned having looked at eucalyptus and other vendors, tell me about that path. Right, so within PlayStation we've always, we've got people who've always been very passionate. So we've always been invested in that open stack mentality. We've been doing game hosting since 2002 when PlayStation 2 went online and our client server architecture has always been based on Linux and we've used Apache and various other different open stack models. So as we started moving into requirements for doing private cloud, we'd already been in public cloud for a few years. We certainly had a preference to something that was more open. Something because we did, the mission of World Wide Studios is to innovate. So every game architecture looks different from every other game architecture for what we develop internally. And so it's hard to standardize, it's hard to push out standards and tell our studios do it this way. So having an open model gives us a lot of flexibility to go in and do stuff because we don't do a lot of web-like stuff. Our game traffic looks like a medium-scale DDoS attack. So it's very unique, it's very different. And for 10 years, we've had the history of going in, tuning the kernel, tuning a lot of low-level parameters to get what we need to make sure that we protect the game experience. And so as we selected open stack and we saw the momentum behind it and we liked the openness of it and the ability to start understanding the code to give back to the code, to start making it something more than what it was. And we started having these discussions with Rackspace and understanding that there's this whole untapped market because there was two, three years ago no cloud platform that truly embraced an enterprise-class solution. And it's still a very developing marketplace. So one of the reasons we're kind of coming out from under the rock, as it were, is we wanna be a lot more engaged in the open stack community. You're gonna see more and more contributions by us directly. We've been doing it kind of under the covers to Rackspace for a couple years now. But we really wanna start helping to develop this market because it's gonna benefit not just the market, but us, other game developers. You've seen a big push towards independent game developers as we've announced in PlayStation 4. And so we really wanna help the community, whatever community it is. Take us 10 years from now, 2023. Is OpenStack still the new thing? Has it lost its luster? Will you wanna go first, Rob? So one of the challenges that OpenStack has is its strength and it's also its challenge going forward. And I think I'm hoping we'll resolve this in 10 years. But we've chosen to be very implementation-focused. And one of the things that that does is it means that we define OpenStack as this is the code base. And so in 10 years, I would expect to have seen us change out the underlying implementation three times. And so the challenge for OpenStack is getting out of our own way and allowing that to happen. That right now we don't have an easy mechanism for somebody to come in with a new implementation of OpenStack and we've got a plugin model, we've got extensions and things like that. But I think we'd really struggle with a whole new implementation. We did a keystone and it was okay, but it's still a challenge. And so I would expect in 10 years to see the code base basically be entirely turned over two more times. Only two. At least two. Okay, fair enough. Now it's interesting you say that because in the hosting we've been doing for the last decade, we've kind of gone through that same iteration where in the beginning there were not commercial tools for what we needed to do so we had to write them ourselves. Much like the origin of OpenStack is what was out there wasn't good enough. And over the last 10 or 11 years, yeah things have built up to be monolithic and large and hard to manage. And you wanna be in a position where you can change our pieces and parts of it pretty seamlessly. And I think everybody is understanding this is a reasonable way to approach things which will make really everybody's life easier. So if you wanna adopt something, if you really wanna spread this as a market to gain market share, to gain momentum as a standard, making it easy to use, easy to upgrade, easy to change out components to use it either this big or that big will really, I think, drive adoption and help keep it around. I would say that it's very likely that OpenStack is gonna become hidden inside something different. So I mean, you see, if you look at the themes of the community right now, there's already people moving on to this concept of platform and what platform looks like. And a lot of that is because users simply don't care about thinking about infrastructure. They think about just consuming it and using it. And so I do think that there's likely going to be other projects or areas that, frankly, this community moves on to to solve and puts more of their effort in. It doesn't mean that we don't have a lot of work to do, but I do think the core concepts of compute network and storage are we're making a lot of progress. We clearly have more work to do. I think that will get fixed. I do worry about the number. I think one of the beautiful things about OpenStack is that it evolves because the community decides it's gonna evolve and it can start with one person. It's also a real danger. So if you think about, again, where we started, we had Nova and we had Swift and then we had Quantum Pop-Up and that wasn't really planned. And then we've had, obviously, you know, keep going, we've had Solometer and Heat and all these other different projects and they're awesome, but it starts to become a very broad set of things that we're trying to tackle. Is that good or bad? I don't really know, but I think at some point it becomes almost too big for this community to handle the single thing. And I think in particular, it risks having the core be neglected to a certain extent. So I think we have to be careful about that because we still got some work to do to get that core right. Well, isn't that almost why you've got something defined as a core and then you've got projects that literally are kind of on the stratosphere? So you really wanna protect that core experience, the core thing. Lots of things can plug into it and they can be associated and help write the fine standards. But you've got to protect that core. There's definitely a danger that OpenStack brand becomes so diluted from that perspective that it really doesn't mean that much. And I think that there are risks from, for the Linux community in a sense that when we talk about Linux, we always talk about distros that have diverged into a certain extent. And I think that one of the real risks for OpenStack is how do we keep the community so that the OpenStack brand is the brand that people wanna work under. One of the dangers is distributing it with all these extra projects which are exciting and funding and bring people in which we want but also make OpenStack become more like the cloud or the internet. And in those cases, it becomes something that's so undefined it's just a brand. Well, I think this is a question that we're talking about it on the board and it's a question the community needs to really wrestle with is before this came to the foundation, we'd had the concept of actually the OpenStack brand implying interoperability. And implying interoperability because there was a set of defined services that everybody ran. And I do think we're changing that. OpenStack may or may, that may not be what it should mean. In fact, to a certain extent, OpenStack has become a brand that we haven't. We actually need to sit down and define what the terms about it are mean but I do think that's gonna be important because OpenStack has to decide what its purpose is. It's interesting because if you talk to a lot of people that have been approaching OpenStack about affiliate input and projects in it, they wanna do it because they like the governance model, they like the community model. It's not necessarily always just about the business problems or the technology problems we're trying to solve, just like the way the community works. And maybe there's an opportunity to also think about what we're doing here in that respect, which is if we do wanna move up and work on a platform solution within OpenStack, should we do that? Should the OpenStack brand be allowed to do that or not? Maybe, I think we need to debate that. I think that there should at some point and be a divergence between the OpenStack culture and governance and things like that. That might be repeatable without having the OpenStack code base actually be as, you know, get as large. As a matter of fact, that's one of the things I believe in very strongly and the fun thing about being a technology person is that we have the ability and we do this all the time, write the tools that make it easier for us to collaborate because we have to collaborate in ways like globally across releases, across, we have to figure out ways to collaborate that nobody ever had to do before. That is actually, I think, as much OpenStack's legacy as the code base. And I think it's gonna keep turning, should keep turning, should keep growing, changing. But what we're learning how to do it, how we're learning how to do it is really the viral thing that we're creating. Well, and you're talking exactly the direction that we're going from an enterprise, which is, as we're building our hosting platform based on OpenStack, I can't envision this as a two-year project. I have to look at this as something that needs to last five or 10 years. Literally. So, knowing that every year my studios are going to innovate, I have to be thinking ahead about how do we design this in such a way that it can handle the problems that I haven't even thought of yet. This is the fundamental revolution that I see happening in IT. Change is accelerating. We can't go and say, I'll help you cope with change. We actually have to have a whole new paradigm that says change is accelerated to the point where we have to adapt to it, not push it off to a longer release cycle or it's a little bit different. You're talking about a technical meritocracy. And I know, Jimmy, you have some kind of strong opinions on this. You think it's 60? I bet Rob does, too. Long term, maybe you have a different opinion. No, I think it's funny. We spent a lot of time designing the governance structure. We spent a lot of time trying to set up what the purpose of the board was or even before the board and we had the project policy board before the foundation was set up. And the process is around that. I think we actually got one thing right. And one thing that is, ultimately we'll keep this project honest is a great mechanism for keeping vendors honest. And it is the technical meritocracy. And that came out a lot of reasons. It came out because we modeled a lot of stuff of Buntu and what a Buntu was doing. We as a company at Rackspace and we're very much a frontline company that the people that are doing the work are the ones that drive what we do as a company. But I think that does create these problems that we're talking about, which is it can take off in different directions. But man, I mean, the stuff that's actually done by people sitting in front of their machines and coding is what really matters, not nearly as much as what goes on the board and director level, in my opinion. And I think that's what's really interesting about this project. Do you? I'll share one if you want. No, please, please. So one of the things that I hear a lot about OpenStack, and I also value meritocracy, that the challenges that we typically tend to only have the meritocracy in the dev community. And so one of the things that I think is a struggle for us is that as the project ensures and as it grows into more and more community and user bases and operators, and we've got a real wealth, documentation is a great example. We have to find a way to create meritocracies in non-development places and say, and this is a struggle at the board level, I think it's a struggle in the community levels where people who aren't contributing code feel like second-class citizens. And that is one of the dangers of a technical meritocracy is that we have a tendency to overlook somebody who's doing something important. The classic one is that the best operator, the best ops person you can have is the person who doesn't look like they're busy. Because their systems are up. And so we have to be careful about building a technical meritocracy that recognizes people's contributions more broadly. And also based on, not strictly on the size of their organization, but on the way in which they contribute and the behaviors they model. Which probably the opposite of that is this completely business driven. Correct. So probably as with most things in life, it's finding the balance. A pure technical meritocracy may not lead where the users of that product really want it to go. On the other hand, if it's completely business driven, well now you're not gonna get all that great community support that people feel eager to put back in. So finding that blend where, hey, the great clusters of innovation and development come together and great and brilliant things happen guided by some business sense on top of that. You don't wanna sink a million dollars into the development of something that three people are gonna use even though it's technically brilliant. You wanna guide that investment and even as we talked about an open source project, that investment is people's time. The time that you guys as developers are putting into things needs to be, in some sense guided with some balance. One thing I'll say though, if you look at, I think this is pretty unique to OpenStack. I can speak specifically from a rack space perspective but I do think Dell and other companies did the exact same thing. There's a lot of collaboration that goes on with customers into the project. So we spent a lot of time working with you guys to put stuff back into OpenStack. HubSpot has talked about the stuff that they've done not only to consume OpenStack but to contribute back into it and they're starting to become this culture, it's almost like a little bit of a cult when people work with us around OpenStack, they feel the need to actually start contributing back into it as well and this doesn't occur in other open source projects to that extent. There's two really important elements to that that I think OpenStack is modeling really well. The first one is the anti-forking mentality, right? A lot of open source projects, people think I'll just do my own thing and I'll fork it and just do that. And we have and I don't think we do enough and this is where actually the board I think is incredibly powerful and needs to be given credit or needs to step up, maybe both, is this fork avoidance, right? We must find, model and enforce this upstreaming mentality and it's not new but it's different and we really need to be careful with that. The biggest danger I have for the 10 year vision is that there's 100 different forks of OpenStack, all of which are being maintained. I'd rather there be 10 or less. I don't think one might be too ambitious, that'd be great. The other thing that I see from the same perspective is people not talking about OpenStack as a them and so I see this inside of companies that I work, you know, customers I work with inside my own company where OpenStack, oh when is OpenStack gonna deliver this new feature? And instead of saying when are we going to deliver that feature in OpenStack? And it's a world of difference between the two. And so the challenge here is that we really have to kick people into, it's not OpenStack delivering features, it's a joint project, right? And so that's a really tricky challenge. Steve, you bring a unique perspective as a user. What are your, you're welcome. And you're a long horse, that makes you okay in my book. What are your asks and your warnings? I'm sorry. I miss Rob's comment over there. I'm sure it's really sarcastic. You're the joke. Gotcha. So what are your asks and your warnings for the OpenStack community, both as a contributor and as a consumer of OpenStack over the next seven to 10 years? So Rob hit on the first one that's been something Jim and I have talked about but is one of my major concerns about the long term which is if it gets so popular and there's not enough guidance and control over that fragments, it's like this beautiful ice sculpture that you've taken so long to build and there's been so much energy and passion to put into it and then somebody comes along and tips it over and now you've got snow all over the place. If it fragments too far, the value gets diluted. Used to business term, sorry. But then I, as an enterprise user go, which one should I use? And then I've got to make that commitment to use that. I can't just switch out platforms every year. I need to use this for the next five to 10 years. Which one do I choose? Well, this one has some merits, this one has some other merits, this person becomes a very dangerous decision to make. So by keeping this and even, this is part of why we want to be involved, helping to keep this together as a core product which is why I think the core of OpenStack is so very, very important. Driving it towards a standard, towards something that is easy and that everyone accepts to be easy to use. That you know what? It's good enough if I don't like it, I can help change it and we all agree that this is the right direction to go. And over the last two, three years, we've seen so much momentum. As long as we really capture that momentum and we keep it going in the same general direction, we're all going to do very well. Steve, you said the word standard. I'm sorry. Oh boy. That's okay, but I want to ask you to clarify what you mean when you say standard. The great thing about standards there's so many to choose from. And that's what we want to avoid. So it's not necessarily that there has to be one way of doing it. And maybe it's a methodology, maybe it's a philosophy of how we do it. Maybe that's where OpenStack really starts to develop. If it involves beyond a technical standard into a philosophical standard. Everybody have a sec? So are you thinking IETF or are you thinking you know some, we're all the standards I like to avoid. But you know that there are standard bodies out there. One of the very contentious things that happened with OpenStack at the time was VMware was busy pushing through a cloud API standard. And several other companies were doing it too through different bodies. And OpenStack sort of said, we don't think that's our right thing to do right now. Where do you stand on that? I think that's where the technical meritocracy comes into it. Is if you get a large body, a large community behind it, the community, the market, if you will, will help decide which is the right direction to go. So by continuing to foster the sense of community, the sense of involvement, keeping people involved, so it's their project, not their project. This idea of standards, however it evolves becomes, perhaps it's a little bit more of a democratic standard. Something that more people agree on than don't agree on. Yeah, so going to standards bodies, my personal belief is that standards are evolved through use, not boards, right? So it's about what becomes ubiquitous. And I think when it, I think we have this discussion, I think at this point, I'm far less personally worried about fragmentation. I think we're very early in the market and we need to actually people to get out and use it and implement it. And ultimately, certain things and certain deployments and implementations of OpenStack will become more standard. And I think OpenStack is such an, again, such an ambitious project. It's hard for me to imagine that there's going to be one or two companies that really own that and define it in the way that basically happened in Linux. I think it will end up being a broader set of folks. But I think ultimately we need to give more time for the market to develop and let the people that are developing it or selling it help us determine where that goes. I think one promise we've always had around this is we did try to set it up, whether or not we're doing a good job whether it's not as a community as a debate, we did try to set it up so that OpenStack core would always be an option for people that you can always come back to trunk and use that. And we obviously I think we have more work to do to get to the project of that state but as a way to try to keep the overall community honest and hopefully come up with something that is much more standard. We also had this vision and I don't know if this is actually realistic that users will have seen this before and want to keep the community honest. So as we wait for ubiquity to evolve through vendors that they will work to make sure that there's enough diversity in those vendors that users will continue to have choice. And I don't know if that's actually realistic or not. I don't know if users will actually have that power not to make that happen. So Rob, you're asking questions. So what do you think? I think it's a two-edged sword that standards bodies spend a lot of time thinking through the use cases and they work things out. And in some cases we've seen some very successful standards like the internet itself where things were thought through and it's proven it's been very time-tested. The challenge with implementation is that somebody at two in the morning might make some bad choices that we then have to live with for quite a long time. So I'm really torn because I like the implementation approach. I think it's pragmatic and I think it's very flexible and it's very fast. But I think that we have to find a way to rationalize it and slow it down without making people feel stifled from an innovation perspective. We have a question from the audience. What would it do to open staff at Amazon, turn around and offer a legal AWS API compliant solution tomorrow? Anyone care to take that one? I think that would be great. That would be great. They would take a stand. But if that would further help the market feedback to Amazon, is that important? And if it is, maybe that's something that continues. That was one of the Amazon API compatibility was one of the reasons we chose open stack in the first place because we were already in Amazon at the time. We still are. That's one of those, hey, it helps us move between. What are you using now? Are you using the open stack API or the Amazon API more predominantly? It's a blend. What's the trend? No clear trend yet. I know where I want the trend to go. But it's still a blend. There are times because Amazon is not internal, it's easier to just rent the stuff right now. And it's easy for me to tell studios, hey, go develop that out there. And once it starts to become more production worthy, bring it in, we'll put it on open stack. And we help them make those choices. So early on, the Amazon API was very important for us. Over time, does it continue to be that important? We'll find out. It will really be up to my studios to tell me. Well, that's a really good question. So let me start with philosophy. When we got this started, I mean, the belief was adopting the Amazon API without the implementation behind it, that access to the services behind it was not a good strategy. First of all, you're seeding your roadmap control to another company. And second of all, can you really build what Amazon has? It still remains a black box. You don't know what's actually behind the scenes. I think the way it changes this question is what would happen if Amazon actually decided to open source their entire system? I think that would be an interesting question to someone who wants to keep going with that. But I would say that from a rack space perspective, what Steve is talking about, we actually have worked with customers who want to use the Vectis the first way we worked with them was using it, but we view it as a transitional API towards getting them onto OpenStack. We ultimately want to have our customers on OpenStack. So we do work with customers on it today. I think that it would be the best thing that could happen to OpenStack, that it would drive adoption through the roof because we could very quickly just take the API we've got, make it, yeah, even, you know, would there be a standard, it would be easier to implement and then OpenStack would have both APIs and unless Amazon open sourced all of their code base or created a really significant base, then I don't think it would do anything but accelerate adoption. But don't you think most of the major tools that are running on Amazon today are already running on OpenStack? You know what, let's, I wanna ask the audience real quick. Those of you in favor of Amazon API compatibility, raise your hand. Those of you against it, raise your hand. Those who don't care either way. Maybe the rest of you, interesting. It's at this point Amazon sort of cast their lot, I think that any action like that's only to accelerate adoption. And you can see that what they've been doing with Eucalyptus, where they're really trying to treat Eucalyptus as an open source Amazon. But Amazon's secret sauce right now seems to be the speed of which they can innovate and change their APIs. And, Which is good and bad. Which is a very powerful force. And so, you know, publishing a standard like that, if they were actually gonna do it as a community standard, you just mentioned licensing. If they're gonna do it as a community standard, it would really change their business model from that perspective. If they were just open licensing them, I actually, I think Jim's more right that it wouldn't help us that much and people would wanna be back in the community managed APIs. So we're almost out of time here. I kinda wanna just go down a line. Just final thoughts, 10 years from now. What do you think this is headed? Well, if you do the math, we're headed to about 20,000 people at the conference. It's a lot of tickets. Which I have no idea how we're gonna make this work. You know, I think it's, again, I actually wanna come back to this culture comment about the, again, we're talking about a product. I find it, it's very few times in life do you get to be associated with a movement like this. And the culture behind the collaboration is actually real. I think, you know, I'm sure there's press in the room. They love to make the fact of the idea that these vendors are, we're jockeying behind the scenes and all fighting each other on this. Of course we're all here to ultimately, for our businesses, make money and win in the long term. But I think we have actually done a really tremendous job working together and collaborating to really help OpenStack win as a platform. And in my perspective, the platform battles really gets to Amazon and I think we've done a great job. And I don't see signs of that actually getting worse. I see signs of it getting better. I think, you know, to give credit to folks like IBM who've been, Red Hat and others, been in the community. They have a lot of experience in this and they've done a good job continuing to push forward our level of collaboration. So I'm actually very hopeful that we're gonna continue to see this culture evolve. And I do think that we're gonna see this same model start to be applied to different areas around infrastructure as a service. And I expect to see this community move on and work in other areas as well. So I'm really hopeful about it. So I expect that what we know as OpenStack today will look back 10 years and go, like, well, we did that 10 years ago. Wow, it'll be so much different. But I think the real hope for the project is not, it actually goes beyond the product itself in that what does OpenStack inspire to happen? If we look back at technology 10 years ago, we go, I had that phone 10 years ago, wow, cramming. So what is the cloud going to look like 10 years from now? It's gonna be so ubiquitous. It's gonna become like running water. You almost don't even think about it. So what's really interesting to me is how will OpenStack drive this into such a ubiquity that we all have it, that the cloud is my phone, my phone is my cloud, or whatever my phone is 10 years from now. It'll just be there, we won't think about it. But as techies, as IT guys, we'll understand all this core technology that started 10 years ago that hopefully we'll just feed such innovation and development efficiency and new innovation. So it's, I think a lot of the hope in this really is beyond the product, beyond the number of lines of code. But what it inspires? So I was doing cloud in 2001. And the visions that we had in 2001 were pretty much similar to what we've only just now done. And so some of our expectations of workload portability and being able to treat hybrid, public, and private cloud as a continuous stream of cloud based on my seasoned experience of that real pace of change. I think that we'll be only then really seeing that type of fluidness that we feel like we're right on the precipice of. Because I know that 10 years ago, I felt like we were right on the precipice of having standard APIs and things like that. So maybe I'm a little bit more pessimistic that our visions will come through. But I do think that we're gonna have, there's gonna be surprises. And I think the biggest statement I would say is that I like that I can't predict what cool thing is gonna be 10 years from now. Because that means that we're gonna keep it in. Run of applause for our panelists. Oh, and there's an interoperability panel. I'll plug the panel for interoperability next door starting at 5.20, where we're gonna deal with exactly the issues of workload portability.