By popular demand I have decided to continue my series on selling open source (Part 1, Part 2).

A couple readers both reacted my previous blog with more or less the same words: This is great, but what about the level of mission criticality of the use case? Surely you should count that as a third variable since it impacts the likelihood of a user becoming a paying customer?

Lead qualification

Yes and No. The overall topic we are talking about now is in fact the second variable: the Conversion Ratio. Or if you take another perspective, we are talking about lead qualification: for each identified user, what is the likelihood that they will become a paying customer? In other words, should you spend time working that lead or not?

And I do agree that the level of mission criticality is - also in my personal experience - the single most important variable predicting that. But it is certainly not the only one. Below I will present a list of things I personally pay attention to, ordered by the most important ones on top.

In addition to lead qualification, these variables may indirectly also guide your R&D strategy. For example, if your product is great for mission critical use cases (such as having great HA features) then you are more likely to win more paying customers. In other words, product feature set will impact the conversion ratio by appealing to different kinds of users.

But it's also important to keep a balance! Remember that first and foremost you should always invest in the total population of users growing. Many high value features, like scaling to hundreds of nodes, or Active Directory integration, are actually totally unimportant to 99% of your userbase.

Selling as data science

But before I share my personal list, it is important to emphasize that selling is not an activity where you repeat some motions based on a list you read on a blog. What you really should be doing as lead qualification is collecting data about the leads, and then when opportunities are either won or lost, you should go back and analyze which variables (predictors) were strong for the won deals and which for the lost ones. This way you can develop a mathematical model which assigns probabilities to your new incoming leads and helps you prioritize your sales efforts.

If you have no idea what I'm talking about, you should hire a data scientist to help you out. Hiring a data scientist is very trendy right now.

You might then of course start by measuring the below list of variables, but probably you can also think of your own, and I'm sure each product has different variables that will be important. In addition to the below variables, there will of course be others that are uninteresting for this blog. For example public information about the company you are selling to, the title of the person you are talking to etc... In contemporary data science there is a golden rule: more data is better data.

Different types of open source vendors

I should also point out that in this post I'm writing a bit more from personal experience than the others. In reality there are different open source companies. Some vendors sell a productized version of an open source project with multiple competing vendors (Linux, OpenStack, Hadoop...). Others are the single vendor in control of the entire open source product (MySQL, MongoDB). Some had VC funding and others didn't. And so on.

I happen to have experience from single vendor open source companies. Hence the steps to winning a deal are just:

1. Adoption
2. Paying customer

In multi-vendor ecosystems, there are more steps:

1. Adopting the open source product (e.g. Hadoop)
2. Competing offers from competing vendors (Cloudera, Hortonworks...)
3. Paying customer

For simplicity, and because that's where I actually have experience in, this blog post mainly assumes the former, simpler scenario. If you have experience of the latter kind of ecosystems, I'd love to hear about you!

Variables (or predictors) I use for lead qualification

Mission Critical use case

The definition of Mission Critical is that the user would lose a lot of money (revenue, SLA penalties, outright damage to property...) if there is downtime or other issues related to your product. In this case it becomes a very reasonable choice to pay what is comparably a small amount of money to get the best support you have to offer.

What other software are they using or have been using?

If a prospect is currently using mainframes, Oracle databases, Solaris Sparc servers, etc... that means they are used to paying for software, a lot. It also means they are not so used to downloading stuff on their own from Github. So there's a high likelihood they will pay you too, and you will also have more than usual negotiation room with the pricing, since they will think your product is really cheap compared to what they have been using so far.

Conversely, if the prospect is using all open source software, most of which may not even have commercial support available, they are likely to be comfortable going into production also without your support.

A great indicator is whether someone uses Red Hat Enterprise Linux or Centos. If they use RHEL, they are likely to want the enterprise version of your product too.

Company policy or legal requirements

This is a minority of your users, but it's great news every time it happens. Banks, some telcos and some other companies may have a policy that all production software must have commercial support. They may require indemnification, warranties and whatnot. This is great news, it means they will be buying your enterprise version!

