 Okay, so my name is Matthew Ravel and I am someone who over the past 18 years has come to accept that I do marketing for a living. And I'm sorry about that, but that's just the way it is. So I work at a company called Hoopie where we do developer relations consultancy. We help companies to work out what it means to work with developers and how to do that in the right way. So I've been doing kind of developer community stuff professionally for about 12 years. There are companies like Canonical, Couchbase, Bashow and now work with a bunch of different companies. So that's who I am and that's how to get in touch with me, but I'll show that later as well. Okay, so in a lot of talks people who don't know quite what they're going to say will start with a dictionary definition of something or a Venn diagram. And so I thought I'd go with a Venn diagram because I want to talk about this whole weird relationship between marketing and community. And I appreciate that at Fozdem in particular that we're very much on the community side of things. And that's okay, that's good. But that doesn't mean that we have to throw away the good things from marketing. I've kind of come to think that really working with developer communities, whether you're doing it with for a company or for a free software project and whether it's with people who are paid to use your software or whether it's with people who want to submit patches or pull requests to your project, overall there are a bunch of things that we can learn. And it's kind of this weird mix of disciplines. So it's a bit business, it's a bit tech and it's kind of a bit of art as well. There's writing you need to. Sometimes it helps to be good at video editing. But also it's as well as being technically astute and able to maybe even if you can't write code, at least talk about technical issues in an in-depth and empathetic way, then it helps if you understand something about strategy, something about why what you're doing is important either to the business or organization that you're involved with. It doesn't have to be a business in terms of a company that's making profit, it could be the Apache Software Foundation. So running developer communities is kind of a plate spinning job that involves all of these different things, mostly I think marketing and technical astuteness. And even though particularly going back to my early days in the free software world, marketing was a bad word as Leslie hinted at. And it was something that you wanted to avoid. The marketing team were the people who sold unrealistic dreams to people. Whereas we in the free software community were looking for reality. We were looking to deal in practical benefits in changing the world through code. And yeah, okay, some of that dichotomy still exists. But there's this really good phrase which I'm sure you've all heard. And if you haven't, that might be because it's more UK centric than I realize, but it's don't let the devil have all the best tunes. Even if there's something out there that is associated with marketing and you feel uncomfortable about marketing, it's okay. We can borrow those good things because, I mean, there are ideas that don't fit into this, but a lot of ideas are kind of neutral in terms of they can be applied to good things or they can be applied to bad things. So let's learn from marketing. Let's apply the good things from marketing to what we do as people working in free software communities, maybe API and user communities, whatever it is. But develop communities generally. So you might be thinking, what can we learn? There are, I think, obviously a lot of things we can borrow from marketing, but I think there are four main ones that are interesting to talk about. One is about understanding where we are. And I'm gonna go into this, but a lot of the time we just kind of jump into doing things because they look like things that we've seen other people do. And obviously that has a name, Cargo Colting, and we see a lot in software projects and we're no less guilty of it in working with developer communities or free software communities. So it's important to understand where we are because that gives us a starting point for knowing what to do next. And then knowing who you're best to work with, particularly when you're doing this in your spare time, working with communities is a time limited and resource limited thing to do. And so it's best to think carefully about where you can have the most impact. And in doing that, you are able then to make the best use of your resources. Creating a strategy, once you know where you are and who you want to work with, how are you gonna make this a worthwhile enterprise? How are you gonna reach those people? How are you gonna get from the place where you are now to the place where you want to be? And then something that is hard, measuring and reporting. How do you let the organization, whether it's your free software compatriots or it's your employer, how do you let those people know what you're doing, whether it's working and how you're honest about the things that haven't worked so well? Now, we haven't got all day, we've got 20 minutes remaining or so. So I'm gonna knock off those two and we're only gonna talk about the first two, which I think are a really good starting point. And the aim here is not to give you a playbook for how to go and do this, it's to give you some ideas for how you might want to get started with some of the borrowing from marketing stuff. So before I go any further, just get an idea of who's got what experience. Who here works professionally? Who is paid to do some kind of developer community work? Okay, and who does this because they love it and it's part of their free source and open software contribution to the world? Okay, cool. So of the people who raise their hands, we're roughly 50-50. And I think that the things I'm gonna go through here apply equally to both. The interpretation and the way that you use them are gonna be slightly different, but they're still useful. So number one, knowing where you are. Now I'm not really one for Googling fancy quotes off the internet, but this one is quite useful from Sun Tzu and The Art of War. Victorious warriors win first, and I don't wanna look at everything as a war. But the idea is that if you plan well, then you've already done half the job, if not all of the job that you're setting out to do. You wouldn't start a journey without knowing where you are, unless you're in very unfortunate circumstances. So you generally think, I wanna get to Amsterdam. I know I'm in Brussels. Well, that being in Brussels defines 90% of how I'm gonna get to Amsterdam. And in marketing, people talk about situational awareness. They sit down and they plan not what they're going to do, but how to understand where they are and what's already happened. And they generally use a very light framework for this called the five C's. The five C's are your company, your competitors, your customers, your collaborators, and then the general climate within which you're operating. I didn't mean to make that look like a target, but it does, so I see. But the thing is, community is not marketing, and don't let anyone tell you it is. Community is something of its own, and so we have to approach this in its own way. And I mean, okay, I changed the colors a bit, so it looks a bit different. But really, actually, the key thing is that I don't think that at this stage, in a community setting, we should be thinking about customers. I think really, more than anything, we should be thinking about product. And this is perhaps one of the differences between marketers and developer relations or community people. Is that in marketing, like I said, you're selling a feeling, you're selling a dream. You're trying to paint a picture of what life would be like if only you bought this thing. Whereas in developed communities, in developer relations, what we're looking at is being honest brokers of saying this product or this software project that we're interested in can do these things well and these things not so well. And so that's kind of a good starting point. We can worry about customers and things like that later. So why haven't I included community? Because that's got to see, why not there? Well, community kind of falls under the climate within which you're operating. And because it's the overarching thing that we're interested in, I haven't called it out as a particular point there, but don't worry, we will cover it. So thinking about product, when I say product, I might mean just that Git repo that you and your friends are working on. Let's make product and project interchangeable for now. I know that they're not, but just for the purposes of this talk. So thinking about product, the first question you want to ask is, how does it change the world? Now, if anyone's getting a slight, sticky feeling of, my God, Silicon Valley, don't worry. I'm not trying to say that we should be saying that we're setting out to change the world through APIs that make it easier to do HR or something like that. What I'm saying is what would not happen in the world if your project didn't exist? It might just be that it's scratching your own itch. Or it might be that you are looking to reach vast numbers of people and do something big in the world. But either way, you've got to be aware of what it is in the world that you're trying to set out and do with that project or product. Next, what are the positives? What does it do well? Or what do you hope it will do well once you've reached a version of 1.0? What are the negatives? It's really important to be, like I say, an honest broker. You've got to be upfront about what it doesn't do well. Because if you go in and do the marketing thing of trying to sweep that under the carpet, developers will not trust you. The community will not trust you. You're asking people to invest time and faith in what you're saying to them. So be honest. And then the legacy of your project or your product. And we'll talk about this a little more. What has happened before that will impact how people view what you're saying to them now? Next up, you need to be aware of the competition. And so I appreciate that in a free software context, the word competition may not seem appropriate. But let's talk about not them as commercial competitors. But these are people or projects that are competing for space in people's lives, space in people's minds. So if your goal is to recruit contributors to your project, what else could they be doing other than contributing to your project? So let's think of competition in fairly broad terms. So again, we're going to ask those same questions about all the projects or products you think are for whatever value of that term competing with your project. But interestingly as well, I think you should look at the market. And again, I'm using commercial term, but we might mean community there rather than market. But each project that's doing the same sort of thing as yours will have a place in people's minds and play a certain role. So if we're looking at more traditionally commercial stuff, there would be a market leader. If you think of no SQL databases and you probably think of MongoDB, there'll be a market challenger. This is the company or the project that could topple the leader and he's doing lots of great things and getting lots of mind space from people. Is mind space a word? No, it's not. What I'm thinking, people are thinking, mind share, that's it. Thank you. Then there's a niche player. So you could have said that in the world of Linux-based or GNU Linux operating systems, there may be core OS was a niche player. So that gives them certain different characteristics and different ways you should think about them. And then there's often that company that is a shooting star. They've got way too much VC money or they're an organization in the free software world that gets lots and lots of visibility and maybe they're burning through good will or rather than good money or bad money. But either way, they're burning through resources and they're getting lots and lots of attention. You know it's not sustainable. They'll probably be gone in a year, but there are problems for you right now because people are thinking about them instead of you because they're buying up all the mind share. Then your company, so in free software terms this could be your company or organization, however loosely termed that might be. You need to start off by thinking about what is it that your company or organization is setting out to achieve in the world. Because if your goals aren't aligned with that, then you're wasting your time and you're creating a lot of friction. And so if it's within a broader free software foundation, then and your goals are not aligned with that foundation's goals, you should consider where in the world you should be. You know maybe you should be somewhere else. If it's within a company, then you've probably got to realign what you're doing rather than expecting them to do so unless you have a great deal of influence. What about culture? What is the culture of your organization? Is it very slow moving? Will it be hard to get things done? Is it seen as very conservative? Or is it very quick to get things done? Or is it one that welcomes everyone? Or is it run by a benevolent dictator for life who is a little bit angry and won't let you do the things that you need to do? Speaking of which, there are two people there who had very different approaches to what they did. But ultimately they both became seen as the figureheads of their company and they both had a huge influence on it. So if you have a person like that at the top of your company, then beware that that's going to, or your organization, beware that's going to really influence how the world sees you and what you can do within the world. The legacy is more than just people. If at some point your open source project kind of named itself similarly to another database project or something like that, sorry I didn't say database meant, sorry I'm thinking about couch DB and couch base. You know, it happened, right? And it annoyed a lot of people and as someone who used to work at couch base I dealt with that all the time. So you need to think about the ways that your organization, your project, your whatever has upset or delighted people in the past because again that will affect where you can go from where you are. And then the broader climate, even in free software world, you know, we need to think about things like, is the economy tanking? Has a very big company just decided that all of a sudden they love free software? Has another very big company just acquired one of our competitors and oh my God, they're going to put all that money into it and what do we do now? Or are there things like, you know, the flavor of the month, you know, is Bitcoin the thing right now? Is, you know, before it was containers, before that it was no sequel? I mean, there's always something, right? So you've got to think about the broader climate within which you're operating because that will affect how people see you, it'll affect your opportunities and it'll affect the way that you can reach broader communities. Collaborators, especially important for open source software, right? So your project sits there in isolation. Hooray, no it doesn't. You have upstreams who feed into you and then you have downstreams that you feed into. So if you have bad relationships with your upstream because you're not committing your changes back upstream, well that's bad for you ultimately, it's bad for the community and it's bad for your relationships with people that you might want to get to contribute to your project. If you have bad or good relationships with your downstream, then ultimately it affects how you distribute your project. You know, you might not be writing code because you care about anyone else using it, that's fine. But if you do want people to care about it, you have to think about distribution. Okay, point number two, this feeds on from climate. This is something that marketing people talk about all the time, targeting. And I think I have very little time so I'm going to think very quick. Five minutes, okay. So this is something I like to trot out all the time. There is one developer community in China called the CSDN and it has 48 million registered users. You might see stats saying that there are 18 million software developers in the world. No, not at all. So with that bearing that in mind, it is not possible to target all developers, all right? Whether you're saying you want to get people contributing to you or you are saying that you want to go out there and sell your software to people, you have to think about what specific people you're trying to reach. So let's think about motivators. What things motivate people towards your project or your products and what things drive them away? So let's have a look at how to understand the motivators related to your project. First one is around the technology. I'll go into this in more detail in a moment. Then the individual person themselves, the developer or the contributor, the company or organization at which that person works or is involved in, and then the broader market community things that are going on. So the technology, it might be that you have something that's only suitable for Java developers. You know, maybe you have an MVC framework for Java, in which case obviously you're only going to target Java developers. It might be that your project has absolutely no documentation whatsoever. So the only way to learn how to use it is to read the code. And so then the sort of developer you need to reach out to is going to be someone who's super motivated and very experienced. The company or organization that they work at, if you're, this is more for if you're selling your software, but maybe your software has a really, really high license fee, in which case you need to probably sell it to big companies who can afford it. And then what's going on in the broader market or community feeds back into what we were saying earlier about the economy tanking or Bitcoin being fashionable right now. So once you understand the motivators that will get people to be interested in or not interested in your software or your project, then you can start to segment people. You can start to take the broad world of software community and think about groups of people that might be interesting to you. So how do we do that? Well, let's imagine you've gone through this process and maybe you have some APIs, some, yeah, an API tool that makes it easy to create secure web chats. So your first thing is you want people who are looking to do secure web chats, okay? That's a very, very simple way of looking at it. But then you realize that actually a really good market for this is developers who are working for banks. And in particular, your Python SDK is really good. So you're gonna target people who are Python developers. And then you realize, well, actually, all of our team are based in Europe, so we'll go for EU developers. But then you think, well, actually, that's a bit too broad. So we'll go where we actually have people. So we'll go for France, the Netherlands and Belgium or Belgium and Netherlands. And this is in a commercial context, but in a free software open source context. You can do a similar thing of thinking, well, if we wanna gain contributors to what we're doing, we wanna get people to either do drive-by patches or really become involved in our project. What are the sorts of people we need to reach out to? How can we make this appealing to them? So once you've done that segmentation work, you can then go and choose your targets. You ask that by saying, is this segment relevant to our community? Are these people who program in the language that we're working with or whatever? Are they large enough to spend time advocating with? Can you reach them? Are they people who hang out in the places you hang out and you have the resources to reach? And even if you do all this work with them, will they make a large enough contribution to your community to make that effort worthwhile? Similarly, in a commercial context, then the things change more or less and it becomes more about money, but it's more or less the same thing. Now, because it is a 25-minute talk, I'm not gonna go into the detail of making a plan, but it's really important to take all this information and to then come up with goals that align with your organization's goals or your company's goals and have a strategic plan. You know, say, we're here right now, in order to get there, we will need to do these things. Sounds very basic, but like I said, we don't have time to go into it right now. And then you need to do a whole bunch of measuring and reporting. So basically, there are things that you'll keep to yourself, like they're more activity-based, and then there are metrics that you will report back to your organization, to your bosses, whoever it might be. Ultimately, what I'm saying is, borrow from marketing wherever it aligns with community. If you can do that, you can do it with a clean conscience. You know, you're not turning into marketers, not that all marketers are bad, but you are borrowing what works from marketing and making it appropriate to software developer communities. Before I end, I would like to invite you to come to DevRelCon if you'd like to submit a talk. I will say more about that on my Twitter feed. But yeah, if you wanna get in touch, then hello, hoopy.io. And if I've got time for questions, I'll take some now. First of all, Matthew, thank you for your talk.