Does your company produce open-source software? Are you considering doing so?  Emily Omier helps open-source startups with product positioning, and today she joins me to discuss how you can position your open-source project, if you have one, and help you decide if you should have one.

In this episode:

• What are the reasons to contribute open-source, as a company?
• What are the differences and siilarities between open-source and non-open-source software products.
• How to market your product to both technical and non-technical people.
• Why to focus on outcomes before features
• Who are the buyers/stakeholders for your product?
• Use language that resonates with your target audience
• Should you seek contributors for an open-source project? And if so, how?
• Tips for accepting financial sponsorships

Guest
Emily Omier
emilyomier.com
Cloud Native Startup podcast
Positioning Open Source blog
Twitter: @EmilyOmier

Transcript

Speaker 1: Ladies and gentlemen, The Tiny DevOps Guy.

[music]

Jonathan: Hello, everybody. Welcome to the first Guatemala edition of Tiny DevOps. I'm your host Jonathan Hall. On this show, we like to talk about DevOps for small teams, small companies. Today, as I mentioned, I'm in Guatemala visiting my wife's family. We're here for a few weeks. I apologize for the roosters you might be hearing in the background but that's what's going on. Welcome to the show, roosters. More importantly, though, my guest of honor today is Emily Omier. Hi, Emily. Thanks for coming on.

Emily: Hi. Thank you so much for having me.

Jonathan: Tell us a little bit about what you do. You have a unique value proposition for your business and your consultancy. Tell us what you do and what's unique about the services you offer.

Emily: I help open-source startups with their positioning. First of all, open-source startups, that's a squishy term, I suppose. The way that I define it is just any company that is tightly connected to an open-source project. Sometimes this means and the most traditional open-source project or open-source startup is a company that's following an open-core strategy, but there's a lot of ways that a company could be connected to an open-source project. Sometimes it's a lot more loosely than that we have an open-core strategy.

I help them with positioning. Positioning is basically about determining what label to slap on yourself. The key is it has to be something that people understand, and it has to highlight the value that you provide and you, meaning your open-source project and whatever thing you do to make money. You also have to have a relationship between the two that make sense. That's one of the unique things about what I do, is helping companies figure out how to position both and how to position them in relationship to each other.

Jonathan: That's really fascinating. I can imagine that that's a big challenge. I've actually worked with a few companies that have an open-source component or something like that, and often they had the attitude that if you build it, they will come. I imagine you see that a lot, "Oh, look at open-source this thing," and everyone's going to want it. Does it ever work like that?

Emily: Does it ever work like that? Maybe, but for the most part, usually when somebody has a story like that, there's something that they're not telling you, basically. The way that I would put it, I know that people don't like to use the word marketing, but you have to tell people that your open-source project exists, whether this is just a side project or you're building a company around it. If you care about getting people to use your open-source project, you do have to tell people that it exists and you have it make sense. There's literally millions of open-source projects.

I think there's like 8 million on GitHub or something like that. There's a lot of noise out there. If somebody doesn't understand what your project is doing, and I'm talking even outside of any outreach, like somebody lands on your README, and if it doesn't make clear why they should care about this project, and by that, I mean what does this project accomplish, and who is it for? People have short attention spans, if they don't get that in the first 30 seconds, they're off to see if another one is going to meet their needs.

Jonathan: How is that different than a non-open-source product? If I want to sell an eCourse about knitting, I need to make the same points, don't I? Or is it different for open-source?

Emily: Yes. First of all, I will say that, I don't know, I can't really speak about positioning for a consumer audience because it doesn't really make sense to me. That's not true. Does make sense to me, but it's a mindset that I don't get. I'm pretty hard into the B2B, honestly, mostly because I'm not much of a consumer myself, so it's hard for me to get into the mindset of somebody making a consumer purchase.