It is less and less common, but some companies also have policies against some specific open source licenses. In practice the only policies I see today are against the anti-DRM clauses in the GPLv3 family, and sometimes also against the web-service-copyleft provisions of AGPL. If you are in a position to sell your product under a traditional commercial license, this is again great news for you.

Note that in these cases you can approach the pre-sales cycle more like selling closed source software. You can invest pre-sales effort into making the prospect adopt your software, after which they will be paying. Quite likely the buyer will want to proceed like that too, they need to negotiate the price first, before committing to using your software.

Large use cases

It turns out these are not always a positive indicator for high likelihood of becoming a customer. For example, large users of your open source product may themselves hire some gurus full time to ensure their system is running. Still, since the potential deal size is big, it makes sense to engage with these opportunities even if the likelihood of winning the deal might not be.

Also, engaging with the advanced users usually has a lot of value for *yourself*, for example they may have very valuable input to your product management process, or in the best case source code patches which solve your problems without any effort needed from yourself.

High volume users can often be sold on the efficiency argument. If you can improve performance of your product 5%, they can save millions in hardware cost, and you can get at least half a million or so of that money. For all the talk about "value to the customer", I've been surprised at how rarely many sales/business types understand this simple formula.

They really need support

Especially when I've been selling MongoDB, I'm often talking to a prospect who has never even downloaded MongoDB before they met me. They know they will need support while they're learning the new product.

Unfortunately there are also people who really need support, but don't want to admit it. I hear the infamous words "we have such great engineers that we do not need support" all too often. Then you leave them alone, and some months later their great engineers contact you again for some more free pre-sales advice. Often there's nothing you can do here. They will not pay you and you will not help them.

The exclusive features

This is what most open source companies focus on as the solution. We have some closed source tools available exclusively for paying customers. (Note that exclusivity doesn't necessarily require something to be closed source, but unfortunately that's usually how those open source companies approach this topic.)

Even I have to admit this sometimes does help in selling. Sometimes the closed source tools can be used as an excuse to justify the cost of the subscription that the engineers want for other reasons. This has happened to me and the engineers were quite open about it. Then we demoed the MySQL Enterprise tools to their managers and everyone was happy.

The problem with this so called open core strategy is that there's a very small margin for you to maneuver the balance of community vs exclusive features. Your user adoption is driven by people using the open source product, so all important functionality has to be open source. Then again, if there's nothing compelling in the closed source parts, of course nobody will pay for them. And to make it even more challenging: if you do keep some compelling features exclusive to paying customers, it is likely that eventually someone else will write a competing open source version of the same feature. Then you would have lost both the sales advantage and the control of your product roadmap.

In conclusion, while exclusive features sometimes do help in selling, I've found that executives in open source companies do tend to overestimate their importance. The reality is that more than 99% of your users get along just fine without those precious exclusive features, and if you try to increase the amount of exclusivity, you're only making things worse for yourself.

Charity: "We like open source and want to support your product by paying"

Like once a year or so you meet the programmer who opens the meeting with saying the lovely words: "We like your open source product and want to support it by paying for it".

Finally! You say to yourself. This guy understands what it's all about! Now we're talking...

You're a fool.

It turns out charity and business are different worlds.

You will soon find out that by "paying back", what he is really meaning that he would like to buy a consultant for 2 days, and has maybe a 2-3k budget available for that. The list price of the subscription you expected him to talk about is north of 100k. So you're quite far apart from each other in the start of negotiations. Eventually you realize this guy had no intention, and also has no authority, to pay you anything near what you're actually supposed to be selling him.

I've found that the best way to benefit from these open source supporters is to use their good will to get more connections inside their organization. Let him introduce you to people who do have authority and budget to buy a 100k subscription. His positive endorsement of you will be valuable starting capital in that negotation, but then you sell the 100k deal to the higher up manager with other arguments. Maybe one of those I listed above?

So that's my list of things I pay attention to when selling open source. I would love to get feedback, in the comments below or on twitter, about what you think. You're experience might be completely different from mine.