 Okay guys, welcome to the Saturday session here at DevConf. The next talk, well the first one of this day, is going to be about a how to build a successful open source project presented by Joe Brogmeier, who is a manager at Red Hat, but has been engaged in many open source projects and basically is an open source enthusiast. So please welcome Joe. Thank you. Okay, thank you for the introduction. So I'm just going to jump right to the slide that has all my pertinent information here. I'm going to give all this information not because I like to fluff up the talk or talk a lot about myself, but because this is relevant in terms of the talk itself. So I've been at Red Hat since August 2013. I've been an Apache Software Foundation member. I joined the Apache Software Foundation working on the Apache CloudStack project when I was working for Citrix. I'm also a PMC member in the Incubator, which how many people are familiar with the Apache Incubator? That's kind of where this title comes from a little bit. Okay, so how many people are familiar with the Apache Software Foundation? Okay, good. We have what is called an incubator for new projects. Basically, you don't just walk into Apache and say, hi, I have a lump of code and now I would like a project, make it a TLP and give me resources. You come to the Apache Software Foundation and say, hi, we have a small but hopefully growing community or we have something that we would like to turn into an Apache community. Will you please accept us? And they say, okay, we'll put you in the incubator to make sure that we're doing things the Apache way because Apache is a 501C3 that has rules that govern how it releases code and things like that. And companies like Red Hat and IBM actually trust Apache to release code that they can count on having already been vetted somewhat and have legal dependencies and all these other things. So there is an incubation process for every project that they have to go through that makes sure that one company isn't dominating the project or make sure that you're not releasing stuff that everybody expects if it comes out of the Apache Software Foundation, it's Apache Software Foundation licensing, right? So you got to make sure that they're not doing something really fun like depending on LGPL libraries unexpectedly and things like that. I was the first OpenSUSA community manager. I did that for two years. That was an experience. I'm also a recovering tech journalist. I did that for many, many years. Basically, most publications that cover OpenSource I have written for at some point and completely unrelated to the talk. These are many of the things that I really enjoy. All right. So what we're going to cover in this talk, I talk a little fast and I apologize for that although I think at least my perception when I'm sitting listening to other people talk is that it's harder to get bored when the speaker talks quickly. So people can actually listen at a much faster rate than most people speak. That is not a problem that most people have when I'm talking about things on stage. So anyway, I'm going to talk about why this is important. I want to talk about defining success for a project because I have people come up to me all the time. It's like, you know, we want to make our project successful. Great. What do you mean by that? So we'll talk about that. We'll talk a little bit about governance and community. By the way, this talk is compressing a lot of things that don't always go together. But as you might guess, a lot of these things have to do with my day job working in OSAS and we bring all of these things together. You will also notice that the one thing I'm not going to cover in this talk is trying to tell any of you how to run your projects technically. Okay. I'm not going to have an opinion over Jenkins over Travis CI. I'm not going to have an opinion over code indentation. I don't have an opinion on Golang versus Pearl versus whatever. These are things that you can decide. I am not an expert in any of those things. Infrastructure. We're going to talk a little bit about project infrastructure and what you actually need to have for a successful project. I'm going to talk a little bit about marketing and promotion. I am not using the textbook term of marketing here. We're really, when we talk about marketing for projects, we're looking at a lot of things from public relations and marketing and promotions and communications and things. But they all kind of blend together when you don't have a distinct marketing and PR budget and analyst budget and all of those things. Okay. And finally, I just want to put in a solicitation for how can we help your projects? And I will reiterate this later. We do not have infinite resources or people, but OSAS would like to help projects as much as we can. That may vary between if there is a business case to help a project. By the way, how many are red-hatters here? Okay. So if there's a business case to help grow your project, we can make that. And I've been through that process. That process takes a long time. Another important thing is anything that you think is going to take two weeks can take up to a year when you're talking about budgets. But anything we can do, we will certainly try to do. I want to put in a quick plug. This is part of the marketing part that comes at the end. But remember, use social media, okay? So I want to put in a plug for the conference. Please tweet about this talk. Please tweet about the other talks that you're going to. These are the relevant details right here. I'm JZB on Twitter. By the way, that's a really easy way to find me later. DevConfCZ is a conference and hashtag DevConfCZ. Please make a point to blog, write, do whatever to promote the conference and have I said that the conference organizers have done a great job because if I haven't, I want to say that right now. So, all right. So what is community over code? Basically, you can do a couple of things in open source and companies run projects in a couple of different ways. One way to run an open source project is to develop something, toss it over the wall with an open source license and keep going and do traditional development as if open source processes don't actually exist. Okay, so you could basically spend all of your time doing things the traditional way, not taking input from other people, not really trying to build a community. And you can go a fair long way with that sort of thing. Anybody remember MySQL? They did that for a long time and they basically for a long time were very popular. People think MySQL is on an upward trajectory at this point. Right. Not because the quality of the code is necessarily worse than it was five, six, seven years ago, but because the quality of the community has gone downhill and people have moved on to other things. How you do things is as important sometimes as what you do. This goes against, for example, the example of the fantastic contributor who's kind of a pain in the butt to work with. Okay, but he's such a good contributor. Yeah, but five other people left your project because they didn't want to deal with that first thing in the morning when they look in their email. Okay? So what you have in your project, you have to always be building and trying to make your community better. You cannot afford, I'm going to use a bad word, but I'm quoting somebody, as Donnie Burkholz would say, when you have somebody, and we all have bad days, that doesn't mean like the first time somebody sends a grumpy email that they should be booted, but when there are consistent bad actors or people who are consistently hard to work with, you may want to find ways to either coach them or remove them from your community. By the way, coaching is important too. Don't just go straight to like, okay, well, your time's up, thank you for coming. Sometimes people just don't know. Okay? And you could do a whole talk about that, which I will not do, but something to think about. Remember that everyone leaves eventually, one way or the other. Sometimes it's feet first, but hopefully it's because they found another day job or something else. And you cannot depend on a community basically always being around one person or a set of contributors, okay? You need to build a community that is going to be sustained. And that we think about, okay, if you're at this level of the company and you want to move up, you need to be thinking about grooming other people to take your job so you don't leave a vacuum, right? Same thing in the community. If you are a hardcore contributor to something, unless you're going to make a lifetime commitment and plan on that project not to outlive you, you need to be thinking about who's going to replace you when you move on, okay? The other thing that I see a lot with companies and I'm not pointing a finger at anybody's Citrix is, you know, basically we'll do it right later. Most important, we have to ship now, okay? That will get you through this quarter. That will get you through the next quarter. It might get you through a year or two. It will doom your project, okay? Now, you may be able to coast on a good project, a technically good project for a while, but unless you're building a community around it, it's not sustainable, okay? So, sometimes you need to make a choice to think about the long-term future and maybe miss a ship date sometimes or maybe figure out how you're going to work around bringing in other actors from other companies, okay? Pardon me while I take a... So some of the core principles that you need to have in any successful community. Communication and openness. In Apache, we like to say on the mailing list, it didn't happen. What this means is in a project, you can't take decisions in groups of two or three people and then bring them back and not allow other people to have input when they are... should be part of that process, okay? So when we go to a patch icon, we don't get a bunch of people sitting together in a room and making decisions for a project. You can talk about things. You can come up with plans and you can carry that back to the mailing list and say, hey, what do y'all think of this? We were sitting in person. We were at the pub last night, whatever. And we have some great ideas. But you have to give other people ways to weigh in, okay? Mentorship. You have to spend some time working on talent in your community. You have to spend time bringing people up to speed. You have to spend some time working with people who have been there a while who may have plateaued. Maybe they're a great programmer who has plateaued or whatever. Or they're organizational skills of plateaued. So you need to always be spending time mentoring other people. You also need to be willing to be mentored and ask for help. This was a hard thing for me when I started working with Apache because for many, many years I was a writer and I was used to tinkering with technology and figuring it out alone and having just a deadline to worry about. But I did a couple of cycles as a point release manager and I quickly learned my limitations with Git and with doing merges and things like that. And I could have waited and struggled with it or I could just go to people who knew better than I and ask for help and that's what I did. But it wasn't the first time. It was the first time somebody poked me like, hey, you know that thing you said you were going to have done yesterday? What's going on? So you've got to be willing to do both. How many people participate in any way in atomic or docker efforts, container efforts? Or where? Just a couple people. Okay. How many people work with upstreams that are relevant to a Red Hat product? Okay. Anybody ever run into problems where Red Hat needs to ship something or we need a feature or we need a patch or something like that and upstream doesn't want it? Okay. That's not fun, is it? No. Now imagine turn the tables. Imagine we're running an upstream project and someone comes to us and they have the same problem. Okay. We have to find ways to give other people a seat at the table when we're running a project and we want a seat at the table when we're participating in the project. There needs to be a clear path to having rights in a project. Quality is often better than speed. I think this one pretty much speaks for itself, right? Another core principle all contributions matter. If you look at Debian if you look at Fedora if you look at many of the projects that are more than 10 years old you will notice that their language is burdened with when it comes to participation or membership and things like that. They all center around packaging and technical contributions. They do not center around things like people who do graphics or people who do social media work or blogging or documentation or any of the other things that make projects go. So you need to make sure that your community also respects and thanks people for contributions that are not code. Okay. There are a lot of contributions that we need from people that are not just code. And finally, users matter. How many people went to Tim Burke's keynote yesterday? Most of you, I hope? Not as many as I thought. Okay. Well, one of the things that he said when he was talking about how to be an effective developer I don't like the term rock star, but an effective developer is that if you're just doing something for yourself it's basically an academic exercise. And this is a problem I had with KDE when they did the infamous 3.5 to 4.0 switch was they got a bunch of feedback saying, no this is not good enough, this is not whatever, this is not what we want. And they were like, well we're the ones doing the work, we don't care what your opinion is. That was literally what they said back to people. If you're not doing it for the users why are you doing it? I mean why put it on GitHub if you're not doing it for anybody else, right? Why ship it if it's not for other people? So you have to think about your users' wants and needs. Sometimes you have to hold back the desire to say patches welcome and instead work on other people's problems. So defining success is another very important part of this. By the way, I'm happy to take questions I think I only have 40 minutes so there's a lot to cover, but I am happy to take questions during the talk. So feel free, I know you're all very shy, so feel free to raise a hand if you have something to say. Define your project goals. You need to know what you're building, why you're building it and for whom. Again, I get called into conversations where people are like we want a community, okay? A community of whom to do what, you know? Just having kind of this nebulous idea that more people is better doesn't quite work. You need to know your target audience. You need to know what you want to get out of that. Now Red Hat often when the first goal is we need to continue growing and making money. But when we talk about an audience and who we're trying to reach, that varies, you know? Who we're trying to actually pull in and projects differ. So for example, the audience for Fedora is much larger and less well-defined than say the audience for Overt, okay? We have a much better defined audience for a project like Overt or RDO than we do for something like Fedora. And I'm sure most of you have watched the last few years as Fedora has worked on, you know, okay, we shipped this big distribution that's general purpose and you figure out what to do with it to okay, the message we're getting is we need to do a better job of delivering a tailored experience for certain use cases, okay? Also has to be measurable, okay? You can do a lot of stuff and measure success and trace it back to what you've done, it's useless, okay? You need to communicate the goals to everyone in the project on a regular basis, okay? This is one thing, it's very easy for people to get tunnel vision on the one thing that they work on and lose track of what they should be really focused on big picture, okay? So you need to occasionally remind people of the mission of the project or what you are trying to achieve. It is possible to be successful accidentally, docker, but it is it's hard to sustain, okay? It's really, the Linux kernel is a perfect, the Linux kernel breaks many, many, many of these rules and they have been just tremendously lucky at the right place, at the right time, they did some things right, they did some things horribly wrong, but you know, they are a poster child for open source, they are also a terrible example, okay? You can just stumble into success but I wouldn't count on it. All right, I want to talk briefly about governance in community and I've already touched on this a little bit, but one size cannot fit all, okay? So I'm going to pick on somebody in the audience, Ian runs a project called Image Factory, okay? And that project has a narrow focus, it's user base is about this big if Fedora is this big, right? And so a governance policy or governance setup for his project is not the same thing that's going to work for Fedora, it's not the same thing that works for Docker or anybody else, okay? So the scope of your project and the mission of your project is going to affect your governance. But some clear guidelines on how things are done is very important. People come into a project and I'm always because with Project Atomic, I was heads down in that project and had a pretty good idea of what we wanted to do and then a new person would come in and say, I want to help but I have no idea where to start and I'm like, it's obvious, right? Okay, it's obvious to me, it's not obvious to them, okay? It's not obvious who to go to want to change something. It's not obvious where to change something. So you have to have a map for people, okay? You also want to know how does the user get rights to become a contributor, okay? How many people have sent patches to a project for a long time and gotten frustrated because it's like, look, I've been working with you for three years, I've been sending patches, you accept them, but I can't just commit directly to the repository. That's frustrating, right? Okay, you don't want to do that. I've had that experience with documentation. It's like, you know, after 50, 60 patches, if you still don't trust me to do it right and you're not telling me how I'm doing it wrong, I'm starting to lose faith that, you know, I'm ever going to be on equal footing, okay? Likewise, if you are accepted as a contributor, how do you become part of the inner circle that makes decisions about the project? How do you earn rights? You really need to have those things be clear. Sometimes they don't need to be enumerated as long as you're doing them well and you have a culture of that, but this is one of the things that we work on in the Apache Software Foundation and the incubators, trying to teach projects that, you know, you started this project with 12 people from your company, you've been in here for a year, we have 15 other companies contributing and yet somehow mysteriously not a single one of them has contribution rights. That's a problem, okay? We can't, Red Hat cannot build successful communities if other people never feel like they're going to be equal. Other companies are not going to put money into participating in our projects if they don't feel like they'll ever, ever be close to equal, okay? Golden Rule treat contributors like you want to be treated in another project. Look around your projects and ask yourself would I personally contribute to this if, you know, it was run by someone else, okay? How many people, for example, object to canonical CLA's and won't contribute to things because of the CLA's that canonical has, okay? We shouldn't have those things and we try not to have those things because we want people to contribute, okay? We don't want to have better rights than others, for example. And finally, this isn't precisely governance, but I've already talked about the importance of, you know, recognizing contributions from others. I also want to just briefly touch on you need to pay attention to diversity in your project both for people and skills, okay? You need to make sure that you're not just cultivating other people like you. You need to try to broaden your community. A couple of suggestions, again I've already touched on a couple of these things. Everything should happen on the equivalent to a mailing list, okay? If you have IRC meetings at a certain time, guaranteed it's two o'clock in the morning for somebody who might be contributing to your community, right? If you live in Europe and everybody else participates in the project is on the west coast of the United States, you are going to have a lot of trouble participating in real-time meetings. If you're in Australia and, you know, whatever, it just holds true across the world and we have a lot of things like that. If you want to communicate, sometimes projects try to balance this by saying okay, once a month everybody in North America is getting up at 2 a.m. to have this thing. People don't do their best work at 2 in the morning, maybe find an asynchronous way to communicate instead, okay? These are often also, you know, my experience in Apache that I think works very well. Try to give people about 72 hours on a mailing list of feedback. That's about 72 business hours. Don't send something out at 8 a.m. Friday and then Monday morning call it good. Give people some reasonable time to communicate. But also hold to that window, okay? Set the expectation that if you open a discussion on a mailing list and by the way, if you're going to open a discussion on a mailing list, make it obvious. And hey, maybe even put discuss in front so people can identify those things versus random missives to the universe. But basically give people time to comment and then hold them to it. Don't let people come into a community and say I just wasn't paying attention to email for three weeks. I'm sorry but I want to go back and reverse this decision that we made. You know, you have to have a community where you can make decisions effectively and move on. I like lazy consensus for decision making. Is anybody familiar with lazy consensus? Hands? Not many, many. All right, lazy consensus is basically with certain exceptions, you send something to a list and when people don't reply, you're just assuming that's a senting to whatever it is that you want to do, okay? Now obviously there are things that you can't do that for. You can't lazy consensus a license change from ASL to GPL v3. You need direct ascent for that. But generally speaking lazy consensus and in Apache for example you can't add a PMC member based on lazy consensus or do a release on lazy consensus. You actually have to get strong plus ones from people. But as far as like, well I would like to change this library to this library in this tiny little part of the project. I want to send that to a mailing list and give people a chance to look at it, but you don't want to hold the decision so long that it holds everything up. Leave your hat at the door pun intended. When you are participating in a project, you should never be taking the position that my opinion matters more than yours because I work for Red Hat. You should never take the position that you're, you know, if somebody from picked whatever company in your heads is a direct competitor to Red Hat or a rival company on the planet comes into your community and wants to make a contribution, they should not be dismissed because of that. As long as they are participating in good faith they should be treated equally. I already said the part about make decisions stick and finally document the hell out of everything please. Find a way to, when you make decisions, put them somewhere they can be found and revisited so that you know this is a thing I see over and over again in projects and frankly just general human interactions when it involves groups that have rotating people in and out is decision is made time passes, six months later people forget about the decision and want to revisit it or people didn't like that decision and use an opportunity of time passing to bring it up again. Sometimes that's valid, sometimes things change but usually it's just a disruption so if you make a decision that you're going to do X, Y or Z document it and refer people back to that decision and not just keep reliving conversations over and over again. Any questions on that? Is any of this helping or making sense? Okay. Infrastructure what I like to call the care and feeding for community. These are pretty obvious but these are things in OSAS we set up over and over again. Mailing lists for projects you should have a user list, you should have a develop list, you should have a private list more than likely, you should have a security alias that goes to somebody who is going to be responsible for security things. For the love of all this holy, please do not have a security alias if no one pays attention to it, just send it directly to red hat security. The worst thing in the world is when someone actually sends you like you have a zero day and nobody notices. So have somebody who is responsible for paying attention to those things. Depending on the project it may or may not merit having a forum, it depends on the audience that you have and whether they like to interact on forums and this is a really important part whether you have someone to man the forum or woman the forum sorry I don't want to be people the forum and watch for things coming in. Because if you have a forum where people are asking questions or spamming it and no one is watching that's bad. This is the thing that we've had lately with Project Atomic which I was running Project Atomic as a community lead and then I got promoted and had other people and all this other stuff and then suddenly like I don't have time to go look at the forum every day but we didn't backfill the position for six months so it's tumbleweeds and spam, lots of spam and so please pay attention to that. Bug tracker, pretty obvious right you need one. Documentation and maybe a wiki wikis are where information goes to die but people still like them. I forget what I said a few months ago I got retweeted a bunch but something like there's no better way to see broken hopes and dreams than a wiki you know. Yes. That's a legitimate question I mean they can be useful but also if you go through, I'll pick on fedora if you go through the fedora wiki it's not maintained well and who has the time? Sorry? Sure, sure, sure but large areas are not. I will assume that the QE portion is lovingly maintained all right. Code repositories, clearly you have to thank you, clearly you have to have those probably? Just pass around it's horrible, sure whatever works. More than likely your code repository these days is going to be get maybe on github, maybe some other pager one of those other services how many folks know about fedora pager? Okay fedora actually provides a service for people who want to host code and do not want to be on a proprietary service it is not as fancy or you know whatever is github but it's maintained an open source and you don't have to worry about it turning evil one day when Oracle buys github Anybody remember the whole kernel thing and why we have get, what's that? Bitkeeper, thank you, yeah. Right, right it amazes me how people do not learn from history bitkeeper is why we have get and now everybody has moved to github which is kind of like bitkeeper but you know, all right you may want to provide it I'm sorry, sure and in ten years we'll say without github we won't have whatever comes after it but moving on Trello and Kanban you may want to provide these things to track things that are not bugs features and ideas and so forth there's Kanboard there's a couple of other free software versions of this that people really like continuous integration this is something that a couple of years ago wasn't really a thing but projects are asking for more and more is a way to do testing and continuous integration these are good things, you should find a way to do them you should do them early in your project before things move to a point where it becomes ugly and you're too deeply into suggesting what you do technically I would even suggest I think we had a talk about this yesterday about somebody said no commit without documentation I would also suggest no commits without tests and finally and very importantly translation tools because not everybody speaks English and maybe people in other parts of the world would like to have things in their language so very briefly this thing we're doing here where I can see you and you can see me and we can exchange words and beers it's a good thing, it's a good way to build community and you should find ways to do it in your community if you possibly can we still do not have a way to deliver beer over TCPIP, this is a tragedy but it's the truth so meetups, lugs, daycares probably not daycares but find a way to meet people in your community and talk about your projects most of you probably live in a city where other people care about your technology so get out and meet them and talk to them and you will learn things and they will learn things from you more than likely I come to a lot of these things and I do talks and I guarantee you that I will learn more at this conference and you will learn sitting through my talk and I don't just mean attending other talks I just mean talking to other people and hearing their ideas and learning what they're doing okay that said it does not depend on having a budget to do in-person collaboration all of the time so make it count and try to make it happen try to find time when you are in a group for learning, socializing and doing try to do all of those things when you are at a conference try to spend some time working try to spend some time going to talks and learning from other people and try to spend some time going out and actually socializing with people because that part is important too I love open source I got into open source and I got enthused about open source when I was working for Linux mall in 1999 in the first conference I went to there were two vendors that we worked with that sold backup products and I was used to the proprietary world where company A and company B can't like each other because they're competing right? No after the show was over they all went to dinner and had beers together and I'm like wait I can go have beers with people that work for a competitor I can do work with competitors I can have friends all over the industry how much would it suck if every time somebody left red hat you could no longer be friends with them or talk to them or work with them that would be horrible we're all here really because we love working with this community right? so remember that when we're working on these things and finally when you do in person events try to carry back to the community as possible for two reasons one a lot of people who are here for every person who's here there are ten people who are not who care about what's going on here or more so you have a responsibility for carrying some of this information back to those folks take the highlights back don't make them feel jealous I'm not talking about the pictures on Facebook of like world's largest beer no I'm talking about bring back information that will help them and because they couldn't attend and hopefully they will do the same for you write up blogs about one or two talks that you went to that are useful share information I'm pushing this is a slow process because people are resistant but I'm pushing with OSAS anytime we fun travel for anybody you must blog about it you must provide pictures you must carry back information but also it helps you remember what you learned here if you take the responsibility to sit down and write an event report or sit down and actually blog about talks it will help you retain that information okay marketing and promotion last bits first of all you need to know your audience and your goals we've already covered that right but if you don't have sharp goals you are unfocused in what you want to do marketing wise think about who you want to reach think about the personas okay we did an exercise was it last year or the year before we sat down we were starting to talk about the developer tools for containers and we started talking about well who are the people who are going to use these things that's deeply important okay what do the people want that are using your stuff craft a story to them okay you need to see and then go back and see how what you're doing fits that story okay do a feedback loop you should be doing user surveys you should be talking to your users and asking them okay how are we doing is this working for you are you enjoying this can we do better where can we do better sometimes that will also entice people to join in and help because where do contributors come from they come from users they come from a beautiful cocoon after using something for a while they enter the little thing and then they come out as a butterfly that contributes okay maybe not but seriously I mean most of the people who are contributing to open source these days started as users right you don't just leap into contributing project voice and messaging you need to tailor your website to your users and target audience in other words if you are trying to target website should not look like it came from 1999 with a bad hangover okay you need to have talking points and messaging for everybody that they can talk about your project you need to explain benefits this is something that hangs a lot of people up even like the fedora workstation folks I usually get when I was working on fedora marketing and trying to pull together the release for several years you would get back this implemented ah library and implemented this and weyland now does foo and it's like what does that do for me it's like I don't understand why do I care as a user I don't care that weyland does foo I care that it lets me do copy and paste between windows more efficiently I care about this that or the other I don't care about the technology I used to get horrible press releases from java companies I'm already too okay that's nice I don't know what that is but good for you tell me how that benefits me and finally find a way to show me how to be successful quickly if you don't have a start guide that helps someone up and running in whatever is a reasonable time frame five minutes is not reasonable for cloud stack five minutes is reasonable for atomic make sure that you have that blogging and social media okay take the time to write about what you're doing provide social media guidelines and advanced have an editorial calendar SEO scheduled target influencers for bonus points if you have somebody who works in social media and goes and follows people who are relevant to the industry that you're targeting and interacts with them and talks to them and gets them talking about your project you are on the road to better success than just blasting your message out okay finally release announcements this is something that drives me bug nuts because people want to notice engineering teams want to push a release out the door the minute it's done and they want to do this on a well we're not sure when it's going to be done it's done as soon as we fix this bug okay show it out the door and they don't give people time to write a release announcement or schedule it or do the proper exploitation as they say in blues brothers you know you actually if your code is done on Friday it's going to sit there till next Tuesday do not release an announcement on a Friday unless you just want no one to see it okay I am out of time so summary this is a process it is not an end state you will never be done successful communities change they grow they evolve okay single company projects are not as good projects if you build it they will not come you still have to promote it if you're not growing you are dying and finally golden rule keep that in mind thank you very much that is not my contact if you want to reach me jzb at red hat please thank you somebody asked questions who asked questions who asked questions during the talk who would like who would like a scarf anybody else