Emily Omier Interview | Craft of Open Source Podcast

Positioning for open source startups is directly connected not just to their free resource but also their commercial strategy. How should business leaders approach this to yield the best results and maintain a well-performing team?

In this episode, Positioning Strategy Consultant for open source startups Emily Omier talks about keeping teams in alignment and in the same feedback loop. She explains how this approach can help them navigate through the complex mind games involved in these projects and why she considers the government as the best open source clients out there. Emily also shares how she sees the industry progress in the next half decade in terms of dominance and refutes three fallacies about open source projects.

---

In this episode, I have a super interesting guest with me, Emily Omier, who has a very interesting background. Emily, you've got 41 experiences or work positions on LinkedIn, which is easily a record whenever I'm researching people. You can speak six languages. Are there any other numbers that you think you would win on with your background from my other guests?

I might win in countries that I've lived in. That's probably something that I would win on in most cocktail party discussions.

What number is that?

I'll go in chronological order. I'm American. I'm from Oregon. I’ve lived in Switzerland, Russia, Spain, and France. I live in France again. Also, in Nicaragua. I spent six months in China. I don't know if that counts.

That counts. That's pretty good. I can count three and they're far less interesting countries. I was only three months in San Francisco at the end of the dot-com boom. Emily, do you want to give us a bit of a background of you? Your background is super interesting. You've worked at all different places from MIT to CloudBees. Is it writing that brings your work together?

It's a little disingenuous as I have worked at these places because I haven't had a job forever. I have had a job before but it's been a very long time. I've worked as a freelance and then more as a consultant for a lot of different companies and capacities. How interesting my background is depends on how our back we go. I spent my twenties doing a bunch of random stuff, which is true but I see the connections being made.

I went to graduate school here in France. I went to journalism school which is why you see a lot of writing-type things in my background. That's what I would say is my background as a journalist. What happened is I never successfully figured out how to make a living as a journalist. Being desperately poor is okay when you're younger but it starts to suck even worse when you have a kid and stuff like that.

At some point, I decided I needed to get out of journalism and apply the skills of being a journalist to something else. That's how I started on the path that led me to what I'm doing. What happened is I started writing for some tech-focused publications and doing more content marketing and marketing communications for tech-focused companies. This was several years ago. How much honesty are you looking for here?

You mentioned it so it’s 100%.

The reason I mentioned that is the root of this transformation was not in a vacuum. I had been a journalist for a while. I sucked at making a living at it. I had a kid. My husband and my mom died. I lost all of my safety net. I was like, “I have to get my act together.” If you're looking at an interesting background, it's interesting.

I started doing marketing communications for companies in the cloud-native space. That happened because I started working with The New Stack. I was writing for them. They are heavily focused on very modern software development technologies. I started getting a lot of connections and some expertise in the area. I started working with companies in that space on marketing communications.

As I worked more with companies on their marketing communications, what I realized was that a lot of them had problems that went well beyond their marketing communications. What would happen is they would say, “We want to do a series of blog posts.” I'd be like, “What do we want to say in the blog post?” They'd be like, “We're not sure.”

I’d have the fourth company say, “Let's do a white paper on Kubernetes 101.” I was like, “First of all, this is so boring. Second of all, it's not differentiated.” If every company that I'm working for is writing a white paper on Kubernetes 101, the value that they're getting out of it is not great. Often, there would be a disconnect between the CEO and the marketing person about, for example, what the differentiated value is for the company or even what the company's point of view is.

I had this horrible experience where I'd worked with this marketing person to write this white paper. We finished it. It goes to the CEO and the CEO is like, “This is not our point of view at all. We want to say something that's a 180-twist from what we're saying in this white paper.” I was like, “Do you guys talk to each other? How did this happen?”

You feel bad as the person who wrote this white paper because they’re like, “Your work is shit.” At that point, I have a little bit more self-confidence in that. I was like, “This was not my fault. This was your fault. There's a problem with alignment communication.” That's how I ended up doing the work that I do, which is no longer writing. I no longer focused on the cloud-native space.

I started working with companies on getting their messaging right and then getting their positioning right which is one level up from that. It's almost more in the commercial strategy area, the type of work that I do. As I started working with companies on their positioning, in the cloud native space, there are a lot of companies that are open-source companies but not 100%.

