Consultant Emily Omier discusses her work with open source companies on product strategy and positioning. She explains the unique challenges and opportunities such companies face, particularly the tension between commercial offerings and open source projects. Emily highlights the importance of solid product strategy, shares her process from customer interviews to leadership workshops, and addresses common misconceptions and struggles companies encounter. Additionally, she touches upon the strategic reasons for open-sourcing software.
“A lot of the work that I do is not about going in and telling people what to do, but rather about helping surface the knowledge that they already have internally, but they aren't really able to take advantage of because they're not asking themselves the right questions.”
— Emily Omier, Consultant and Host of The Business of Open Source
Katherine Druckman: Hey, Emily, thanks for taking time to talk to me. Really excited to talk to you about all of the things you've experienced and about what you do. If you wouldn't mind, give us a little bit of an introduction.
Understanding Product Strategy in Open Source
Emily Omier: Well, first of all, thank you so much for having me. I'm Emily Omier, I'm a consultant. I work with open source companies on their product strategy and their positioning. And what this means is, among other things, figuring out how do you manage the tension between the product, which is the thing that you charge money for, and your project, which you don't get money for.
And I've come to the conclusion after working with open source companies, more focused explicitly on positioning for several years, that positioning is really critical to product strategy, but there are some other things that fit better in product strategy than in positioning that are really critical for open source companies in a way that they aren't in a non-open source company.
So this idea of product-project tension is something you wouldn't have if you were just a straight proprietary software company. And I would say one of my interests is understanding what is different about open source companies compared to other straight proprietary software companies and how to take advantage of the opportunities that only exist for open source companies and also manage the risks.
And I really think that the key to succeeding as an open source company and doing both of those things, managing risk and taking advantage of opportunity, is having a really rock solid product strategy.
Engaging with Companies at Different Stages
Katherine Druckman: What advice do you typically... Actually, let me rephrase that. When you start working with a company, do you typically work with people who are early stage or do you come in the middle or how does that work?
Emily Omier: My ideal situation is to come in once you have either a project or you have a product, and at the very least, you're actively developing the second part. So that could be you have a product, you're currently a straight proprietary company, but you want to open source a significant portion of your code base and you want to figure out how to do that.
Or you are an open source company already. You already have an open source project, and either you are actively developing your commercial offering or you already have it. The key being if you're just heads down in development, we haven't even released our open source project yet, it's not really the time for me to come in. You need to have at least something for me to really be able to dig in.
Katherine Druckman: Where do you typically start?
Emily Omier: I start by interviewing customers and interviewing users. That's the first step.
Katherine Druckman: Excellent.
Workshop and Internal Knowledge Surfacing
Emily Omier: And after that step, I run a workshop with the company leadership. A lot of the work that I do is not about going in and telling people what to do, but rather about helping surface the knowledge that they already have internally, but they aren't really able to take advantage of because they're not asking themselves the right questions and/or because there's different pieces that are in the heads of different people in the company and they aren't really able to pull it out and access it in a way that's actionable.
I run a workshop with the company leadership and we run through things like: “What in your experience is unique about this company in terms of the attributes? What does that lead to in terms of differentiated value for a user? What outcomes can they get with you that they can't get from anybody else?” And because I work with open source companies, the really interesting thing is, what is the difference in value that someone gets from using your open source project versus using your commercial offering being a customer?
And I really like to focus on making sure that there's a situation we can identify where the open source project is the best option for somebody and where the commercial offering is the best option for somebody. And really understand what those two situations look like and what the characteristics of the people who would find themselves in those two situations are.
The goal is to both help communicate internally so that everybody feels comfortable with the fact that, there's this situation. Our open source is the best. That's what we're really going to focus on in our outreach, our dev rel. Anything that's focused on our open source community, we're going to focus on that situation where the open source project is 100% the best.
And then if there's anything we're doing in terms of sales, we're going to make sure that we're focused on our commercial offering when the situations and the individuals who are likely to get the absolute maximum value out of the commercial offering so that the team doesn't feel like it's in competition with itself as much as before. This can also be communicated externally.
And then I mentioned, I see what I do as product strategy because ultimately everything here is used to make product decisions. So differentiated value is how you decide, “what are we going to prioritize in our roadmap? What are we going to put in our open source project? What are we going to not put in our open source project, but put in a proprietary if we're doing open core and a proprietary option?”
Or it could just be like, “what are we going to put in our project? What are we not going to put in our project because that's going to erode our support or our services? And how do we make that decision in a way that's transparent internally, but also transparent externally?” Because there can be a lot of tension sometimes in open source communities about not being sure, why is this company acting like this?
Why is this thing not being released into the community edition? And really just trying to help the community understand this is what we see as who the project is for and the value that it provides. And if you are in that situation, use the community edition. However, if you meet XYZ criteria, you're going to want to pay us, and being really transparent about that.
Common Struggles and Misunderstandings
Katherine Druckman: Do you find that there are common struggles across all of the different types of companies that you work with? In other words, common areas of misunderstanding even.
Emily Omier: Yeah. So I would say it's remarkably common for people to not understand what is different or not appreciate what is unique about their product and even about their company or their team. And this often manifests itself in just not being sure how to respond when somebody asks, why should we choose you over a competitor? And what's really interesting as a consultant is that sometimes I go into companies and it is just abundantly obvious, and yet they can't see it.
And when I say abundantly obvious, within the first 15 minutes of having this conversation, it's obvious to me. Or sometimes it's the same thing. I just worked with a company and they have an open source project that you can run yourself. But because of what they do, it requires using a data set. And in this case, it's a routing company. Sorry, it's vehicle routing optimization. So in the open source version, it's designed to work with OpenStreetMaps data.
Well, they also have an API that you can use to be a customer. And they'll run, they'll manage the data aspect, and the data is higher quality. The data that they use for their customers, for their API customers is higher quality, which means that you get more accurate timeframes for your routes. So what's interesting about this is that is something that people care about really obviously. None of their customers that I interviewed realized that that was a differentiator between the two things.
I never would've guessed just from looking over their documentation, their documentation ReadMe, et cetera, for the open source project or their website, I never would've guessed that this was the case. And it was like, why aren't you talking about this more? But I think people often just don't see or don't appreciate the things that people can really care about, that customers can really care about.
Community Building and Its Importance
Katherine Druckman: Let's talk a little bit about the open source communities within these companies, right? If you have an open source project, ideally, I'm guessing, that the people you work with would like to build some community and get some outside contribution and find collaborators out in the wild, so to speak. What advice do you typically give them there?
Emily Omier: What's really interesting about that is there's another aspect of what I do is helping people define what they expect to get out of their open source project in terms of business value for their company. And depending on the answer to that question, you may or may not want to focus on community building. So there are definitely situations where the community isn't really that important, particularly if the reason you have an open source project is around transparency.
And then this is a real value that customers can get out of open source, that their customers are able to see and run and really understand what their software is going to do ahead of time. If that's the case, the community is beside the point. However, yes, in the majority of cases or in many cases, it is important to have a community. I would say it's not super common for companies to actively want like a large number of code contributors that can end up actually being a bit of a burden for a lot of companies.
I wouldn't say that they necessarily like actively have a program around trying to create a contributor ladder so that they get more contributors, especially code contributors. I don't think they're necessarily like opposed to it either. But the biggest piece of advice that I'd give clients around community building is thinking about the community itself either as a product or as a part of the product. Because when people join a community, they are giving time.
And you want to make sure that you're offering them something that's of value if they're giving you your time. So what is the value that someone gets from being an active member of your community? Whether it's answering questions on your Slack or your Discord, or whether it is improving your documentation, or whether it is contributing code. So what do they get out of that experience that they don't get from just using your project?
And you don't necessarily have to use that as part of a communication strategy, but it does influence how you structure your community, what you do, and what sorts of actions you do to try to build community. So being able to understand that is really important. And sometimes it's things like our users tend to be really isolated in their jobs. They tend to be the only person who does X.
And so it's really important for them to be able to connect with other people who are solving the same problem. That can be a really powerful motivator to join a community. And if you can be the place for people who are in that situation, especially because that makes you a place, it's not just connected to your technology, but it allows you to be a leader in whatever ecosystem you play in.
Katherine Druckman: Fantastic. When your fellow users become advocates for each other and helpers and mentors, it's a really great situation to be in. Have you ever been in the scenario where you are working with a company who wants to open source a project and has not yet done that?
Emily Omier: It's really interesting because I have a lot of people who reach out to me and want to talk about it, but I haven't actually ever had them hire me. So that's why I would be interested to do that, but I haven't actually had somebody follow through and hire me to do so. But ultimately, it's a very similar problem.
Open Sourcing Projects: Reasons and Benefits
Katherine Druckman: What are your thoughts on why would you recommend somebody open source a piece of software that they've built?
Emily Omier: Yeah, so it goes down to understanding what you expect to get out of that open source project. And the advantage in that scenario is that you're only going to do that if you're clear on what that answer is. Whereas a lot of companies that start with the open source project, they don't really know what they want out of the open source project in terms of business value for their own company.
That's the starting point, why are you even considering this? What do you expect to happen when you do open source it? What are the risks that this is going to bring up for your company? How do you mitigate them? And what do you think the opportunities are?
It's pretty common for people when they reach out to me thinking about open sourcing, something for them to say, "In our ecosystem, one other competitor or more than one competitor has created an open source project and it's worked really well for them. And so now we want to do the same." I would say that's mediocre reason to do it. You don't want your sole reason for open sourcing a project to be like, "Our competitor did it."
And you want to make sure that you understand why, or at least have a hypothesis about why it worked for your competitor if you're going to just follow the route because your competitor did it. But oftentimes it can be like, first of all, it can be an ecosystem play. Having an open source project is really strong if a part of your strategy is to create an ecosystem around a technology.
Having a foundation of an open source project is the way to do that, basically so if that is your play, you probably do want to create a project out of your product, out of some portion of your product. The other thing is like if adoption is something that you're really struggling with and you really want to get a lot of adoption, open source, again, there's no straight line from adoption to revenue.
But if adoption is a thing that you're struggling with most, creating a legitimate open source project can definitely help with that. A third reason for having an open source project is feedback, tightening the feedback loop with users. That's something that a lot of people cite as a reason for creating an open source project. And that I think is one of the best because it is true.
Maybe you're not getting the code contributions, but contributions to your community can also be discussions and feedback, and that can be super valuable for companies.
Experience at All Things Open
Katherine Druckman: Tell me how your experience at All Things Open has been.
Emily Omier: This has been really cool. I also have a podcast called The Business of Open Source, and I have been recording onsite, the first time I've done this, at All Things Open. Yesterday, I gave a talk and then I was on a panel in the afternoon.
Katherine Druckman: Is this your first All Things Open?
Emily Omier: This is my third All Things Open actually.
Katherine Druckman: Yeah, it's been a nice event. A lot of very interesting people gather at this event. I think that's definitely the highlight. Is there anything that you wanted to talk to me about that I didn't ask?
Emily Omier: Gosh, I don't know. I should probably make a plug also for the conference that I organized, which is called Open Source Founders Summit, which is a very small conference for founders and leadership of open source companies. So if that is you and you're listening, look up Open Source Founders Summit.
Conclusion and Upcoming Events
Katherine Druckman: Where and when?
Emily Omier: It is in May in Paris.
Katherine Druckman: Oh wow! That sounds like a great event. Open source and croissants.
Emily Omier: Hopefully for reasons more than the fact that it's in Paris.
Katherine Druckman: Well, hopefully, yes. Ideally, yes. Well, fabulous. Thank you so much for coming over and sitting down and sharing everything with us. We really appreciate it.
Emily Omier: Thank you so much for having me.
Katherine Druckman: You've been listening to Open at Intel. Be sure to check out more about Intel’s work in the open source community at Open.Intel, on X, or on LinkedIn. We hope you join us again next time to geek out about open source.
About the Guest
Emily Omier, Consultant and Host of The Business of Open Source
Emily Omier is a consultant who helps open source startups accelerate growth with killer positioning. She also hosts The Business of Open Source, a podcast about building open source companies and is the founder of Open Source Founders Summit, a business-focused conference for leadership of open source companies.
About the Host
Katherine Druckman, Open Source Security Evangelist, Intel
Katherine Druckman, an Intel open source security evangelist, hosts the podcasts Open at Intel, Reality 2.0, and FLOSS Weekly. A security and privacy advocate, software engineer, and former digital director of Linux Journal, she's a long-time champion of open source and open standards. She is a software engineer and content creator with over a decade of experience in engineering, content strategy, product management, user experience, and technology evangelism. Find her on LinkedIn.