 and hopefully everyone can see my slides now. So the plan for today is really to focus on, like I said, this new OpenStack Power program and some of the new technical requirements around that, which should be especially relevant to those of you who might be launching some new products around the Vancouver Summit. We usually start getting a lot of requests about right now, so we want to make sure that everyone is informed about the new program and processes and then talk a little bit about how we're planning to roll it out to the broader market as well. And then finally, if there are any other topics or questions you guys have, we can use the rest of the hour to go through that. So with that, and if you have any questions, feel free to throw them into the chat or jump on the line either way. So just to give a quick set the context, hopefully most of you are familiar with our commercial product marketing programs right now. We have three logos that we license to companies who offer OpenStack products. And those logos are powered, compatible, and training. And each of them are for different types of products and services. They have different technical requirements and they allow different usage of the trademark, the OpenStack trademark, whether that's the word OpenStack in the product name or the use of these different logos. So just kind of a quick refresher on the overall program that's been in place for some time. Today we're going to focus on the OpenStack powered products. So this is a screenshot from the OpenStack marketplace. Those OpenStack powered products would fall under the distributions and appliances, public clouds, or hosted private clouds right now. So these are primarily the products that we were talking about today. So what we'd like to do is talk a little bit about the evolution of the OpenStack powered program in particular. And some of this has been through policies set by the board from the Deaf Corps Committee. I'm really excited about this because we've been talking for a while about how important interoperability is and trying to make sure there's consistency out in the marketplace in response to user expectations and setting those expectations. And so we'd love to thank everybody who's worked on this committee as part of the word for past several months. It's been a lot of work put in and gathering feedback and constantly getting different perspectives and also iterating as we go. And so we're excited because this is the first time now as of today that we're going to start doing new license agreements under the OpenStack powered program and logo that include these testing requirements. And so having a clear set of what's expected and these types of products that are branded this way can be great for people out in the marketplace looking for products to know what to expect and then actually having real world tests that we can run against those to validate that it works the way it's expected has a lot of benefits for driving the market forward. So thanks to everybody on the Deaf Corps group and the people have been putting input into that. Now we're able to kind of operationalize this from the standpoint of the foundation licensing and so forth and I think it's a big milestone. Yeah, so if you are familiar with the older technical requirements for OpenStack powered they're basically what we had in place for quite a few years now since the early days of OpenStack and in order to qualify for OpenStack powered you had to include all of the OpenStack NOVA compute code all of the OpenStack Swift object storage code and then expose the APIs. So the major changes to this going forward are one, we now have three different programs under this powered license. So if it's a compute only cloud with a storage only cloud or if it's a platform which is essentially a combination of the two they all fall underneath this powered logo. And two, the biggest change are these new API tests which match up to those sections of code. So we're really excited about this new testing. So any questions about that so far? We're going to go through a little bit more detail about the different programs that we just mentioned. The powered platform, compute, and object storage. The main differences between them obviously is that compute has to include all of the compute specific designated codes and expose those capabilities while object storage needs to include the object storage designated code and expose those capabilities and there's differences primarily in the way that you can use OpenStack in the name of your product. So for example with OpenStack platform which includes all of the compute and object storage you can use OpenStack in your product name like distributions do now so you'll ask me OpenStack or whatever else but under the compute or object storage you need to use the qualifier with computer object storage to be more specific. One thing to emphasize here is the program names these are just literally the names of the licensing programs. These are not brands themselves so you're not going to go out and use the words and this less column under program names. It's literally just something we call each licensing program to be clear about what the requirements and the different rights are associated with them but those are not brands per se. OpenStack powered is the brand overall that kind of indicates to the market okay these things are actually powered by OpenStack software so don't get too hung up on those names those are just kind of there to help us spell out with each licensing program what the different requirements are and some examples of what types of rights you can pay once you meet those requirements. Yeah that's a good point those are not public brands. So now we want to talk a little bit about how you participate in these programs. So there's a couple of new steps that are really specific to this the new testing requirements. If you go to OpenStack.org. You'll find all these details including the designated sections of code that must be included and the different API level tests that your product needs to pass in order to qualify. And then there are also instructions on those pages of how to run those specific tests. And I think actually Chris Hodge is on the line too on this call he is the interop engineer that works with the OpenStack foundation and has been helping with this process with the deaf core committee in the test setup and he's a good resource for you as you're going through this process if you have any questions or need help getting started his contact information, well he responds to the interop at OpenStack.org alias and his contact information is on that page for future reference. But basically the primary steps are going to this interop page you know checking out the requirements, checking with your product teams to make sure that you meet all these requirements and then going back through the same process that we've had in place for some time where you go to the OpenStack brand page, there's an online form to submit where we just ask for a few more details about your product where you'll indicate that you're interested in the powered license of that step and then once we have your test results submitted to the interop at OpenStack.org email address we will go ahead and execute the license agreement. So it's basically just adding in that additional testing step before we will execute the license agreement there. And then as always we are definitely happy and would like to work with you if you're doing a product launch or need help understanding how to incorporate the logo and the wordmark into your product collateral and branding we're there to help and we definitely want to help spread the news of products and services in the OpenStack. I was going to actually just pull up these pages on the website to show everyone and make sure everyone's familiar. So I'm going to back out the presentation for a second and go through these pages. So the first one I mentioned was this just the general OpenStack brand page. So hopefully most of you are familiar with this. It goes through just helpful information and requirements both for just community use, non-commercial use of the logos as well as details around commercial use and the different programs that we discussed a little bit on this call. So you'll notice the changes that we made with this new launch are that we added in the requirement to pass interoperability tests and where to get that information and just made a few updates to this page as we roll out this program. So from here you would click through to OpenStack Powers and you can see the updated technical requirements on this page and links to reference those on the Interop page. And from here is where you would go through and fill out the form to request a trademark license. And you would indicate here that you're looking for a powered logo and fill out your company name and the name of your product which is very important because that's one thing that we do check and provide permission for if you're using OpenStack in the name of your product we need to make sure it's done properly. And then a little description about your product and the type of product it is. So that's the steps that you would take on the branding page. And then if you were to click over to the interoperability page you can see in more detail again it's the same chart that we showed about the different programs and kind of high level requirements for that. And then goes down into the very specific required capabilities and tests that you'd be running in order to qualify as well as instructions on how to run the actual test and as I mentioned information to get in touch with the foundation should you need some help with that. So are there any questions at this point or want to take a minute? I have a question. So if you were already issued an OpenStack powered logo like last year or the year before because you launched a public cloud I guess anyone who already has an OpenStack powered logo and you've been using it we also have to go through this new requirement and run through the testing requirements to obtain the new licensing agreement. It's such a good question that it's literally the next slide. So perfect time. We thought there might be some questions on this. But right now this is effective immediately for all new products that are going to be licensed. For existing products what we encourage you to do is to actually look at the technical requirements, make sure that you meet those and actually start working with us on testing those and signing updates agreements. And it's not something you have to do immediately actually and so forth but there's a lot of reason that benefit really to getting on top of that. One is we want to actually start to call out in the marketplace starting around the Vancouver Summit which products have been tested and sort of show the check marks next to all the capabilities showing hey you've got these capabilities. So that will help put those in a more positive light. And then our goal, so of course we'd love to have everybody in the marketplace there for Vancouver. It may not be realistic but our goal is definitely by the end of this year to really understand the situation with every product in the marketplace. We hope that they would all be tested and have the licenses updated by the end of the year. So there's kind of two answers to it. One is our recommendation slash kind of ideal outcome which is everybody takes advantage of this opportunity to be part of something we're going to message heavily at the Summit which is look at all these products that are, we have testing now look at which ones are tested but it's not something that you absolutely have to do for your older previously launched products right away. So I hope that answers your question. Yeah, thanks. So what all of this means from a messaging perspective and kind of the impact we're trying to make. I mentioned that this is something we want to talk about quite a bit at the Vancouver Summit because I think people, users in the market and people looking at OpenStack have been asking about interoperability and wanting to know more about what's not and wanting to make sure we're doing testing. So it's really about all about interoperability and so we will be talking quite a bit about that. We want I think it's important when we think about the ecosystem above OpenStack. So people that are building apps for OpenStack APIs, for OpenStack clouds whether they're consuming public or private clouds or hybrid clouds or if they're, if you think about platforms like pass and things like that we want to get this very solid foundation that all this ecosystem above OpenStack can rely on and so that's why we're doing this and we want to also be educating people when they see that OpenStack powered logo on your website or if they see your product in our marketplace they understand what it means and their expectations are met and there's a definitive list of what qualifies and what to expect. Yeah, so in terms of educating the broader market about that, so right now we're really trying to communicate these new programs and requirements to the community itself to get folks on board especially ahead of like I mentioned earlier the kind of new product launches that often happen around the summit. So right now it's kind of the internal community focused education trying to get people on boarded and like Marc said the incentive to that is that we are planning to really message this strongly around the Vancouver Summit so we know the presentation will really be focusing on these new OpenStack powered programs and the reason why consumers should really seek this out in the market we're actually going to be issuing a press release around the summit to hopefully showcasing all the OpenStack powered products that have taken these new API tests so that's again another incentive to go ahead and get tested and have that showcase in the marketplace as well as this press release we're going to be briefing, press and analysts about the new program and the meaning of that and how we're really focused on interoperability and the meaning for the community and the market overall and finally in the actual Exo Hall which we call the physical marketplace we'll have different signage focused on OpenStack powered products. If you offer an OpenStack powered product there might be a sticker or signage in your booth as well as I guess educational signage overall so we're planning to really go big on this at the summit so it's something that we definitely want to roll out and get everyone onboarded in the community so we can make as big and unified as possible. Yeah and I would just add that because we are for the first time introducing this set of tests they're most likely are going to be bugs or challenges you run into running the tests and that's why we've got Chris Hodge there to help and we want to be iterating on those tests as well as the documentation around it so that hopefully in the not too distant future you'll be able to very quickly and easily just download the test running against your product, you're running cloud and get results back. We're getting there but we're not quite to the state yet so bear with us, we certainly want to work with companies as you're running the tests and help you understand kind of how to set it up and what the results mean and if you get a negative result it could be a false negative there could be a bug so don't panic if you see any errors just help us kind of work the kinks out of it here in the early days and then in the long run I think it'll be quite automated and we are leveraging a lot of the great work from the OpenStack QA team upstream so I want to thank those folks as well they operate a test framework called Tempest as part of the development cycle day in and day out I'm sure the developers for you guys companies are all familiar with this but it's a really great way in which we ensure quality upstream as the code is developed day in and day out and new patches come in so what we're really trying to do is in the downstream products that are productizing that code be sure that it still meets those same types of quality standards and so leveraging those same tests is the approach we're taking which is the way to go and like Mark said we at the foundation staff level are really focused on the execution of this in terms of getting the tests ready and helping companies through this testing process as well as executing these new license agreements and the logo programs but the actual policy is set by that board committee called DEFCOR that we mentioned earlier and if you're interested in getting involved in the evolution of that it is a very open process there's a mailing list, it's the board committee but anyone can participate and join and share their opinions so this is important to you which I'm assuming that it is, it's a good place to get involved and help set that direction as well. Yeah I don't know if you were going to show them the page but I was going to talk a little bit about the fact that there will be multiple versions, I guess multiple specifications over time of what's required. Right now there's just one because we're beginning but the way that the specifications are numbered or labeled is based on a year a month when they were approved by the board just to kind of make it easy for us to have a naming scheme so the first iteration which is what's detailed out on the InterRoc page, OpenStack.org slash InterRoc is 2015.03 so for extra credit you can figure out when that was approved but it is the only version right now but we expect because we're kind of playing catch up as this is rolled out there will be additional versions approved this year with the date stamps on them but generally the idea here is that you need to be compliant with one of the two most recent versions so right now there's only one so once there's multiple over time we've kind of set this up so that it kind of rolls along as a requirement and the day a new version is approved by the board you don't have to immediately go change your products so there's some lag there but that just kind of explains a little bit about the different version so if you look at this InterRoc page this is OpenStack.org slash InterRoc is kind of the shorthand that there's a little bit longer and it takes you to this page and so it explains a lot of the stuff that we talked about in the slides but it really gets into a little bit more of the nitty gritty on the requirements here like what are the capabilities how it maps to the Compute Licensing Program, the Object Storage Licensing Program or the platform which you'll note is really just the addition of these two so those are the different programs and the capabilities and the designated sections are spelled out here as well and then there's detail here about getting started with the testing when in doubt and an email interop at OpenStack.org which we'll get you in touch with Chris and then there is actually a link here to something that probably your development teams will want to look at it's a little less human readable it's a JSON file that's sort of the source of truth for the requirements but this is sort of summarizing it in a hopefully more human readable format and that's kind of the, I mean this page is going to be actually referenced in the new licensing agreement so respectively it's going to look a lot like the OpenStack Powered license agreement but instead of saying trying to spell out in those agreements what the requirements are it's going to point you to this page so this is a very important page to bookmark if you're doing your product planning and wanting to make sure you understand what we're requiring. Well that's really all that we had to walk through today so I'd love to take any more questions or thoughts on this as we roll it out and if there's any other just general marketing OpenStack questions happy to run through that too. Hi I have a question to Sean Jakes from IBM is this going to affect whether products are included in the OpenStack marketplace or not? Yeah so what we're planning to do is for new products that are launching in order to be in the marketplace they need to be specifically the categories of products that fall under OpenStack Powered so the products that include OpenStack we are going to be requiring them to sign these license agreements that have these technical requirements which include passing the test so it's kind of a long ended version of saying yes a lot of going forward basis for the existing products we're going to take some time to kind of go back and work with those companies and not sort of pull them out quickly. Well we're very excited about this. It's been a long time coming and I think there will be more opportunities to kind of expand the list of capabilities over time and to beef up the testing that really it all starts with that first set of tests and that first set of requirements and getting feedback from the market and feedback from the ecosystem so I think this is a really good thing for the health of OpenStack overall and that's why you'll be seeing us kind of talking a lot about it at the Vancouver Summit which of course I hope you're all going to be attending. I've got one question on a different topic if that's okay. Sure. So with the Keelow release coming up on April 30th are there marketing events online or other that the Foundation is planning so we can sort of schedule some things around that? Yeah that's a good question so what are the things that we are planning around the Keelow release is I'm sure that you're familiar there are a lot of changes happening in the upstream community right now just in terms of how we're managing and looking at these releases going forward so one of our main goals from the marketing and messaging perspective around Keelow is to help communicate those different changes. I think that we've gotten feedback and have kind of been gradually doing this in terms of taking the foot off the pedal a little bit in terms of how we promote the individual releases from a feature perspective or from going out and shouting from the rooftops when a new release comes out. We've kind of pulled back from that a little bit and especially now we're going to be focusing on kind of the evolution of the project structure and how that will be happening in the future. As far as the specific states we typically do a webinar on or around release day I don't think that we've scheduled that exactly yet but as soon as we do I will let you know and we will do a press release on April 30th as well. We probably will schedule another marketing meeting in the next week or two or something else to list with some of those plans but we're not quite there yet. Well thanks everybody. If you have any questions send us an email or emailing list but I think we'll be putting this recording up as well so you can share with your colleagues and for people that weren't able to attend today we'll have access to the information and I guess with the slides we'll be on the marketing. Thanks. Bye everyone. Thanks everybody. Cheers. Thank you.