This is a seemingly simple question with a long, political, and policy-setting answer, which stands before all 3rd party control vendors. It has no simple
correct answer, but here is a stab of why our policy is what it is, and why it is so:
It has always been Telerik's policy to offer the most stable and updated versions to our customers. We do this by working on the most recent codebase and constantly improving it. In our view, this is the best way to keep our costs down, be able to keep the prices low and competitive, and deliver new features to you at the same time. We are very aggressive in our release schedule, and although one can argue that this has some negative sides in the WinForms world, the vast majority of our customers are very happy with this fact, because they are getting needed fixes more often.
Let's dive deeper into this:
1) If you are to work with a 2-year old version of our tools (say Q2 2009) and we provide you with a "fixed Q2 2009", you will be more or less stuck with a custom
implementation which solves your single problem. This means that you will miss all future improvements, which we have released, because a) you will be happy with your current version, and b) it works, so why bother upgrading. This is an important factor to consider, not only because you will miss a big chunk of the value that our licensing offers (i.e. new products and updates + support services), but also because the upgrade process from Q2 2009 to today's version will be much harder due to the introduction of new features, new products, and/or improved new API. This situation begs for a few questions, all of which translate to jacking our prices up:
- What happens if a new issue pops up while you are extending your legacy application? What if the need for this fix is discovered 3 years from today, i.e. in 2014?
- How much extra are you willing to pay to a vendor to provide a fix for such legacy applications?
- What is the oldest version that you think Telerik should support?
2) For us, supporting an old version means providing support for another codebase (in this case Q2 2009). If we are to prepare a new custom build with the same fix for another
customer with another
version (say Q3 2008), we will be repeating the same job time and time again which will lead to much higher non-competitive prices.
There is also another factor to the equation - the time we need to prepare the fix. As with all fixes, we will need fix the problem in Q2 2009, test the build, package it and give it to you. Fixing aside (covered above), testing and packaging only takes about a week of time; time, which again costs money (see questions #2 and #3 above).
This is why we have decided to support only the last 4 releases (which cover a time span of one year) and keep our pricing low. For older versions we offer the free service of upgrading our client's applications to the latest current version. This helps us keep legacy apps to a minimum and have our costs under control.
Indeed, this policy puts more burden on you - the developer - because you will need to update the application more often [than you like] and distribute it to your users. There are automation tools which do this for you, so the cost of distribution today is much lower than it used to be. The plus side of our policy however, is that you are paying lower prices, but you are always getting the best value for your dollar, because you always have the latest and greatest we produce. Basically, we think this is a win-win situation. This is why we have our policy set the way it is.
the Telerik team
Do you want to have your say when we set our development plans?
Do you want to know when a feature you care about is added or when a bug fixed?
Telerik Public Issue Tracking
system and vote to affect the priority of the items