 So I haven't spoken in like a year since I became a dad. I also became a dad, more like five years ago, but I haven't spoken very much since then either. Yeah, so we want to talk about open source today. So I think sometimes when people get started with open source, they kind of think, oh, this is fun. I'm going to do some cool tech, and then maybe some people will come by and we'll have a good time, and we'll all just like collaborate and hold hands. And that'll be great. Fun time will be had by all. So Leia Silver calls this the open source pixie dust theory. And the problem is that the reality, the lived experience, sometimes comes away a little less ideal than the theory. Yeah, so that's what we're here to talk about. And so Dave talked for a second about a conflict between what people expect the world to look like and what it looks like in the real world. And what we want to do today is unpack it a little bit. Basically, when we talk about the feedback loop in this talk, what we're saying is in the real world, people, communities, and projects all evolve. They grow into things that are different than where they were when they started. And as they evolve, there are tensions between the people who started out, the first users, the first use cases that something was designed for, and the newer users, the newer use cases. And when you experience attention, it's very tempting to say, well, what we're going to do is we're just going to pick a winner. We're going to say the first user's win, or we're going to say this use case is out of scope. And sometimes that's a good idea. But mostly what you should try to do when you get into a situation where there appears to be a conflict between two groups of users or two use cases is try to find a way to synthesize them into one solution. And that's the way that we grow. That's the way humans grow. It's the way communities grow. It's the way basically anything that involves people grows. And that's also true about open source. And actually, the story of how Dave and I both met has some conflict in it. This is a picture of the physical room where we met for the first time. It's a place called the Grove in San Francisco. This is the room where it happened. This is the room where it happened. 20%. All right. So I went over to the Grove to meet Dave, and I met this ivory tower academic guy who worked on TC39. And so I came into this having worked on TC39 for a while. And the thing that I was working on at the time was the module system for ECMAScripts. And I had these goals of getting a static module system into a dynamic language. I thought this was going to be controversial. And I didn't know Yehuda personally, but I had this kind of image of him as this like kind of scary, you know, dynamic language, you know, ruby. I hear it's kind of weird. And he's sort of an agitator. You know, he's known for kind of like, you know, mix it up on the internet. So we both kind of went into this with some misgivings about whether we were going to be able to collaborate on our kind of respective dynamic languages, static modules, perspectives. But as you can see, the conflict between those two perspectives wasn't reconcilable. In fact, it was the beginning of a long-standing collaboration and friendship that continues to this day, and that's why we're here. So for the rest of this talk, we're going to talk about a couple of well-known tensions that exist in the open source world that people are often grappling with, and talk about some tools that we personally have used to try to help resolve the tensions that are pretty common. And basically what this slide is telling you is quite often when you encounter a conflict or a tension for the first time, people want to tell you, don't spend too much time thinking about that conflict. Don't spend too much time trying to resolve the tension. They're just irreconcilable. There's just two sides, and one side has to win. The other side has to lose. And that's a pretty good way of not actually trying to solve the problem. And in general, my opinion is when people say that they're usually wrong, you should spend some time to try to figure out if there's a way to resolve it, and we'll talk about some details. So there are a number of ways in which people working at open source for a while find themselves feeling disconnected from their community. There's the sense that you are a maintainer of your open source project, and there's the community, and they're sort of two different groups. And a common way that a lot of people experience the tension of the maintainer perspective versus the community perspective, what feels like a hard tension, is through a sensation that people describe as open source burnout. And this is a topic that if you've been paying attention to, Hacker News, which you probably shouldn't pay attention to, comes up periodically. It's a thing people comment about a lot, people tweet about it. So open source burnout is a thing people have talked about. And in particular, one of the ways that open source burnout really manifests itself in the most frustrating way is dealing with users who the first time you encounter them is they are expressing a lot of frustration. So just imagine if you worked on Webpack and you got a tweet like this. I think you would probably not be very happy, would not make your day feel brighter. A lot of the way that people say that you're supposed to handle the problem is they say you're supposed to grow a thick skin. And this is really terrible, terrible advice for two reasons. First of all, how are you supposed to magically will yourself to feel differently than you felt before? There's really no way to do that. As a person that maybe you perceive as having a thick skin, I can tell you that that is not what's going on. Second of all, most of the time when people say grow a thick skin, what they really mean is ignore the feelings of the people who are getting in your way. They are basically telling you to not think a lot about what the person who is frustrated is feeling. And in general, it's just a pain avoidance strategy that only leads to chronic pain because the pain doesn't go away for any reason. And general numbness, which is what people are feeling. So what's a better way? If the answer is not just learn to deal with a never ending barrage of negativity, what's a better way of dealing with this? One of the best people in open source that I know of who deals with this is for dealing with frustrated users is a person named Sean Larkin who happens to work on Webpack. So you may see what the plan is here. So a first reaction that a lot of people have to this kind of tweet is like, oh my god, I'm under attack. And that's definitely a thing that you could feel. That is a Unicode character. It is supposed to be. I'll act out the Unicode. So that's the first reaction a lot of people have to a situation like this. They say, oh my god, I'm under attack. And they go into very defensive mode. Instead, let's look at the thought process that a master like Sean goes through when he encounters this kind of problem. So first of all, he first feels like, oh, am I getting attacked? And he first thinks, no, it's not about me. This person is not, the problem has nothing to do with me. And in fact, not only does it have nothing to do with me, Cosmic Brain Sean realizes that it's telling. That's a CCTV feed of Sean. So Cosmic Brain Sean realizes that it tells him something about what this person is going through. What does it take for somebody to get to the point of tweeting something like this in the first place? What it tells us is that a customer of our project is experiencing pain and frustration, and they're crying out for help. And what happened, so this is a story. It's a remarkably self-contained example of this phenomenon. Instead of tweeting something angry in response, or ignoring them, or muting them, or blocking them, what Sean did is he used positive deescalating language. And a lot of the time, that's all it takes. Because a lot of the time, angry tweets are really just a cry for help. And as soon as somebody sees another human being on the other side, they realize, oh, people can start to understand what's going on between people. And so I think this is a particular example. And you might think, oh, that's probably not very common. But actually, this kind of thing is very common. Quite often, all it takes is one positive deescalating tweet to turn the whole thing around. And you're probably asking, how does Sean keep his calm? It seems hard. And the answer is not that it's easier or fun. It's not that there's a way to do it that makes it feel it feels like running in the playground. But the successes when you turn a conversation like this from the first tweet to the last tweet is really a fulfilling and rewarding thing. I think once you start to realize that you can do it, you can accomplish that, you can get people, you can deescalate situations, it starts to feel very positive to deal with a situation like this or it can. So that's a Sean example. I recently had a similar situation where someone tweeted at me that they said they felt abandoned by the Ember Core team. They like, all we care about these days is glimmer. Nobody, we don't care about them anymore. And they were pretty aggressive tweets that came out in the middle of a different conversation. It felt pretty aggressive to me. But basically following the same pattern, I said, if the user is really angry and they say they feel abandoned, that is pretty overtly a cry for help. It's pretty overtly a sense of somebody feeling helpless and powerless. And so like Sean, I didn't flip tables. I basically, he tried to learn more about what was frustrating the user and within like a few minutes, the user reached out to me privately to apologize and I was able to understand basically what was frustrating to them. And in addition to figuring out what was frustrating, I was also able to do a bunch of things pretty quickly to fix a lot of the things that were frustrating. And recently, so after that, I have now DMed with this person pretty often about various things. Is there an Ember user and it's interesting. And recently when we were DMing about a completely different topic, he said to me, I'd say that talking with you has definitely brought me back around to be more interested in Ember. And this kind of thing has happened to me over and over and over again throughout the years. And at the end of the day, turning frustrated users into fans is an amazing feeling when it happens and it happens pretty often, it's really the highlight of my week or month. So that's one aspect. That's one thing that makes people feel burned out, makes people feel like, that's one thing that makes people feel very burned out, makes people feel like there's nothing that they can do, they just feel an endless barrage of negativity. Another, the flip side of that, another aspect of it is a feeling that there's not negativity in the things that are coming, but it's an endless rush of more people needing things. So it's not, so sometimes people are super negative, you have to deal with angry users, but sometimes there's a sense of quote, unquote, open source guilt where you just feel like there's an increasing number of users forever and ever demanding your time, demanding your attention and it's no longer fun. So Michael Rogers wrote a really good blog post recently called maintainer versus community, which is to talk about this. And here's a piece of the quote that I think is probably the most relevant, which is it says, trying to tackle sustainability from a maintainer-centric view is to paddle against the flow of the river. We continue to see barriers to adoption and participation fall away, enabling a new generation of contributors to be involved as long as we can view them as part of the solution rather than the problem itself. So before unpacking that a little bit more, how about a little game theory? I wanna actually talk a little bit about some jargon that I think is useful for the next thing I wanna talk about. And that is the difference between zero-sum solutions to problems and positive-sum solutions to problems. How many people have heard of this terminology before? So like a third or half of the room. So zero-sum solutions are solutions that take a particular conflict and say the only solution to this problem is to pick one of the two sides. There's a winner and there's a loser. And obviously the zero-sum means there's a plus one and there's a minus one, right? Yeah, those together, you get zero. And in fact, that's how a lot of people think about the world. They think about the world, there's a conflict. The answer to the conflict is somebody wins, somebody loses. A lot of people think that. Our president thinks that. Sorry, I'm in Texas. I didn't say it. But I think it's normal, right? It's a normal way to find yourself thinking. Whereas a positive-sum is basically saying a lot of the times things that are apparently in conflict are not really in conflict. And you can find a solution that makes everyone really happy. It doesn't make anybody, usually neither side is 100%, but maybe it's like 0.99 plus 0.99. That's much bigger than one, right? So the idea is we wanna try to find solutions that are positive-sum that give people mostly what they want instead of insisting that somebody has to win and somebody has to lose. And the zero-sum approach to the question of maintainer versus community makes every new user feel like a conflict. There's so much inflow from new users. Every time there's a new user, the new user introduces some amount of additional work. And that work is just naturally in conflict with the maintainers who only have a limited amount of time. They have lives, they have children, families work. How can they possibly manage if there's just a new user? Every time there's a new user, there's new work. How do you deal with that? It seems like there's not a very good answer. And the solutions on the left are basically the way people try to deal with this problem from a zero-sum perspective, right? They say maybe the solution is issue templates. We'll make people fill out a lot of stuff before they can even report a bug. Or pull request templates. We're gonna make people jump through a lot of hoops because we can't actually deal with asking a lot of questions. So we'll ask everybody a bunch of questions. Maybe some of them will apply or formal ownership models, right? These are all ways that you try to deal with, you try to reduce the amount of inflow. On the flip side of that, there are positive-sum solutions which are, like Michael said, mostly about trying to find ways of, as you get new users, having some of the new users deal with some of the inflow. So in practice, the zero-sum solutions basically can't work because as Michael pointed out in his blog post, the rate of inflow as it's increasing comes from new users. So as long as your project continues to grow, which hopefully it does, any attempts to tamp down the inflow are gonna continue to fail. So you'll have some solution, but then as your project continues to grow, that solution will stop working. The positive-sum perspective is basically asking, as Michael said, how can we empower more users to manage the inflow in the first place? And the reason for that is that if you do that, managing the inflow scales as the users grow. In other words, we view open-source users as part of the solution instead of part of the problem. And so that was kind of a little bit of an abstract point. More concretely, what ends up happening is that if you treat users as part of the solution, if you treat the problem as how do you get some number of your users to help you manage the inflow, what you notice is a thing that I think everybody knows, which is that users that start off doing very simple things like fixing white space in your documentation or something, quite often will end up growing into contributors and even maintainers. And so once you recognize that this phenomenon exists, Trek Glawaki, who's on this slide, was one of our biggest dissenters for Ember in the beginning on Twitter, and he eventually became a core team member and ran the documentation team for a while. Basically, giving people a lot of opportunities to grow from users who are basically introducing inflow into your project to contributors and maintainers that help reduce it is something that you need to, you wanna spend a lot of time thinking about and finding strategies for dealing with. Okay, so Yehuda talked about this sort of apparent or partial tension between the maintainers perspective and the community's perspective. There's another tension that people experience a lot which sort of questions about what should the relationship between community and companies be. This is something that I've had a lot of firsthand experience from the company perspective because I ran the Mozilla research group for about seven years. I worked at Mozilla for about seven and a half years and at LinkedIn now. And we took a lot of projects from sort of early experimental phase to try to getting them adopted in the world. And so we kind of experienced that growth path and having to figure out how to navigate the relationship between companies and communities. So the particular experience I wanna talk about the Rust programming language, which, yeah. Yeah. I'm a big fan myself. So there's no Rust code in this talk, don't worry. See me after if you want me to write some Rust code. So Rust started out inside of a company. It started out as a project in a company. And it was a company that didn't necessarily have the deepest pockets like Mozilla was not as deeply resourced as some of its competitors. And at the same time, we also had this sense that we really wanted Rust to grow. We wanted to build an ecosystem. So we already had some inklings that it was kind of, it wouldn't really make sense for this to be something that a company could do on its own. And of course Mozilla sort of in its core values believes in open source. So we were primed to think about it but we didn't have all the tools. And so over time we started discovering all these conflicts between people in the Rust community who didn't work at Mozilla and people who did work at Mozilla. And we had to learn how to deal with that. So really at the end of the day this came to a head where the Rust leadership started to ask themselves what kind of a community did we want Rust to be? So I was sort of learning in real time. I was friends with Yehuda. I was getting a lot of ideas from him. I was working with the Rust core team to try to figure out how should we be thinking about this? How should we be thinking about the relationship between leadership and the rest of the community? And how should we be thinking about the relationship between this company, Mozilla, that has to date been kind of the primary supporter of the project? And we ended up coming up with sort of two basic models in our head for two different approaches that companies tend to take. And we came up with these slogans, one OSS versus two OSS. The basic idea being how many communities are there in practice? Is there just one Rust community and everybody is sort of on a level playing field or are there two separate communities based on your employment status, based on what institution you're a member of? And what we were realizing was that the two OSS approach was tempting and maybe in some ways easier, but it wasn't actually a way to empower community, to scale community, to decentralize the project, and ultimately to let Rust grow into something that its entire ecosystem wanted it to grow into as opposed to being something that Mozilla controlled. So yeah, basically this is kind of a nut of the idea. What is the relationship between the institution and the community? In one OSS, an institution has no governance role. No institution has any kind of special status. In two OSS, there's one particular, one special institution that manages the governance. It's the one that's in charge. With the leadership structure, you can't actually be a leader unless you work for the institution in a two OSS setting. Whereas if you look at the Rust core team, there are people who work for multiple companies. Now there's still a lot of Mozilla employees, like Yehuda for example. There's still a lot of Mozilla employees, but it's not 100% and it's not a factor in the decision of whether you become part of the core team. And maybe the most important part is how decisions actually get made. Is the liberation done through the community within the community or is there sort of community feedback that's taken and then the real leaders get to decide what to do. So if you're thinking from the perspective of say a suit at a company and somebody like this young whippersnapper Dave Herman comes up and says, hey by the way, I think I wanna take this project and I wanna like take it out of the control of our company. That might feel threatening, that might feel scary. And they might naturally ask, is that actually good for us? And there certainly was a fair amount of controversy. I would say that at Mozilla I had a fighting chance because the company at least had a belief in open source. But even so, this was kind of counterintuitive for a number of people at Mozilla. But if you think about it, it actually makes total sense for a company for some kinds of technology, particularly infrastructure type projects like a programming language. It can't survive without an external ecosystem. It's not possible to build a core platform infrastructure technology without building a broader ecosystem. And if one company controls that platform just sort of by the normal workings of any institution, there are all sorts of internal pressures within the company that are gonna push for various short-term solutions that may make sense at the moment for the needs that the company has, but doesn't necessarily make sense for the long-term health of the project or for the broader ecosystem. And bringing external investors into the project and giving them leverage and giving them a voice and trying to counterbalance those forces that happen inside of one particular company creates pushback against some of those pressures. And of course, independence removes friction for participation so you can just get a broader range and a broader set of kinds of inputs into the project. So another question of kind of the relationship between community and companies kind of comes from the community perspective. So when you're sitting in the community, how should you be thinking about what you wanna do with companies or do companies even have a role at all? There's certainly lots of people who are really not very comfortable with the idea that there are businesses involved in open source. And it's kind of easy to think of companies in this sort of abstract way or to think purely in terms of the most powerful people at those companies like VPs and executives. And those are real, those are very real things. But it's also really important to remember some of the individual engineers and what they're doing in the companies or other kinds of contributors, not necessarily engineers and what they're doing from day to day. So like this story here, this is a really common story but it's one that we forget really easily. You've got an engineer who's just got a job to do in their job, they're sitting down at their desk and they need to ship a piece of code and there's already an open source package out there that they can use that'll just solve it for them. In some sense, this is obviously great. We all live in a world where open source is normal. This didn't used to be normal. But it's a common day to day occurrence and the thing is once you go from that first step of adopting the piece of software, it's a very natural next step to say, oh, there's a bug, I need to fix it or oh, there's another feature I'd like to have, I'll just contribute that. So there's a very smooth and natural graduation path from a user and adopter to a contributor. And of course that can go even farther and that's really I think where the story has the most potential is that you might have this long tail of people who are just using, you might have a long but not quite as long tail of people who are occasionally contributing sort of little contributions here and there but every once in a while, without of that larger pool, you'll get people who kind of keep going. They kind of keep building their relationship within the community and all of this started within the context of their day job in a business. And importantly, the person in the company doing the little work didn't have to get that much permission to fix the bug in the first place but it's very hard inside of a company to get permission to do a bigger thing when you're not already a contributor. So this basically gives people an on ramp to getting permission from inside their company at a higher level to do more serious contribution by giving them a way to start from the bottom. Yeah, the sort of contrast would be you try to negotiate big contracts with like BizDev or something like that and you come in and say we're gonna have a million dollar contract for your company to bet on this particular open source project. It's a lot easier for them to get to that point if you had lots of intermediate stages before you got to that point. And this, these individual contributors are kind of the lifeblood, they're kind of the key to that on ramp. So this is an abstract, like just to give you some concrete examples, actually one of the first ones that I experienced was Yehuda himself. So as you can see here, and I've collaborated in a bunch of different levels. There was the TC39 story, but also, you know, as we were talking about TC39 stuff, I kept telling him about Rust and he was thinking this really solves a particular problem I have in our product Skylight. And so they experimented at this company with using Skylight and found that, sorry, with using Rust for Skylight and found that it was solving their problems. So we got a huge boost in the Rust project from Yehuda adopting Skylight and he brought new stuff to the Rust project as well as to Mozilla, for example, more modern open source workflows, a GitHub based workflow instead of the old crafty Mozilla technology that we were using from the 90s. In fact, a lot of the open source ideas from this talk were coming out of Yehuda's involvement with the project, his relationship with me. And generally, it would not have been possible for me if the project was more in a two OSS frame. If I couldn't, they were sort of thinking, oh, we're building it, it's not really ready for users, but the fact that it was already kind of primed to have leadership from outside the company allowed me to say things like, I actually need to support Linux 2.6.18, which they probably would have just said, cool story if it wasn't structured correctly. So this person here in the middle is Carol Nichols who is on the Rust core team and she runs a consulting company of her own and she's also been experimenting with some new product ideas that are actually coming out of work that she's been doing on the core team. So for her, there's been these sort of flowing the other direction of the open source work has been providing business opportunities for her. That guy over there may look familiar to you. The whole reason I'm here today is because Terrence has actually been playing with a project of mine called Neon and experimenting with maybe whether that might be useful to his employer. So I've lived a number of these different experiences of people sort of kind of dabbling with open source and then growing in their relationship through business. And the person over there, Chad Hayatala, is he went from being kind of a struggling internal champion of Ember, had to do a lot of work to get LinkedIn to even use Ember and now he's probably one of the top highest value contributors to the Glimmer VM and Krati, the person on the top left is a, she basically works on internal tooling for LinkedIn but she's produced some of the highest value Ember CLI tooling improvements for Ember based on her work at LinkedIn. So basically both of them went from kind of very small improvements to being very high value contributors through their work. So part of the point we're trying to convey is that instead of just sort of thinking abstractly about business, thinking about the individual people involved in the business world, they have a day job, we all have to have day jobs, that's how we feed ourselves or our families. But in fact, open source has created opportunities and leverage for those engineers in I think a really successful way. And amidst the various problems that we see that are legit and that we need to work on, it's good to actually periodically sort of take a step back and celebrate our successes and say hey, this wasn't necessarily the world we were headed for, it wasn't clear that open source was gonna be adopted by the business world and now that it has, it's actually created a lot of power and leverage for individuals in that world. And just generally, that's another aspect of sort of what can make this fulfilling as you're growing your project, as you're finding new challenges, it's important to have things that actually make it worth it and make it fulfilling. And knowing that your work is helping people to be able to not just solve their specific problem that hand in their job, but maybe grow in their career or maybe have more influence at their company and maybe grow their whole career, that's a really fulfilling thing too. So yeah, I mean generally part of this question of the relationship between community and business is this undercurrent or the sort of chorus you hear a voice is saying like we have a problem with open source funding and the problem is that there's a lot of companies that are taking the results of open source and they're not giving back. And I see that perspective to some degree but I guess I don't really look at it quite the same way because I see just the act of adoption within a company as creating the conditions where individual contribution can grow. It's creating opportunities for these individual contributors who can then grow in their career and their relationship to the project. And that also can grow into that individual within the company convincing the company to contribute in other ways to the project. So sort of that incremental growth path that allows for companies to have a good relationship to open source is really powerful and we should just be careful as we think about ways to fund open source and ways to make it sustainable that we don't cut off some of these paths that are really valuable. And I would also add that it's not intrinsic that if you do get a lot of adoption you have past for individual contribution what we were talking about before about the maintainer versus community point of view and the one OSS versus two SS division actually has a lot to do with this. The more people outside of the main core group actually have leverage and power and deliberative capability and the more they're able to do things the more likely it is that you actually get some of these people who are adopting it to be individual contributors which is what Michael meant when he said we need them to be part of the solution instead of part of the problem. And since I've never written a line of ruby code in my life the least I could do is to cite DHH just to kind of echo some of these same sentiments that we sort of cast a wide net and we never know which individual people who get involved in a project are the ones who are really gonna take to it and grow and that's part of why we cast a wide net because as he says you never know when the next person who's started with just fixing a mix misspelling in the documentation ends up implementing the next great feature and that's another one of the really fulfilling things about open source is the surprise that you see somebody who just came in with a really kind of humble contribution and all of a sudden they're implementing a deep compiler feature in the Rust compiler and you never even knew that they had the ability to work on compilers for example. So that's kind of one of the big takeaways that we're hoping to leave you with is that this sort of one OSS frame, this idea of there is one community is a really healthy way to grow open source and to sort of make it through these different stages of the life cycle of a project and generally the goal of having kind of one big umbrella is to avoid the unnecessary divisions or limitations that keep people from participating the way that works for them, the way that they want to participate, to contribute the way that they want to contribute. One of the ways that Yehuda often says or sort of the thing you're trying to do in building a healthy open source project, he often says is trying to determine the least coordination required to enable the most decentralization. That's usually not zero. Right, that's right. Yeah, and that's sort of a common mistake is oh since the goal is decentralization all coordination is counter to that goal and in fact if you don't have a bunch of decentralized people sort of working towards us some set of shared purpose, some set of shared values then it kind of falls apart. But I imagine in the Ruby community that's not a hard sell. So yeah, Yehuda and I have been kind of working on our model together on how we think about open source for many years. What is the one OSS model? We don't claim that our, where we are at any given point is perfect and we're sure that there's a lot of different ways to approach it. But we find some of these frames to be really useful thinking about positive some outcomes thinking about deliberative participatory open source communities. And then we've also benefited a lot through our collaborations on Ember as well as Rust. And then as we go along and standards and as we go along sometimes we share our thoughts on this blog called the feedback loop. So we invite you to come check that out. So there's a lot of people in this room with a lot of different perspectives. And so what I want to say is if you're starting out if you're new, if you just want to learn the ropes then find a small project or contribute to an either starter, sorry. Either start a small project yourself which you can learn the ropes or find an existing project that you can do something simple like fixing documentation. If you run an open source project already and maybe you're already feeling overwhelmed in some of the ways that we described then study how your decision-making works. Think about ways that you could modify your decision-making to be more, to be healthier, to be more open to a lot of different contributions. And finally, this third one is something that is not totally obvious but if you have access to resources give your employees permission to do open source work. And that starts with give your employees permission to write a pull request if they want to make a change instead of hard coding the change in your local repository. But also maybe you're a director and you have some control over resources or maybe you're a lead and all you have access to is some persuasive capacity. A lot of these decisions are very small decisions. It's today should I be working on a pull request for to fix this thing upstream or should I do something else? And what I would say is no matter where you are if you're a leader, if you're a manager, if you're a VP, if you're a CTO, whatever find ways to encourage people to participate more. I think that helps a lot. Thank you very much. Thanks. Thank you.