 Welcome, everyone. Thank you so much for joining me to talk about open source communities. I'm really excited to dive into ambassador and contributor programs with you today. So let me start off by introducing myself. My name is Caitlin Barnard and I work in developer and community marketing for open source currently at Kong. For those of you who might not be familiar with Kong, we help manage all of your API's and microservices through our open source API gateway. API testing and service mesh solutions. So prior to that, I was at CNCF where I worked heavily in the Kubernetes community and still do. I'm the co-chair for SIG docs where I lead the Kubernetes blog subproject. I also work from home with my favorite coworker Bruce. I always like to throw in a dog picture to help get everyone's attention, but I do hope you are a little bit more excited to hear me talk about work than he is. So today I'm going to be talking to you about the basics of building an ambassador program and a contributor pipeline from scratch. I will say a lot of the themes that I'm going to touch on today will be relevant no matter where you are in your community building process. So when it comes to community building, I very much believe that there is no one size fits all solution. So today a lot of what I'm going to be talking about is my personal approach to community building based on two examples of ambassador programs that I've run. Cloud Native Ambassadors and Kong champions. So Cloud Native Ambassadors is CNCF's program. It's currently at 106 ambassadors. The first time I did the talk, it was actually at 50 ambassadors. So I'm going to be referencing examples from the earlier days of the program. I also find that oftentimes this example can be a little bit intimidating for people who are just getting started with these programs because CNCF has experienced type of growth over the past few years and they have a pipeline of contributors from 19 projects now. So I'm also going to compare that to a newer program that I'm working on now, which is Kong champions. So we started this in May 2019 and are currently at nine champions across five countries. So let's say you're thinking about starting an ambassador program. When does it make sense? I oftentimes see leadership teams saying that they want to have an ambassador program, but they haven't really fully thought through the goals and how this fits into their overall community strategy. And that's a really difficult position to be put in as a community manager to have to manage those expectations, especially when it might not be the right fit for your business or your community at this time. So there's two indicators that I like to look at before I try to start one. The first is a clear path to contribution. So your contributor pipeline has to be really healthy before that can feed into your ambassador pipeline because most of the time these are the candidates you're going to be pulling from. So you really can't have active ambassadors until you have active contributors or users. And then the second is, do you have internal buy-in to support the program? Ambassadors require a huge amount of support and resources from you internally to make them effective, and is your organization willing to support that? Do they understand the value of the program? And then at the end of the day, do they care about supporting the community in that way? So I'm going to dive into both these indicators further, but I do want to first start talking about goal-setting for the programs because this is going to affect internal buy-in as well. All right. So setting goals for the program is the number one thing I like to do because it, one, ensures that it fits into our strategy. And then two, it helps get buy-in because that is what our entire team is then agreeing to work towards. So these can definitely differ between communities, but for me it's almost always these four. One, we want our ambassadors out in the community creating awareness for what the technology is. Two, we want them educating the local and global community on how to use the technology. Three, we want them helping to expand that contributor pipeline that we talked about by sharing their journey and helping others get started. And four, we also want them to grow personally and professionally by being part of our community because at its core, this program really should be rewarding to them. So now that we talked about high-level goals for an ambassador program, I want to take a step back and dive into that first indicator that I mentioned, which was your contributor pipeline. So contributor pipeline is a huge factor in the health of your open-source community to begin with, but it's also really difficult to build an ambassador program until this is done really well. So let's dive into how to build an effective contributor pipeline. The key tenet in a lot of the things that I'm going to mention here is really having a clear and accessible contributor documentation. So this starts with your contributor guide. This should really outline the ways for contributors to get involved and then what the entire contributor process looks like from start to finish. The contributors guide should also include a clear review process because the worst experience for a contributor is they do all the hard work of contributing something and then their issuer PR gets stuck in limbo for months with no answer. So the review process should be clearly documented straightforward. They should understand when to get a response to their contribution and then know who to ask for if they don't. There should also be a place for contributors to get help and ask questions if they need it. So this is something like a Slack channel or weekly office hours where they have that open line of communication to other contributors and maintainers of the project as well. And then finally, it's really important to make sure this is all in a central location in my opinion, something like GitHub, Confluence, whatever your central community hub is. There should be that one stop shop where any newer existing contributor can go to get that information. So once we have our documentation, let's talk a little bit about how to get new contributors into the project and there's two pieces I want to talk about here. So the first is overall project awareness. And this is where someone typically like myself in developer marketing comes in or individuals in DevRel can help with this and it's how to market your project to get more awareness. The project is most likely solving a problem in some way. So we tend to share that information through things like thought leadership, tutorials, partner webinars, meetups, conferences and speaking, stuff like that. Basically anything you would do to get a user is a great way to get contributors as well. And then partnering with relevant open source communities. So is your project written and go? For example, you can target go developers. Whatever relevant technologies you're leveraging, embrace those communities. And just to be clear, this isn't meant to sound like poaching contributors from another project, but more so expanding opportunities for them to get involved with other relevant technologies in the ecosystem. And these should also be communities that you're contributing back to. So for example, our engineering team at Kong contributes back to the projects that Kong is built on top of like Lua and Open Resty, but we do also get a lot of contributors from those communities as well because it's a shared technology that it's built on. And then the final piece here is recognition, but I want to get to that on the next slide. All right. So how to incentivize contributions and recognize your contributors. These people are really contributing their time for free. So how can you thank them and make them feel seen? And then similar to what I said with ambassadors before, give them the opportunity to grow personally and professionally. So at Kong, we have the concept of code contributors and non-code contributors. You might be familiar with this. If you've worked in the Kubernetes community before, we also talk about it this way. So code contributors quite literally contribute code to your project repo and then non-code contributors create content like videos, blog posts. This can manifest in ways beyond content, but for today I'm specifically going to be referencing content. Both are equally valuable to our community, but they do contribute in different ways. So we like to balance the recognition depending on the contribution type and then what is important to that type of contributor. So a few things here stay the same, but I'm going to talk about what we do for each. So for code contributions, we do things like contributor shirts. If your PR is accepted to the Kong repo, you will receive a custom contributor shirt. We do different designs each year. Contributor perks. So these are things like discounted access to Kong summit. We do special events at the summit itself for contributors. This is our yearly community and user conference. We also do first look at new features that are coming on our roadmap. Anything that can have exclusive access, we like to give that to our contributors first. Contributor spotlight. So this highlights contributors in our newsletters and blog posts. We'll eventually expand this to fuller interview styles like a blog post or video series on our ambassadors and contributors. We did a similar series at CNCF called Meet the Ambassadors. It's a video series you can check out. Hacktoberfest. So this has actually been a great way for us to get new contributors to the project and awareness. But we also do a fun piece of swag exclusive for the event each year as well. And then finally, a clear path to take on a larger role. So what does it look like to go from a contributor to a maintainer? What does it look like to go from a contributor to a champion? This really goes back to that personal and professional development piece on how you can give people a clear roadmap to taking on more responsibility. So then for non-code contributions, in my opinion, these are just as valuable as code because people are bringing in new users and awareness to your project. So for them, we do things like we have custom swag actually for non-code contributions. So we do like a custom gorilla for non-code contributions, a t-shirt for code contributions, and you can kind of collect them all. Contributor perks are typically the same, but contributor spotlight is a little bit different. So we amplify the content that they're creating on our channels, retweeting, cross-posting, guest blogging. Really, however, we can help get more eyes on their content. And then finally, the clear path to take on a larger role. So this might look a little bit different depending on how your project is set up, but this could be contributed, that contributor to Champion Pathway or a special role like, for example, in Kubernetes, the blog sub-project lead is a dedicated non-code contributor role. So now that we've got our goals, we've got our contributor pipeline, how do we start building our ambassador program? And there's four initial things that I like to do here. The first is reaching out to those people in your contributor pipeline. So not only are they your potential ambassadors, but you can find out what they would want out of an ambassador program and build around that. So for CNCF, we started with people already doing these things on their own and establishing the community. For example, hosting Kubernetes meetups and then built the program around that. For Khan, we started with our most active contributors and users of the project and then built around them. The second thing is do your research. So what are the communities exist in the space? What's working for them? What isn't? How can you differentiate? Because a lot of people are part of multiple communities and you don't want to have an exact replica of the same program somebody is already in. But you also don't necessarily need to reinvent the wheel for your program either. Third is establishing the value of being part of the community. So what value are you providing that those other programs don't? This isn't the ambassador's full-time job. So it's really important to clearly communicate what exactly it is that they're getting out of it. And then fourth, figure out how you're going to promote your program and get new ambassadors into it. So we already talked about contributor pipeline, but I also want to expand on that a little bit more. And that's to say, to reach out to people directly. It's a really great way to reach out to people who are beyond just your GitHub contributors that you know. So for example, we reach out to those users who have written blog posts on us or people who we meet at conferences who we think might be a good fit. People really like to feel special and invited. So it doesn't hurt to ask them because worst case scenario, they say no. And at the end of the day, it might provide some really useful feedback on how you can make your program more compelling as well. Awesome. So when first starting out, these are the key pieces that I like to put in place at the very beginning. So the first is a program overview. And this is similar to the contributor guide in the sense that it should outline what it means to be an ambassador, what do they get out of it, and how this benefits the greater community. And then located in that central community hub that we talked about as well. The second is requirements and expectations. As I've mentioned a few times now, this isn't their full-time job, but you should still set clear expectations prior to someone joining the program, whether that's you're expecting one blog post per quarter, hosting two meetings per year, basically how much time should they expect to be contributing to this role. And then what happens if they don't or are unable to meet those requirements at any point? Third is a code of conduct. So these people are acting on behalf of your organization and your project and working in a diverse community of individuals. So a code of conduct really helps set forth the values that you want your community representatives to adhere by and helps create a more welcoming community. So it also provides documentation in case a complaint is issued against an individual on how to respond appropriately to that. And then finally resources and training. So ambassadors need to know what they're talking about. We like to provide content for this in the form of slides, recordings, demos that they can use in presentations, as well as monthly calls where we help familiarize them on what to do with the technology and help train them on it. All right. So then there is some additional elements in the day-to-day management of the community. I'm going to talk through these a little bit more high level today than I typically do, but I'm happy to dive into these further if anybody is interested after this talk. So first is the application barrier, sorry, the application process. And what we typically do with this is figure out the lowest barrier to entry. So for us, it's a Google form, but keep in mind that can't be accessed everywhere. And if that is the case for the tool that you choose, make sure that there's an alternative process in countries where this might be blocked. So after that, then it's time to set up some review sessions with the decision-making committee and decide a couple of things. So how many applicants can you reasonably accept into the program based on resource and budgetary constraints? What are the admissions periods going to be for your ambassadors? And then what qualifies someone for acceptance? Because having these clear review cycles and requirements with status updates helps set up expectations for the community and then they know when to accept a response and what a reasonable acceptance period looks like. Onboarding. So I typically do this three different ways. One is with a detailed welcome email and this is everything that the ambassador needs to know to get started. So this is where you can reiterate the role, expectations and code of conduct. A monthly onboarding call. So this is just great to get some, not necessarily in person, face-to-face time, but talk to the ambassadors live, get to know them, do an actual onboarding call live over a call, and then onboarding decks. So it's a lot of information to take in up front, especially in an email. So I like to also reiterate this in an onboarding deck so ambassadors can go back and reference that at any point. Monthly ambassador meetings. So for CNCF, we used to do these as exclusive for ambassadors where they're a mixture of project updates as well as knowledge share. So for example, a couple of ambassadors can come on and share meet-up best practices. For Kong, we do them a little bit differently. They are not specific to Kong champions, but they are actually for the whole community. We do them one of two ways. So it's either a demo from community members on open-source technologies outside of Kong or a Kong project update with demos from our engineering team and sneak peeks on upcoming releases. We're also working in a global community, so I like to make sure that we have clear channels for communication. They're not just for updates specifically, but also so ambassadors can connect with each other as well. So things like private and public Slack channels, an email alias, a GitHub repo for info that requires more transparency and accountability within the community, and then discourse for things like evergreen questions that impact other users as well. And then finally, special perks and benefits of the program. We talked a lot about incentivizing your contributor pipeline, but I'm also always thinking of ways to remind our ambassadors that we really appreciate what they're doing for the community. So this is things like ambassador swag. We make sure ambassadors have custom swag for all the events that we're at. At CNCF, we used to do front row keynote seating for ambassadors, face-to-face meet-ups. Anytime we are at an in-person event, things like a happy hour or breakfast to give them that VIP experience whenever we're face-to-face. At CNCF, we had free access to exams and workshops so ambassadors can take the CKA and CKAD exams at no cost to them, and then meet-up reimbursements and sponsorships if that's something within your budget. So I'm sure this list will continue to grow, but this is just a snapshot of some of the ideas of more tangible perks of these programs. So finally, I want to talk a little bit about measuring success because at the end of the day, what the higher-ups care about are what the business impact of the program is. So the problem with that is oftentimes developer advocacy and ambassador programs can be really hard to communicate the impact of. So I like to specifically measure the impact of each program. Another thing I see, it's oftentimes really easy to measure output. For example, the number of blog posts put out by an ambassador. But I personally prefer to measure quality over quantity. So a few examples of this are the growth of the number of ambassador applications and then how many of those are converting to actual ambassadors. Number of unique blog post views on content written by ambassadors. So basically how many individuals are you reaching with that piece of content? Meet-up attendance. It's almost as a CPM model, for example. So how much did it cost to get in front of X number of people? Which kind of math-wise looks like the cost to send the ambassador there divided by the number of people who attended. I also like to set a baseline with this compared to other events like trade shows. You probably have this number for trade shows as well already. And then finally, downloads. This is really my ideal way to measure if you do have a setup in place to attribute your marketing efforts to downloads. Your marketing or community efforts. But this is really difficult to do in open source right now. All right. So with that, that's all I have for today. I know this is a lot of content to go through in the last 20 minutes. So I'll make sure to put the slides up later with more details after this. But we have a few minutes left now if anyone has questions. All right. So we have one in here. This is a great question. So how effective has Hacktoberfest been to getting permanent contributors? And this, I will say we definitely have a spike in contributors during Hacktoberfest. And I don't know the exact numbers off the top of my head, but you know, not all of those are going to stay around as permanent contributors for sure. But happy to look into what the actual number is on that for you. Awesome. So another one in here is recommended tools for measuring success. So my advice here is actually use whatever you have in place already. You know, assuming you might already have things like Google analytics, some type of social media management tool. I try to keep it really, you know, just really in line with what other members of my team are using. So we're kind of speaking the same language. Another question in here is for those of us who are just in the beginning, what should be the main focus? So in my opinion, what that should be is figuring out, you know, kind of who your star contributors, contributors are already. So who are the people in your community that you want to build this program around? And sorry, I'm making the assumption here about ambassador programs. And then also researching the other programs out there. So what are the, you know, are there relevant technologies in your space that already have an ambassador program? How can you kind of differentiate and expand on that? Well, I think that's all we have right now. Thank you all so much for joining me today. Like I said, I will put the slides up later with more information and then I will be over on the Slack channel if you have any more questions. I'm also available on Twitter if anything comes up after this. So thanks everyone.