In terms of the difference between a product and an open-source project. I would say there's not a huge difference between an open-source project and another dev tool. The thing that you get into with open-source projects is that you will always be selling shoes to shoemakers. Your audience will almost always be somebody who is able and will and wants to look under the hood and see what's going on, and possibly they are not actually able to create the thing that you've created themselves, but they think that they can.

[laughter]

Emily: That is a distinction, but that just means if you're selling software to accountants, that the accountant is never going to be like, "Oh, I could just do this myself, and I'd do it so much better." When you are selling a dev tool or when you're selling, not selling, when you're promoting an open-source project, there will always be that aspect in whatever communication you're doing. Especially because when you're marketing in an open-source project-- Did I just say marketing? Sorry. When you're promoting-- I'll use some other word besides marketing.

When you're trying to get people to use your open-source project, you aren't just thinking about having people use it, you're thinking about getting people involved. Ultimately, you would like to perhaps recruit some more contributors and you think about things like contributor ladders and things that. In fact, you have to think about what your goal is even before you start positioning, because sometimes the profile of who's going to be a superuser, isn't the same as somebody who's going to end up contributing back, or who's going to get involved in some other way just like making comments or attending an event or something like that.

Jonathan: I feel like that concept of selling shoes to shoemakers is something that a lot of technical people try to do, even when they shouldn't. In other words, as a practitioner, or a developer, or an engineer on a team, I approach my product owner or my boss, and I'm trying to sell him things on the technical merits that he probably doesn't care about, he's not a shoemaker. [chuckles]

How do you address that? Let's start with the open-source thing, because, often, your decision-makers I'm expecting aren't shoemakers, but they're relying on the opinion of other shoemakers to choose a tool. Suppose you're choosing, I don't know, a workflow tool or something like that. You want your developers, your engineers, to understand it and to be excited about it, but as the decision-maker, you may not be technical.

How do you address that without alienating the other shoemakers who are also evaluating the tool? How do you bridge that chasm if you will?

Emily: There's a couple of things. First of all, even if you are selling a technical product to a technical audience or you're marketing an open-source project, all of your audience is going to be software engineers. You really still have to focus on value. This is a mistake that I see people make, they'll lead with the features, and then they'll say, "Oh, I'm selling shoes to shoemakers, so they really want to know how long the laces are or something like that."

I might be winding down the shoemaker analogy soon.

Jonathan: [laughs]

Emily: Anyway, the point is that even if you're selling a technical product or marketing an open-source project to a technical audience, they still care about value and they still care about the outcome that they get from that project. When they go to your README or they go to your website site of the open-source project, the first thing that they see should be about what outcome they get from using this project.

Whether that is you'll never write another YAML script or you'll get away from CI lock-in, or, I don't know, whatever your project does, they want to know what the thing is that you help them accomplish. You can't totally neglect talking about how, but nobody will care how you accomplish that goal until they've established what you accomplish. That's really important because people need to know what it is that they get out of this project, and they need to understand that really fast because otherwise, they'll just move on.

Next, I wanted to just say it does differ. This is one of the differences between an open-source project and just a commercial product, is there's different adoption patterns. The whole thing about open-source is that anybody can go download it, start using it. That's usually the adoption pattern. Even if you have a company using an open-source project, it's usually that some individual engineers have gotten interested.

Maybe they tell their colleagues about it, whatever. They're probably not having to have that business conversation, or at least, you as the maintainer of this project, aren't having to sell to, or aren't having to convince non-technical people to use your open-source project. That's different when you have a commercial product. Usually, when you have a commercial product, at the beginning, you have to bring in the business, the buyer persona. They have different needs and you have to address those.

Whether you have just an open-source project or a commercial product or both, as with most of the companies I work with, you do have to recognize that there are different stakeholders. The key is you have to understand what the adoption pattern is for your particular thing. You want to adjust how you talk about it based on that adoption pattern.

If your adoption pattern is that you have an individual contributor who discovers your open-source project, they talk to their boss, their boss signs off on it, and now everyone in the organization uses it. Obviously, you want to be talking directly to the needs of that individual contributor.

