 Okay, thank you everyone for coming. I am here to chat about how to have better conversations about what your open source project is and what it does and why people should care about it. So let me start with a question. Has anybody ever come across an open source project, not your own, hopefully, and just not felt, like read through the website and not felt like they understood anything about what it was doing? All right, how did that feel? We got some thumbs down. All right, so my first, I have two hopes for that situation. The first hope is that it wasn't actually too frustrating and that you ultimately figured out whether or not this open source project was gonna do what you wanted it to do or not. And I also hope that you thought if you have your own open source project, I hope nobody has that experience with my project. So here's why. There's really two reasons. One, more self-interested than the other. So let's start with the less self-interested. I think this is really about respect for the overall open source community. Any individual project is gonna have some people it's appropriate for and then a whole host of people who it is not appropriate for. We don't wanna waste any of those people's time, not the people who we do want to become users of our project and we also don't wanna waste the time of everybody else either. So when somebody encounters our website or read me, we want them to be able to really quickly understand which category they fall into, the people who should go away quickly or the people who should stick around and figure out exactly how this open source project works. There is a more self-interested reason why this matters and that's because most people who maintain an open source project want to build a vibrant sustainable community of like-minded people who are working towards similar goals. And in order to do that, you need to make sure that you are actually attracting people who have similar goals. And if people don't really understand exactly what a project is about, you have two risks. So one risk is that people who do in fact have really similar goals and who this project could help will go away because they didn't understand what the project was when they first encountered it. And then the second and related thing is that if it's fuzzy, what exactly this project is all about, you might attract people who have sort of adjacent goals. They're sort of on the fringes, but they're not really rowing in exactly the same direction and that will dilute the power of your community if you are attracting people who are maybe not really supposed to be there. All right. So how do you know if this might be a problem? The first sort of warning sign that you might be confusing about how you're talking about your open source project is really kind of straightforward. If you're having a conversation with somebody who you think should be your target user, should be in your audience, I'm not talking about when you go talk to your mother-in-law about what you do for a living. But if somebody should understand what it's all about and they don't, and it takes them 15 minutes or it takes them half an hour of conversation about what it is that your project does, that's a sign that maybe the problem is with you, with your project and not with them. Another sign is if they ask weird questions and weird questions is just questions that you think should have an obvious answer. Like if you really understood what this project was, you wouldn't even have to ask this question. And then also the competitive alternatives that they bring up makes sense. So when somebody asks, well, how does your project compare to X? That X should make sense. And one of the most common things is that people will bring up as competitive alternatives. So alternatives to your project, things that are actually complementary. That's a really common point of confusion and really important for people to understand what exactly how your project fits into that equation. And before I go further, I wanted to talk about why this happens. It happens because when you start something, when you're involved in it, immersed in it every day, it becomes so obvious to you what your project is, why it matters, what it does, that it can become really hard to figure out how to best articulate that because you take so many things for granted because you know it so well. And that's the core reason why this ends up happening. All right, so then how do we get people to that light bulb moment as quickly as possible? There's really four steps that I'm gonna talk about. One is knowing exactly who you're talking about, so being really clear about who your target user is, your audience. The second is being very specific. Third is using terms that people already use and understand. And then the last one is to focus on outcomes, that this is related to pain points. So focus on the pain or the problem that people are coming to this project to solve and the outcome that they're getting from using it. All right, so what do I mean when I say, who are you talking to? What are the things that you need to know about these people? The first and probably most important is why are they looking for an open source project? What pain are they experiencing that's making them look around at projects and look for something that's gonna solve their problem? What is that pain? And then what do they want? What do they want the outcome of working with, any particular open source project when they come to you? What's the outcome that they're looking for? And then you also wanna understand what else is in their stack? What other technologies are they using? What are they already familiar with? Then you also need to know what constraints they work within. And then lastly, what are the defining characteristics of the application? So basically what you're trying to figure out is what are all the characteristics of people in this audience, of the application that they're working on that you can talk about and that are gonna allow people to immediately see I should be in the group of people that do use this project or I shouldn't be. This isn't right for me. All right, the next thing is to be specific. Focus on pain points and outcomes. Articulate very clearly who is gonna benefit the most. Be specific as specific as possible. And in fact, I would say err on the side of being too specific. Error on the side of forcing more people out than in when in doubt. So I wanted to give you some examples of this that I have seen out in the wild. So an example of something that is not very specific is saying we revolutionize data storage. First of all, there's a couple of problems with this. Data storage has a lot of meetings. There's a lot of different kinds of data storage. So what kind of data storage do you revolutionize? And in fact, a lot of data storage, we do not want to be revolutionized because we would like it to just be stable and not go anywhere. So that already could be problematic, but then there's also the word revolutionize. What does that mean? What exactly is it about data storage that you're revolutionizing? Are you making it cheaper? Are you making it faster? What is it that doesn't, when you think about it that word doesn't really mean anything. So then here's, this is actually a real life example. What this project actually did was increase the speed of containerized IO bound applications. That is so much more specific. Allows people to easily see, okay, this is something that's for me or that's not for me. If you care about cost, for example, that's not the revolution that we're talking about. If you're not working on an IO bound application, this is not the data storage that we're talking about for you. So go use another project. On the other hand, those people that do want this outcome, they can immediately see that this is the project that's gonna work for them. I like to, on the second example, I always like to use security as an example because there are offenders in this space. Security is very complicated, many facets, there are no silver bullets. Most people understand this and yet there is a lot of projects and people out there that talk about very generally, we're going to improve your security. We're gonna secure your cloud environment. Well, that doesn't actually tell us very much about what that particular project does. There's so many pieces of the puzzle and there are so many different scenarios under which you might want to increase your security. You need to be specific so that the user, the potential user understands, is this a piece of the security puzzle that I am missing and that I want? Would this even help my particular situation? So, and then I have another, an example of how this could be much, much, much more specific if you talk about mitigating risk from software supply chain vulnerabilities, if you talk about a specific cloud environment, a specific type of cloud environment in AWS, if you talk about a specific type of workload, PCI compliant workloads. All right. Next, I do think it's important to use well understood terminology. There are a lot of people who like to talk about how innovative their projects are. Lots of projects are very innovative and that's fabulous. Nonetheless, they're probably not so innovative that it is impossible to find a way to describe it using terms that people already understand. The problem is that if you get too creative with how you describe your project, people just don't understand and they get really confused and it doesn't get anywhere. It doesn't do anything for anyone. Save your creativity for some other endeavor. So here's some examples of that. Again, these are real examples that I've seen. The first one, Continuous Operations was something that I saw and the people behind this project thought that it was a great name. They had sort of a rationale for it for why this platform was a Continuous Operations platform. The problem was that nobody understood what that was and so people kept just sort of being blank and then they had to describe what exactly they meant by Continuous Operations and then we're like 20 minutes into the conversation and we haven't even talked about what outcome you would get from using it. So instead they switched to call it a Cloud Native Application Management Framework which everybody understood. It combined terms that people understood already and then they could start having real meaty conversations about why this platform was interesting or why this framework was interesting. Another example, Pre-Production Application. Health monitoring changed to a change validation platform. Again, had that same transformation where people went from like not understanding and having these really sort of convoluted conversations about what exactly do you mean by Pre-Production Application Health. I don't understand that to just getting past and allowing people to make sort of implicit assumptions about what it meant and what sort of outcomes they were gonna get. All right, speaking of outcomes, you wanna focus on outcomes and you wanna be clear about outcomes. So we are talking about open source projects. Eventually people are gonna care how you accomplish these outcomes but at the moment when somebody lands on your website they don't care about the how, they care about the what. They wanna know what you do because if you don't do what they want you to they are not gonna care about the how, they're just gonna go somewhere else. So be clear about how your project solves the audience's problem. Here are some examples that I have again seen in the wild that are outcome-based. The outcome that you get after you use this project, never write another YAML script, eliminate deployment delays from broken dependencies, speed up iteration on your ML applications. After we have seen those on the website and we're interested because that's the outcome that we want, that's solving my problem, then I'll start to be interested about and how this is accomplished. All right, so how do you get here? What if you don't know where to start? Some people are not actually sure, for example, who their audience is. So they're not even sure what sort of outcomes they would want from using this project. Well, most projects do have a couple of true believers and that's where you wanna start. You wanna think about who are the true believers in this project? Who are really active? Who are the people outside of the maintainers who are really active, who are contributing back and who are really key members of the community? What characteristics do they share? Think about that even before you talk to them, but then you need to talk to them and you need to ask them, hey, what are you working on? Why do you even like our project? What's so great about it? Sometimes you'll have these conversations and it will turn out that the people will love your project for something you didn't even expect that they would even have noticed. And that's really important information and you won't find it unless you actually talk to people. It's important to talk to people, though, who are true believers. Don't just talk to everybody, you won't get this information in a survey because you wanna talk to people that really love your project and figure out what characteristics they share and you want to eliminate everyone who's just sort of on the fringes and isn't really that in love with your project. So when you talk to your true believers, it's gonna allow you to isolate what outcomes they were looking at, what value they get out of your project. And this is how you're gonna get to the outcomes that you're gonna focus on when you're talking about your project. And then one of the other questions that you wanna talk to users about and ask them is how in their own words would they describe your project if they were talking to somebody else? One of their colleagues. You don't wanna just take that verbatim, but you wanna use it as a starting point to come up with between two and eight words. I know I said five to eight here on the slide, but really if it's the shorter the better to describe your project that is very specific as specific as possible and that hints at outcomes that you provide. Use the words of your true believers but only as a starting point and you can sort of mash together. They won't all have exactly the same answers for you. So mash them together and come up with something that uses their words and really describes your project accurately. And then what do you do once you've done that? The whole point of being able to describe your project more accurately of course is to be able to attract a larger community. To be able to build a bigger community that's sustainable. So spread the word. The first step though is just to update the basics. This is like not really even spreading the word but just update your read me, update your website. Basically your read me like the first description should be that eight or five to eight word description of your project that you came up with that specific should be focused on outcomes. And that same thing should be as sort of the title on your website. And then you also want to have the outcomes. If you think about like scrolling down on your website, what outcomes are you gonna get from using this project? So that when somebody comes to the front page of your website, they can see all of that. They can see exactly the specific thing your project is and the outcomes they'll get from using it. And then we've also clarified what the characteristics are of your audience. And if you wanna build an outreach strategy, wanna focus on the these characteristics of who your audience is and figure out where they are. And that is the place that you wanna be when you're talking about your project. Five minutes. So we have time for questions. And if anybody wants to send me a question later, you're welcome to do so. But I'm happy to take questions now too. I definitely find that they're updated. I mean, it depends like there's so much diversity in open source projects. And it depends what the goals are. But it, you know, when one of the main goals is building community and people are really serious about it, often actually there's like some level of iteration that goes into how the project is being described. I would probably err towards the side of being more specific. I mean, it depends a little bit on what your goal is, but not every single person in the world is gonna come to your website and understand it. And that's how it should be. So you do want to be specific so that the people who you want to understand do. And if, you know, if you've determined that you want, you know, a certain level of like less technical people to be able to understand your project for whatever reason, then absolutely, you know, make it tailored to them. But never expect that every single person is gonna understand your website. Okay, back there and then we'll go to the front. You know what, I fixed it. Thank you for noting that, but I fixed it. Visuals are awesome. I would say, you know, you have to be strategic about how you use visuals, because there's always situations where they're more or less appropriate. But yeah, you know, I do think you have to be clear. It's like you have to be clear first on what it is you're trying to illustrate. And then you can think about how you're gonna illustrate it. But yeah, absolutely, there's a lot of situations where visuals will tell a better story than that's a good question. That's a good question. I've always thought of this as being like a relatively human touch, just because there are so many variables that are fairly human, like understanding how people react to a certain description versus other descriptions. But yeah, I don't know of any tools. I would actually be really curious to hear about any tools that would help. We have time for one more question if anyone has any. Okay, let's do it. Thank you, everyone.