Positioning as part of your open source strategy
Yesterday I wrote about the unique positioning challenges when you’re building a company around an open source project and monetizing the project by offering an enterprise version. Today I wanted to talk about the positioning issues when your company maintains an open source project but your product is not just an enterprise version of the open source project. Some examples, from companies I’ve worked with, include Nirmata (a unified management plane for Kubernetes) and Kyverno (a Kubernetes policy engine); Chronosphere (cloud native monitoring) and M3 (a metrics engine); and Shipa (a cloud native application management framework and Ketch (a deployment engine).
The positioning challenge in this scenario is different from the community version / enterprise version we talked about yesterday. Here are some things to take into consideration.
Why are you developing the open source project?
Before you start thinking about how to position your open source project and your project, the first question to ask yourself is how the open source project fits into the business strategy. Here’s a non-exhaustive list of reasons you might have for investing in the open source project:
The open source project pre-dates your startup and is an important part of your credibility
You are using the open source project as a way to build authority in the cloud native space
You consider the open source project a loss leader that will bring prospects into your sales funnel
Clarity about how the open source project fits into your business strategy will inform how you want to position it relative to your commercial product. You might discover that the open source project does not serve a business purpose. If that’s the case, you can decide whether or not to continue maintaining the project as a hobby, but stop investing business resources into the project if it isn’t contributing to business goals.
You are a two-product startup
The challenge for companies with this strong association with an open source project is that they essentially have two products. Each product needs to have it’s own positioning, and they are going to be even less related than the positioning of an community version vs enterprise version of the same software.
General startup best practice is to focus on one product initially, only introducing a second product when the first product has clear traction in the market and the company is generating significant revenue. If you’re also promoting an open source project, you essentially have two products, one of which does not generate revenue. Assuming, though, that building adoption of the open source project is important for the company’s long-term success, you have to focus on promoting both projects.
To do so, you need to make sure:
The relationship between the commercial offering and the open source project is clear
When you talk about the open source project on your website, in your marketing materials or in other places it should be clear who the OS project is for and who the commercial project is for
Depending on your business strategy, make sure that the positioning for the open source project and the commercial product make sense given the business reasons for maintaining the OS project
When you go through a positioning exercise and you have an open source project that’s important to your business strategy, the positioning exercise has to take that into account. You’re positioning the company, the commercial product and the open source product as well as trying to define how they all relate to each other, in a way that reinforces your business goals for the open source project and doesn’t confuse prospects.