On the other hand, if you have a commercial product usually that is super useful to the boss and it will usually be the boss persona. The boss persona actually might not be a non-technical person. We could be talking about a VP of engineering here. The bottom line is that somebody like a CTO or a VP of engineering has different needs than an individual contributor. Part of their job is to care more about businessy stuff.

Just as a result of that, you have to be able to make a more business-focused pitch in order for them to really see that this is something that meets their needs. I'm not even talking about a totally non-technical person, just that it's somebody who has more business metrics in their job title. If that is the person that usually is the champion for your product, then you need to speak to that person's needs.

On the other hand, you also can't neglect those other stakeholders completely because you need to make it easy. The individual contributor finds your open-source project or finds your product, goes to have a meeting with their boss, make it easy for that person. Have a website or have a page on your website that that person can send to their boss or something like a PDF that they can download and say, "Look, here are some talking points." Make it easy for them.

Same goes if you have more of a top-down adoption pattern. Ultimately, the VP of engineering isn't going to want to totally force, whip their direct reports or their individual contributors into shape. They want to convince them that this is a good tool. Make it easy for them.

Jonathan: I hear what sounds to me like a lot of parallels, but just communication in general. If you're trying to convince your spouse that you want to go to dinner at place X versus Y, you need to consider the value of going to place X versus Y. Do you have any advice for people who maybe aren't doing open-source projects, just to communicate within their team, with their colleagues, with their stakeholders, with their boss, when you're trying to influence a decision somehow? What do you need to focus on? What are the, say, top two or three things to focus on in that scenario?

Emily: Actually, I'm glad that you brought the parallels with just, in general, communication, because it's true. One of the best practices of any communication, especially when you're trying to persuade someone, is understanding what matters to the other person. What matters to the other person is very likely not the same as what matters to you. If we talk about this in an employment situation, maybe if they have precisely the same job title and role as you, they might have the same needs and you don't have to think about it too much.

On the other hand, if they have a different job title and oftentimes, particularly in a DevOps scenario, you'd be on one team but each person has a slightly different responsibility. That means that somebody who is responsible for, let's say security, that person is evaluated on different metrics than you might be. You have your security person and your app developer, for example. The metrics that they're evaluated on are different.

What leads them to get a promotion is different. What leads them to get fired is different. What just leads them to feel like they've done a really good job in their job is different. When you're making a pitch to somebody you have to consider that. If you're just making a pitch for, "We should use this tool or we should do X," and you're only talking about reasons why it benefits you or why it benefits somebody like you, that's going to fall really flat.

Instead, you have to think about, "This is why this is valuable to somebody like you." I'm the app developer talking to the CTO and I'm saying, "This is why it's going to make our whole organization look good. This is why it's going to help us meet X, Y, Z metrics that are the metrics that you, CEO or CTO, are evaluated on." That's really the core, is understanding what matters to that person that you're speaking to.

Jonathan: So you need some empathy? You need to understand--

Emily: You need to start with empathy. Yes. There's also the issue of using language that that person understands. If you're inside of a technical organization, you can be technical. Particularly, this is going to be the case if you're at a small company. You're going to be making a lot of these pitches directly to a business owner, a CEO. That person probably doesn't really understand a lot of the technical jargon. That it's great. That's not their job to understand the technical jargon, they have a different job.

I say that because I think there's sometimes a tendency to look down on people who don't get the technical stuff. It's not that they're in some ways less capable, it's just they have a different job. They do stuff that probably you can't do or would struggle to do. If you want to make some sort of pitch, you have to make it in the language that they understand. Use the language of business to talk about why this particular tool is necessary or why you need to spend a month rewriting this particular application instead of creating new features or whatever it is.

Talk about things that they care about which-- If you're talking to a business owner, it's all going to be about, "This is going to increase our revenue, or this is going to make our customers more happy or it's going to futureproof our application. We're going to basically have a more stable application that we can rely on for a longer period of time." You use the language that they'll understand. Don't get into the technical weeds, they don't care.