What I noticed was that those companies that are open-source have a different positioning challenge. It’s more complicated and interesting than those that are not open-source. I ended up switching the focus of my work to working with those open-source companies. 1) It's more interesting. 2) It's harder for a company in the open-source space to take existing resources or work with a consultant who's not in the open-source space and apply that to their business because their business is different.

‍

Whereas, if you're making a software-defined storage solution for Kubernetes or something and there's no open-source component, I don't think that just because you have this very technical product, it's going to be a fundamentally different positioning exercise than any other enterprise software. Whereas with the open-source, it is. That's the evolution of my career in a nutshell and how I got to working with open-source companies on their positioning.

Positioning in the context of an open-source business is very much connected to commercial strategy because it's about defining the positioning of your project, product, and entire company. Also, the relationship between the two. How do you manage the tension between your open-source project and commercial product? What's the ICP for each one? What's the overlap? Is there an overlap?

What's the differentiated value of your project and product? How does your product add value that goes above and beyond your open-source project? Also, the company. You have to have an umbrella positioning for your entire company. You only get one home page. You have to have a story to tell about your company that encompasses everything. That's what I do.

You mentioned cloud-native. I guess at the time, those people you were working for those companies and projects didn't define themselves as cloud native. I'm trying to think about how long ago it was when I first heard of the term but it's interesting because I'm hearing you say that. I was at KubeCon in Amsterdam in the spring. I can't think of a single company there that didn't have a significant open-source component.

It's interesting because although the conference is called KubeCon, Kubernetes is the sun and all these different projects and companies orbit as planets. Maybe it's more relevant than those commercial open-source companies. It's interesting. Those two things are very wrapped up together. I can't think of a single company that was purely a commercial entity.

Portworx is a storage company. They were acquired by Pure. They had no open-source component and were a long-time KubeCon presence.

Maybe over time as well, those companies are becoming less common. It's interesting as well. Most of the people that I've spoken to on this show have backgrounds where they were either heavily involved in open-source or had used it for many years. They were hacking around with Linux and all this stuff. It's fair to say that you've joined that community much later.

It’s got an interesting perspective on it because your time slice is shorter, which is interesting. It feels like things have accelerated a lot more in terms of commercial open-source businesses in that time frame. There's been a lot of IPOs and unicorn companies like GitHub, HashiCorp, and folks like that. You've got some experience working with cloud-native companies that weren't open-source but how do you see that progression in the last few years in terms of the dominance of that?

I've left some things out. My first experience with open-source was quite a bit earlier. I had an idea when I was living in Spain to create podcast audio tours. If you're visiting a city, you download an audio tour. This is super easy now but at that time, there was one person who was doing this. I was like, “I'm going to produce this and build a company around it.” I did not build a company around it. It was a total failure.

At that time, I'm not a developer. I had no experience with building websites. I asked somebody, “I want to build a website. How do I do it?” This person was like, “You should use Drupal.” I want to note here that this was very bad advice. Knowing what I know, the person should have said, “You should use WordPress.” Incidentally, both of those are open-source but I went ahead and built a website with Drupal. That was my first experience with open-source.

I went on to build several more websites with Drupal. My first experience with open-source was being a Drupal user to build that website and then a couple of others. I wasn’t super involved in the community but I knew my way around. I was very aware of the whole Drupal ecosystem. In that sense, I'm a newcomer but I was pretty aware of the open-source ecosystem at least in terms of using it for something as simple as building a website a little earlier on.

In terms of the people you're working with at the moment, can you give us a flavor of the people that you're working with?

I am on the advisory board for a bootstrap company called Karrio. I'm going to talk about them because they're the only company that I’m in a long-term relationship with. Most of the time, my work is we do a workshop and then we finish. Karrio has an open-source shipping API. If you are a retailer or one of their use cases is an online pharmacy, you need to ship stuff.

You have to print shipping labels and things like that, which means you have to handle sensitive data. It's even more sensitive if you're in a regulated industry like you're a pharmacy or something like that. You can use Karrio to help manage that shipping process and ensure that you're protecting their data. It's a good example of some of the advantages that are baked into open-source already that people don't always talk about, which is around transparency and being in control of your data.

