http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Doh! 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!http://ayende.com/154689/the-economics-of-continuous-deployment#comment56http://ayende.com/154689/the-economics-of-continuous-deployment#comment56Fri, 30 Mar 2012 15:26:02 GMTBrian, That isn't the case, actually. What you see is the strangeness of currency fluctuations over time. http://ayende.com/154689/the-economics-of-continuous-deployment#comment55http://ayende.com/154689/the-economics-of-continuous-deployment#comment55Thu, 29 Mar 2012 21:43:56 GMTPerhaps 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).http://ayende.com/154689/the-economics-of-continuous-deployment#comment54http://ayende.com/154689/the-economics-of-continuous-deployment#comment54Thu, 29 Mar 2012 21:19:36 GMTI 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". http://ayende.com/154689/the-economics-of-continuous-deployment#comment53http://ayende.com/154689/the-economics-of-continuous-deployment#comment53Thu, 16 Feb 2012 22:21:36 GMT"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!http://ayende.com/154689/the-economics-of-continuous-deployment#comment52http://ayende.com/154689/the-economics-of-continuous-deployment#comment52Wed, 15 Feb 2012 18:53:26 GMTErmio, 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. http://ayende.com/154689/the-economics-of-continuous-deployment#comment51http://ayende.com/154689/the-economics-of-continuous-deployment#comment51Wed, 15 Feb 2012 10:04:00 GMT@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, Ermiohttp://ayende.com/154689/the-economics-of-continuous-deployment#comment50http://ayende.com/154689/the-economics-of-continuous-deployment#comment50Tue, 14 Feb 2012 20:09:51 GMTErmio, 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.http://ayende.com/154689/the-economics-of-continuous-deployment#comment49http://ayende.com/154689/the-economics-of-continuous-deployment#comment49Tue, 14 Feb 2012 07:48:04 GMTPlease 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. http://ayende.com/154689/the-economics-of-continuous-deployment#comment48http://ayende.com/154689/the-economics-of-continuous-deployment#comment48Mon, 13 Feb 2012 21:29:16 GMT@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, Ermiohttp://ayende.com/154689/the-economics-of-continuous-deployment#comment47http://ayende.com/154689/the-economics-of-continuous-deployment#comment47Mon, 13 Feb 2012 21:15:36 GMTWe 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. http://ayende.com/154689/the-economics-of-continuous-deployment#comment46http://ayende.com/154689/the-economics-of-continuous-deployment#comment46Mon, 13 Feb 2012 15:34:50 GMTI 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 :)http://ayende.com/154689/the-economics-of-continuous-deployment#comment45http://ayende.com/154689/the-economics-of-continuous-deployment#comment45Mon, 13 Feb 2012 12:56:47 GMTWe 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!http://ayende.com/154689/the-economics-of-continuous-deployment#comment44http://ayende.com/154689/the-economics-of-continuous-deployment#comment44Mon, 13 Feb 2012 10:15:23 GMTI 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.http://ayende.com/154689/the-economics-of-continuous-deployment#comment43http://ayende.com/154689/the-economics-of-continuous-deployment#comment43Mon, 13 Feb 2012 08:04:08 GMTI 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.http://ayende.com/154689/the-economics-of-continuous-deployment#comment42http://ayende.com/154689/the-economics-of-continuous-deployment#comment42Sun, 12 Feb 2012 06:59:58 GMTI 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 ithttp://ayende.com/154689/the-economics-of-continuous-deployment#comment41http://ayende.com/154689/the-economics-of-continuous-deployment#comment41Sat, 11 Feb 2012 20:35:20 GMTI'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)http://ayende.com/154689/the-economics-of-continuous-deployment#comment40http://ayende.com/154689/the-economics-of-continuous-deployment#comment40Sat, 11 Feb 2012 18:21:56 GMTI'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. http://ayende.com/154689/the-economics-of-continuous-deployment#comment39http://ayende.com/154689/the-economics-of-continuous-deployment#comment39Sat, 11 Feb 2012 18:20:35 GMTAnother 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. http://ayende.com/154689/the-economics-of-continuous-deployment#comment38http://ayende.com/154689/the-economics-of-continuous-deployment#comment38Sat, 11 Feb 2012 17:28:23 GMTI 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.http://ayende.com/154689/the-economics-of-continuous-deployment#comment37http://ayende.com/154689/the-economics-of-continuous-deployment#comment37Sat, 11 Feb 2012 17:08:20 GMTI 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 ;-)http://ayende.com/154689/the-economics-of-continuous-deployment#comment36http://ayende.com/154689/the-economics-of-continuous-deployment#comment36Sat, 11 Feb 2012 13:37:07 GMTIf 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'. http://ayende.com/154689/the-economics-of-continuous-deployment#comment35http://ayende.com/154689/the-economics-of-continuous-deployment#comment35Sat, 11 Feb 2012 12:27:08 GMTAyende, 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).http://ayende.com/154689/the-economics-of-continuous-deployment#comment34http://ayende.com/154689/the-economics-of-continuous-deployment#comment34Sat, 11 Feb 2012 11:36:11 GMTGreat 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.http://ayende.com/154689/the-economics-of-continuous-deployment#comment33http://ayende.com/154689/the-economics-of-continuous-deployment#comment33Sat, 11 Feb 2012 09:43:03 GMTExt.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: - Premium support on the forum - Access to source control. - Emergency Bug Fixes - It does not stop working after expiration - etc. 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. http://ayende.com/154689/the-economics-of-continuous-deployment#comment32http://ayende.com/154689/the-economics-of-continuous-deployment#comment32Sat, 11 Feb 2012 09:06:34 GMTAyende, 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.http://ayende.com/154689/the-economics-of-continuous-deployment#comment31http://ayende.com/154689/the-economics-of-continuous-deployment#comment31Sat, 11 Feb 2012 05:49:06 GMTI 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.http://ayende.com/154689/the-economics-of-continuous-deployment#comment30http://ayende.com/154689/the-economics-of-continuous-deployment#comment30Sat, 11 Feb 2012 01:31:25 GMTSean 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.http://ayende.com/154689/the-economics-of-continuous-deployment#comment29http://ayende.com/154689/the-economics-of-continuous-deployment#comment29Sat, 11 Feb 2012 01:12:34 GMTAnother 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.http://ayende.com/154689/the-economics-of-continuous-deployment#comment28http://ayende.com/154689/the-economics-of-continuous-deployment#comment28Sat, 11 Feb 2012 01:10:44 GMTI'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.http://ayende.com/154689/the-economics-of-continuous-deployment#comment27http://ayende.com/154689/the-economics-of-continuous-deployment#comment27Sat, 11 Feb 2012 00:27:42 GMT