 I got the applause, so I guess I'm done. No, hi. So as she said, my name is Brian Prophet. I work with the open source and standards team within Red Hat. If any of you were here earlier for my colleague Jennifer's talk about corporate versus community, I'm definitely on the community side. So I'm the hippie with the make love sign. So our job in OSAS is to try to support the various open source communities that are very critical to Red Hat's product line and also provide support to communities beyond just those core products and projects. And in doing so, in the past, we've really worked to establish best practices and procedures for managing communities. And until recently, it's really all been done sort of with a gut feeling. People bring their own experiences to the community, how they've managed other organizations in the past, and they apply those principles to the community that they're managing. And for the most part, that works out really well. But being humans, there are going to be mistakes that are going to be made. We all not only bring our own skills to the conversation and the management of communities, but we also bring our own biases and our own preconceptions, which may or may not fit within that community and also may make you miss things. So the point of this talk today is to sort of review what it means to be a healthy community, because that's not always a given. And then talk over some things about where there are going to be danger areas within a community management structure and how and why you can sort of see these things not only with your gut, but also apply analytical metrics to the equation and get some real quantitative looks at community. So defining community help, I want to make sure that we have this down pat before we move any further. A healthy community is not the same thing as a successful community project. So the classic example that I give is Mozilla and Firefox. Now keep in mind, what I'm about to tell you at this point is a work of fiction. Please don't walk out of this room and say, oh my god, Firefox is burning. Let's just use this as a hypothetical. Firefox, as we all know, is a very successful open source browser. And it's really been a great internet platform for many, many years. And looking at it from the outside, you would be fair to conclude that it is a healthy open source project, because it has thousands of downloads per day. It's widely distributed. And it looks like it's doing great. But is it healthy? Because you may not know, and this is the part that's fiction, let's make sure, you may not know there might be a huge infighting going on within the Firefox community. There might be some kind of trouble. They may have a process issue that things are just this close to breaking down. Or there might be a huge fight going on about codes of conduct or anything. You don't know. Just because the product is successful, what's being put out is good and stable, and there seem to be a lot of people using it, does not necessarily define the health of that community. So let's move into out of fiction into reality. So the key areas of community health are going to be around four different areas, and they're going to all be defined by different sets of rules. So the first area, and these are all coming from a project chaos, which is a project within the Linux Foundation. I happen to be a member of the board of that project. And its goal is to define common rules of the road and really set out to figure out what can be quantified about community management. Because at first glance, you look at community manager like, how are you going to measure anything in there? Because every community is different. But you can actually apply universal sets of criteria and measurable things to a community. One of them is going to be the growth, maturity, and decline model. You can look at a community and say, is this community growing? Is it sort of stable? Or is it in decline? Notice I didn't say crisis. Crisis and declination are not necessarily the same thing. They can be, but a community can also be in decline for natural reasons. So a good way of explaining that would be like in the Apache Foundation, Apache projects can be retired and they will go into the attic. That would be a sure sign of decline, but that's not necessarily that something blew up or went horribly wrong. It's just the planned end of life for that project. Another area is around diversity and inclusion because this is a very critical area to any community. And there are metrics that you can ascertain about that. And we're going to review some of these as we continue the presentation. Risk is another factor. I want to be very careful here about risk because there's a little negative connotation about risk. There are some people in the free and open source software communities who define risk as something to do with the license. Specifically, the one that I hear a lot is, oh, they're using a copy left license, like the GPL or the LGPL, and that is risky because that's not as stable as something like an open source license like Apache, for instance. That's not the kind of risk that I'm talking about. I'm actually talking about the risk that's involved with projects that are perhaps mission critical, like the open SSL project a few years back was maintained by just one developer. And it was kind of critical because if that developer were to stop working on open SSL, there are so many other projects that are dependent on that that it would be a critical breakdown. One way we assign a value of risk in this scenario is it's commonly known as the bus factor. So if people in your project were hit by a bus, how many would it take to be hit to actually bring your project to a grinding halt? For the less violent among us, the other version of that is the lottery factor. How many people in your project can win the lottery and basically go off and live on an island somewhere and your project can still keep going? So the lower that number is, the more problems you have. If it just takes one person to leave and your project grinds to a halt, you have a very high risk factor. If you have more than 10, that's pretty good because it's pretty unlikely that 10 people are going to win the lottery at the same time. Are we doing questions now? I guess we are. Let's go. Let's go. Bring the question. If you have a bus factor. Yes. Yeah, I mean, so it could be argued, although I would strongly disagree, but you could argue that the Linux kernel has a bus factor of one. If Venus Torbolts gets hit by a bus and there have been actual articles about this, what would happen to the Linux community? You and I both know that it would probably go on. He has enough maintainers that that would go. 10 years ago, would that have been true? Maybe not, but it can be. So having a bus factor of one is not an automatic, like huge alarm, but it's definitely something to pay attention to. And I think 10 or 15 years ago, the Linux kernel did pay attention to that. And I think that's when we saw sort of spreading out of his responsibilities. But yeah, you're right. Okay. Other things that Mark, so we talked about some of those, the growth model, risk, diversity, inclusion, advocacy is another part of defining how a project works. Are you looking for users in your community? Are you looking for developers in your community? And how you approach that means you're gonna have to apply a certain different set of metrics. And then again, your output. I'm not a big believer of downloads as a metric. I actually think that they're kind of bad. I used to think they were great, but somebody on my team convinced me otherwise a few years ago. So, but you may actually believe that downloads are a critical part of your community's health. Okay, if that's what you're gonna buy into, then stick with that and find a really solid, consistent way of measuring that. As I said, and this kind of gets into your question. I already mentioned that you can have a user community or you can have a contributor community. I used to work on the Overt project, which is a virtualization management platform. It is very much a user-oriented community because the project itself used to be proprietary code. It's very large, it's very cumbersome. It's not easy for people. The learning curve to contribute to Overt is very steep because of those things I just mentioned. So, they're more interested in building a user community, but other communities might be looking for more developers and people that contribute in that way. Is your community brand new? You're gonna have a totally different set of goals. Or is it mature? And how do you keep it stable and keep it out of that decline part of the cycle? Again, you have different goals. Is your community organization, is it very flat? So, everybody has a piece of the pie sort of thing and it's very communal and progressive or is it hierarchical like the Linux kernel, where you have somebody at the top and it's very stepped down. Then you're gonna have a different governance model and you have different ways of getting inclusion and contributions and whatnot. So, you have to kind of keep this in mind when you're talking about community health. So, now let's talk about when things can go wrong. The danger part, so to speak. So, when I'm traveling and I work out of my home, a lot of us at Red Hat work remotely, something like 25% of us work out of our homes instead of an office. So, when I'm on the road, I actually get to see my colleagues face to face. And one of the things that we always like to do is go find places to eat and maybe drink, but that's another story. But we're gonna go out and have social time together because this is one of the few times of the year that we can have socialization. So, in that vein, I decided I'd try to use the going out to eat problem as an example of different areas of danger. It also might be that I'm a little hungry right now, but we'll go from there. So, here's the first problem that you have whenever you try to get anybody together. Where are you gonna go? This guy wants Chinese, this lady over here wants Italian, so forth and so on. You gotta pick a place. That's probably the hardest thing. What kind of food do you wanna go eat? Where do you wanna go? Is it too far to walk? Do you have to get an Uber or a Lyft to get there? All these different things. I hate this part of it. I just want something to get into my mouth and into my belly. That's all, okay? But people put a lot of buy into this, okay? So, picking the place. What that means in community speak is how do you communicate and get a community together? This is a danger point for a lot of communities because a lot of communities now are asynchronous. Very rarely do you find a software development project that is in the same location or even in the same time zone. This is something that my team is actually very familiar with because we had people on our team and none of us, I think, no, none of us now, on our team work in an office at Red Hat. I think they're all remote. Oh wait, no, there's one. Yeah, Misk? Oh, thank you. Two, yeah, so we got two people out of 30. Misk is officially remote. Is he remote? Yeah, but he shows up at the office. He likes a free coffee. It's all good. By point being, out of 30 people, none of us work in a central location. And we're across, we have people in Asia, we have people in North America, we have people in Europe, we've had people in South America. We're spread across the globe. We have massive time zone differences that we have to deal with. This is a critical piece of any community with any success and you have to keep this in mind. How are you going to communicate and how are you going to encourage contributions? And it's not just like how do you set up your chats or email conversations or things like that. It actually gets into contributions. And this is an area that's come up a lot recently, especially when you have corporations like, you know, Google, Red Hat, Microsoft, who are very interested and focused on open source and free software projects. And they're also interested in different models of development. So we're, you know, not everybody uses the waterfall development method anymore. Now we're seeing Agile and DevOps methodologies. But what happens when you're working with volunteers on the outside? A corporation has people working on it. And I'm not trying to badmouth any corporations, but this is the way it works. You have people working at least eight hours a day, 40 hours a week at minimum on the software. Whereas on the outside of volunteer, very rarely can match that. They're not going to be working eight hours a day, five days a week on that software project. They may have another job. They may be a student. They have other things to do. And as we move to Agile models with like sprints, now you have a problem with asynchronousity because if you do a sprint over a few days or a week, how is an outside contributor going to contribute and be a part of that sprint? It can be done if there's advanced planning and whatnot, but it makes it more difficult. And even without the Agile model, it's becoming increasingly difficult for volunteers in your community to participate. Because by the time they, you know, they'll put in a poll request. If the maintainer doesn't have time to look at it and pull it in, or they decide, well, we're not going in that direction. And then the volunteer comes back a week later and their poll request has been rejected for some reason. Or it hasn't been reviewed yet because nobody has time to review it. And it doesn't get in this version. Maybe it'll get pulled in to the next version. So this is a danger area for healthy communities. If you want outside contributors, and I'm pretty sure we all do, then you're gonna have to be very cognizant of the fact that everybody not only lives in different time zones, but they have different life schedules. They're not working in a corporate environment where they're paid to do nothing but this. Joining the conversation, how do you get people, when you go out to a restaurant, there's always somebody new who's there and there's people who's like, we're talking about things that have happened two or three or four years ago and the new person's looking at us like, what, what is it? Well, yes, hi, new person. So, this happened just yesterday. How do you get the new people involved? How do you get them into the conversation? So now we're talking about contributions. How do you increase the level of contributions? And here, this is where I'm a big believer in the concept of onboarding. I mean, for me, it's basically putting your best foot forward as my grandmother used to say. We all believe in first impressions. We're human beings. The first time somebody comes and speaks to us, we're going to make an initial snapshot of the impression of somebody. That's how we work. You know, sometimes we're right, sometimes pleasantly we're wrong, sometimes unpleasantly we're wrong too. But we make that initial first impression and that is key for any community too. And that's where I really focus on the concept of onboarding. How do you get people coming into your community? This is another big risk factor for community health. Don't just take it for granted, please don't take it for granted that just because you make the coolest software in the world that everybody's going to want to come in and jump in and work on it. You have to make it simpler for them to contribute. You have to define what the project is, how do they get the project and how do they contribute to the project? And I know that seems like I just said the sky is blue but you would be amazed at how many mature software projects there are out there who do not consistently do this. They just say, we have the best thing ever and they assume that everybody will want to jump in. And then just beyond that first impression, how do you keep them contributing? Who do they contribute to? You know, what's the process that actually contributing? What's your pull request process? Who's going to be looking at it? How long does it take for them to actually expect a response to any kind of PR? If they have a question, who do they go to? Do they go to this maintainer? And oh, by the way, who is the maintainer for this part of the project? These are things that a community will assume that everybody knows but they don't. You know it but you've been in the community a while. You have to not assume and take for granted every aspect of your community. So you have to make that as plain as day and put it on your main communication platform. Whether it's a website or stack overflow channel or whatever, whatever you're using for your main line of communication, you need to spell this out and make sure that not only do people know what your project is about, they know the easiest and most effective way to contribute to that project. There's always going to be somebody who doesn't like the food you're eating or they're like some food that you think is bizarre. I have a colleague that hates peanut butter. I don't understand, that's her thing. I don't know, I love peanut butter but whatever. You know, I try not to judge. I just bring it up in random talks for humor's sake. But the point of this is, you're always going to be working with people who are different. They have different values. So bringing different values, different skill sets to the table. And this is another danger point, okay? And it's kind of weird because you say, wait, diversity is a danger? Well, no, it's not. Diversity is the goal. Ignoring diversity or not paying attention to what it really means is the danger part, okay? People are going to always have different ideas. We're all locked up inside our skulls here. We have different life experiences. We have different formal education experiences. We have different informal education and training experiences. We have different cultures. And so ignoring diversity is probably one of the worst things you can do. And I'm not even really, I mean, yes, I believe it from a moral and ethical standpoint that we should just all be free to contribute whenever. But even from a practical point of view, ignoring diversity is harmful to your community. You have to make sure that you understand that differences mean that, yes, excuse me, not everybody's going to get along. And yes, you are going to have to try to accommodate different values and different ways of doing things. You can't be the person to say, well, we've always done it this way. That's one of my favorite lines ever. If anybody ever says that to me, I always laugh at them. We've always done it this way. We never really want to try something new. Really? Is that how you grow? Is that how you get better? I don't really think so. So you have to be aware of the practical side of diversity that differences not only mean, yeah, you're great and you're multicultural and you're multi-gender and that's all well and good. But it also means that you're going to have to be able to work with different ideas and not make your software project static as far as how change is approached. Who's running this joint? Sometimes you look at your food and you're like, I want to really compliment the chef. Or sometimes you look at your food and say, I want to call the health inspector. That's okay, that's valid. So who's running the project? A lot of times and especially in this environment, let's face it, I work for Red Hat. So corporations run a lot of projects I'm familiar with. We run a ton of projects on our own and I think we do an okay job. Google runs Kubernetes, Docker runs Docker. I mean, there are people who don't work for those companies that are working on those projects but who's managing them? Or is it completely out in the open? Is it all volunteer? You know, is it something like, again, Firefox? Which is, by the way, just a reminder, doing quite well, thank you. But you know, that's run by the Mozilla Foundation. You know, how a company, or I'm sorry, how a community is organized is critical, okay? As a corporation, and I've already talked about the asynchronicity problem, but you know, if you're a corporation that's running an open source or free software project, you have to be mindful of how you govern. You have to be willing to accept that outside contributions may mean that your project may take off in a direction you didn't plan. This is why I'm not really a big believer in development practices and licensing practices like open core licensing. Open core licensing is a huge danger to free and open source software communities because when people start talking about changing over to that, what they really mean is that one single entity in the community is trying to hold and maintain power. And they're not really interested in community contributions anymore. Now for us, I'm sure none of us are thinking about doing that, so that's not really gonna be a problem directly, but it is something to be mindful of. You know, who's governing this project? And more importantly, what's the process to get into that governance? If somebody's a contributor to your project and they've been there a long time, how is it that they will be promoted? What's the process to becoming a maintainer for your project? Do you have a formal process in place or do you just say after a while, this person's really good, we should make them a maintainer? Are you consistent with that? If you are, great. If you're not, maybe you should think about writing it down and coming up with policies. What makes somebody a potential candidate for being a maintainer? What makes somebody a potential candidate for being on your board of directors? You know, a lot of mature projects like Fedora have, you know, and Eclipse, they have a very rigid and formal election system. And I'm not telling you if you've got a small software project to do that, but you do wanna have things in place to make it consistent as far as how people are promoted within your project. Because let's face it, you know, people, if they're passionate about something, they're gonna wanna like do more, and they wanna get more involved. And you, as a project manager or community leader, need to make sure that the path to that, you know, getting more involved is clear. And again, so I gotta get on a little bit ahead of myself, the leadership path, that's the key to who's running this joint. Just forgot to advance the slide. Picking up the check, that's always fun. So usually when we go out with colleagues, the rule is whoever's the most senior picks up the check. Mostly because it's just one, you know, let them fill out the expense report. But when you're with your friends, it's a different story because it's basically like, okay, we gotta divide this up and pay for it and everything like that, it becomes a real problem. And to your community, this gets into corporate participation again, but not from a leadership governance model. Now we're talking about sponsorship. Okay, does the sponsorship and does the governance from a corporate involvement mean that you are going to have a potential roadblock for your community? Time and time again, I've had people say about a project within the Red Hat ecosystem, thank you, that I don't wanna participate in this because Red Hat's running it and I have nothing against Red Hat, but why are they gonna listen to me? I don't work for Red Hat. Why are they going to take value of my contribution? If I hear that, the less mature Brian would say, are you kidding me? You're just looking for an excuse. The more mature Brian would possibly go back and look at my community and say, do we have a perception problem here? Are there things we need to change within our community to make it easier and more transparent for people? So they understand that their contributions are valued. So beyond leadership and moving up the chain, you have to, on an individual basis, make sure that everybody understands, no matter who's running it, the corporation or foundation or just a bunch of volunteers, everybody's contribution is valued. And you do that by measuring things like when a contribution comes in, how long does it take to get that pull request done? And if there's a big difference between how long does it take to get the pull request from a corporate employee pulled and merged versus a non-corporate employee, you may have a problem. So make sure that that is not a barrier to your community, otherwise you're gonna find yourself basically running a paper tiger of a community where it's just people who work for you. So in the red hat? Yeah. Which contribution is more? Everybody. Oh yes, I'm sorry. So the question is, in the red hat development model, which contribution is more valued? Is it the outside contributor or the corporate contributor? I get the question right. So officially, both are equal. Unofficially, I'd say both are equal, but there are gaps in how that's executed because not every project within red hat is consistent with how they do that. I would love to be able to stand here and tell you every project is consistently taking outside and inside contributions equally. But I also know that that's not true for every project because even though we firmly believe in open source and we're not just talking about it, we're doing it, but I will argue sometimes that some projects are doing it better than others. And I've had this talk within, a version of this talk within my own company. They do have equal access. Yeah, we don't do, so our development model is all of our code is outside. You know, yes. So he's asking, do external contributors have access to the code? Absolutely, 100%. Code is not, there's very little code development going on in what we call the upstream. There's no code in the upstream that is inside the company that somebody can't get to. And even on the commercial side, which we call downstream, it's still open source. A lot of that you can get to too. The only thing we sort of keep private is our pull requests that are coming on the commercial version of the product that are coming from customers because customers don't want that advertised because they want a feature in there that it's not public. That's more consideration. Yeah, but we do everything in the upstream first, and that's where a majority of the development lives. So, yes. Yeah, I was gonna say, sometimes it depends. So, like I think about projects, and I'm a part of it, at least you're so thrilled when somebody from outside the company is gonna be saying, I mean, it's like super excited when you get a new outside contributor. Okay. Sometimes I think if a project, if the contributions don't necessarily reflect what maybe red hat customers are looking for, or the strategic vision of where they're hoping the projects go, sometimes it's more likely for somebody who's insight to be able to be aware of that and contribute in that way. So, it may depend. You might get a different reaction if it's kind of head of the business. Okay, so I've talked about some of the critical danger areas. How do we make this better? So, I'm down to five minutes, so I wanna make sure of this. The number one thing that you can do, this isn't gonna solve all your problems, but oh my goodness, is it gonna help? Transparency. If nothing else you get out of this talk today, get this. Make everything, all your process as transparent as you possibly can. Because even if it's wrong, even if your process is broken, if you have it out in the open, you've taken a really big step to getting it fixed because everybody can see it. And yeah, I know, that can be hard. Nobody likes to put out a broken process or a broken piece of code out into the open, but you should because it gives people a chance to contribute and help fix your process. Because if it's been broken for a while, maybe you as a community member or leader don't know how to fix it. It's okay. I don't know everything about community management. I learn stuff from my colleagues every day. Okay, and by making your decisions and your processes as transparent as your open source code, you've got a big, big way towards improving your lives and making this better. Onboarding, again, I can't emphasize this enough. Make sure that at least you have three concepts covered for getting people into your project. What is the project? How do you use it? And how do you get it? Okay, those three things should be very well explained in your front page of your website or whatever your main communication line is. Okay, you get those three things down, you've made your community a lot better just by doing that. Review. Mention this before I'll mention this again. I seem to be repeating myself today. Oh, well. Don't just assume that the way you've been doing things for X amount of time is the way thou shalt do everything. Look at your project's processes, not just the code. Look at the processes. Look at it once a year, or maybe more often if you have the time and the energy, but at least once a year, look at your processes and see if there are any problems. Okay? Do you still have a diversity problem? Do you still have a problem with people coming in from the outside? I tried this, didn't seem to work. How do I make this better? Okay, you don't want to just keep doing things the same way. I'm not talking about radically changing your governance model or your development model overnight, but I am encouraging people to look at your process and see where it can be improved and tweet as time goes on. A regular review process is key to making that work. And with that, I believe I am finished with this part. And now I'm ready for more questions from you guys if you have any. Yes? I'm curious, you talked a little bit about kind of a risk factor of one. Do you feel like if there's a project that has sort of a single person take out is a problem, would you be more inclined to encourage them to develop successors for that person or to distribute the kind of responsibility in account? So the question is if there is a risk factor of one or a low risk or high risk factor, low number, would I encourage building successors in or distributing the responsibilities? Was that, okay, making sure. This is a personal bias because I'm a father of three. I'm gonna say share. I was an only child. I didn't understand siblings at all. When my second daughter was born, I was like, why are they arguing about the air they're breathing? Because they're in the backseat of the car and they're arguing, she's breathing next to me. What is going on? I was an only child. I didn't have to share my toys. It was great. Some would say there's probably a lot of that still going on with me, but that's a whole other thing. But anyway, I digress. I would encourage distribution because you not only take care of the risk factor, but you also sort of, you start to automatically build in an upgrade path for people. You can still do that with a successor model, but sometimes they might be put on standby. I kind of prefer real time sharing so that things are distributed and your risk factor goes down and you've given people more of a way to be promoted. I don't really like, you know, so yeah, that's my take on that. So other questions. Yes, sir. I wanted to ask if you have a community project which has many contributors coming from corporate, say the radar, for example, which has many developers paid by Red Hatch, then how do you encourage people from the outside, the volunteers, who are not paid for doing the work, how do you encourage them to do the work which other people are paid for and they don't know? Okay, so the question is, if you have a project with a lot of corporate contributors, how do we encourage people who are outside volunteers to come in and contribute? That's, oh, that's like a whole other talk, man. So no, it's cool. So there are a lot of approaches and people are gonna use different approaches. I mean, making, I think the core ones are going to, as I said earlier, make sure that all contributions from the outside are valued. As my colleague Rebecca said, we do get pretty excited when we have a project that's got a problem with outside contributors and we start getting outside contributors and we tend to make a big deal about that and praise those people and try to encourage them to come in. So making sure that all contributions are valued and it may seem silly, but there are things like, so we talk about things like swag that you get at these conferences and that may seem very superficial, but it actually is a part of, it helps people feel a part of something. They're belonging. If I'm a contributor, maybe you give them a special t-shirt or some form of recognition and a physical thing. I know when I worked on the Overt project, we had like t-shirts that only contributors would get. And so that made, that kind of increases that sense of belonging and as superficial as that sounds, it actually does a lot of work. Having events is another thing. It's not, you know, for me having an event is, yeah, we're spreading the gospel of whatever software project we're working on, but if we have an event where people can come in and be a part of that project, like have your hackathons, have your meetups, have your labs and bigger events like this. Make an effort to bring people physically together. Those three things right off the top of my head would be ways of increasing the outside contributors. There are other things, and as I said, that's a whole other talk, but yeah, that's the big three I would take. Any other questions? You've been very, very kind and patient. Thank you very much and have a great rest of the day.