That's why you find that a lot of open-source companies do well in industries that care a lot about privacy and industries that are heavily regulated. This isn't the case for Karrio but in general, governments are good customers for open-source companies precisely because governments tend to care deeply about things like privacy and security in a way that isn't just checking a box. They will want to verify what your code is doing. That's an advantage that open-source gets out of the box which is much more difficult in proprietary software.

Governments are good customers for open source companies because they care deeply about privacy and security.

We started hacking on the projects as a side project a few years ago and that was in a private GitHub repository. I don't remember the company that it spun out from. We made it open-source. We had two branches that lived in two different places. One lived in our private GitHub repository and that was the one that we worked on. The other one was GitHub where it was like, “This is open-source.”

For some reason, culturally, we carried on working on the project and committing to the private repository. Once every few weeks, we push to the GitHub one. After a while, we were like, “Why are we doing that?” It was because we culturally had come from a background of having the software that we were writing in and the issues that we were raising in private.

One of the most important decisions or changes in behavior that we made as a project and subsequently as a company was, “Stop doing that. Take all the issues that are in GitHub. Take all the branches, pull requests, and push them into the GitHub repository. Archive your GitHub to a private one and work on everything in public.” We were like, “Can we do that?”

At that time, we didn't have a huge number of issues. I was looking through them going, “No. There are things in here that are private.” We checked through, made sure of that one, and then pushed. That changed. That was super fundamental. I didn't realize it at the time because no one was immediately like, “This is much better,” but then I realized that we were selling the platform to commercial organizations who mainly were super interested in data privacy, openness, and control that they have over their infrastructure.

I was like, “They're all the issues that we've got. You can go and look at them.” If a customer finds an issue, I'm going right into our public GitHub repository. You don't have anything private in there but that's the pull request for the fix that we worked on. It will be public and you can follow that. That was a revolutionary thing for us as a project and for our customers because they were like, “I can see you working on it.” Sometimes they're even like, “Work on it with us,” which was the thing that blew my mind.

That was a change in the vibe of the company. It was like, “Stop doing everything.” We've got almost everything that we can have open. There are a couple of projects that we have that are private around the SaaS infrastructure and stuff like that. That mindset shift was fundamental to the business. It felt like to me that was the moment we became a proper commercial open-source business. Before that, it felt like we were pretending to do that but we weren't doing it.

One of the things that I've been increasingly interested in is the interplay between sales, marketing, product, and engineering. In a lot of organizations, you see those four things divided into two buckets. You have engineering and product, and sales and marketing. In any company, you should have product, sales, and marketing very closely aligned, particularly in an open-source company.

First of all, everything's more complicated in an open-source company because you have the free thing and the commercial thing. It's a much more complicated interplay but another thing that isn't discussed as much as it should be is that your engineering decisions have an impact on sales and marketing. Your engineering decisions can be part of your communication strategy, for example.

Another thing I work on with companies is articulating their point of view. The decisions that you make from an engineering perspective, if you were making proprietary software, your customers do not care as long as your thing works and scales. How you achieve that nobody cares. If you have an open-source project, the decisions that you make from an engineering perspective starting with what language you're writing this project in matter dramatically.

In an open source project, every decision you make from an engineering perspective, starting with the language you are writing with, will deliver a drastic impact to the entire thing.

You can write a project in a particular language and have it bomb just because you used this weird language that nobody knows how to use and they're like, “I'm not learning another language to interact with your project. Forget it.” That happened to a company that I worked with. That wouldn't happen if you had proprietary software because they'd be like, “It works. Who cares?” Understand that all of these things are related to each other and get even the engineering team to think about how my decisions are impacting our sales strategy.

The feedback that our sales team is getting from customers, how can we integrate that into our engineering process, decisions, product roadmap, and what kind of marketing campaigns we're doing? Get all of those things to work together and all inside the same feedback loop. This is one of the things that I'm interested in when I work with companies. We get a point in time alignment between all of those things but I have a suspicion that it doesn't stay for quite as long as it would like to.

