Selling Open Source 101: Why it makes a difference to understand what you're doing

So, yesterday I wrote about what the sales funnel looks like when selling open source software, compared to what it used to look like when we sold closed source software. In this post I will build on that theory with some practical conclusions. (I assume you've read the first post.)

Why modeling your business matters

When running a business we need to do budgeting and other planning related activities. If you don't, you'll probably run out of money at some point. Also the point of planning is to capture as much of the business potential out there as possible. For example, to sell 5MEUR next year, do we need 5 sales managers or 6? (...and, can we afford 6?)

Surprisingly often you can see managers coming up with next years budget and targets with fairly simplistic methods. Say that we made 5MEUR last year, and that was a 30% growth year-over-year. By extrapolating we might say that next year the goal is to make 6.5MEUR in revenue. Or maybe we want to show that we can do better than last year. So let's make it 40% growth and 7MEUR in revenue! Done, now let's go for beers...

My first job with a profit and loss responsibility was in a software subcontracting company. In my business unit 100% of the revenue was from selling developers to Nokia, and invoicing for each hour they worked there. I spent a couple days with an Excel sheet and sure enough, it was easy to figure out the variables of the game. Our costs were constant: we paid our developers a monthly salary. Revenue on the other hand was a function of 3 major variables:

First was the utilization rate. How many of your developers are actually at a customer doing billable work each day? This one they had figured out long before I joined the exec team and it was quite well understood.

Second, it turns out each month has a different amount of working days. This ranges from 19 to 23. (December could have even less than that due to holidays.) In other words the monthly revenue had a 20% variability that came from a random source called the calendar. Since monthly salaries were constant, it means the profit margin could vary by 20% due to this alone!

Much to my surprise nobody in the company had realized this before I joined the exec team. So I would go to the monthly business review meeting and the CEO would be smiling and say "well done guys, the revenue (and therefore profit) from last month was really good". And I would be like, yeah, but last month had 23 work days, of course the numbers look good! The next month I would go to the meeting and the CEO would be really worried, because revenue was down and there was almost no profit. So I would tell everyone to chill out, it was only because that month had had only 19 work days.

Some people have to be told more than once before they learn.

The third variable had to do with a detail in Finnish labor legislation: in the first year you don't get to have annual vacations, but after that everyone has 5 weeks. The impact of this on a fast growing company is left as an exercise to the reader.

I hope the above story illustrates why it helps to model and understand your business. (Otoh, they had done well for many years without understanding these things, so who am I to judge...) Now, let's talk about the business of selling open source software...

Highs and lows of growing an open source business

As we learned yesterday, in open source you first get lots of users, and then eventually you manage to sell your software to a tiny fraction of those users. Turns out understanding this dynamic matters a lot for an open source startup.

Often the software is out there, maybe as beta versions, and used by thousands of people, long before you hire your first sales manager and close your first deal. But once the userbase - and therefore the business potential - is big enough, your product and the company is mature enough, and the use cases of your users are critical enough, it is time to start monetizing. So you hire a sales guy and start selling.

a graph

Since there are lots of users out there, it's easy to find leads, qualified leads and closed deals. Like I wrote yesterday, maybe somebody needs support and calls you with money in their handing, wanting to buy immediately. Maybe you even sold a couple of those before you even had a dedicated sales guy!

In short, selling is easy.

Once you grow the momentum, you hire more sales guys, they contact more of the userbase, and your sales grows even more. Since there is untapped potential (the userbase) out there, selling is easy at this point. Even with a poor conversion ratio, you're bound to find someone somewhere willing to pay.

And this is where understanding your business model matters: At this point in the company lifecycle, your sales growth is a function of just hiring more sales people, but don't expect it to last long!

So, say you're one of those managers who looks at the revenue going up, and uses the well known projection method to plan next year's budget and targets. Maybe the previous years you've been growing 50-100% (which is completely realistic, even normal, when starting from zero). So you want to grow at least 100% next year, maybe even more! And to enable that growth, you plan to at least double the headcount for sales and marketing, maybe R&D too. (Done, now let's go for beers...)

And now you are in trouble

Unfortunately, this leads to trouble. As you've been living in the phase where sales grows as a function of hiring more sales people, it has made you feel invincible. But then one day you hit the limit. Your userbase isn't really growing 100% or 300% or whatever % per year. And once you've tapped all that untapped potential, your sales will eventually start to become a function of the growth of the userbase.

Now, if you did hire all those sales managers you planned for with the projection method, various things will happen. Obviously, they will first of all fail to meet their targets, because the targets are not based on a correct understanding of reality.

Second, you might hope that reports from your Salesforce or other CRM system will predict this declining curve in advance and you'll not get into trouble. Unless your lead qualification process is really good (ie you've learned to do the selectivity part well), then this is unlikely to save you. Even if the sales potential is starting to get exhausted, there are still lots of users and potential users out there who can be counted as leads and opportunities. Since your newly expanded sales force has to do something for work, they will find something that looks like an opportunity, spend time working on those, but unfortunately they will not sell as much as they were hoping for. Because, it is the unfortunate nature of selling open source, that not all of your users choose to pay you.

