 So today I am going to talk about contributor growth strategies for open source projects. I wanted to quickly start by thanking the Alpha Peace Loan Foundation for funding my position along with some other chaos project initiatives. Now I have been in the technology industry for well over 20 years working mostly on open source projects with a focus on community strategy, data and metrics, growing your contributor base. And I can tell you that it's really, really hard to build a strong open source project and a strong open source community around that project. And most of us struggle, right, finding enough human beings to sustain our projects. So let's start by talking a little bit about the problem and why it can be so hard to achieve sustainable contributor growth for your open source projects. I'd like to start this with a little Star Trek quote. So an alien life form on Star Trek the next generation once described humans as ugly bags of mostly water. Now I think they got the ugly part wrong, right, and I think we're kind of attractive as a species, but we're kind of squishy, right, and not just in the physical sense. We can be unpredictable. We can be irrational, especially when we're stressed out, when we're overworked, when we're burnt out. And the reality is that we, we are not robots or mindless automatons, right? Humans have feelings. We have bad days. We have other commitments and personal challenges in our individual lives that are often completely invisible to other contributors. And they get in the way of our contributions to open source projects. But you can't have an open source project without actually having the human beings to maintain it. So you need to be able to encourage people to participate in ways that are sustainable over the long term, both for the project and also for those people. And it helps to be proactive and ask people to participate in specific ways that match the work you need to do within the project. Many projects struggle to find people who will actively participate in those projects and continue to participate over the long term. If it was easy, you would all already have all the people you need. None of you would be sitting here in this room watching this talk. But we're in a situation now where there are a lot of open source projects, so many projects and just not enough contributors. So maintainers are burning out and they're really in desperate need for help. And sometimes it can be really difficult to get people to contribute to your project. And unfortunately, there's no magic, there's no one size fits all solution. So throughout this talk, I'll focus on some things that you can do to increase the chances of being successful at building a community and growing contributors for your project. Open source project maintainers are also squishy humans with feelings and bad days. And maintaining an open source project is so much work. And it often extends out over many, many, many years. And maintainer burnouts common, really common in open source projects. Even the really big successful projects like Kubernetes, they struggle with maintainer burnout and growing their contributor community over time. And it can be hard for those already overworked maintainers to balance the day-to-day work required to actually keep the project running, while then also investing additional activity to increase that future community sustainability. So this creates this vicious cycle, right? Maintainers don't have enough time to onboard new contributors, which then leads to fewer contributors, which leads back to no time to onboard new contributors. So while it takes a bit more time up front, if you can invest some time in activities that will help onboard some new humans, like onboarding documentation, for example, you can increase the chances that you break out of that vicious cycle. Now that we've talked about the factors that can impact contributor growth and why it can be so challenging, I'll shift into talking about some of the strategies for growing your contributor base, using contributor ladders to find more humans who can grow into leadership positions. And finally, I'll talk about some metrics you can use to measure project sustainability, along with some resources and then a few final thoughts. So as promised, let's start by talking about developing and executing on a long-term contributor growth strategy, including motivation, governance, new contributor onboarding, mentoring, and leadership. People's motivations for contributing to your project vary widely. Some people are contributing as part of their job, others might contribute to gain some experience, or maybe learn about a particular language or a particular technology, and you don't really have any control whatsoever about what originally motivated these humans to show up in your project. But there are some things you can do to motivate them to stick around, regardless of why they showed up in the first place. Clear communication and reducing friction are key to helping people stick around. So I'll talk more in upcoming slides about the importance of explicit and clearly communicated governance, along with solid onboarding documentation and fostering a welcoming and inclusive community. There are also other things you can do to motivate people to contribute. So if you're in the last talks, Les talked about having good first issues, help one-a-day labels are also excellent places to start, because these help the humans find something they can work on while they learn a little bit more about your project. And good first issue should be targeted to something really simple, that a brand new contributor could pick up and actually complete in a short period of time to help them learn more about your contribution process. And help one-a-day labels can be for issues that are maybe a little bit more involved, so that people who've already started to contribute can find something to work on next. But good first issues and help one-a-day labels are passive requests for help. So I encourage maintainers to be proactive and specific about ways that people can help. Asking someone specific to review a PR or answer a question from a user demonstrates that you recognize their unique expertise and want their help. So this is what motivated me to start contributing to CNCF's tag contributor strategy. Paris Pittman asked me to write a guide for the tag about measuring project health, a topic that admittedly I am as a data scientist, pretty passionate about, and it just made me feel good that she respected my expertise and actually wanted my help with this document. And so knowing that we're wanted and appreciated makes the squishy humans feel good, which can be a really strong motivator to contribute to an open-source project or to stick around and continue contributing. A lot of people like to hate on governance. It's just extra paperwork. It's busy work. It's all the stuff that gets in the way of doing the real work on the project. But this is not true of good governance, which is just really about setting expectations and getting all of the various humans within your community collaborating together. Ultimately, the focus of open-source project governance is on the people, the roles we play, our responsibilities, how we make decisions, and what we should expect from each other as a part of participating in a community. The goal should be to make the processes for participation as obvious as possible, even for people who are brand new to the community. Having clear rules about how collaboration occurs, how decisions are made, what types of contributions are in or out of scope, help community members make contributions that are more likely to be accepted and embraced by the project. Now, this avoids wasting maintainer's time with contributions that, for whatever reason, just are not aligned with the project at all. A healthy project with clear governance makes the humans happy and helps set your project up for future growth and long-term success. Another aspect of governance is about making it easier to move people into leadership positions and increasing responsibility to help reduce the load on those existing overworked maintainers. We'll talk more about this later in the section on contributor ladders and leadership. The good news is you don't even have to start from scratch. We have some really good templates with instructions that we've developed for the CNCF with the link on the slide, but these really apply to most projects. You could grab these templates to help you quickly and easily build out some basic governance for your project. Now, I suspect that some of you are still thinking that you don't really need to spend time documenting governance, but think about this from the perspective of the brand-new contributor. It's a lot more difficult to participate in a community if you don't know anything about the role you might play, the expectations, the key players, or just the rules for participating in that project. Explicit documented governance gives both new and existing contributors a clear path to guide them through your project. And spending a bit of time documenting this upfront can save you a lot of time later with fewer questions about how things work, and it gives you a document that you can point people to if they have questions or if there are issues later. Personally, when I start contributing to a new open-source project, I want to know how decisions are made. Who makes those decisions? Where are the discussions about those decisions happen? Which helps me understand whether decisions seem to be made fairly in the open based on solid information with the involvement of people with the expertise to actually make those decisions. And I also want to be able to see a clear path into leadership for me or my colleagues or other participants if we decide to embrace that project over the long term. And the bottom line is that if processes for collaboration and decision-making are not clearly documented as part of governance, this introduces a lot of uncertainty into the mix. And uncertainty makes the humans nervous. It increases the barrier to contribution and jeopardizes the health and viability of that project. Good documentation is how we scale the things that take up precious time for those already overworked human beings. Like answering the same onboarding questions over and over and over again. And I see so many open-source projects with contributing guides that don't actually provide much or frankly any useful information. And at a minimum, a new contributor needs to understand how do they spin up an environment where they can do their development? The expectations for testing and how to run those tests. Any other processes or expectations you might have for pull requests or other types of participation. Instructions for additional requirements like maybe somebody has to sign a contributor license agreement or use a certificate of origin process. If this is all well-documented, new contributors can get started with a minimal amount of help from the existing maintainers which can save you a lot of time in the long run. When a project doesn't have good onboarding docs, those squishy already burnt out maintainers get frustrated by the amount of time that they spend on new contributor questions which can make it hard for new contributors to feel welcome and it can take a long time for them to become productive. And this is how the humans get discouraged and just start to drift away from your project. Now, what this does not mean, you do not need to spend days and weeks writing the perfect onboarding documents. Anything is better than having nothing. And if you start with a few things that will help people get started quickly, new contributors can actually help make the onboarding documents better by adding more details or additional instructions for something they found confusing that they struggled with. Your project should also be designed to keep diversity, equity and inclusion top of mind, building a diverse community where all humans feel welcome and included doesn't just happen. It does require putting a little bit of work and thought into it. But this is time well spent, right? Providing an environment where everyone, including people from marginalized populations actually feel safe in your community is the first step toward building a diverse community around your project. Ideally having programs that give people opportunities for shadowing, mentoring, sponsoring these new potential leaders can help you grow a diverse set of people into leaders within your project. The Kubernetes contributor experience SIG is a great place to see some examples of how to implement programs for things like shadowing and mentoring. Projects that make a concerted effort to bring in new people from a variety of backgrounds and have programs in place to help those people grow into leadership positions are more likely to benefit from increased innovation and have a healthier overall community. And by having a diverse and welcoming community, you also have the advantage of getting the humans who might not feel welcome in some other projects. Oops. Now, this is still kind of part of the strategy section, but it's important enough to call out separately with its own section since moving humans into leadership positions is really a key part of growing your contributor base and scaling your project. And I'll talk about this in the context of contributor ladders because that seems to be a pretty good way to do it. Defining the roles and responsibilities for contributors, reviewers, and maintainers can help with recruiting new humans into these roles. It can help to think about this as a ladder, right? Where new contributors climb up to become reviewers, those reviewers become maintainers. And what's important is to document and make sure that people understand how they can climb that ladder and gain more responsibilities within the project. A contributor ladder usually outlines the different contributor roles within the project along with responsibilities and privileges that come with them. Community members generally start at the first levels of the ladder and then advance up it as their involvement in the project grows. And for each rung of the ladder, you can define responsibilities, which are the things that the contributors expected to do, requirements, which are the qualifications that a person needs to meet to be in that role, and privileges, maybe some additional things that people on that level are entitled to. And all of this helps set the expectations for those new roles and encourages people to think about how they might take on areas of increasing responsibility within the project. And as you get more humans moving into those maintainer roles, you can reduce the load on the existing maintainers. The good news is, again, there's a template. You don't have to build this from scratch. It was based on Kubernetes, so it probably has way more roles than a lot of people need. A little smaller project, you can simplify it, you can customize it, and make it work for your project. Project leadership is one of the key elements of good governance, and I love that photo. Paris is just demonstrating the leadership in that photo, right there. But this is an element of key governance, right? This is how you scale your project. So you should have really clear documentation about your leadership. For small projects, maybe you just need a list of maintainers that indicates which of the humans are responsible for which areas of the project. The key is to spend some time thinking about this as you document your governance and contributor ladders. So you can bring new humans into leadership positions and reduce the load for the existing maintainers to help scale your project by growing your contributor base. There are loads of different options for selecting leaders as part of defining your governance. And the ideal is to have a process that provides a fair and level playing field that defines how contributors become leaders. And this should be documented so that all participants can clearly understand the criteria and the process for moving into those leadership positions. Some of the bigger projects, like Kubernetes, have an election process, at least for the top levels, like the steering committee. But only the biggest projects actually need something that complicated. Most projects have a very simple process where the existing maintainers or leaders get to select the new ones. For example, new maintainers are often nominated by existing maintainers and approved maybe after a certain number of maintainers agree or sometimes it requires a vote. And there are loads of different options for selecting leaders. So I won't try to cover them all here. There's a link to a doc with more details, but I would say pick the one that's the simplest one that could possibly work for your project. Now mentoring does take a bit more time, but it's also a really good way to help existing contributors become even better with an eye toward moving them into leadership positions. For busy maintainers, one good approach is to focus on mentoring some of the humans who've already been around for a while and are unlikely to disappear and maybe help them learn to do some more complex time consuming tasks within the project. Like with lots of things, mentoring is not something that has to be all or nothing. And you can just time box it to whatever amount of time you can fit into your schedule, even spending an hour a month or an hour a week to help someone quickly become more productive in your project can really be time well spent if that person can then take on a few tasks to reduce your load as a maintainer in the future. You can even structure this as shadowing, right? Allow them to watch and learn while you do some maintainer tasks that needed to be done anyways. And if you focus this on helping another human learn to do something that can free up your time as a maintainer later, so this is gonna be time well spent for you. Humans like to think of ourselves as irreplaceable, but we are not. We move on to other jobs. We burn out. We retire. And let's face it, humans are mortal and we don't get to live forever. So you should think, think about what you wanna do next and how you can prepare someone else to take over after you move on. I encourage projects to have an option for people to move into emeritus roles, which recognizes the hard work that you've put into a project and gives others a point of contact if they have questions about what came before, while also allowing you to maybe step away from the day-to-day responsibilities on a project. So I encourage you to think of stepping into an emeritus role as a successful way of handing off your duties to the next generation of maintainers to be a project. The strategic part of all of this comes in thinking about where your time would be best spent. I've given a lot of suggestions so far in the presentation and you should not, not try to do everything at once. So I recommend you think strategically about where you should start. If you know you've had interest in contributing, but people have given up and they couldn't get started, maybe you start with some onboarding gox. If you have loads of casual contributors, maybe you focus on the contributor ladder and governance to help you move some of those other humans up to take on more responsibility and eventually move into leadership roles. Another way to free up some time for maintainers and break out of the vicious cycle that I talked about earlier is by getting help with different types of contributions that take up valuable time and are required to make a project successful. So this is what Celeste and Natalie were talking about. Things like documentation, marketing, community management, project management and so much more. And for projects with really complex code bases, it can sometimes be easier to onboard people into these roles first to free up some time to onboard other contributors later. One way to figure out the best place to start is by using metrics to help find the problem areas and figure out where you should be spending your time. Time is really precious, right? So it's important to identify the problem areas where you can focus on the right things while avoiding wasting your time and other things that maybe are already working well enough. However, metrics do need to be interpreted in light of the project and how you operate as a community and the other things that are happening within your project. There is absolutely no one's eyes if it's all interpretation for metrics. So in this section, I'll use some example graphs using some of our chaos metrics tools and talk about what some of the trends might indicate and how you can think about addressing some potential issues. One key area to look at for your project is responsiveness. So this is a backlog graph from the chaos grimoire lab tool. And in this project, you can see that there are times when they have a lot of PRs in the backlog that need to be either merged or just closed without merge. And if these PRs are coming from several regular contributors who aren't maintainers, it might be a good idea to look at how you can promote some of those humans to become reviewers or provers or maintainers to help out with the workload of catching up on this backlog. But with any metrics, you need to interpret them in light of the project, right? There are loads of other things that can cause an increase in the backlog, like everyone preparing for a big release, conference season, if it's July in Europe, vacation season, because everyone is out. And so you need to think about whether these are really caused by something that you can fix or something that is just seasonal and we'll go away the next time you measure it. Again, these graphs come from grimoire lab. Other metrics to look at responsiveness focus on the amount of time it takes for maintainers to close issues in PRs. Looking at the trends for these metrics could be particularly important. In this example, you can see that it's taking longer for maintainers to close PRs or issues. And like with other responsiveness metrics for the backlog, the one we showed earlier, it might be a good idea to look at how you can promote some of those other humans to become reviewers or provers or maintainers and help out with the workload. But again, you have to interpret them in light of your project. There are other things that can cause increases in time to close, like the project becoming more complex or just becoming larger, which can increase the time required for testing and other activities that would happen during the process of reviewing and closing PRs. It can also help to look at the types of contributors you have. I really like this type of measurement because in this case, one of the things you can see is that there are casual contributors, are those sort of drive-through contributors who make a small handful of contributions and then disappear? It's totally normal, that's fine. Regular contributors are the ones who stick around, they make some contributions, they stick around and continue to make contributions over a period of time. And core contributors are usually the maintainers who make most of the contributions and stick around over the long haul for the project. Now you can really learn a lot from this type of graph. If you have a very small number of casual and regular contributors, this could mean that maybe you don't have the information needed for people to become productive and contribute. In some cases, onboarding docs can help solve this issue. Another thing that this graph can indicate is whether maybe you have some fundamental issues within the project that are possibly driving those humans away. If you see the total number of contributors declining or the number of regular contributors declining, this could potentially indicate some deeper issues, maybe with some toxic community members or an unwelcoming environment. And that probably needs to be resolved before you take any other actions to grow your community. Or it could just mean that people are leaving your community for other reasons, maybe lack of responsiveness, like we talked about earlier. This metric is often called the bus factor. I like to call it the lottery factor based on the idea that if one person disappeared after winning the lottery and retired on a beach, and if that person, like in this graph, was making all or most of the contributions, then that project would probably be kind of screwed if they left, right? This graph uses data from chaos's auger software, and I really recommend measuring this because there are a couple of things it can tell you. First of all, how big of an issue is it in your current contributor situation? If it's like this one, you really need to focus on getting a few more humans that can eventually be moved into leadership roles and making more contributions. You might find that there are people who are contributing more than you realized, which is the other reason that this is a really good metric to look at. This can help you think about who you could encourage to contribute more, or maybe find someone who could move up the ladder into a leadership role. Reaching out to someone and acknowledging their work while encouraging them to do more can help quite a bit with contributor growth. Sometimes people just need a bit of encouragement, and you can ask them, as I mentioned earlier, for specific things that you know that they're good at. In this case, you might look at that person making 11% of the commits and decide that they're ready to become a maintainer. Some of the ones a bit lower down who are making six to 8%, maybe they're good candidates for mentorship or becoming reviewers with an eye toward making them maintainers after maybe they get a little more experience. And the catch here, and with many metrics, is that we don't want to just think about people who are making commits. So this is one way to look at it, and this is a good start, but you should also be thinking about how you can move people into leadership positions who are responsible for other things that may or may not show up in GitHub, like documentation, community management, marketing, project management, and loads of other important roles within your project. Now, we recently launched a survey of existing and past users of chaos tools and metrics designed to help us understand some of the challenges and barriers in using our tools. So if you've ever used tools or technologies from the chaos project or our metrics, I like Augur Grammar Lab, Beturgia Cauldron. I encourage you to complete the survey. It closes on September 26th, so next week. So that would be great. I'll just pause while people take pictures, QR codes. As I mentioned, the slides are already uploaded onto the schedule, so you can grab it there if you need to. Before I wrap up the talk, let me leave you with just a few resources that I think you might find useful. The CNCF contributor strategy tag has a governance working group, contributor growth working group, several other working groups, and we provide templates and guidance about contributor experience, sustainability, governance, and openness to help people develop strategies for maintaining healthy projects. We also have a contributor growth framework that you might find useful. The open source way guidebook is a great resource that has loads of details about building and maintaining open source projects. The chaos project, as I mentioned before, has loads of metrics definitions and software that you can use to measure the health of your community, and they're all great starting places for understanding how to grow your contributor community. Now, I mentioned the CNCF contributor strategy technical advisory group and linked to our resources on various slides, but I also wanted to put in a quick recruiting plug. Like with most open source projects, we are also looking for your help. The resources and templates that I've linked to were all created by the humans behind the technical advisory group, and we can use your help to improve them, create new resources to help CNCF projects. So if you're passionate about contributor growth, governance, building community, and want to help CNCF projects improve in these areas, we'd love to have you join us and help us develop more resources and provide advice to projects. So let me wrap things up with just a few final thoughts and a call to action. So maintaining an open source project is so much work, and there are so many maintainers who are overworked, exhausted, burning out. And the best way to address this challenge is by finding more humans and growing your contributor base. But it's hard work and it takes time away from the day-to-day activities right now, which can be really hard to justify if you barely feel like you're keeping up as it is. But in the longer term, spending at least a little bit of time on things that can help you recruit and keep new contributors will be worth it. And as I mentioned before, you don't need to do everything at once. Spending just a little time on something to grow your contributor base is really a great way to start. So this is what I'm asking you to do if you're a maintainer or even just a regular contributor to an open source project, carve out an hour a week to improve your onboarding docs, your contributing guide, your project governance, or just spend that time helping another human learn to do something new. Thank you and we'll open it up for questions. Okay, we have a question in the back. Do we have a microphone for the questions, for the lovely folks on the recording? Or the live stream? I guess it's been live streamed. Right there in the back. Thank you for your talk. Just a question regarding the matrix you showed at the end. What about the, you know, not the quality, the complexity sometimes of the issues, the commits, you know, you can have just a couple of commits be the guy with only two commits. But that's, you know, that's a really complex one with a lot of changes compared to maybe documentation, the guy, you know, changing a line, you know, commit per line in the documentation, for example, or translation. So how can you wait, you know, those kind of commits and contributing issues regarding complexity? Yeah, absolutely. Not every commit or pull request is equal, right? Some of them are very small. Some of them are incredibly large. And so by looking at some of the metrics that I showed, it gives you kind of a holistic picture. It's sort of an average or a median, depending on how you calculate it. So it's one, it's a simple way to look at it. You can do a lot more advanced things, right? You could include something like complexity into a calculation and include that into a graph if you wanted to do that. It makes it a lot harder to take that into account. But, you know, and the other way you can take that into account is just by understanding the project and what's going on and looking at the data yourself. And so you can see some of those, some of those things happening in the data itself. So you can measure it, it's a lot more difficult. Yeah. Question up front, Natalie. Thank you. Thanks Don, for your talk, it was awesome. I think, I just want to, a huge thank you for leading with the Emeritus as a goal and the leadership purpose. I think a lot of projects are scared to lead with that, to say, come and lead our project, it's a resume building, it's career building, et cetera. But what about the leaders who aren't in that high contributor character, not doing the most work, so to speak? How will you go about off-boarding specifically in terms of how that would be documented and then what metrics you show to kind of prove that needs to happen? So let me understand the question better. Is it, how do you know when a leader needs to be off-boarded? Yeah. Oh, I don't know that I want to step into that pile of boobs. No, that's a good question. I mean, not, yeah, a lot of projects end up in this situation, right? Where they've got leaders within the project who effectively maybe aren't doing as much as they used to. Or the other problem you have is that you have leaders within a project who are the only ones who know how to do a certain thing. And you really need to find ways to bring other people in to help them out. So in the case where they're maybe not responsive and not doing a whole lot, I think someone else would have to mentor some people in to take over some of those tasks. Ideally, you can have that person start to mentor people and bring them in and help them understand what else needs to be done and start to share the load a little bit. But one of the ways you could look at that, you could look at something similar to what I did with that bus slash lottery factor graph, but look at maybe a bigger swath more than just a couple of people and compare that to what you have in your governance. So compare that to the leadership that you have and look at which people are maintainers and leaders within your project and what are they actually contributing compared to other people? Celeste. Hi. It was a fantastic talk, thank you so much. But the question that came up for me, and this is just because I think we both have worked on projects like Kubernetes, but a part of our roles have also been working with the significantly smaller projects. What do you feel like the minimum viable contributor ladder is for say the five person project and what's the minimum viable governance model? Because I really feel like small projects do need some level of governance to be successful, but you don't wanna overload them and you can't say well take this thing that we did in Kubernetes or even take this thing we did in Envoy and apply it just doesn't work. Yeah, absolutely, it's a really good point. I mean not all projects are created equal and they're of various different sizes. And so what we consider within the CNCF minimal viable governance is kind of our maintainer template, which is a really simple template which basically says that the maintainers get to pick the new maintainers is kind of how to boil that down. So that's what we consider sort of the minimal viable governance. I would say the minimal viable contributor growth ladder would probably have maybe contributors, reviewers and approvers slash maintainers and simplify it down to kind of like three things. So like everybody's a contributor that's kind of where you start in the ladder. But getting some encouraging people to move into that approver or sorry that reviewer position even if it's informal maybe they don't have any additional responsibilities from an administrative standpoint in GitHub but having other people review code or review documents or review other contributions is a great jumping off point to becoming a maintainer slash approver. So I think those three roles are probably what I would consider the minimum. Awesome, thanks. Perhaps just one hint because we have some good experience with foundations could jump in for incubation, something incubate such projects like at Eclipse Foundation you get for example a mentor. So I guess that could also be a cool idea as a small CNCF also have such a mentorship from the foundation to just bridge this first few faces until you get big enough to manage that on your own. Yeah, mentorship is incredibly important and incredibly beneficial. And I talk a lot about the CNCF because I tend to work in that space a lot but like you said there's loads of other good foundations that provide projects with additional services like you said for mentoring so things like Eclipse and Apache and there are loads of options for your open source project for sure. Steven. Yeah. So I was gonna try to answer Natalie's question as well regarding when is it time to go or when is it time to rotate the ladder? And I think it starts with a conversation because there's so many people that are I think if you reach mentorship and especially in a smaller project where you have built up trust with your maintainers it's like, hey man, are you okay? Like I noticed that you've changed jobs or you've got stuff going on like usually it's a conversation like maybe it is time right? Let's set a window, let's figure out how to get this done and so I was former tag contributor strategy chair as well and there's several roles that I've emeritus out of and it really is like, hey, let's sit down and figure out where we're going in the next three to six months and further, so. Yeah, and that's a hard one because it's very individualistic. If you could pass the microphone back to the purple shirt in the back. Yeah, the thing with replacing leaders is it's so individual, right? Every situation is different so it's a hard problem to approach but I like Steven's approach which is, hey, you're all right, what's going on, can we help you basically? Yeah, go ahead. Thanks a lot for the talk, I learned a lot. I was now, so we have a product now, Newish, and we have a team in-house and we're developing on it and there's also, like we also want to really be open to the community. So, but I'm struggling to find the way on how to do that in a way that it doesn't interfere with the in-house team. Do you have any thoughts on that? So it's a project which you've started within a company and it's open source and you're trying to get more people from outside the company involved. Exactly, yeah. Yeah, that's super hard. So as a person who's worked at a lot of big companies, there are a few things you can do actually to make that easier though. Part of it is really kind of shutting down your internal channels for doing this, like the internal Jira that you might be using or the internal Bug Tracker and moving all of that out into the open so that your developers are forced to do all of their work in the open so that people can actually see what's going on because if people know that you're doing most of the work in the private channels, they don't really want to participate. And the other piece that can really help is roadmaps. So making the roadmap public and people being able to see what's coming next and maybe what they can help with because you can also put some things on the roadmap that you would love to see happen but you know your developers aren't going to have time to do and so it's like a low priority for you but would be really nice to have in the product earlier. You can put some of those things on the roadmap as well and encourage other people to work on them. It may or may not work, but it does give other people something that they could work on. Paul, that's really helpful. Thanks. Yeah, thanks. I could do one more question if somebody has one. Everybody wants to go to lunch. It's awesome. It's awesome. Yeah. Thank you. I'm glad you liked it.