I found that there's not a natural equilibrium between those things. They feel like they're constantly out of balance. You're constantly nudging them back one way or the other or something like that. That's how it's felt to me. You never feel like your pricing is perfect. You're always thinking, “Maybe it's wrong.” There's no way of validating that it's right, which is annoying. When you say a point in time, can you define what happens there and what you did? What do you mean by that?

I'm not in a long-term relationship with most of my clients because we work and do a workshop together. We get a positioning strategy in place that defines, “This is what our company stands for. This is our company's point of view. This is the target market for our project and commercial offering. These are the pain points that we're addressing for each thing. For the open-source project and the commercial offering, this is the differentiated value.”

The key as we're working on this is that we're bringing everyone together. Whoever is responsible for sales, marketing, product, and engineering, we're bringing all of those people together. We're working on doing this as the whole leadership team. They get that alignment because everyone is working together and everyone buys into the final strategic document that we develop.

I would like to think that alignment will last. Getting to that alignment even at a point in time is valuable. There's a strategic document that we do together so people can refer to it. It's not just living in somebody's head, which is what a lot of people do instead of having a positioning document. However, they're still not inside the same feedback loop. You still would have the sales team, the salesperson, or the CEO, depending on how big the company is, to have a sales conversation.

Something happens. Maybe they close the deal. Maybe they don't. At any rate, there's some learning from that sales conversation but does the engineering team figure out what that learning is? Does the product team have an easy way to figure out and know what happened? Not just in one but the pattern of what's happening in these conversations. In most cases, no. How long is that alignment lasting? I'd like to think it lasts for a long time but I'm not sure how long.

It’s interesting what you said about these companies only having all these projects and one homepage. My instinctive reaction to that was like, “No, we've got two. We've Flagsmith.com and then GitHub.com/Flagsmith.” As an engineer, I feel like that's what I am. A lot of me cares more about GitHub, how many stars we've got, what our community engagement is with the projects, and things like that.

With my engineering hat on, I’m thinking, “Is it harder to bring the non-engineering disciplines along with that?” Those things that are in tension, what causes that tension? Are there patterns to things that cause that tension? In the Flagsmith case, the tension from my point of view because I'm responsible for the product more than anything else is like, “Do we work on the pull request that the customers ask for that's wanting to pay us money for it,” or, “Do we work on the thing that helps the open-source projects?” That's the thing that I'm constantly pricing. I never feel like, “We’ve perfectly threaded that needle this quarter.” You never feel like that. You look back and you're like, “We neglected X over Y or vice versa.”

The first way that I'd answer that, and I think this is exactly what you're saying, is rather a tension between sales and marketing for your sales and product, it's often a tension internal to the leadership. I had a conversation with a company that ended up being a client but this is in one of our initial conversations. They were talking about some decisions that they had to make. I asked, “Who's advocating for each of these decisions?”

The response was, “We're all advocating in both ways because the tension is internal to each of the founders. It’s not two founders arguing but each founder arguing.” One of the interesting things about open-source companies to me is that tension exists inside most founders of open-source companies rather than being, “Our sales team is saying X and our product team or engineering team is saying Y.” With that said, one of the challenges that can come up is there's a not a huge pool of salespeople who are experienced with open-source sales.

‍

What happens is that as the company scales and you need to hire a sales team or a marketing team, the chances that you're going to hire somebody who's experienced with this type of company is possible but not likely. It's not super likely that you're going to have your whole sales and marketing team full of people who are experienced with open-source companies. This is even true if we're talking about product managers.

Chances are that you're going to have product people, salespeople, and marketing people who are relatively new to the open-source ecosystem. I don't think it's true with engineering so I'm leaving them out. Your engineers know what open-source is all about. On the other hand, they're probably less attuned to how are we going to make open-source profitable. That can create a big problem because your salespeople don't understand necessarily the business model unless you tell them.

You have to do a lot more hand-holding about, “This is our business model. This is why open-source matters to us. This is how the things are related. This is the framework for how our open-source project and our commercial product work.” I'm giving a talk about lessons from working with founders and operators of open-source companies. The first thing that came to mind was that running an open-source company is a mind game even more so than running a company in itself.

