 All right, everyone. Let's get started. So this is the struggle of getting an open source community off the ground. I'm Alana Burke. Alana rhymes with banana, but please do not call me Alana banana. My pronouns are she, her. And I currently work at Amaze.io doing documentation, community management, and developer advocacy. You can find me on Twitter at my personal account, abrx626, or at Use Lagoon, which is our open source. Ah, I touched the cable. OK. Use Lagoon, which is our open source product. And Amaze.io, what happened? And you can also find me on the Drupal Slack at Alana Burke. So today we are going to talk about creating a community. And as I go through this talk, I will answer some of the questions that I ask with anecdotes about my experience building a community around Amaze.io's open source application delivery platform, which is called Lagoon. So for background, just so you understand a little bit. So Amaze.io is a hosting company. And we use Lagoon, the tool that we've developed to deploy and manage our customer's sites. We also maintain Lagoon specifically as an open source product for anyone who wants to use it themselves without our help. So this year, I have been working to plan an official community launch around Lagoon. As our current community is kind of spread out over tons of private customer channels, rocket chat, Slack channels. There's a public rocket chat channel. There's a channel in the Drupal Slack. So we want to try and bring all of those together. And while we'll be talking about some of the issues that are inherent in open source ecosystems, most of this advice is applicable to pretty much any kind of community build. So we're going to break down the community building process into three main steps, planning, launching, and nurturing. So how do you plan a community? There is a lot of consideration that goes into deciding how to plan and build your community. You want to make sure you sit down and really think about all of these things before embarking on your community building journey. Research, what a community will bring to you, your users, your project, and your organization or company. So we're going to ask ourselves these questions. Why do you want a community? So in our case, like I said, we need a space to connect all of our open source users and all of our paying customers. Like I said, we have a rocket chat channel, but nobody really uses rocket chat. And it doesn't have as much reach or engagement as we wanted. Most customers, they just stay in their own channels, same with the Drupal Slack. So it's great to have that there, but we do a lot more than just Drupal, so we're not reaching people outside of the Drupal community. So what do you want your community to be? What kind of community is it going to be? Where will the community live? What's your gathering space? Do you want a forum? Do you want to work in an open space like Reddit? Do you want a chat platform, GitHub discussions? So we chose Discord because we felt that it's a platform that many of our audience already uses. So that makes it a really low barrier to entry. It's also similar to many other chat platforms, making it easy to use, even if you're not familiar with it. We're also going to continue using GitHub because anyone who is contributing to the project or just using it, we'll have to check out the GitHub repo anyway. So that's a place that there are already going to have to be. And go find out where your community is already. What are they using? Where are they gathering? Make it easy for them. Are you going to have community roles or are you going to let that happen organically? For example, the Drupal project doesn't really have any official community roles, but it allows all of our members to self sort into where they want to contribute. And leaders tend to just naturally emerge. Community members benefit from being a part of this community. How are you going to empower them? How will the project or organization benefit from the existence of this community? As an open source project, we want to get as much influence and as many contributions from the community as possible. Making it easier for the community to be a part of the project is ideal for everybody. The more diverse your community members are, the better and stronger your project will be from their input. What goals do you have for the community? What do you want to accomplish by creating this community? And what is the value of this community? So a lot of what we do is pretty specialized knowledge. It can be a really steep learning curve, learning Kubernetes and all of that kind of platform management. Allowing our users to connect with other users for troubleshooting and issues will allow them to share their knowledge without relying solely on us for support, especially as it tends to be the same kind of things that trip people up. So ideally, as users start to support one another, our support team will be able to focus on the bigger issues that crop up and spend less time on minor issues. We also, at Amazio, we don't support the actual applications that people use on our platform. So we deploy your Drupal site, but we don't fix it or troubleshoot it or manage that. And customers, again, tend to run into similar issues with their applications. So letting them bounce issues and ideas around amongst themselves gives them another layer of support. It also gives us an easy way to communicate with all of our users, ideally in both directions. We can share updates and changes and hear about their issues and ideas for the platform. We also wanna know what kinds of frameworks, organizations, or sorry, applications and languages users are interested in and what do they wanna see supported on the platform. So one of the things we do is we create a lot of templates and examples for various frameworks like Drupal, WordPress, Node.js. So when someone says, hey, do you support this framework or organization? We can get it working and put out an example for them. How are you going to define the community? So is it defined by the people? In our case, it is. It consists of everyone who uses our open-source project in any capacity. Or is your community going to be defined by the space that it's in? So we plan to launch a space for the community and it gives us a place to gather, but that's not going to define our community. Is it the work that defines your community? Are you all working towards the same thing? Or is it some shared goals? Your shared goals may be very straightforward. Generally, everyone involved with using a specific product will be invested in its success. Whether you're on the team who built it or someone who is using it, you obviously want it to be successful and flourish. And who is responsible for your community? Do you have a community manager? A DevRel team? Without a dedicated person, communities often flounder, especially when things get busy. So I'm our community manager and developer advocate and I sit on our product team. Also, you don't want to start from scratch. If you build it, they may not come. Utilize your existing community in whatever form that takes. So if your community already gathers somewhere, don't make them go somewhere else. If you have, say, an active Slack channel where all of your users connect, don't decide to shut that down and redirect them to a forum. It can be a bit tricky when you're in our situation and you're trying to condense disparate spaces where your community is currently gathering, but pay attention to what's already working and go from there. In our case, since pretty much all of our existing spaces are chat platforms, we decided to stick with a chat platform. And where is your community? Where do they come from? Are they customers? People interested in doing something specific like finding a new hosting company? Or are they a subset of another community? For example, if we only hosted Drupal sites, we would concentrate all of our community building efforts within the Drupal community. And don't forget to start with your current users and customers. Having a paying customer base means that you have an existing engaged user base. So while their paths may be different from our open source users, their goals and problems are largely the same. The planning stage will have you putting together several different documents. First up is our community strategy. So how do we draft a community strategy? Answering all of these questions will get you a great start on your strategy, defining your community, what your goals are, and how you're going to grow and maintain the community. The foundation of a successful community is a well-defined strategy that integrates social tools and methods with business goals and processes and aligns and organizations' needs with their members' needs. So how are you going to measure your success and growth? Is it the number of members, the number of interactions, maybe you're measuring your GitHub stars or something like that? Make sure you are measuring anything that you could possibly find useful to analyze your growth and success. So what's happening day to day, month to month? Are there numbers you want to hit, like pull requests or blog hits? Do you have a social media engagement goal? Are you looking for brand recognition? Number of users. Another way to measure is to ask yourself, what's going well? What's going poorly? What could you do differently? So consider both qualitative and quantitative measurements. So what is your gut telling you about the community? Is it busy and vibrant? Or do people seem kind of unengaged and disappointed? And don't forget that anecdotes are data too. How often do you have users say things like, oh, this platform is so easy to use. I love it. That's positive feedback that you can use to measure your success. There's also what is called pirate metrics or ARP. So these different, this weird acronym stands for awareness, which is general knowledge of the product and what it does. Acquisition, which is users coming to your site from various channels resulting in some kind of sign up. There's activation, which is product implementation. So for example, this could be your first deployment. Retention is continual use of the product. Revenue is paying for usage. So for example, becoming an Amazio hosting customer. Referral is referring others, becoming a brand ambassador. And finally, we have product, which is providing feedback or contributing to the product. So these are some other helpful ways that you can measure how things are going. And also, we use these metrics because ROI is not really a good metric for measuring community success. Measuring online engagements is much easier. Community is a thing that can be very, very hard to quantify and that's okay. So measure whatever you can and then decide which metrics work best for you. Also in preparing to launch our community and give this talk, I read a book that I think everyone involved in community building should read. And I'll share all my sources at the end. But the following quote is from the business value of developer relations, how and why technical communities are the key to your success by the very amazing Mary Thangval. So here's the quote. The inherent challenge is that when you're measuring community, you're trying to measure things that are mostly intangible. Community building is fundamentally about relationships. So how do you conduct a cost benefit analysis on a relationship? We don't go up to a friend and say, well, he took me a cumulative 68 hours of conversation, 16 cups of coffee and a birthday cake to go from being acquaintances to being a close friend as defined by the discovery of common ground and the mutual exchange of confidences. However, I have derived 1.21 gigawatts of emotional satisfaction, three new friends, eight book recommendations and three homemade dinners in return. Also, if I hadn't been at your house eating one of those dinners, I would have instead been on the freeway during the 13 car pile up last month. It just doesn't work like that. So finally in your community strategy, you wanna ask yourself, what will you do if you don't meet your goal posts for success? What if your interaction isn't what you hoped? How will you improve it? So we're taking a fairly laid back approach to our community, but we do have some scheduled interactions planned like community hours. And to foster more interaction, our plans are to have more topical or scheduled chats via either video or just text chat. Once your strategy is in place, you are going to want to create a roadmap to plan out what you're going to do and when. There's a few things to keep in mind here. You want to align priorities. What does everyone involved, what do all of the stakeholders want out of this? Is everyone defining success in the same way? Make sure that everyone is in agreement on the plan. You want to communicate value. Remind everyone via all of the questions that we've just answered. Why this community is important? And finally, organize your planning. Make sure that you're working with everyone who should have input. Like ensuring that you're working with your marketing team so that all of your messaging is cohesive. You also want to map community activities and initiatives to the key objectives that they're going to address. So for example, if you're planning out a Q2 roadmap, take a look at your organization's plans for Q2 or your OKRs or whatever way that you set goals within your company to ensure that your community plans are in alignment. Having an organized work plan also helps you decide what resources you need and when. So you're going to have to define and assign all of your resources. Who on your team is responsible for what? Once you have a roadmap put together, you have a few more documents that you're going to need. The most important thing is the code of conduct. But you're also going to want member onboarding plans and participation guidelines. Make sure that members know what is expected of them as well as what will happen if they break the rules. A code of conduct helps your community be welcoming, open and safe. This results in a more diverse and inclusive community where everyone feels like they can contribute and everyone knows what's expected of them. Also, online communities, as we probably know in the Drupal community, can be really tough because text is hard and tone is hard to communicate. So setting expectations of what your community members will and won't do and what will happen if they violate those guidelines will help everyone just sort of be on the same page. You also want to ensure that all of your writing is clear, concise and free of jargon. Online communities are international in nature and you want to be inclusive of everyone no matter their native language or their cognitive skills. You're going to want to have a clear read me or getting started guide to welcome your users as well as clear documentation for contributions. So what can contributors work on? A great thing to do is to go through your get issues and label them. Let people know which issues are for beginners, backend versus front end, code or documentation tasks. The more easily people can find a task they can do, the more likely they are to participate. Do you have things that people who are interested in your product but don't yet have expertise can help with? Maybe you have some files that need to conform to code standards or some front end styling work. Make sure that not all of the issues that you have require expertise. Otherwise, you're only going to have a community of people who are already experts at your product and you'll miss out on getting the feedback and interaction with your potential users or with inexperienced users. Our challenge is that developing Lagoon itself requires some pretty good Kubernetes and platform knowledge and there aren't a ton of beginner issues. So we tried to provide as many examples for supporting various frameworks we have and helping to create examples is a great way for us to get people to contribute. And you want to have a community onboarding plan for new members. This can be as simple as an automated message or a more involved introductory process. But it's important to make sure that you are welcoming and acknowledging new members so that their very first experience in the community is positive and it encourages them to stick around. So now, we have everything planned out and written down and you're ready to go. You have done the hardest part. But we need one more plan, your launch plan. How are you going to roll out your newly planned community? How will you get the word out? How will this be communicated to existing clients or users? Where will you go to connect with potential users? You want to make a splash, get attention with your launch. You only get to launch once. But you can also consider a soft launch before the announcement to see how things go. This is a route that we have taken with our Discord channel. And I'm glad we did because we wound up pushing back our official launch because our company had a really big announcement that had to go out the week that we'd originally planned to launch the community. So we decided to delay it so that we could announce our community without it being overshadowed. And finally, when you launch, you want to have rituals, things that happen at the same day and the same time, like community office hours or releases or meetups. Whatever you do, have some kind of a schedule so that people remember it and make interacting with your community a part of their routine. Finally, you need to nurture your community. I personally love plant metaphors for nurturing documentation and the same applies to communities. You have to tend to them, prune them when needed and help them to grow. So we do this by planning activities. Sometimes a community takes off and it thrives without any input or organization from community managers. But more often than not, it needs a little push to get people engaged and to keep them there. Keep things on your community calendar so that there's never a long stretch of time where you're not offering an opportunity for interaction with your community. Remember your metrics. What did you decide on when it comes to measuring your community? Keep going back to your strategy and to your roadmap. Your community may start to evolve over time and you want to remember all of the reasons why you planned and started it the way you did. Some things may continue to work, some things may change, but your strategy will help guide you no matter what happens. And then finally, give back to the community. Hold workshops, sponsor events, invest in the community so that they know you're really in this. Especially in the open source world, people are much more likely to join and engage in a community run by an organization that they're already familiar with. So start a mentorship program or even an internship. Establish yourself as a good citizen in the larger community from which you pull your members. Contribution to open source projects can be a big ask. So remember that make sure that you are doing your part to support and uplift your community members however you can. Always remember that by asking for open source contributions, you are asking people to do work for free just for the betterment of your project and its users. Okay, I wound up going through that a little faster than I anticipated, but here are the sources that I used. If you are planning a community or you're in the process of it, like I said, you absolutely have to read the, it's on the bottom here, the business developer relations. Also, I highly recommend the organization, the community round table. It's a fantastic resource for anyone working in community development. They have so much material, that's where the rest of these sources are all pulled from. And of course, in the spirit of this talk, don't forget to contribute back to the Drupal project. There is mentored contribution if you're new, as well as a first time contributor workshop. These are great examples of member onboarding. You can also join in the general contribution any day of the conference or all day on Friday. I would love it if you can fill out the feedback form, which you can do either, I believe, in the app or from the session page. And I'll open it up to questions. Anybody? We have time to go. Thank you. Hello, I'm Matthew. Do you have any advice for anyone who wants to build a community internally in a company? In a big company with multiple teams, working especially with Drupal, and some design tools that have been to use, have to be, excuse my English, have to be shared, and across multiple teams that don't have the same roadmap. And if there are some kind of advice, general advices are very useful there, and I will learn from it, but specifically in an open source environment in a company, do you have some kind of advice to scaffold the very first embryo from the community? So the general approach would be the same, no matter where you're developing the community, but if you're building an internal community, presumably this is something that you've already talked about and that you already have buy-in from, and you have a captive audience, so you don't have to worry about where you're going to find your community. So I think one of the things you want to focus on that I think can be an issue internally in companies is what tool are you going to use? What is this going to be? Is it going to be another Slack or Teams channel? Is it going to go into Confluence or a Team Wiki? What is it that you need and what is the goal? Is it just because you have a bunch of teams that don't otherwise connect? Figure out, you're sort of more problem-solving, I think, when you're creating a community within an existing company, so you have a problem that you're trying to solve, so I think I would focus it a little bit more on analyzing what already happened, what is going wrong, why is it going wrong, and I think that since you already have your community members, this is a place where I would probably try reaching out to them and saying, hey, this is the problem that we're trying to solve, can we help get some input, ask your coworkers and set up some little informational interviews and say, this is the problem we're trying to solve, if you're on team A that doesn't talk to team B and the goal is to get them together, why don't you talk to team B, what's holding you up? So I think I would focus a little bit more on the why and the problem-solving of things because you don't have to worry about a lot of the other things. Is that helpful? Cool. We are looking to build a distribution for the government, for the Dutch government, and I'm from a governmental company, but my question is, is it the best idea to start with a code base and then build a community around the existing code base to ask for input and stuff like that so that you can set the standards of the code or should we now already go meet all the companies that are using Drupal to build for the government and ask what are you doing, why are you doing it and start the community first and then the code base? I think that totally depends and you're gonna have to ask yourself some questions. Do you already have an idea of who your members are? Do you already have a group of people who are interested in this project and are motivated and want to work on it? Is this happening because a bunch of people came together and said, hey, we want to do that? In that case, you already have a community that's starting, so I would start with those people and then develop all of this, you're sort of scaffolding for your community and then work on the code base. But if this is sort of like a project that you've already started that you want to get people involved in or if you want, if you have strong feelings about how it should run or the leadership, then I think sort of starting with a code base and working on your community scaffolding afterwards so that you're the one that's establishing what's going on. That's how I would approach that. No, there really isn't any right or wrong way to build a community, which is why so many of these are questions that you and your specific situation have to sit down and think about. Why do we want to do this? How is this going to work? What are we starting from and where do we want to go? Hang on until it gives you the mic so we can get it on the recording. Do you think the roadmap is a game changer in building a community? I mean, I don't think you can really do anything without some kind of a roadmap. So if you just sort of launch a community and are like, okay, what now? Like, it's going to founder, you're gonna forget about it or it's going to just kind of die down a little bit. But if you've planned out, like, okay, we're gonna do this stuff and we're gonna try and meet these goals and this is what we want to see by this point in time, then you're gonna be motivated. And, you know, if it turns out that your community isn't turning out the way you want, you've already got these plans to say like, okay, well, we didn't meet this metric, so we're gonna try and do this and this is where we want to get to. And if you don't have that, then you're just sort of like, oh, well, our community didn't work. Like, what do we do? Do we just leave it there? Do we let it die? Like, how do we fix it? So you're sort of already defining how you're gonna fix it. So any advice of how to deal with the community that is dying and that need some actions to survive? I think what you would wanna do is take a look at what you expected and what's happening now and see if you can analyze what happened, which would help you see how to fix it. If you don't have a lot of insight there, then I would turn to your community members and engage them and talk to them and say, you know, hey, we created this community and you joined it, but now it's not really very successful and we wanna know, like, what would you wanna see out of the community? Like, you're not engaging, so how can we get you to engage? What is it that you want that we're not doing here? Thank you for the talk. Really, really useful. I'm coming from the local Gov Drupal distribution, which is a community that has evolved from people collaborating and some funding coming in from central government. I'm actually doing a talk on Thursday, growing and sustaining an open source Drupal distribution, so come into that if anyone's interested, but there's lots that you said that's directly relevant to us. However, it seems like you've planned a lot of it in advance. We have sort of stumbled across it, realized that we're growing a community, we need to nurture it and we need to find out how to do that. So lots of the stuff that you have mentioned, I've written down and it's gonna be directly useful. One thing you said was it's important to have a community manager, somebody who's actually kind of in the position to do probably full-time work, I guess, I'm wondering how, is that just one full-time person or do you have a number of people who are helping to manage the community and yeah, how much time is that, is that roughly? So yeah, we don't have a particularly large team, like we're about 30 some right now, so I am the only community manager and like I said, I wear a couple of hats, so I also do our documentation and developer advocacy and some things like that. So because we're just still sort of launching this community and it's not like it isn't anything big that's gotten away from us, we don't really need any more staff on that and I don't devote my full time to it, but I think when you have a bigger community and there's just sort of more work required to continue maintaining it, like if I got to the point where we were scheduling tons of events and doing tons of activities and things, then that would take more of my time and we'd have to talk about whether is this something I do full-time, do we hire someone else? And it doesn't always have to be a paid person. I mean, if you have a totally open-source community that's like Drupal, that's sort of developed without a company or an organization, I mean we do have the DA and we have, there's been various roles within the DA to sort of help the Drupal community along, but I think you'll find that there's gonna be natural leaders and people who want to help, so community manager as a role doesn't just have to be someone's actual job. It can be like, okay, so we're some of the most experienced people in this community and we have really strong ideas about how we want it to go, so we're the people who's gonna manage this community. Yeah, that makes a lot of sense. I would encourage people to take their bits of leadership, distribute that and facilitate it rather than necessarily centrally control it. And then the other thing you mentioned was metrics and so I guess I'm interested, how big is your community now? Is that one metric of what's your vision? Where are you going and what other metrics do you have for success? So we have not actually officially launched the community, like I said we were planning on it and then we had a bigger announcement, so I don't really have any, oh, sorry. So we don't really have any numbers there yet, right now it's pretty small because we, the big step that we need to do for launching is contact all of our customers and get them in. So we have quite a few of our open source people that we, and of course open source projects are a little hard to track because we don't know who's out there using our product unless they come tell us about it. So a lot of the people that we do know who are using it are already in our Discord channel that we told them about and it seems to be, compared to the number of people in it, I would say that I'm pretty happy with the current engagement, people are asking questions, they're starting to come and sort of troubleshoot. So I feel pretty good about how it's going and I'm hoping that once we do the official launch it's going to continue that way. Thank you. Oh, we've got one in the back there. Hi there, I'm community manager of an internal DevOps community in my company and just a question, do you have any experience with communities which are developing totally different roadmap that you expected or that you planned at the beginning? So problem solving or whatever they tend to is totally different of what you planned and what your metrics has been at the beginning of the community. That's not something that has specifically happened to me but I think no matter where you are in your sort of community journey there's never a bad time to kind of sit down and say like, okay, well, this isn't exactly what we wanted, so let's kind of start from scratch. I don't know if you sort of created a community without having this scaffolding behind it. I think that's the point where you want to engage your, you're the community manager, you want to engage maybe other people in your company or in the community and say, okay, we need to step back and make some plans so that we can kind of fix where this is going. We can figure out what went wrong and what we want to do to change it and how can we get this to what we want it to be? Like I don't think just because your roadmap kind of didn't work out the way it planned you can always just make new plans. Communities, I think people tend to sometimes think of them really rigidly like, okay, well, we started this community and it is what it is, but communities are just people engaging with each other and that's something that you can always kind of continue to shape and change and they should evolve and shape and change over time. If your community is exactly the same on day one as it is five years later, like I don't know that that's a good thing. I think that they should continue to evolve and be kind of an organic thing and all of this scaffolding is just to guide you and say like, okay, well, these are all the things we're gonna try and maybe they don't work so maybe we'll try something else. Anybody else? We have a couple more minutes. Nope. All right, well, thank you everybody. I will post my slides as soon as I am able and again, you can find me on Twitter and Slack and I am always happy to answer questions. Thank you.