Yes, hello everyone. Can you hear me? Welcome to WordCamp Miami 10 years. Woo! Come on, some enthusiasm. Woo! There it is. Let's wake you guys up. We're going to open up with some interpretive dancing. No, I'm just kidding. All right. I guess we'll go ahead and get started because it says 9 o'clock on my computer. All right. So hi, everyone. I'm Nicole. This is elementary, my dear coder. I focus on teaching computer science and coding concepts to pre-readers. So it's mainly ages four to seven. Is the age range that we're targeting here. So I'm Nicole. I am a front-end developer for Bolgrid. And I also do design work for them. Bolgrid's a suite of themes and plugins. And I've worked on websites for about six years now professionally. And those are my two cute Children that inspired me to do this. So how to teach coding concepts. So the best place for this age range is called hourofcode.com. It's run by code.org. People familiar with code.org. Yes, yes, awesome. So these tutorials are available in over 45 languages. And they do say it's for ages four to 104. So it's pretty inclusive. They have something for everyone. So when you come to hourofcode, this is what it looks like. And you can see here that you can sort by different age ranges. So when we click on pre-reader, we get some options here. And then the grades two through five is where it really gets A lot more fun because they have the minecraft and the Star Wars and moana and angry birds and all of these Licensed characters that children of course love. So that's something to work towards all of these pre-reader Courses will build on the skills that then would be needed to do The next level of the tutorials. So the first one we're going to talk about is codable. Codable is a self guided game that introduces children ages Five and older to programming basics and reading is not Required because it's a very intuitive UI and the game teaches you how to play it. So we're going to pull it up now. So this is what it looks like. I got to get back to the first level because I was totally playing this earlier. Which way does he need to go first? So as you can see, it really does show you exactly what to do And what to click on. So it's very easy for children to know what to do. So once we drag everything and then you hit the play button And the goal of all the levels is always the same is just to collect the stars And go through the maze. I know it may not seem like this is actually teaching coding But it's just logic. It's getting the brain used to doing sort of logic puzzles And step by step sort of instructions that's setting the foundation For what would be needed later in coding computer science. So the first sets of levels are pretty basic. They do get a little bit harder as you can see with more directions and things. Then the next area is for conditions. So you can see if we just run it, there's already code here. But it wants you to turn where the green mark is. So that's why we added this new green. And then we put that there and then the code will run. So what I would tell my son is when he would get frustrated with the level And he wasn't quite sure what to do because there's like seven, eight steps there. Like for a younger child, that's a quite... I mean I tell my kid to get dressed, brush her teeth and put your shoes on And they already forget by the third step, right? So remembering eight things at once is maybe a little bit harder for some children. So you can always hit the play button early and just see what happens. So we can drag the stuff out and say, okay, well that's what happened when you got that far. Like what do you need to do next? And really just step through it step by step if they're having problems doing too many at once. So then the next one, it teaches loops. So we have what's called this looper here that you can repeat commands. And the way that the looper levels are structured is you really do need to use it And use it correctly in order to pass the level because there's only so many boxes there. There's only so many arrows that you can put there. So if you don't use the looper, you're not going to make it through the level. So this is quite a bigger level as you can see. This would definitely be one I'd recommend stepping through a little bit more slowly. And you can see it scales pretty fast. Like they start out easy but then they get a little bit harder. I don't have the complete game unlocked because the hour of code, it gives you only about 20% of the total game. As you can see, there's a whole intermediate and advanced world that really builds up to teaching true JavaScript as your child gets older. So if they respond to the program when they're younger, this is one that, yes, they can grow with and keep using up until probably middle school or high school. There is a fee for the full course. I think it was only like $40 the last time I checked. So that's not really that bad if your child is interested in it. But I do like that you can check it out for free before paying the money. So that's codeable. So the next one we're going to talk about is called the foos, otherwise known as code spark academy. It's very visually based and they say that children of all abilities can play and learn. And this is definitely another reading not required one. So the link that's on the hour of code website for them doesn't actually work. This link works. If you put that exact url in, it will take you to the game. That link does not appear anywhere anymore on their site. So if you want to play this game, make sure you write that link down because it's like the secret code or something at this point. Like you cannot link to it anywhere else. So it's still up. It says it's going to come down January 15th. But it's still there because this is my favorite one. So I'm glad it's still here. So we just have some cute little cartoon characters. We don't need the volume. It always starts with a little cartoon to kind of set up a little story for the kids. So we have a foo that stole some donuts. So now we need to collect all the donuts. So again, you can see that it's animated showing the child what they need to do. So we drag this block up and then we click the green foo and she very happily gets her donut. And then more actions are added as the game goes. But the goal is always just to collect the little green dots or collect the donut. And you'll get stars along the way for doing so. So with this one, again, it's a paid program, but there's a good number of levels that are available for free. All of these 12 levels are free. And then once you get 30 stars, you can unlock this little free play area. When I student teach at a local elementary school and they just love the free play. Because eventually in this game, you can get these boxes and dynamite and blow stuff up and jump really high. And it's just really fun for them to make their own creations and just see, like, you can make anything. What do you want to make? And just seeing what they come up with is amazing sometimes. So again, that's a secret code. All right. And we also have code.org courses that they run for a pre-reader all the way up through university level. The pre-reader course, specifically, each one has about 13 lessons. And some of them are online and some of them are offline. So like printer, paper, scissors, type of activities for the offline stuff. So this is what the website actually looks like. And then if you click into the course A, this is kind of the overview of the courses. So you can see the unplugged activities. The triangles are videos that teach different things. And then the circles are actually lessons. So it starts out very simple. And it's just drag and drop little puzzles. Because if your kid's like my four-year-old, of course the first thing they do is touch the screen and try to drag it over. It's like, no, you need to use the mouse. So I'm trying to teach you how to use the mouse and drag the little pieces over. So then there's a lot of this kind of stuff. But then it gets a little bit harder and progresses to the arrows. And so you always want to move like this one. You just need to move the two birds together here. So we just do that. Click there. And he'll hop on over there. And that's all we need to do. And it'll actually show you the actual javascript. If you're interested, you can always click show code. Because when I teach in the class, they're like, I don't understand how this is coding. And I was like, well, you can always click in here and see what you're actually doing. This is just the foundation. So you understand in the future what you're doing. So there's a lot of different types of these things. Different themes. There's an artist one here. There's an adventure one. And there's also the branded ones. Yeah. Probably not on this one. Let me go back. Yeah. No, it's okay. This one, it's more just the arrows. Because, yeah, trying to see if there's... So you can always show it, but you can't write it. Hop along. They're all basically the same. It's just that skinny one to put on it.  Because they're all basically the same. Just hopping around the little screen trying to solve the puzzle. So some tips for success. Definitely sit with your child while they do the activities. Especially with this age range. They might get frustrated very, very quickly. And we don't want this to be frustrated.   If they're struggling, you play a level. And show them how it goes. And then maybe they'll get interested and start taking over again after a level or two. And like I said before, click the run or play button often. If they're stuck in a bigger maze, that's the best way to get them through. It's just say, okay, you've made it halfway there. You can do it, buddy. Like just get the rest of the way. So then some additional resources. These are the links that I used earlier. Codeable in the foos. The bottom two are new. There's a light bot one. And a disney one. So light bot is a cute little robot jumping around Little squares. And then the disney is more the arrow kind of games. There's also one called tinker. This one is probably a little bit more for older kids, but it's something to keep in mind as an option. And if you're going to a birthday party or something like that, I would recommend this really cute little board game called Robot Turtles. It came out of Kickstarter, but now you can get it at Target or Amazon or any of those kind of places. But it's just a board game maze. So you have the gem in the center and you have to program your little turtle to get around different obstacles and get to the center of the maze. So it's a lot like the online games, just in board game form. And it's really fun. So that's what I've got for you today. Are there any other questions? Yeah. Yep. That's this one. The foods.com slash WebGL. Oh, and this one doesn't work unless you actually type .html, because apparently that's still a thing. It doesn't work if you don't type it. All right, yeah. I like the foods quite a bit. There's a lot of extras that come with it, but it's also the most expensive one, because it's like $8 a month or something. However, if you can go to your kid's school, they offer it free for K through 12 schools. So you can get a teacher to set up a teacher account, and then you can have your child maybe play it at school for free. That's what I'm in the process of setting up right now at my son's school. I haven't finished it yet. I'm working with them to get that instituted, but they do offer it free for schools, which is awesome. So you just have to contact them and set up this little teacher dashboard. And that's a way, too, to check out more of the program, because there's, yeah, all sorts of mini games and extra levels. And the very intuitive, visually-based that one, that one, I think, was the best one. Yeah, the Angry Ritz one? My mom, because she was a teacher, they had a couple days of training for them so they could do it at school. She was like, I'm doing pretty well. I can do your house if I can do it. So she came home, and my son, I had done it from before.  You got frustrated. But then my mom was doing it again. She was, like, lost. Like, he could be, like, the person who knew more. Right. Well, this is what you do. Oh. That's great. That's awesome. Yeah, it really can be, like, a whole family learning experience. Yeah, it's really, really fun. I, for Tinker, they have Minecraft times. Yes. For the bigger kids. Yeah, you could actually mod Minecraft. Do they still give you a free server? Yeah. Okay. If you sign up for Tinker, yeah, you can get a free Minecraft server and start modding that for the older kids. So that's really fun. But Tinker is another one. It's paid, but they have some free stuff. So you just kind of have to find the line of, yeah, what's free and what's paid and what you want to spend money on. There's definitely a lot of free stuff out there. But once you find one you like, go ahead and pay for it. I wish I took our code down. But yeah. So some of these, too, I forgot to say are offline. Some of them, once you click into them, you really need like an ipad or a tablet or something else to play. But it'll tell you right here what you need. So as you can see, like I couldn't even play this one on my Computer if i wanted to. Thank you.