That resonates with me. What you talked about with commercial companies or the commercial projects as well, commercial businesses have one type of customer but I feel like we have the open-source folk who are contributing to it and the open-source folk who are running in. Also, the infrastructure and platform folk who are our customers who are running it. We've also got the engineers that are logging into the platform. That's four types of people who are in tension with each other. Thinking about it, if you were a private company, life would be so much easier because you have no tension there in that regard at all. You've got one person that you want to make happy.

The other thing that is underappreciated is it's a tension for you because you're running the company. You're the CEO. It's a mind game for you. Being the CEO of a company is always a mind game. It's a mind game also for the whole team in a way that if you're running a proprietary software company, I don't think it’s necessarily a mind game for your sales team but it can be if your sales team is new to selling open-source. There will be things that do not make sense to them unless you very explicitly explain. They will lose deals.

With Flagsmith, we had three guys come on board and invested a bunch of their time in the business. They all had Valley Commercial go-to-market backgrounds. I remember we had one that would have been a massive deal for us in our early days when they started working together with me. We're good with the open-source project and they were tearing their hair out going, “This is a disaster. What are we doing working in this model?” I was like, “Just wait.”

A year and a half later, they came back and were like, “We've got six deployments of Flagsmith globally. They're a multinational company. We need to buy the enterprise version.” I was like, “There you go.” It was very hard for me to explain that. Having six open-source deployments was a complete failure. From a sales point of view, it was but from a holistic view, to me, six deployments of the open-source platform were a complete success.

It's not adding to our topline but there are about 500 engineers using the platform and 6 different platform teams that I've got experience running it. The only thing we need to do to give them the enterprise version other than sign a contract is to give them a different Docker image. That's one of those learnings. You can only do the hard way which is to go for that experience at that call where they're like, “This is a disaster. What are we doing?” I'm like, “It's fine. “You've got to believe.” They get it but it was a fun few months where we were like, “What are we doing?”

That's exactly the situation that repeats itself over and over. You have to be aware of the mind game that you're forcing your team to play as well and make it easier for them. They don't go into it like you as a founder go into it knowing that this is going to be a mind game. However, your team doesn't necessarily know that. If you want them to be successful, you want to set them up first of all with all the tools you need to make it less of a mind game.

Having a clear framework about how the open-source and commercial products relate to each other is one of the ways that you do that. Be clear about how the open-source contributes to the business goals explicitly. Do not assume that everybody understands that implicitly is another way that you do that. That helps set those people up for success and hopefully, not tear their hearts or quit and leave because they don't understand what the hell is going on.

For the people who are reading who feel like they're in that struggle at the moment, how do you go about talking to the companies that you work with about that? How do you start on that? It's especially interesting as well. Most of the people that I've spoken to on this show, I can't think of any that didn't start as pure open-source projects that didn't have a commercial inkling at their inception. You've also got the private companies that are coming in from the other direction. How do you go about working with the companies that you work with trying to make that progression?

There are a couple of things. The first thing is the process that I go through is figuring out what's the differentiated value of the open-source project. You want growth of the open-source project. What's the differentiated value of the commercial offering? What outcome are people getting from each? The thing that I like to pay attention to is always the delta between the two. If you cannot show me a delta between your open-source project and commercial offering, you have a problem. There has to be a difference.

The bottom line challenge or key to monetizing an open-source project is how you are going to provide value above and beyond your open-source project. That's all you have to do. Understand the differences in pain points between project and product, and the difference in ideal customer or ideal user. Also, understand who the buyer is for your product and how that's different from the user for your project. It boils down to differentiated value. It’s super important.

The key to monetizing an open source project is learning how to provide value above and beyond to your target audience.

Core market category. What's the fundamental way that you describe your open-source project? How does that differ from the fundamental way that you describe your commercial product? There should be a difference because there should be some difference in the outcome that somebody is getting and the value that they're getting from this project. There should be a difference between the fundamental market category description of those products and projects.

This is something that you should work together with sales, marketing, product, engineering, customer success, and community managers if you have it as well. Get something that incorporates every type of feedback that you're getting as a company, not just one type because a salesperson gets a certain type of feedback. A community manager gets us a different type of feedback so you want to make sure that you're getting everyone on the same page.

