 Hi, everyone. I'm Anne Gentel and I see customers in the cloud all the time. So I want you to picture this. I'm at my son's preschool in his two-year-old classroom. I'm on a ladder and I'm cleaning the air vents up above for our spring cleaning day. It's a volunteer day with the rest of the parents. So one of the moms who's working with me on the windows turns to me and says, oh, where do you work? And I say, oh, I work at Rackspace here in town, you know, even though corporate offices are in San Antonio, I'm here in Austin. And she said, oh, we use Rackspace. We use it for this refund rebate site that we have for our city of Austin website so that when the rebate time of the year comes around for your air conditioning, you get to use this website. And we only need it sometimes where there's big traffic the rest of the time it's down. I'm like, wow, this woman knows what cloud means and why you have it. So that is my story of finding customers everywhere. I work on a team of about 30 people at Rackspace and we are the developer experience team. We do upstream work, outreach work and open source. We support directly developers using the Rackspace cloud, which is built on OpenStack. And we now officially support certain SDKs. And so what I'm going to talk about today is what is developer support and what does it look like? And I will take questions at the end. So I'm trying to time it so that I give you time to ask me as well. So what is developer support? Why are we here today? What are some of the terms I'm going to use? Developer support is a bridge to users, users of SDKs, users of the APIs. In our case, we specifically support multiple languages. We have some Polyglot developers on our team, but we also have people who focus directly on specific languages and specific libraries that work on basically cross-cloud, multi-cloud, Rackspace cloud APIs. We also do developer documentation. And so most of you who know who I am know that I am the documentation PTL, Program Technical Lead for OpenStack. And I've done that work since OpenStack started four years ago. I also serve on the technical committee. And so I feel like it's a chance for me to talk not just about documentation. Usually that's all I'm preaching when I come talking to Summit. But I wanted to do a deep dive on very specific documentation for developers using our APIs. Now when we at Rackspace do developer support, we actually really love this book called the Developer Support Handbook. It was written by a Google developer advocate. She'd been working there about four years. Her name is Pamela Fox. So definitely look this book up. She has some guiding principles that are right there in the introduction. Oh, and another note about this book. There's an entire chapter dedicated to documentation. It's there. But this handbook talks about how we need to care about your developer's success. We need to put ourselves in their shoes when they're struggling middle of the night on a deadline trying to get something working. Really think about their viewpoint. Keep them informed, right? That's the point of documentation, but not just dry, dull, boring API documentation. Also blogs and looking at what they are working on and helping them collaborate with you on how to articles. That is an important part of informing your developer base. And always listen to your developers. And I'm going to talk a lot about how we're listening and on what channels developers tend to be. And then importantly, appreciate them, send them stickers, send them gifts, give them trips to your conferences, help them really feel like they are building something with you. And when they ask for features, they know they're asking a team that cares about them. So these are some of the supported languages and libraries that we support on OpenStack first than the Rackspace Cloud. So we test against, honestly, our developers stand up at DevStack and make sure the API calls and their SDK calls work against a DevSkat cloud as well as our Rackspace Cloud. I won't read the list to you, but this gives you an idea. J Clouds is across Amazon. It supports AWS. It's across cloud. We can support HP Cloud. We can support Rackspace Cloud. And it's the same thing with some of these other cross-cloud providers like Fog. We're trying to be, I guess, cloud agnostic. And the main point is that when you see something say something, even if it's not in your language of choice, we're not all contributor developers. We're not all Python developers. These are application developers writing apps on an OpenStack cloud. Well, the great thing about the team I'm on is we actually have a good sense of humor about some tooling for developer support. We have a tool called Parall. And it basically watches on all the channels that we know developers to be on. And they actually put really funny messages like, someone needs help. Weep, weep, weep, weep. It's actually something that notifies us. And this is a shot of our internal channel where we can listen to these all day long and scroll back and up. It's like IRC with nicer pictures and better linking, I guess. But we're watching on lots of places, including our own Exchange server where we have an SDK support at rackspace.com, email address. And the funniest thing was one time the Exchange server was slower than our Parall tool. So Parall sent up an alert and we read it online and then the email came through. Happens quite a bit. But I want to say this shows support across a community setting rather than just individuals reaching out one by one. We're able to actually watch a bunch of sites that developers tend to hang out on and ask questions. So what are some of the places where we're seeing people come in? We watch Stack Overflow, and so our tool uses slurpers. Stack Slurp right up at the top, 13.09%. Another big one is Hub Slurp, which is to watch GitHub issues and pull requests against the SDKs that we support. And it's interesting, the largest one is this RSS Slurp, and so that's a grouping of, say, JCloud's issues plus a community site that we're on Rackspace, a community.rackspace.com website where we can subscribe to an RSS feed. And so the kind of keywords we're looking for are Fog, Rackspace-Cloud, Package Cloud, Go For Cloud, looking for the actual SDK names. And I think it's interesting what we're observing, and so that's what I want to deep dive into today is what kind of things are we seeing from application developers trying to work on an OpenStack Cloud as their platform base. So what are we going to see? Application developers in the wild. So who are they? What channels do they talk on? What do they look like? Where do they hang out? Where do they get their questions answered? Where are they talking to us, the OpenStack community? So these are some of the tools where we're listening. And I'm going to talk about each one in turn. Discuss is a message and commenting system that you can add to your documentation. Gotta lead with that. Stack Overflow is one of a collection of sites that offers question and answers for developers, and we'll deep dive into that because they have an API that I could query to find out more. GitHub also provides an API, and we're going to talk about each one of these in turn. The next one is actually TriStack's Facebook page. And I don't know if you know a lot about TriStack, but you actually have to have a Facebook login to use the API. So we're going to look a little bit at that later on. And then the last one is ask.openstack.org. That's the site where you can do a question and answer style posting very similar to Stack Overflow, but it's an open source engine running it. And then I'll be able to talk about some of the questions we're seeing, the answers, how fast we're answering, those kind of, that kind of metrics and data. So Discuss is a threaded commenting system. We use it a lot on Rackspace API documentation, and so I've been observing that for about three and a half years since we had it in place. In OpenStack documentation, we've actually removed a commenting because we could add a doc bug and a link to ask.openstack.org. So we decided to sort of funnel those to those channels more appropriately than just monitoring all these Discuss comments coming in. We really like doc bugs, so that system's working well for us. Next, Stack Exchange is a collection of sites. Specifically, OpenStack questions are on Stack Overflow where a lot of developers hang out. This engine actually boosts motivations for answering questions by having kind of this voting up and helping out others as part of the site's credibility that you get by being on the site, helping other people on the site. And they have a lot of data, and we'll be able to dive into it a little bit more. GitHub issues turned out to be a really good place to look for the actual users and the problems they were having with SDKs specifically. And so when you want to find out why a developer is having trouble with your SDK, this is a place to look. And then like I said, TriStack, we actually get really cool comments on the Facebook page that you have to use to get to your API on TriStack, which is this community cloud with a bunch of donated compute nodes from various people in the OpenStack community. And then the last one is this Askbot. Askbot is the engine running ask.openstack.org. One of the patterns I saw is that if a person can't find the answer on Stack Overflow, where they almost always will ask first, they'll come over to Ask.openstack. So let's do a deep dive on the data. First of all, discuss comments. We definitely see three categories for requests for help on discuss. When something doesn't work as they expect, they will come to the documentation and ask a question. And so that's just like a shout out for help. Hey, I tried this. It didn't work. I expected this. Can you tell me how do I get from what I got to what I expect? I'm also finding that they're asking for features that may or may not exist. So this is a real place to mine that goal of what is the next thing to implement in an API that users are looking for. And then lastly, the request for a docs fix. This has happened on the Rackspace Cloud APIs documentation where one of our build tools removed all of the indents from our JSON examples. Kind of embarrassing, but man, immediately we heard about it from the discuss comments. And I have also seen a pattern where people will ask a bunch of questions at once on a single document. And it's as if they're doing a review of this document all the way through. And so that's really useful to a doc writer to actually know that people are reading and reviewing your documentation is a huge bonus. But it is interesting to see that pattern of, it's obvious you read through this whole thing, because I now have six comments to address in the morning when I came in. And then Stack Overflow, I'm going to look at the frequently asked questions, related tags. That's tags related to the OpenStack tag. Some of the top tags we see and how they're grouped. Unanswered questions, that's a very important one. And also, who are we seeing answering the most? So frequently asked questions. Anybody have a guess? I'll ask you the questions. What do you think is the top question asked on Stack Overflow? And they have their own algorithm for how they're doing a frequently asked question. But for sure, why can't I ping SSH to and from IBMs? This is problematic. And I think that it happens because of security groups. Oftentimes, I've talked to many operators who say, number one user problem is they didn't set up security groups ahead of time. So there is a lot of setup before you actually get to a running VM that gets to the world that can ping Google.com. What's interesting is there are oftentimes these questions with the ping or SSH that have no answer. And I think that that's the type of question that goes past the, yes, I have security group set up. What's next? So that's the kind of deep dive where it is really hard to troubleshoot, because there are so many networking options. You may not know what that user has specifically in their DevStack, in their Provider Cloud. It's just really hard to troubleshoot. How do I change the admin password for the dashboard? That struck me as a surprise. And I think it is one of the top frequently asked. It does have an answer. But it just surprised me that the dashboard itself was kind of giving me hits on the OpenStack user side that it sounds like people actually want to get admin privileges right away. So to me, that points to the real, we need to get to the tipping point where people don't want to administer OpenStack Clouds. They want to run things on OpenStack Clouds. This one did not surprise me. And I'll tell you why. How can I create an OpenStack image by importing an OVF file? This page that explains how to do that on the OpenStack doc site is the most exited page. Now, you might think that means it's not doing its job. I say it is. People got the answer. Left the site. They're good. This is awesome. And then lastly, how do I make an application on OpenStack? And I tell you, this was in the top 10, but not the top three. So I think this is really crucial to understanding where we are in the timeline of adoption of OpenStack. People are running it like crazy. But we still need to make sure that we can serve the application developers who are saying, hey, I looked for Hello World on OpenStack. Never found it. So what is related to OpenStack? This next one shows from the API a data visualization of what is the most correlated tags by percentage of all the tags related to OpenStack. And what's interesting is, I don't know if you caught it on a previous slide, when I did the screenshot of the Stack Overflow related tags, there were 121 OpenStack-swift, 122 OpenStack-nova. So I think even in the week or so when I ran the data, these actually got a little bit out of sync. So what I'm finding is there is a lot of questions, Nova and Swift, for the first two. And here we are four years later. They're still very popular in people asking questions about them. But I also think that the large correlation to Cloud and Python is just that people, when they write tags, are going to definitely group things like, I need a Python person. Well, of course, this is very general. It's related to Cloud. I'm going to tag it this way. Now, this shows the ones most related to OpenStack. But what about the top tags? After you see the ones that are related, which ones are the most tagged questions that are tagged the most often? So the larger bubbles show that definitely Python, I would expect that from an OpenStack tag correlation Python. PyRx is a wrapper for all of the Python-nova client, Python-swift client, which were always meant to be used as libraries, not really CLIs, but that's more OpenStack lore. But PyRx is just a wrapper for Python developers to have objects to manipulate that based on those client libraries. And I think it's also important to notice. Anybody see a Windows relationship there? Next one, right? So I think that's important to note, too, that there are needs for Windows applications on OpenStack. And that is where a lot of questions are coming as well. The smaller bubbles are a grouping of tags that are just so many tags that it didn't show up a bunch, and that's the people who real tag happy. And they're like, I'm going to put six tags on this, and then my question will be answered. So that might be JavaJ, Clouds, Cloud, Amazon, Google. That's going to be a smaller set of questions. But I also think it's interesting that some of these smaller bubbles are related to security, related to networking. And so while there may not be a ton of questions about it, people are definitely looking to relate those. I'm trying to get this thing working on OpenStack. It relates to security problem. Now the interesting one, what about unanswered questions? And it's kind of a long list. Oftentimes, and the top one, and let me tell you, the frequently asked questions had 1,000 views, and these questions had 100 views. So it's hard to say whether these are actually not able to be answered, or whether they just aren't getting enough views. Like it's a small enough set of customers or users trying to figure this out that they're just not getting the foot traffic for someone to actually know the answer. But definitely, I want to say probably, oh gosh, the things that surprised me, I mean, still a lot of these are networking based, which I don't, of course, right? Like that's exactly what I would expect. I was honestly a little surprised to see some of the celiometer questions, getting no answers. But also that they were being asked that much. It seems like a new project to me in my OpenStack timeline. And the questions related to AWS are very interesting. In one case, they were saying they used the same command in Yucca tools. But then when they tried it in the AWS PHP SDK, it worked. So they were doing EC2 credentials against an OpenStack cloud. Very interesting. But also pointing out that our community doesn't always do that and may not know the answers, hence unanswered. So who are our rock stars answering these questions, right? Anybody have a guess? Is anybody in the audience? It's not PTLs. None of these guys are PTLs. And they are guys. I have to point that out. Matt Joyce, Everett Taves, Lauren Hoxstein, the rock star is out on Stack Overflow answering questions. And these guys have been around OpenStack for years. They were very early on. Everett Taves actually set up one of the first OpenStack Clouds in Canada, then flew to Australia and helped Tom Feifield set up the first OpenStack Cloud in Australia. So these are guys who've been around the community a while. They've been on the operator side. They've been on the developer side. Everett is now a maintainer on J Clouds. And so these are people that are all up and down the stack of what I do for OpenStack. So how about Askbot? Askbot is that little engine that's open source that runs ask.openstack.org. There's about 4,000 page views a day. And I definitely see there are way more questions from operators than application developers on Askbot OpenStack. That could be correlated to it's not exactly where developers hang out, because it's so specialized. So the developers are on Stack Overflow. But I think it is interesting to think about how we could start to aggregate and combine efforts across companies for supporting application developers on an OpenStack Cloud. If you think about how also an API call needs to be configured, some of what my data was showing is that even if it was related to an API or an SDK, it was still an operator or an engineer trying to get OpenStack working for their users. And so what I think it would be great to do to collaborate is to figure out how to support those users' users, the super users' users. That's who we need to get to that next level. So a little bit of a deep dive on the data. VMware, what? Why is this even in the top part, top portion? Well, there's this little thing called a VC-SDK that an engineer has to download and install and configure in order to get that particular hypervisor driver working in Nova. So that's why that ended up on the list. But I'm also not surprised to see PHP quite high. And we especially see a lot of popularity with PHP and our Cloud Files product, which is Swift Object Storage. But it was pretty funny to see VMware in the top four. And you can also tell the volume isn't very big. There's less than 30 questions, even in the top one, onask.openstack.org. And then ones that have API in the question or answer set is interesting to me. Now to me, I think it's fairly obvious that identity is going to be the source of most of your questions because it is the gatekeeper, the first thing you do. I read a paper that said Keystone is Cookie Monster. So it is the way that you have to talk to any of the APIs. So of course, identity is going to have the most questions. Next is compute followed by networking. Here's the one that surprised me. Why isn't storage somewhere in the top three? Well, guess what? Measuring, metering, that's in the top four, right? So that one actually took me a little by surprise. But I think that ask.openstack.org is a logical place for people to ask questions about salameter and its API. How do I set alarms? How do I trigger alarms? All of these kinds of things. And it's fairly new. So again, I was a little bit surprised. So let's deep dive on the next bit of data. Octocat, our friend, let's look at the GitHub issues that we see. The GitHub issues are interesting when you look at specific SDKs. And so that's where being on the team I'm at really gives me a good viewpoint into how our users really putting this into place, putting this into practice. So the one I did a deep dive on, because one of my team members had done it his first week at Rackspace, is PHP OpenCloud. And so he looked through 190 GitHub issues and did some categorization. Were they asking about a particular platform? Were they asking about a particular service? And what he found is 28% were specifically asking about object storage. And then only 9% about the SDK itself. And it's not even so much questions because GitHub issues are very specific bug requests. I thought it should work like this, but I actually got this. Can you tell me where my cognitive dissonance is caused by a bug or actually a design? Some of the users on this platform, I'll go back to another Austin, Texas story. Oh, but first of all, the number one by downloads WordPress backup tool. It's called Updraft Plus, uses PHP OpenCloud. So they are using the SDK to do backups of WordPress. And I also know a statistic where I heard that WordPress sites are 22% of the internet. So this is a big deal. These are people we need to support, keep them running, help the rest of the internet keep up. Right? But Savado Technologies, you wouldn't know it by the name, but they actually make power tools for real estate agents. And so they'll host the websites, they will do the video listings, they will do these office display rotators where they're actually, when you walk into the real estate office, you see all these beautiful houses for sale. And they actually do synchronization of data between, in the US, MLS is multiple listing services. And that's where all the base layer data for real estate listings is found. And in real estate webmasters is another one, and they actually do the websites themselves, and they're hosted on Rackspace Cloud Files, which is object storage. And the house I bought most recently, right after the Portland Summit moved in, was in fact, hosted on this person's account. So, small world when you come to OpenStack customers. Call Fire is a video broadcast, and it actually does reminders and notifications via video, very interesting use of the technology. They also do phone trees, which, you know, any time I call a doctor's office, I'm like, do I need, wait, is it scheduling? I don't know, but anyhow, they're responsible for keeping that going. They also do some of the auto dial leaving messages for political campaigns. And one of the US-based ones is moveon.org, they're actually one of their customers for basically getting the message out to people on political action items. And then Dear Doc is a way for customers, patients to securely transmit messages with their doctors. So next, let's look into TriStack. Last time I looked at TriStack a couple months ago, there were 10,000 members. There are 15,000 members now. So this is amazing, it's this growth thing, and it's basically a community cloud with shared resources. People have very limited quotas, so many of the questions are about their quotas, and I actually had the opportunity, thanks to Dan Redez, who runs all of TriStack, to look through all the logs, and let me tell you, people were querying their quotas or their policies all the time because they get very limited storage, very limited instances. But I think the neatest thing about this particular project is someone posted just the other day, Dan Redez, you're my hero, you've inspired me to build a cloud in my garage, and it is growing faster than I ever expected, so that is really cool. I hope it'll move out of the garage someday, right? So we also found that a lot of TriStack users tend to go to the dashboard, but then we also have services turned on that are API only. So if you want to use load balancing as a service, you must use the API. Another thing that happens commonly, because it's such a small cluster, the floating IPs run out, and Dan has to sort of scramble to reset the database and make sure everybody gets a floating IP again. They also had the open vSwitch database go corrupt, he had to rebuild it, so it's a neat case study in what it takes to run a cloud and serve users. So what do I want us to think about today based on all of this data that we're seeing? What are some of the takeaways? What have we learned from actually looking at what our users are asking? For one, on PHP OpenCloud, we had a person who just said, look, I have these large files, but I'm on this terrible network. Can you do any kind of timeout optimization? So there are very specific things that SDK developers can do to have that empathy for the application developers. We will absolutely be able to think, API and SDK developers will always want to do bulk actions. I'm gonna do things on 1,000 objects. I'm gonna do things on 10,000 objects. Try to think about bulk operations. Consistent naming, this is one of the most difficult things to do when you're creating an API is for projects in their silos, they don't often look over to other APIs that came before them to replicate their naming. So I think that's a really important thing. And anytime I look at supporting developers, a lot of times it's the names or the assumptions about names that get in the way. I think that that will go a long ways. And I also want to make sure that we think about date time formats. I think that's, isn't that one of the hardest computer science problems, whether you start with zero or one and then any kind of date time subtraction, it's pretty terrible, right? So just think about how to make sure that every OpenSec API uses these consistently, thinks about these consistently. And also across services, making sure that, you know, if Celiometer chooses one way but Nova had already chosen another, just not to make the assumption that they would know my API works this way if they're already used to another. And of course, the errors and error messages. This is from one of the PHP OpenCloud users and he's like, yeah, sure, if you've been doing this forever and you're totally great at it, which I'm not yet, you'd know what a 409 means. But in my case, I had no idea. I was just told good luck figuring out. And this is where documentation comes into play, of course, but I would also like to encourage us as a community to make sure that the APIs can tell people more about the errors that they're getting and do customize error messages and don't just make them look up that 409 error HTTP error. So another thing I wanted to discover was I'm really tied into OpenStack releases. I know Icehouse, I know Juno, I know Havana, Grizzly. I know all these code names for the releases. Are SDK and API developers understanding or tied to releases at all? The answer is nope. They do not even know, probably don't even care. And while we are very tied to releases, the users just wanna get their thing running with the SDK version that they're handed. The SDKs themselves have not caught up with the fast addition of projects to OpenStack. So JClouds does not yet have heat support. It does not yet have Celiometer support. It does not have Glance v2 support. It does not have Keystone v3 support. It does not have IPv6 support. All of this is discoverable from looking at their backlog of what they're working on. So I would also like OpenStack as a community to understand they need the resources to get these implemented. Oh, and what's the hot new thing in Swift? Storage policies, not yet in the SDK. And that's just for JClouds. There are some that are ahead and some that are behind, but JClouds is a large one and pretty well supported. So I want us to start thinking about how, look, the adoption of these actual services on the API level are behind and are not, we can't just assume that an SDK is gonna have it right away. So this is my favorite documentation joke. Dockers, the hot new thing. The new hotness. No, documentation is the new hotness, let's go. All right, so these are some links of how documentation is supporting OpenStack and application developers on OpenStack. Last release, we set up developer.openstack.org. You can get all the links to all the SDKs that are known to support OpenStack Clouds. We actually have had an API reference for, oh, three years now. And I tell you, when we first announced it in conjunction with the launch of TriStack, I had people come up to me after the talk afterwards and I was like, thank you for doing that. I finally have the information I need to get going. There's also a new movement toward API specifications. And so I have a series of patches going in that will, onspecs.openstack.org, that will define to the contributor developers what it is that the API itself will do, look for, should be standard. And I'm doing a design summit session about scaling documentation across projects. And one of the things that is really hard to scale documentation across is API documentation, specifically reference documentation. And we're still not serving the application developer very well in the documentation path through SDK docs and that kind of thing because the SDKs themselves, like J Clouds, like PHP OpenCloud, take care of their documentation within their, I guess, community, which makes sense. So we're linking to them. So what is it that we can do also as a community besides documentation? I'm always preaching about documentation. But it is shaping our content strategy. This kind of deep dive is helping us look at other things. And so what is it about the SDKs that we can do? What's another area of activity if you wanna get involved? The OpenStack Python SDK is a new, relatively new. It's been around a couple years now, but slowly adding more and more services. And so there's a getting started talk about that right here in this room this afternoon. And then also there's an API-competible mock service and it's called MIMIC. And so there's a talk about that on Wednesday. And so there are things that people in the community are doing to make sure that our API testing can be very robust, very across services, find these inconsistencies and then we'll be able to fix them, right? And then one of the most important ones going on are new working groups. And I mean, literally I was in the OpenStack training on Sunday and there's a new flag that the API working group put together called API Impact. And so a contributor developer can put that on their commit message and then the working group will know to go review that patch for any kind of API. And so API guidance or API consistency across services. And so the API working group is just getting going but we have a lot of sessions to discuss at the summit and a lot of people adding themselves to our Wiki page. And the idea is to offer style guidance, to write a set of draft guidelines so that contributor developers have a place to look it up instead of just kind of inventing it when they write the patch. There's also the application ecosystem working group. They have a bit more of a wider scope, a little bit loftier goals, create an environment where a diverse array of applications built for OpenStack can thrive. And so they're doing a couple of sessions again where we need to start talking. And especially if you are engineering or operating in OpenStack Cloud, please help us understand your users and what you are doing and what you need the OpenStack community itself to make sure that ecosystem is activated and that they can start to talk to each other. And then let's, this is my call to action. Let's watch and learn. I wanna talk about a couple of takeaways. I would like to see us strategically invest in documentation, API documentation, reference documentation, examples, how to run code right away, and how to do community-based docs that are still about this set of APIs that we are providing where we are serving not only the application developer themselves, but also serving the developers writing the J Clouds, the LibCloud, the CrossCloud SDKs. Because we have that opportunity to do community-based support on Stack Overflow, on ask.OpenStack, as a community, I would love to see us work with the contributor developers on ensuring that the application developers are also supported. And also work with contributor developers to make sure that their API design is really robust, really thought about all the edge cases, really has that user empathy, put themselves in their shoes. That's the end of my data collection. Do we have any questions? Go ahead and step up to the mic and ask. And I'll try to do a good job of repeating it back. Boy, I was really worried you guys have asked me the tough questions about the data. Right, the question is, is the Parallel tool open? And I have to tell you, yes, it is. You can write your own slurpers for it, but yeah, it's completely open source and it's under Racker Labs on the GitHub, on GitHub site with the Racker Labs org. So github.com slash Racker Labs slash Parallel. I would love to see us maybe in OpenStack stand up an instance of it. And it's frankly hilarious. So it's really cool to see that stuff. And if we just had it connected to an IRC channel where the notifications came in, just keep an eye on that all day. It'd be really interesting, especially 24-hour round-the-clock kind of support. Yeah. It's like, help, help. Somebody needs help. Weep, weep. It's pretty cool. Yeah. I like that question. So the question is, is there any way we can add on ask.openstack.org a way to identify the type of person asking the question? Is that accurate? We have a really good relationship with the developers of Ask.OpenStack, the Askbot itself. One of the things I'd like to add, that identifier would be great, right? Persona-driven, who's asking what sort of empathy can we have for this particular person? I don't know today, but they're open source developments, so all we have to do is ask. Yeah. Yeah. Any other questions? Right. The question is, how does the feedback we receive channel back to the SDKs themselves? Because our whole team is very in tune to the support aspect, I think it's really neat. Our developer advocates are the ones doing the support. We also have this team of people who are in support teams at Rackspace directly supporting developers. So we have that line from support to product. In Rackspace's case, that's just a direct line to say, we want to be able to boot from volume. We want to be able to have these kinds. So we have an entire backlog of things that came in from developer support. And then there was one more question I can probably go ahead and take. Yeah. So the question is similar to this one, which is, now that we have all of this information, is there a feedback loop to the developers making their products? This is, I think, the first session on developer support at a summit. And it, again, just speaks to the fact of where we are in the whole timeline. We've been supporting operators really well for a little while. We've got to get really good at supporting the application developers and getting that feedback loop. Yeah. OK. Thanks so much for coming, everyone. I really appreciate your time.