 So, I am in this role that's called industry analyst. What we do is basically research on industry trends, talking to lots of different companies, lots of different community members, developers, users, and trying to build that into what's going on out there in the market. Turn that into a set of best practices and things like pitfalls that you want to avoid. This is a huge pitfall that I lived through myself when I was working on an open source community called Gentoo Linux in the kind of early 2000s era. But a lot of these lessons are timeless. So, I gave this talk once about 10 years ago. Since then, there's a whole lot of people who have started working in open source for the first time, or who have experienced maybe bullying or incivility, or possibly even something you might call assholes in your workplace for the first time, and you're trying to figure out how to deal with it, or you're trying to empower others you work with on how to deal with it. Or you're seeing it in your community, and you're wondering, what do I do about this either as an individual to cope or as a community influencer and leader on how do you make it better? But step one is going to be, does it even matter? What is the impact? So you're going to hear the word, assholes, a number of times in this talk if that is going to bother you, then I'm going to just have to ask you to deal with that for a moment because I think it is really important to use strong words when things have such a strong impact on us and not to downplay them into, oh, people are being slightly off-putting, for example, which is completely understating the impact. So a lot of the way I think about successful community, successful software adoption is I trained as a biochemist back in the day, and as a biochemist you have these things called enzymatic reactions and catalysis. We're not going to have time to go into all the details of that, but there's a lot of commonalities between that and community growth when you think about something that's called the barrier to entry. How hard is it for a user who wants to join your community or wants to take that next step to get from where they are to where they want to get to? And as you roll, as a member of that community, how do you make that barrier as low as possible? And then on the way out, sometimes people are leaving your communities. You'd want that to be for a good reason. You don't want to be chasing people out of your communities because they're so unwilling to deal with the kinds of pain they have to put up with every day, whether that's microaggressions building up or whether that's a lot of massive behavior and people who are just kind of looking the other way at code of conduct violations and all those sorts of things. So really it's all about that barrier to entry. How do you make it welcoming for people to want to come in because they've heard about your community and they think, wow, that's an amazing place. I hear nothing but great things about being part of that community. And how do you avoid chasing them away once they're there by getting these surprises where they run into and they say, oh, I can't put up with that? I mean, it's really critical to the success of your project, your community, or maybe even your company. Because it's like this virtuous circle that you start building. You've got contributors turning into results, right? They produce something, but they also produce a community working together. And that is done in the open, in an open source software context. So the world sees it happening. The world sees the communication, whether that's in chat, whether that's in forums, whether that's in GitHub issues, whatever else it might be. Everybody in the world sees what's happening there. And they make their judgments in a way that you can't control. Whatever conversations are happening, wherever they're happening, people who are thinking about joining your project, maybe they're reporting their first issue, maybe they're thinking about contributing their first code. They will come across some random post on the internet googling for things. And whatever that post is is going to be their first impression of your community. You want that to be a good one. Otherwise, instead of this virtuous circle, you end up in more of a vicious cycle of downhill spirals where you can actually start attracting the people you don't want to have be part of your community because they say, oh, this is a great place for me to be a total jerk. Like I can just say whatever I want here and nobody's going to care. It's fantastic. And there are communities you can think of like that, guaranteed. Everybody in this room could probably think of one. If you can't, let's come talk afterwards and I will share some with you privately. So your ability to get results really does depend on your community. It's not about one person, no matter how amazing that one person might be. It's always about the community working together. And they need to feel happy. They need to feel a sense of ownership in what they're building. They need to feel a sense of accomplishment. In all of these cases, if you end up allowing this assholeish behavior to happen, you're chasing out those people. They don't feel ownership. They don't feel valued. They feel violated. So what does a great community look like? This is a Gaussian distribution or a normal distribution I made in GNUplot. Good old school graphing tool. And it's completely made up, but a lot of things do resemble these Gaussian distributions in practice. And just like that, members of every community might resemble a Gaussian distribution, where most of us are in the middle. All the combination of random variables makes our behavior what it is every day. It contributes into that Gaussian distribution of normal behavior. Relatively good. It's not amazing. It's not terrible. But then on the bottom end, you've got these outliers at the bottom of the curve. And what we're going to be talking about today is how these outliers have an outsized impact on everything you're doing. There are, though, great people at the other end. This talk isn't about those people, but I do want to say they exist. They're almost angelic in nature. They brighten up everybody's day every time they interact. One of the reasons that I started working on Gentoo 20 years ago is because of somebody exactly like that, who was just so welcoming and got me so engaged and so happy about what I was doing every day, feeling like even these tiny little differences mattered. And so the question here is, if you've got a roughly symmetric distribution of people, most of them in the middle, some on either end, does it balance out? Does the good balance out the bad? Or does one outweigh the other? And so we'll come back to that later. First, I want to show you a few case studies. Examples of community size over time and tying that into some specific events that happened in those communities. So this one, we'll take a look at Gentoo. This is the one that got me started very passionate about this because I was personally involved seeing these behaviors happening every day, seeing the impact they had on people, seeing people leaving the project altogether in a way where they could point very specific events and people that caused them to leave. As soon as you get to that point, you know, you've got a major problem, right? Because it'll start quietly. People just sort of vanish. They'll not really mention it. But then over time, you start to notice patterns. And those patterns are going to tell you problems. So in the case of Gentoo, I'll show you a few different events that happened in late 2004. Ubuntu launched, right? So new desktop Linux distribution. The thought was, well, will that be the thing that causes contributor size to go down? And so you're always trying to, there's no causative relationship we can show in these things. There's only correlation. And so we're trying to build up correlation over time to say it's anecdote, the plural of anecdotes. And so a bunch of launches, shortly after that, we had three specific contributors to our project, core developers. We started getting a lot of specific complaints over time from multiple different people, different events, different communication. Started to become a pattern. And then shortly after that, we removed those developers. So what we're looking at here is a pattern that we can see which events seemed like they had the biggest influence on things that happened after that. And you might expect that if Ubuntu were really the thing, Ubuntu didn't stop growing in popularity. Nothing changed there that would change the later trend of events. So if that were the cause, you expect that curve to top out and keep going downhill rather than to see it suddenly flatten out in plateau again afterwards, which we saw happening after we removed some of these toxic developers from the community. And you can also see the long lasting time trend here. It took more than five years, maybe seven years after that for things to begin picking up again, because it sticks in your community. It is, in fact, contagious. Like there are academic studies you can go look up that will show you how contagious rude behavior is, whether you're getting that from collaborators, coworkers, or customers. You will definitely, you will turn that right back around and apply it to the next person you run into unless you're very cognizant of that. Here's another case study. It's G-Lib C. Everybody here is probably somewhat familiar with that, the Core C Library. And we had two pretty interesting events happen here. One was that they switched to Git. So they moved to decentralized version of Control, which, of course, opened up opportunities for people to get authorship in the commits, even if it was still being merged by a single person or a small team. And we saw a sharp increase there. We also saw another sharp increase here, which was when the lead maintainer, who was rather notorious for his behavior in the community, suddenly got a job at Goldman Sachs. Probably fit in real well. And we saw another sharp increase in the contributor community at that point. Things suddenly got more welcoming for some reason or another. And we can tie that back to events related to people who were known to be very difficult to work with. And then one third example I'll show you, and then we'll get back into talking about the whys and the hows and the whats. This is NetBSD. NetBSD had a core developer who is now the founder of OpenBSD, another person who has had his fair share of negative interactions over time, been challenging to work with. And so he, back in 94, was asked to resign from this project, shortly afterwards, forked it into a different one, OpenBSD. And at that point, we saw suddenly after, it's a little bit harder to see at this Zoom level, but it's very flat for a while. And then suddenly, when this person is gone, contributors go way up. All right, so these people are, in some cases, holding back the growth of your community. And in other cases, actually slowing it down and turning it into a decline when, by all rights, you're doing everything correctly around the software, around the product, around the project, but these community members, even very, very small members of them, can hold you back. So I think it's really important, though, to be clear on what isn't abusive behavior, because it's not necessarily about everybody just agreeing with each other all day and saying, like, oh, great idea. Like, that's a good one, even if it sucks. We have to be very clear that we produce great open-source software by having great, vigorous, energetic debates about the best way to create. So conflict is good. Conflict is not bad for projects. Conflict produces better results than a lack of conflict. And in fact, there are companies that will train people in their corporate training on how to have a good argument about things, because it's hard. You have to separate the content of your disagreement from the people you're having it with. And it's very easy to cross that line of that's a really bad implementation, or that is a bad approach with you are a bad and terrible developer. You are not good at documentation. You are not good at marketing. Separating those two is what gives you the ability to have a real debate about the work, not about the people. And so if we look at the other side of this, what is an asshole? And we can look at a few points. These are backed up by all kinds of great research, which is the reason that I got very passionate about putting this talk together and giving this talk, because it's not just me out there saying things, making things up thought-leading. It's real academic research done by people who are experts in things like organizational psychology, workplace behavior, who are pulling this together. And I've got a bunch of resources that I'll share with you at the end of it if you want to go learn more and share more about that. So really, it's all in the eye of the beholder. That's the key. You have to think, do I feel abused? Do I feel oppressed afterwards? And that tells you. It's not, I can't decide if I'm being the asshole only you can, as you're hearing me, you're interacting with me, and you say, wow, that guy, he's a total jerk. I don't want to be around him. I don't get to make that decision. It's in the eye of the beholder. And over time, it's about looking for patterns, just like anything else, right? You're looking for patterns so you can start to do some tracing, go find the root cause of what's causing all these different issues. Everybody has a bad day sometimes. The question is, are there people for whom every day is a bad day and everybody they talk to is a bad interaction all the time? That's what you're trying to look for. Because sometimes I make mistakes. I've made a lot of mistakes in my life. But people point them out to me. I learn from them. I get better, I move on. In some cases, you've got the assholes who are completely convinced they are right and that is the right way to do things. But in another case, it is, in fact, possible to give them a strong jolt and get them to change by realizing the consequences of their actions. But first, you have to be able to find those patterns, show that evidence to people who are causing those issues so that they can see that and think, wow, that's terrible. I was just reading an article by Robert Sutton who's one of the researchers that's done a lot of work in this area the other day. And he had an example of a bunch of vice presidents in a room having a meeting, you know, how they gathered all waving their hands around and stuff. Some men, some women. And the CEO came out of that meeting and two of these women, vice presidents, walked up to him and said, you interrupted both of us six times over the course of this meeting and you interrupted the male VPs zero times over the course of this meeting. And those kinds of things, you know, he was able to fortunately realize by having it pointed out to him that he's doing something wrong and he needs to fix it, and he did. But you have to have that pointed out to you because a lot of times you're working in a vacuum of knowledge. You don't realize what's going on. And so we talked about the good and the bad, this Gaussian distribution of people's behavior in a community. And so I'm going to do a brief quiz here and then I'll share the answer with you. How many good interactions does it take to balance out one bad interaction? This is backed by research. There is a number here. And I'm going to ask you all a few different numbers. Hold your hands up if you think it's roughly close to right. How about one to one? How about two to one? Five to one? Ten to one? One hundred to one? One thousand to one? All right, we've reached the peak of that distribution. We found the outliers. So anywhere between about two and about hundred is where most of the rim was. So I'll tell you you're correct. We've crowdsourced the correct answer. It's in that range. Negative interactions are five times worse than positive ones. So you have to have five great interactions after a terrible one to balance that out. And that is just on an individual basis. When you think about things in the context of open discussions, open communities, those people might not have the five to balance out the one. They just see that one negative one and they walk away and they think that's a terrible community. Like I saw one negative and two positive. That's not a good place to be. Why would I join that? Commonness also affects the diversity of your projects. Don't take those too strongly in terms of gender stereotypes, but there are patterns of behavior that are more common for men versus women, right? Probably a byproduct of way too much testosterone is that men tend to fight in the event of a conflict. There's some research by Pearson and Porath. Great book. I highly recommend it. They tend to engage more often in a vigorous debate whereas women tend to do the smarter thing and say I'm getting the hell out of dodge. Why am I here? I'm not going to waste my time in this negative place. I've got better energy and better things I could be doing with this. But the targets also, instead of only blaming those who are treating them badly, they blame the leadership too, right? Because it's the fault of the culture that's being created in this community, whether that community is open source or whether it's your own company. It's not just individual and one interactions. And this turns back into that vicious cycle that we were talking about early on, right? They blame the leadership. They blame the community as a whole. The community gets a reputation. Everybody who's seen these interactions happening starts talking about them, right? Because the open source community is a small world, especially once you start refining that more closely, more closely, right? How about the open source Linux distribution community? Like everybody knows everybody or the open source database community, right? Like these are small worlds you get in and if you build that reputation, everybody in that entire ecosystem knows about it and is making their own decisions about not only being part of your community, but like am I even willing to use software being built by that community, right? Like there's like ethical implications of are you willing to use things that are produced in ways you despise? There's a really fun calculation that you can do on this and there's in fact, again, numbers to support these things, right? That you can do, you've heard about TCO calculations, the total cost of ownership, you've heard about ROI. You can do the same thing on an organizational context. What is the total cost of having this behavior happening? There's time. Imagine this is a professional team working in an open source software community, right? So you've got now HR that's going to be getting involved in things. You've got management chains that are going to be getting involved. Every one of these people is trying to deal with this problem, right? You've got team leads. You've got might be developer relations externally. It might be human relations internally. It might be both of them. It might be your OSPO getting pulled into these things. You've got project leadership getting derailed by this externally. You've also got executive leadership middle management internally. You've got the cost of turnover and the cost of failed recruitment when you need to train new people who left as a result of being around this behavior. And you've got the cost on people who are the targets, but also people who are the witnesses. And I think in the context of open communities, the witnesses are the most important one. Now, when we think about this turnover, 50% of people who are the targets of bullying consider quitting. 12% of people who witness bullying consider quitting. So that's about one in eight right around there. So if you imagine just a circle of people having conversation might be an eight-person circle at this conference here, might be over at the coffee shop or during a break time or whatever. If that abuse happens in that group, one of those people is quitting. They're done. They're moving on with their lives. So when we think about the impacts, again, we can quantify these across lots of companies, large studies over time. You can just look at those percentages there and think about how painful that is. I'm not going to read through all of them because you can do that yourselves. So we said 50% considered quitting. 25% actually quit. It's a really, really large number. The impact is massive and it's not just purely on retention and turnover. It's also on time and distraction. You see people's performance go down. You're like, huh, you were doing great. What's the problem? How come you're suddenly producing lower quality results than you were? Well, because this jerk over here joined our team and he or she is giving me a hard time every day. And that's such a distraction for me mentally that I can't focus on producing the best work. Like I said, cascading effects make it even worse in open source communities because, one, everybody sees it happening. If you've got a community of 50 people, 250 people, 1,000 people, and they're using a shared forum, a shared mailing list, whatever it might be, if that abuse happens and nobody steps in immediately, you're setting an implicit cultural assumption that it is totally fine and okay for that to be happening. A lot of people get very nervous about like, should I step in, shouldn't I, or maybe they go do it privately because that's what you might do in a company. You might go privately and engage with that person one-to-one after the fact. But in a community, you have to do it in public immediately or people walk away thinking, I guess this is just how we work here, right? It's just okay to act like this here. We should keep doing this. And not only do they see it and get all those witness effects that we just talked about, but they see it and think, I should start behaving this way too, right? It's like a fungus. It just spreads. You start to see it and it gets worse and worse and worse. And sometimes what you got to watch out for is if you got a larger organization, you have people working in small subgroups. You got to watch every single one of those subgroups to make sure each one is healthy because it can spread within a subgroup before like a cancer and metastasizes out in the larger organization. You got to catch it early to do regular biopsies almost, right, of each one of these groups and say, Hey, is that healthy? Is that healthy? Is that healthy? Because it is hard to believe, but it's amazing just how quickly people see it happening. They flip that around, right? They walk away with a negative attitude and then they immediately vent it on the next person. It's very unfortunate. So let's look at some of the problems that happen, not just to the targets, not just to the witnesses, but also to the projects. As a direct result of accepting this kind of behavior, you are making your project worse, right? You are saying we are not going to bring the best people into this community. We're chasing them away actively. We're like setting up a no trust passing sign on the front door and saying, like, don't come in here. This isn't the place you want to be. It harms innovation because people are less willing to share their thoughts and ideas if they think they're going to get torn apart instantly. And in a more abusive community, that is the expectation that gets set. So people, if you're trying to come up with great ideas, a lot of times it's not the first one or the first three. It's like number 10 or number 15 or number 20. That's really the great one. Nobody's going to even get past number three because they're going to stick with the safe answers that they feel like they won't get torn apart for. And of course, you'll keep bringing in more people like that. So something that you need to accept to be true to make this difference is you need to think of social behavior and technical ability as two completely orthogonal axes. There is not one that balances out the other. There's not like a teeter-totter or some sort of some total score of social and technical that makes it okay. A lot of times, especially in tech communities, we think that's just the cost of doing business is that you're going to have amazing people and along with them comes terrible behavior. We've taken that way too far. We think that's completely okay today in many places. And it's not. There is no developer out there who is so amazingly productive that they outweigh the broad impacts to the rest of the entire community, the entire network that not only works with them, but that sees that work happening. You would have to be like the 10,000 to X developer, not the 10X developer for something like that. Like the real 10X developer is the one that enables the community to grow. That's your 10X developer. It's not someone who's turning out more and better code. So the way I like to think about this is, you know, a good coder has great technical ability, but a good developer has both. Like, you can't be successful in an organization if you can't communicate and collaborate effectively with others. So how do you fix this? This is an amusing picture to me because if you just sort of look at the way they're parked, like one of them parked over the line already and then the other one parked even farther over it, really just epitomizes the kinds of behavior you're trying to deal with is like things just only get worse, right? One person does and they're like, oh, that seems okay. I'll just park halfway out on the street then. That'll be fine. Then you get the next timer that pulls up and does something even crazier because it's contagious. So how do you fix it? One of the most important things you can do is what we're doing right here is getting together in person to build those relationships and build that level of trust. It's not impossible to do that virtually and remotely, but the barrier is higher. So if you do have ways to get your community together in person, I highly, highly recommend it. When I was working on Gentoo, we had the opportunity to be involved in this great Google initiative called the Google Summer of Code, which gave us an excuse as a very poorly funded community to bring all of our mentor or many of our mentors together. Many of those people were also core contributors to the community, so even as a group without any sort of travel funding, we still found ways to do that. We found ways to do regional events and meet up. Back then, there was something called Linux World Expo, right? Now there's something that's called Scale, very similar sort of Linux community event, right? In Europe, it's Fozdem. Everybody just takes the train over and somehow gets there and makes it through a weekend on very little sleep and very little money being spent, but builds that relationship. There are ways to build it remotely, but again, it takes more work and it takes a lot more intentionality to it. I'm a strong believer in fully remote work, but I think it gets a lot better if you can do an occasional in-person gathering once or twice a year. Second, you need ways to give people confidence that if they have a concern, something will happen with it. One of the worst things you can do is that hypocritical sort of behavior, like putting a motivational post around the wall in an office where you're like, oh, here is our beliefs, and then every day you see them being violated wherever you go, right? You have to have a clear suggestion box equivalent, right? A code of conduct creates this. If that code of conduct also says, here is where you go and there's almost an SLA that the team behind it has to respond and say, within 24 hours, within three days, whatever it might be, we will react to this and we will give you a clear decision on what the next steps will be, right? We're not making the final decision yet. We're just giving you updates and giving you belief that we do care and we are doing something about it. If you don't have that belief, again, it becomes this hypocritical situation and you probably walk out the door. How do you prevent it, though? Fixing it is not the position you want to be in. You want to be in a place where you can avoid these problems from happening in the first place. And culture is not like code. Code can be quickly changed. Culture cannot. So you don't want to be in that position where you've got that culture that had the problem that had to be fixed. One way you can go about preventing it is being quantitative. I always find that as a mostly former developer myself, I now write most of my code with the help of chat GPT. I am always more convinced and many people are more convinced if you can show some data, show some numbers to support the point you're making. How can you prove that this really matters? There's now a great deal of data available both in the form of academic research and also in the form of community metrics that you can very easily collect. In fact, it's only getting easier every day. We've had for a number of years now these events. There was actually a pre-event here that was called ChaosCon talking about community metrics. Great open-source software is now available from Baturgia and others to look at these things. You don't have to hack it all up by scripts yourself anymore. There's also things that I showed like OpenHub, which many people don't know exist that will track community size over time and what's going on. There's opportunities now in a way that you couldn't before to easily do things like calculate sentiment on individual comments or on issue threads. I would tend to use chat GPT for that myself because I don't want to be too much of a champion there, but it's pretty darn cool the kinds of stuff it can do with minimal information. It used to be 10 years ago. You have to go dig out a bunch of NLP libraries. You've got to figure out what the right algorithm is to do sentiment analysis. It's sketchy and doesn't really work that well in a lot of different situations, and you have to be a data scientist to understand how to apply it and when. Now you can just take a block of text and throw it some more and say, tell me how positive this is on a 1-10 score. Does it talk about certain kinds of topics or not? Pretty powerful stuff. Also a lot coming out from open-source LLMs, like those from Huggingface and others. You can keep it fully open-source here too. But be quantitative and provide expectations. I already mentioned codes of conduct a couple of times, but the best way to prevent things from happening is to set the expectations up front to communicate very clearly and frequently so people know what is okay here and what is not okay here. And then couple that with the rapid reactions when things are not okay to reinforce the reality of this. And so in conclusion, I'll say in the long run, dealing with assholes is never worth it. I've shown you lots of academic research. I've showed you examples of different communities here. And I'm going to share with you in just a minute a couple of resources in case you want to take this back to your own communities and your own companies and be the champion for great community membership there. So here are three books. I would highly recommend these ones. I'll be sharing the slide deck afterwards as well. The one in the middle is a great starting point. And then if you want to go deeper, there's a couple. The left one talks more about coping. How do you push through that sort of challenging behavior? The right one talks in more depth about the costs of it in a little bit lighter weight language. And then there's even a couple more follow-ups. These ones are primarily about coping strategies as well. So if you're in a position where you're stuck in this sort of community, these are really good ones to help you understand how can you protect yourself and insulate yourself from the negativity so that you survive so that you can maintain your morale. Thank you. I think we do have about three minutes for questions if anybody has any. We've got one hand in the back there. Thanks. So I was just wondering if you could tell whether a situation is fixable or you should just quit right away. It's a great question. And so what you need to be considering here is a lot like what you would consider if you're a people manager and you're trying to decide whether somebody's going to succeed in your team or not. Typically, the right approach is to always act sooner rather than later. The question is just what do you mean by act? Right, because the community is different than a job. It's like you can't fire somebody from a community. You have to go through pretty extensive contortions to try and keep them from being involved in any way. So really the best thing is always act as soon as possible to inform them of the problem, inform them of the impact that that problem is having and tell them exactly how their behavior needs to change to stop that problem from happening. Because as I mentioned earlier, many cases people are surprised. They didn't realize that they were doing things that were that challenging. And what you want to do is try and rescue that proportion of people who can turn into a valuable community member while also learning that if that rescue effort fails, you want to learn that quickly too. And you want to be able to ask those people to leave your community and find a place where they're a better fit. Thank you. I got a question over there too. So I mostly work on open standards and so we're like cousins to open source and within my community and there are other leaders who are nobody's sexually harassing anybody and nobody's being a direct jerk. But women and people of color consistently have bad experiences in spaces that they are leading. They had a code of conduct committee. It got disbanded because there were so many complaints against the leaders who's the guy, right? So when it's actual, sort of like it's a peer to me, I can't fire them or kick them out of my GitHub. And I know that because of that behavior, there's less women and people of color protesting overall because they go to that event and they are like, oh, that was bad. Like I'm not coming back, right? So it's that quiet leaving. Like how do you document it when it's, anyways, I'm just like it's, how do you deal with the peers who are not doing, who are hurting the open meta community that you're participating in? Yeah, it's a really tough one. One approach that I have seen work well is to create a code of conduct working group or committee who has that as a focus area because then you're able to approach them not just as a peer but as the group that has ownership for kind of stewarding the health of the community. It can work, right? There's, it's tough though, right? Like if you've already tried to share with them examples of, you know, here's what I'm seeing, right? You don't want to project into people's heads, but here's what I'm seeing. Here's the reactions that are happening as a result. Here's the impact of those reactions. You know, if you change your behavior in this way, like maybe we could decrease the churn rate of our community members, which is the other question about metrics as well, right? If you have some community metrics that you're able to collect on maybe people who showed up at your community page, people who joined and later left. You know, I used to, well, until a month ago, work in product leadership roles. And so we are always thinking about like things like cohort analysis and like 30 day retention rate, right? Who shows up once and then never shows up again? I mean, if you can bring those metrics to it and bring, you know, tools like some of this research to it, that can always help, whether it's this research or, you know, other research that might be able to point more closely at the specific kinds of problems that you're discussing. Or if you have an appeal to a higher authority, you can go to, that works too. I think we had one more question and then we'll probably have to wrap. I'll go hang out in the hallway outside a few minutes after too if anybody wants to chat more. I think you may have answered this a little bit in your first one, but I was wondering about communities where you have large contingents, whether it might be like a cultural difference, right? In the way that just certain cultures choose to communicate or it could be neuro types, it could be any of these things where it's something that you want to have that diversity, but you've got friction, you've got the perception of asshole behavior happening with one group and not the other, but you're trying to sort of balance the two. Right. Yeah, great question. I think when you set expectations for what the community should be like, part of that is also setting a cultural expectation because the community culture is different from the cultures of every single person who's part of that community. Just like if you join a new company, you might say, oh, here's the culture here. I guess we, this is how we work, right? Like there's some of that onboarding and do a community that you can also set expectations for. And say, look, your natural tendencies might be to behave you like this. In this community, we need you to be conscious that this is how we work in a slightly different way over here. Like for example, you might find people who are coming from Asian backgrounds to be a little bit more indirect. You might expect people from Israel or the Netherlands to be extremely direct and forceful and very opinionated about what is right and wrong. And you need to find a way to help them all understand that this is the engagement model we use here in this community. There's a book called The Culture Map by Aaron Meyer that is pretty good for understanding what some of those differences might be and then helping people think about how to accommodate and adapt their own behavior so that you can all work together effectively. All right, thank you, everybody. Appreciate it. Enjoy the rest of the show. Thank you.