 We'll get started. This is the four-year-old panel, so we've been involved in OpenStack since the beginning of OpenStack, and it's changed into something we didn't really expect, so we now are all repentant OpenStackers, and we will start with a quick introduction of like where you were four years ago, what you did during those four years, because that's special for Jay. We'll start with Vish. Hi, I'm Vish Aishaya, so four years ago I was in San Francisco when we wrote the first line of code for Nova before OpenStack was a thing, which is a long story that I won't get into yet, although maybe if things get really boring we'll get into the really old days, and I was the first OpenStack compute technical lead for the first two years, and I'm currently on the board director's and the technical committee, so I'm still very involved, although I do a lot less coding now. Four years ago, God, I don't really know. Four years ago, oh, sorry, I'm Monty Taylor. Four years ago I was actually a core developer on Drizzle with our good friend, well actually like five years ago I was a core developer on Drizzle with J-Pipes, working at Rackspace, and around the time that we started all this stuff, I started the the Infra program was the original Infra-PTL. If you look at my Stacolytics numbers, you'll realize that like Vish, I probably do less actual real technical things, or not, yeah, I do less coding in the thing that I did maybe a year ago, but because other smarter people have taken over for me. Good morning, I'm Ann Gentel. Let's see, four years ago, November 2010, I had just started at Rackspace, brand new, hadn't had a Mac computer in about eight years, barely remembered three Linux commands. What else? I had been working as basically a community documentation consultant, and I had just like I started at Rackspace. I had this keynote in Sweden for community documentation. I found out that there was this community documentation job in my backyard in Austin, Texas, and jumped at the chance. I think only one other person applied. But that was, you know, four years ago fall, I wasn't at the actual Ozcon starting, like, kickoff, so I was even a little later than some of these old-timers, right? Old-timers. We're all so old. That's right. Hi, I'm Jay Pipes. Sagittarius, I like long walks on the beach. So yeah, Monty kind of said four years ago. Monty and I were working on the Drizzle database project. We'd both come over from Sun Microsystems and got involved with what turned out to be an open stack doing sort of due diligence on what the next generation of Rackspace cloud would be, and so we did a bunch of due diligence on various systems at the time, and Nova had literally just been sort of thrown out into the world and we got notified about it and took a look at it and said, well, this might work, and it's been a long, strange journey ever since then. And my name is Thierry Cares. I was involved, I was in Canonical as the technical lead for Moon2Server when OpenStack started, and I got hired by Rackspace to work on the release management side of things and try to bring some structure to the effort, and then I moved to the OpenStack Foundation, and I basically do the same thing I used to do, but the job changed in four years a bit, apparently going from 10 to 1000 developers brings interesting scanning challenges. So we all moved on, but we all had a different journey, but we're still involved in OpenStack, and that's what makes those five people a bit special, because some people that were there four years ago just moved on, because, you know... Okay, Mark's not here, but I met Mark Collier and Jim Curry, and they were the ones who interviewed and hired me, and they were both kind of business development people at Rackspace who had these crazy ideas, and if you really want a wonderful history of OpenStack, there's a wired article that I now hand to every new Racker, and just highly recommend it for the real, true story of what happened at Rackspace, what happened at NASA, how people met, and it's a wonderful story. So if you're interested in this kind of historical context, read that one. So my first question to the panel is we all started this for different reasons, and coming from different backgrounds, but we all had a goal, personal goal, that we wanted to accomplish by joining that project. So my first question is the most controversial one. What did we fail to accomplish during those four years? What did we set out to do originally when we joined this journey, and we are still not there. We did other things, but we failed to accomplish those early goals. I have not made a hundred million dollars, personally. That was your original plan? Surely, that was not your original goal. I didn't know you're going to start with the hard one. Wow. Wow. I've got one. So the initial plan for NOVA was to basically create a private cloud for NASA, which had both an infrastructure and a platform component to it. NASA aims, unfortunately, doesn't use that cloud anymore. So that was a failing, I feel. And that was primarily because OpenStack grew so quickly that it sort of grew out of NASA too fast, and a lot of the experts, including myself, that were at NASA, ended up leaving and going on to do other things. And so there wasn't enough expertise there to keep going with it. So there's a fail. The reason why I added this question to the panel is that I have an answer for that. My... Cheating man. I asked you for questions. You didn't provide any. So my initial goal was to not have a future where only Amazon would provide public cloud. And so the early goal was really to build this interconnected hub of OpenStack-powered public clouds that would take over the world and beat Amazon as their own game. And I feel like we accomplished a lot more than we set out to do, but on this specific specific aspect, Amazon is still very much there. We don't have this interconnected hub of small public clouds or small, smallish, bigger public clouds that were supposed to replace this this thing. So to me, it's we are not there yet. And I feel like we took a long detour to that original goal that I had. So it would be my fail. I would say my personal failure... Well, two things. So I personally wanted to rid the world of the scourge of XML. And I have surely failed in that. We've made big, big strides towards that. But it's still in there. No, but in all seriousness, I think we have honestly failed to focus on the API side of OpenStack. I think it is to this day a mess. The public HTTP APIs and 3, 4 years ago, I was really pushing for, look, it's the API. We need to standardize the APIs, make them consistent. We can have differing implementations. We can, you know, and that was one of my personal goals. And I really haven't seen that through. But hopefully soon we can make some some more progress there. We've got a new working group. We do have an API working group. Get involved. My... I think, and similar to all these, I think we've made some interesting progress in the general direction, but started off, you know, on the N4CI side of things with the idea that we do things such that every commit into the things would be releasable. Like that's sort of the goal there. In theory, I mean, we do have people running, you know, this stuff continuously delivered, but a lot of them are running it, you know, two, three, four, five weeks behind, six months behind, what not. And that's because there's four years behind. And that's because in truth, it's a bit harder than that, right? And we haven't quite accomplished for all of the stuff that we do and for all of the sort of the effort that goes into that side. It's still we're still not sort of hitting that on the cycle. I would love to make that, I'd like to make Thierry's job irrelevant, you know. It would be great. You know, I'd love to make my job relevant. And we're both still here. So I'm trying to think of a failing in the documentation side since I'm the Docs PTL. Oh, you are so awesome. It's not awesome. It's so interesting, though, with the growth. We actually had a session yesterday where it's growing so much so fast. So many projects from two to now 17 are in the integrated incubating sort of realm. And yesterday, we actually had a comment in one of the sessions. Your team is not going to write the documentation. Your team is going to write the docs on how to write the documentation. And so I feel like there's this total inception going on where we've gotten so big that, you know, the experts laying around with this very specialty area of Docs are just going to have to write a small shell script to replace themselves. You know what there's a lot of in documentation XML. Slowly changing. So my next question would be a bit more positive. Which of our successes were unexpected? I can clear it off. Mark, if you're here, just feel free to come up on stage. Growth wasn't expected. How fast it grew and how many people we attracted? Right. I mean, how many people were in Austin? 200? No. No less. No. 150 people in Austin. 75. Yeah. I mean, I think I vaguely remember the temperature was about the number of people in Fahrenheit. It was like 110 degrees or something in Austin. Yeah. I mean, I wouldn't say that the growth has been, I mean, it's been pleasantly surprising how quickly things have grown. I mean, obviously we've had challenges in keeping up with, you know, the growth curve and the popularity. I think the, an early criticism of the open-stack community was that, oh, it's all sort of fluff and marketing and, you know, there's no there, there. So I think we're actually starting to catch up to the marketing hype a bit, which is, I think, a successful sort of curve, right? I think we're getting to the point where we're matching what we're saying we are, right? In the vein of growth, when we first started writing NOVA, we would have been happy to have five users. Like we did not expect to ever have other people looking at that code and complaining about how bad it was. And so for us, it was a big surprise on the NASA end to have Rackspace join and then have this whole initiative sort of spring up out of what we thought was some code that we wrote over a weekend. So that was definitely a surprise on the positive side. One of the surprises that I had was the infrastructure model we built for this. Maybe that was your plan all along, Monty, but I feel like we built a development model instead of a cloud platform in some ways and that other people adopt, even internally, inside enterprises. And it wasn't like an expected development. We weren't set out to, you know, fix all the development models for everyone and build something that would inspire others to reuse it. We just tried to iterate on well-known patterns and it ended up being something that serves as a model for the rest of the open source community and inside companies. Yeah, I would completely agree with that. And if you look at the just the sheer breadth of tooling that the infrastructure team has created over the last, you know, three or four years with Zool and NodePool and GitReview and GERDI. I mean, it's just, it is kind of astonishing how much that team has produced and coped with, you know, the growth in the developer community in such a short amount of time. It really is pretty fantastic. That's your Q, Monty. You can go. I was just going to say, Monty, you're great. Oh gosh, well, I was just going to say that possibly the most unexpected thing is GERDI that we could produce GERDI out of all this. What's GERDI? For those of you who don't know, it's a text-based TTY interface to Garrett and Code Reviews that is fantastic. So never would have expected that that would have been a thing that we would have worked on or found pleasing. But things grow and change. We started off with some development model stuff. And because of all of this growth that we sort of had to, I'd say possibly it was unexpected that we were able to cope with the sort of explosive growth as well as we have. I mean, there's still tons of warts and tons of ways in which we just had a session yesterday on how to deal with the review load and project scaling issues. But that's a fascinatingly great conversation to have to have at this point. Do you remember the, I think it was the cactus, maybe it was Diablo Summit where we were having the debate about going to GitHub or using Git as opposed to Bizarre and Launchpad? Oh my gosh. I mean, it really is weird to think that that was only two and a half years ago, three years ago. Fun memories. Yes. And now we just sort of take a lot of that stuff for granted. But that was an actual conversation that we had. So I was thinking about this this morning coming over here is that we used to have a bunch of these like the official OpenStack argument of JSON versus XML. But there was there was also the event that twisted argument and, you know, there was that there was the Git Bizarre, you know, kafafel and like all of these different, different things that were just like diametrically opposed, like, like, you know, die hard people punching each other in the face. Right. And I'm sure four years from now we're going to look back and say, do you remember like blueprints? We had these things called blueprints. Yeah. But but that said, I mean, we had like 100 people in the room yesterday talking about the the spec process. And like, really, what we're talking about is like, hey, maybe if we had like a thing where you did the first heading first, and then we got it, we got approved to that and then we moved on. And there was nobody like standing up screaming like, we should clearly just use GitHub issues, you know, like that's nobody's doing that anymore. Which somebody did just, you know, two and a half years ago. Yeah. Another unexpected development, I think, was the technical meritocracy that we built. I mean, it was set as more as a social experiment and it actually lasted and created this this hot market for open stack engineers. That makes us all very well paid. So that's an unexpected development. You remember, we started off with me saying that I did not make my 100 million dollars. That was your plan, not mine. Well, next question or anyone? No, I don't have a good unexpected. I can't believe there's still not so many women. I guess I have to say that like, I'm like, really? I can't. There are more and we're growing every time. So that's it's it's full of promise full of potential get more women here. Yeah. But like, yeah, the there's four. You guys haven't gotten the meta cloud playing card deck. You definitely should get one of them because our faces are in it and that's a great narcissism boost. But maybe not for you, but it is for me. But but if you look into this, there's, there's exactly four women in it and each one of them are the queen of something. Right. And and that's, that's, that's cute. But sadly, you know, and was pointing out that that's actually that's one female card off from being the appropriate percentage percentage of women attendees at open stacks at summits. And if that doesn't put in perspective for you, what that percentage really is and obviously shouldn't be. It's good visual. Yeah, it's, I mean, for four playing cards. But I never expected to travel the world like we have and I never expected to have relationships with true collaborators in Europe in Asia around the world. Like that's been amazing. That's true. So next question is, which are our largest challenges ahead of us? What? What can what should we fix? What is left to do? I think we, we, we had so much marketing hype so early, right. And then we had some explosive growth, both in the, in the code success and in the, in the community, that we, we never really got the chance to, to, to have that sort of second version iteration thing that oftentimes you'll have early on. You'll have like the early crazy thing you did over the weekend and you do it for a little while. And then you're like, okay, let's rewrite that. And then we'll, then we'll be serious, right? We're, we're basically having to, to, to do a 5,000 person summit on, on the basis of something that we're, we, we can't like we have, we have to organically iterate on, on this thing that we've got right now. And it's doing a great job for lots of people, right? But like we, we didn't, we grew so fast. We've got to, we've got to, we have to keep making this thing work and move forward. And I think that at the scale of humans we are and, and how in use this thing already is, everybody wants it to be so many things. And we can't just, we can't, you know, we can't just take a chunk and throw it away because there's a billion people using it already. And so I think that's figuring out how to, how to move that forward in a, in a sane way is, is the sort of the ongoing challenge. And it's not going to get any better. To me, the current challenge we have is, is around the project structure. And we've, we've been having those discussions lately on the, on the design summit side. Try to not be limited by the project structure that we said we'd be built early on. We iterated a number of times on the way the, the, the various projects are structured. And we, but today we are reaching a new, a new, a new level where we need to adapt again. Because, because the current model doesn't fit what, what's required of, by our ecosystem. And, and so this, this is like the next challenge for, I mean the very next challenge, basically. We need to evolve the project structure so that it's not constraining our future growth and, and doesn't prevent competition, doesn't prevent interesting projects from, from being taken into account. And I think that's the, the next challenge for me. I think our biggest challenge is struggling with how we define ourselves, like what actually OpenStack is over time. Because the, the growth has led to this, the situation where we have everybody wanting to be part of the community and have this great expanding, growing group of people working on many different things. But that creates confusion and a lack of focus in terms of us really defining OpenStack. And, and the reason that definition is important, which is the other piece that I think we need, the biggest challenge we have is, is interoperability. When, when we have a loose definition of OpenStack, it makes it very hard to give guarantees to the community around what is interoperable and what works together and what doesn't. And when you have something that's growing this quickly, it's very hard to define it and, and give it a full set of full structure. And I think that structure is going to be a big challenge that we deal with over the next couple of years. What is OpenStack? What does it mean to be OpenStack? How do I interoperate with different OpenStacks? Like can we really, because that's really what we need to achieve those goals that we're talking about taking over the world and being, you know, a bunch of little clouds everywhere, you can't do that without some kind of definition. I think that's like the, the really big challenge, like the elephant in the room. Yeah, but I, you know, there's little, there's smaller challenges, how to get enough people who know Nova well enough to review it, reduce the technical debt. Not that that's a small challenge, but it's a piece of the puzzle. I also agree with Jay that we have a big challenge where we have huge adoptions of our APIs and there's applications built everywhere, specifically for OpenStack. That, I mean, I'm running the numbers, I'm looking at the support, I'm looking for the developers that are application developers. And so there's so much, even though I led with like a contributor developer challenge, the other challenge is the application developers supporting them, giving them interoperable clouds. Yeah, I guess it always comes back to that large one, right? And another point on that is we, we are too big to know everyone and assume that our culture, our common values will, will naturally spread to new, the people that are joining our community. So scaling that culture, we have lots of unwritten rules, we have lots of principles that are, that we take for granted and that we expect newcomers to also adopt. And, but we failed to maybe document those shared understandings in a way that is consumable by new, new community members. So scaling our community to past those, this new number of people we can't really connect with and have a success there. I think, and I think this has come up a few times from, I think it came up in the keynote panel on Monday. The, as far as that goes, we're also reaching out more and more into, not just to non-English speaking, I mean, because, you know, we've had you around since day one, so we've always been at least slightly non-English speaking. Sure. But we're actually getting into, into more and more into non-Western cultures, right? And if we're actually going to be sort of global, then things that we take for granted as a basis for our culture as we interact with, you know, new friends around the world are, we have to encounter those. But also, it's not just about assimilation. Like I certainly hope we don't like attempt to be an American-style hegemony, right? Like this is, this is, as we, as we meet new people and bring them into sort of our culture, they're going to have, they're going to have cultural values and new experiences that are important for us to engage with. And that's, that's a, that's a, that's a big thing. I mean, like that, that isn't been really all that successful in the history of mankind, honestly. But like if we're, if we're going to do that and we're not just going to bulldoze people over, then that's an important thing to grapple with. I would say for me, looking into the future, the, probably the number one challenge of the OpenStack community is actually, it's challenged personally that I, I have, which is learning to say no, right? I think that, especially with the, with the growth in the number of vendors and the number of developers and contributors, operators, and employers, and business folks that are, you know, relying on, on OpenStack, building businesses around OpenStack, obviously using OpenStack in, in IT infrastructure, there are just, it's, it's just a never-ending stream of feature requests. And constant pressure. Constant pressure, you know, whether it's NFV or, you know, IT, enterprise art, IT stuff, it's, it is a constant stream of feature requests. And even if you had a million developers, you know, working out, you still can never keep up with it. And, you know, one of the discussions that we've been having in, and certainly in the NOVA contributor team, but also just across OpenStack development is how, how do you prioritize what you work on, right? And we've, we've had a number of different proposals and we've, we've hashed out a bunch of ideas. But I think solving or answering that question and, and getting tools that enable us to say, we're going to focus on this, you know, these few things for the next X number of months. And we're going to not, not do this. You know, we're, we're not going to look at this. We're not going to work on this. We need to, we need to learn how to say that. You know, we need to learn how to say no gracefully and explain in, you know, very clear words why, why we're focusing on some things and we're not going to do others. And it's a natural consequence of the meritocratic model we built where, where technical people are in charge. We don't want to say no because we want to be nice. Right. And it's not just, you know, the, the technical side, right? I think a lot of it, you know, is a product management. We need to take some, some best practices from product management communities and be able to project our roadmap in a way that people understand and, and can, and can deal with. Yeah. One of the, I mean, we've, there's been a lot of talk about need for, for product management in the, in the project. And I think actually one of the, one of the things that we really need to engage with or think about there is that we spend a lot of time early on. And we've done it sort of throughout of how do we, how do we allow 2000 developers to, to collaborate in a, in a, in a leaderless model where there is not a top down command and control structure. Right. Because that's something that normally doesn't scale to the size because we've built that. It now means that as we, as we look at bringing the product managers from, from the different, different interests that are, that are, that are, that are going to be involved with us together. We, we kind of have to, to develop a, the same thing, except that at least in the development side, we had a whole bunch of open source history on our, on our side and we were just taking the next step. There is, I would say, zero history of cross company product management collaboration in this particular, in this particular way. So like there's, it's going from iterating on something to inventing. Right. There's not a, there's a, there's a long history of developers working in the open source community together. Right. There's not so much of a long history of product managers working, you know, cross company saying, oh, you know, let's get together. And, you know, so, so I, yeah, I think we are hitting, we've hit that wall and, and, and that to me is, is probably the biggest challenge in the next, next few years. Okay. So we have 10 minutes left and I want to open the, the floor for questions from the audience. Do you have any question for Mark? My question for Mark is Mark, where are you? No answer. Any questions anyone? Go for it. There is Mike. There's a microphone over there in the halls in the room. You've got mics all over the place. It's crazy. Or just scream. It's fine. So this is not a question. Just a comment on the last statement. My name is Sean. I'm from Red Hat. I'm one of the product managers that actually work on OpenStack. And that's what I do for a living. And I just want to give you an update that this actually is one of the themes that we saw in the community. Right? This is, this is bigger than just one entity would like to represent their sort of interest in OpenStack. And we have in the foundation, the storage of the OpenStack foundation, we actually realized that. And this summit is the first summit when we actually had a meeting with all the influencers of OpenStack. So all the product managers actually met for the same time, first time here in this summit. And I believe that's a good start to get us what we need and actually start looking ahead of what we need to do at the project level. Right? And our goal is to start putting some governments inside the project so we can scale up in all that. So I believe that the first seeds already been laid out this summit. And it's a good indication of the maturity of OpenStack. And we got to this point now. And we need to put some formation in that. So I believe we're going to see more seeds of that in the next upcoming future. That's very good to hear. All right. Thank you. OpenStack is often compared to Linux at a number of different levels. I'd like to ask about the economic comparisons. When you go back, when Linux was four or five years old, you could go down to, you know, a computer land store and buy a box with Linux in it. It would be about $80. And if you got tired of paying $80 and you had enough bandwidth, you could start downloading the same distribution for free. And then over time as Linux matured and the enterprises adopted it, people wanted a higher level support and started paying for it. It seems to me that OpenStack has jumped to the end point where you can't get an upstream, you can't take the upstream OpenStack unless you're incredibly skilled and make it work. And the entry cost for somebody using it from a commercial vendor is, I don't know what the average is, somebody quoted me yesterday, $3,500 per node per year. Those are very high prices if you're trying to convince people that, you know, Amazon is too much money. I'm wondering what you think about the economic model of OpenStack and how that relates to the current state of the product. Anyone wants to take it? As someone who's never paid money for, well, any software, really, I don't quite know the product side probably as well as I should. So I can't really speak much to that. I do know that you are absolutely correct that it is way too difficult to get a simple running, well, is there a simple OpenStack system? I don't know. But you are absolutely correct that it is difficult to install and deploy OpenStack and get it running in a simple fashion. There's lots of ways to do it. There's lots of different guides. We do have upstream guides and there is an OpenStack release, like an upstream release, but you're absolutely right. There's different distributions, Mirantis, RDO, Ubuntu Cloud Archive, you name it, Appliances, Nebula, Piston. I guess my answer is that I don't know whether we jumped to the end or whether the vacuum was just there from the beginning and was filled from the beginning because it's hard to install and configure highly distributed systems. It's not like you're installing a Windows application on a single box or something. It's just inherently difficult. I think we're actually at a point where quite early in the Linux ecosystem where people want to build a supercomputer out of it, but it's only four years old and if you wanted to build a supercomputer with Linux by that time, you would pay that type of price. So we still need to potentially make it easier to deploy and consume directly from the upstream project so that a small university can set it up without having to resolve two crazy prices or a team of 100 to do it. There's a big difference in what's happened since 93 to now. One of those is that I'm much older than I was back then. But OpenSource in a lot of ways is one. It won a lot of the battles. It's become the de facto... When you do something that isn't OpenSource, you have to justify it now. I'm going to look at you funny and basically call you an idiot. That isn't ridiculous at this point. It would have been ridiculous 20 years ago. But that means the unintended consequence, I think, of the resounding success of OpenSource overall is that most of the people working on OpenSource projects now are not doing it in their spare time. They're not doing it on the weekends. They're working for companies and they're working for companies who are involved in those projects, which means that I think that the economics of OpenSource in general have changed. We don't have things... Docker is a company. It's not a project. Ansible is a company. All of these things are being driven by that. All of them from a very early age. So with something like OpenStack, we had companies get involved immediately because it was in fact the only way to get developers on it. That is a very interesting... I think the OpenSource as hobbyist, that ship has sailed a long time ago. So long ago. I think the economies of OpenSource in general, not OpenStack specifically, I think the economy of OpenSource changed quite some time ago to be driven in large part by corporate contributors. When I say corporate contributors, I just mean people that are employed to work on OpenSource not necessarily that all they work on is corporate or vendor-specific stuff. I'm just saying developers who are employed to work on OpenSource. One more question. Morning. Thank you. If you could change one thing since you started from the four years ago, what would it be? OpenStack. I mean, not in the world, but in OpenStack. XML. I wouldn't have picked Python. There's a scaling... I feel like some of the scaling problems we deal with would be much easier in a statically-typed language and in a language that is built more for large-scale teams. Python is a great language for small-hack projects, quick iteration, like some of the stuff that was good early in the project, but at the current scale, I feel like it gets in our way sometimes. I'd agree with that, and I was one of the early proponents of... I mean, I obviously didn't make the decision to write Nova in Python, but I've been a Python person for years and years, and I was actually one of the reasons that I thought this was a good idea. I was like, woo-hoo, yay, Python, that's great. And yeah, it's fantastic in so many ways, and also we're quite a large... We get at odds with some of the other folks in the Python community sometimes. She's like, oh, why are you doing this? You should do this other thing, and we're like, yeah, no, that doesn't work at our scale. And that's itself been some interesting challenges, and we've been working with people to try and address them that, but there's some fundamental things that I'd totally re-write in C++. I wouldn't. I'm fine with patterns, like the only language I can code in, so it's fine. It's a really good question. I'm trying to think about it. Why would it change? The other thing, and this is crazy, because this actually would make everything harder on us today if we did this right now, because we're actually trying to do the opposite thing, but in some ways our decision to make this... Or to keep it, it started off as two projects and two source code repositories. Our decision that that was to remain a good idea, rather than to make it a project with a whole bunch of endpoints and features inside of it and to solve the problem of how do you manage the internals of that, I think that we started down the road of keeping that separateness and that's led us into some interesting places that I think feed into some of the product management woes and some of the other scaling problems that we have kind of come back to that. So we just shove it all back into one thing that would... Out of time maybe in last comment. I was just going to say, I don't know if Soren Hansen's here, but he probably would appreciate this, but I think our heavy reliance on centralized database systems within a number of the components is a design choice that looking back, if we could now undo a lot of stuff around that, we're going to be struggling to un-centralize a lot of things in the next few years and hindsight's 2020, it would have been nice to design things a little differently on the data layer. One femto question with one femto answer. A lot of pressure. Thanks again, I think it's pretty clear that OpenStack's a great example of how to kind of come together as a community and develop code in a way that also fosters a healthy competition, but there seems to be some market pressure starting to come around the perimeter of open source type initiatives. Do you see any sort of clouds on the horizon in terms of influence from other public cloud providers or other entities, or is that something that's been on your radar as of yet? I think we've been pretty resistant to external pressure. Originally, it was like, oh, Microsoft will kill you, or this company enters the OpenStack space to hurt you, and it never happened, and it's true that there are new initiatives that are coming that are copying parts of OpenStack and not the whole model. I don't really care about threats. The biggest threats I see are just in terms of hype, like Docker, Kubernetes or two that have gotten a huge amount of attention. It reminds me of the early days of OpenStack before there was a lot of meat to it, and it was just a lot of, oh, I've got to use this because it's the new hot thing, and that I think can distract people from getting real work done sometimes because you always want to be on the cutting edge and using the cool new thing and sacrificing something that maybe works already, but for something that might work a few years down the line. Yeah, I would say generally my personal philosophy is to not worry too much about, let other people compete and do their own thing and focus as much as you can on making your own stuff as good as it can be. Otherwise, it's just going to be a constant rat race where you're constantly trying to keep up with XYZ. Well, thanks everyone for keeping up with us. Thank you.