 Just in case you're wondering if you're in the right place, this is product development in the open. So just a little bit about me. My name is Brian Ross Mehta, that's my Twitter thing, I don't use it much, and my IRC Nick when I'm in the open stack rooms. I'm the Cloud Images product manager at Rackspace, and that's our groovy cloud images logo. So we just launched, what cloud images is, is a public lance endpoint in the Rackspace public cloud. So we've been live for about a month now. So you can do all sorts of great stuff, import images, export images, share images with other users. So feel free to check that out at our website. I've been an open stack technical contributor since Folsom, mostly working with Glance and documentation. I'm on the Glance drivers team, and I'm happy to be here, and I hope you are too, and I hope you're enjoying the summit. So what I want to talk about is, let me get that little hand out of the way. So this is the basic thing with the talk. So I want to talk about who cares about open stack, and then some talk about open source code development and product development, and then why product development is really important for open source, and then just some remarks about doing product development out in the open, what I mean about that, and then what you can do. But while I was putting this talk together, I was thinking it's really a little bit more than what you can do. I really think this is what you should do, and that's probably not even strong enough. I really think this is what we must do, we as product type people who are interested in open stack. And that brings me to this, the point about who cares about open stack. So this is mainly a celebration of open stack while we're here, but I just want to step back a little bit and think carefully about just open stack. So first question is, do end users, so people who are accessing the cloud to build VMs to do stuff, do they care about open stack? And I'd hate to say this, but probably not. That's the way it goes. Do they care about open source? Maybe people have a little bit of allegiance to that general idea of open source. But I really think for that one, it's also probably not. I mean, what they really want is they want their VMs to start up, they want their stuff to work, they want to be able to handle their workloads. So I don't think they really have an allegiance to open source, might give them a nice feeling, or maybe not. So can we just ignore them if they don't care about us? And right, again, probably not. I mean, if you're running a public cloud, definitely not because the end users are the ones who are ultimately paying the bills, so we need to make sure that we address their concerns. And even if you're running a private cloud, there's the shadow IT problem that Chris Lumie from Disney talked about. So it's just, if you don't give your users what you want, so you think if I'm running a private cloud, I've got a captive atmosphere. But if you're not giving the people who have to use it what they want, they're going to start developing other solutions or just using other stuff, and then you're going to have to cope with it. So I think even if you're running a private cloud, you can dictate, hey, we're going to use OpenStack. But if people don't want to, then you're going to have problems and have to adjust. So end users, I think, are probably kind of fickle, don't care much about OpenStack. So then how about cloud providers who are pretty big customers of OpenStack? Because they're actually using the software to deploy their clouds. So I think people who are working with OpenStack now, current and maybe potential people who are out there really care about open source. So they probably have a commitment to open source. But when we think about what providers want, I mean, the key thing is stability. So if we can deliver stability, we can have them. They want ongoing improvements. So they want the software to continually get better, add more features. They also want stability with the ongoing features. And then they need to have end user features that are competitive with the other clouds. So that's a key feature also. And they also want stability. So the key thing is that they're looking for things that don't necessarily have a lot to do with OpenStack as such, unless we provide these kinds of things. So when you think about it from the provider point of view, if your customer base is primarily interacting with a control panel, then it's kind of easy to swap out one control plane with another. And your customers might not even notice. They click in the same place as their VM startup. They really don't care about what software is actually powering the entire cloud. And you could also just switch to a different cloud software with a compatible API. And then even the API users might not notice, right? From the perspective of how they're interacting with curl or their scripts or whatever, the same stuff is happening. So for providers, I mean, I think stability is key. We have to provide that. But the point is it's, you know, basically, it's just kind of a jungle out there. I mean, people like OpenStack, they're going to show a little bit of allegiance to it, but only as long as it's doing what they actually want. And as we know in this kind of survival of the fittest atmosphere, it's not always the best product that wins. So there's no guarantee that just because OpenStack is designed better that it's actually going to be adopted more and used more. So just a sobering thought to scare us. So, all right, now the next question, though, is even scarier. And you can probably anticipate what I'm going to ask. And our software developers committed to OpenStack. Because of course, we need them because without software developers actually writing the stuff, we don't really have OpenStack. And it's kind of scary to think about that question. So you can talk to some developers, try to get a sense of what their motivations are. I think a lot of developers are committed to open source, again, similar to the providers. As far as OpenStack itself, well, OpenStack has like a particular kind of community atmosphere that you can see here. That's good. It's got some good practices that developers like. So that's good. But again, I mean, things could change. Other things could become popular. So I just don't know. So now the next question is, are you committed to OpenStack? And I don't really want to put anybody on the spot here. So I'll just change this. How about me? Am I committed to OpenStack? And sort of, I mean, yes, I mean, what I'm committed to is this ongoing shared product that we've got of developing excellent open source cloud software. And I think OpenStack really has that. And I think OpenStack is the best game in town. And I want to be a part of that. And I'm doing what I can. I'd like you to be a part of that too. But you can see all this stuff is there's a lot of stuff in motion and a lot of places where things could break down. So what I mean by an ongoing shared project is really the community. The OpenStack community is extremely important. So just so you're aware of that. So it's vibrant now, but it's not going to stay vibrant unless we actually do stuff. And I think we all have to do our share. So Troy Tomin's keynote on Monday, he mentioned the key thing about the OpenStack community is trust plus contribution. So we have this kind of trust with each other with what we're working on, that when we're doing code reviews, we're not just going to make snide nasty comments that are not helpful, but actually contribute to our ongoing project and contribution also. So it's really important that everyone find a way to contribute. So the point is when we talk about the OpenStack community, you can sort of think of it as something that's out there that you can step back and sort of watch and see this wonderful thing taking place. But it's really something to participate in. And that's what's key to keeping community going. So one way to just say this is the community requires constant care and nurturing. If it's going to remain the vibrant and exciting entity it is today. So I mean, when you go outside and you walk around the marketplace, you can see how exciting it is to be here and to be part of OpenStack. So I want you to sort of take that and translate it into action. So what this talk is really about is what you can do as somebody who might not necessarily be a software developer, you might have some other skills, right, how you can participate because keeping the community vibrant is really in all our interests because it's what keeps the developers there. So what's going to keep the providers there. So go on with that. All right, so the question I'd like to ask yourself is just not what am I going to do with OpenStack when I download a distribution, but really what am I going to do with OpenStack? So in addition to using the software, you should really get involved in the whole community and the development of OpenStack. So you can see these are pretty bare-boned slides. This is the only one I've got that's got like a cool image. So we can go with John F. Kennedy and just say, ask not what OpenStack can do for you, but what you can do for OpenStack. And I think this is a really a key thing because OpenStack can do a lot of stuff for you. But if you do stuff for OpenStack, we'll be able to keep it so that everyone can use it and it will continue to develop in a good way. Okay, so enough of my sort of pessimism. I guess it's not pessimism as much as just warning that the community is great, but we can't just sort of sit there and watch it. We've got to participate if we're going to keep it vibrant and keep this whole project going. Okay, so as you know, with open source code development, all the coding is done out in the open, so everybody can look at it. And anyone is a cloud provider, you can look at the code, the ops team can see what's going on, developers, end users if they really want to. And just random people passing by who find the website can just go look and see what the code is like. And it's not only that you can see the code, but you can also see all the peer reviews of the code because we have the Garret system. You can actually look through to see what people have said about it and what changes were made in response to that. So you can really see the history of code development, which is kind of interesting. So I mean, it's not just out there in the sense that the final product is there. You can see exactly, right, you can see what's going on, you can watch the sausage being made and see the history of the code development. You can also look up the ideas behind the piece of code, so exactly how it came that that particular feature was decided on and people decided to implement it. So places where you can look, there's an active mailing list for each of the projects where a lot of discussion goes on. So you can look at the archives of the mailing list. All the meetings are held on IRC, so you can go back to the meeting logs and see exactly how the discussions took place. So there are official IRC meeting channels, so OpenStackMeeting and OpenStackMeetingAlt. You can sort of go through and look for the minutes there. And then there are product-specific meeting channels, so like, for instance, with Glance, we have the OpenStack Glance channel where people get in and just talk about Glance, and a lot of design discussion happens there. So you can notice these things are getting smaller and smaller because, I guess I skipped too fast, because the stuff gets harder and harder to find. I mean, it's there, but you really have to search. So if you want to trace back to the origin of the tasks API for Glance, you've got to look through all the Glance meetings and try to find the few interactions about that particular thing. So it's like you're really doing open-source code archaeology to try to determine why things were developed, because you've got to really get in there and dig. So the information's there, but it's not always there in a really accessible form. And the history of how the code or how the idea for the future developed is important when you review the code. Because when people go to review the code, they can say it's acceptable because it's got no obvious flaws. So as far as the Python goes, everything's being used properly. It looks good. One reason to have experienced developers looking at it is just to make sure it doesn't break compatibility with other sections of the code of which the person working on this is unaware. But then another thing we're interested in, whether the features implemented correctly. And that's not always so obvious from looking at the particular piece of code you're working on. That's more involved with what the discussion was, what the original plan for the feature was. And another thing that sometimes not there is the migration path. Sometimes introducing new features to the code cause pain because there's a database migration involved or something like that. And so it's important that that actually be taken into consideration or else you're getting situations where the database is down for an hour while you're trying to migrate. It's pretty much unacceptable if you're running a cloud because it's got to be available all the time. So the last two aren't so evident just from looking at the code itself. So one sense it would be good if doing the code archaeology were not so archeological. So you didn't have to get down there and dig with the shovel so much. And so that comes to the next topic. So why product development is important for open source. So with modern product development, you're all familiar with this, right, it's customer validated. And open stack is really kind of interesting because we've got two customer segments that we need to worry about. So they're the deployers of clouds who actually use the open stack software. They need to be satisfied or else they're not going to deploy it. On the other hand, we have to also worry about end users who want to use actual cloud features in a cloud that's already deployed. So we really have two kind of market segments and we just need to pay attention to both of those. So just moving back to, so the idea with the customer validation is that you've got data that some kind of proposed feature is actually going to be used by real customers, right? And that's a very important thing because it helps guide the direction of code development. Now with modern software development, pretty much all the research agrees that software development goes better when the developers are more keyed in to the big picture, right? So they need to know the purpose of the feature they're developing, not just that, hey, you've got to do something that does this, but what's the business purpose for having this take place? So developers really need to understand how it fits into the big picture because then they can make better contributions as they're determining how they're going to design a particular feature. And the other thing that is good about software development is if developers are convinced that a feature is actually going to be used, it gives you better incentive to actually work on it. So it doesn't make it seem like this is kind of just a pointless task, it's something that you really want to do. So, and then the other thing is the code reviews of stuff that's implemented will be much more meaningful if these things are understood. If you understand the big picture of how the feature is supposed to fit in, what's supposed to happen, then you can have better code reviews. Okay, so product development in the open. So I think product type people do have a skill set that can make a contribution to the community and I'd even be stronger and say we can make a serious contribution to the community. So for one thing, we can decrease the amount of archaeology necessary by treating OpenStack code development as part of product development. And what I mean by this is don't just view OpenStack as something we can build a product around, but actually get more involved in actually developing the features as a product set. And I think this would increase developer satisfaction, right, they're more keyed into the business purposes or how this is going to work and that people are actually going to use the features. It can increase deployer awareness because they can see features that are coming before they get delivered and can comment also and then it helps documentation readiness because if all these things are worked out in a clear way then right it's much easier to write the documentation. And someone had to talk yesterday about user delight. I mean if you have all these things and your features are great then users are really going to like your cloud. So I might as well add that in there too. Okay, so given all this what can you do? So I got some ideas from this one. I looked at Chris Vandermeer's book, came out like two years ago called Shipping Greatness, and he has a couple of ideas that he drew on from his experience at Amazon and perhaps Google, I'm not sure though, I know Amazon for sure. But one thing is a press release before the product's built. So, right, you may be familiar with this idea, but the basic idea is just if you write the press release you articulate the main points of this particular feature and then it's kind of clear where it's supposed to go. But also as you're writing the press release it sort of makes you think about well does this make sense? And you can think about the customer validation you've hopefully done about does this really address what my customer interviews told me. And the other thing is FAQ before the product's built. And this is really kind of helpful because a lot of, with the open stack blueprint process, a lot of the blueprints are a little vague and it's not completely obvious what's supposed to happen. And the way something's developed may depend on which developer adopts it rather than what the overall idea is. So with the FAQ idea you can address some of the issues about how is this going to be used, what do we expect to happen in this case, what do we expect to have happened in that case. And it's also a way to capture a lot of the discussion that happens already in the particular product channels. Because as a feature is being developed somebody will just say, look I'm picking up this blueprint, I want to work on it, but how exactly are we going to deal with a final upfound condition. Do we just return a 404, do we do something better, what's the basic idea, how does that fit in. And then that kind of thing can be incorporated into the FAQ for, all right, what do I expect to see happen if the resource doesn't exist. Another thing we documented use cases can really help because they sort of stretch the boundaries and show you some of the edge cases with a feature. And again those are some of this, I mean this is like common sense kind of stuff, but it's also sort of missing. But this is something that product people can really help with. And then of course the customer validation. So if we know, I mean because it's a very powerful argument that a particular feature is important, if we know people actually want to use it and how they're going to use it. And it can settle a lot of arguments about well what's the best way to develop it, we can go this way or that way. And it's like well we need to go this way because this is what the customers have said. So and remember customers in this case is both cloud deployers who are going to deploy OpenStack and end users. So we really have two segments we need to satisfy. And in some cases they may have competing interests, but maybe not. And well, and so you can use your imaginations. So I'm not a real experienced product guy and a lot of you may have a lot more experience. There are probably other things you do in your normal course of product work that you can bring to OpenStack. So before I get to the examples, one thing I've noticed is that I don't know if you've been by the developers lounge, but this year it says right developers lounge and it says users and developers. Now it's a difference because the past two summits I've been at have been pretty strictly the developers lounge has been set apart from the main conference and you had to show your badge to get in that you were an active technical contributor or you were pretty much discouraged from going up there. So it's nice that now you can go in there. Although I did talk, I ran into one of the developers I work with and he just mentioned it's really crowded in there now and it's a bunch of people sitting there checking their email and taking up space. So what I want to do is encourage you to go in there, go to some of the design sessions, interact with the developers but interact with them. Don't just sort of anthropologically sit there and observe the community as you're checking your email. You really want to get involved. So there is a big push. We saw this in Troy's opening address. Want to get more segments of the community involved in the community and from the beginning of this talk you can see why that's important because the community is it's vibrant but it's really fragile. So it really I want to hammer this into the ground but go out there and get involved. All right. So I did promise some examples. So these are a few things I've worked on so I'm not saying this is the way to do it or even the best way although of course I think it's great but you know just some ideas of what you can do to sort of extend this and then my experience has been developers I mean I'll show you some of these pages right so the press release in the FAQ the developers think that's kind of stupid but the FAQ has turned out to be kind of helpful because it does answer some questions and it does it does help motivate some design discussion as things are going along. So the press release I think there's still a bit skeptical about but the FAQ is a help and as more of us do this kind of thing I think it will help people will start to understand that this really is a contribution. So you have to have a little bit of a thick skin. I mean I was introduced to a developer yesterday and I said I'm project product manager for cloud images you know you roll designs it's like one of those guys. So you just have to bear with it but I think as more of us do stuff I mean the developers the people who are involved in the community want open stack to succeed and want open stack to be great. So just keep that in mind as you're interacting with people. Anyway I set up some of these tiny URL things to make it easy for you to go look at these right now at your seat although they didn't turn out as easy as I wanted to. I wanted to just be ATL, BR and then 123 but two is taken by somebody else. So that's E2. Let's just take a quick look at this. Actually before I look I do want to just the key takeaways before I'll go show you some stuff and then open this up for questions which hopefully there's plenty of time for yeah lots of time for. So key things open stack is more than just code so there's a lot of people can do. The key thing I think about open stack is the community. So if you want open stack to succeed we have to make sure the community stays vibrant and the community succeeds and I think product type people can contribute to open stack and more than that I think product type people should contribute to open stack and I'll even do this one more time and say product type people must contribute to open stack if we really want this thing to happen. So enough of the preaching I'll say thank you but actually let me go do some examples before I say thank you. Okay so the open stack blueprint process has traditionally been done through launchpad and that's gradually changing. So Nova Neutron and Glantz is going to be doing it in this development cycle or switching to making the blueprints more like code. So there'll be a blueprint repository where you check out the template you create your own local branch and get you do what you want to do to it and then you submit it just like you through Garrett just like you would if it were a piece of code. So what happens with the Garrett review is your stuff is posted tests to run on it which I guess there could be some tests to make sure you filled out the thing properly I'm not sure if we're going to do that in the first iteration but there'll be a place where people can go to just look at it and leave comments like either right there or say you need to address this and then you address it and then you resubmit your review and people look at it again. So we'll be able to have a better ongoing discussion. The problem with Launchpad is that it's just so wide open that you're just faced with a blank page and that's a problem for a lot of people to get started what do you write and a lot of people write just a quick sentence and the way you go and then Launchpad sort of encouraged you to put the full specification of something an entirely different place from the blueprint and some people did and some people didn't so we're going to try to to unify this more so I my only point here is that this is sort of with the old style process. So this is for property protections which came out in ice not ice house the one before so grizzly I think no Havana one of those it's been around for a while. So with property protections basically it was needed to prepare so Lance traditionally has been exposed indirectly through the Nova API through the Compute API because you can do image lists and look at images that way. So we want to be able to move and then the problem with that is that if we wanted to expose some type of new feature in glance you'd have to write a Nova extension and if you've been in the design talks yesterday about the extensions that's been a big problem. So what we want to do is just have glance available by itself so that people can interact it with it directly and then if we introduce new features we don't have to build an extension to expose it and compute you can just get it from the images endpoint. But in order to do that in every cloud there's certain metadata that's put on images that's kind of important for the hypervisor or possibly for billing or for whatever and so some of the properties need to be protected so that users can't modify them and then other properties we just want to be available for people to mess with. And then the key thing is that it depends on from cloud to cloud which ones are protected and what your policies are so it had to be completely configurable. So that was a basic idea. So I'm not going to read through this you can check it out later if you want. So a quick press release just saying what's happening that's available in Havana and then the FAQ going through what property protections are about how the roles are going to work. So it was made a really flexible thing where you just you currently can define roles in JSON policy file for how calls who has access to what calls and glance. And so this was built on top of that and then just some questions about configurations how you're going to broadcast this to users and then why not take a different approach which is kind of an important thing to keep in mind because as you design anything several people are going to think about it and say well you could do it this way instead. And so if there's been that what the one thing I found if there's been a discussion and it's determined that something should not be pursued it's really important to document that because two months later somebody is going to say hey why don't you do it this way and we've already discussed it but it needs to be reopened as part of the vibrancy of the community but we can keep the community more focused by doing these kinds of things. Another example I wanted to show you is the with the Tasks API so you can take a look at this later the Tasks API was really interesting because I was actually a product driven feature into OpenStack so a lot of things are just brought up by developers that they notice end users would want to do this or somebody's told them we need to be able to do this. We decided to expose Glance I mean Glance has the ability you can upload images to it and you can download images and in a public cloud that might not be so great because if a lot of people are uploading a really big image on a really slow connection that can really affect things in your cloud. Also you have to worry about people uploading bizarre stuff like perhaps a JPEG or something and then trying to boot a server from it. So that's not going to be a very good user experience but they're going to waste a lot of time they'll import it they'll boot why isn't it booting they call support and it's like well you can't boot a JPEG so we want to try to avoid that kind of thing from the beginning. Another thing was just the nature of the way you deal with Glance is that it's similar to the server's API you can pull an image object images have a status and so you want to as things are happening with an image you can look at the status and when it's active you know it's usable. We wanted to make this a little bit more user friendly because when an image goes into error status what you know is that the image is in error status. What happened to it now I mean we behind the scenes can go look at logs and stuff but as far as the user's concerned error and it's like what so that's not really user friendly so the idea was to add tasks to Glance and then the idea is what you would do is you create a task to do a particular thing I guess I use the word task and I want to use it twice so you use a task to do some type of operation that you would like to have happen in your cloud so for instance importing an image and then what you can do is pull the task object and the idea is that you could that this was a really big discussion and we had it three times that's why I emphasized you need to record this so people people can look people are saying why don't we just pull the image because we already have a queued status that indicates that the image record is available but the data isn't and that's exactly what's happening with an import and the problem is all sorts of stuff can happen during an import because if somebody imports a JPEG we don't want it to succeed somebody might import an image but it might for various reasons you might want to reject it I mean it might have bad stuff on it that could compromise the hypervisor or it could just be you know the format's corrupted and we could detect that in advance and that's a better user experience so the idea is the kind of information you want to give back about a task that's happening is really different from the kind of information you want to have present about an image and so by having a separate task resource you can pull the resource and then the resource can evolve in a different direction from an image because tasks have different responsibilities and different ways to describe them and that kind of makes sense so that's ultimately the way we want so in Icehouse Glance does have import tasks and export tasks the default well to be extremely explicit about it the API is available the actual underlying stuff that does the tasks is still in review so you may have been at Jonathan Bryce's keynote where there's the guy in China wrote out his code and then put it on the ship so it's basically that's what's happening with the review for the asynchronous worker that processes the task so that should be be in glance soon but anyway so the main point is just you can take a kind of product approach and I think it really helps it will help the developers but the most important thing is it will contribute to the community and then you don't have to go overboard like I kind of did on these things so so you can even do something simple like this this is just articulating what community image sharing is supposed to be like so this is a blueprint that's accepted I think it's scheduled for Juno and it basically goes through where I said we've got some use cases for why you want to do it then there was a long discussion about what we should call it so the basic idea is that right now there are two types of images in glance you've got public images and those are ones that everyone can see in their default image list and then you have private images which are the ones that individual people own with image sharing in glance which hasn't been available since I want to say grizzly well either grizzly or Havana you can share images with other users but the the way it was designed when we did the image sharing we're very worried about spam so we're worried about people stuffing other customers image lists with just you know garbage basically or ads or you know stuff you know because I guess you could carry ads in the metadata of the image we don't nobody wants to see that so the way image sharing works in v2 glance is that you have a consumer producer relationship and so the producer if I want to share an image with you I make you a member of that image but that only what that does is that immediately allows you to build a server from that image if you knew the UUID the image won't actually appear in your image list until you go through a separate process and accept the image and then you can make it show up so that seems to to be a good way to handle the spam case now the case that community image sharing is built for is that we want to have sort of a middle ground so some open source projects just want to share images so as a cloud provider you might not want to make that a public image because if you have a public image in your cloud you have kind of an implied support relationship that you know what's in there it's good go ahead and build from this whereas these random things that people think work may work in some cases and not others so you want to have some way to distinguish them so community image sharing is going to be sort of a middle ground where individual users can share an image so that anybody in the cloud can build from it but it won't show up in anybody's image list until they accept it but the producer does not have to maintain a relationship with the consumer so anyway that's what community image sharing is so we had a lot of discussion about whether community is the correct name for this and that discussion went on for several weeks and basically what it comes down to is that nobody could think of anything better so everybody pretty much had some kind of problem with community but what can you do so that's basically it so do you have any questions oh yeah could you I can't hear up here for the presentation good work so how do you you know when the stakeholders are so you know distributed and product need to prioritize so can you share like your experience how you are doing that with so many stakeholders in a different part of the country and then building a priority list and getting a buy-in yeah well that's we've just started doing this process so it's hard because you want to find customers to interview but then everybody else does too so you don't want to bug them so it calls for some coordination and then just sort of some guesswork I'm so I don't have a good answer Christian oh develop oh okay sure oh okay so good quick but you know the developers also what what's what I find really interesting about working with OpenStack is it's really a 24-hour day project because they're developers located everywhere and with some of the IRC channel discussions you know you'll leave off in the morning and just say you know I just committed this can you take a look at it and sometimes somebody will review it that night and when you come back in you've got comments and you can work on it so it's it's kind of nice from that point of view but that's also where documenting stuff I mean my experience of working with developers I used to be one myself as developers hate doing documentation it is so beautiful and it explains everything it's just look at the code it's you know self commenting but that usually doesn't work for end users so I think developers do appreciate getting help with with things so one one thing you can do if you're in some of these discussions you know in the IRC meetings I mean you should definitely lurk check it out see how the discussions go but if you volunteer to help somebody because somebody will say all right I want to do this and there'll be a little bit of discussion somebody say okay go ahead and file a blueprint and we'll take it from there so it's a good place to volunteer is to sort of help with the blueprint process because you know having to write sentences that are in English instead of in Python is a problem for some people so they appreciate the help so it's one easy way to get in to just start make things go more smoothly yeah but a lot of this looks um you know like very traditional SDLC type model requirements functional specification high level design that sort of thing and you know I'm I've been in the private sector for many many many years where all of that stuff was kind of you know built in place so I'm kind of new to open source and a little surprise that a project of this kind of scope is lacking some of those controls so I guess that's more of a comment but I guess my question is you know myself as a developer I also realize the value of these kind of processes and you know how does how do you get your foot in the door and the in the open stack community to bring this kind of empowerment to our developers that's a really good question I think the way to do it is you have to I know instead of from the top then you have to go from the inside out basically because um yeah if if you show up and say hey here's an API that somebody should develop just on general principles nobody's going to do it so right so it's more I think so like the FAQ and stuff I didn't show up with the FAQ it was as the discussion so the discussion was originally how are we going to do this I think we need to have like important export and so just upload and download just so we have some controls so we talked about that for a while and then it was well where's that going to live in the URL and so there was some discussion about that and then there was like well maybe we could have a task because we were really worried about how are you going to get the information back to the customer that they're so we allow imports of VHDs so we run some validation checks to make sure the formats are correct and so you won't run into problems later so like how do you get that information back to the customer so once it's sort of converged that that was the direction then I went ahead and wrote this up and it's like here's some more stuff we can talk about to just kind of bring this into focus so you sort of have to do it so you have to be more organic than with a traditional model so these look sort of like traditional documents but it's sort of the mode of development is what's missing here and that's if you work from the bottom sort of up and have this as an end product rather than at the beginning and when I say that I mean we want this to sort of be ready when people start coding but all the discussion is going on so you have to be sensitive to the discussion and sort of capture what's the general consensus of the community is about a particular thing even if you don't agree with it and you know but these things are kind of influential and helping push things in a direction but if you push too hard you do get pushed back that you know your product guy what do you know so you just have to be sensitive and have a have a thick skin okay well that's my contact information so feel free to probably I've only like ever made one tweet so Twitter's probably not a good way to communicate with me but my email address is up there feel free to shoot me an email the main takeaway is I mean we've got a great community here we need to keep it going we all have to do stuff even if developers don't particularly like it we can really contribute so please do it had one more question oh sure you talked about documenting the consensus organically as it evolved but with regard to let's say you're representing a provider customer use case I would think it is okay to say hey this is what I'm seeing from my customers but I do realize that when you go to the granularity of things some of the what's become house and there you know it needs to be organically so can you speak to that do you see a distinction meaning there may be four different folks representing four different customer communities who can come and say hey these are the types of use cases that we see yeah I mean I think having the customer data now I've got to admit I've never actually had I haven't tried this in practice yet because I haven't had the customer data I think that would be a convincing argument to help drive the direction but you have to in dealing with the community you have to be open to the fact that things might not go your way and what's nice about the community though is it's always there's always good faith arguments and there may be a couple of other directions things could go that aren't quite what you want but there may be good technical technical reasons I think having customer data is kind of a strong one to say that you know this is the way people want to use this and I know that because we've actually gone out and asked them because a lot of the the features that have been developed is you know I'm a developer my friends are developers we sort of want to do things a certain way and what's our intuition may not match the intuitions of actual people are going to be using the APIs so it's important to have both but yeah you have you have to be ready you know you're going to lose some battles basically and that's open source okay well thank you very much