 Good afternoon everybody. I'm Jesse Nohler, developer advocate for Rackspace. Also Python contributor and other things. This is my name is Everett Taves. I too am a developer advocate at Rackspace. I'm there primarily working on our Java SDK for OpenStack and Rackspace and HP and all your OpenStack-powered Clouds, a project known as Apache J Clouds. And I'm going to be kind of winding things up at the end of the presentation. So I'll see you all in a little bit, and I'll turn things over to Jesse here. All right. So title of the talk, very simple, focusing on the developer experience and I'm gonna walk you through some of the problems that we're facing right now and why. So what is the actual problem that we're facing with OpenStack? I'm actually here with Everett today to actually have an honest and fairly opinionated and frank discussion with all of you. We're closing in on close to 30 individual client libraries inside of GitHub, Stackforge, etc. for OpenStack. These are the clients that if you're a developer trying to consume in OpenStack Cloud, you actually have to install and you in actually important use if you're going to actually consume and open to that cloud. This is actually only one aspect of a much more fundamental problem, which is why we're here today. But in God's name, why are we in this quagmire and why is that quagmire spreading? Why do we have 30 clients to actually just talk to an OpenStack Cloud? My thesis is that it's the definition in audience problem. So when I say users or developers, who are you thinking of? Just anyone, raise your hand, fill it out. You, okay, so you're thinking of you. Okay, raise your hand if you are currently building an OpenStack Cloud or deploying, building or deploying. All right, how many people in this room have built an application on a cloud? I don't care which, I'm not judging. Just built an actual featured application on a cloud in the past one to two years. Oh, thank you. The right people, although I'm preaching through the choir now. All right, so most of the people in this building, when I say, let's talk about developers, they are thinking users and developers are people building clouds. And you've heard this in the keynotes, you've heard this elsewhere. You can actually see this like systemically at this conference. Everybody here has very much an ops mindset. I'm building or I'm selling clouds. Jonathan called it out in his keynote. There are over 600 operators here, and that doesn't include the business people. I'm not even joking. We are looking at cloud builders selling clouds to other cloud builders here. And this actually invokes Conway's law within the community. Conway's law basically being the communication structure of your organization will reflect in the product that you actually end up providing. We have reached full inception. We are 10 levels deep here. So when we talk about developers, people get very, very, very confused. So it's time for a reset. Let's reset some key terminology just for a moment. The first, let's disambiguate. OpenStack developers are those building the cloud operating system or kernel or whatever you want to call it known as OpenStack. These are OpenStack developers. They are different. Technically, I have the commit bit. And then we have application developers. Application developers are the rest of the world of developers trying to write applications on the cloud. It really doesn't matter which one. Sometimes the two are mixed. Sometimes you're an OpenStack developer and an application developer. I know I am. But generally speaking, application devs are the ones that I'm here to talk about today that are generally ignored. So a question. What made Amazon a technology giant in eight years? It lies and I have a laser pointer. No, it's not books. Application developers did. So eight years ago EC2 and S3 were actually released. This kind of fundamentally disrupted our entire industry. The problem with OpenStack and the OpenStack community is that we have largely ignored them, not through malice. There's no, never attribute to malice what you could attribute just to people being focused elsewhere. We want to build a cloud operating system. Naturally, it tracks people wanting to actually build a cloud operating system. It's all ops all the time and all the way down. The vendors are guilty here too. My employer included. It's not just OpenStack. Most of the vendors in the community ignore application developers as well because we're all in the middle of a fundamental disruption within the industry. And so we're all kind of panicking and we're like, okay, everyone's got to have a cloud. You know, let's get the cloud. Except what was true 10 years ago isn't true anymore. It's not enough to go and package and build out clouds and then just let stuff happen. We're talking about platforms and what makes a platform. What fundamentally drives the adoption cycle and makes a cloud are the developers who consume it, who actually build applications and through that building of applications, they showcase the underlying platform and technology. That's what built AWS, an army of advocates building on this wonderfully powerful cloud OS and that's what OpenStack needs. Software, you've heard this before, you heard this earlier. Software is eating the world. Application developers are in fact the new king makers. If you actually haven't read the book, The New King Makers by the Red Monkey Guys, I recommend you do so. I also recommend if you're a business person, go and take a look at like 451, Evans Research and others. All of the market data backs up what I am saying. So the market typically doesn't lie, although it's been known to. Application developers are the key drivers of technology adoption today. From enterprise to startups, garages, dogs with blogs, etc. They're the ones. So what do I need to write an application on an OpenStack cloud in the programming language of my choice without having to build my own network effect, ecosystem and abstraction. Namely, everything you need and rely on as a developer every day. That's where OpenStack is falling over. We are consistently failing a key audience that we need to care about, that we need to actually woo, and I don't want to say sell, but seduce onto this platform. So that brings us to developer experience or DX. Handcrafted artisanal slides. That's my attempt at a developer, you can tell because of the beard. So developer experience. What is it? Developer experience is actually inspired by the user experience practice. It actually sees developers as a special case of overall users. And it is the practice of understanding how developers, application developers, disambiguation get their work done and optimizing for that. Actually, this quote from Pamela Fox really brought it home for me several years ago. The sum of all interactions and events, both positive and negative between a developer and a library, tool or API. That is developer experience in a nutshell. But why focus on it? Well, you need the group on the right. Right. We've got people who build and sell clouds. We got people who build stuff on clouds, and this is the current state of our community. This is bad. Network effects. So focusing on developer experience helps us build a developer network effect. Network effects are imperative to the growth of a platform. It is the net effect that one user of a good or a service has on the value of the products to other people. This is sociology. The better the experience, the more you get promoters, the more adopters, the greater the network effect. Network effects help build ecosystems. An army of promoters swayed by their peers, and trust me, peer pressure works not just with smoking, but also with cloud adoption. They help build the ecosystem. For example, Amazon, again. Because of the network effect and ecosystem behind AWS, we consistently and constantly hear the refrain and pressure of cloning their APIs inside of OpenStack just so that we can piggyback on an existing community of developers and tools. Think about that. Their ecosystem is so strong that they are now influencing others to basically black box implement their APIs. Network effects plus rich or rapidly growing ecosystems build something called innovative usage. Innovative usage feeds the system. This is the virtuous cycle of promoters creating things on your platform. You go from network effects, ecosystems, innovative usage. The next person who says, I just built this really amazing application feeds into a bunch of other people who want to build really amazing applications. It's very empowering. This is what we want. A fried egg. We want built on clouds surrounding us. We want people talking about us giving us constant feedback to actually work with the cloud builders. We need these promoters. Fried egg. Couple of examples. And actually we're padding this so we can have some Q&A at the end intentionally. So if it seems like I'm talking too fast, just say I'm talking too fast. But examples. Twilio. So take a look at this page. To get to here as a developer, it takes me one click. A single click. And I can actually see as a developer what I need to get started. Developers are the key to their market and they know it and they accept it. And another one, Stripe. It's not really infrastructure as a service, it's more like money as a service. Which is actually really cool because I'd really like that. But again, developers are actually critical to their adoption and they know it. But again, one click to get here. They've optimized for developers end to end. I see everything that I need to do to get started. And actually here's one close to home. Rackspace actually owns Mailgun. Mail is a service. Pretty simple, right? But its value, what it is, why it is, is all right there. That's their landing page. They have optimized that far down. They've said, we are a developer service, here you go. Look at that great code example that they have there. That's actually, you can swap it between languages, it remembers, it's amazing. So great app portals, developer portals, app developer portals, sorry, actually answer some very fundamental questions. Do I want to use it? How do I sign up? How do I get started? How do I use it? How do I get help? Five questions. Making things simple, intuitive, engaging, and showing developers how to be successful and enjoy building something using the platform is an imperative if you're going to survive. And this is more true in the cloud world than ever before because fundamentally developers are the ones who are going to show the value of the platform to others. And I don't know if this was Troy Toman or Chewbacca who said this quote. I'm not sure actually, but essentially every investment we make in OpenStack usability brings dividends to the entire community through these network effects. So UX, UI, Horizon, the command line clients, ease of use, ease of installation of those clients, everything helps build this network of promoters of developers that we need. So what can we do today? And this is kind of a tough one. We actually need to stand up within the community and within the actual development of OpenStack and advocate for those using OpenStack to build application builders. We have to advocate for them within the actual development community, within the board, technical committee, etc. Because we have to get their voices heard. That's Advocacy 101. Some current programs, and actually there's a Dean Troyer's client tools program is having a design summit concurrently with this, which is actually very awkward right now, three levels up. So if you totally want to bag and go to that, I understand if you want to influence the future. Go check out Dean Troyer's client tools program and contribute. That would help. He's focusing or him and many other people are focusing on optimizing application developers lives. The Python OpenStack SDK, this I actually kicked off and then I had to hand off to a co-worker just because of time, seeks to actually unify all 30 of the command line clients into a common back end and then working with the OpenStack CLI, which we've really got to work on shorter names. Working with the OpenStack CLI, you'd actually only have one point of entry on the command line and one point of entry as a programmer if you were writing in Python. Let's not talk about the other ones yet. Get involved in the OpenStack UX team. They need help, they need bandwidth, they need feedback. And we also need more application builder focused documentation. Right now, almost every piece of documentation is really aimed at I am building a cloud, I am contributing to OpenStack, or I'm deploying a cloud. Software development kits. So just to unpack that. Software development kits. This isn't just client bindings for a given programming language. It's like I can say, hey listen, this is a library, it talks to an API, I have a nice day all day long. Software development kits are something different. Software development kits come with examples. They come with amazing documentation, or are they better? And they come with the client binding. So if you're in Python, you can say import OpenStack, and you can say OpenStack.execute compute, here are my credits. But it comes with all of those things. So an SDK is a holistic approach to actually doing client bindings for an API. We need to actually embrace as OpenStack, as a community, other languages.net. Python, PHP, Ruby, well not Python, sorry, my bad. PHP, Ruby, Perl, Java, Go, you name it. In fact, I'd say C and C++ are in there too, because the company I worked at before Rackspace actually had to write a C and a C++ SDK for OpenStack. That was a pun. So the other thing is that OpenStack is very fond of not invented here syndrome. And we need to actually link in and adapt to existing open source and standard tools for development, DevOps and deployment. We need to stop reinventing the wheel. For example, Vagrant is a huge one. And I know we currently, I think we actually integrate well with Vagrant, but these are tools that developers need to be successful. So some bad things. And these are bad things that the community has done, and we really shouldn't be doing. Things like changing APIs between versions, right? Doing this without a long, well-communicated deprecation period will wipe out the ecosystem you just built. If you roll out an auth change and suddenly it gets deployed to, like say we hit the perfect world where you can do a one-click rolling upgrade of every OpenStack system in the world, everyone sets their Jenkins servers up to pull down trunk and we go and you roll out an auth change. You will wipe out every client and every application built on your cloud. That's simple. And I've seen it done. One point here, and working on Python Core for several years, conservatism in your APIs can actually be a virtue of large open source projects. Keep the core solid and consistent. This is less on the API layer and more underneath it. Stop changing underlying behavior or contracts without a longer deprecation policy. An API exposes a contract with a user. Users build on that contract and they get an expected behavior and they get a set of errors and responses. Every time you change those, they have to go and scramble and change some code. Users, especially users in the enterprise building applications, really don't like upgrading things much less the client stuff that worked yesterday. I think some of the stats that we have for Rackspace customers, they're using like PHP, Dawn of Time edition and they're never going to upgrade. And that's good. That's okay. We also can't tell people that they're doing it wrong. Now this is a cloud favorite. I love this one. It does this. They say time and time again, and I know a lot of cloud vendors who say this, design for failure, if you don't, you suck. So that's totally cool. Cattle not pets. You expect your cattle to randomly die when you're trying to spin it up. No, I don't, but nice. We can't do this as a community. We have to actually teach and educate and be honest with the limitations of the systems that we build. This will actually help instill more confidence that I can be successful building on your platform. On the other hand, if you are using a cloud or the cloud as a VPS thingy or a managed colobox, you are doing it wrong. I know I said not to say that, but I just had to get that out because it's pent up rage. So what is success? What does success look like? And I'd like to say that I've rewritten this deck with, I've actually hand drawn it, probably four times and I've redone it in keynotes, something like six just because. Success. Success actually looks like for OpenStack. Again, my focus is on the community, not me. Success looks like we will have a discoverable portal dedicated to application developers. It will speak to success when using the platform and it will talk about the speed of development on top of OpenStack. But most of all, it will actually showcase other successful applications built on the platform. Again, this is that network effect. This is reinforcing your peers and people coming into the community that they can be successful building on this. Why the platform made it successful is key. This is why you see hundreds of companies all over the place always doing customer success stories, you know, blah, blah, blah, made me a success. The same thing applies to tools, technologies and platforms. But fundamentally, we will actually be the most, we will be successful and it's not the end game. When we can actually answer who will be the next Instagram, Pinterest or as my sketch up there says cat social empowered by OpenStack. That's the question we have to answer because that's not the story we're hearing. We're hearing stories about people deploying rapidly agile clouds inside of their private data centers. We're not hearing about the applications built on those and we have to. So, a few other things. What else do we need to do? Let's address some other concerns. Everybody in this room and everybody who may watch this video, etc. Engage with the board of directors and the technical committee. Engage on the community level. The user experience team. Everybody else. We have to build a solid and consistent voice within the community for application developers and consumers of OpenStack clouds. Vendors, my employer included, have to engage with one another to build from common tools. Stop reinventing the wheel. I do not know how many JavaScript talking to OpenStack libraries there are, but it's more than 10 and less than 100. It's sort of scary. We have to dig into the user survey. Everett helped get an application developer section into the user survey. The community actually has to look at that data and act on it. Moreover, we actually need to get that survey out of our echo chamber and into the hands of people not actually using OpenStack. Sending a survey to a bunch of OpenStack people is kind of self-serving. We also have to drop the dogma. I've been in the Python community for probably 12 years now and that makes me feel really old. But the fact is, the developer world and the community is much bigger than the world of Python. And Python isn't always the right tool for the job, not just for client libraries, but also for the OpenStack system itself. APIs, integration points, etc. We have to be welcoming to other languages, methods and systems. And we have to pressure the vendors. We need to pressure the vendors for interoperability. We need them all to have an amazing developer experience from end to end. When one developer has a bad OpenStack experience on one vendor, we all get the black eye. So on the positive note to the future, I'll hand it off to Everett. Hey, let me see if her mic's on. Maybe you turned it off. Hello? Oh, it's on. Check one, siblings. Check two, siblings. Okay. So the future, what does this look like right now? We need to focus and cater to that developer audience that Jesse was talking about. We need that discoverable portal that developers have come to expect where their needs are catered to to make them productive and efficient when building applications. So this is a very common domain that developers have come to expect. It's a de facto standard. Developer.whatever.com.org.net, what have you. So if I'm trying to figure out how to develop on the Twitter API, I'm going to developer.twitter.com. I'm not even going to Google. I really don't honestly. I will simply type in developer.whatever.thetopleveldomainname. Some examples of some of the commercial companies that follow this. There's really countless. Here's just a small handful. developer.yahoo.com. Showcasing a lot of their excellent front end tools. And of course, they're a great community member in the open stack ecosystem. There's developers, plural in this case, it's a bit of a wart.google.com. This is like a tour de force in developer experience focused on getting developers rapidly building applications on the entire Google ecosystem. It's really very impressive. developer.github.com. Again, a very nice site, very direct, gets you started quickly and lets you dig deep when you need to. And it really showcases their great API very, very well. But it's not just commercial interests that follow this pattern. It works for open source too. The good people at Mozilla have realized the importance of developers supporting their ecosystem of applications. And so they provide their developer.mozilla.org site. Likewise with GNOME or GNOME project, if you will. Showcasing all of their tools that help developers get started on their platform. And now today I'm super happy to announce that we have developer.openstack.org. Yay! Thank you. So this is our commitment as the application developer community that we are focusing on them and getting them productive and getting them started off right. So you can go there right now. I encourage you to tweet it out far and wide. Now, it doesn't look like so much at the moment. This is just a starting point. It's a first step on a long road that we need to take and follow this path. So that we can bring more application developers into the OpenStack ecosystem and really start benefiting from those network effects. So now we have the visibility, the discoverability. We're going to iterate on this thing and make it that great developer portal that we need it to be for the application developers who are adopting OpenStack. And thank you so much for myself and Jesse here. And we'll take some questions. If we have time? Yeah, if you have time, I'm probably going to bolt pretty quick because there's those developer experience sessions going on on level three. But we'd be happy to take a question or two. Do we have time? Yeah? All right. Perfect. So we do have time for a couple of questions. So step up to one of the two beautiful mics. Or if you don't have any, we can totally go upstairs to the design session and rock that out. Questions, answers. All right. Well, we're good. Thank you very much. Have a good day. Thank you.