Live from all things open, Matt & Avi welcome Emily Omier to the Hacking Open Source Business Podcast. Emily and Avi discuss their talk on how to determine if your open source project sucks or not, as well as dig into how to interview users, figure out the position and messaging for your open source project, and more! We hope you will join us!
Checkout our other interviews, clips, and videos: https://l.hosbp.com/Youtube
Don’t forget to visit the open-source business community at: https://opensourcebusiness.community/
Visit our primary sponsor, Scarf, for tools to help analyze your #opensource growth and adoption: https://about.scarf.sh/
Subscribe to the podcast on your favorite app:
Spotify: https://l.hosbp.com/Spotify
Apple: https://l.hosbp.com/Apple
Google: https://l.hosbp.com/Google
Buzzsprout: https://l.hosbp.com/Buzzsprout
Live from all things open, Matt & Avi welcome Emily Omier to the Hacking Open Source Business Podcast. Emily and Avi discuss their talk on how to determine if your open source project sucks or not, as well as dig into how to interview users, figure out the position and messaging for your open source project, and more! We hope you will join us!
Checkout our other interviews, clips, and videos: https://l.hosbp.com/Youtube
Don’t forget to visit the open-source business community at: https://opensourcebusiness.community/
Visit our primary sponsor, Scarf, for tools to help analyze your #opensource growth and adoption: https://about.scarf.sh/
Subscribe to the podcast on your favorite app:
Spotify: https://l.hosbp.com/Spotify
Apple: https://l.hosbp.com/Apple
Google: https://l.hosbp.com/Google
Buzzsprout: https://l.hosbp.com/Buzzsprout
Welcome to another episode of the Hacking Open source Business podcast. Once again, I'm joined by Avi. Avi, how you doing today?
Avi Press:I'm doing well. The conference is going good so far,
Matt Yonkovit:and we are here at all Things Open. Um, and so we decided to grab a few folks who we know in the community space, and of course we have Emily Omier here, and Emily has, a talk with Avi today, so we figured why not sit down and talk a little bit about, you know, what Emily's an expert at, which is the messaging and positioning and all things in the open source space. Great to have you here, Emily.
Emily Omier:Thank you so much for having me. All right.
Matt Yonkovit:What's your talk today about? You have two talks actually, right?
Emily Omier:I do. So the first one with Avi is about using quantitative and qualitative metrics to figure out if your project sucks or not, or more positively if it's any good or not. Um, , it's gonna be, it's be great talk . Yes. But, uh, and then the second one is about how to talk about your open source project so people get it.
Matt Yonkovit:Oh, okay. So why don't we start with how do, how do I find out if my open source project sucks.
Emily Omier:Uh, well, so Avi has a big, a big part of it where he talks about collecting, like actual, uh, metrics that are sort of broad. My, my part is actually related to talking to people. So you have to have sort of a pulse on the community. And the only way to do that is to talk to people and see, uh, do they like it? What do they say? If you say, you know, what happens? Or what would you do if our project were to disappear tomorrow and magically get erased from your code base, what would you do? Um, some people will say, Eh, I'll just use this other project. It's whatever. Um, that's not a super good sign if they say that. Um, but then I've also had conversations with people and they're like, Oh. Um, if that happened, I think I would retire. Uh, and, uh, this is the sign that your open source project is very good.
Matt Yonkovit:Okay. Okay. And Avi, what are you gonna talk about today? Like, you know, obviously it's probably gonna Involve Scarf.
Avi Press:It's probably, Well, we, we, I'll hopefully be mentioning scarf very little only for fun facts that we've found in our data that are relevant to these kinds of metrics. Um, but we, we will be going over the kinds of quantitative things that. Most projects should be measuring, all projects, should be measuring, um, et cetera. So things like, um, conversion rates from your documentation to downloads. Um, things like what is your, what does your churn look like at each stage of the user funnel? As people discover your project, then go to adopt it and then become, um, you know, people who are relying on it heavily. Um, and. Yeah, I'm really excited for this talk cuz it actually, you know, blends these two very different, um, very different approaches to this kinds of measurement, but are both really, really important and both need to be done, I think. And, uh, there's a lot of difficulty in both of those things. And personally, I think I, I'm very interested in. Emily, your experience with user interviewing and where you've seen a lot of people make mistakes? Because I know as, yeah, as someone who has tried to do both, you know, user studies as well as just surveys and research, it's. Very hard to do it well. Um, and I don't think a lot of people understand that until they try to dive into it and try it themselves. Um, so I'm curious what kinds of things that you see people, common mistakes you see people
Emily Omier:making. Yeah, so there's uh, there's a couple aspects to this answer. I think. Um, the first one is that, so I am talking to users on behalf of my. Um, which does give me like a built in advantage because it can be more challenging to do talk to users, ask them questions about the project that you're emotionally invested in. And it is also harder sometimes for that to get honest feedback, um, because they, you know, people wanna be nice and they don't wanna be, Hey, you know this feature that you launched, like it was garbage. And um, you know, you do want to know if they think that, but it can be really challenging, you know, if, if it's you, cuz people don't wanna say that. Um, I would say there's a couple mistakes that people generally make. You know, one is coming in with too many assumptions and uh, again, you know, you create your project, you have like a specific use case in mind for what this project is gonna be used for. And sometimes that is what your users actually use it for. Um, very often it's a little bit different. And sometimes it's a lot different. And so if you come in with too many baked in assumptions and you ask like a, a lot of the questions sort of I have baked in assumptions are sort of leading. You can end up like missing the point.
Avi Press:What would be an example of an assumption that you see people making that are wrong?
Emily Omier:So, Um, I'm thinking of a company I I worked with had an open source project related to cutting cloud costs. Well, this was what they thought about, right? We, we created this project. The reason that we created it, cuz our cloud costs were out of control and, um, thing was, none of their users were thinking of it as a, like, cost control project. That's not why they were using it. So, um, they could come in and say like, you know, Why, Why did you need to, like, why did you need to get your cloud costs under control? And they'd be like, Well, uh, that actually wasn't an issue. So here's this other thing. But you'd end up sort of not getting enough information about what the actual use was like because you were so focused on what you thought they were probably using it for.
Matt Yonkovit:Yeah. One of the things that I've seen, especially when talking with users, it's very easy to lead the users. Right. You know, because you'll, you'll start to talk to the users and try to drive to the conclusions you want them to tell you. Yep. It's so common.
Avi Press:And it can be really subtle too, like even your body language when you ask a question can like hint at the answer that you want, um, or these kinds of things. And there's so many different subtle ways where you can be guiding the, the person you're interviewing to a particular answer. Um, And, you know, even if, even if they, and you are not picking up on it, it might be skewing the results. Um, you see this kind of thing in like the science world a lot as well of like psych studies and these kinds of things. And all of those principles are super relevant here as well.
Emily Omier:There's also, uh, another really common, um, mistake that people make is talking too. And first of all, you want to spend most of your time listening if you're doing a user interview. But second of all, if there's silence. So we have all been conditioned to find silence really uncomfortable. So if there's like a long pause. Chances are you, like, you will feel an overwhelming urge to jump in and fill the silence with something. Totally. And that is a mistake because what you want, like, you want to use that to make your user feel really uncomfortable and to jump in and fill the silence. Um, sometimes with something they might not have. To say, um, and you know, I'm not trying to be malicious, right? That's not, that's not the goal., Avi Press: it'll be my quote, Yeah., yes. Ok. Yes. Um, but it's, it's just about getting people sort of off their script. Uh, this is actually why it's not really that great to do, like. Questions over email or something like that. Cause you don't want people to think too much. Uh, that also allows them to think a too much about like, well, I wonder what they're, what they want to hear. Um, I wonder what I could say that would like impress them or something. And that's not what you want. You want really honest feedback.
Matt Yonkovit:Yeah. I mean, I think that's a good point. You know, when people are uncomfortable, or maybe uncomfortable is not the right word, but when they're comfortable enough in the moment to share. And not be afraid of the repercussions. That's an important thing. I mean, and I think that that's something that we all, um, tend to overlook. Who's typically the people who are asking these questions though? I've seen this in the product team for instance. Uh, is that somewhere where the product team generally takes this responsibility?
Emily Omier:That is a really good question. So, um, we are talking about open source and there can be d. Different types of open source projects, like different reasons why an open source project is supposed to be successful. So it might be a product team if we're talking about an open source startup, um, sometimes there's an open source project that is run by like an osbo or something like that. Um, then it might be somebody in the Osbo or whoever is the team behind that open source. Um, if you are just an individual who has an open source project that you want to be a success, you should be doing this, right? Um, but often, yes, so often team, uh, oftentimes it's product teams that sort of get this responsibility to do, to do user interviews. Um, I'm coming at it from a marketing perspective, like a marketing and sales perspec perspective, not a product. And there are some differences because product, our teams are really interested in like, Well, what do you think about this feature? And, um, from my perspective, that is a little bit of a mistake. because it's not getting the big picture and it's not really getting at the why. Like, um, e even asking a question like, you know, what do you think about XYZ feature is, it's almost a leading, almost a leading question. Cause it assumes that they care about X, Y, Z feature. Whereas, you know, if you ask a question like, so, you know, tell me why you started to use. This project, or like, I always like to start off conversations asking like, why were you looking for a project like this in the first place? Like what, what was the thing that not made you discover our project, but made you start looking and considering anything like in the universe of our project? So, zoom out a little bit, um, and then you can then, you know, you wanna focus in, but, but don't get so focused initially on. Teachers,
Avi Press:I find that for individual maintainers or people who are trying to start projects or companies on their own, this can be particularly very challenging. Um, cuz usually you need to have a lot of conviction about what you're doing to, you know, invest so much of your time and life into some product. And, um, in a lot of ways having that really narrow focus and even like blinders on on that. Goal that you are trying to achieve can be a very good thing. However, you know, if you are not headed in the exact right direction, that can definitely lead you astray as well. And so, um, one of the things that I've found very valuable with this is to really have a mindset that you're trying to get the negative feedback. Like that's really what you want to get as much as possible in some ways, and not being afraid of it, and like really leaning into it. Um, and that's sometimes where a lot of the, the most valuable insights can, can come from as well, But, Don't wanna be leading people into stuff, but getting very just comfortable with the fact that you're gonna hear some critical feedback that is maybe tough to hear. And
Emily Omier:sometimes though the your, your weaknesses quoted quote or your negative feedback can like be really important towards pointing you and towards what's like special about your project. Right. So this company I worked for recently is they are absolutely objectively. Behind their competition in terms of features, they're, they're not as feature rich as their comp, as their sort of main competitor. The reason is because they are incredibly anal about security. And so as a result it takes'em like three or four times as long to to deliver a feature. And yeah, some of their um, some of their users would say like, Yeah, we kind of wish there was little, little more. More feature rich. Right? And, um, and, and they were aware of it too. Like, you know, one of our weaknesses is that we, we don't have as many features in our development, uh, timeline is, is longer. Um, but then there's gonna be some people who really value the fact that they know as soon as we do launch a feature like it is, Okay. Maybe they would not want me to say like as secure as possible, but you know that it has been engineered to with security like at as the top priority. And so that means like they wanna talk about that. They wanna like really put that security for focus at the forefront.
Matt Yonkovit:So this is an interesting, you know, thing if you have users. And there are a lot of projects who start off, and maybe they have a small subset of users, maybe they don't know who those users are. So how do you go and get that information from, you know, an empty user base or a very small user base when you don't necessarily know who those users are? You're starting a project, Maybe you're just launching your company, you think. That this is what people want, or you think that this is what you know, um, is good for the community, or this is what the feature set is that they're gonna be excited about, but you don't necessarily know.
Emily Omier:Okay. You kind of have to have some users in order to talk to users. And the, the same with, with, um, you know, positioning and just talk to people, I guess
Avi Press:capture obvious. There
Emily Omier:you go. Yes, you can talk to people. Um, I mean, it, it is a good idea to talk to people who are gonna be in your target audience. Like before these are called like listening tours or something. Before you actually dedicate like six months of your life to or, or more, um, to building something. Um, but, uh, you know, when we are talking about, about really working on like messaging, positioning, getting feedback from users, um, yeah. I usually advocate, like, think about it as you're, you're trying, as you're thinking about going to market, not like at the point where your head's down. Developing because you, you do wanna get like something in front of people that they'll be able. To interact with. And the reason that
Matt Yonkovit:I brought this up is, you know, when you talk to a lot of companies who are starting to try and build that revenue stream, maybe they've got some open source users. They're trying to figure out how to position this in the market. They're trying to come up with something. That is unique. And generally what they'll come up with is, Oh, I'm the open source version of fill in the blank, or Mm, yes. You know, I'm the, you know, more secure version of fill in the blank or whatever. And they always kind of start with the competition and then just say,
Emily Omier:We're better than that. So those two examples that you gave are not the same. Okay. Because people pay money to be more secure and they don't pay money for open. So if you are the open source version of X, what you're saying is, I am the cheap and free version of open source of, of X. Sorry, I'm the, I am the cheap and free version of X. If you say I am the more secure version of X, what you are saying, you know, the message that you're sending by saying that is, I'm quite honestly like I am the more expensive and better version of X. People will pay money for that. Whereas, you know, once something is going into production, your critical systems are depending on it. How much do they really care whether or not you're open source? Honestly, most companies don't. They're like, No, I need to make sure that like my customer's credit cards aren't declined. Or like their shopping cards don't accidentally get emptied. When, whenever they try to check out, right? If you're going into a, if you're gonna be in production in a critical system, people, you know, companies are gonna wanna pay you. And the fact that you're open source, so developers will care about it, it care, it matters for your adoption. But at the point where you're really commercializing stuff, I, I think it's way less important. And I don't like when people position themselves as this open source act.
Avi Press:Well, let's dig into that then. There are companies that do this, uh, and definitely the, i, you know, to varying degrees of success perhaps. Um, but I suppose for the ones that, you know, are seeing some success and, you know, we could, could name a couple examples, but how do you, do you think that their success is more luck driven? Or like, what, what do you think makes some of these projects. Just seemingly just quite successful right away just because there is that, um, you know, like a big launch of like, Oh, we're open source this, and people just kind of, you know, gets a lot of buzz right away and they. Somehow try to capitalize on that. But what do you, So
Emily Omier:my take on this is that the companies that you do see being really successful, that you see sort of positioned, this is a little bit challenging cuz like we are here in the open source world and so we would tend to tend to see, like towards us, they would tend to position themselves as we're an open source Shopify, for example. Thinking of a specific example, they don't necessarily position themselves that way to their customers. And I think a lot of times they don't. So in that example, open source Shopify, which is, um, Medusa, um, they actually position themselves as more of a Shopify for like a, a mid-market company. They're not their, um, their market is, um, companies that. Exceeding the capabilities of just like plain Shopify, but they are not at the, they're not large enough to really get like a, a big custom development. And so they are not really positioning themselves as open source Shopify. They're positioning themselves as something that is more robust than Shopify to meet your, like, and it's more customizable than Shopify to meet your more complex. But not as expensive as getting something custom developed.
Matt Yonkovit:Yeah, and I think this is a good point because, um, I think people go. You know what, what you're saying is there's different messages and different ways to position yourself depending on the audience you're speaking to. Yes, definitely. And coming to all things open, like, we're here, you know, live, so, you know, if you hear background noise, that's why, um, you know, it's, it's more important to connect around the open source. side Then if you're going to go to the, you know, web summit, right? You know, which might be very e-commerce driven, it might be very commercialized. And from that perspective, those who are there, open source is a checkbox, not necessarily a way of life,
Emily Omier:or also like so MatterMost is another really good example of this. So yeah, they might come to Open Source Summit and talk about being an open source. Collaboration platform, or had they used to be an open source Slack, now they're much more robust. Um, so they might talk about open source Slack, but when they go to like a conference headed by the Department of Defense or something like that, like vendors for the Department of Defense, they're talking about being security first. Mm-hmm., they're talking about being most secure and that's, they're another really good example of like, maybe in our ecosystem we think of, oh, open source Slack. But no, they're, um, In when they're actually talking to customers and when they're actually thinking like, who are we for? They're thinking, you know, we are, uh, collaboration, uh, for very security focused organizations. I
Avi Press:think this is a very interesting and important topic here of a lot of open source companies. Um, There's a difference between the persona that is driving adoption versus the one that is making the decision to purchase the way that you position yourself, and like you said, the way that you're positioning yourself to these distinct groups might be very different. How would you, how do you think about this when you are talking with companies? This exact kind of problem and how you balance these two kinds of things. Cause it, it makes a lot of sense that if you're going to say a conference and you can play up a single value proposition a lot more, but like what do you put on your website? What do you put on, you know, these other places where it's a more general audience? How do you think about what you focus on?
Emily Omier:Yeah. That this is true and I do tell, tell, tell this to people like you. You only get one website homepage. You have to, you do have to choose at some point. Um, yeah, so it does depend a little bit like what does your adoption pattern look like in your particular, um, you know, in your particular company. Um, but I think, you know, you wanna focus on the things that, that are differentiating. So an example, if all of your competitors are also open source, you do not wanna put that you are an open source. Whatever it is that you are. Right, Because then that's, that's the same as as everyone else. Um, And so then there might be other situations where it would be appropriate to, to say open source, because that is the thing that makes you different from, from everybody else. So it really, you know, whether to emphasize or deemphasize the open source aspect, I think really depends on what your competitive landscape looks like and who tends to, to adopt. Um, there are buyers who care about open source. Um, sometimes it's not just, You know, it's not just free as in free beer. Um, but it's also that they can inspect the code and they know that you're not putting in a back door. I keep talking about security, but it's just like, this is something that people pay for in companies is, um, the ability to, to be really confident that this is, this is secure. Um, So, you know, I, I am giving a wishy-washy answer, but the, the, yeah, the, the truth is that it depends, You know, you have to really think, think through like what is unique about our particular offering. Um, whether or not you emphasize the open source does depends on what, to what extent that matters, um, to your buyers.
Matt Yonkovit:Yeah, no, it's a good point. And I mean, I think there's a lot of nuances to this, especially when you talk about what goes on your webpage, what's your kind of primary message position, , for the market. I think this is one of those things where there's a couple different things that you have, especially when you're talking about the single solo messaging, when you have to consolidate for the website for, you know, some sort of like vendor pitch whatever, or a VC pitch. There's two things that I see formulating. Number one is, You have this, you know, we really don't know what our go-to market strategy is. We're just going to go ahead and throw something up, and we're just gonna say we're better than everybody else. And, you know, or we'll copy our closest competitor word for word, almost. Um,
Emily Omier:she's, she's, she's sad about that. Don't do that.. Yes.
Matt Yonkovit:But it happens. Um, and then the other thing that I. Is everyone is so focused on the developer as the audience now. They go insanely technical and they put code examples up front and it's all about the code. It's all about that adopt, adopt, adopt, uh, from the individual user perspective. So I see those two patterns quite a bit. And what are your take in those?
Emily Omier:Yeah, so obviously I don't think that you should just copy your competitor word for word. That is not a good practice. Um, I do not think you should just say that you're better than everyone else, right? Because that's like, that's probably BS and everybody's gonna know that. Um, chances are you are better on some points and chances are that you are not as good on other points and being honest about that. Um, you know, going to win you a little bit of loyalty, but it's also gonna make sure that people aren't so disappointed when they figure out the, the way in which your, your project or your commercial product, um, is not as good. Um, so, and then about being the sort of insanely developer focused, I think the, the way that this pattern sort of manifests itself is almost like, not. Treating developers as humans. It's like treating them as robots and. I don't like that. I, I think that, you know, developers are as, just as human as everyone else. Developers are looking to achieve some sort of outcome with the project. And you do wanna, you wanna focus on what that outcome is, not necessarily how, like they, they will be interested in knowing how, but when we're thinking about like, webpage, you know, your homepage, um, that's where you wanna talk about the outcome. And then later, like you, then you direct them to the docs and talk about how it is achieved.
Matt Yonkovit:And this is interesting. So when you talk about that and the outcomes, Yeah, I, I find a lot of projects focus on the exact same outcomes. Right. And they're, they're all trying to say, Oh, developers, you're really busy. Come use my as a service and it'll just be super easy. And then you never have to write, you know, code for XYZ again. And it's just so much easy. It just plugs right in. It just works. And you see that repetitiveness over and over across projects. How do you differentiate when that's your driver?
Emily Omier:So here's the thing. Um, if you zoom all the way out, Yes. Like all these tools, probably every single sponsor here, like has this, this same sort of like all the way zoomed out goal, improve your developer productivity. Yeah. It like accelerate innovation. Like I bet we could just like, we can just slap that on every single like booth here. This is true. Um, so saying that you like accelerate innovation is meaningless, but uh, you know, your project is going to have a very specific outcome that. Plays into this like theme of accelerate innovation. And what you wanna do is you wanna sort of find the right granularity and you can talk about outcomes, you can talk about technical outcomes, you can talk about outcomes in a technical manner while still talking about outcomes in a way that doesn't sound like bs. And that doesn't sound like everybody else, right? So, If you want to, um, easily understand the relationships between all of your cloud resources, for example, being able to, you know, if you wanna get a picture of the relationship between all your cloud resources, um, that in and of itself is an outcome, right? And. Yeah. You know, maybe, maybe that accelerates innovation or some, something like that, you know, But that's, that would be really zoomed out. Um, so you wanna focus on the very specific outcome that your project provides.
Avi Press:I guess one follow up that comes to mind then is, What do you, what do you recommend companies do when there's a question of how to position the open source offering versus the commercial offering and how those things differ? Cause you, you know, you, you still wanna, you wanna market the, the open source side still very well. Oh, it's great, but you still also want to provide additional value in the commercial side, and so, Yeah. How, how do you, how do you think about that trade off, uh, in terms of, you know, what you're putting all of that positioning effort into or how you talk about them as separate entities?
Emily Omier:Yeah, so this depends. Again, it depends a little bit on the goal. So sometimes, you know, a company will come to me and they'll be like, We have this open source project. Super, it's super successful, super, super successful. But uh, now, you know, we don't have any money cuz like nobody's using our commercial offering. So in that situation we would focus on the commercial offering. Um, I've had the converse happen too, where a company ha comes to me and says, Look, we're an open source company. We have this open source project. We have revenue. Yay. But our open source project seems to be underperforming. And we would like to make, you know, we would like to have our open source project be quite a bit more successful. We'd like to put some resources in that. So let's focus on that. Um, however, ideally, You will have your company positioned as sort of in, in some sort of overarching positioning that's gonna be sort of applicable to your company. And then you'll have more specific positioning for each of your, each of your products, shall we say. So maybe you have a, um, open source project, maybe you have a commercial that, the commercial offering that's on prem, maybe you have a cloud offering. Um, so each thing that's in your, your product line is you're gonna have a separate positioning for. Yeah, very related, but separate.
Matt Yonkovit:Well, Emily, thank you for hanging out with us at All Things Open. I know we have to skedaddle here because we've got conferences coming up and um, we've got people, uh, starting to mingle around. But we do appreciate you sharing some thoughts on what you're gonna be talking about and also on what's happening, um, in the messaging, positioning space around the open source side of things, uh, is always. So thank you so much. Yeah. Yeah. And until next time, um, we hope that you will like, subscribe, follow us on all of the socials. Uh, we appreciate it. Talk to you later.