Kent Clark wrote in post #15908158
...I don't like that a reasonable option, buying one edition of the software and keeping it for as long as I want to, is now no longer available.... I don't buy Adobe's claim that this move makes them more efficient and makes it easier for their programmers.
1. Reasonable for whom exactly?
2. Are you in software development? Have you worked on a major software project in the past?
Ditching future developments of the non-cloud version either eliminates a production branch of code, or greatly simplifies a security feature set. They don't have to test against authentication of Subscription vs authentication of lifetime license on maybe eight versions of Windows (Remember, not good enough to just test software against windows 7, you have service packs and the like!), and a pile of OS X versions. (I'm on a project at work that is on OSX, and I should know how many versions are being tested against, but I can't for the life of me remember how many.)
Oh, and don't forget you need to do localization passes against all those as well, so multiple that by the number of supported languages. Also don't forget to add in your hardware variations to your test matrix!
Dropping one of the two models is going to save them at least $10,000 in direct QA labour based on other projects of this size. And that is Per Build that receives a full test pass. Each patch or upgrade you see as an end user is going to represent many builds. Odds are with software like that you are getting at minimum of 5 builds getting a test pass.
Long story short: Dropping dual purchase methods is going to save them a pile of money. They are a business, they are in business to make money and turn a profit, they are NOT in business to ensure you can edit photos.
As for making it easier on programmers in general: With a subscription model like this, the development cycle is no longer "Version Bound" on features. That is, if I am a programmer and I have a good idea that the team supports, then my new feature doesn't have to be budgeted closely and worked into the project as a whole where it is allotted a tight money and time frame budget. I can be sent off into my corner to program away, and when my feature is done, it is done. That feature doesn't have to wait till the next major in six months time to be included, and my feature can't delay the release of other features. My feature merely gets rolled out in the next content update at the end of the week along with the general bug fixes.
Working under a subscription based model is far nicer, and with a lot less stress.
Under the old system of large monolithic releases with "big version jumps" (ie, CS6 to CS7) the programmer is always under the risk of some delay in the features they are responsible for. Bugs happen, designs fail, things go wrong. If a programmer knows the product is shipping as a whole at the end of a milestone, then they are under a huge amount of pressure when they find some bug or issue a week from release. Crunch time sucks. You don't see your family, you barely get to leave the office, you have managers breathing down your neck constantly asking you what is going wrong, why isn't it working, is it done yet, why wasn't this caught sooner, what kind of idiot are you to have missed this, etc.
Under the new system, it is far more practical to release smaller updates far more often. Programming a new Red Eye reduction system? Is it ready to get to final QA and be included in this week's release on Thursday morning? No? Oh,... well, next release cycle is in a week or two, which is more than enough time to finish it. Since you won't make it this week, and will dig into the next cycle, may as well take the afternoon off, go clear your head, and spend a bit more time looking for issues.
Way more relaxing, and vastly more productive.
Canon EOS 7D | EF 28 f/1.8 | EF 85 f/1.8 | EF 70-200 f/4L | EF-S 17-55 | Sigma 150-500
Flickr: Real-Luckless