In the first years you've been so busy selling left and right, that you didn't build that selectivity into your lead generation process - in fact selectivity happens naturally when you're so busy. But when you have a surplus of sales guys with too much time, they will fill that time with their best bet. So the pipeline reports will continue to look good - until the reality hits.

So instead of relying on your CRM, you really should have focused on those metrics about user adoption, like I told you yesterday. Because ultimately user adoption is the key variable forecasting your business growth.

Push vs Pull

Finally, you experience a significant chance in dynamic at this point. In the first years there was a strong customer pull. Everywhere you look there's a new customer waiting to sign the deal. This helped keep the sales cycles short and efficient - just as they should be! But now, with surplus in the sales force and less untapped potential, the sales guys are able to connect with opportunities earlier, which means they spend more time with each one, which means you are being less efficient and cost of sales is going up. Your sales effort is now pushing the adoption rather than the adoption pulling your sales.

Now, it is worth pointing out that for a VC funded startup it might make sense to "push" the adoption rather than the more passive "pull". The whole point with taking VC money is to accelerate both your adoption and sales, and "pushing the envelope". I guess the point I'm trying to make is just that there is a difference between knowingly choosing to push the envelope, versus sleep walking into an envelope by accident and ignorance.

Repeating the same mistake over and over

The world has several continents. Often a startup will start in North America first. And you will do the above mistake there first. But, then you expand to Europe and to Asia, and congratulations, you can do the same mistake again!

In fact, for each continent the above effect may be amplified. Quite likely Europeans and Asians have also started using your software from day one, just like they did in America, and the userbase has been growing stronger. All the while you have delayed the introduction of a salesforce on those continents.

And that means - you guessed it - the effect I've explained above becomes even more amplified. Once you hire your first European and Asian sales guy, there's even more untapped potential for him, and an even steeper growth curve results. And even bigger trouble once the potential is exhausted and sales growth starts aligning with the growth curve of the userbase.

So what did we learn today?

Ultimately your sales growth is a function of the growth of your userbase. In the beginning you might not see it. But to avoid trouble, you really should focus on estimating your userbase growth as a predictor for sales growth.

And what did we learn yesterday?

Since growth of your userbase is the main variable determining sales growth, the best sales investment is to invest in your user community.

Next: Selling Open Source 101: Lead Qualification

Generally in all the same ways as a larger business :-)

For example a couple years ago I worked together with Galera, which back then was a 4 person company, 3 of whom were engineers. They had a similar subscription model like any other open source company. But since they are small, they focused on partnering with Percona and SkySQL. For example doing 24/7 support is usually not feasible for such a company, and also the sales and marketing power is limited. But these are common challenges for any small company, not specific to open source. On the contrary, thanks to being open source such technologies can become widely used, whereas it's quite unheard of that a proprietary technology from such a small company would have thousands and even millions of users.

Add new comment

The content of this field is kept private and will not be shown publicly. Cookie & Privacy Policy
  • No HTML tags allowed.
  • External and mailto links in content links have an icon.
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.
  • Use [fn]...[/fn] (or <fn>...</fn>) to insert automatically numbered footnotes.
  • Each email address will be obfuscated in a human readable fashion or, if JavaScript is enabled, replaced with a spam resistent clickable link. Email addresses will get the default web form unless specified. If replacement text (a persons name) is required a webform is also required. Separate each part with the "|" pipe symbol. Replace spaces in names with "_".
About the bookAbout this siteAcademicAccordAmazonBeginnersBooksBuildBotBusiness modelsbzrCassandraCloudcloud computingclsCommunitycommunityleadershipsummitConsistencycoodiaryCopyrightCreative CommonscssDatabasesdataminingDatastaxDevOpsDistributed ConsensusDrizzleDrupalEconomyelectronEthicsEurovisionFacebookFrosconFunnyGaleraGISgithubGnomeGovernanceHandlerSocketHigh AvailabilityimpressionistimpressjsInkscapeInternetJavaScriptjsonKDEKubuntuLicensingLinuxMaidanMaker cultureMariaDBmarkdownMEAN stackMepSQLMicrosoftMobileMongoDBMontyProgramMusicMySQLMySQL ClusterNerdsNodeNoSQLodbaOpen ContentOpen SourceOpenSQLCampOracleOSConPAMPPatentsPerconaperformancePersonalPhilosophyPHPPiratesPlanetDrupalPoliticsPostgreSQLPresalespresentationsPress releasesProgrammingRed HatReplicationSeveralninesSillySkySQLSolonStartupsSunSybaseSymbiansysbenchtalksTechnicalTechnologyThe making ofTransactionsTungstenTwitterUbuntuvolcanoWeb2.0WikipediaWork from HomexmlYouTube