Perpetual Money vs. Perpetual License: Subscription, SaaS, and Perpetual Business Models

I had breakfast the other day with a software entrepreneur.  When I asked if his company was on a subscription or perpetual model he said:  “we should kill the guy who invented the perpetual license — I’m on the perpetual money model, subscription all the way.”

Having worked largely in perpetual license firms, I admit there are many downsides to the perpetual model.  Companies on perpetual models typically:

  • Have more volatile revenue performance due to a relatively smaller annuity “keel” on the business (in the form of maintenance renewals).
  • Are more exposed to end-of-quarter shocks driven by backend-loaded sales.  (Most software companies get 70%+ of their orders in the last month of the quarter and most of those in the last week.)
  • End up with “drive-by sales” cultures because sales reps are paid only on license sales and not on maintenance renewals.
  • Have less customer-success-focused cultures because sales reps care about customer success only to the extent they see potential follow-on license business in the short term.

That said, there are many ways to mitigate each of the above points and all of the world’s largest software companies, such as Oracle and SAP, still do most of their business on a perpetual license model.

Over the past decade companies like Salesforce, NetSuite, and SuccessFactors have pushed the software as a service (SaaS) model where the vendor both runs the software and bills on an annual subscription basis to use it.  While the SaaS model cut its teeth in applications like sales force automation, vendors are increasingly selling platform as a service (PaaS) offerings as well, such as Amazon Web Services, Google AppEngine, or

Clearly SaaS interest and hype remain strong.  Salesforce is trading at 100x FY11 earnings.  Bankers have told me that the IPO bar for SaaS companies is $75 to $100M in revenue, while for perpetual companies it might be 1.5 times higher than that.  A recent Software Equity Group report pegs the median enterprise value (EV) of of SaaS companies at 4.9x revenues, almost double the 2.7x revenues for perpetual companies.  On an EV/EBITDA basis, it’s even more dramatic with SaaS companies at 44x and perpetual ones at 13.6x.

Given all this, I thought it would be fun to make an Excel model that concretely demonstrates some of the differences between  perpetual and SaaS software companies.  To do so, I’ll first model a fictitious, red-hot software startup on a perpetual basis.  Then I’ll remodel the same company on a SaaS basis.  Then we’ll play around with the models and see what we find.  (For Excel geeks, my model is here; you’ll need to download it.)

To make my model, I started with bookings for the perpetual company and hard coded $5M in the first year on a reasonable ramp.  Then I made a set of reasonable assumptions (for a hot startup) that drove the rest of the model:  100% license bookings growth, a 20% maintenance rate, a 90% maintenance renewal rate, a 50% rate of professional services organization (PSO) services bookings relative to license, and a bookings-to-revenue conversion rate of 85% for PSO in the subsequent quarter.  To keep things simple, I didn’t model months, I didn’t model cash, I assume all bookings happen on the last day of the quarter, and I assume all license revenue is immediately recognizable.

Then I remodeled the company on a SaaS basis.  The most important assumption to make here is labeled “subscript as % of license” – i.e., if someone was ready to pay 100 units for a perpetual license to use something, presumably they want to pay some fraction of that for a one-year subscription to use it.  (I’ll call this F for fraction.)  For the initial model, I assumed F=50% which is arguably aggressive.  I kept the renewal rate at 90%.  I assumed that configuring a SaaS system requires less PSO than customizing a perpetual one, so I assumed a 50% PSO bookings rate relative to the subscription (or 25% of the total PSO required from the perpetual vendor).  I assumed subscriptions were one year and revenue was recognized ratably over the year and that all orders were received the last day of the quarter.

When you make these two models, here is what you find:

In year 4,

  • The perpetual company is 2.2 times larger than the SaaS company at $62M vs. $28M
  • The perpetual company is growing at 103% and the SaaS one at 115%
  • The perpetual company has an 8% “annuity keel” in the form of maintenance renewal bookings while the SaaS company has a 33% annuity keel in subscription renewal bookings.  (You can’t see this in the picture, but it’s in the model.)

Valuation and The Fallacy of Equivalence
Using the standard multiples above, let’s see what each of our companies is worth:

  • The $62M perpetual company is worth 2.7 x $62M = $167M
  • The $28M SaaS company is worth 4.9 x $28M = $137M

