 Okay. Let's go ahead and get started. My name is Joe Brockmeyer and I am the speaker for this talk. I'm going to be talking about how you can build successful open source communities. I enjoy when people follow along on Twitter. So I'm JZB on Twitter. If you have questions, comments, concerns, whatever, feel free to post them on Twitter. Shout at me there. I work for Red Hat. I've been at Red Hat now for about three years on the open source and standards team right now. I've also been involved with the Apache Software Foundation, which knows a little bit about communities, open source communities. I've been on the cloud stack PMC. I'm now emeritus on that. Also work with the incubator PMC. How many people are familiar with the Apache incubator? I'm not seeing too many hands. Okay. Well, I'll talk a little bit about that during this presentation. I'm also a member of the Apache Software Foundation, formerly the open SUSE community manager from 2008-2010, and I am a recovering technology journalist. So not doing that anymore. And also I like books, beer, cats, and polar bears, not necessarily that order. And I'm a bit of a music fiend. If I may do one personal plug, if you check out Zonker.net, I've been working on a project. I decided I wasn't writing enough. So I've been working on a project writing about my favorite 100 albums, which has been a lot of fun, but not getting as much traffic as I want. So feel free to look at that if you want something that has almost nothing to do with technology. So let's talk about what we're going to cover today. I'm going to discuss why community over code, why community is important. Many of us are technologists, and it's not immediately evident why community is more important than code sometimes. I want to talk about defining success. A lot of people, you know, have an idea that they want community. And that's about as far as it goes. They're like, well, we need community. What does that mean to you? Because that means different things to different people. I want to talk a little bit about governance in community, why governance is important. I want to talk about infrastructure, which is important. I'll talk a little bit about marketing, and I'm not using the strict textbook definition of marketing here. I'm talking more just about promotion in general. This is an old version of these slides. So ignore the how can we help part LibreOffice helpfully crashed and restored a slightly older version of these slides. So this is actually, it looks like it retains some stuff from when I gave this talk earlier this year at Dev Comp CZ, which how many people have heard of that? It is a conference Red Hat does in the Czech Republic in Brno every year. Mostly about 60% Red Hat or 40% other. But a really good conference if you care about things like JBoss and Fedora and that kind of thing. So ignore that slide. Let's talk about what community over code means. In an open source community, sometimes how you do things is important is what you do. When you have a bunch of people who work for one company, for example, participating in a project, it's very easy to just have conversations and make decisions in the local office over lunch, which tend to exclude all the people who participate in your project that don't happen to work in that office. That's actually even true when you have a preponderance of developers in one area of the same company. You can tend to exclude people by making decisions locally. So it's important to have procedures in place sometimes that ensure that those things happen in public, even if it's slower, even if it's a little bit harder sometimes. Another thing that's really important is having a healthy community so it can roll with changes. How many folks are familiar with open source communities that have basically died when the main company involved has withdrawn its support? There are many examples of what looked like a healthy project until a company decided this isn't important to us, we're not paying people to work on it anymore, and suddenly the project basically is a ghost town because they never grew the community appropriately. Another thing I want to talk about is nobody is irreplaceable. People have heard of the bus factor, right? How many people can get hit by a bus and your project is still a viable concern? People used to really worry about the Linux kernel, for example. What happens if Linus is hit by a bus or decides that he just wakes up one day and this isn't what he wants to do anymore? You need to have a number of people who can step up, and it's just like being a manager at a company. If you don't know who is going to replace you, there's a problem because you're not going to be in that position forever. If you're a contributor in a community and you're not looking around and trying to grow a contributor to take your place or two or three, then there's a problem because eventually either life will get in the way or you'll find a new job or something, which means that you have to go do other things and there's no one to step up and replace you. Another problem that a lot of communities have is the person who is abrasive or hard to work with to put it in nice terms. A lot of communities suffer from people. Often they are great contributors technically, okay? There are a lot of people who are really, really abrasive and they're good contributors from a technical standpoint, so people are hesitant to say, you know, show them the door or correct their behavior. But what happens with those folks is I don't care how great a contributor one person is, they're not a replacement for five other people who will never get involved in your project because they don't want to deal with the abrasive person, which I have seen happen over and over and over again. Like I said, I'm a member of the Apache Software Foundation. I'm on the member and the board lists and I watch people come in and complain about different people in different communities and say, this person has driven this person and this person and this person away, you know, and sometimes it's hard because sometimes that behavior is borderline. It's not always as simple as one person just shouting things on a mailing list and calling people names. Sometimes it's somebody who always drags a conversation out longer than it needs to go or always has a technical question even about things that they're not involved in or somebody who's a little bit abrasive, but not, you know, not enough that you would call them out on it at any one instance, but it happens over and over and over again and people need to be willing to pull the plug on those folks, okay? So whenever you say, like, we have a problem with Felix or we have a problem with Alice, don't let people say, well, not but they're a great contributor. You need to set that aside. We'll do it right later. How many people have heard this in, yeah, so many scenarios? We'll do it right later. Later never comes, okay? Both technical and social decisions, when you make a technical decision, assume that it's going to be in place pretty much forever, okay? Some projects are good at revisiting decisions, but generally, especially when you're talking about technical debt, try to make the right decision the first time, not, you know, throw something in and do it right later, okay? And that also goes with governance, which I will talk about in a little bit. So there are some core principles that, you know, if you're trying to grow a healthy community, you should think about. My favorite with the Apache Software Foundation is if it didn't happen on the mailing list, it didn't happen, okay? You don't get to make decisions that affect the entire project in private and then, you know, just implement them, okay? Now, what does that mean? It doesn't mean that if you're developing something in Apache that you have to run every single patch by other people, okay? It doesn't mean that you can never commit something without having discussed it with other people. But when you're talking about architectural changes or major changes, changing the API or whatever's important to that project, you need to put it out on the mailing list for discussion, okay? You need to have an open community where you can do those things. You certainly can't have six people who work for one company having a voice conference and then coming back to the list with decisions. That, you know, really disenfranchises everybody else. You shouldn't be making decisions in IRC in real time when, you know, six people are on the East Coast in the United States and two contributors are in Australia because that's hostile to the people who can never join those conversations in real time. Mentorship. People often need guidance in a community. They need a little bit of help to learn how to do things. So it's important for people in the community. I was about to say senior people, but it doesn't necessarily have to be. One of the other communities I'm involved in is Fedora. And we have a contributor right now who's only been involved for, as far as I can tell, about 16 months. I think he's a sophomore in college and the guy is awesome. He is all over the place. He's doing things right and left. And whenever somebody new shows up to the community, he's right there like, what do you need help with? Yes, it's really tough to get this done. I know how to do it. Here, I'll show you. Like, he is the guy standing by the door showing everybody the punch bowl and is awesome. He's not one of the senior members of the community, but he's certainly a leader in just a very short time. But it's very important to provide mentorship to people. There's a, there's, I am not the most extroverted person in the world. And when I go to a party or something like that, I'm usually the person that, you know, if it's like a corporate party, I go find where the snacks are and I stand by that table. If it's a, if it's a party where people have pets, I'll be the person over in the corner talking to the cat. Okay. But if you have somebody who like, hey, hey, you know, let's go introduce this person to everybody else. That's what you really need in your community. You need somebody that when somebody shows up, they will take them by the hand and say, hey, everybody, everybody, this is Paul. They're awesome. So Paul wants to contribute. How can we help them? Okay. Earned rights are really, really important. Has anybody ever participated in a project where you've contributed for a long time and never seemed to get recognized? You know, where you've basically, you've done stuff for a while and other people have commit bits because they all work for the same company, you know, new hire comes in, hey, let's set you up with get commit. Yeah. Okay. You're good. And here's this person working for another company, maybe even a competitor who's been contributing for six months or a year, they still don't have the same rights that the person who was just hired in over here has. That's a problem. That is poisonous to communities. And it's something that people don't generally think about. A lot of times now in projects that I work with at Red Hat, we will set up a thing where even people who it's your job to commit to something, you don't necessarily get commit privileges right away. You don't necessarily walk in the door and get the keys to the project just because you work for Red Hat. There is a concept of earned rights. Okay. Another thing that's really important is quality is greater than speed. I don't think I have to do a lot of selling on that particular point. I think a lot of us know that it's better to ship things when they're ready as opposed to just as soon as possible. One thing that's really important to me as a non-coder is that all contributions are really important. And this is something that has taken open source communities well over a decade to really start coming around on, which is funny because really if you look at things like, let's just take an example, Debian. The preponderance of people involved in Debian are packages or technical folks, which to me means that they're doing a fairly decent job of attracting those people already. What they are missing is people to write documentation or do marketing or translation or some of the other things that aren't as immediately recognized as the technical quote unquote contributions. If you're trying to stand up a community or you're trying to write a community and get it working properly, you need to go out of your way to recognize contributions from people. Doesn't matter whether it's marketing, whether it's somebody who's on IRC every day answering user questions, which is really important and usually not something that developers want to do. You need to make sure that you are recognizing all those people. I've had a number of conversations in Apache communities where we've had to basically say, why isn't this person over here a committer? Why haven't they earned a voice in the project? Well, they're not a coder. They haven't contributed anything. It's like, really? Because every time somebody stands up over here and they say, I don't know how to do this, they're in IRC handholding. That takes time and it takes skill and it's not terribly rewarding, especially if the project you're trying to help doesn't recognize that as a contribution. And the last thing I want to talk about is that users matter too. Why are we doing this if the users don't matter? But there are a lot of projects when a user rolls up to the door, hey, I have this problem. Patches welcome is a hostile response. It's a friendly response when you have a developer that rolls up and says, hey, I found a bug and I think I know how to fix it. Hey, your patch is totally welcome. That's a friendly response. When you're talking to somebody who probably doesn't know the sharp end of an IDE, then you probably are going to, when you say, hey, I have this problem and you say patches are welcome, you're basically telling them pound sand. That's the nicest way I can put that, by the way. You're not giving them a friendly response. So we've talked about some of the things that are important in general, kind of more vague and soft things. But let's talk a little bit about what success looks like. Because, again, I've worked with a number of different companies and projects with inside companies and you go to them and they say, well, we want community. Great. What kind of community do you want? Who is important to you? What users matter to you? What developers matter to you? And they get this deer in the headlights look, which is basically like we want community. Isn't that clear enough? No, it's really not. You need to know what success looks like. You need to know what your project goals are. These look different for different projects. A successful and healthy Linux kernel community is drastically different than a successful and healthy LibreOffice community. The number of people who use the Linux kernel is larger, probably, than the number of people who are using LibreOffice. But they use it differently. You interact with that differently. And the number of people who can contribute to these communities differs as well. And a healthy community is very different. So what are you building and why? Some companies, for example, really don't care that much about having a core contributor community outside their company. But they care deeply about having a lot of users. And so it's, if you're building a community that you're trying to attract users, that's not the same thing as building one to attract core contributors. Another thing that's really important is making sure that your goals are actually measurable. More is generally not something that you can deliver convincingly. Okay? How about twice as many downloads in 12 months? That's something that you can deliver. Or twice as many patches in 12 months. Or three other companies contributing to your project. Those are metrics that you can actually track. Okay? If you're doing this in a position like mine, you also need to make sure that you communicate the goals often and to everybody. The reason I stress everybody is because it's really easy in a company, especially larger ones like Red Hat or Citrix or other ones, to tell the salespeople, here are your goals. And tell these people, here are your goals. And tell the PM group, here are your goals. And then tell the marketing group, here are your goals. And they don't look alike. And if you don't tell PM that part of the goal is a healthy community, then they're going to ride the developers to deliver features without any regard whatsoever for the work that it takes to work with external contributors. When I was with Citrix working on Apache Cloud Stack, for example, we had folks who, you know, would go out to customers and they would promise features in a certain timeframe. Regardless of the fact that those features needed to go through an open source project with very strict governance and with contributors from other companies that had a vested interest in the development of that project. So they would target some features that conflicted with folks from storage companies, for example. The folks from the storage companies who also have a voice in the project are trying to do thing A, and Citrix is trying to do thing B, and they don't quite mesh up. And the people in PM at Citrix wanted to just push things through regardless of what people from company B thought. That's a problem. It was a problem for the people working on Cloud Stack on the Apache side. It was a problem for the developers, and it was certainly a problem for the project. So you have to be really careful about those kind of things. There are projects that are successful accidentally, and it is really important to make sure that they are not held up as poster children. I don't want to name any projects specifically for names changed to protect the guilty and all that, or innocent, no, guilty in this case. But there are some projects that just happen to be in the right place at the right time and take off up and to the right very violently, and people say, oh, well, they must be doing everything right because look at all of the success. Not necessarily. They may just have gotten very lucky. So you need to know the difference. I want to talk a little bit about governance and community, but I'm going to pause to take a drink of water because this is my second talk of the day, and I'm starting to lose it a little bit. Talk amongst yourselves for a second. Okay, y'all are quiet out there. So governance and community. One size does not fit all. So what works for the Apache Software Foundation projects, for example, may not work for Gluster or for Fedora, for example. You need to have very clear guidelines on how things are done. This is both so that people are consistent and also because a lot of new contributors, even, I mean, I've been involved in open source now for a long time. I've been using Linux for 20 years, and for those of us who have been immersed in it for a while, the idea that you are empowered to do things in open source communities seems like it should have made its way, but it has not. People still show up to projects and they feel intimidated or they feel like they don't have permission to do things. And so it takes a while to make sure that people understand that yes, you do in fact have permission to do things. And having public guidelines on how those things are done is very important. You also need, and I alluded to this previously, you need to have clear guidelines on how someone becomes a contributor officially, so that they are applied equally across your project. How do they get core commit rights? How does somebody earn the right to just commit to master or whatever without any supervision or hand-holding? It's important to make sure that people know that. How do they do that? Also important is that your governance thinks about inclusion and diversity within your community, and make sure that you have something in your governance. I'm not going to say that every project absolutely has to have a code of conduct, but it is not a bad idea. And that code of conduct should specify, at a minimum, a level of behavior that everybody can live with. Any questions? Y'all are so quiet. I'm not sure if I'm making all of my points so well that there are no questions or people are just bored. So I'm going to assume it's the first one. A couple of very low-level governance suggestions. So everything happens on the mailing list. We've kind of already covered that. Give 72 hours for feedback. Give or take. Your community may differ, but I generally think 72 hours is long enough that if somebody sends out something to the mailing list and asks for feedback, 72 hours is long enough to be reasonable for people to have checked their mail. And I would put maybe a little asterisk next to this that says 72 business hours. Obviously, it's not cool to send something out on December 23rd and then make your change on December 27th or whatever. You need to make sure that it's a reasonable timeframe for people. Don't do it on Good Friday or something like that. I'm a strong advocate for lazy consensus. Is everybody familiar with lazy consensus? No. All right. So lazy consensus is basically the concept that send it to the mailing list. Send all the information that's needed to make a decision. If nobody squeaks, then you have consensus. So in other words, you're not trapped waiting for five people to act it and say, okay, you're setting forth the expectation that everyone is going to read the mailing list that cares. And if they have an objection, they're going to speak up. You don't get to revisit decisions three weeks later when something is already halfway implemented because you've decided now I have a question or now I have an objection that I didn't think of before. There are exceptions. Red Hat Legal, I'm sure, would like me to especially stress the legal angle. Lazy consensus does not work necessarily for things like trademark or license changes or things like that that require explicit permission from someone. So if you're in a patchy project and you want permission to use a trademark for a conference, if your company wants to run a patchy foo conference and you need to get explicit okay for that, lazy consensus doesn't work. Security things. You may need to push something out faster than 72 hours to fix a horrible security bug. So where common sense applies, the 72-hour rule can be set aside. Really important and puns sort of intended, you need to leave your hat at the door. No one likes participating in a community where one company gets special privileges. Nobody really wants to work with somebody who's clearly only vested interest in a project is whatever their employer wants. You need to be invested in the good health of the community, not just the health of your employer. And I can't stress that enough. You need to work with people you can trust that you know are going to do the best thing for the project. So any project you're participating in, nobody should come in and say, well, company foo says this or company blah says that we must do it this way. I already alluded to this a little bit, but do make decisions stick. It's both people will, some people have a habit of liking to revisit decisions given a couple of weeks. They'll bring a topic up again and hope they can get the group to change its mind. And also people, you know, people rotate and so people forget or weren't aware of decisions that were made. So one, find a way when decisions are made to record them somewhere so people know what those decisions were. Again, this is where everything happens on the mailing list, assuming you're using some sort of archiving software is very useful. But you need to have a culture where once a decision is made, you don't revisit it every two weeks. So document everything. Infrastructure. I won't spend a heck of a lot of time on this, but this is pretty obvious stuff. Every project should have mailing lists. It should have forums, maybe. I put a question mark there because a forum where no one is watching for questions is worse than one that doesn't have a forum at all. You probably need a bug tracker of some sort. You need documentation or a wiki. I like to say wikis are where information goes to die, but they can be useful for certain things. Obviously you're going to need a code repository if you're shipping code. Yes, sir. Hey. Okay. Sure. I mean, there are a number of different checklists on the Internet from different sources. Okay. Okay. Cool. Yeah. Also, I think I have this in the resources at the end, but you also want to look at Carl Fogel's work as well. Yeah. Okay. Cool. Thank you. You may want to also consider something like Trello or Kanban boards. I don't know how many folks are using those. I like them a lot because I like the visual nature as opposed to bug trackers and whatnot. A lot of projects. Now, this wasn't the case when I started doing open source stuff a long, long time ago, but a lot more projects are finding a deep need to have continuous integration and testing and infrastructure. If you are considering starting up an open source project these days, you may want to start from the idea that you're going to use CI when you're doing check-ins as opposed to, well, we'll just throw stuff together and assume that people are testing it. Then once every three months, we'll try to compile everything and then start debugging from there. I've been part of that culture too. It's not fun. Yeah. Translation tools. Depending on your project, you may want to consider whether translation tooling is necessary. Fedora and other projects, for example, make heavy use of translation. Quick shout out, since we are in fact at a conference, quick shout out to the usefulness of doing things face-to-face. They have yet to invent a technology to ship beer over TCPIP. It's a tragedy, but you're working on it. Good. Good. But there are very few things that beat buying somebody a beer in person and thanking them for their work. Meetups, lugs, daycares, maybe not daycares, but definitely getting to talk to people face-to-face. You find out, as a contributor, that people have questions you never dreamed of and you will learn a lot about the way that people use your software, a lot about the nature of your audience that you may not expect. One example, so I worked on Project Atomic with Red Hat, which is a container operating system, basically, and found out that people were using some of the technology, not because they really cared so much about running containers, but because they found the RPMOS tree stuff really good for Internet of Things devices. They wanted basically a way to push out the operating system and reboot without having to fuss with RPM updates. They just wanted to push out an update as one entire unit. We didn't see that happening, so we learned that by going to meetups and people coming up to us going, you know, we're doing this thing, and that's great. You also actually get to talk with other people who care about your technology, which, you know, depending on whether, if you're a remote worker and most of your friends, I used to live in St. Louis and most of my friends were involved in art groups and so forth, and so having a conversation about technology really didn't go very far, so I found that when I would go to a lug or some sort of meetup, it was like, holy cats, people actually, right, this is why I do this stuff. And then you can make sure you bring it back to the community. Don't hoard your information. Get into the habit of doing trip reports or whatnot. If you go to this, if you work for a company and you're at LinuxCon and it's not already a requirement, I strongly recommend that you make it a requirement when you come to one of these things to write up a trip report afterwards about what you learned, what you did while you were here, and share it with all of the people who didn't get to go to this event. Because there are a lot of people at your company, assuming you're with a company, that will not have gotten to learn anything here, and this will make the most of your company's investment and show why it's useful to send people. Yes, sir? Question on that. Yeah. You can comment on those. Okay. So at Red Hat, people do read them. I mean, when we send them out now, it's not 100%, right? I mean, it's usually, if I know there are 300 people on a mailing list, it's usually the same 20 people that will actually give me feedback on a trip report. But I guess the way to make people read it is have a culture where people are curious and want to know. So that probably doesn't really answer your question. It does, actually. Well, sure. And sending it to the right place, hey, start using the upworthy style headlines. Like, I went to LinuxCon. You won't believe what happened next. Do whatever you got to. I'll read it if people put cat pictures in there. All right. Marketing promotion. So this is a good topic, right? Again, audience and goals. This is deeply important. If you do not know your audience and you do not know your goals, you cannot market to them effectively. Okay. If you don't know what peeps want, you can't give it to them. If you don't know what they care about, you can't craft messaging that works for them. So I recommend that people come up with personas of the people that they're trying to reach and keep them updated. Okay. Come up with personas. One thing that I have seen that is also very important when you're writing those personas, pro tip, they should not all be white males. Okay. So if you give names to your personas, if you, which I recommend, make sure that they are a diverse group of people so that when your developers are looking at these personas or when your teams are looking at these personas, they are thinking about a diverse group of users. Okay. Ask yourself what they want. You do this by talking to users and not just assuming. Okay. Any questions on that? Yes. So the question is, are there less anecdotal ways to collect information than personas? Would that be a fair summary? Okay. Yeah. I mean, you can do user surveys. For example, the OpenStack Foundation does a survey every six months, which is both a blessing and a curse. It's a blessing because it's great information. It is a curse because they change the questions every six months, which means you cannot possibly use it for tracking things between OpenStack releases, which is infuriating. Not that I've run into this and it's made me annoyed or anything. But basically, yeah, you can do user surveys and you can gather statistics and so forth. And that's a good thing to do as well. Definitely. A couple other things, too. You obviously want to tailor your website to users, which means that maybe your lead developer is not the person who should write copy, or at least not the last person who should touch the copy before it goes to the website live. Have someone sit down and develop talking points and messaging for the product, for the project. Also, this is a great exercise if you are trying to get a larger audience. This is a good exercise when you can sit down with people and say, okay, what's the story for this release and worry if they do not have one? If you have a release and there is no overall theme of some sort, if you have a release and you can't produce a coherent tale with it, there's probably a problem there. Whenever you're writing about your project, the worst press release I think ever received when I was a reporter was a press release that said something to the effect of this release of software foo implements JSR, blah, blah, blah, and JSR, blah, blah, blah. I don't follow JSRs. That's basically like sending me the IETF codes or whatever for something. It's like I don't walk around knowing what the TCP IP over avian carrier number is. At least tell me what the name of the standard is, not just the number. Yeah. So show me the features and the benefits of the features. Don't tell me, for example, with Fedora we want to talk about Wayland. Users don't care about Wayland. Users care about X isn't going to crash as often. They care about fonts look prettier. They care about faster. They don't care about an obscure technology, generally speaking. Some users may care about Wayland for its own sake, but they probably already know that it's going to be in that release. So we're actually looking at making it the default in Fedora 25. So there are still some things that need to be implemented in Wayland and basically we are at that point now. I was just reading about this this morning on the plane, actually. We're at the point now where we have reached the most things are implemented, but the only way we're going to find out what's really broken is put this in front of enough users. So this is going to be the good news is we are going to make it easy to fall back to X for Fedora 25. So yeah. Well, we know how responsive Oracle is to the community, so I'm sure that will happen. Excuse me. I didn't say that. All right. And the last most effective thing is the best marketing is your tool lets me be successful at something and quickly. The tool that you install and can do something useful with in five to 10 minutes is the thing that you want. Okay. There are certain things that some users will stick with something because the end goal is so great they're willing to put up with the pain. But generally speaking, if I install something and I can't be successful with it quickly, I'm moving on to the next thing. The slide that I actually added in the plane that got dropped was and I wish I would have remembered this at the beginning but was basically all of this is academic if your project sucks. So no amount of makeup on the porcine creature is going to actually make it good, you know, if the project isn't useful. Okay. So that's step one. So if you can't be successful quickly, part of the process of marketing is going back to the developers and the rest of project and saying, folks, we got a problem that we need to fix before we can go out and tell people this is wonderful. Blogging and social media. This is always like pulling teeth but it's really important. Take the time to write about what you're doing. If you are a developer, spend just a few minutes occasionally writing about what you're doing. It doesn't have to be, you know, deathless prose or anything like that. Although I do appreciate it when developers actually find the shift key. Yeah, I'm thinking of a certain KDE developer who did blog prolifically but his blog looked like it was written by Hello Kitty. So take the time to write about what you're doing. It doesn't have to be John Irving but it does need to be out there somewhere where I can find it and follow what you're doing. If you are younger and like the videos more than the text, just sit down in front of your webcam and talk about what you're doing or create a screen cast that people can watch. For extra bonus points, really successful projects will do both. They will create screen casts that show off the technology and for old fogies like me, they will write text that goes along with it. Okay? They will reach out to both audiences. Again, this comes under the heading of people who can contribute to the project who are not technical. Find somebody to run the social media because odds are the developers on the project don't want to spend their time feeding Twitter. But it actually does help to have a active social media presence. Okay? Provide social media guidelines so people know what the voice of your project is and what to and more importantly what not to say. Okay? For example, your open source project probably should not be bashing other open source projects. That doesn't look good on anybody. Okay? For really advanced stuff, find someone to run an editorial calendar. Find somebody to do SEO on your website. Okay? Target people who are influencers in your industry. Releases. This is something that should be obvious but isn't. Start planning your release announcement early, ideally before the alpha is ready. Identify any publications that might be interested. Identify partner projects that might promote your project. So for example, Fedora and Python go together like peanut butter and chocolate. And so whenever a new version of Fedora comes out, the Python folks should be talking about all the stuff that we're doing in Python in Fedora and vice versa. We should be talking, and we do in Fedora, talk about all the stuff that we're doing with Python and the benefit to Python developers. Go big but do not just focus on releases. If your project only releases twice a year, that doesn't mean you should only be heard from twice a year. Okay? So summary and I think I'm getting close to out of time. You're never going to be done with tending to your community until they, you know, put your project in the attic. So a little bit about the Apache Software Foundation incubator since I skipped over that earlier. The incubator in Apache is a project that helps new projects before they become a top-level project and can govern themselves. The idea is that when a company or a group of people come to us and say, we would like this to be an Apache project, we say, great. Do you have this many people from different companies who can be involved? Is it going to, you know, can you put out releases? Is there enough steam behind it to actually work? And we work with companies or we work with groups until we see that yes, they can govern themselves and then we promote them to top-level project. And sometimes projects basically live out their lifespan and are no longer interesting or don't have enough people contributing. And at that point, we have a conversation about, is it time to put this in the attic? This is really important, okay? Because this gives people a chance to say, is this project done? Sometimes the project is, you know, there are open source projects that live out their life cycle and they're not that useful anymore to people. And it's time to signal to the remaining users like, hey, we're going to stop maintaining this. If you were expecting security updates, that's going to stop in September or whatever. Start making plans. Because it's just as important to let people know that something is coming to an end as that something is beginning. Successful communities change over time. Thank you. Thank you. Things have a beginning, a middle and an end. And in the middle, things may blow up. You know, look at Docker as a good example, okay? When Docker started, it was this tiny little thing that was part of a platform as a service company. And then all of a sudden they realized, hey, this is more interesting to everybody than the platform as a service that we're trying to work with, okay? And so that changed radically and continues to change. Single company projects are okay. I'm not going, there are a number of single company projects that are all right. But they're never as good as multi-company projects. Sorry about that. If you build it, that does not necessarily mean that they will come. You do actually have to go out and promote it. If you're not growing, you are dying. And the golden rule, treat people the way that you would want to be treated when you're working in a community. Any other questions? I have like four minutes for questions. Yes, sir? Yeah. Well, then you can revisit things. I mean, it's reasonable to revisit things when the world changes, right? It's just not reasonable to revisit things because either people have forgotten the original decision or because somebody didn't like the original decision. So knowing the difference between those things is really important. So does that answer your question? Yeah, yeah. So for example, you know, we should base this on this version of Java, okay? People may say, no, we don't want to base it on the newer version of Java because that's going to be painful for users. And then Oracle comes along and says, we're discontinuing the old version of Java. Time to revisit the decision, right? So yes, sir, back there. Actually, well, I think it depends partially on your audience, right? So the Linux kernel community is an example. I don't know that anybody that many people in the Linux kernel community would be terribly motivated by a leaderboard, right? However, in Fedora, we do see people who, for example, do package tagging and other things because there are badges attached. I have to admit this is really kind of terrible for me to admit, but I'm actually sort of motivated by those things. So how many people use an app called Untapped? Untapped? Yes, for beer, yep. So I'm actually a little motivated to get new badges on Untapped, and I will try beers that I wouldn't ordinarily try. Like my favorite, I know what my favorite beer is. My favorite beer is Paul and you're hip-wisin. And so if that's on tap, I'm like, that's what I want. But then I'm like, oh, wait, I'm in a new city and they have different things, and I can probably get two or three badges. I'm going to try this. So I'm actually motivated by that a little bit more than I should be. So it really, really depends on your community. And if you want something to implement that, I would recommend looking at the Fedora badge project and our unfortunately named Fed message bus, which is not actually Fedora specific. It can actually be used by other projects. But Fed message actually will watch things happen and let you collate data for that kind of thing. So I think at this point, I am actually out of time. So thanks everybody for showing up. I really appreciate it.