The public cloud relies heavily on open-source software and on companies that build products out of open-source projects. But how do they get off the ground? How do they build awareness in the broader community, communicate the problems they solve, attract contributors, and develop a user base?
Guest Emily Omier is a positioning consultant who works with companies that are building a project around open source project to help them communicate the value, what’s being built, and why you should care. The trick is to raise awareness without committing the typical tech marketing sins leaves a bad taste in most engineers’ mouths.
We discuss:
- The differences between positioning and marketing
- How to communicate value by helping people
- Attracting contributors
- Which communications platforms make sense for an open-source project
- The role of content and social media
- More
Takeaways:
- Think about what problem you’re solving from the user’s POV.
- Think about your true believers and what they use it for.
- One clear sentence that describes your product.
- Make sure you’re aware of not only features, but why they matter to your users.
Sponsor: Aviatrix
Check out Aviatrix’s Flight Training to learn about multi-cloud networking and security. It’s worth your time if you’re defining your company’s multi-cloud strategy or want to nail down your Aviatrix Certified Engineer certification. Get details and register at aviatrix.com/flight-training.
Show Links:
@emilyomier – Emily Omier on Twitter
Transcript
[00:00:00.260] – Ethan[AD] Check out sponsor Aviatrix is flight training to learn about multicloud networking and security from the Aviatrix perspective, Aviatrix dot com slash flight training. Worth your time if you’re defining your company’s multicloud strategy or want to nail down your Aviatrix certified engineer Cert Aviatrix dot com slash flight Training. [00:00:25.170] – Ethan
Welcome to Day Two Cloud. And today we’re going to have a marketing discussion. Well, we’re kind of going to have a marketing discussion. We’re chatting with Emily Omier. She is a positioning consultant, and she works with open source communities about how to get the word out to the world about this open source project, what it is, what’s being built, why you should care about that? [00:00:47.560] – Ethan
Because, Ned, if we’re honest here people that are engineering like us doing things that are marketing related and talking about ourselves and the things that we we’re not good at that, are we? [00:00:58.030] – Ned
I feel dirty saying the word marketing. Oh, there it goes. It’s like saying sales. If you want to clear a room and that’s how you do it. But the thing is, if you want people to know about your awesome projects, you got to let them know. And that’s not necessarily marketing. That’s helping out people who might have a problem. So that’s one of the things that we focus on in this episode with Emily. [00:01:19.740] – Ethan
So enjoy the show with Emily Omier of Emily Omier Consulting. She is a positioning consultant, and she can help out you and your project. [00:01:29.740] – Ethan
Emily welcome to Day Two Cloud. In a sentence or two, would you introduce yourself, who are you and what do you do? [00:01:36.280] – Emily
Sure. So I am Emily, and I help companies, particularly companies that are building around an open source product or have a product that is in the cloud native ecosystem, communicate their value in a way that makes people understand what the heck it is that they do preferably immediately, not after 15 to 20 minutes of talking or reading through the docs. [00:02:01.430] – Ethan
Now, that sounds suspiciously like marketing, Emily. And in fact, I had a working title for this show of “Marketing your open source project”. Then you’re like, no, that is a bad idea. Marketing is a dirty word in open source. And I laughed at that because I do know what you mean. But we got to get into this. [00:02:18.970] – Ethan
Why is marketing looked down on so much? [00:02:21.400] So people have a bad impression about marketing because there’s a certain amount of marketing that’s done poorly. So if marketing is done well, you don’t really notice it because it just feels like somebody trying to help you understand what this product is. And often in this space. In the case of, say, an open source project, it’s somebody trying to help you upskill yourself and offering you tutorials and showing you how to do something. People don’t generally think of that as marketing, but it is. The reason that marketing has a bad rap is because some marketing is done poorly and it feels like really, you know, really inelegant way to shove something down your throat that you don’t really want, and you don’t really need that’s not what good marketing is, but it is some people’s association with marketing. [00:03:14.950] – Ned
Yeah. I think my association with marketing is you’re trying to sell me something and you’re actively trying to sell me something. And it sounds like what you’re saying is marketing should be more of a helpful hand. Here’s a guide or a way to solve a problem you have. Is that the tack that you take when you’re talking to these companies about their marketing? [00:03:34.700] – Emily
Yeah. And positioning is actually about more than just marketing. It’s pretty high level marketing and sales strategy that actually bleeds also quite a bit into product development. So it’s not even just marketing that I help with, but yes. So best practice, honestly, this goes for any type of product, not just something that’s aimed at software engineers. You don’t want to just try to shove something down people’s throats. You want to be clear about who needs it so that you’re only talking to those people. This is what I help people do. [00:04:09.960] – Emily
Be clear about who needs it. So you’re talking to those people and then communicate in a way that makes it easy for that person to understand why they need it and why they should care. If you can do that. It’s not going to feel like marketing. It’s just going to feel like you helping them. [00:04:27.180] – Ethan
And there’s such a big difference between that approach and what so many marketers that do it. I would describe it as by the book tend to do they glom onto buzzwords and keywords and search engine optimization and trying to pull people in with some… I get so many pitches in my inbox from marketing folks and PR folks who are trying to share a Press release let’s say. You read two or three paragraphs of it, and you have as little idea of what is actually being announced after reading it, as you did from just reading the headline because it’s obfuscated and buried in jargon and lingo that is utterly meaningless and especially for technical people. It is maddening when you read that kind of stuff. [00:05:11.290] – Emily
Yeah, so you should be able to understand what it’s about from the headline. [00:05:16.340] – Ned
Right. Not 15 minutes of reading. And you’re like, I just read four pages and I still don’t know what your product does. [00:05:24.260] – Emily
Exactly. Yeah. That should never happen. It should be whether we’re talking about a Press release or a website or somebody talking to you like, we’re talking like one sentence. It’s all it should take to really make it clear what the thing is and hopefully why it matters to I mean, what it is, why it matters. [00:05:45.920] – Ned
You say one sentence, and I think you mentioned earlier. You have to tell people what your project does or your product does. But that means you have to understand what it is your project or product actually does. How often do folks writing the software or making the product actually understand that portion of things? [00:06:06.240] – Emily
So here’s the challenge is that often somebody will start an open source project. I’ll go ahead and focus on open source projects, and they have a particular goal in mind. They have a particular problem that they’re solving. And this is awesome. Often it’s not even just one person. They create something that’s awesome, and it fixes that problem, and then they open it up to the world. And often what happens is that people start using it for ways that they didn’t initially intend. And sometimes, in fact, quite often, it turns out that these sort of unintended uses are actually more prevalent out there than what the team or the person originally had in mind. [00:06:54.520] – Emily
So that’s the first thing. If you get too fixated on what your original vision is, you can miss out on these other ways that the software could be used, and you can end up missing the ability to connect with a lot of people because you aren’t able to recognize that your project could do something other than what you originally envisioned. So that’s the first thing. [00:07:22.580] – Ethan
I just felt challenged there because when you build something, you have an expectation of how it’s going to be used because you built it to solve a problem that you have probably. And then if people start doing other things you’re like, no, no, that’s not what I meant. That’s not what that’s supposed to do. Don’t do that. That’s the instinct to embrace what you think of as odd or unusual use cases. It’s counter intuitive. It’s like that’s not what that’s supposed to do. Please don’t do that. [00:07:50.380] – Emily
Well, you know, if you have a thousand users and one person is using it in some edge case use case like, ignore that. That’s normal. But if you built it to do X, and it turns out that of your users are using it for Y, that’s something that you need to know. And that happens more frequently than I think a lot of people are really aware of. And then the other thing is sometimes it’s like shades, just because there might be, like a middle ground between X and Y, and you might just need to make a relatively small adjustment and how you’re communicating about this project to make it sort of fit what people are actually using it for. [00:08:39.360] – Ethan
All right. You said communicating. So we’ve decided in the open source project context, we’re not going to say marketing. So we’re going to say communicating about our open source project. All right. This may sound like sort of an obtuse question, but why am I actually doing this communication? Am I trying to attract users? What am I trying to achieve here? [00:09:02.840] – Emily
Well, actually, that’s a good question to ask yourself. So in my experience, most open source, most maintainers or people who create an open source project. They do want to build a community. Now, if you don’t care, if you really don’t care how many users you get or whether or not anybody other than yourself ultimately contributes to this project, it doesn’t matter. Honestly. The fact is that that’s not the case for most open source projects. And so if you do care for whatever reason, and almost everybody does, whether it’s just one lone developer in their garage or, like, Comcast, there’s usually some sort of strategic reason for Comcast to want their open source project to have users just like there’s usually some reason the loan developer in their garage also wants more users and more contributors. [00:10:01.360] – Ned
Right. So how would I go about raising awareness of my project? Assuming I do care, I want to build a community, or maybe someday monetize this open source project. What would be the first step? Assuming I figured out what my solution or what my project actually does, what’s the next step in that process? [00:10:24.580] – Ethan
Ned you said, monetized. Come on, man. That’s the other dirty word, isn’t it? [00:10:27.997] – Ned
It is [00:10:28.054] – Emily
It is the M word in open source. [00:10:31.450] – Ned
We can talk about that in a moment. But first, I’m just curious about the first step after going, okay, I know what my thing does or at least what people want it to do. Now, what do I do next? [00:10:42.530] – Emily
Right. So the key is you have to tell people about it. And in fact, this actually comes before you figure out what the best way to describe your project is. You need to start talking to people about it. I mean, this should seem fairly obvious, but in fact, it isn’t like people sometimes think that they’re just going to put something up on GitHub, and it’s just going to be magic, and they don’t have to talk about it at all. That isn’t true. I mean, communication is everything. [00:11:16.510] – Emily
It could be just like sending an email to everybody, you know, all your old colleagues or all your current colleagues, who you think might use this project or putting something on social media or starting a medium blog or starting a real blog or starting a website for this project. But you have to talk about it, whether that’s in written form or going on podcasts or things like that. You have to have one on one conversations with people, too. And that is how you’re going to understand what’s resonating and what isn’t. [00:11:50.290] – Emily
So if you go on a podcast, you’re not going to get that that feedback about whether or not the way that you’re describing your project makes sense in the same way that you do if you’re talking with somebody, one on one or two people and you’re talking about the project. [00:12:08.080] – Ethan
So one on one. As in testing to make sure that your communication is getting across the message you’re trying to get across. [00:12:16.340] – Emily
Exactly. So if you’re having a conversation with somebody and they meet the, they’re in this general universe of somebody who you would think of as a user, of someone who would get value out of your project, and they don’t get it. If it’s taking you, like, 15-20 minutes, and they’re still kind of like, don’t really understand what this is. That’s a red flag. That means that there’s something that’s not working about how you’re describing this project. You don’t want to have to tell them, like, go check it out, and then we’ll talk. No. At the beginning that might happen, but you do want to be able to have them be almost immediately like, oh, yeah, that makes sense. [00:13:01.140] – Ethan
Although that can be obscured by if it’s a domain specific sort of a project like this is something that helps Kubernetes do X, and you maybe have an idea of what Kubernetes is. But if you’re not into it, I mean, some of the domain specific projects around Kubernetes that deal with some esoteric function you’re like, I don’t know. [00:13:20.640] – Emily
But this is why it’s so important to know who you should be talking to, because if that person I mean, if you’re talking to your dry cleaner, they’re not going to understand what your open source project does. Obvious. But if you’re talking to somebody who you think should be like a potential user, they should understand. And it doesn’t matter if it’s a domain specific, because you should be like, we’re only really talking to people who have that domain specific knowledge if you’re doing it right. If you’re thinking critically about who should be, who’s a potential user and who isn’t. [00:14:01.380] – Emily
Actually, I will add something here. I notice when people talk about stuff like developer marketing and things like that, I notice there’s sometimes a tendency to talk about all software engineers as if they are like one homogeneous mass. And this is a mistake, obviously, because there’s so many different sub domains within software engineering that yes, it is very easy to talk to another software engineer who still is absolutely not a potential user for your project. And will have no clue what you’re talking about. [00:14:34.580] – Ethan
Well, as in there’s front end developers, back end developers, UI specialist, infrastructure specialist, and so on. [00:14:40.680] – Emily
Networking specialist, security specialists, all sorts of other, there’s storage engineers. And it goes sort of on and on and on. And then we get into the thing with there’s people who are Kubernetes experts, people who never use Kubernetes. So you just have to know, be clear about who your project is for. And if you’re talking to that person, they need to understand if you’re talking to someone who doesn’t fit that profile, they might not get it. [00:15:10.960] – Ethan
There’s a feature on Hacker News called Show Hacker News show HN colon. And then you can talk about your project. And some people do that really well what you’re describing where in the paragraphs of whatever it is they’re showing to the hacker news community, they clearly delineate it. And you kind of get it pretty quickly. Yeah. I should poke around at that or like, Nope, not me. Other folks. It’s like they have this problem that you’re describing where they’re showing and you get to the end of the I I still don’t really get what this thing is that it’s supposed to, but just a good case in point, because I see those all the time people showing off their projects there via that show HN feature. [00:15:46.650] – Ethan
It is a great way to get feedback from a community of interested folks about what you’re doing. And although I don’t know that that’s communication testing, such as more like user acceptance testing in that kind of a setting. But still. [00:15:59.310] – Emily
Still, it’s a type of communication. And that goes to my point about like, you got to talk about it because it can be a barrier to people just because they’re afraid of rejection or whatever. Then. So ultimately their project goes nowhere because they’re not talking about it. So no one ever finds out that it exists. [00:16:22.960] – Ned
Right. For me, I don’t like talking about myself a lot. And to promote a project or something I’m working on feels like I don’t know what the right word is. Maybe bragging or just being too much about yourself. And so I would tend to turn that dial down. But what you’re saying is you do have to talk about it. You have to be open about it. If you want to build that project up and have people be aware of it. Are there some ways that you can do that without feeling like it’s self aggrandizing? [00:16:57.380] – Emily
Yeah. I mean, when it comes to both marketing and sales, ultimately the best practices that you shouldn’t even think of it as being about you, you should think about as being about the potential user. What are the problems that they have and how are you helping to solve them? And if you think, we’ll talk about mindset first and then how that actually translates. But if you are thinking about talking about your project and instead of thinking, oh, I really want people to use my project. Please use my project, use my project. [00:17:34.180] – Emily
And instead of thinking that, you’re thinking, I spent a bunch of time to create this thing and it solves a real problem that people have here’s the problem that it solves specifically. I bet there’s a bunch of people out there that are struggling with this problem, and I can help them. If only they know about this. I can solve their problem makes it not about what you and what you desire, but how you can help this other potential user. That’s a very different place to to be coming from. [00:18:07.090] – Emily
And it can actually just from a mindset perspective, can really change how you even think about your marketing. And if you do sales, like how you do sales. [00:18:18.910] – Ethan
I was just going to say it’s also a sales technique. They can’t say yes, unless you have the conversation with them, you’re definitely never going to sell anything. If you never talk about the product and try to get it sold. [00:18:30.200] – Emily
Yup, exactly. [00:18:31.560] – Ethan
Gotta have kind of that conversation. [00:18:32.760] – Emily
And it should be about the potential user, the potential customer and what they need, not the fact that you want more downloads. [00:18:41.740] – Ethan
So let’s talk more about communication strategy. Then how does an open source project craft their message? You’ve mentioned earlier, the one sentence approach. You should at least be able to compartmentalize what the project does clearly in a sentence. But we got to go beyond that, though. You need to be able to communicate beyond that one sentence in more detail what it does, the problem, it solves how it might fit into your workflows if it’s a technical product. And how do you get that value clearly communicated? [00:19:11.050] – Emily
First, I wanted to say if you have just open sourced project, like, just pressed the button, you’re going to need to iterate. You’re going to need to do a little bit of figuring out to understand what the best way to talk about your project is going to be. This also isn’t something that can be done entirely without feedback. You can get closer without any actual user feedback. But you do need to actually talk to people in your potential user community. Once you have a handful of users, the first thing is to talk to them and figure out: A. What are they actually using it for? [00:19:50.700] – Emily
What are the things that they actually value about the project? And then this is the key. What would they do if your product didn’t exist? And sometimes people think about, well, particularly in the commercial world, they get really obsessed with their competitor. We have these two competitors over here, and sometimes usually your competitor, like the thing that you lose deals to or the thing that causes somebody to not download your open source project. It’s doing nothing. It’s just the status quo that’s your big competitor, whether it’s an open source project or whether it’s commercial. [00:20:33.680] – Emily
So you have to figure out what does that status quo mean? Is the status quo acceptable? Is there some other way that they were solving this problem before? Often there is maybe they were tracking stuff on a spreadsheet. Maybe they were manually doing whatever it was. Usually those are the sort of things that you’re replacing with your project or with your or with your commercial product. You know, writing a bunch of custom scripts, doing something manually, tracking it with an Excel spreadsheet. It’s not. It’s less frequent that you’re actually bumping out another product or even another open source project. [00:21:17.960] – Emily
So you want to understand that because then that’s going to help you understand what value it is that your project provides. And also, like what context you want to put around your project in order for people to understand it and think about in contrast to these things that people would do if your project didn’t exist. What sort of value are you providing? It might not be easier or cheaper. Often it isn’t, but often it is faster or it is more secure or it’s more reliable things like that. [00:21:55.600] – Emily
So when you hear, like, easier or cheap, you think is easier than doing it in Excel, or is it easier than doing nothing? Usually it’s not easier than doing nothing. And so if people are currently solving this problem by not solving it and doing nothing, you don’t want to talk about how easy your thing is to use because they’ll be like, it’s just not easier than doing nothing. [00:22:23.760] – Ned
Yeah nothing is pretty easy. I just don’t do it. [00:22:28.500] – Emily
Anyway, so once you figure that out, then you can start figuring out what one sentence, what label you can slap on your project. That’s going to make this value that you provide fairly obvious, and it’s going to make it clear what use case you’re most appropriate for, and that’s kind of the process. [00:22:52.000] – Ethan
I’m rudely cutting into this conversation to ask you where you’re at with your multicloud networking strategy because a few different multicloud networking vendors, they’ve come on as podcast guests, and they’ve shared their approach here on the Packet Pushers Podcast Network. One of those vendors is today’s sponsor Aviatrix. And in fact, you heard from Aviatrix engineers and a customer as Ned and I nerded out with them on the Day Two Cloud Podcast episode number 113. We covered their data plane that’s common across all the different clouds, giving you consistent network operations. [00:23:21.870] – Ethan
Now, if Aviatrix isn’t a company name, you know very well, don’t just blow them off. I challenge you to consider all vendors that might solve your problems. And Aviatrix is going out of their way to make it easy for you to include them in your upcoming multicloud networking bakeoff. First, they are well funded, so they’re going to be around for a long time. Tell your boss, Aviatrix just close to $200 million series e funding around if you get asked. Second, Aviatrix is also offering Nerdy deep dives for you, the engineer, so that you can make an informed, nuanced decision about whether Aviatrix is the right multicloud networking strategy for your organization. [00:23:57.930] – Ethan
They call it flight training, and you can go for a 90 minutes, hands on lab, a five hour deeper instructor led hands on experience, and even prep for the Aviatrix certified Engineer certification. So give Day Two Cloud episode 113 a listen and then visit Aviatrix dot com slash flight-training to find out more. I’m hoping to take the five hour flight school training sometime myself soon if they can find room for me. Again, that is Aviatrix dot com slash flight-training and let them know you heard about it on the Packet Pushers Podcast network. And now back to today’s episode. [/AD] [00:24:34.560] – Ethan
There’s a central theme here in the way you’ve described Emily, which is putting yourself in the position of the person consuming your product. Think about it from their perspective, you built it, you know what it is and what problem it solves for you. But now imagine you never heard of this project or product. Put yourself in the shoes of that person. Think about it as they would be thinking about it, seeing it for the first time and then fill in the blanks that are created at that moment. [00:25:02.120] – Emily
Yes, exactly. Because that’s the person that person is coming at this project. They have no baggage. They don’t have all this explanation, all your rationale for why it was created in the first place. But, I mean, that is the person that you want to be convincing to use it. [00:25:21.060] – Ethan
Does this also translate to a venture capital pitch? If I want to go try to get funding to really make my big project go even bigger, would all of that leg work be helpful there? [00:25:33.330] – Emily
Definitely. I mean, ultimately, you want your VC to understand what the heck your product does, too, or your project. There are some differences. First of all, in sort of a product positioning or open source project, a scenario you do want to be very specific about the problem that you’re solving, and you want it to be for a relatively narrow number of people because you want to be extremely specific about who is in and who is out of your target user criteria. And ultimately you want to get pretty narrow so that you can really speak directly to that situation. [00:26:10.900] – Emily
I will say, like, sometimes VCs like you to be extremely broad and have this, like, giant vision about how you’re going to be Google and you’re going to make everyone better, totally revolutionize the whole world. But from an actual strategy, like business strategy perspective, you do not want to try to be Google in your first year of business. That’s a terrible idea. You want to focus on something extremely specific, and that’s part of what positioning is becoming extremely focused on a very narrow set of problems that a very specific set of people experience, so you can really talk to them in all of your communication. [00:26:58.960] – Emily
Really be clear about how this problem manifests itself, what sort of words they used to talk about their problem and what they expect in a solution. [00:27:07.840] – Ned
I think it’s important to avoid scope creep in your project because like you mentioned before, some people are going to have edge cases, and they’re going to want to apply your product in different ways. And having that sort of almost mission statement of this is what my project does. This is what it’s intended for can help guide that or contain that scope creep. But then you also mentioned sometimes people are going to use it in novel ways that are actually good and may change that direction. So when do I know I should veer off in this other direction a little bit and not consider it scope creep on my project? [00:27:46.680] – Emily
Well, you know, it’s all about, like, sort of scale. So again, if you have a hundred, let’s say you have 100 users and five of them are using the project in some weird way. And those five are like, they’re not super active users, then you ignore them. Now, let’s say that you have a hundred users and you have ten who are really active with your project. They’re like, they’ve become contributors. They’re like fixing bugs. They’re becoming really integral parts of the community. And let’s say all of those ten users, the users who are really extremely sort of true believers in your project, they’re all using it in a way that’s different from what you intended. [00:28:32.710] – Emily
And it’s all the same, like they’re using it in the same way. But it’s all different from what the way that you originally intended. That’s something that you should pay attention to, for sure. So you do have to pay attention to the quality of the users that we’re talking about. I mean, if they’re real true believers, if all of your true believers are using it for one purpose, that’s probably the purpose you want your open source project to be promoted for. [00:28:58.540] – Ned
Right. It sounds like it reminds me very much of the DevOps principles of rapid iteration, listening to the feedback that you’re getting from the operations team, which is almost like your users and your potential contributors. And what’s very unique about an open source project versus something close source from a vendor is people can contribute. They can comment. You can see how many pulls you’re getting of the software. If I want to try to convert some of those people consuming the project into contributors, is there a way to go about getting them into the contributor mindspace instead of just using the product? [00:29:38.480] – Emily
So that is not really my specialty. There’s all sorts of people who have, like, you know, community management specialty. I actually don’t think that it’s rocket science. I mean, part of it is like knowing who has become a contributor already. And how do you attract more people who are like them? That is what I do. I help you attract more people who are like, the contributors that you already have, so that you’re sort of attracting this, like, higher quality pool of users already. But then there’s all sorts of other techniques, like creating a welcoming environment, like personally inviting everybody to contribute when they first become part of the community. [00:30:26.190] – Emily
Having good documentation, all of those things make it more likely that somebody is going to become a contributor, and those are not related to positioning. [00:30:35.460] – Ethan
You said documentation one of my very favorite words. And this can be a tough one for open source projects because too busy building features. Documentation is like, yeah, I’m going to get to that at some point, but it can be hard for the people that are writing the code to also spend a lot of time on good user focused, consumer focused sorts of documentation. So how do you think from a communication standpoint, enlisting and building your community? What role does documentation play? [00:31:06.590] – Emily
Oh, I mean, documentation is really important because you need people to be able to understand really well how to use your project. I mean, it’s not always self evident just from downloading the project itself, how you’re supposed to use what the architecture is meant to be like, even things like when it’s going to work and when it’s going to not work, what situation it is and is not appropriate for that’s really important that it helps people not become frustrated. I mean, honestly, you just don’t want people to get frustrated and you want to make it as easy as possible for them to sort of self serve. [00:31:46.380] – Emily
So ultimately, that’s what documentation is all about. You don’t want them to have to ask you a question. [00:31:51.640] – Ethan
Can I just say if your idea of documentation is a cryptic man page, stop, don’t stop it. That’s not enough. A man page is great depending on what your tool is, if that’s even an appropriate thing. But my word I’ve written read some man page like, yeah, I still don’t know, but well written documentation that actually explains not what a command line switch does. Not what a checkbox does, but context around the tool and how you’re meant to treat it and what it does for you in a big picture way and then dive into the details. [00:32:31.440] – Ethan
You get grounded first and then you can go to the details. That is good documentation. And it is hard to come across that sort of documentation a lot of times. [00:32:44.250] I’m glad you mentioned a big picture because I think of big picture sort of what I specialize in doing. And I find that a lot of the people I work with aren’t very good at big picture. They’re really good at like details and really zooming out and talking about the context that their project is part of. That’s what they often find challenging, and that’s what ultimately ends up preventing a lot of them from communicating effectively about it is because people need that context. [00:33:18.660] – Emily
And yes, even if your audience is just as technical as you are, everybody needs context in order to understand, anything honestly, but they need context to figure out how your project fits into their workflow, what it should and should not be used for and provide that context in the docs and any other place possible. [00:33:42.940] – Ethan
Is it possible, Emily, to attract the wrong sort of either contributor or maybe community member to your project if you get the communications wrong. And if so, how do we avoid that? [00:33:55.080] – Emily
Yeah, it’s funny when you say wrong type of contributor. It’s like if you got a jerk, but you can have jerks who are actually the good type of contributors, by which I mean, they fit the criteria of your ideal user just because they fit that criteria doesn’t necessarily mean they will not be jerks, but yeah, no, it totally is the wrong type of contributor would just be somebody who’s trying to push your project in a way that it shouldn’t go. And this is especially bad if you have, like, numerous contributors who are all trying to push your project in a way in different ways that it should not go. [00:34:40.850] – Emily
That can be particularly bad and stressful for anyone who’s trying to maintain this project. Keep it on sort of the focused path that you are going on. The way to avoid that type of situation is just being really clear about what it is that you’re trying to solve and who you’re trying to solve it for. Communicating that really clearly having it written down so that if somebody says we want to do X, it’s very easy to point to look here’s our mission statement that we have written down, and that is public, and this does not jive with that mission statement. [00:35:23.210] – Emily
This does not move that mission forward. So we’re going to not do it. It is much easier to say that if you have documentation, if it’s not just in your head what your mission is. [00:35:34.480] – Ned
You know, that is one of my absolute favorite things in the world is documentation. I think Ethan and I are both on the same page about that and clear, well written docs that explain the project and also get you started with some real world examples and get you started quickly, so you don’t feel like you’re just floundering through marketing fluff is so important. But sometimes the people writing the software are not necessarily the best people to write those docs. Do you recommend reaching out to the community or finding someone else who’s a technical writer to help you with that portion of things? [00:36:11.900] – Emily
I mean, there are, like there’s a whole subspecialty of people who specialize in writing docs. So yes, if it’s something you absolutely can’t do, find somebody who can. Chances are, I think that most people can, they just don’t make time. And then I would say, you know, it also depends, honestly, how mature is this project? Are you just one person? Is this like a well funded project by a Fortune 500 company? There’s different levels of resources and in the situation where there’s plenty of funding. Yeah. You should get somebody who specializes in writing docs and like that should be the person writing the docs. [00:36:59.430] – Emily
And you should probably have somebody like me helping you figure out exactly what message you’re going to put out in the documentation and how you’re going to write your mission statement. If you’re just one person, you should do your best. [00:37:14.860] – Ned
At least put the effort in. [00:37:17.270] – Emily
Put the effort in. Yeah, that’s the thing. I think with a lot of things, it’s like just trying just making the effort sort of puts you ahead of the pack, right. [00:37:28.940] – Ethan
With leadership. Emily, it’s really if your project you’re one of the leaders, this is your baby. This is the thing you’ve been bringing to the world. How important is it to be a strong leader that keeps that project on track? We were talking about that wrong sort of contributor. Or we’ve heard about kerfuffles within open source projects where some groups like this isn’t going the way we want. And so they fork the project and start something else because it’s like this is the way it should go. [00:37:57.090] – Ethan
And it feels like sometimes such an event is fine. And sometimes it’s like that was actually dramatic, and it was an argument between people they couldn’t resolve. And maybe that was a communication breakdown. So going back to leadership, if I am a strong leader, I’m assertive I am maybe I’m the benevolent dictator for life sort of a role. How does the communication factor into that? If I want to take that role, should I be communicating and in what way to my community? [00:38:28.360] – Emily
So there’s a lot of levels to this question I think. First of all, when it comes to positioning, if you are sort of the leader, your identity can get sort of wrapped up in this project and what it is. And sometimes that is a barrier to effective communication, because if people aren’t getting it or if people are using it in a novel way, sometimes because the leaders identity is so wrapped up in what this project was supposed to do when they originally designed it, they can get extremely resistant to change. [00:39:06.380] – Emily
Then the next thing that you’re talking about is this sort of when there’s an argument and like, what type of leader should you be? I think you just need to be clear. Like, this is where the project is going. And in the case of an open source project, you know, somebody else that feels really strongly that there should also be, it should also go in some other direction. Honestly, I think that that’s okay. I think that as the leader, you should be clear. Like, this is where I think that this project should go. [00:39:37.850] – Emily
If you want to fork it and start something new, I actually don’t see a problem with that. I mean, obviously there’s some interpersonal skills that you should think about to make that not painful, but yeah, that’s fine. Maybe somebody else sees another problem that I think should be addressed. In fact, actually, I think it is better to do that than to try to do too many things with one project. So I would rather see projects getting forked, having these divorces between communities so that they can really effectively address a problem. [00:40:13.880] – Emily
And instead of just trying to do a hundred things with one project. [00:40:18.870] – Ethan
Well, let’s talk about tools a bit. Emily. Now, we said before the show that you didn’t really have much opinion on tools, but yet it is sort of implied in this that we are using some sort of communication tools to chat with different folks, for example, GitHub and a GitLab and other things like that pop up as ways that we can get our open source tool out there and share with people, and they can do pull requests and there’s comment threads and all the rest. Is there a prescribed have to way to get your open source project published? [00:40:55.480] – Emily
From my perspective? No. I mean, just get it out there. I mean, when it comes to communication, my feeling is that the tools you use don’t matter as much as what you’re saying. So don’t stress out about what tool you use. I mean, there’s a little bit here, like you do want to think about what tools your potential users are already familiar with, and that is important. It’s important both choosing how to publish your open source project. It’s also important when you think about what to integrate it with or what it should depend on. [00:41:36.740] – Emily
So when you think about promoting like, well, do your target users use Twitter? Well, if, yes, maybe you should use Twitter. If no, maybe you shouldn’t. You want to think about where do your target users actually hang out? And that’s where you want to be. But it’s not so much like that X tool is superior. [00:41:59.480] – Ned
You can also get into a situation where you try to push your message out on too many platforms and you find yourself over taxed. So, like, do you have a recommendation on the number of platforms you should go down? Or does that depend on the size of the project and how many people you have on your communications team? [00:42:19.910] – Emily
It totally depends on the size of the project and how many people you have on your team. I mean, again, if you have tons of resources like, gosh, why not? Just I wouldn’t actually even say, like, go all in on all channels. I think maybe two is probably good, but yeah, if you’ve got a giant team and you’ve got a ton of resources, that’s one thing. And if you don’t, I mean, that’s another. But that’s why it’s so important to focus. Like, if you’re really focused, it’s going to be a lot easier to get traction, even if you’re just one person, then if you’re not really focused. [00:42:56.380] – Emily
So if you’re really, really focused, really specific on who you’re trying to reach, then getting traction is going to be a lot easier. [00:43:04.430] – Ethan
If we talk about chat platforms like so many projects. We’ve got an IRC, we’ve got a slacker, discord, etc. Do you think a real time chat platform is important for community interaction? Community growth? [00:43:17.100] – Emily
I have no idea. [00:43:20.450] – Ned
Neither do we. [00:43:21.760] – Emily
Yeah. I mean, maybe it is. There’s probably someone out there who’s an expert on this. I have no idea. [00:43:28.100] – Ethan
It almost seems like a given like it’s expected. But then on the flip side of it, I’m in a few different slack groups that are community oriented. Sometimes there’s really interesting conversations that are happening there. Sometimes it’s completely dead. In all cases, you’ve got to moderate. You’ve got to pay attention to what’s going on and deal with those trouble users. Deal with the drive by marketers who fly in because they want to spam your community with their products, and that’s inappropriate. So it’s definitely a burden that comes with it. [00:44:00.930] – Ethan
So I’m I’m with you. I have the opinion that there’s value because people within the community make a connection around your product, whatever that might be. But the trade off is the time you have to invest as a project or community leader in interacting with that group. They can self police to some degree. But you got to be in there. You got to be involved if you lead that. And if you don’t have that kind of time, that can be tough. [00:44:30.480] – Emily
You know and I think I’m going to say this again. I keep talking about focus, but this is another area where actually having almost a smaller community can be better, especially if you’re just one person. You don’t necessarily want a giant community. You want a community that has a high percentage of true believers. And then that helps your community grow because the true believers are going to be able to help you with moderation, etc. Those are the people that are more likely to be contributors, etcetera. And so that can help you grow sort of organically, as opposed to getting a giant community with a bunch of sort of not super committed users. Then that makes managing something like a slack like way more burdensome. [00:45:29.340] – Ethan
What’s your take on building content around your project? Like starting a podcast or YouTube, which we’re all podcasters here. So it’s easy for say, yeah, start a podcast. But we also know how difficult that is. And the same thing with a YouTube channel. You can build a YouTube channel. But the creating content that’s out there regularly is hard. So how does that fit into your communication strategy? [00:45:52.660] – Emily
Yeah. So my background is in content marketing, so I’m pro content and in all of its forms. But yeah, you know, the thing that I would say is like, you want to do something, but you don’t want to do it all. So pick something. And if podcasting makes sense to you, actually, I don’t think that podcasting makes tons of sense often for promoting an open source project. I do think things like video tutorials that can make total sense, blog posts usually, those are kind of the two things that I would say, like webinar style videos and blogs. [00:46:32.280] – Emily
Those are the things that I would recommend if you’re going to do content marketing for an open source project. [00:46:37.740] – Ned
Right. Right. [00:46:39.380] – Emily
Start there. [00:46:40.750] – Ned
Yeah. The podcast seems to make sense long after your project has taken off and reach something like Kubernetes scale, because there’s a whole bunch of Kubernetes podcasts. But that happened after the fact after the project was wildly successful. [00:46:55.980] – Emily
Yeah. And when you’re talking about promoting an open source project. Often there’s like stuff that people want to see and like, an audio only format isn’t the best. So it’s harder to talk about exactly what you’re doing in the code when you can’t, like, actually show people. [00:47:15.390] – Ned
Right. Well, let’s say that I either have an open source project that I want to grow or I’m thinking about starting one. Can you distill it down to a few key takeaways for the audience? [00:47:27.940] – Emily
Yeah. Absolutely. So first one is think about what problem you’re solving from your users point of view, not just from your point of view. Pay attention to who your true believers are and what they’re using your project for. Make sure that you can describe your project in a sentence. And when you’re talking to somebody who should get it, who is a potential user, make sure that they understand what you mean in that one sentence. And then the last one is make sure that you’re aware of not just the features that your project has, but also why those features matter, which is like, what value do they provide to your user? [00:48:14.850] – Emily
We talk a lot about value in sort of a business sense, but there’s technical value too that makes it faster, more reliable, etc. So connect it not to just sort of technical outcomes, but also sort of more value for the user. [00:48:34.300] – Ned
Awesome, good takeaways. If folks want to follow you or get more content from you, where can they go? I think you’ve got a few things you’d like to promote. [00:48:45.710] – Emily
Yeah. So go to Emily Omier dot com. I have a blog that’s about positioning Open source. It is called Positioning Open Source. You can actually go to Positioning Open Source dot com, and it will redirect you to my blog. And then I also have a podcast called Cloud Native Startup that is about founder stories. I talk to a lot of founders in the Cloud Native ecosystem about sort of the journey that they’ve been on, what they’ve learned, mistakes that they made in the process of building a company. So check that out.It [00:49:22.620] – Emily
is called Cloud Native Startup, and yeah, I’ll be speaking at Open Source Summit and Container Days here, coming up in September. I’m sure by the time this publishes, that will have happened. But listeners can go find the video of my talk. And what else? Do you want to work with me? I usually work with companies that are building a commercial open source company, or I should say, in the Cloud native or native Kubernetes ecosystem. So if you want to work with me, just send me a message through my website. It’s pretty easy. [00:49:58.280] – Ned
Awesome. [00:49:59.160] – Ethan
Excellent. That’s all at Emily Omier dot com. And thanks Emily for being on the show today, you’re West Coast, which this is like the 6:00 or 07:00 hour for you. So thanks for coming on the microphone first thing in the morning. And if you’re listening out there because I guess if you’re listening, you’re hearing this. Hey Virtual high fives to you for tuning in. Awesome Human if you have suggestions for future shows, we would love to hear them hit Ned or I up on Twitter. We’re both monitoring at day two Cloud Show or hey fill out the form and Ned’s fancy website Ned in the cloud dor com. [00:50:33.230] – Ethan
Quick Bit of Housekeeping. Packet Pushers We have a weekly newsletter here at the Podcast network. Human Infrastructure Magazine, Human Infrastructure Magazine is loaded with the very best stuff we found on the Internet, plus our own feature articles and commentary. It’s free and it doesn’t suck. The whole idea is you’re just going to get in a one week a distilled version of what’s going on in the tech industry. Get the next issue for free packet pushers dot net slash Newsletter. Until then, just remember, Cloud is what happens while IT is making other plans.
Podcast: Play in new window | Download