Simply put:  the stock market works.  With only a 20% difference in valuation between what ostensibly seem like two very different companies you can see that higher EV/R multiple for SaaS companies is almost completely offset by the increased difficulty of building a SaaS revenue stream.  Wall Street “sees through” the differences in the models and values the companies roughly equivalently.  Put differently, SaaS companies fetch 1.8x the revenue multiple of perpetual companies because they are worth 1.8x the revenue multiple of perpetual companies.

During the past few years I have spoken with several CEOs who transitioned their companies from perpetual to SaaS.  The standard word is that it takes 3 years to make the transition and the transition must be a top-three company goal for that entire period.  While there are many good reasons for perpetual companies to consider moving to SaaS models, valuation isn’t one of them.  Yes, you get roughly twice the EV/R multiple, but building the R (revenue) stream is just about twice as hard.

Max Schireson calls this the fallacy of equivalence.  If gold is worth twice silver and assume we have an equal amount of gold as we had silver then we are worth twice as much.  The fallacy is that gold is twice as hard to come by as silver so you can’t assume equal amounts — see the huge revenue delta which is largely driven by the SaaS company’s need to spread revenue over 4 quarters.

Taking a Bad Quarter
Let’s look at how each company takes a bad quarter by assuming that we hit 70% of our bookings target in 3Q13 — doing only $4M in perpetual license bookings (cell P8) and only $2.25M in new subscriptions (cell P27).

  • In the perpetual company 3Q11 revenue drops from $8.7M to $6.7M, the year/year growth rate drops from 105% to 58%, the stock is presumably crushed  by 80%, and the CEO summarily fired.
  • In the SaaS company 3Q11 revenue is unchanged. (Recall I modeled all bookings on the last day of the quarter.)  4Q11 revenue drops from $4.5M to $4.0M, 1Q12 drops from $5.8M to $5.6M, and the following two quarters also take ~$100K to $200K hits.  The stock drops 20% because 4Q11 guidance is dropped but the company appears in control of its business and no one is fired.

Hitting The Flat Part of the Market
Now let’s examine both companies assuming that the market goes flat in 2014 (i.e., that 2014 license bookings / new subscriptions do not grow over 2013, cells S8-V8 and S27-V27).

  • Our perpetual company sees 2014 revenue growth slow from 106% in 2013 to 17% in 2014.  Revenue drops from the plan of $62M to $35.9M.  The CEO is fired for flying the company off a cliff.
  • Our SaaS company sees 2014 revenue growth slow from 141% in 2013 to 76% in 2014.  Revenue drops from the plan of $27.9 to $22.9M.  The CEO is commended for successfully managing the company through a tough transition.

What going on here is simple:  volatility is being damped — for better and for worse — by the SaaS company’s need to spread revenue over the four quarters following the booking.  That makes it harder to grow the revenue stream quickly.  It also makes it harder to change once established.

Sales Compensation
One tricky issue in the SaaS model is sales compensation.  In a typical perpetual company total sales commissions (at all levels) add up to around 10%.  So, for 100 units of revenue, you pay 10 units in commissions.  Sales reps are usually not paid on the 20 unit annuity stream of maintenance renewals.

In SaaS model, we have a conflict.  If you assume the annual subscription fetches 50 units (i.e., if F=50%):

  • The company wants to pay 10% of 50 = 5 units in year 1 and then pay little or nothing on the renewals.
  • Sales want to argue either that [1] the deal is worth 150 units over three years and compensation should be 15 units or [2] (if they’re good at math) 300 units if you look at the stream’s terminal value (factored by renewal rates and discounted by 8%) and thus sales compensation should be 30 units.

So what do you pay:  5, 15, or 30 units?  I believe that most SaaS companies end up splitting the difference in the some way, perhaps paying on a declining scale over the first 3 years.  If you have good examples here, please share them in the comments.

While I didn’t model cash in the spreadsheets, one huge issue is the timing of commission payments.  For example, if a company were to adopt the 3-year 15-unit commission argument and foolishly pay those three years up front, it would have a big cash consumption issue because effective year 1 commission rates would be 15/50 = 30%, three times the industry norm of 10%.

I think the best answer is to pay commissions on an declining scale and timed close to the receipt of cash from the customer (e.g., on booking the annual renewal).