Jonathan: Back to the topic of open-source a little bit here. When you're promoting an open-source project as a company, you're promoting an open-source project, I think there's a lot more than just getting people to use your software. You probably also want to get people to contribute to your software, for example.

I think there's at least two different models. I've seen companies were they actively want contributors to their open-source project to build a community. Others who don't care. They make something available and if you want to contribute, that's fine. Let's just start with, how do you appeal to potential contributors on an open-source project? Is that something you deal with and how do you approach that?

Emily: First I wanted to address, do you want contributors? It all comes back to this is even more fundamental than thinking about how to position your open-source project but asking yourself why did you open-source this project in the first place? There's different answers to that question and there's not necessarily a right answer and a wrong answer. You do need to understand that.

Then the next piece is, let's say your goal is community growth. This is a big one for people that have an open-source project. What does community growth mean? There are different ways to define community growth. It could be a growth in number of downloads. That's actually a metric that people will look at but you don't know how many people are actually using it if it's just that people have downloaded it.

It could be the number of act of users. It could be the number of people who aren't contributing code back but are active in the community. They're asking questions. It could be contributors and even in some open-source projects, it could be that you'd to recruit another maintainer. You do have to know how you define community growth and why this open-source project matters in the first place is going to give you clues to which one of those metrics matters the most to you.

Do you want people contributing code or not? It all depends on what your goals are for the project and then also for your product and how you view them as being interrelated or not very interrelated. I do usually see that the companies for whom it's very tight and open-source, is really critical to their identity as a company.

Those companies are more likely to be interested in really creating a community which includes the code contributions and I would say it's skewed towards the, not just active users, but active community members which I think of as people who would go to an event, make comments in the Slack group, not necessarily contributing code back, but that's also included, the code contributions. Just contributions to the community.

Then people for whom the open-source project is less critical to their identity as a business, they will generally not care so much about those particular metrics and they're usually looking at number of users.

Jonathan: Let's take a step back then. You did a good job of reeling me back a little bit but I want to go back a little bit further and address what are the top most common reasons that a company would choose to open-source something? We should have done this in reverse order but that will feed into what we just discussed. What are the top reasons that a company would choose to be open-source?

Emily: The first reason that comes into my head actually is that they can't imagine not doing an open-source. Which is to say, I work with a lot of companies that are in the infrastructure space and the cloud-native space. They'll basically just say, "I don't want to get up on a stage, talk about my company and not have an open-source component. I feel having an open-source component, it's just table stakes. It's a core part of being credible in this ecosystem."

I don't want that to sound like the founders who say that are self-serving, I don't think it's that. It's just that they consider, if you want to play in this space, you have to be open-source.

There are other reasons. I think anybody whose goal, their company mission is really about dominating a very specific type of tool. I don't think you're ever going to totally dominate the mind share unless there's an open-source component. Of course, we're talking about a tool that software engineers use. I think you have to have an open-source component if you really want to be considered the best at X because--

Jonathan: Do you have an example of a tool that fits in that category?

Emily: I don't have a good example. There is a company I'm thinking of that I think should have a better open-source strategy, particularly for this reason because they want to-- I'll out them slightly but anyway they want to be the place that you go to if you're incorporating a keyboard into your application.

It's an excellent idea but I don't think in order to really dominate this really specific niche, you have to have an open-source because there's a lot of developers that are going to be looking for something that's open-source and disappointed if they don't find it and so you're almost asking somebody else to come into the market.

The next thing I wanted to say is if your mission is anything about democratizing X, that's the same. I do talk to a lot of companies that part of their mission is democratizing X. I just worked with a company recently whose part of their goal is democratizing privacy. A lot of privacy tools have only been available to really, really huge companies because they're hard to develop, basically. They have a privacy tool that software engineers can use, the developers can use as part of their development process.

