 Well, welcome everybody. Thank you for joining. My name is Boris Rensky. I'm a co-founder and chief marketing officer at Morantis. And today we're going to talk about OpenStack Co-Opetition, a view of it from within inside. We are kind of an active participant in the OpenStack ecosystem. I am on the OpenStack board. So a lot of you might be reading a lot of different press releases of kind of figuring out how OpenStack world works. And I wanted to give everybody kind of a view from inside. As a chief marketing officer, my job, Morantis, is actually to pretty much do exactly that. I continuously monitor the OpenStack ecosystem, how the different players kind of behave, what new offerings they push to the market. And try to figure out how we should adjust our strategy as a company. So I'd like to start with the definition of co-opetition. And just by kind of a view of hands, I was wondering how many of you actually know what that is. So raise your hand if you know what co-opetition is. Okay, so that's like five people out of what, 30? That's not very surprising, but I myself have learned the fact that such a term exists only after we started participating in the OpenStack ecosystem, which is a co-opetitive ecosystem so to speak. So I pulled up the definition of what it is. I want to read it out loud. So co-opetition takes place when companies that are in the same market work together in exploration of knowledge and research of new products at the same time that they compete for market share of their products and the exploitation of the knowledge created. So that's a very long and complicated mouthful and there's kind of an easier way to define it I think. So if you look at the OpenStack from the outside, if you look at the keynotes and things like that, OpenStack from the outside kind of looks like this, a big happy party of a bunch of people. And this is Jonathan Brice, the head of the OpenStack Foundation. But from the inside the picture is very different and it looks more like this, which is nothing like the picture before. And I wanted to kind of explain specifics of what that looks like during this presentation. So we'll look at three things really. We'll look at the territories that are being conquered in the OpenStack ecosystem. We'll look at the weapons that the different companies choose to use to conquer those territories. And I'll also give kind of a quick highlight of the key battles being currently fought. So territories being conquered, first part. And in talking about it, I specifically decided to choose kind of a metaphor of kind of an island with territories and small islands around it. And this right there, the big chunk is the biggest kind of most valuable treasure island territory that most companies are battling for. And I call it the OpenStack Distro Treasure Island. The guys that are battling for it are Redhead, Susie, Morantis, and Canonical. And the island actually has beach heads. Beach heads are the areas that are the easiest to attack and conquer to begin with. And there's three beach heads that I've identified. The first beach head is what I refer to as the services beach head. There's a training beach head. And then there's upstream influence beach head. And conquering those three beach heads is instrumental to ultimately taking control of the OpenStack Distribution Islands. Now in addition to the OpenStack Distro Island, you have kind of a small islands around it. And this is something that analysts nowadays like to refer to as the OpenStack products and solutions island. So let's try and quantify this. I can tell you right away that there is no accurate numbers with respect to the size of the market for any of those territories. But some of the analysts have started speculating. So the OpenStack Distro market, according to the report from the 451 group, the recent report, is 52 million in 2013, growing to 82 million in 2014. Again, those are ballparks. But as somebody who's participating in that market, they think that through the bottoms-up analysis, that's maybe somewhat accurate at this point. And the OpenStack products and solutions, all of the islands they are combined together, is roughly 31 million in 2013, growing to be 49 million next year. Now in creating this metaphor with the OpenStack Island being the big treasure islands, I think it's kind of a leap of faith when it comes to OpenStack. It's not for sure at this point that Distro is the treasure that you should be going after. And it is quite possible that this island will just end up being a desert and there's going to be absolutely no money to be made. While the small kind of products and solutions islands on the periphery will actually be the oasis, and this is where the guys will build great companies and create a lot of value. So going forward, I'd like to take a look at each of the beach heads in a little bit more detail. The first one is a services beach head. Why is it a beach head and why I think that it's important to conquer it? I think that the history so far has shown that with any early and particularly complex like OpenStack project, services is the first thing that companies start buying. And the reason why it's important to conquer this beach head early on is because in new markets it's impossible to just build a random hypothesis about how you're going to make money or what customers are going to ultimately buy. And by conquering the services beach head, you're actually able to harness the early adopters and get close to the customers and learn how the customers are actually using the software, then ultimately tailoring whatever goes into your offering, into your distro in a way that will be relevant to the customer. Another thing that it allows you to do early on because services again is something that customers pay for in the early days of the market evolution is you can build reputation. You get the opportunity to build reputation and get a lot of customer logos which is important if you're going after the big territory afterwards. I did a talk about a year ago at two summits ago when I talked about how to make money in OpenStack and I talked about how the market is going to be adopting OpenStack software. And I kind of threw out the hypothesis that up until the end of 2013 the primary buyers of OpenStack is going to be technology and infrastructure companies themselves and service providers and web 2.0 companies. And the thing that these companies tend to do is they don't like buying products because oftentimes or more often than not, rather, they have an enormous army of smart engineers already working for them and oftentimes they're able to build software, particularly infrastructure space, better than any outside vendor can. So they would just buy some services to help augment their binge. The 2014, I believe, is going to be the year where enterprise adoption, the traditional enterprise adoption of OpenStack is going to start happening. So let's take a look at who's attacking the services beachhead. So we, Marentis, we were the guys that kind of believed in this beachhead early on. And day one, we positioned ourselves as the services company for OpenStack. And I think that I can say with a certain degree of confidence that we were able to a large extent conquer this beachhead. We've done over 70 OpenStack deployments during the course of the last two and a half years. And we have roughly 370 OpenStack engineers on the bench doing OpenStack services. The guys that are attacking the beachhead that I think that we have conquered, as follows, Rackspace, they have a different business model. Their business model is not distro, their business model is about managed hosting effectively, building a cloud in your data center. But despite this go-to-market model, we do know that they actually do simply services. And in fact, there's press releases out there, and we know firsthand where, for instance, Rackspace has done some services for companies like Sony Entertainment that didn't have to do much with actually providing a managed hosting service. Ubuntu is another guy that, well, canonical rather, that we see in competitive tenders quite often. And they perform services tied to specifically the Ubuntu stack. And finally, now that Red Hat distribution is out and these guys are the credible players pushing forward, we do see them in competitive tenders quite a bit as well. And naturally, they do services for their stack. So let's talk about the training beachhead. This is a beachhead, and why is it important? So a lot of the companies in the OpenStack ecosystem today doing training, they really see training as a really revenue source. There's some companies that don't have any product strategy, and they just do training. They're just training companies. But the reality is that training is not just the revenue source. Training is the opportunity to actually indoctrinate the evolving ecosystem with your opinion. And let me kind of quantify or qualify that rather. The opinion can be a fairly loose term. It doesn't mean that my opinion, and this is what OpenStack configuration looks like. It can be a lot of different things. So our opinion in Rantis, for instance, is that OpenStack was originally envisioned as this fabric that would tie together a very diverse set of infrastructure vendors and overlay kind of a unifying control fabric over this diverse set of infrastructure components. And this is exactly what OpenStack was started for back when, particularly in all the part of it, when it was first created by NASA. Red Hat might, for instance, in doing their training have a different opinion that they'd like to indoctrinate the ecosystem on. And their opinion can be that having an unlimited number of configurations and being able to tie together all the different infrastructure components is impossible. So you have to limit the set of configuration options, so to speak, or set of choices that a customer gets to a more narrowly defined stack, which, of course, should be the Red Hat stack of components, such as it should be a rail. It should ideally be things like a glaster for storage, and it should be KVM for the hypervisor, which I'm not saying it's a bad approach. We'll see which one's better, the time will show. But ultimately, that's their opinion. And in their training, they will be indoctrinating that opinion to the ecosystem. And another proof point, I think, of why I believe training to be Beach Hat is, some of you may not know that, but we know Red Hat pretty intimately. And we know how they've kind of evolved to be the leader in Linux distribution space. And the thing that was absolutely paramount to their success is specifically around their training. They've introduced a very rigorous training program and certification program for Linux. They're actually indoctrinating a bunch of CIS admins about how to properly administer, how to deploy and manage Linux environments. And then the CIS admins got hired all over the place, and they bring this knowledge to the customer, and the customer wanted Linux. They'd say, well, Red Hat are the guys to actually go to a full Linux. So let's look at who's attacking the training Beach Hat. The two guys that kind of started out on this, the first guy was a rack space. We've launched our training offering shortly after, and I would like to believe that between us and the rack space, we're kind of still controlling this Beach Hat for now. But Red Hat absolutely knows the value of winning this Beach Hat. And they're pounding just crazy to do whatever they can to conquer the Beach Hat, just throwing nuclear bombs. And everybody else at this point is also doing OpenStack training. Some of that is really byproduct of the OpenStack Foundation launching the training marketplace recently. But I think that a lot of the players that are kind of on the bottom right quadrant there are just doing training for the sake of training, not for the sake of actually indoctrinating the ecosystem with particular opinion. So third Beach Hat, upstream influence. So this is surprisingly not very well understood Beach Hat by a lot of the guys in the OpenStack ecosystem today. And I think I'd like to explain it by reading out loud a few quotes that I found enlightening about why winning the upstream influence Beach Hat is important. If you were going to buy a service contract for your open source software, would you prefer your service provider actually be the certifiable authority on that very software? This very one good question to think about. Second, in open source being the source of the source code matters most. Since open source developers essentially give away software for free, the key to monetization lies in being known as the source of the code. So let's take a look at some of the important kind of supporting historic facts. So let's see this thing works, wow, okay. So this right here is the list of contributors to the Linux kernel. The interesting thing that we can see right away is that Red Hat right there historically has always been the number one contributor to the Linux kernel because these guys know the importance of the upstream influence Beach Hat. Let's look at some of the more recent examples. This really here is a contributions to Hadoop. The guys that the leaders in Hadoop distributions today is Cloudera and Hortonworks and of course right there Cloudera Yahoo which technically is Hortonworks now and Hortonworks themselves are the key contributors of code to upstream Apache Hadoop. So I think that to just kind of list some concrete points of why it's important rather than use just historic facts and quotes. In participating upstream you're actually able to shape the roadmap of whatever product you're selling to the customer as a distribution. Moreover I think in order to be successful in the distro game you have to really, your whole organization has to really be wrapped around and believe that building software in open source way is the better way to do it, harnessing the knowledge and power of the ecosystem. In very pragmatic terms that means that if you have the upstream influence for the customer you can just land patches upstream faster. And most customers that buy distro rather than the product what they buy they don't just buy a piece of software from you. They see you as a gateway to the community. They expect you to be their advocate in the community and without the upstream influence there's no way that you can do it. So there's two ways to really kind of monetize open source and I'm going to go off on a little bit of a tangent still talking about the upstream influence beach head. But there is a way to do it where you are kind of the source of the code as we talked about in some of the quotes that I've listed. And then there is also kind of an open core model where the open source part is just the open core and then you have a bunch of value add proprietary solutions that you differentiate with. So the source of the source code is the Red Hat and Hortonworks model. The proprietary value either open core model is for instance a Cloudera model. But I think that it's particularly important that whoever wants to succeed in the distro game and open stack understands that there is no core, there is no open core model in open stack. I'm not the reason why because I think that in open stack at least today and from the virtue of what open stack is in general, open stack doesn't really have a core. So let me explain even deeper what I mean by that. So open stack, and I'm just going to talk about the compute part of open stack, kind of the nova stack of open stack, started out about three years ago just a small kind of set of projects. And the first thing that happens immediately when open stack just came out there's a bunch of products slash distro vendors that appeared. And what they said, well, you know, cloud's great, but with cloud you actually need metering and billing. So I'm going to build some proprietary hooks to do billing and metering for open stack and that'll be my value add. So lo and behold, in just a little bit of time, open stack added a cylinder that is now the default metering project for open stack that is also now going into monitoring that has eradicated a lot of the value. So these guys that have built their proprietary solutions and weren't doing it as part of the kind of upstream community, they're pretty much toast. And let's move on. Another kind of set of value add components around open stack historically, around orchestration and configuration management. So some of you might not agree with me, but I believe that these guys are being threatened as well. What's happening right now, open stack is heat. Heat is the, started out as kind of the cloud formations project, but now it's the official orchestration engine for open stack. It doesn't just do provisioning of the infrastructure. It does, you can use it to actually do the open stack deployment. And some of the recent blueprints, such as a heat software blueprint, very much, I think, eat away at the value of things like even puppet and chef, a basic configuration management. So now we're going to get them to a better part. Every product or every vendor that's been trying to kind of monetize open stack, the one thing that they did is they said, okay, well, open stack is a cool product, but you need to be able to deploy it, and you need to be able to manage it. So what we're going to do is we're going to build our suite for deployment and management of open stack. So with that in mind, kind of a non-upstream initiatives have emerged. Some of them are proprietary deployment management engines. Some of them are open source, but none of them are really kind of a deep upstream. So what happens next? PEM, HP and RedHead, they being the smart upstream guys. They start project 3.0 in Tuscar. All these other deployment tools, long term, potentially toast. And this actually keeps going. So the recent big hype that has happened now is there's a lot of platform as a service vendors are saying we build out platform as a service. And what we're going to do is we're going to use open stack as one of the infrastructure as a service engines underneath. We actually wrote a blog about it. Hey, guys, that's maybe not the right way to, you might be threatened by upstream open stack. And we didn't know anything about this. But literally after we wrote the blog, two days later, BAM Project Solom, which is a native platform as a service for open stack. So there is no core in open stack, is my point. And by trying to build value at around rather than working upstream, you'll just waste a bunch of time and money and build kind of a proprietary island. So my kind of encouragement to everybody is instead of trying to go with proprietary routes, go ahead and start working upstream. If you see a gap, if you see something value add, be the evangelist of it upstream and harness the points for actually evangelize it upstream and having been the first one. So let's take a quick look at the upstream kind of an influence beach head state of play. Red Hat, smart guys know how to do open source. So they are the first ones to kind of pound on the beach head. And arguably they've reached a fair amount of success. So if you measure by commits across all projects, Red Hat has been steady kind of a number one contributor to our open stacks since Folsom. But there's a bunch of guys that kind of continue pounding at the upstream influence beach head. Rackspace historically been number one. They've actually been displaced to now number three. They're slowly losing control of that beach head. Us, we were kind of challenged with the problem of having to educate an army of Russians of how to work upstream, which is a very alien thing for the Russian engineer to do. They tend to just kind of have their opinion about how things should be implemented and write code. And that's not how you develop it upstream. But we've been making steady progress. And actually we've moved since just the last release, we were number 16 in Grizzly. We came out number five across all commits, across all core open stack projects. HP, also fairly smart guys know how to do open source. We've been holding steady ground at number four. IBM actually been increasing their pace slowly. So they're moved from number six in Folsom to now number two in Havana. And finally, another company that actually seems to actually know the value of upstream influences in the ones, and they're steadily gaining Folsom, number 11, Grizzly, number seven, Havana, number six. There is ways, though, to measure upstream influence. It's not just about commits to core projects. There's a lot of initiatives happening. So if you look at, for example, who commits most documentation, the picture looks different than if you just measure across the projects. If you look at, for example, Stackforge, which is a sandbox for kind of new projects on open stack, or related projects, they're not guaranteed that they'll ever be adopted by the broader community, or be made into the integrated release, but still it's kind of like the innovation sandbox. So the picture is also very different. Redhead is number six. And we've been doing crap load on Stackforge. And you can keep slicing and dicing it. So, for example, if you look by project, then in Nova, IBM is number one committer. If you look at Cinder, which is very core, HP is number one committer. If you look at Neutron, VMware is number one committer. So let's take a look at some of the islands as I'm about to close on the territory stock. Let's take a look at some of the islands that surround the Distra Treasure Island. There's an AWS Fidelity Island, Enterprise OpenStack Island, Managed Services Island, and then what I refer to as the OpenStack Appliance Island, and then there's a Complementary Product Island. And in each island, there is currently kind of a respective occupant that is sitting there and protecting their territory. Cloud scaling is the AWS Fidelity guys. Piston is the enterprise substitute to VMware and the enterprise type guys. Managed Services, this island is going to get crowded. So right now you have Rackspace and MetaCloud. But HP and IBM are starting to kind of get their game together. And I think that once that happens, they're just going to drop a nuclear bomb on this island. OpenStack Appliance Island versus Nebula and Morph Labs. And Complementary Product Island is just random value-ed technologies that try to piggyback or hold on to the momentum of OpenStack. And there's many companies there, but I think my subjective opinion that Ink Tank, who they're self storage, are the guys that actually probably benefited most and played it the wisest. And if you just look at the territory, I think that we are still kind of controlling the services beachhead. We're sharing the beachhead of training with Rackspace. And Red Hat's pounding hard, as I've said. And Red Hat's sitting kind of holding on very hard on the upstream influence beachhead. So look now at some of the weapons that companies use. Marketing NPR is the number one weapon. And marketing NPR is just kind of almost like a doping peel. So you have certain capabilities or certain strengths, and then you can swallow this pill. And you'll be stronger for a little while. So Red Hat, their positioning is that we own the upstream influence beachhead, and we'll do for OpenStack what we did for Linux. So hey, we're cool upstream, and we know how to do it. We've done it before. So we'll be the winners. Stick with us. Canonical, they are pimping the number one host OS for OpenStack. They are the most popular host OS, and they're pushing hard on that. Rackspace, their messages, we started OpenStack. Our messages, we are pure play OpenStack, and we don't have any kind of a portfolio product baggage around us. We just focus on OpenStack, so we're not going to push you to use KVM as a hypervisor or REL as a host OS necessarily. Cloud scaling, they're like, we have the opinion, and our opinion is that OpenStack should look like AWS. Piston, again, we started OpenStack, but we're fun. And then the two guys, IBM and HP, for understandable reason, we are IBM bitch, but the main thing is we are committed. And there's a lot of value in it, because for IBM, they don't need to prove to the customer that they are cool or they're a good partner. They already have all the customers, so they just need to prove to the customer that they are committed to this new technology. And the guys that have been buying IBM for the last 50 years, now that IBM brings this technology to them, they'll buy it from IBM. The same goes from HP. And I think that this is the excerpts from the opening statements, the opening descriptions of how companies position themselves coming into the summit. So you can look, this is the redhead description. So they're pimping the upstream influence beach head as far as we can. We are the top code committer opening line. And of course canonical, we are the most popular host operating system for OpenStack. Again, some of the headlines, IBM and HP, they're all focused about it. We are committed. We are committed. This is their message. Account control. So this is a weapon that few are privy to. Morent's cloud-stailing piston, we don't have account control. Guys like HP, IBM, redhead have account control. What does it mean? It means that Mr. Customer, I've been selling you shit for a long time. I've never let you down, buy from me. The problem with account control is that it can sometimes be a double-edged sword. Because the customer ultimately knows you as somebody who's been selling him shit x. So that means that potentially by introducing something like OpenStack into the mix, the reason why you're doing it is because you want to sell more of that shit x. And there's actually history that shows how this can be double-edged sword. And I think that the very good example of how that history plays out is redhead themselves. Because if you remember back to Unix Wars, the guys, the powerful giants, were really selling HP and IBM, which had their proprietary versions of Unix that were just tied to their expensive mainframes. That was this main shit that they were selling to the customers for a long time. And then came redhead and said, well, we'll liberate Linux. You can have any kind of vendor. Now, you don't need the expensive mainframe. You're going to cut down the cost of computing by an order of magnitude. And ultimately, that worked for them. So another interesting weapon is partnerships. Partnerships can be viewed as a shield from account control to some extent. Because the guys that have account control, like I said, their account control is tied to certain baggage always. And you can mitigate that with partnerships. So some examples. Mark Shuttleworth invested $1 million into Seth Storage. So one way to look at it is Mark Shuttleworth is a brilliant entrepreneur. And he believes that Seth Storage is a great, great product that's going to make a lot of money on the exit. The other way to look at it is he's basically saying, up yours to redhead, by saying that Canonical is best friends now with Seth. And Seth is better than Gluster. Another is Suzy Cloud 2.0, recent press release, specifically focusing on compatibility around Hyper-V. Again, very similar message. It can be interpreted as basically Suzy saying, well, redhead, they'll make you work with KVM. But we are all open. You can do Hyper-V and you can do VMware. Another one is a plum grid and redhead shake hands. So one way to look at it is, you know, plum grid has bought into the brilliance of the redhead open stack distribution. Another way to look at it, my pragmatic Russian way to look at it is maybe redhead is just kind of saying, up yours to VMware that is competing with them around virtualization technology. So all this fun and games aside, I think that the most important weapon that you can use is really kind of a focus on technology and focus on customer. You need to make stuff that is relevant to the customer and that stuff needs to work. And that's the bottom line. And the reason why I bring it up is because there's a lot of speculation where the best technology doesn't always win. That's kind of a common theme. Yeah, so we have a great technology, but these guys are really powerful. And they were able to outcompete us with partnerships and marketing and things like that. I think it's to some extent true, but I personally believe that good technology almost always wins. So in trying to use different weapons, it's important not to get distracted away and produce a lot of great partnerships and marketing, but build crap technology. So to close, I wanted to kind of highlight some of the interesting battles that are happening in the ecosystem. And so this is one battle that maybe some of you saw. And the point of the battle is as follows. Certain companies with cloud scaling kind of at the lead being the cheerleader believe that effectively Amazon has won the cloud wars. Most of the guys that have been indoctrinated into cloud were indoctrinated by Amazon. So instead of being antagonistic to Amazon, what OpenStack should do is really embrace everything Amazon. Embrace Amazon APIs, embrace Amazon implementation, become effectively an Amazon software that customers can use. The alternative kind of viewpoint is that API really doesn't matter. And that obsessing with somebody like Amazon could potentially drive the OpenStack community to miss some of the important things that are actually relevant to the customers. And for every battle, I kind of put this bullshit meter on the bottom, measuring how much of this battle is really about technology and substance, and how much of it is just kind of a PR bullshit. So I think that this one is probably mostly PR bullshit, but I don't know. Maybe I'm wrong. The battle of host OS. So this one's kind of interesting. Naturally, Red Hat canonical Susie, they control Linux distribution. So what they say is that, well, you cannot have an OpenStack distribution if you don't have an underlying host OS distribution. And there's a whole bunch of reasons given to that effect. You need to be able to actually fix bugs in the host OS because host OS is what the OpenStack distribution runs on. And ideally, you shouldn't optimize the host OS to make OpenStack run better. And you should have the ability to support the entire stack. Now, there's a whole different camp of guys, and I think that kind of rackspaces the main cheerleader there. It says that, OK, well, host OS is just one component, but there's a lot of components on OpenStack. Host OS is not the only one. There's, for example, MySQL that Red Hat does not control. There's RabbitMQ, which Red Hat chose to substitute for something else for Cupid. And there's many deployments of OpenStack where people don't want, for example, your host OS. And the interesting thing that has happened is actually this kind of new whole theme is that no host OS is optimal for OpenStack. There should be a native cloud OS. So there's a peculiar project that has been invested in by Lou Murman, who is the president of Rackspace, called Core OS, that they're building just the new Linux distribution optimized just for cloud. And the idea is that I'm hoping that they're going to become the native OS for OpenStack. So again, the bullshit meter, mostly tech stuff. The looming battle of Swift. So let me give you a little bit of context here. We'll see how this one plays out. But the context is as follows. So foundation right now is working really hard to define what is OpenStack Core. Nobody agrees on anything, pretty much. So the process is going very slowly. But the one thing that everybody agreed on at this point is that whatever is Core should have pluggable architecture. It should allow for different implementations to be substituted in. So for example, if you want storage and you want to have object storage, if you have SIF with S3 APIs, that should also have the right to be called OpenStack. Swift is Core, is mother of Core. There's a second project in OpenStack contributed by Rackspace. But the problem with Swift is not very pluggable. It's the entire implementation. So I think that there's going to be kind of a looming battle about Swift. And the idea is that there's valid arguments that guys like Rackspace and probably guys that are monetizing specifically Swift like SwiftStack will make that OpenStack is not just kind of an API layer, which I personally agree with. It should not just be an API layer. Swift is probably arguably the most solid production ready project on all of OpenStack. And it was there day one. And there's certain counterarguments that the opponents like, for instance, Ink Tank could likely make. And again, on the PR meter, I think that this is mostly kind of technology stuff. So this one, we highlighted a little bit. But I think that probably this very vivid battle right now, there's a whole bunch of guys that there's a whole bunch of deployment tools that have been built. And there are cool tools that do a lot of stuff. And then there is the blessed official OpenStack deployment program called TripleO Intascar. And this kind of looks like this, despite a lot of deployment tools that are out there in the market today, arguably, work better and have been deployed in production than TripleO Intascar is just a framework, but they are blessed. So the customers ultimately don't care so much if it's a blessed framework or it's that project or it's this project, they care about stuff working. But I agree that actually developing stuff under the auspices of a community rather than doing it in a silo is a better approach to ultimately getting a better product. So we'll see how this battle plays out. So final one. This is kind of a battle that not many of you are aware of, but I think that it's happening. And that's a foundation's battle for quality of all. And the general idea here is that the last thing that the OpenStack foundation wants is for there to be kind of one guy that is the default go-to guy for everything OpenStack. Because in their mind, it's going to look like this. And there's probably a personal, somewhat selfish aspect to that. Because if this was to happen, then this will be the foundation, and this will be this one guy. So they're doing a lot of interesting things to even the plane. I think the one thing that they did recently is the launch of the OpenStack marketplace. Effectively saying, here, come to the OpenStack foundation website and we'll list the Red Hat training. But we'll also have up-tier training and cloud-scaling training. And we are the guys to actually come and look at work with the best training provider is. So they're kind of taking away a little bit from the marketing momentum of some of the big guys, and evening the plane for the smaller guys. And I personally know that this trend will continue, and they'll continue pushing on it. And this is about it. So any questions? All right then. Question right there. Explain. Yeah, I can talk about it a little bit more. So foundation is right now trying to figure out the definition of core. So right now, there is kind of effectively three categories of projects in OpenStack. One is core projects. Two is integrated projects. And three is just related value ed projects, which is a bunch of guys writing code on StackForge. And there is no very concrete definition around each one of those levels. So it's very easy for somebody who just has a project on StackForge to say, well, we are an OpenStack related project. So you're integrated and we're related. What's the difference? And core integrated, again, the difference is vague. So foundation is trying to come up with a very definitive set of guidelines for which project can legally actually leverage the OpenStack trademark in a particular way. And they're working on these guidelines right now. And one of the things that everybody has agreed on is that whatever is core has to have pluggable architecture. You should be able to plug in various implementations. For example, Nova, you can use multiple hypervisors. Cinder, you can use multiple storage back ends. Quantum, you can use different networking solutions. But Swift is the entire thing. It's the API with implementations, the whole thing. So what should happen to Swift? Should Swift be dumped out of core? Should Swift be just reduced to just the API layer? That's kind of the battle. So any more questions? OK, then we're done. Thank you.