For more videos on people's struggles, please subscribe to our YouTube channel. The figures that the ministry of power is given, not the coal ministry, is that you have only four days of stock in the power plants and you could therefore be running from hand to mouth and India cannot buy coal at the moment because the coal prices are very high. The coal ministry or the coal India do not seem to be beginning so much. They have blamed the power plants and the power ministry saying that they had said they should be 22 days of coal stock. They should stock up before the monsoons that has not happened and therefore there is this artificial shortage because the stocks have not been created. So combination of one hand of the government not knowing what the other one was doing and the typical of this government that instead of looking after the problems in a holistic way trying to solve problems and believing that somehow the god of the market will take care of all their coordination for them, that is not happening. The power plants don't want to keep extra stock because it is also reserve stock meant also money.  Cost of storage. Buy coal you pay and therefore whatever you keep as inventory of coal is money that could be in your bank. So therefore this is something which capitalism in general and let's face it are increasingly removed away to private power production and also we have asked all the public sector undertakings including the government ones to behave like private companies. So one of the things that all companies do is to reduce inventory. This is called just-in-time production. The Japanese model. So once you do it for the power plants now you have a problem. The just-in-time production may mean that okay you don't produce for some time and you don't supply the market. Somebody else supplies who has the necessary supplies the inventory but when it comes to energy now that's not an option because you shut down, you're shutting down other industries. It is it's a cascading effect of a shortage of power is of course on the festivals as you said Dark Diwali or a Dark Dashara but also the industry also and offices also in markets this government making everybody behave as if there is a market economy which will regulate power is I think the bigger problem because power plants infrastructure does not operate in the same way as do other industries do markets don't operate when it comes to infrastructure there is there are other issues over here which I'm not going into today but basically the lack of coal now in the power plants brings out that just-in-time production models don't work in the electricity sector for obvious reasons. Secondly that if you do not plan for storage then how do you meet sudden shortfalls that you can get in supplies and sudden spikes that you get in consumption which of course the festival sees it but we are going to also see the economy constrained by lack of power electricity if we don't solve the coal problem. Your only solution still is getting the coal India and other coal plants to produce more coal but the shortfall which is all the plants which are importing coal for instance Munra which is shut down Tata's also have an ultra mega power project which they were importing coal from Indonesia there were coastal plants or other plants which were using imported coal that is the one which is going to take the main hit because we cannot get imported coal at the prices which we can then sell to the Indian consumer A, B we cannot substitute that imported coal readily with Indian coal because the power plants the boilers take a particular kind of coal then been designed for that there is a range but the Indian coal and the Indonesian coal have very different characteristic you cannot burn Indian coal readily in a Munra power plant for instance without changing major making major changes in the boiler burning systems and so on but you know central problem that we see in the Indian power sector that this is classic example of that not that you don't recognize power is essentially infrastructure electricity generation is infrastructure and it has to be planned for the long term it is not the market which can drive in the electricity sector as somebody has said electricity obeys the laws of physics it does not obey the laws of the market and that is something the Indian planners have not recognized they believe market will solve all your problems another example how markets do not solve certain problems and certainly the infrastructure problems and the electricity sector are not amenable to spot prices going up and down and therefore, fixing how much generation will come up or will not I think this is the classic example of that.


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 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.  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?  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.  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?  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.   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.