The economics of continuous deployment
One of the things that I did, almost by accident, when we started Hibernating Rhinos was to create a CI server and a public daily build server. And every single successful build ended up in customer hands. That was awesome in many respects, it removed a lot of the “we have got to make a new release” pressure, because we were making new releases, sometimes multiple times a day.
When we started with RavenDB, it was obvious to me that this was what we were going to do with it as well, because the advantages to this approach as so clear. With RavenDB, we needed a two stage system, but still, every single build gets to the customer hands.
Awesome, great, outstanding, exceptional and other such synonyms. As long as you look at this from one angle, the one in which we are only concerned about the technical challenges of delivering software .The problem is that there are additional things to note here. Economic challenges.
Let us take the profiler as a good example. It was released in beta on the Jan 1, 2009, and since then we had 920 separate builds, adding a ton of new features, capabilities, improving performance, making things smoother and in general making it a better product.
That is over 3 years without a major release, mostly because we never had the need to do this, we kept delivering software on a day to day basis.
During that time, we delivered features such as viewing the result set, checking the query plan of a query (in all major databases), exporting the entire session to HTML so you can send it to your DBA, CI integration and so much more. It has been wonderful.
Except… this has one implications that I didn’t think of at the time. If you bought NH Prof on the 1st Jan, 2009 you got 3 years of product updates, for no additional costs. And unless we create a new major version, you can keep using the software, including all the updates and improvements, without paying.
That is great for the very early customers, but not so good for the people who need to eat so they can work on the profiler. Let us think about the implications of this a bit more, okay?
In order for us to actually make money, we have to:
- keep expanding our one-off customer base, which is going to hit a limit at some point.
- create a new version, getting the old customer to purchase the updates.
Seems simple, right? This is what most companies do, and how most software is sold. You get a license for version 1 and you buy a license for version 2.
So far, so good. But let us consider the implications of that. In order to get the old users to buy the new one, I have to put some really nice stuff in the next version. Which means that I have to do a lot of “secret” development because I can’t just release it on our usual continuous deployment mode. That sucks. And it also means that features that are already coded are actually disabled because we defer them to the next version.
So, the next version of the profilers is going to have to have some interesting features to get people to buy it. One of them is production profiling. It has actually been around for quite a while. It has simply been #ifdef’ed out of the product, because it is something that we keep for the next version.
I just checked, and I was acutely surprised by what I found. The initial work for production profiling was done in Jan 2010, it is working since then. I got side tracked with RavenDB so I never had the chance to actually complete the rest of the features for 2.x and release them all.
In mid 2010 we started experimenting with subscriptions. Instead of having a one time payment model, we moved to a pay as you go. So as long as you were using the profiler, you were paying for it, and in return, we provided all of those new features.
I have been thinking about this a lot lately. I strongly lean toward making the next version of the profiler (coming soon, and it will have a bunch of nice features) subscription only.
My current thinking it to allow two modes of buying the product. Monthly / yearly subscription and a one time fee that give you 18 months of usage (and doesn’t re-charge). That would allow us to keep producing software in incremental steps, without having to go away for a while and work in secret on big ticket features just so we can have enough stuff to put on “why you should buy 2.x” list.
I would appreciate any feedback that you may have.
Comments
Personally I really like the pay once get 18 months of new features.
I don't see a problem with the subscription only model. Most web applications focus on there business model around this, so why can't installed software.
My only note would be, to build the subscription renewal and purchasing right into the application itself, so I don't have to go to a site or wait for an email to get delivered.
I like the idea of subscriptions, but a lot depends on pricing structure. i.e. if 12-month rolling subscription turns out to be more expensive that an 18-month license, then I won't bother with subscriptions.
If I buy something I want to be able to use it as long as I want. Like @Chad Myers said, buy a one time license and let people decide to buy updates (software maintenance).
Just like this software: https://shop.paessler.com/en/prtg
Apart from this there is also the other side of the economics: the fact that some old-fashioned IT managers like version numbers. Sometimes they like it so much that they have created company-wide policies regarding to version numbers (e.g. "we never ever use 0.x releases"). This is obviously silly since you can't compare two totally different products just by version numbers but you may want to consider adding "real" version numbers to your products instead of just using build numbers. As long as you only use build numbers people might assume that you're still in a beta stage and your product is not stable.
Not so much of a problem for UberProf since that's a developer tool. This may be more of an issue for RavenDB however...
Have you considered that by switching to a subscription model you may find yourself at a point in time where you (and the users) are happy with what Profiler does.. but feel that you must continue to add features so that the subscription continues to have value?
And if you're thinking subscription.. what about a 'day pass' kind of idea where I can rent the software for 24 hours? Obviously the pass would have to be quite expensive..
Shane, There are additional things to software than just development. Support is one example. But I am not really afraid of running out of things to do, worst case scenario, I'll do perf work :-)
And there are always new things, new versions to supports, new reprts, etc.
As for a day pass, how would you price such a thing?
Actually regarding the day pass.. scratch that idea. It helps the user do the wrong thing. People shouldn't be pulling out a profiler once a year to fix a problem. They should be using it every week to double check that new feature they just built.
And yes.. I was taught well the idea that for every $1 spent on my development work the company had to make $4.. but eventually every product (should) be done.. look at the monstrosity that has become Word because MS HAS to push a new version. I guess it comes down to which is going to happen sooner.. we stop using ORMs.. or you run out of good improvements for the profiler :)
I could live with the pay once and get 18 months of new feature. However, I want to decide after 18 months if I WANT to upgrade. Please don't force me to upgrade after that.
In other words, if after 18 months I'm happy without the new features, don't disable because it doesn't run the latest version.
I like the idea of buying 18 months worth of updates and then getting the option to renew or stay stagnate. However, I don't see how that idea necessarily solves your issue. Wouldn't you still strategize when to release "New Feature XX" when your largest group of 18-month license holders expires?
Eric, I am talking that after 18 months, the software stops working
I think the subscription (recurring or non-recurring) model is fine, especially since the update stream is so constant.
The only difficulty I see is providing bug fixes to old versions. Let's say that I upgrade a day before my subscription expires, and there is some critical bug. You can release a patch the following day and provide an exception, but that patch (due to the CI nature of the product) may include new features that the user didn't pay for. Customer service
However, if the update stream gets stagnant, paying users tend to get aggravated and even resentful. The makers of Trillian (IM client) have tried this model numerous times, selling temporary subscriptions of, say, 12 months, while their release cycle is 16-18 months. A similar thing happened with Microsoft when they first started selling Software Assurance with Windows XP, but Windows Vista was released after most SA contracts expired.
And now you understand why SQL server licenses are so dang expensive :)
I find the subscription model to be very convenient as a personal consumer. I'm a consultant, so that's where I come from, I often buy my own tools. As long as it's easy to see the improvements and new coming in regularly I feel like I'm getting my money's worth. I feel like if I know that the service provider is holding itself accountable and I can easily see that, I'm happy to keep paying month after month for incremental updates.
Ayende, if the software stops working after 18 months, what is the difference between subscription and one time payment? There would be a discount on the 18 months OTP and that's it ?
I would prefer something like this: - One time payment, get new features for 18 months, then auto-update stops working. - Subscription, get new features as long as you are subscribed, stops working if you unsubscribe, discount over OTP.
What do you think ?
That's what I was wondering. Essentially the 18 month option would work like a subscription, but you have to "self-renew" every 18 months, whereas the annual would "auto-renew". Ultimately I think numbers would be the major deciding factor. If the annual subscription is a good/fair price, why not? I think, though, most of us would prefer to not have something that stopped working without our consent. Do you have any estimations on what you were thinking for pricing?
We have a similar situation with our main product and I would strongly recommend NOT to go with a subscription only model, as this will be a show stopper for many customers (which I absolutely understand - recurring costs can kill your business very easily).
This is what we have done: Buying a license enables you to get 12 month of updates and phone-support for free, beginning from the day of purchase. Afterwards you can optionally get another year by paying 30% of the initial amount. This sounds similar to your 18month suggestion, however, the important difference is that our software doesn't stop working if the customer decides not to renew his license. In practice nearly all customer renew anyway, but it is a very important psychological selling-argument, that renewal is optional and they actually own the software when pay a lump sum.
"My current thinking it to allow two modes of buying the product. Monthly / yearly subscription and a one time fee that give you 18 months of usage (and doesn’t re-charge). "
This is a good move. Recurring budgets are sometimes hard to establish in a company.
BTW, your comment section doesn't look right on Chrome.
Anyway, I hate your auto-updating feature. Hate it, hate it, hate it. You show a button that says ' new build available' and then update anyway even if I explicitly don't want to click the damn button.
Why don't you do the obvious? After 18 months, the software stops updating, but whatever last build was downloaded keeps working?
I would encourage you to consider the model Jetbrains uses with Resharper: you buy a license to (effectively) 1 year of free upgrades and support. After that time, support and upgrades are not available until you renew your license. Also, if a new version of Visual Studio is released, you MUST purchase a new version of Resharper to use with the new Visual Studio.
Jeff, They can rely on VS to have a new version, because of the same reason. I can't really do that.
I have to say, I can't see buying software that expires. I would prefer the option of buying software with updates covered for X amount of time, and the updates stop at some point in time, but the software continues working. If there's a trigger that stops the software working, I couldn't justify purchasing.
I totally agree with the folks who vote for the subscription being to the updates, not the product (i.e. please don't disable what I bought). I can completely understand why from your perspective it seems to implicitly improve the odds that there will be recurring revenue (or else), but from my perspective I'd think of it as kind of a dick move to force me to only be able to rent the software (given that the product is unquestionably awesome, it seems likely to me that there will be some feature, bug fix, or flat out compatibility requirement that will encourage me to renew/upgrade...establishing a system that forces my hand would just feel shady to me). Just my 0.02USD...
I I believe that you should get paid for the work that you do, but I don't like being forced to pay for things I don't necessarily want.
Could you bundle those 18 months of updates you've mentioned at a higher price than the sum of those same months would cost as a subscription? The extra cost could buy those consumers the right to keep using the last version they had access to in perpetuity.
Or do a subscription, but then let the consumer pay some amount to "freeze" their subscription where they are. Sort of like buying a car after your lease is up...
I'm very interested in the idea of a subscription. Has the potential to be more beneficial for all involved.
You get to keep doing continuous development (which I think makes for better quality software) without hiding features.
Customers know exactly what they get and what they expect; if I know that someone is continuously improving a product, I'm much more likely to not mind continuously paying for it. Customers also have an excellent veto -- if you slack on updating the software continuously or fixing defects, they can cancel the subscription. It's much more tied to the current series of events.
And, regular payments ends up being better for you because folks are less likely to cancel or have to make "big decision" about renewing at large cost. Additionally, you can forecast precisely how much money you'll be making, check your subscription attrition rates, etc. The addition or cancellation of subscriptions due to the current events also helps you gauge the direction your software is expected to head, and helps you form a more realistic set of metrics than finding out folks didn't like the last 365 days of development time.
If priced right, I think subscriptions (at least in this arena) should become the dominant form of licensing.
Another option could be to release new features as part of the CI cycle, but the features are disabled for license keys that are more than (say) a year old. The numeric range of the license key could determine when it was purchased. Old customers would continue to get bug fixes for the features they purchased, but not new features.
Sean raises some excellent points. I'd just prefer software not be disabled (frozen at a version is ok) at the end of some time period...look at the P.R. shitstorm Redgate brought on themselves with Reflector. We need a happy medium.
I would suggest doing what many software providers do this these cases, allow us to buy the software with updates for 1 year and then have the option annually to pay for upgrades through maintenance fees - A Subscription (typically 15-30%) annually. If a customer doesn't subscribe they keep the version they are on keep going forever. If you subscribe you keep on getting updates until you no longer subscribe.
Ayende, is it possible that, when a person purchases a license, the license is 'locked' to that version. say .. build 616.
Now, if i bought the 18 month license, then for the next 18 months from the purchase date, i get free upgrades. But after 18 months, no more upgrades -BUT- i can always use v616 for eternity (with my provided license file).
Or with a sliding monthly/annual subscription .. the same thing goes. while subscription active, license is ok. once i stop, no more upgrades. BUT of course, I can stick with v616 which was the most recent -stable- build at the time of purchase.
No idea how to code that.. but just thinking out loud.
I'm sure a hard-core version of this idea, is that instead of using v616 as the basis of your eternal copy, it's the current stable build number at the time your license ended.
Ext.Net has model similair like you're searching for. http://www.ext.net/store/
Its free and OS but if you have a subscription you get:
I won't go for 18 months but yearly. It's easier for you and the customer). We're quite happy with this model (and product). They only have to differentiate better between stable builds and interim builds.
The version that everybody can download is always a bit older and stable version.
Great article, and a concept I hadn't really thought about - very enlightening.
I like both the proposals, but I suspect most people will opt for the 18 month one off payment - so how you set price of this will be a big factor to how many "subscriptions" you sell.
Ayende, we work on a private LAN without a direct access to the internet. A subscription model probably won't work because it will have to "phone-home" for license checking. And a product with expiration date is something I don't feel comfortable with (If I bought a license for a project that's no longer in development, and after 2 years I need to fix a bug using the profiler, you force me to buy a new license).
If you pay once for 18 months and it then stops working, you're 'renting' the software (or, 'leasing' it).
Also, your subscription model works with profilers which are tools at the end of the line (i.e. a change in them won't likely break software they're profiling). For ravendb however, you'll sooner or later hit a breaking change requirement, or deprecation requirement. With a rolling subscription model, this won't work, as you need strict boundaries from which version things broke/changed. 'build 14637A from january 2012 contains the breaking change' is perhaps nice for some javascript lib you pull from github, but not a DB which is meant to be the foundation of mission critical data.
Personally, I'd never purchase 'rent-ware'.
I also like the concept of buying a software instead of renting it. I like the idea of having 18 months of free updates for my purchase, but I don't want the software to stop working after 18 months.
Maybe after 18 months my software is shipped and I don't feel the need to renew my license. However from time to time I would like to look at the software, maybe for a small bug, without having to buy the ultimate version of the product, just using the old version that I bought.
I know Resharper isn't directly comparable to your product for the reasons you mentioned. But I also like it's licensing model a lot. I usually buy the latest version of their software, knowing it's more or less every 12 to 18 months, but I take some weeks or months before I do this (waiting for a good time). I don't want to be in the middle of a project being forced to upgrade my license to continue working, when I'm perfectly fine with the version I had.
If you continue to add interesting features to the program which are useful to the people using it, then this will not prevent people from buying your product. Just like I buy a new Resharper every time.
Disclaimer: I'm not currently a customer of your products, so you can see my opinion either as a) objective or b) irrelevant ;-)
I can certainly see it from Oren's perspective...at least for the profiler, there are only so many of us out there that are going to buy it and he would like to establish a system that implies recurring revenue...scale the revenue vertically since horizontal scale is less likely, so to speak. It's just going to be tricky to find the right combination of justifications so it doesn't sound like you're just being yet another greedy software vendor (I know you're not, but it sure seems like a delicate line to walk). Though the reasons are plentiful and valid, to me software rental just doesn't feel right yet. Perhaps that perspective will change over time.
Another option could be to use different branch for each major version. You commit new features to the vNext branch, and bug fixes to the vCurrent branch. Whenever you feel like it, you release and sell vNext, open a new vNext branch, and so forth.
I'd say - go for the full-out subscription model. It's simple. The profiler gives continous value - so the customer should continously pay for it - and the profilers' features should be used when they are developed - not when an imaginary version line is crossed. Pricing is simple - bundles for 5-user packs, full-site license etc. And it avoids nitpickers arguments and sub-optimizations around expiration dates etc. For the ones having bought the profiler at present can keep it, but to get to vNext - subscriptions is the only option from then on.
I'd say - go for the full-out subscription model. It's simple. The profiler gives continous value - so the customer should continously pay for it - and the profilers' features should be used when they are developed - not when an imaginary version line is crossed. Pricing is simple - bundles for 5-user packs, full-site license etc. And it avoids nitpickers arguments and sub-optimizations around expiration dates etc. For the ones having bought the profiler at present can keep it, but to get to vNext - subscriptions is the only option from then on. (hope this isn't a re-post - hate captchas)
I really don't like the idea of software that stops working on a particular date. If the subscription is only to download updates and doesn't actually kill the application if you don't pay for it, I think that's cool, but you should be very clear and up front about it
I don't mind this licensing idea, as long as older version continue to work past the "support and upgrades" licensing period.
Let's say I buy v2 (or my current v1 licenses) and then support/license ends for that version. I would still like that version, the one I had last during an active support license, to continue to work as it always did. I don't expect it to start working with, for example, NHibernate 4 or ASP.NET 5.0, etc. when they're released, as that would be a new feature. I don't expect free upgrades in that case. But I would want it to still work for my old projects that I used with the older technology, for example NHibernate 3 and .Net 4.0 in the case of v1 right now — anything that I was using at the time I had an active Profiler support license.
Also, major bug fixes for recent versions past license expiration would be nice — within reason; if you're on v6, fixing some new bug that Windows 9 causes in v1 Profiler wouldn't make much sense. But when v2 Profiler is latest, and a bug/security issue is found in v1, even if you don't have a v2 license it would be nice to get the bug or security fix to v1.
I understand that a one-time fee can not perpetually get me support, nor constantly entitle me to the latest features and bug fixes. But I can not accept software to just stop working.
I can live with having to upgrade due to breaking changes in the OS or .Net runtime. But software that stops working is just plain evil. If I buy something I want it to keep working, at least in the context I bought it originally (i.e., same NH version, same .Net runtime, same Windows version...).
I second Musafa's take on this.
We ship a desktop product and use a yearly licence and the software stops working if it is not renewed. The annual purchase price is lower relative to our competitors and it is easier for our users to change to another product if they are not happy.
This seems to work well for our users and us. The upgrades, support and new features are included in the price. If they decide they're not happy and want to change then they have not invested as much in the first year. Because we make our money from the main licence, we do not have to try and sell support packages or other items that, in my view, lead to a more complex product for the user. You either in or you're out!
I would be happy to purchase software on this basis too, but I would think carefully about buying infrastructure that stopped working when the licence expired. If it were something like a hosted package, then that's fine. If it were something like RavenDB Embedded then I need it to carry on working should I not renew since I have to guarantee operation in the field for my users. I am effectively reselling what I buy from you. I ship on VistaDB now and have not renewed the licence as I know that I am going to migrate this year.
Another benefit I am hoping to see from the annual licensing model is to be closer to the demand for the product. If we start to do things wrong, or there is a better product out there then we see the renewals dropping off sooner than if we waited until a major release.
That's me as a seller. Personally, as a buyer I would be happy to buy a tool like your profiler on an annual basis + stops working basis, but I would not buy infrastructure I resell like RavenDB Embedded unless I could rely on it continuing to work. I think your balance with pricing more for year 1 of Raven Embedded than other years gives a good balance. I also personally hate vendors who use the model where they charge as much as possible but sell fewer units. That always leaves me with a bad feeling about them like I've been ripped off. I go with Seth Godin's philosophy of "the right price the first time". It leaves me feeling happy about the purchase!
I like this idea. Thinking of setting up some of the same setup aswell for my own projects. Have CI already, but might mix this with CD when I get a publish latest version to customer up and going :)
We are active in the financial sector, so our software must always be up to date.
We also work with a subscription model per concurrent user per month. Once there is a new version, the older version can't logon anymore. They can only upgrade. This is a safe guard to prevent 'user' to generate out-of-date contracts.
But we allow the customer to pay upfront for multiple users/months. That gives us the ability to provide discount and other marketing goodies. If the license isn't renewed than the application stops working.
@Oren: just to be very very clear, when you say "the software stops working" you mean the engine? the database engine stops working?
I mean, let us make an example, shall we? We decide to use RavenDB, so we build a software for a customer on top of it, we finish it, tests go well etc... then we deploy the software to the customer's servers and everything would be fine. In an entire year the customer found zero bugs, there are rainbows in the sky, butterflies and everything.
18 amazing months of non-stop happy work for the customer goes by, and one day, after 18 months + 1 day... everything would stop? in production?
That is the case? Please tell me i'm wrong.
Cheers, Ermio
Please also consider floating licenses.
I'm against the whole "disabled after x months" thing - but floating licenses are a must for us. We are a software shop with 20 devs, and only 60 people in the company. All 20 devs do all dev work, so saying "if you have nhibernate problems, see Joe" is out of the question. At the same time, we're a small company, and NHProf is probably used for a total of 20hrs a month among all of our devs - so we bought 5 floating licenses because we couldn't afford 20 regular ones.
We simply can't justify 20 subscriptions. And if I pick two people out, then they have to stop what they're doing to help others - if those two are doing higher priority work, that doesn't make sense.
So whatever you do, please keep the "small shop" in mind.
Ermio, We are talking specifically about the profiler here, not RavenDB. The way RavenDB expiration works, even if you are overdue on the subscription, you can keep using the database. You'll get a warning when you look at the UI, but the database functionality is going to be there.
@Oren: that seems more reasonable. Though I have to say it's kind of strange to have a mixed license: you pay once to "buy" the engine and "rent" the studio. Thinking about it it kind of makes sense, since (thinking about a single project) one usually use the engine and the studio at the beginning and then, if everything goes well, only the engine must run without limits.
One question: the studio is in some way bounded to a specific instance? Practical example: we buy 1 license (599 $) and we get some time with the studio + unlimited running time for the engine instance. Then, 2 years from now, we'll decide to buy another 1 license (599 $ again) so we get some other time with the studio + another engine instance running forever. The studio may than be used with the old instance or there's some trickery to avoid that? Sorry if this question may sound stupid, but i have some people asking small details like these and i need to give them answers.
Cheers, Ermio
Ermio, The studio is actually embedded inside the engine. They aren't separate. The error you get in the UI is just that, informative and doesn't give you any problem with regards to actually using it.
"I am talking that after 18 months, the software stops working"
This is never acceptable. If I bought software directly, it is mine to take to the grave.
As others said, 18 months of support/updates and after that those end is fine, but not deactivating the software itself!
I would agree with the sentiment that "stuff that I bought should be mine forever" -- this feels like a very primal thing. :) On the other hand, I think people might warm up to the idea of rent-ware if the price difference was significant. Something along the lines of "you can rent the profiler for $20/mo, or buy it for $500, and that gives you a year's worth of free updates".
Perhaps this has been addressed elsewhere, but I was just wondering what factors went into the decision to make it so that renting efProf at the monthly rate for 12 months is actually a bit cheaper than renting it at the yearly rate. (Not a complaint at all...just curious).
Brian, That isn't the case, actually. What you see is the strangeness of currency fluctuations over time.
Doh! I had considered that but for some reason when I looked at the non-USD pricing my brain still saw it as less. Must have been running low on blood redbull content. Cheers!
Comment preview