There's an open-source and a commercial product. In their case, one of the reasons to have an open-source project is because their goal is to democratize the access to this kind of tool. In order to do that, open-source is the way to accomplish that mission.

Jonathan: Those are the two reasons it sounds like you deal with the most. Is that fair?

Emily: No, because then I'm going to get into the more self-serving ones. Open-source can also quite honestly be a marketing play. People don't like to say this out loud but I think that this is a real reason that people do open-source. I don't think that people should think of their open-source project as a lead pipeline. There are people out there that definitely do and then there are people also who just do open-source is a part of our adoption play.

We have people adopt the open-source and then once the CTO finds out then the CTO decides that that's something we need to pay for. We need to pay for support and then bada-boom, now we have a new customer. I personally don't encourage people to think of their open-source project as just a marketing play. I actually think that you get more value out of the open-source project. More business value for the company maintaining the open-source project if you don't think of it as just a marketing play but I do think that that is how some people think of it.

Jonathan: What about companies that they have a closed-source core but they have an open-source say SDK or something that. Is that a special case because usually, they're just trying to let you integrate with your other stuff without paying licensing fees or something. How does that figure into your business or your thinking on the topic?

Emily: I think that that's a little bit different. That's a different kind of open-source model. In that case, I would say the open-source SDK, it's an adoption play. They're trying to make their product more accessible to more people but you're going to have to pay if you want to use the product.

Jonathan: I don't know if companies do this or more open-source organizations but if you want to sponsor an open-source project or maybe individual maintainers will do that, you can certainly do that on GitHub these days, you can put up a sponsorship thing, sponsor my package. Is that something you see companies doing or is that more for a nonprofit individual type approach?

Emily: I will say, I don't know a ton about this. This is outside of my specialty. On the other hand, I don't know zero about it because I should go to conferences and listen to talks about stuff like this. From what I have heard, this is definitely a thing that happens, and companies, there is a couple of challenges. First of all, if you are the open-source maintainer who's asking for some contribution, there are some types of projects that are more visible than others.

One of the unfortunate things is that a lot of really fundamental open-source projects, the kind of thing that everybody uses, often, they're the least visible to people. They're taken for granted. Even though it might be really critical that often they're less likely to be supported financially.

Another takeaway that I had actually, I went to a talk about this at the Linux Foundation Member Summit, but another takeaway that I had is that it's harder and you expect for a large company to just send money to somebody because that's not how big companies work. They have to have a purchase order and there's all sorts of implications if they're sending you money, is this a donation to a nonprofit? They have to have you sign paperwork that you're not an employee.

It's not just as simple often for a VP of engineering to take out their company card and be like, "Hey, let's see, who am I going to send money to today?" It's often more complicated than that, just from a bureaucracy perspective. If you have an open-source project and you want to have people send you money, keep those things in mind. There's some steps you can take to make it easier.

I know that it could be things like incorporating a business or having some document that you can easily send to people who would like to give you money. Then the last thing is, just make it as easy as possible if you want people to give you money. Companies know. Companies that use open-source, they recognize that they're relying on open-source projects and they don't want them to go away.

This is a challenge I think, in the open-source ecosystem, in general, is-- In fact, it's why I think a lot of companies love open-core because they feel confident that this open-source project isn't going to go away because there's a company behind it and it's going to be sustainable. People who use open-source, particularly those at large companies, they're very aware of how critical it is.

Jonathan: I was working with a client recently who was considering open-sourcing a very small module of some sort. Their reason was because they could get some corporate sponsorship. I don't remember how it worked, if it was compensation or if it was just somebody going to support the thing or what it was, but they got some sponsorship if they wrote a module and open-sourced it.

They were going to do all the work in-house. They didn't want to build a community. It wasn't a marketing employee. It wasn't anything like that. It was just to check a box, basically, to get some benefit. That's one reason I've seen a company recently considering open-source, but what are other reasons that maybe listeners should consider or not consider doing open-source if they're thinking about it if they're on the fence? Should we open-source our product or part of our product? What are the things they should consider in making that decision?

