 So, I've been in the technology industry for well over 20 years, working mostly on open source software projects, with a focus on community strategy, metrics, and growing your contributor base. And I can tell you that it is really hard to build a strong open source community for a project. Most of us struggle with finding enough humans to actually sustain our projects. So let's start by talking more about the problem and why it can be so hard to achieve sustainable contributor growth for open source projects. And Alien Lifeform on Star Trek the Next Generation once described humans as ugly bags of mostly water. So I think I got the ugly part wrong. I think we're pretty attractive people, but we are 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. The reality is that we are not robots. We're not mindless automatons. Humans have feelings. We have bad days. We have other commitments and personal challenges in our lives that are often invisible to other contributors and they can get in the way of our contributions to open source projects. But you can't have an open source project without having human beings to maintain it. So you need to be able to encourage people to participate in ways that are going to be sustainable over the long term, both for the project and for those people. It helps to be proactive and ask people to participate in specific ways that match the work you need to do within your project. Many projects struggle to find people who will actively participate in their projects and then continue to participate over the long term. If it was easy, you would already have all of the people you need to maintain your project and none of you would be here watching me talk. But we're in a situation now where there are a lot of open source projects and not enough contributors. Maintainers are burning out and they're in desperate need of 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. But throughout this talk, I'll focus on some of the things that you can do to increase the chances of successfully building a community and growing your contributor base for your project. Open source project maintainers are also squishy humans with feelings who have bad days. Maintaining an open source project is hard work and it extends out over many years and maintainer burnout is common within open source projects. Even the really big successful open source projects like Kubernetes struggle with maintainer burnout and growing the contributor community. It can be hard for those already overworked maintainers to balance the day to day work to keep the project running while also investing in additional activity to increase that future community sustainability. This creates a vicious cycle where maintainers don't have enough time to onboard contributors leading to fewer contributors which leads back to no time to onboard new contributors. And while it takes more time up front, if you can invest some time in activities that will help onboard some new humans into your project like onboarding documentation, for example, you can increase the chances that you'll break out of this 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 by talking about some strategies for growing your contributor base using contributor ladders to help 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 final thoughts. As promised, let's start 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 a part of their job while others might contribute to gain experience or learn about a particular language or technology. And you don't really have any control over what originally motivated these people to show up. But there are 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. And I'll talk more in upcoming slides about the importance of explicit and clearly documented governance along with solid onboarding docs and fostering a welcoming and inclusive community. There are also other things you can do to motivate people to contribute. Having good first issues or help wanted labels are excellent places to start because these help the humans find something they can work on while they learn more about the project. Good first issues should be targeted as something simple that a brand new contributor could pick up and complete in a short amount of time to help them learn more about your contribution process. Help wanted labels can be for issues that are maybe a little more involved so that people who have already started to contribute can find something else to work on next. But good first issues and help wanted labels are passive requests for help. So I also 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. This is what motivated me to start contributing to TAG contributor strategy within the CNCF. Paris Pittman asked me to write a guide for the TAG about measuring project health. A topic that admittedly I'm pretty passionate about. But it made me feel good that she recognized my expertise and that she wanted my help. Knowing that we're wanted and appreciated makes us squishy humans feel good, which can be a strong motivator to contribute to an open source project or to continue contributing. So I know that a lot of people like to hate on governance. It's just paperwork, it's busy work, it's politicking that gets in the way of the real work on the project. But this isn't true of good governance, which is really about setting expectations and getting all of the various humans within the project actually collaborating together. Ultimately, the focus of open source project governance is on people, the roles we play, our responsibilities, how we make decisions and what we should expect from each other as part of participating in the 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 and what types of contributions are in or out of scope helps community members make contributions that are more likely to be accepted and embraced by the project. 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 positions of increasing responsibility to help reduce the load on the existing maintainers. We'll talk more about this later in the section about contributor ladders and leadership. But the good news is that you don't have to start from scratch. We have some good templates with instructions that we've developed for the CNCF, but that apply to most projects to help you quickly and easily build out at least 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 new contributor. It's much 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 the rules for participating. Explicit documented governance gives new and existing contributors a clear path to guide them through your project. Spending at least a bit of time documenting governance upfront can help save you time later with fewer questions about how things work, and it gives you a document you can point the other humans to if they have questions. When I start contributing to a new open source project, I want to know how decisions are made and who makes those decisions, which helps me understand whether the decisions are made fairly based on solid information with the involvement of people with the right expertise to make those decisions. And I also want to see a clear path into leadership for me or for my colleagues if we decide to embrace the project over the long term. But the bottom line is that if the processes for collaboration and decision making are not clearly documented as part of the project governance, this introduces a lot of uncertainty into the mix, and uncertainty makes the humans nervous. It increases the barrier to contribution while also jeopardizing the health and viability of the project. Good documentation is how we scale the things that take up precious time for those already overworked human beings, like answering same on-boarding questions over and over and over. And I see so many open source projects with contributing guides that don't actually provide much or frankly any actual useful information. At a minimum, a new contributor needs to understand how to spin up an environment where they can do their development, the expectations for testing and how to run tests, any processes or expectations you have around pull requests, and instructions for any other requirements you might have, like signing a contributor license agreement or using developer certificate of origin process, for example. If this is 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 does not have good on-boarding docs, those squishy burnt-out maintainers can get frustrated by the amount of time they spend on new contributor questions, which can make it hard for new contributors to feel welcome and take a long time for them to become productive. And this is how the humans get discouraged and then just drift away from your project. This does not mean that you need to spend days and weeks writing the perfect on-boarding documentation. Anything is better than nothing. And if you start with a few things that will help people get started quickly, new contributors can actually help make on-boarding documents better by adding more details and additional instructions for things maybe that they found confusing or that they were struggling with. Your project should also be designed to keep diversity, equity and inclusion top of mind, building a diverse community where all of the humans feel welcome and included does not just happen. It requires putting work and thought into it. But this is time well spent, providing an environment where everyone, including people from marginalized populations, feels safe is the first step toward building a diverse community around your project. Ideally, having programs that give people opportunities for shadowing, mentoring and sponsoring new potential leaders can help you grow a diverse set of people into new leaders within your project. The Kubernetes contributor experience special interest group is a great place to see some examples of how to implement programs for things like shadowing and mentoring. And projects that make a concerted effort to bring in new people from a variety of backgrounds and then have programs in place to help those people grow into leadership positions are more likely to benefit from increased innovation and have a healthier community. 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. Now this is kind of still part of the strategies section, but I think it's important enough to call out separately in its own section, since moving those new humans into leadership positions is a key part of growing your contributor base and scaling your project. And I'll talk about this in the context of contributor ladders, which is a good way to do this. 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 where contributors climb up to become reviewers and those reviewers can become maintainers. What's important is to document it and make sure that people understand how they can climb the ladder and gain more responsibility within your project. A contributor ladder usually outlines the different contributor roles within the project, along with the responsibilities and the privileges that come along with those roles. Community members generally start at the first level of the ladder and advance up it as their involvement in the project grows. But for each rung of the ladder, you can define responsibilities, which are things that a contributor is expected to do. Requirements, which are the qualifications that a person needs to meet to be in that role. And privileges, which are the things that contributors on that level might be entitled to. And all of this helps set expectations for the roles and encourages people to think about how they might take on areas of increasing responsibility within the project. And as you get more of the humans moving into maintainer roles, you reduce the load of the existing maintainers. The good news is that again, we have a template to avoid building this from scratch. It probably has more roles than most projects need. It was kind of based on Kubernetes. So it can almost always be simplified and customized to meet whatever your project actually needs. Project leadership is one of the key elements of good governance, and it's how you scale your project. So you should have clear documentation about your leadership. For small projects, maybe you need a list of maintainers that indicates which of the humans are responsible for the various areas within your project. But the key is to spend some time thinking about this as you document your governance and contributor ladder so that you can bring those new humans into leadership positions and reduce the load on the existing maintainers to help scale your project by growing your contributor base. There are quite a few 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 can become leaders. This should be documented so that all participants can clearly understand that criteria and the process for moving into leadership positions. Some of the bigger projects like Kubernetes, Knative have an election process, at least for top levels of leadership, things like a steering committee, but only the biggest projects actually need something that complicated most projects have a relatively simple process where the existing leaders select the new ones. So for example, new maintainers are often nominated by existing maintainers and then approved either after a certain number of maintainers agree or sometimes it requires a vote of maintainers or committee members of some sort. And there are a whole bunch of different options for selecting leaders that I'm not going to cover here, but there is an entire document devoted to these various options available at the link on the slide. Now mentoring takes a little bit more time, but it's a 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 the humans who've already been around for a while and are unlikely to disappear to help them learn to do some more complex time consuming tasks within the project. Like with many things, mentoring is not something that has to be all or nothing. And you can just sort of 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 more quickly become productive in your project can be time well spent if that person can take on a few tasks to reduce your load as a maintainer. You can even structure this as shadowing to allow them to watch and learn while you do some maintainer tasks that needed to be done anyway. And if you focus this on helping another human learn to do something that can free up your time later, this will be time well spent. 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 do not live forever. You should think about what you might want to 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 to emeritus roles, which recognizes the hard work that you put into a project and gives others a point of contact if they have questions about what came before, while also allowing you to step away from the day-to-day responsibilities in the project. And I encourage you to think about stepping into an emeritus role as a successful way of just handing off your duties to the next generation of maintainers. 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 try to do everything at once. So I recommend you think strategically about where you should start. If you know you've had people interested in contributing, but they've given up when they couldn't get started, maybe you focus on onboarding docs. If you have a lot of casual contributors, maybe you focus on the contributor ladder and governance to help move some of those humans up to take on more responsibility and eventually move into leadership positions within your project. Another way to free up some time for maintainers and to break out of that 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 an open source project successful, documentation, marketing, community management, and so much more. For projects with complicated 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 problem areas and figure out where you should be spending your time. Time is precious, right? So it's important to identify problem areas where you can focus on the right things while avoiding wasting time on areas that are already working well. However, metrics do need to be interpreted based on how you operate as a community and other things happening within your project. There's no one-size-fits-all interpretation of metrics, but I will talk in this section about what some trends might indicate and how you can think about addressing potential issues. One key area to look at for your project is responsiveness. In this project, you can see that there are times when they had a lot of PRs in the backlog that needed to be merged or closed, 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 with the workload. As with any metrics, though, you need to interpret them in light of your project. There are other things that can increase, cause an increase in the backlog, right? Like everyone preparing for a big release or a conference, or maybe it's vacation season where a lot of your developers are based. So in that case, things might not be resolved by moving people into more leadership roles. It can also help to look at the types of contributors you have. In this case, casual contributors are those drive-through contributors who make a small handful of contributions and then they just disappear possibly forever. Regular contributors are the ones who make some contributions and who stick around and continue to make a few contributions over time. Core contributors are usually the maintainers who make most of the contributions and then stick around over the long term. And you can really learn a lot from this graph. If you have very small numbers of casual and regular contributors, this can mean that people don't have the information to become productive and contribute. And in some cases, onboarding documents can help solve this issue. Another thing that this graph can indicate is whether you have some more fundamental issues within your project that are driving those humans away. So if you see the total number of contributors declining or the number of regular contributors declining, this can indicate some deeper issues, maybe with toxic community members or an unwelcoming environment that probably needs to be resolved before any other actions that you take to grow your community. Or it could mean that people are leaving your community for some other reason, like lack of responsiveness. This metric is often called the bus factor or lottery factor based on the idea that if one person disappeared after winning the lottery and that person was making most of the contributions, then this project would be in a lot of trouble if that person left. I recommend measuring this because there are a couple of things that can tell you. First of all, how big of an issue is it within your current contributor situation? If it's like this one, you should really focus on getting more humans that can eventually be moved into leadership roles. You also might find that there are people who are contributing more than you've realized, which is the other reason this is a good metric. This can help you think about who you can encourage to contribute more and maybe find someone who can 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 we will just need a little bit of encouragement, right, and you can ask them for specific things based on what you know that they're good at. And there are several communities I've gotten more involved in because people were asking for my help. Before I wrap up this talk, let me leave you with just a few resources you might find useful. The CNCF contributor strategy tag has a governance working group and a contributor growth working group which 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 document that you might find useful. The open source way guidebook has loads of details about building community and maintaining open source projects. The chaos project has loads of metrics definitions and we have software that you can use to measure the health of your open source community. And these are all great starting places for understanding how to grow your contributor community. Now I've mentioned the CNCF contributor strategy technical advisory group and linked to our resources on the various slides but I wanted to put in a quick recruiting plug. Like with most open source projects we are also looking for help. The resources and templates that I've linked to throughout the presentations were all created by the humans behind the tag and we can use your help to improve them and to create new resources to help CNCF projects. If you're passionate about contributor growth, governance or building community and want to help CNCF projects improve in those areas we'd love to have you join us to help us develop more resources and provide advice to projects. Now let's wrap things up and I'll leave you with just a few final thoughts. Maintaining an open source project is so much work. And there are so many maintainers who are overworked. They're exhausted, they're burning out. 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 now which can be really hard to justify if you feel like you're barely keeping up as it is. In the long term spending at least a little 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 a good 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 one hour a week to improve your onboarding docs, your contributing guide, project governance or just spend that time helping another human learn to do something new. With that, thank you so much and I think we have a few minutes for questions. Any questions? We do have a microphone that he'll run up if we have questions. I'm sure we have questions. I'll just stand here. People who know me know that I will stand here awkwardly until I get a question. Okay, we've got a question. He's on his way, Sam's on his way with the mic. Hello. Yeah, so my first question is how do you get past the first critical mass of having people contribute to your project in the first place? Yeah, that's really hard. And I would say that it's often part of another problem which is getting people to adopt your project because if you don't have a critical mass of people actually using your project, it's really hard to get that first critical mass of people contributing to your project. So I'd say in that case, if you're, especially if you're a solo maintainer and you're just starting something, I would say focus on getting adoption first and getting some people using it which tends to get more people excited about contributing anyways. So that's where I would start in that case. Okay, thank you. Yeah, we have another question up front. Actually I just wanted to tie this back to something you mentioned earlier about asking individuals to do specific things. And that's something that like, I've been wanting a good way to articulate and like you said it perfectly. But to get to that critical mass, do things that don't scale like learning what individuals can do and asking them to do specific things for you like that. So the question was, how does that scale? I was really just, I was expanding on your answer and bringing it back around to that point because that's something that I completely agree with. Yeah, yeah, and it is hard and it does require getting to know your contributors and being able to ask them for things. And sometimes you can ask people for things who aren't necessarily part of your community too. So that's kind of what happened with tag contributor strategy. So at VMware, I'm responsible for our community strategy within the open source program office. And I saw that the CNCF had this contributor strategy group and I was like, that sounds like something I should be involved in. And so I showed up to a meeting and Paris Pittman looked at me and she said, hey, I know you, you know stuff about metrics because you participate in the chaos project here. We need someone to write this project health guide. And so I wasn't even part of the community but she was already tapping me to do something because she knew me from somewhere else. So I would say also leverage your relationships that you have with other people and other communities. Other questions? Yeah, in the back. Oh no, here, because the microphone's quick and then we'll go to you next. Yeah, so I'm a community manager for a commercially backed open source project and we don't have a really strong contributor culture yet but I'm liking this idea of asking people for things specifically. Do you have any recommendations on how to do so tactfully within the construct of a commercially backed project? Yeah, so that's a little bit harder. Is it engine X, can I see your hoodie? Yeah. Yeah, I mean, this was a challenge that we faced a lot when I worked at Puppet, for example. So it was a commercial kind of contributor community. And I would say to start by asking them for things that are relatively small. So things like, hey, I know you know a lot about this particular technology. There's this question, can you maybe add something to the answer there because you've got some specific expertise? And so I would start with really small things. Like you're never gonna be able to ask somebody, especially being a commercial backed open source project, you can't really say like, hey, you should do this new feature for us. This is not gonna be realistic. So I would start with the small things and maybe they would want to do a new feature eventually. But yeah, I would start with small things. Great, thank you. Yeah, and there's a question in the back. Yeah, because we have people on the recording, I think. Okay, very nice. Sorry, I like the references. I had no idea CNCF had that group, so I may join. I'm a community manager myself so I kind of identify a lot of the issues. Maybe a question or a remark I have is mostly on the, let's say, the recipe side of things because what this guidelines show is you should do this and kind of this makes sense. I often find this as common sense action points, right? But what I find, what I'm doing my experience is maybe equally important, if not more important is what I call mindset. And that's the mindset of the maintainer, the mindset of the manager, community manager, such as pro-activness, such as, I'm not sure, being human, being kind. Martin Hake, I see you, you're there. Also, I have a talk later and I have this be human, right? So there is a lot of items that aren't that receivable. I'm not sure if that's a word, so you can write it. And they tend more to the way the, I mean, psychology of things, of high-risk, the attitude, optimism, being around with people. And this is kind of a remarkable idea question. Is there some guideline on kind of documenting this, hey, how you should be, let's say, a good human in your role as a maintainer, as a manager, beyond recipes, right? So this is things that, if you have them, that's going to make these recipes feel easier to implement. Yeah, that's a good question. I mean, so the idea behind a lot of the templates is that especially engineers tend to have their face with like a blank document, just don't know where to start. So you give them a template, it gives them a place to start and then they can pick and choose the stuff that works for them and that doesn't. That does not solve the human problem, right? It doesn't solve the interpersonal skills that you need to have to be a maintainer. But I think that there are a lot of complimentary things around. So like the CNCF specifically, it's only for CNCF maintainers, but we have what's called a maintainer circle. Where it's basically kind of almost a support group for maintainers, where they get help from each other and learn from each other. But then there's loads of other things, like GitHub has the maintainer month and they do loads of programs for maintainers to help maintainers learn the skills that they need to be successful. And I would also encourage maintainers to spend some time thinking about where you might not have all of the skills that you really need and seek some mentorship and seek some training. And I know this is hard because unfortunately some of the bad maintainers that I know don't necessarily know that they don't have the skills to do that and aren't really open to feedback. So that's a whole different problem that you just can't solve. You can't necessarily change people in that way, but you can provide people with training and conferences that they can go to and places where they can talk to other maintainers to learn. Yeah, I would just add something. So I like your comparison of engineers. I come from an engineering background and it's kind of very template. I want to do this. And what I'm often, let's say afraid of is that people are going to look for these patterns and when the pattern doesn't match because reality is a different thing than kind of the theory behind the rule, they freeze or they kind of do something stupid because they tend to follow that rule. So there's some sort of, let's say, well interpersonal skill or weighing to adapt a given situation. I think that's very valuable. You're going to have tension. You're going to have some sort of level of quarreling and it helps if you know how to handle those. Sometimes someone may be happy, some I mean they may not be happy, how do you handle that situation, right? And there's no recipe for that. There may be some guideline, but it ends up with kind of your personal skills. Yeah, thanks. Other questions, yes. Start with that one and then we'll move to you in the middle. Not so much question. So I work with the government of British Columbia and you were talking about how to get developers on board and bring things on. We have a, the government has a really good program. I'm just a contributor to it, but the government has a really good program that you might look out called Code With Us. And basically what we do is we create a goal and we put an amount of money on it that we estimate and then open it up to anyone to apply. So it's because it's government has got to be a very proper procurement. So it's gone through legal, it's done all that, but we can in a week post something, in another week receive a set of responses, pick one and the delivery is a merge. And once the PR is merged, the payment goes out. So it's a really good program that I would recommend for private industry to look at because it's really a fast way to get contributions to a project and we've had really good luck with getting new and different contributors onto our project because of that and then they just keep going. Cool, that's another question, right? Just a couple of rows in front of you. Yeah, there we go. Yeah, so I'm the Director of Community Engagement for the Decentralized Identity Foundation. And so we're working on specifications. So we're not working on software, but a lot of our community members are. And we just got our first volunteer DevRel person. And it's a challenging environment because the technology is so new, it's hard to find someone who would wanna be a DevRel volunteer and have the knowledge to be able to do that. So I guess, do you have any insights or advice on that kind of situation in terms of, I guess, recruiting when there's a high learning curve? Yeah, that is probably the hardest part of growing your contributor base, whether it's kind of the environment that you're in or our environment. The example I like to give is, at CD, for example, is a key component of being able to run Kubernetes because it's a key value store for Kubernetes. But that also means it's basically a database, right? And not a lot of people have skills to contribute to what is essentially database technology. So they constantly struggle with getting new contributors because it takes someone with some specialized expertise to do that. So I think to the extent that you can reach out to people that have that expertise and try to talk to them, reach out to, in our case, a lot of times we'll reach out to us, we'll reach out to companies, for example, and who are using a particular technology and say, hey, do you have anybody who can help us work on this since you're using this technology? But it's a problem that doesn't have a good solution. I wish I could give you like, this is what you need to do. But it's hard. That's probably the hardest part. Yeah, thank you. Other questions? I'm a maintainer of Apache Open, Apache Project, one Apache Project. And the problem is many maintainers are being less active these days. And I realize that many of them no longer work in this area. So in this sense, if you give me one advice about immediate action item, then what would that be? Yeah, I mean, I think it's, so this is a problem that a lot of communities are facing right now, where the maintainers are becoming less active, they're busy, they're burnt out. And I think putting more work on those people who are already just not able to do the work for whatever reason doesn't help. So this is where I think you really need to find new contributors who you can mentor to eventually replace some of those maintainers who aren't as active as they used to be. And this is something we're seeing in a lot of projects right now. So just having documentation for new contributors, that is the beginning of the action items? That's a good starting point. Yeah, better onboarding documentation and promoting the fact that you need contributors. So letting the people who are using the technology know that you need contributors and maintainers is one way that you can then start to recruit some of those people. Okay, thank you. Yeah, I think we're probably out of time. Is there any one final question? Okay, cool, it's great seeing everybody. Thanks for coming.