The other thing is understanding how your open-source project contributes to your business outcomes. A lot of people skip this step or at the very least, they skim over it and don't make it explicitly clear to the team members who are not experienced with open-source. There are different ways that an open-source project can contribute to your business outcome. It's not all about, “The open-source is driving adoption. We're going to magically convert 1% of those users into commercial customers.” It's not always like that.

Sometimes we have this open-source strategy and approach because transparency is important to our customers. How many people use our open-source project? It doesn't matter because the reason that it's useful to us is that when we're negotiating a deal, the customers can take a look at our code, know exactly what it does, and sign on the dotted line. It expedites the process dramatically but that's a different way that your open-source project provides value. You want to be aware so you can evaluate if it's working. You won't know if it's working unless you know how it is supposed to work.

How do you see things coming into the future? One of the things that's been more of a theme that I've been talking about is the VC winter. It's more the case of the cheap money's gone. Those days are long gone. I'm in London. The inflation rate is 7%. That's seen as a win at the moment. We touched 11% at one point. That's been interesting from our point of view in terms of we decided to stay on bootstraps and didn’t take on a load of VC debt. How do you see what we've talked about in the context of the super cheap money not existing anymore?

There are a couple of myths out there about open-source companies. This is not related to your question but one of them is that all open-source companies are DevTools. It’s not true. Lots of open-source companies are non-DevTools but the second one is that open-source companies should focus initially on growing their community for several years and only then monetize.

That's a myth because there are loads of successfully bootstrapped open-source companies out there like any company. It's a different game that you're playing if you decide to get VC money versus not but there's no reason that an open-source company can't be bootstrapped. It's a different way to think about the problem. I like the bootstrapping approach for open-source companies. I probably shouldn't say that because most of my clients are VC-funded.

‍

The reason is that with open-source, figuring out how you're going to make money is important if you're running a business. If you’re bootstrapping, you have to address that head-on quickly or immediately. If you have VC funding, you don't. That can end up being a trap for people because they have a team of 50 and 0 dollars of ARR. One of the fallacies of open-source businesses is that having a project that has a great market fit is going to automatically translate to product market fit and that is not the case. Being forced to sell something and get people to give you their money very soon is good for the business long-term.

Thinking about that in that context like Flagsmith was very fortunate because it was bootstrapped and a side project from an agency as well. That meant that there was never a moment of crisis. The boat launched into the water as this little thing was super gentle. That's a super important distinction between project success versus product success. There's no certainty in any way that those two things are related to each other. The combination of side projects and bootstrap for Flagsmith was perfect because we got to test and validate both of those things in a risk-free environment.

We didn't do this by design. This is just how it's turned out to happen but I've been pleased with that. You take it from the opposite approach where I wouldn't have been able to raise $20 million. If I had been a successful person, you could have easily gone and grabbed $20 million. “I want to be able to build a feature-playing platform. I need $20 million.” Someone would have given me $20 million. Suddenly, you've got this total moment of crisis where you've built this huge vessel, you're trying to launch it into the water, and you don't know what's going to happen.

Those things are slowly being figured out but I wonder what the long-term learnings of that are. We so happen to have the luxury. It’s weird to talk about a software agency or an agency as a business as a luxury because normally, they're hard to run. They are stressful. You're constantly having to win business and trying to find good clients. You are not trying to find bad ones and things like that but that was a complete and utter luxury in the context of our project because we didn't have those tensions.

What I'm trying to figure out is how you can apply that and take the benefits of those side projects things but apply them in the context of not having somebody who can financially support you. It's interesting as well because that feeds into the engineering of light, cloud-native, and stuff. You can build so much so quickly and cheaply. That's had a big change as well. Emily, thanks so much for your time. It's been super interesting to hear your story. Is there one thing that's in your head that you want to get out before we close?

I also have a podcast called The Business of Open Source. I also wrote an eBook, Positioning Free Open Source Projects. If you're serious about the growth of your project, you want to position it correctly and get your GitHub page talking about your project in a way that makes sense to your target users, that's what the eBook is all about. You can find that on my website. My website is EmilyOmier.com. Connect with me on LinkedIn.

Thanks again for your time. I look forward to seeing where things go.

Thank you so much.

‍

Important Links

• Emily Omier
• Flagsmith.com
• GitHub.com/Flagsmith
• The Business of Open Source
• Positioning Free Open Source Projects

‍