Fun Software Annuity Math: SaaS, Perpetual, and Open Source Models

As a follow-up to my previous post, Perpetual Money vs. Perpetual License, I thought I’d take a few minutes to further explore the math of software annuities.

Let’s start with some perpetual license software that costs 100 units and has an annual maintenance fee rate of 20%, or 20 units per year in perpetuity.  To avoid math and equations, I’m going to brute-force things in Excel, do a 40-year model, round it up, and consider that equivalent to perpetuity.  (You can download my spreadsheet here.)

Now what is this sequence of cashflows actually worth?  100 + 20 + 20 + …

Before calculating we need to remember two things:

  • Not everyone renews every year so we need to model a maintenance renewal rate (MRR) and use it as a probability of renewal each year
  • The time value of money becomes important in long time series so we’re going to need to pick a discount rate (say 8%) and model that as well

It turns out that 100 + 20 + 20 + … is worth 220 units.  Recall in the prior post that we said sales commissions typically run 10% and are paid on license and first-year maintenance only.  Thus, the company pays commissions on the 120 year-one units, which represent only about 54% of the value of the contract.

Now let’s see what a SaaS annuity is worth at 50 units per year.  The answer:  300 units.  More interestingly, let’s find the breakeven point between the SaaS and the perpetual model (i.e., where 100 + 20 + 20 + … = X + X + …).  The answer:  37 units.  That is, a SaaS annuity of 37 units is mathematically equivalent to a perpetual fee of 100 with a maintenance annuity of 20 in perpetuity.

Note that all these calculations have been based on a 90% renewal rate.  Let’s see what happens if the renewal rate drops to 80%.

  • The maintenance renewal stream’s value drops from 120 units to 77 (36%), so the total value drops from 220 to 177 units (20%)
  • The SaaS annuity stream drops in value from 300 units to 193 units (36%)

Conversely, if we increase the renewal rate from 90 to 95%:

  • The total value in the perpetual model jumps to 266 units (21%)
  • The total value in the SaaS model jumps to 413 units (38%)

So, unsurprisingly, the large up-front payment in the perpetual model acts as a keel on the total value, damping the volatility of the renewal stream’s value as a function of renewal rate.

But – back to plain English – you can see why SaaS companies are so focused on renewal rates:  increasing the renewal rate by 5% increases revenue by 38% over the long term.  That’s leverage.

Let’s conclude by looking at open source models where certified/enterprise releases and associated support services are sold on a subscription basis.  In some ways you can think of this as SaaS without the need to operate the software.  But I think it’s more accurate to think about about this as a perpetual model where the initial license fee is zero.  (Arguably, the difference is pure semantics.)

Let’s say a piece of enterprise software costs 100 units and comes with a 20 unit annual maintenance obligation.  We know that’s worth 220 units in total.  If you sell the open source support subscription for the same price as perpetual maintenance fee, then the value for the company is 120 units and the customer “saves” 46% — and all of it up-front – by avoiding the initial license payment.

If you could sell the open source subscription for 30 units, both sides still win.  The value is 180 units, still generating a savings for the customer and a revenue increase for the vendor.  The breakeven point is, as we found earlier, 37 units – at that price the customer should be indifferent to either a 100 + 20 + … stream or an annuity of 37 + 37 + …

Let’s say we decided to sell our open source subscriptions for 30 units and see what happens as we vary the renewal rate.

Now you can see why open source vendors are so focused on renewal rates.  What’s more, when a SaaS customer fails to renew they need to stop using the software.  When an open source customer fails to renew they simply downgrade to using the unsupported or community-supported open source version of the software, which is a far less dramatic alternative.  This is why open source vendors work so hard to justify the upgrade to their supported enterprise versions.  With a renewal rate of 95% the value is 248 units.  If that rate drops to 65% because many people feel they can get by with the community version, then the value drops to 75 units – a difference that could decimate a company.

As one friend in the open source business said:  “it’s hard work giving away your software.”  Remember that while MySQL was ubiquitous at the time of its $1B sale to Sun Microsystems, there were rumored to be doing only about $65M in annual revenue.  Such is the nature of disruption.

2 responses to “Fun Software Annuity Math: SaaS, Perpetual, and Open Source Models

  1. Dave,

    I really enjoyed your presentation of these models.

    For a while, I have been interested in is modeling how an SaaS company could increase its revenues by also offering an open source solution as a deployed alternative for customers that can’t or won’t do SaaS.

    So the question is, what is the best choice:

    Not offering a deployed solution, and only offering SaaS.
    SaaS + Offering a deployed solution with typical license and maintenance
    SaaS + Offering an free open source solution with support contracts

    This model quickly gets complex, especially when factoring in pros and cons of the open source community, and support costs. I am not sure there is a one size fits all answer, but its an interesting thought experiment none the less.

    Thanks for the brain food.

    Cheers,

    Casey

    • Casey,

      My guess is that would be difficult not for business but technology reasons. Multi-tenancy brings an extra layer of complexity (and benefit) to SaaS users and just taking SaaS application code and open sourcing it would result in [1] potentially giving away some cool multi-tenancy IP and [2] extra complexity in the open sourced project — i.e., there’d be a bunch of code and/or wierd metadata-driven database schemas that are wholly unnecessary if I’m deploying on premises.

      But putting that aside, let me take a swing at the question. I am generally anti-mixed-models because you invariably create arbitrages in your pricing model That said, at BusinessObjects we had an arbitrage for most of the years I was there and while it did cause many headaches, it didn’t seem to do us any real harm (you could buy per-user at $K list or per server at $125K.)

      Now, putting fears of mixed models aside as well, if were to take a codebase and “pick 2” of [1] on-premises open source, [2] on-premises perpetual license, and [3] SaaS service, my instinct would be to make [3] my 95% norm and once in a while (e.g,. the NSA or CIA) offer a very high priced, unsupported almost source code license — in effect saying “we are a SaaS provider, that’s the way we do business. If you want our code and you are special then for a very high price, I can let you run your own cloud using my software in a closed environment.”

      Net: I don’t like mixed models. Even as typed that answer, I didn’t like it. And I think the aforementioned technical hurdle is real.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s