What if F>=1?
Recall earlier that we talked about the fraction, which I called F, that represented the fraction you would be willing to pay to use something for a year as opposed to license it forever.  Because of the big difference between “forever” and “1 year,” I led you easily to the assumption that F should be less than 1.

But should it be?  When you look at total cost of ownership, it’s not obvious.  In the perpetual  model you need to license the software, pay annual maintenance, pay typically 4x the license payment in total deployment costs, and buy the hardware on which the system will run.

In the SaaS model, you have the subscription cost each year and some modest year 1 costs to configure the application.  See this simple model:

With F at 50% the SaaS TCO is $200K vs. $610K for the perpetual model.  With F at 100% the SaaS TCO is $400K.  Even with F at 150% the SaaS TCO is $600K — still less expensive than the perpetual TCO at $610K.

And this, by the way, isn’t theory.  A friend who worked at Siebel told me that a typical Siebel sales perpetual license seat sold for about $1,500 back in the day.  A friend’s company recently renewed Salesforce at roughly $100/seat/month, that is $1,200/seat/year — not quite F=1, but in the same order of magnitude.

Let’s finish the post by seeing what happens to our model when we assume that F=1, i.e., that the SaaS vendor can get an annual subscription equivalent to the license fee a perpetual vendor would have charged.

In year 4, our our SaaS company is now $55.8M or 90% of our perpetual company, but with all the added benefits of being on a SaaS model.  In terms of valuation it is now worth $274M vs. $167M for the perpetual company.  This is clearly SaaS panacea.  The implicit assumption that an annual subscription to use a service should cost less than equivalent perpetual license is both invalid from a customer TCO viewpoint and suboptimal from a SaaS vendor viewpoint.

While this would seem to suggest that every software vendor should switch to a SaaS model, it is important to remember that many customers don’t want to buy — particularly development platforms — on a SaaS basis.  Why?  Some of it is about ownership and control.  But much of it is because many customers think on time horizons much longer than a 3-year TCO.   With F=100% in our TCO model (and ignoring TVM effects), the SaaS system becomes more expensive after year 6.

If you like playing with financial models, I encourage you to download the model spreadsheet that I built for this analysis, play with the assumptions, and share your own conclusions.  My plan is to do some open source analysis by setting F=35% and the license fee to zero.