Emily: One aspect that we haven't touched on and I apologize because I'm so biased towards the startups' scene but there's a lot of individuals who create open-source projects. I wish I had statistics, actually. I'm curious what percentage of open-source projects are just created by an individual.

That, I think, has a lot of benefits, particularly, if you're not super well established in the industry. It can be a really compelling way to establish that you're good at what you do. It can become a calling card if you're a consultant, if you're looking for consulting gigs, if you're looking for a job. I think that is an excellent reason to have an open-source project.

Jonathan: I can attest to that. I have an open-source project. It's landed me several jobs so it works. It takes time. It's not a quick turnaround, but it works.

Emily: Oh, definitely. I think the other thing about open-source, no matter what your reasons for doing open-source, it is not a quick ROI type of thing, whether you're a startup. In fact, I think a lot of open-source startups are slower to hit revenue milestones because they're developing two products, basically. Whereas, just a pure closed-source, they're focused on just one.

I do think that, ultimately, they can win the race for sure but the early days, it's a slog. The same, if you're an individual developing an open-source project because you want to upskill yourself, you want to get a better job, whatever. It's not going to be immediate for sure. Another reason that I hear companies open-sourcing is actually for recruiting because-- and this is big companies.

If it's a, let's see, a company that is not creating developer tools then often their open-source projects, they'll have a recruitment element to why they're doing it. They see people from the community and they can use their open-source project and people who are involved in that open-source project as a recruiting pipeline. There's another thing again for companies that are not necessarily creating a developer-facing tool, but an open-source project can be a way to collaborate with other people in the industry on something that's like table stakes for everyone.

That's certainly a reason that I see that's a very good reason to work on an open-source project. It's rarer, I feel like, to have open-source projects that are in that category, but I feel like they are a little bit more, I want to say pure. The pure open-source ethos when you have a bunch of companies, some of whom may even be competitors working together on an open-source project that solves some fundamental problem that doesn't add any value to any of their products but has to be solved.

I just actually spoke with the folks from OpenTelemetry and that's the category that they fall into. I think that's a very good reason for having an open-source project. The thing I just want to impress on everybody is that communication matters and positioning matters, even if you're dealing with technical products. Software engineers aren't robots, they're humans and you have to talk to them like humans, they have the same human goals as everyone else.

If you're trying to get people to use your open-source project, or if you're trying to get someone to use your dev tool, you have to have empathy for who your users and who your buyers are, and make sure that your thing makes sense.

Jonathan: The technical part is always the easy part of this job. It gets all the attention but it's the easy part. It's the communication, the human interaction, that's always complicated and trips us up, I think. Emily, how could people get in touch with you if they're interested, if they have an open-source project or considering one, and they think you might be able to help them? I know you also have a podcast. Maybe you want to talk about that a little bit? How can we reach out if we want to?

Emily: My website is Emilyomier.com. You can find it on the show notes, maybe.

Jonathan: Yes, definitely. [laughs]

Emily: I know my last name is slightly hard to spell. I also have a podcast, a cloud-native startup. In the podcast, I talk to open-source maintainers and founders and other people who work in the cloud-native and open-source ecosystem. Obviously, fairly focused on the startup world. I write a blog, positioning open-source. I have a couple of webinars out there that are focused on positioning for open-source projects. That's where I am. Feel free to connect with me on LinkedIn too. You can connect with me on Twitter but I'm not very active.

Jonathan: Great. We'll have all those details in the show notes. Thanks again, Emily, for coming on. It's been a fascinating conversation. We covered a bunch of topics, how to do open-source, how to communicate about open-source. In general, it's been fascinating. I really appreciate you taking the time. I understand you have some bread to go catch up with in the oven.

Emily: I do.

Jonathan: All right. Enjoy your bread. Thanks so much.

Emily: All right, thank you.

Jonathan: Come next time everybody.

[music]

[00:41:21] [END OF AUDIO]