VCL product subscriptions: listening to feedback

We’ve had a lot of extremely valuable feedback from my previous post about our plans for our VCL product line, both as comments to the post itself and as emails to me. I want to thank everyone who did respond: we’ve looked at and discussed all of them. And by “we”, I mean both the management of DevExpress and the VCL team, since we are all here together this week in our development offices in Russia.

Why subscriptions again?

Firstly, we feel that we didn’t communicate effectively (and by “we” here, I mean me, obviously) what our reasons were for moving to a subscription model. Let me take an aside here to explain.

As part of a license to a DevExpress product you get the right to create as many applications with that product as you want for as long as you want. Furthermore we will provide support services as part of that product for as long as you use it. We’ve delivered on that promise again and again.

However, what we have found over the past few years is that a greater and greater amount of support is being spent on version incompatibilities. We’ve tried hard in the past to provide support to people who want to use product X from a couple of versions back with the latest version of product Y, given that both X and Y use some of the same underlying codebase (simple example: using an old treelist with the latest grid, given they both use the same editors). Since this support invariably requires input from the development team, the upshot is that, overall, we are spending too many resources on issues that affect only a small proportion of our customers; resources that, frankly, we should be putting towards creating new features and new functionality. The same goes of course for the original development of new features: explicitly allowing interactions between just two different versions of our controls at the outset exponentially increases the amount of testing we have to do for a release.

If we had a system whereby customers were guaranteed to get the latest versions – were encouraged to keep up to date, if you like – we could spend more time in producing compelling updates on a regular twice yearly cycle, and less time on such cross-version issues. If we had a system whereby customers could get new minor features quickly and regularly, the less time they would have to wait for a major version update before being able to update their apps. The current system does not facilitate these goals at all, hence the idea of moving to a subscription model. Naturally a subscription model not only helps our customers budget their annual expenditures on controls, but also allows us to budget what we allocate on producing and supporting VCL products.

What should subscriptions apply to?

And so to my next point: one of the biggest complaints raised by people is that the proposed subscription packs were too coarse-grained and that the packs didn’t address their particular needs. (OK, we did briefly discuss adding a couple of new packs to try and alleviate the problem, but, to be honest, we abandoned that line of discussion pretty quickly.)

Hence, we are proposing to make the individual products subscription-based as well.

If you are buying our VCL controls new, you have the choice of purchasing a subscription pack if you require a spread of controls, or of buying the individual products you need on a subscription basis. Prices for new product purchases are the same as now, annual maintenance renewals will be 40% of original price.

If you already have licenses to some of our products, you can promote them individually to the subscription-based v2011.1 version. The price would be (essentially) 40% of the list price if your version is the current latest version; 70% if you’re one version back; 85% for two versions back; or full price any older than that. Of course, if you find that a subscription pack is more to your liking, you can promote to the same ones I discussed (and at the same prices I provided) last time. All subscriptions are renewed on an annual basis.

I will re-emphasize my first point again here, though in a different way: v2011.1 (and later) will not be “cross-version-compatible”. If you decide to promote at least one of your VCL products to v2011.1, you will have to promote them all if you want to use them in the same IDE and for the same applications. We cannot provide support for using a v2011.1 control with an earlier version of another control. The new installer will continue to remove earlier versions of controls for compatibility reasons.

Oh and by the way…

Finally, we found that we don’t really know what kinds of development you, our VCL customers, are doing. Apart from some raw sales numbers, we don’t have much relevant data. For example, we don’t know

• whether you are maintaining legacy systems or writing new ones or thinking of moving to new platforms;
• whether you are old-time Delphi devs or new customers using Delphi for the first time;
• whether you are writing in-house programs or retail applications;
• what you are planning on doing with Embarcadero’s promised new features, if anything.

Hence we will be contacting all of you individually over the next month or so to survey your environments, usage patterns, future plans, and so on. The hope here is that by knowing more about our market, the better we’ll be at satisfying that market’s future needs.

Summary

In short: products are purchased by annual subscription, upgrade options for existing product owners, same subscription packs, no cross-version code from v2011.1 onwards, surveys to come.

Apart from all that, we are altering our sales system’s business rules to support this new proposal. Once that is done and the website updated, we will release.

Free DevExpress Products - Get Your Copy Today