 I'm going to go ahead and kick off. And thanks for all of you who made it out. I'm going to talk about StackStorm, cover a little bit about the company and the vision. And then I'm going to touch on some of the underlying code, especially the OpenStack code, of course. That is part of our project. The first point I'd make is we're 100% open source. And we wouldn't be here, obviously, without OpenStack. I don't mean just here, but as a company. We did launch the company last week, and we just announced that we're doing private betas. And I'll talk about the requirements for being kind of invited there. And I'll talk about the team and so forth. But this, you might wonder, why do we have a self-driving car up there? And it's not just a marketing spiel. We really do believe that. And we have some of the chops. And I'll talk about some of our advisors here in a second, that we're getting to the point that we need to automate not just all the things. Automating all the things is great. Yay, OpenStack. Automating the automators is what is really going to take to get to the levels of adoption that we're all betting on. There are not enough humans in the world who can operate OpenStack, who can write operations environments for it to be broadly adopted. So you've got to get to the point that the software is smart enough to teach itself how to operate better. And I'll talk a little bit about that. I've got about 15 minutes or 13 minutes and six seconds now. So I'm going to try to leave some time and let's try to have a bit of a conversation. That's me. I don't think you need to see my photo anymore than that. The quick point I would make is that you can see it in Dimitri's bio. Operations automation has been done before. A guy named Ben Horowitz did pretty well at it. You may have heard of him. Sold his company to HP for a billion five. We think this is the third wave of operations automation. And the difference is you have to have DevOps roots. Real DevOps roots. We can't come to you and say, we're going to help you manage your DevOps environment if you can't, let's say, externalize your configs right out of our product. So it's fundamental, and it's a big disruption. So who is this guy? So this guy is the father of, he's a Berkeley professor. We call him Professor Alberto, mainly because we don't like trying to say that last name. But he's the father of control theory. He's now working a lot in deep learning. And some of the use cases, and he's an advisor of Stackstorm, some of the use cases are things like when obviously a person didn't fly your airplane when you came here this week, right? 99% of the time, it was software doing that. Or indeed, self-driving cars. If you look at the big self-driving projects, they all have Berkeley alums on them. Five, six years ago, that was considered impossible. Today, it's starting to happen. But he also created the EDA industry. A couple of companies called Synopsis and Cadence. He was one of the founders there. And again, 25, 30 years ago, when he first went to Intel and said, guess what? I can automate the design of a system with a million, or now billions, of transistors on it. They kind of looked at him like, yeah, you're crazy, right? But now, in fact, it is a highly automated world. And something called swarm intelligence, which I won't get into, but it is somewhat frightening. But he's an advisor. And what he does and what he helps us do is understand, really, the algorithms, the domain-specific algorithms that people use to automate complex systems. And obviously, a famous case of this is Deep Blue. 1996, 1997, it was a big deal when Kasparov lost. And for good reason, right? Being able to think eight moves ahead means you're thinking through as many permutations as there are stars in the galaxy. I could do my Carl Sagan, but you get the idea. It's a big, big number. And today, your cell phone has that much power, right? And pretty much any decent cell phone can beat any human in the world in chess if you have the right chess program. So what seems impossible today, truly automating and creating self-learning systems to operate complex cloud environments in five, 10 years, will be how it's done. Any questions about this? So what this is, is this is actually out of a deep learning textbook. But it also sort of gets to what we do. So what StackStorm is, is we're not your input layer. We're not your monitoring. We're not New Relic. We're not Nagios. We're also not Chef. We're not the muscles. We're not the nervous system. We're the brain in between, right? It really ties together inputs into outputs. And over time, it's not science fiction. We will get better and better at it. And our algorithms will learn. And again, they had better. Because those of you who are operating clouds, you're doing amazing stuff. You're one or two orders of magnitude more productive than the kind of customers I worked with in the financials over the last 15, 20 years. It's incredible stuff. But you're also dealing with a more complex environment, in my opinion. And the challenge is how do you achieve those levels of productivity when instead of all these nice name brands, either nice name brands, but instead of that, you have 53 loosely coupled systems. How do you make the whole thing work together? And what we've learned, we've gone out and spoken to maybe a hundred of the top operators, is what they've done is what we're doing. They really try to close the loop, again, between monitoring and events and actions taken in a way that enables transparency. So everybody knows, how do we respond to this kind of action? How do they know? Because it's in the code, right? It's transparent documentation as code, if you will. And then they try to document in real time through auditing what actual activities are taking place. How did they go? And so forth. So that transparency and closing the loop is something that some of the top operators do. So let me try to get a little more specific. So today, if you are Facebook and you're running something they call F-Bar, you might be able to walk a common troubleshooting tree. In our case, we're really interested in putting into code the OpenStack troubleshooting handbook, effectively, or those pieces that are easy for us to, relatively easy for us to encode. But over time, and some of the top operators do this, you don't want to just throw up the information about a common issue. You want to actually remediate. You want software to be your layer one knock, not people. So if you've seen, there's some great stuff out there about how Google supposedly SREs don't wear pagers, right? Because they don't need to, because anything that happens at 2 a.m., if there's an issue, the software should be able to remediate itself. In life-cycling, my application, that's something we can help you with today. But over time, you want to get to the point that you can sort of anticipate the need, moving workloads around. That's being done. That is being done. But again, that's the kind of thing that self-learning could help you do better at. There's a famous case of GitHub, so we have an advisor from GitHub, a great guy talking about a denial of service attack they had in the fall. Thankfully, they already had the automation and they were able to trigger a response from a guy's cell phone. They were using, I think, HipChat or Campfire, one of the chat pieces of functionality, packages, and they were able to respond remotely. Pretty exciting. But over time, you want to really store, okay, what were those scripts or automations? How did they behave? How well did they do? Should we run that one again? And my favorite example for the kind of learning that we're enabling is maybe you want to wait your automations based even on who wrote the automation. Like, if I wrote the automation, maybe you take two points off the waiting. If some great operator wrote the automation, maybe you add 10 points to it. So there's some fairly basic algorithms you can apply to actually get smarter at how you operate these environments. And as I said, it's not science fiction. It's how, I mean, how do you think Facebook is obviously operating at supposedly 25,000 servers to one person when your typical financial is at 200 to one? Right? Calculate the workflows. Don't just assume you know what they are. Build some intelligence into your system so you get smarter over time. Queue them up. You can also do some stuff just prioritizing which things you're gonna, which things you're gonna automate when. So now I'm gonna talk in my, I have four and a half minutes. I'm gonna talk a little bit about the product, where it is today. Again, we are demoing at E26 Mistral, which is a piece of it. It is the workflows of service component that is entering incubation. We're not the only ones behind that. Marantis and Intel are contributing to this. Please stop by. Our code itself is in private beta today. And again, 100% open source, but not even ready to open source all of it. So we're at that stage. I'm gonna fast forward a little bit. Suffice it to say, automation is not a panacea if you don't have transparency. If you're not really sure if you have good access controls around it, if you are in this environment where, I don't know, if I'd be the cowboy. No, obviously the guy without hair on the right. But anyway, where everyone is doing their own automations, that's not a recipe for learning. That's a recipe for people not trusting automation. That's a recipe for the hero complex in operations, which is not good for scaling over time. A little bit of marketing, so I apologize for that, but it looks like the bald guy is smiling more here. But we do ingest, the vision is, and the product design is, we ingest your existing automations. If they're scripts, tag them with some metadata, enable you then, you don't have to rewrite everything, but now you have some control around those automations. And again, enable you over time to learn. And all automations, everything, our own configurations are all just code in the repository. Again, we have to be DevOps centric if we're gonna do this. That's market texture, but it gives you some idea. Notice that we're not saying, hey, first off, to get this smart, you need to throw out your control infrastructure, chef or puppet, not at all. We would hope that you have those so that we can leverage them. On monitoring, obviously, we need to integrate into your monitoring as well. We have some packages that enable that. And the idea is that over time, folks will open source their processes, right? So in other words, it's not just us saying, here's an automation. It's an extensible toolset. So we're all gonna be able to share some of these higher level automations and scripts. Again, this is just sort of laboring the point. We're not reinventing the wheel. People have been doing automation of operations for years, but there is no solution that really gives you that brain today. And we think working with the underlying configuration management solutions, we can help bring some more sanity as well as some self-learning to this piece. Again, above, between monitoring and the config management, conceptually above them. Any questions? Moon pies. So if I didn't do the trick, I don't know if you've ever had a moon pie, but this is like a Southern delicacy. Stop by in a little bit. During the booth crawl, we do have a bunch of them. Not a huge number, but we do have a bunch of them. And try them out and chat with us. This is the third company like this I've done. And the lesson I've learned over time is I'm not anywhere near as smart as you guys are and as the actual operators. So we really are sponges, and we really hope that we have more good chats with you guys. So that's what I've got, believe in it. If it doesn't have to be us, it could be somebody else. But intelligence is coming to these operations automation and we're happy at Stackstorm to be part of that transition. Thank you.