36 responses to “Perpetual Money vs. Perpetual License: Subscription, SaaS, and Perpetual Business Models

  1. Pingback: Tweets that mention Perpetual Money vs. Perpetual License: Subscription, SaaS, and Perpetual Business Models | Kellblog --

  2. Here was a comment I got over email.

    “You know the bumper sticker: ass, grass, or cash, nobody rides free. I think boards today are thinking SaaS, PaaS or I’ll have your ass because we think the ride is free.”

    Too funny.

  3. Hi Dave,

    This is interesting stuff. I tried downloading the model but I get javascript errors (and no download) from scribd when I do so.

    James Dixon, Chief Geek, Pentho

    • James,

      Not sure what’s going on. I just tested it and it worked. Don’t try to view it in their iPaper format; it gets all mangled. You need to hit “download” in the upper right hand corner, then select .xslx for the format. Perhaps try a different browser? I use Firefox. Thanks! Dave [meantime I’ll mail you the file.]

  4. Do you have a feel for how much the valuations would change if additional costs were considered? SaaS would have higher direct operating costs and the open source model could have reduced engineering costs.

    Enterprise perpetual license fees are often highly discounted. I would expect the other two models to have less pressure to discount, simply because perpetual licenses are perceived to have a low marginal cost to the seller.

    • The revenue multiples I took from the survey were averages of real numbers from SaaS companies — so the revenue multiples look only at revenue (and implicitly growth) and the EBITDA numbers do factor in all operating expenses (including the “extra” ones from SaaS). If your hypothesis is correct we’d expect to see a more dramatic increase in SaaS/perpetual EBITDA multiples and we do (44 vs. 13, instead of 4.9 vs 2.7). If you like SaaS topics in general check out Bruce Cleveland’s blog where, among other posts, he has a nice one on SaaS capital requirements.

      On open source, I’m less sure you’re right. Why? Because while R&D should be relatively smaller, remember that revenue is relatively smaller too so the question becomes which one is more relatively small? Look at SaaS powerhouse RedHat. In 2010, they did $750M in revenues and spent/invested $150M in R&D — they spent 20% of sales on R&D which I’d argue is generally high for a ~$1B software company. So if RedHat is the model, the answer would have to be counter-intuitively, no.

  5. This is really nice analysis Dave! One nit that I have, however, is that you are talking about pricing models rather than delivery models. Installed software can still be priced as a one-year term license that is renewable and some companies are adopting this pricing model. In other words, it is a term model that you are modeling, not a SAAS model that you are modeling (most SAAS companies do use term models, but I have seen a few that have perpetual pricing plus a hosting fee).

    I am on a mission to get people to delink pricing models from delivery models so that they can optimize each independently!

    thanks for the post and all of the work that went into it.

    Scott Maxwell
    OpenView Venture Partners

  6. Scott,

    Point taken. You can either sell term licenses or N-year subscriptions to on-premises software as well. I agree that pricing model and delivery model are delinkable (I suppose you could charge perpetually for a delivered service as well, though it’s not a good idea). Further, I know many old-style software companies that made heavy use of term licenses (e.g., Verity) but who did so primarily as a discount-avoidance mechanism rather than a renewability one. For example, I’d argue that Autonomy got a heck of a deal on Verity because it’s valuation was more in line with a perpetual model when in fact Verity had done plenty of term licenses that would later need renwewal.

    That said, I think the F factor in my models would vary across delivery models as a term license delivers “less value” than a fully delivered SaaS service.

    Thanks for your comment.

  7. Dave,
    We agree, but you actually triggered a different point that I try to make with entrepreneurs, which is to create a delivery model that is best for their target customer. If the customer wants on-premise, then give them that. If they want SAAS, give them that. If they want professional service, then give them that. Certainly, they can try to pick targets where the value prop delivery model is in keeping with the best economic results, but if they don’t deliver the best package to their customer, then it is likely that someone else will.

    Separately, you can and should try to get term-based/subscription pricing whatever the delivery model is, but customer also have a point of view on those. Some customers still want to pay up front and others want the costs to be spread out (many times it comes from the budgets that they have available).

    Entrepreneurs can still encourage the delivery model that they prefer to offer and they can still try to have a pricing model that is more term/subscription-based, but if you don’t offer what your target customer wants, someone else probably will at some point.

    This doesn’t counter anything that you wrote, just pointing out to your readers that they don’t make 100% of the decision about what approach to use.

    Keep the great writing coming!


  8. Excellent article !

    The issue of sales comp plans is one of the thorniest for a company that wants to switch to SaaS, even for a private company. Finding the right model is tough and shared experience would be welcome !

  9. There one additional point i would like to mention, is the challenge of discounting in a SaaS model. At the contrary of the perpetual licence, a discount in a licence mode may be… perpetual.
    A way to avoid this is to put the discount up front as a number of period free (i;e the two first months free), nevertheless the client who have set up its budget on yearly basis will try to get this discount the following year.

  10. I have sold both. You mention: “SaaS system becomes more expensive after year 6.” I agree with this as far as what money is spent with the vendor, but I think that we need to look at what it costs the customer to maintain a SaaS model vs Perpetual model. I believe that the amount of effort on both the customer and the vendor sides are reduced with the SaaS model. The reduction in the customer’s cost of staff time and hardware is what makes the SaaS model so appealing. Having all of you customers on the latest version in one multi-tenant database is easier to support. It also allows for consistent delivery of a quality solution with less room for error on the customer’s side.

    With experience, customers will lean towards SaaS and so will vendors. The sacrifice is flexibility and control, although salesforce and others put forth a good argument against that statement.

  11. Dave, this is a terrific post.

    I’m curious about the CEO’s you spoke to regarding SaaS transformation (from a perp license model). I am not aware of any companies that have done this successfully. Would you be able to share the names of those companies, and any commonalities to their methods that might be instructive to other ISV CEOs?

  12. I realise I’m coming a little late to this party, but. . .

    Scott said:
    “delivery model that is best for their target customer. If the customer wants on-premise, then give them that. If they want SAAS, give them that. If they want professional service, then give them that. ”

    I couldn’t agree less.

    This is selling to IT, not the business. ALL the business cares about is a service to the screen, and that’s it. Forget about SaaS, it’s simply the …S that the guy with the checkbook cares about.

    The concept of supplying your ‘goods’ via multiple delivery mechanisms seems to me to be a recipe for disaster. Get your product/market fit right, and that’s the direction you focus on, surely?

    I’m trying to get a start-up off the ground at the moment, and all my customers seem to care about is the service . . . the information on their screens . . . not how it gets there. SaaS seems to me to be an /internal/ business model. Not something the client cares about.

    • I get where you’re coming from but can’t entirely agree. One day, perhaps, software and information will really be like electricity — I just want it to, I expect it to be on / working, and I don’t care where it came from. (Unless of course it’s nuclear, in a tsunami zone, and near the beach …. I digress but some things can make us, quite quickly, starting caring about things we didn’t previously care about.) But today, some business customers very much do care about things like where my data will reside (e.g., try selling the NSA or GCHQ a public-cloud-based service for intelligence data) and I also care about the business model. For example, there is no ability to “own” the software in a SaaS model which means [1] an astute business person will notice that they pay for it every year and [2] to the extent that alternate suppliers do not exist that I am very much dependent “on the kindness of strangers” for the SaaS provider to not double or triple prices. For example, if LexisNexis is rebuilding their search platform, trust me, they do not want to rent it every year, because they are planning on using it for the next 25.

      So yes, overall, I get your point. Most businesses just want it to work and don’t care about the delivery model. In fact, they do care to the extent that they’d rather not spend their own resources doing things that can be don more efficiently by others.

      • This is rather long . . . sorry if it is a bit /too/ long.

        “some business customers very much do care about things like where my data will reside (e.g., try selling the NSA or GCHQ a public-cloud-based service for intelligence data)”

        Ummm. Yes. Fair enough on that one. But do you not feel that using National Intelligence Agencies as an example is perhaps a /bit/ of an outlier? Further, and perhaps more to the point, I would doubt that we would see much SaaS for /any/ enterprise with unique requirements.

        Regarding the business model, I can certainly accept your comments about not owning the software . . . and the hope that the price won’t get raised in the future. I’m just not sure that many business persons /care/ too much about that.

        Here’s what I mean:

        In trying to supply business intelligence to hospitals (using a SaaS model), I find that my clients really care only about what they get on their screens. Their main non-functional requirements are accuracy, reliability, and timeliness. The SaaS idea appeals to them only insofar as it means those non-functional requirements are met. Interestingly, there’s also an appeal insofar as they’re no longer dependent on other *internal* groups to act as gatekeepers between their raw data and their business intelligence. For these customers, not owing the software themselves is simply a non-issue.

        Further, I’m not at all sure that many people actually pay all that much attention to long-term costs. Many executive positions have very short lifespans. Hoggett Bowers studied the length of tenure of NHS Acute Trust CEOs, and found that this was, on average, 2 years 4 months. In the UK, there’s a form of State spending called the Private Finance Initiative (PFI). “According to data obtained by the BBC, 103 PFI projects that were originally valued at £11.3bn will cost the NHS more than £50bn to repay. Once extra costs such as maintenance, cleaning and catering are considered the NHS is due to pay back £65.1bn over the lifetime of the deals, some of which last 25 years.” (Guardian Aug 13 2010). It seems to me that many executives have short-term views. £11B -> £65B? Even amortized over 25 years, this still seems to be a dreadful rate of return!

        I’ve pointed to the NHS, but I think that people in software companies that use an outright sales model are worse. The horizon often seems to be no further than next quarter’s results.

        In any case, I’m completely with you when you say: “Most businesses just want it to work . . . “. Whether SaaS or whatever, I’m sure that’s something we can all agree on.

  13. I have to agree with Donna on this. It is too difficult to go to market with multiple software delivery models. “jack of all trades, master of none…”

    Consider the end of quarter push for revenue to make the number. The first thing the Sales VP is going to do is go the the forecast, look for SaaS deals in upside or commit, then try to flip them to perp license. (implication: take full license revenue NOW, vs virtually NO revenue in the quarter for the SaaS transaction.) *And* he/she will have to offer a substantial discount to get the customer to accommodate a different consumption model (having to now swallow the cost of infra, resources to support the on-premise version). So cut the legs out from SaaS deals, while hurting license margins. I’ve seen this happen enough to know that this “jack of all trades/offer them options” approach is disastrous for any company attempting to be a real player in the SaaS space.

    This is just one example. There are implications that ripple thru Engineering, Product Management, Marketing, Indirect Channel, Professional Services, Finance, etc., with a “jack of all trades” approach.

    The SaaS model can’t get out of first gear as long as there’s a perp license option. Pick one or the other, but don’t do both (except in a well planned, short-as-possible, transition period). If the argument being made is that the market demands both, then pick your market… OR, for the hosted option, rely on MSPs in the indirect channel. Could be an interesting play for them.

    • Greg,

      you mention “except as a well planned . . . transition period”. I’d like your opinion on this:

      It’s my thought that I could /loan/ a server with our stuff on it to a prospective client as
      a) part of the sales process (free samples, try before you buy, etc.) and
      b) as part of the client take-on process (local data cleansing and all that).

      I recognise difficulties, the need to set the scene, manage expectations, and so on . . . but even so . . . do you think there’s merit in offering such a transition period?

      I don’t intend to ever offer an on-premise purchase option . . . the idea is that the only way to fly would be the fee-per-transaction way of doing business. (A transaction might be an OR procedure, an emergency attendance, an in-patient admittance, and so on.) FYI, the market is such that there are fewer than a thousand potential clients, but each client would be high five-figure value.

  14. I’d say it can be done but I certainly don’t recommend doing it. The case is very different for a startup [where you can start clean — and in such cases pick and hold to one model, accepting its consequences] than an established company in transition. Saying it can’t be done is theoretically right but empirically contradicted by Pegasystems and others. Even Jive, who were imagine as pure subscription play, says in their S-1 that they do term and perpetual deals. Messy? Yes. Impossible? No. Recommended? No.

  15. Donna, you say: “I don’t intend to ever offer an on-premise purchase option…” So is your current model SaaS, or ASP/Hosted, or an on-prem managed app?

    Whatever the case, when it comes to SaaS transition, there’s more latitude if you have have a high margin business in a finite market with little competition. But if you’re up against any SaaS pureplays, get ready to move fast…

    There’s a great Sandhill post on SaaS transition… good read…

    • “is your current model SaaS, or ASP/Hosted, or an on-prem managed app?”

      I don’t know the difference between SaaS and ASP/Hosted, I’m afraid. Our model is 1) take the customer’s raw operational data and transfer it over a VPN to 2) our data warehouse (on our kit) that mashes it up and then 3) delivers consolidated business intelligence back over the VPN to end user screens with 4) charging based on the number of raw transactions we process per month. The idea is we have one set of kit and one data warehouse and one set of BI reporting for many users in many clients.

      As an example, a hospital does 1000 procedures per month, we charge $10 per procedure, that’s $10K per month charge to the client. We don’t care about number of users/seats. Assuming we can get up to speed, then our margins will look very attractive. Our status today is somewhere between Seed and Series A.

      We are not transitional. We are SaaS pureplay, and to my knowledge, the /only/ SaaS outfit in this market segment. AFAIK, our competition is on-prem outright package sale and/or hospital internal IT departments.

      I’d sure like to hear your opinion of the model I’ve described.

  16. Pingback: Watercooler talk: Tale of 2 economies – USA and Australia :: Verity Business Solutions Pty Ltd

  17. Pingback: The Road to $1 Billion | Chet Hayes

  18. Pingback: Thoughts on the Splunk IPO and S-1 | Kellblog

  19. Pingback: The Right Time To Raise Money At A Startup | Kellblog

  20. Pingback: Software as a Service provides a way to control copyright « servicesectorblog

  21. Pingback: Modeling startup revenue: subscription vs perpetual license | Gordon's shares

  22. Hi Dave,

    I’d love to play with your spreadsheet. However, I tried downloading the model but scribd says it can’t find the document.

    John Hendry, Chairman, Zap Technology

  23. Would you consider changing your Scribd settings so XLS files can be downloaded for free? Thanks!

  24. Pingback: PODCAST: IFS' cloud strategy explained by CEO Alastair Sorbie - IFS Blog

  25. Pingback: Revenue Multiple Demystified: Tech Valuations 101

  26. Pingback: A Look at the Tintri S-1 | Kellblog

  27. Pingback: A Look at the Tintri S-1 - Enterprise Irregulars

  28. Pingback: A Look at the Tintri S-1 – Kellblog

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.