 There you go. Thank you for coming. Really appreciate it. For those of you who don't know me, I'm Randy Bias. I was formerly the CEO of Cloud Scaling. That's our lovely logo up there, which was acquired by EMC in October of last year. I want to say thank you to the OpenStack community for whatever that's worth. Maybe people watch this video posthumously, but because of OpenStack, I was able to build a really great company and then to exited it to another really great company. Without OpenStack, I'm not sure that would happen. Thank you very much. For those of you who are new to this, I haven't done it in a couple years. I was a little preoccupied last year, as you might expect. The whole idea behind the State of the Stack was to try to give kind of is honest and unbiased kind of a view, end-to-end view of OpenStack as possible. What I really tried to do in the first and second versions was really sort of say, hey, this is what OpenStack is and unpack it and show you all the pieces and what they were good for and what they weren't good for. To be honest about it, I wanted to do that this time too, but then I realized as I started that was going to be very hard. It was going to be hard for a few different reasons, one of which we're going to talk about today. The first is that there's just a lot more stuff. From four years ago, there's just a ton more stuff. There's like 19 or 17 or 19 projects in this release, so it's just hard to cover them all. And then the other thing is that there was, I hate to say this, but there was a lot of almost self-denial when we approached PTLs and we said, hey, we're doing a SWOT analysis, strengths, weaknesses, opportunities, threats. Why don't you tell us what's great and what's not great about your project? And a surprising number of PTLs were unwilling to tell us what they thought was bad about their project, which I was very disappointed in, because as we know, everybody's software sucks. So it's just about figuring out how your software sucks and fixing it. So today we're going to talk about some of that. So I was part of the original OpenStack launch in 2010. I've been on the OpenStack Foundation Board of Directors since it was formed. I built some of the earliest clouds and the very first cloud that Cloud Scaling built was in January 2011. It was the first Swift public cloud outside of Rackspace anywhere. So that was six months within the launch, within six months of the launch of OpenStack. And then some people seem to think that I've got something interesting to say and they like to call me top whatever, whatever, whatever, you know, that's all good. And this watch is going to drive me crazy because people are tweeting and it's telling me all about it. So we're going to take that off. So traditionally I would talk about what winning looks like and it's good to start there. And then my co-founder Adam, he always told me that if I had to deliver bad news, it was best to do it in the format of kiss, kill, kiss. So kiss, kill, then kiss again, right? So we're kicking ass. We're still the fastest growing open source community ever, right? These are the stats directly from the foundation. You know, it's just stunning numbers, just absolutely stunning numbers. One of the other things I like to look at was sort of trends, Google trends, like, oh, by the way, I'll just back up real quick. If you want this deck, it's right here, tinyurl.com slash sots-v4. You can continue to take pictures of all the slides if you like, but you could get them in a high-res PDF instead, tinyurl.com slash sots-v4. Okay, so Google trends, right? You know, this is what sort of calculates or looks at the searches that people put into Google. So I used to show this as kind of OpenStack versus Eucalyptus and CloudStack, but I think this is even more interesting, right? I mean, look at OpenStack closing in on vSphere, right? vSphere has a massive, massive enterprise presence. And the very fact that we're closing in on its mind share, the amount of people who search for OpenStack is almost as great as those who search for vSphere. I mean, wow. Up and to the right, number of contributors in the community. Up and to the right, commit volume. Up and to the right, active developers. See? I told you I wanted to download it. This is a new one. Oh, by the way, I tend to go fast through this because I have 49 slides that we're going to present in 40 minutes, so, you know, hold on to your hats. So this is really interesting. And the Redmont guys were using the LinkedIn API to do an analysis of people who were in groups that were either related to Amazon Web Services, Azure, or OpenStack. And that blue, middle line that's OpenStack. Look at that. Look at that arc up. I mean, that's just really phenomenal. There's as many people in LinkedIn groups for OpenStack as there are for Amazon. That is an impressive achievement. I'm just really impressed that we made that happen. I mean, that shows that the level of interest in making OpenStack awesome is there. So why did we win? We won because of this explosive growth. We won because, you know, we created a certain amount of hype. You know, we got out. We started executing. We made things happen. We had a big tent. We had a lot of people in it. You know, we went from two projects to 17 projects. All that stuff's really, really awesome. And it's also really, really scary because, you know, unmanaged explosive growth can lead to some pretty severe problems. And I think that's where we're at now. So we should take a look at it. Just kind of review it together. This, thanks to Shamal to hear one of the EMC folks that I work with. Shamal, you're here. Raise your hand, please. Thank you, Shamal, so much. This is his kind of like way of sort of spreading out, right? There's so many projects now. There's 19 projects here. That's why this is sort of like an eye chart, right? It's just hard to capture them all. And, you know, we've got the core, right? Sort of the infrastructure as a service piece, then all the pieces that kind of manage it. And then the, you know, pieces that kind of provide services to different, you know, applications or platforms that really consume it. And then kind of the common underlying components as well, right? This is a lot. And if you were to look at this and you're coming into OpenSec for the first time, you're going to say to yourself, wow, where do I start? And if you're a developer and you're trying to figure out what are the dependencies between these things, you wind up with a spaghetti ball, right? This actually comes from the references.txt file and the GitHub repositories that describe the dependencies between these projects. And we kind of manually put it together, kind of a map between all of them. Now, when this was only two, and it was Nova and Swift, it kind of had one line, right? Now it's getting much, much worse. And I would guess that we're going to get closer to like 30 projects in the near term than people expect. So, you know, just imagine what that does to this picture. So, earlier this year, I kind of, you know, called it out, because I guess that's my specialty. I like it when I sort of, you know, call people on the mat for things. And, you know, and I just sort of said what seems pretty obvious to me, and I think it's probably obvious to you as well, which is that, you know, that explosive growth is actually causing quite a bit of risk. And, you know, it's not just me. There's other people in the community who see this as well. And surprisingly, I see more people in the TC who see it than I saw on the board who see it, although I would say generally most people see it. So, that's a little bit of the sort of, you know, foreshadowing of kind of, you know, where the danger lies. But, you know, we've been making a lot of improvements and actually we've been doing this very, very fast. So, September last year, I got on stage at OpenStack Silicon Valley. I made a lot of noise. Basically I said we're not doing product management. Everything's a complete shit show. We need to get our shit together. And then a whole bunch of really, really smart people, much smarter than me. A lot of them in this room decided to form the product working group and really try to figure out how to organize a multi-release roadmap, how to figure out how to help the technical committee out in terms of serving the long-term planning, how to help evangelize inside of their organizations about sort of shared values around certain key blueprints that need to get prioritized over others and how to fund those, how to make sure people are actually working on the right work, so that it wasn't just a bunch of people kind of doing what they felt like doing from day to day. It was sort of more organized, more strategic. So that's pretty kick-ass. I don't know if you went to the multi-release roadmap presentation the other day, but I think the room was totally packed, even more packed than here. So like I said, they're smarter than me. So continue to go to those and support them. And thank you to the people in the product working group because I just kind of, I start the problems and then other people kind of go and clean them up and I'm very appreciative for that. The other thing like I said is the TC has been really, I think they were some of the first to really understand that the weight of the open sec was just becoming just too much. And the reason was because when we were trying to do an integrative release with Swift and Nova, no problem, right? When it started to be like 17 projects, they all had to be tested together and validated together and all those teams had to be managed and encouraged and guided. It just got to be really, really hairy. And so the TC really led by Terry kind of helped figure out kind of this reform, this kind of big tent reform where they said, let's get rid of this six-month integrated cycle. Let's think about what people assume the integration or core, these things mean. Let's try to break things down and kind of come with a sort of more loosely coupled organizational structure. So again, you should check out some of these slides offline. This is just some information on the product working group. I think you should talk to folks in the product working group rather than me tell you a lot about it. The important thing here to notice is that we're trying to coordinate as well with the user committee. So really working very actively with the user committee because one of the places where we haven't done a good job is going out to the people who use our clouds and I do not mean the people running the clouds. I mean the application developers putting applications on top of the clouds and really talking to them and figuring out what's working and what's not working. This is just a quick slide on the big tent release cycle. There's a URL here where you can go and get more information on the move towards this sort of tagged release model. I think there's a keynote and a bunch of other things about this. So again, I have no need to cover this in detail. But it's not enough, right? These are two brand new initiatives. They've only had about six to nine months to really get going. You know, we're starting to see the fruits to our credit. That's actually a lot faster than I expected. But the problem is that complexity kills, right? You know, I used to say when I was running the business when people kind of mean when I was running clouds again and then asked me how we go and approach solving a certain problem. I said, do the simplest, dumbest thing possible that solves 80% of the problem, you know, the MVP, right? And the reason was is that when you start stacking simple things up, together they inherently get complex. When you start stacking complex things up together, you get this exponential curve in complexity, which then causes brittleness, which then causes things to break. So to give you some perspective, here's some information from the RightScale State of the Cloud report which just came out a few months ago. They're sort of this, you know, kind of bell curve with, you know, kind of people like, core people in the middle who are just now experimenting or starting to build clouds. And if you look at sort of their top challenges, they either can't get the resources and expertise they need or the complexity of building a private cloud is too hard, right? So this problem of building a private cloud, this exists beyond OpenStack, right? This is why I always kind of just like do the face palm when I hear people say, wow, CloudStack's easy to deploy. And I'm like, if I only have to deploy Nova, then yes, that's much easier, right? But people are more ambitious. They want to do a lot more with their clouds. They want a private cloud that has a lot of value for their internal developers. And so there's inherent complexity in just building a private cloud. You have to understand networking and storage and compute. You have to understand different types of compute now, bare metal and containers and virtual machines. I mean, all of this stuff is very hard to put together. And so these folks, the average enterprise that wants to use our software, is struggling under that complexity. They're, dare I say it, dying under the complexity. Now if we look at something adjacent like Docker, who's used Docker? It's drop dead simple, right? I mean, it's, you know, it really takes nothing to get Docker up and running on a laptop or even 10 servers, right? It's very, very trivial. And this has really led to it being adopted much faster. So in the first half of last year, they had 3 million downloads. And then in the second half, they had 100 million, right? That's just a crazy ramp, right? And you can look here on the right-hand side where people who were previously looking at Chef & Puppet, and I'm a long-time Chef & Puppet user, so I'm not trying to throw them on the bus, but they're starting to think about using Docker to replace those. And the level of interest is so high that it's about to eclipse both those tools, because it's simple, right? The reason that your average enterprise IT guy likes to use a virtual machine images, that's a terrible way to run the world is that it's simpler. So the moral of the story is that if we want OpenStack to be successful, we need to make it simpler. We need to figure out how to make it simpler, at least to get your feet wet. Right now, there's a big gap between DevStack and what you need to do to run on 10 machines. So I'm sure you've all seen this technology adoption curve before, right? So one of the things that's really interesting about this is that all technology goes through this, right? All technology, right? Something happens. There's some kind of trigger event where suddenly, uh-oh, we're going to have a mic misfilter here. Excuse me. And is that... So, last time I tried that. So what happens is there's a technology trigger. There's a need, right? There's a problem. There's a pain point. So people come up with some way to solve that problem. And then, you know, everybody starts piling on. They're like, oh, man, this thing is awesome. It's going to solve all my problems. It's going to feed my babies, cure world hunger, right? And that's where OpenSec was pretty recently, up kind of that peak of inflated expectations. That's where Docker is now, man. Everybody's like, Docker is going to save the world. But we're kind of sliding down the other side right now. And we're headed towards, you know, the trough of disillusionment. And this is where people start to give up, you know, kind of hope on this new technology and start to walk away from it. So we're headed down, right? If we don't take care, if we're not cautious, if we don't think about what do people need to be successful with OpenSec, we might derail. And I don't know about you, but I would not want to derail at the bottom of that, right? So we have to really think about this. We have to really be honest with ourselves. One of the things that has been frustrating to me is that there are elements of the community that want to be in denial about problems that exist that are obvious to the vast majority. So my job is to come up here and basically tell you what the hell those things are. So how do we know that we're kind of running down the other side towards the trough of disillusionment? Well, there's a lot of growing skepticism. Even inside of OpenSec, but I don't want to call anybody out, there's growing dissatisfaction with certain aspects of OpenSec and I think that's really important because it's leading to failures in the field. And I'm not going to give you my percentage estimate of the failures in the field because that would get quoted widely and be really misused, but it's way higher than it should be. So I think that we probably reached peak OpenSec. It's up to you to figure that out for yourself, right? But that's my estimate. So this is some information from Gartner and some others. There's a lot of quotes you can go find, but what I found most interesting was this one at the bottom which I want to call out to you, which is that what's hilarious is that it dovetails completely and I found this like last night. It dovetails completely with what I've been thinking and what I've been hearing, which is that number one is difficulty of implementation is a problem. Two, shortage of skills, people who can actually build these things. Three, conflicting or uncoordinated project governance and this is stuff that we started to address with the Big Tent approach and things like that, but there needs to be more. Weak spots and some projects and then integration with existing infrastructure which I violently disagree with. If you're building OpenSec Cloud, you should probably do it on the new stuff, on net new stuff, but Gartner is smarter than me I guess, supposedly, but this is pretty smart. So on this number four week spots and some projects, no, I'm just going to keep going. All right, so last week, kind of under the gun, I realized that I wanted, I didn't want to just get up here and tell you what I thought was wrong. I thought that it would be better if I could get more people's opinions. So I tried to put a survey together under the gun to kind of get some feedback from people and you could take it right here, tinyurl.com slash improve dash open stack after you download the Sats presentation and that would be very helpful and I would really appreciate it. But the idea was just try to figure out like, was I crazy? Was I seeing stuff that wasn't there? Was I on a POT trip or something? I don't know. So first is we asked who people were and because of the time crunch and because of the limitations of people who follow me on Twitter, because most of them are not native application developers and so on, we didn't really get any of the actual open stack end users, the people who deploy apps on it, which kind of sucks. But even the user survey has problem getting those people so I don't feel bad. And then most people who responded were actual open stack developers or operators. So I had to set baseline, right? What do you love about open stack? What's your favorite project? Well, as you can see, it pretty much lined up with kind of the maturity and the length of time that projects have basically been around Nova and Swift at the top, the size of the actual communities working on those projects. So that's no big surprise. But then Neutron came in at number five, which was a big surprise because it turns out that Neutron's also one of the most hated. And so what was funny about that is that you look at that previous slide and it kind of lines up the way you expect, but in this one when you say, hey, which project do you not like in open stack? It turns out that there's sort of an overwhelming bias towards Solometer and Neutron. And you probably all heard that this week. And this is unfortunate, especially with Neutron, which is almost four years old now. So the user survey, I don't know if this data came out in the blog postings or if you had a chance to see it. You might have seen some of the top level user survey data. But what was interesting was the actual, some of the comments that they got back, right? Neutron is a lot more complex and harder to provide real HA. Complexity availability and scalability remain some of the concerns of the operators, right? So this isn't just me saying it, like there are people out in the field doing things with open stack and they are saying Solometer and Neutron are not working the way that we want them to. This was a part of the user survey that asked if you're using Nova Network, you know, why can't you move to Neutron? Number one reason, it needs to be simplified. So I thought to myself, and this, you know, I figured this would happen. So this is why I had this question survey. I thought to myself, you know, well, if there are projects that people do not like, why the hell aren't we doing something about it? And I thought maybe the community has an allergic reaction to actually throwing away stuff that's broken. Because like in a good technology business, right, a startup, or even a big business, you kind of build a V1, you learn a bunch of things in the V1, and then you realize that the way you were going about solving the problem was wrong. Like the architecture is fundamentally wrong. You can't iterate and kind of like, you know, fix it a little bit at a time and make it a better thing. You just have to throw the thing out, take everything you learned and do it right the next time. And I asked the community how they feel about that and it turns out that everybody is totally good with that. Except for some people who I just guess haven't really been to business. So why can't we fix these? And what the hell is the problem? We say that they're broken. You know, we say that they're causing problems in the field, that they're helping with the slowing of the adoption, that they're causing grief, that, you know, they're giving us a bad reputation. You know, we say that we should be able to throw away, you know, bad V1s and bad V2s of code, but yet we're still apparently not willing to throw these pieces away. And there is precedent. You know, Keystone was rewritten three times, right? I mean, apparently communities, a whole has the ability to do it, but for some reason we can't exercise that with certain projects. So this is what the thread is, right? This explosive growth is going to create that complexity, which is going to slow adoption, which is, you know, driven by our inability to partially reinforce our inability to kind of fix or address some of the projects. I also think that if we look at the governance model, right, this is part of what the TC is doing. They're trying to make the governance model less rigid, right? We just, we don't, we have too much centralization. There's too much need to go to the central party to basically get things fixed, right? We would, I would prefer an organizational structure that was more loosely coupled, right? Because that's the way we want the code to be. And then, you know, there's still kind of a gap on long-term vision and product strategy. We're working on it. The product working group's doing great stuff, but there's a need for more, right? And I think that we just need to double down on all those efforts. So, back to the kiss. How the hell do we fix this stuff? I think it's, I think it's trackable. I think it's trackable. I wouldn't bother being up here and talking about it. We want to be over there. We have to get through this traffic disillusionment without derailing the train, right? That's what we got to do. This is my idea of a five-point plan to kind of address this. You know, I'd like to streamline the governance model. And I'm not talking about radical changes. I'm talking about the same kind of changes we've made recently. I'm talking about, you know, considering empowering projects more. You know, there really should be kind of almost a TC for a project. That's the way the Apache Software Foundation works. It has something called the PMC. And those folks pretty much just own the project. And they're not beholden to anybody else. And that would also help the working, the product working group focus. And I'm talking about sort of like high level things here, right? I'm not going to say exactly how that streamlining should work. That's a conversation, right? You know, I have a bias towards what I'm making it look more like the Apache Software Foundation. And we're not far from that. But you know, if we can figure out another way, that's fine. But the important thing here is that individual projects need to be empowered to either succeed or fail on their own. And we should not be propping up the failures. I think we need to allow competition. This is very controversial, right? We need to allow non-Python languages. We need to allow competition between projects. A lot of people get really bent out of shape about this. They're like, well, we don't want something to come in and compete with Nova. Okay, fine. Let's not go that far. Is it okay if we have something to come in and compete with Solometer? Because I think that there would be a huge amount of community that would be just fine with that, right? Right. So, and then, you know, something like Neutron also probably be controversial. Because it appears, according to the survey data, it's got a love-hate relationship. People just love Neutron. I mean, they're network guys, I guess. And that's fine. You know, they can love it. But, you know, I don't think it would be a problem to bring in a competitor to Neutron. And to be honest, like, does anybody think that the path that Neutron's on of doing Layer 2, Layer 3, VPN as a service, Firewall as a service, Load Bouncer as a service, name your network thing as a service is actually ever going to work? I mean, talk about boiling the ocean. It took, like, a huge industry, a multi-billion-dollar industry 30 years to build that functionality into hardware appliances with various APIs and all kinds of different semantics. I mean, you just can't roll Layer 2 through Layer 7 up into Network as a service. It's not like storage. Storage is relatively simple. It's kind of got three basic, you know, approaches. Right. I'm conformed in well-known APIs and I'm going to rant about this because it's driving me absolutely nuts. You know, Intestable Reference Architectures. This is my personal hot button. Like, if we had all these different projects that were good for all these different things, then we should be able to assemble them kind of for different kind of use cases like OpenStack for NFV, OpenStack for Republic Cloud, OpenStack for Enterprise Private Cloud. And I'll talk about that some more in a second. But, you know, this is what I think people want. They come into OpenStack and they're like, I need OpenStack. But then the next question needs to be like, what do you need OpenStack for? What are you doing with it? Oh, you're going to do NFV. Okay, come over here. Here's, like, a place to start. Here's a blueprint of a map of how you put OpenStack together for NFV. Here's the recommended components. Oh, and by the way, here's a testable, here's an interoperability test suite that can verify that once you put it together, it works the same. So you want to take OpenStack and take Neutron out and put Open Daylight in because you're whatever big carrier, you know, fine, do that. As long as the interoperability test suite works, then we're all good to go. Why shouldn't we allow that? Okay, maybe they can't call it OpenStack, but they're using OpenStack. They're part of the community. They're probably going to contribute back. You know, they don't have to use all of OpenStack. And then last, you know, ruthless simplification. And this needs to be true kind of across all things. Here I just call out one example, which is that when somebody first comes to OpenStack, they should be able to get, you know, something basic up and running on a small cluster basically in the corner with little or no effort and not using DevStack. Okay, I'll let you look at this offline since I'm probably running behind time and I don't have a clock up here, but I'm sure I'm running behind time because I bit off more than I can chew, as usual. And so this is just a map of kind of how the Apache Software Foundation works. And so some people might be wondering, why do I think that this is the way to do it? Well, it's because they're already running over 100 freaking projects. Okay? Right? We're struggling under the weight of 17. Okay? So I'm doing my startup over the last five years and I just keep saying to myself, man, I really don't want to make any mistakes that anybody else ever made. So I would go get people in to help me out who had done, who had made huge mistakes before. I figured it would be better for me to make new mistakes. Right? So I think that would be good for us, generally speaking. So this allow competing projects, right? This is very controversial, but it turns out there's already some leeway. Like, if you go and you actually look at the project requirements that the TC set forth, they say, look, you know, the project must cooperate with existing projects rather than gratuitously competing or reinventing the wheel. And when you talk to them, Terry and Russell, they say, yes, we don't want you to come in and compete with NOVA. But no, we would consider if you were coming in and you were going to compete with something that we think is broken, we would consider actually allowing that. So the door's already cracked open. I mean, I'd like it fully wide, but I will take what I can get. So, but I don't think people know this. They're like, oh, I don't know if I can, you know, cylinder's broken, but I don't want to do, you know, turn it to it. Instead, I'm just going to go get something else and integrate it. Well, I'd like people to know and walk away from this knowing that if you want to compete with some of the projects in OpenStack and bring that in, it is doable under the right conditions. Okay, and Python isn't good for everything. Okay, who here wants to raise their hand and tell me that Python should be used to basically code every freaking thing in the entire universe? Operating systems, low-level firmware drivers, nobody will do that. Thank you. So, please, please, continue to press on people, right? I get it, you know, developers want to come in and, you know, this thing kind of happened. Some of the people on TC would say, well, we want a developer to be able to start one project and go to another project. Look, if you're new to infrastructure and you came in and you learned everything about neutron, you know, the learning curve for you to come up to speed on like Cinder and Nova is so freaking huge anyway that like whether there's a new language you have to learn there or not is pretty much totally irrelevant. So, is OpenStack the APIs or the code? What if it's neither? You know, I was talking to Terry the other day and getting some feedback on this, so I made sure that I didn't say anything that would be putting both feet in my mouth. One foot's good enough. And he said to me, OpenStack is about community, common values and a common governance model. Not necessarily about the code of the APIs. And I said, man, that is brilliant. That's like the smartest thing I think anybody's ever said to me in OpenStack land, right? Because we're all here to accomplish a common mission. We all want a common outcome. I mean, that's just seems like a no-brainer, right? Like how we get there like the details of the APIs and the code and the languages we use, who gives a shit? I mean, seriously, who gives a shit? Sorry, that was me going a little berserk. The Keystone API. Sorry, I'm about to go berserk again. You know, WTF. Actually, I actually said the entire thing the other day. I apologize for that. But like, why does the Keystone API exist? Right? There are dozens and dozens of well-known and documented authorization and authentication APIs that are scalable. They have existed for 20 or 30 years. And there is no excuse for building a new API that solves no new problems and that almost certainly creates new security issues because the people who created it are almost certainly not security experts. And if Google can use OAuth 2.0 to authenticate all of its services, then OpenStack can too. This is inexcusable. This is inexcusable NIH. Not invented here. Just absolutely, totally inexcusable. This isn't even a public-facing API. My apologies to the Keystone Ptl and team. So these reference architectures I was talking about, you know, like, I just, like, what is OpenStack? Draw a line around OpenStack for me. Tell me what it is. Like, you can't. Okay, it's private cloud. Okay, great. Now draw a line around private cloud, right? I mean, you know, that's really hard. So I just think that, like, we should chop it up, right? We should have, you know, kind of like flavors of OpenStack. And these things are not necessarily, you know, competitive with each other, and some of them may even contain the other. So, for example, I said, hey, basic IAAS, basic infrastructure as a service, right? This should be something where you go to the website, you click a button, you download OpenStack, and you've got something you can run on five machines, and it's just basically one of the compute things, plus, you know, the OAuth 2.0 server. And then the advanced IAAS contains that, plus it adds, you know, Cinder and Swift or Neutron if you really want to hurt yourself. You know, and then things like the application services, right? You know, the message boss, you know, the database and service thing, DNS, like, you know, those things, like, please, somebody explain to me why we wouldn't allow databases as a service and message users as a service and DNS as a service to run on top of Amazon Web Services. People are running OpenStack on top of Amazon to, like, deploy their applications. Oh, and then they figured out that they can actually run the same set of services on top of Amazon as on Google Compute Engine, so now they're using OpenStack to give themselves public cloud independence. And then, you know, they suddenly figure out we're going to build something inside, and neither Google nor Amazon have a private cloud solution, so they say, why don't we use the rest of the OpenStack stack? Like, the whole idea that in order to, like, have any of these services work, have to deploy all of them, like, it's just, it's ludicrous, right? It would be better to chop them into pieces and to encourage them to be used together, but also to allow them to all be run individually and to have a set of interoperability test suites so that you can just verify that these things are actually what you expect them to be, because that's the big thing, right? If a person builds their application to talk to the set of services and OpenStack app services, they want to know, they want to know that when they move from one set of those to the other that it acts and operates the same. So this is what it might look like, right? We have interoperability test suite, which we already have now with ref stack. Thank you, all the people who have been working on that, Rocky and Company. And then that interoperability test suite tests the reference architecture. That reference architecture is something that's put together kind of in collaboration, right? We all kind of have some input on what those reference architectures are. A reference architecture needs to be the set of capabilities and the set of projects that are going into it as well as set of default configuration options so that what we're testing is well understood. And then there's some set of projects that make that up. Those projects have code, API unit tests, and then they have capabilities tests because the project teams own those, and those are what ref stack runs, right? A set of these tests for each of the projects. This looks really doable to me. We're already basically doing this. Def core plus ref stack right now is basically creating a reference architecture for what I'll call basic infrastructure as a service. The problem is, is that if you go and you look at a lot of people's intentions, they think that what Def core will become is that it will slowly expand until it encompasses all of this, right? And that people, in order to get open stack, you know, will basically get the whole ball of blacks, which of course doesn't make sense. Okay. Larry Ellison in his infinite wisdom explained to us that cloud didn't exist and wasn't a thing. And we learned that that wasn't true. Steve Jobs blesses hard to love the man, love what he did at Apple. He was assured us that streaming music would never happen, I guess, until Apple bot beats. You know, and there's just a lot of other naysayers, right? There's a lot of people right now who are watching us plunge down that rail, right? They're just watching it, and they're saying, like, open stack's over, it's dead, it's, you know, whatever. Fine, that's good. I mean, the criticism's great. Like, I get criticism all the time. And you know the thing I love about criticism, like, you know, people tell me on Twitter, I got my head up my ass or whatever. You know, is it like, it makes my argument stronger. Like, I'm like, okay, I was wrong. I'm gonna go fix that argument. I'm gonna go fix that fact. I'm gonna go correct it. I'm gonna make a cope. I'm gonna apologize. I'm gonna, whatever, eat crow. But the point is, is that criticism is not bad. Like, I don't want to operate in a community where we pretend that everything's wonderful, because, you know, it's not. The number one problem that I had when I was building a team at Cloud Scaling was I had people come in who would look at everything that was going on, and they'd say, wow, man, this is really awful. You know, we should do what those guys over there are doing. It was always the grass is green on the other side. Always the glass is half empty. The glass is half empty. I'm like, look, you live in a universe that's filled with entropy. Like, everything is falling down. Like, cities did not assemble themselves. Human beings came around and made them. Right? We live in a world where we're basically building sand castles on the beach. The waves are coming in all the time and washing them out, and it's our job to basically keep working on the sand castles, because without it, sand castles go away. Right? Nothing is ever perfect. We have to spend the time to figure out what's wrong and fix it. Right? And these guys will be made wrong if we do our jobs and we kick ass, which so far, we've been doing. We just need to do more of it and do it faster. So, I think we can do this. Like, I think we've got to just think about these projects as being interrelated and not interdependent. Right? I need networking with my open stack system going in a new drawing. No. No. That shouldn't be the answer. Right? Maybe they need to use open daylight for some reason, or they need to use big switch. Maybe they're a carrier. The carriers are not going to use neutron. Not in the shape it's in right now. Testable reference architectures that are interoperable. We need kind of like those reference architectures. We need flavors of open stack. Right? The Linux kernel runs in red-handed and prized Linux and it runs on an Android phone. On an Android phone, there is no GCC tool chain. There is none of that stuff. But it still links kernel. Exact same code. That's the way open stacks should be viewed. It should be viewed as something that can be used to build a lot of different types of cloud systems rather than just one because I don't think we can get there. The other thing that that really breaks free and maybe I wasn't clear about earlier is that we have a big tent. We have a lot of people around open stack who want to make it be a lot of different things. Trying to get all those people to conform. Like, I gave that fight up like two years ago. Right? That is not going to happen. Right? I was waving the flag like, my way of building an open stack is the right way. Yeah. No. That's not happening. Right? But if you have flavors, if you say there's reference architectures, then you leave the door open. Hey, and somebody could come along. Like, if people go this way, I'm going to come along and I'm going to build an open stack for AWS reference architecture. And maybe nobody will ever use it. But it will be there. And if you want to use open stack and make it as compatible with Amazon as possible, there will be a path. There will be a way. There will be a description that you'll be able to use. Streamlining the governance model. Right? We need to... Any time there's anything that's centralized that any decision-making has to go through, it needs to be broken down. Right? We need market dynamics. And that's how we'll get the survival of the FITUS project. Right? We're dropping up bad projects or programming languages that aren't working for particular use cases. And we need to really internalize this last thing, which is that open stack is really not about the code or the APIs. Right? I'm actually ahead of time. I cannot even believe it. I must have been talking seriously fast. And I apologize for that. I didn't even have coffee today. I think I just got in a rant or a rant in a role. So we need to remember that open stack is not the code and the APIs. I know it's hard. Right? I don't want to take my code and throw it away either. But I remember one of the very first coding projects I ever did. I did the prototype. And it was awful, like really bad. And when I got to the end, I was like, oh my God, I do not want to hack on this. I went back and I rewrote from scratch. And I don't like to redo anything. Right? I left my wedding ring and my wife's going to kill me in a freaking hotel. And it was only two minutes to walk back and I didn't want to walk back and get it because I have to walk back. I don't like to redo anything. But I learned the hard way on that first project that after I got that prototype done, doing the new thing took me one-tenth of time because I had solved all the problems. I had figured all the pieces out. And then it was basically in my head. It was just a matter of spewing it out. How many people have written an email and then to their boss maybe, that was like scathing. And then you stopped and walked away from the keyboard, came back and you edited it. Right? Pretty much everybody, right? Made it less scathing. How many of you like walk back to the keyboard and you're like, yeah, I just shouldn't even send this at all and just delete it in? Right? I'm not saying you throw out everything. I'm not saying we go around and we re-write all of them. It's like, God, no, jeez, there's so much in there now. I'm just saying that like, when something's obviously broken, we should be willing to throw it out. And we should remember that it's not about that code. It's about the learning and it's about the community that we have together. Right? So I hope that this really resonates with you and that you're able to take it back and think about it and share it with your teams and maybe share the deck. And I know I'm rattling the cage a little bit harder than I normally do, which is hard to believe since I'm pretty good at rattling the cage. But I think this is important. Like, there's a cultural change that needs to happen here. And we're so close. We're so close. Like, I can smell it. So, you know, I hope you all go back and kick ass. And that's the end of my presentation. Thank you.