 So, this morning, during the keynotes, we heard from just about every single keynote speaker this morning talking about users, users, users, users. It was a little bit nebulous who they were talking about, though. There were operators and developers and a lot of terms thrown out. Who were we actually talking about when we talk about users? Hi, there. My name is Evertaves. I'm a developer advocate with Rackspace in the developer relations group. And I still get the question quite often, you know, just what the hell does a developer advocate do? Like, come on, really? So first and foremost, I am an engineer. I write code for the majority of time. Sometimes that means 50%. Sometimes that means 80%. It varies from day to day, week to week, month to month. I'm a project management committee member and committer on a project known as Apache J Clouds. This is a Java SDK that we use to talk to OpenStack and the Rackspace Cloud and HP Cloud and whatever OpenStack you got, we'll talk to it. It also talks to a lot of other clouds as well. The advocate is the guy standing before you today doing the song and dance that I hope you enjoy. But it's not just this one-way communication. I'm advocating for Rackspace and OpenStack, yes. But I'm also advocating for the users, which I'm going to define a little bit better in just a moment. I like to take in the feedback from the users and try to understand what it is we can do to make OpenStack better. And this is me on the Twitters and GitHub's and wherever else, my little avatar as it were. And I've done a little bit of operations in my time at my previous job up in a little company called Cibera up in Edmonton, Alberta, Canada. We built the first ever Canadian OpenStack Cloud. We had a region in Alberta and we had a region in Quebec. And they were linked via a high-speed research network. Really cool project. And to that end, I wound up co-authoring a book known as the OpenStack Operations Guide. Hopefully you saw the same screenshot this morning. I feel privileged to have some of those co-authors with me here today. In the back, Fist Pump from Tom, Tom Fifefield. And Gentle here, OpenStack.ptl and Jonathan Pru. So this is a book that we wrote in about five days. It was something called a book sprint. And the reality is that we really wrote it in three and a half, four days. We actually spent that other day, day and a half editing it down and trying to get something coherent out of it. And we kind of succeeded. We more or less self-published this book and eventually O'Reilly picked it up and they created this much more professionally edited version. And it is now, you can buy it, the Dead Tree version, or you can go download it for free. But really do buy a copy for yourself and your friends. OK. So before I get into the meat of it, let's lay some groundwork with some terminology. Because there's a lot of overlapping terms in the ecosystem that we've been using. And this is what I'd like to clear up when we talk about users in OpenStack. So there's OpenStack itself, right? OpenStack itself. It's the other direction that went. OK. So there's OpenStack itself with your developers and operators. And then you have people writing applications on OpenStack, also known as developers and operators. So looking out into it from the OpenStack community perspective and the OpenStack mailing lists, when they talk about developers and operators, they mean themselves. The people are actually building OpenStack itself and deploying OpenStack itself. And it's just commonly known that, oh, when I say developers, I mean someone writing code for Nova or Swift or what have you. What does the rest of the world see when they look at OpenStack? Well, to be honest, when people in mainstream software development industry think about developers and operators, they think about the applications. They're thinking about the people who build that software as a service, those mobile applications, those are the developers. The people who deploy those things, those are the operators. They don't even necessarily see OpenStack. It's infrastructure as a service. It's our platform. This is what we build on. And it's sort of a transparent, it's a black box, really, that you use via an API. So for the purposes of this presentation and kind of going forward, we need to delineate these two terms, these two sides of the same coin. We have our OpenStack developers and operators and our application developers and operators. Overlapping terms in the developers and operators bit, but we need to make this distinction. So I'm going to wax nostalgic just a little bit and tell a little story once upon an OpenStack. So this is actually the story of my introduction to the OpenStack community way back when. And as I've progressed through the community, through the years, I've watched this evolution from where the focus is on developers or operators, depending on what side of the coin you're on. So of course, we'll start with a historical perspective. The OpenStack developers themselves. When OpenStack started and the Anso Labs group at NASA came together with the Rackspace Swift people, the object storage portion, the Anso Labs people were doing, Nova, the compute portion. They brought these two things together and created this open source project known as OpenStack. And you had this core of developers who were working on it. Now, naturally, they were calling themselves developers because they were developers. It just makes sense. And you needed to focus on this group for that period of time, because without those developers working on OpenStack, we wouldn't even have anything to talk about today. So there was a lot of focus on this group. And I distinctly remember being at the Bear conference, where I actually got this t-shirt. In San Antonio, sitting across the table from some of the OpenStack Nova developers, a colleague of mine and I had gone to San Antonio for the express purpose to come away with a working installation of OpenStack that we needed to use for a project. And at the time, one of the developers we were working together and he picked up his phone and read a tweet. He's like, oh, they're calling us the Apache of open source cloud systems. This is referring to the Apache web server and how it's the ubiquitous web server of open source. Everybody was really excited and just tickled pink about this. We're really onto something here. We've got some momentum here. This is the Bear Summit, so it was only the second release that they were discussing. But we're on the right track. This is great. So sitting there across from Vish, we're fixing bugs while we're actually deploying the software, while we're actually deploying OpenStack. So we're trying to get it onto one of our machines and going through the steps that were listed in what documentation was available at the time, which was scant. Yeah, none. Thank you. I remember. Yep. So we're there. And as we're going through the steps, we get a crash. And quickly goes into the code and fixes it up and patches it and it goes in and then they keep going. We just kept going and kept doing that until we actually got something that kind of sort of worked. And so that was pretty good. It was a mighty short cycle between finding that bug and fixing it and deploying it. It was like literally minutes. It was pretty cool. And there were tens of OpenStack developers at that point in time. So coming up a little closer to the present, say six months, two a year to present day, the focus has been very much on the OpenStack operators and deservedly so. These are the operators who are blood, sweat, and tears into their OpenStack deployments. They're the ones who are getting those late night calls when things break. They're the ones who are basically at the bleeding edge. And nowadays, OpenStack is being called the Linux of open source cloud systems. So it's being very much more compared to the broader and more ubiquitous Linux itself, especially in the when they start talking about governance and BDFLs, but other dictators for life, it's being compared to Linux. So it's become even more broad and more ubiquitous. And now we're finding bugs while deploying. And that cycle between actually fixing those bugs and getting them out back into OpenStack and deployed again, I believe that's become considerably longer than the few minutes that it took during the bear cycle of OpenStack. And as we heard this morning, there were 600 operators here alone. So we have hundreds of operators deploying OpenStack for their users, for their application developers, for their application operators. I imagine that once in a while, there is some overlap between the OpenStack operators and the application operators and the smaller private clouds. And that's just fine. OK, so let's take a peek into the future and see where we're going with all of this. Where is the whole ecosystem of OpenStack going? Well, now we're headed off to the application developers, this group of developers who are creating solutions on top of OpenStack. They're the ones spinning up VMs in OpenStack, creating applications in PHP or Java or Ruby or Python or whatever you got, whatever you can run in any guest operating system that you can run on an OpenStack cloud. We're running OpenStack happily, runs Windows Server these days, or any flavor of Windows really, developing .NET applications. So these are the developers who are creating value for their users. Think of what the next Instagram could be developed on top of an OpenStack cloud. And there's this mode of thought that's been circulating around for about the past year or so where OpenStack, well, application developers are the new king makers. These are the guys who rule the roost, really, because they're the ones who are making the decisions about what it is to use, what it is to create. And their productivity has been unleashed for a number of reasons. And they also have a number of monikers, this utterly ridiculous euphemisms for application developers that have been circulating. And frankly, I can't wait to list stuff, dies off. And I think it is. It's on the down slope. I don't see it as much anymore. But certainly, we are all special snowflakes doing magic on a daily basis. But there is a real kernel of truth behind all of this because of the cloud. Because of the cloud has unleashed their productivity and their creativity. We keep hearing again and again how you no longer have to get a server in months or weeks or days. Now you're getting servers in minutes or even seconds. And they can just get ahold of the resources they need to build the applications that they want to. Whether they're software startups, trying to create the next Facebook or next Instagram or next Twitter or what have you. Or they're the developers in some enterprise, some department. And they're absolutely sick and tired of waiting for resources that they should be easy to get because they could get it in the cloud anywhere. So these are the developers who are taking advantage of the cloud. And when they do, they create so much value that they're creating the new startups that are taking over and displacing the old established companies. It's been quite remarkable to see this transformation. And to give credit where it's due, Amazon really did start this game. And there's this analyst firm called Redmonk that quite likes to tell this one story about the new king makers application developers where a developer group within an enterprise company handed a bill for $47,000 to their manager. The company they were working for was a cloud company that couldn't deliver those resources fast enough. And so even those developers went off to another cloud to get the resources so they could move quicker and faster. And I'd also, I think, pretty easily argue that because mobile, now when you pick up your phone and you install an app, so very often the name on that app isn't even a corporation anymore. It's the individual name of a developer. And it's become so much more personal that a developer creates a mobile application. And it hits big. And all of a sudden, they can support themselves and their families from this application they've created. They've made themselves a king just by doing application development on a ubiquitous platform, like iOS or Android. I mean, these are very much the canonical mobile platforms that people refer to in talking about this stuff. And especially so in the case of Android, where you can see how it was a second place to iOS, second to market, and yet through open source, they're able to bring on a lot of developers onto their platform and make it a huge success. There were very low barriers to entry when it came to developing applications on Android. So I would posit that application developers will make or break a platform, whatever that platform is, and especially including OpenStack. And there are tens of thousands of applications developers out there that we can reach and should reach and bring them onto OpenStack and OpenStack-powered clouds. There are hundreds of thousands of application developers that we need to reach out to and bring on to the OpenStack ecosystem and get them developing applications on top of OpenStack. Thank you so much for sickening with me this far. I know it's kind of late in the day. Here's a bad slide. You see the comic sans? Obscured text? And speaking of the past, this was back when I lived in Edmonton, almost a record, almost a record snowfall year. I wish we had the audio because my kids were laughing their heads off as I dive into the snow. So how do we get to where we need to go? What's that roadmap for actually bringing application developers onto our OpenStack platform? I think it's obvious. Phase one, collect underpants. Phase two, phase three, profit. Simple, right? And I see this business model actually kind of played out in the real world, right? I mean, the idea is people are just grabbing eyeballs with the applications they're developing. And when you get that crazy hockey stick spike in the eyeballs you're getting, you need to be able to scale. And that platform you're on needs to be able to scale. And this is what OpenStack provides and what we need it to provide in order for developers to rely on OpenStack. And we need documentation. We need great documentation for application developers so that they can get started so they can dig in to the details that they need to when they need to hit scale. We need beautiful APIs. I'm really encouraged by some of the sessions that I see in the Design Summit tomorrow about creating more consistent OpenStack APIs, about the next Nova V3 API, how they're just making it alone more consistent, and sessions on making all the OpenStack APIs more consistent with each other. Developers love beautiful APIs. I know I do. I write code to them all the time. And I literally have a metric of how bad an API is as to how much of an effect it has on my marriage. So I've had a lot of late nights, a lot of short tempers when I hit a bad API and I am coding late into the night. So we want beautiful APIs. Tools. They need tools to be more productive, to accelerate their development. We need software development kits, SDKs. These are tool kits written in specific programming languages that talk to the OpenStack API. And using these SDKs accelerates application developers. If they're using their own language, they can just start coding directly to the API and just get going right away. They don't have to worry about all the plumbing that you have to do if you're talking to an HTTP API. Integrated development environments. Another common tool of developers that they can use to accelerate their development. And if they're using IDEs, we should be providing tools within those IDEs to help them use OpenStack. We need to make all of this stuff discoverable. What's the point of having it if people can't find it? But what do they really want? So far, I'm just telling you what they want, right? And that's such an easy trap for all of us developers to fall into, whether we're application developers or OpenStack developers. I'm a developer. I know what developers want. It's the easiest trap to fall into. We need to go to those developers and find out exactly what it is that they want. They need to tell us. Hence the user survey. So there's a new section in the user survey, and the tab is called Your OpenStack Usage. A bit vague. The URL itself says app dev sec. I think it is application developer section. So this is a section targeted towards application developers and the kinds of things that they want and need and whatever else that we might have forgotten. So I'm not going to take you through it like this, obviously, but just to give you an idea of what it looks like when you actually go to take the user survey, it's a series of questions with multiple choice or you can fill in an other answer for the stuff we haven't been able to anticipate, because that's probably the most important stuff there is. So there's a question about SDK, what software development could you be using to talk to OpenStack? There's a whole long list. What programming language are you using? Have we missed some really important up and coming programming language community that is really effectively using OpenStack? Can we accelerate their application development by providing an SDK for them? In the API format, are people getting their responses back in XML or JSON? Deployment and configuration. Here we're actually kind of throwing a bone to that other group, the application operators. What are they using to actually put their applications out onto OpenStack Clouds? These are tools like Chef or Puppet or Ansible or Salt. There's a whole handful of these kinds of tools that allow them to deploy resources and configure them. And sometimes there's overlap, and they do things that other tools do. But we need to know what it is they're using so we can support those tools better. What operating system are they using so we can do our testing? What IDEs are they using? What integrated development environments are they using so we can provide tools within those IDEs? And then this is probably the section that I find most interesting. A simple text area for open answers. Asking the developers, asking the application developers, what is it we're missing? What would make your life easier? What have we overlooked? Tell us. Let us know. Is there something we can do for you? And again, there's a question on documentation saying, what would be effective SDK and API documentation for you? What are you looking for when you use SDK and API documentation? I know what I'm looking for when I'm using API documentation. I've written about it before. I'm looking for not ambiguous API documentation to sum it up. OK, so we created this section of the survey in a communal way out on the OpenStack Dev mailing list. I threw some sample questions out there and some sample answers out there. And we iterated on this thing through a couple of email threads. And we finally arrived at what you saw there. And then we baked it into the user survey. And about a month later, I realized, oh, how did I forget that? How could I have forgotten that question? And then a month later after that, oh, how did I forget this other question? And then just yesterday, I thought of another question that we should have included. So we had to start somewhere like anything. And this is what I missed, what we missed. What APIs are people using when they talk to the OpenStack Cloud? There are actually a number of APIs you can use to talk to usually an open source version of an OpenStack Cloud, like a vanilla version of an OpenStack Cloud. You can deploy various APIs on it. And we're going to see them in a second. The OpenStack API itself, the Amazon Web Services APIs for their EC2, that's their compute portion of Amazon, or S3, that's their storage portion of Amazon. So you can actually layer these APIs on top of OpenStack and talk to OpenStack via those APIs. And then OpenStack translates it into OpenStack commands and executes on those commands that way. And the reason they do this is because of the ecosystem of tools that developers have created for Amazon. And people don't want to rewrite all those tools. So there is a sizable portion of the community who would like to see the AWS APIs on OpenStack. There's also something known as the OCC APIs. This is an API out of a standards body, which I gather has gained some traction because people seem to keep talking about it. So sure, if people want standards bodies APIs, that's cool. And then people are even talking about layering the Google APIs for Google Compute Engine or Google Cloud Storage onto OpenStack. So treating an OpenStack cloud like Google Compute Engine or Cloud Storage. Now, to just rant for just a minute, there's been a recent ruling in Google versus Oracle. And the result of this ruling is that APIs can be copyrightable. This is huge for the entire software industry, not just OpenStack. If an API is copyrightable, that means you can't take that API and re-implement it. And that is a fundamental need in software development. It's one of the purposes of software development. But Oracle has had a previous ruling overturned. And now they're saying that APIs are copyrightable. The story's not over. There's still a question of fair use. So Google can still claim fair use and be able to re-implement an API. And they can also appeal that decision that's been made. So this ruling could actually have a huge impact on the software industry as a whole. And if people are looking at using different APIs for OpenStack, OpenStack in particular. So I encourage you to just Google Oracle versus, well, Google API ruling or anything like that. It's actually specifically about Java and Android. And read up on a little bit about it. There's a really great article from the EFF, the Electronic Frontier Foundation, about the kinds of things you can do to voice your descent in this crazy ruling that could stifle innovation across the whole entire software industry. Rant off, no more doom and gloom. Let's move on. Where are developers getting support? It's just a fact of software development that developers are going to run into problems all the time. And they usually immediately go to Google. But that's just a search engine. Where are they actually getting the support they need? Where are those questions getting answered? Are they getting their answers on Stack Overflow? Perhaps ask.openstack.org, which is kind of like an open source version of Stack Overflow that the OpenStack foundation has deployed? Are they going to the mailing list of OpenStack or of the various other SDKs or tools that have their own communities? Are they going straight to those communities to get their answers? We need to know because we need to get there and help them where they expect to be helped. This is the one I just thought of the other day. Why aren't we asking people about their app? What app is it that you've created? We would love to include this sort of stuff in the OpenStack newsletters. I would love to see a section in the OpenStack newsletter saying apps on OpenStack. And there is a list every week of a few apps on OpenStack. And these are apps that people can go and find out more about how they're built. And we can share the knowledge of the people who are actually creating applications on OpenStack. And if you're an operator or somehow involved in an OpenStack cloud, I kind of expect you are, because you're here, then I encourage you to tell your developers about the survey so that we can get more data and we can base our own development of tools and everything else on actual data. Tomorrow, Tim Bell and Ryan Lane and maybe JC are going to be presenting the results of the spring 2014 user survey. So this is the one that has been circulated, I think, about three months ago. So this is the first one that will have this user survey section in it. So I'm absolutely dying to see what the results are. I don't know yet. I'm still in the dark, and I'm really looking forward to this. This is 340, a couple levels down in room 101. I'd also like to highlight one other session tomorrow, kind of in the same idea that we want to provide a better developer experience. And one of the ways we're doing that is through this user survey. And then going back to that discoverable piece, actually providing them a destination where they can learn more about the tools that they can use to create applications on OpenStack. OK, so last but not least, who have I forgotten? These poor guys, right? So like OpenStack started with a core of OpenStack developers, likewise, we need that core, it's going to be a much larger core, of application developers on OpenStack, creating those killer applications for OpenStack, and growing the ecosystem on top of the OpenStack platform. And then hopefully we'll be able to spend a little more time thinking and caring for our application operators and the problems that they're having. There's already, we've already begun on this thing. They have a lot of tools, a lot of their stuff is applicable across many clouds. But I think we can also do a better job there, too. Thank you very much. My name is Evertaves. I really encourage you to go to openstack.org slash user survey and encourage everyone around you to go as well. Thank you.