Take Command Major Updates Poll
- Thread starter rconn
- Start date
Difficult to respond without knowing a little more detail. As a home user who is generally happy making do with whatever features exist in the version I'm running whilst checking each major release to see if there is anything in the new version that would make an upgrade worthwhile/attractive (keeping in mind that buying an upgrade costs as much as a full-price game, which represent most of my software outlay) I find the existing yearly cycle works fine for me. However, would switching to a subscription model mean that there was no longer a separate upgrade cost, just a yearly subscription or a full license, and would that full license include a period of free upgrades in the price or would one have to pay the full yearly sub in order to get any updates?? Perhaps more importantly, how would bug fixes be handled for those not on the sub??
I'm with Steve on this. I usually make do with whatever version of any given product that I last purchased, unless:
1) There are annoying bugs that I hope are fixed, which is usually not true for most products/upgrades :(
2) The upgrade price is below a particular threshold, typically $10-20
I have never purchased an annual subscription for anything, and only begrudgingly purchase upgrades. My favorite products are those with free lifetime updates, although as a software developer myself I understand the other side of that issue...
1) There are annoying bugs that I hope are fixed, which is usually not true for most products/upgrades :(
2) The upgrade price is below a particular threshold, typically $10-20
I have never purchased an annual subscription for anything, and only begrudgingly purchase upgrades. My favorite products are those with free lifetime updates, although as a software developer myself I understand the other side of that issue...
Good questions, albeit ones I haven't explored in depth yet because -- well, honestly, I didn't think that anyone would go for option #3 (the subscription model)! I was debating between #1 and #2, and tossed #3 in there to pad the poll a bit. :)
I've got a number of apps I use that use the subscription model. Most include a free update & support subscription period after a new sale, though it varies anywhere from 1 month to 1 year. After that expires, generally all updates (including bug fixes) require a subscription (which also varies between monthly and yearly). That's admittedly not ideal from a customer perspective, but trying to handle multiple forks of the code base to handle the myriad possible situations would be impossible to manage & distribute.
If your subscription expired on January 1, and I added some major new features on February 1, and discovered a bug on March 1 that affected the January 1 release, I'd then have to update the January 1 release and the February 1 release. Repeat ad infinitum ...
Or, if we say when a customer finds a bug that's fixed in the latest version, they get the bug fix update -- who defines a "bug"? Is a bug only something that crashes Take Command, or is it anything that causes a minor irritation? What if it's easily worked around by using another (inherently preferable?) approach? What if it's a feature request disguised as an imaginary bug? (We get plenty of those in this forum!)
A lot of issues that are going to require more research and more customer input, particularly given the way this poll is trending.
I've got a number of apps I use that use the subscription model. Most include a free update & support subscription period after a new sale, though it varies anywhere from 1 month to 1 year. After that expires, generally all updates (including bug fixes) require a subscription (which also varies between monthly and yearly). That's admittedly not ideal from a customer perspective, but trying to handle multiple forks of the code base to handle the myriad possible situations would be impossible to manage & distribute.
If your subscription expired on January 1, and I added some major new features on February 1, and discovered a bug on March 1 that affected the January 1 release, I'd then have to update the January 1 release and the February 1 release. Repeat ad infinitum ...
Or, if we say when a customer finds a bug that's fixed in the latest version, they get the bug fix update -- who defines a "bug"? Is a bug only something that crashes Take Command, or is it anything that causes a minor irritation? What if it's easily worked around by using another (inherently preferable?) approach? What if it's a feature request disguised as an imaginary bug? (We get plenty of those in this forum!)
A lot of issues that are going to require more research and more customer input, particularly given the way this poll is trending.
Can I change my vote? No, leave it. OK, change it. Never mind, I think I'm confused.
Here's what I want... I like the UltraEdit model. You buy the program at whatever version it is at that time and you get free updates, major or minor, for one year. After that year, you get minor version updates and bugfixes.
So for instance, if I bought TCC 13 today (March 1) and version 14 came out in October, I'd get a free upgrade. If version 15 came out next February, I'd get a free upgrade to 15. After March 1 next year, my "subscription" expires and I'd keep getting minor updates to version 15, but would have to upgrade to get version 16.
Another for instance, if I bought TCC 13 today (March 1) and there were only point upgrades (13.1.64, 13.2.98, 13.3.105, 13.4.155) until April of next year when version 14 came out, I'd have to pay to upgrade to version 14.
I guess you could consider this a combination of option 1 and option 3.
Here's what I want... I like the UltraEdit model. You buy the program at whatever version it is at that time and you get free updates, major or minor, for one year. After that year, you get minor version updates and bugfixes.
So for instance, if I bought TCC 13 today (March 1) and version 14 came out in October, I'd get a free upgrade. If version 15 came out next February, I'd get a free upgrade to 15. After March 1 next year, my "subscription" expires and I'd keep getting minor updates to version 15, but would have to upgrade to get version 16.
Another for instance, if I bought TCC 13 today (March 1) and there were only point upgrades (13.1.64, 13.2.98, 13.3.105, 13.4.155) until April of next year when version 14 came out, I'd have to pay to upgrade to version 14.
I guess you could consider this a combination of option 1 and option 3.
I think the only way to make that work would be to drastically limit the number of major version updates. I couldn't put out a 14.0, then a 14.10 next month, then a 14.20 the month after that without a dizzying array of minor version / bug fix updates for people whose subscriptions lapsed in the previous months. (14.01, 14.01.1, 14.02.1, 14.11, 14.12, 14.21, 14.22, 14.22.2, ... aaarrrrrgghhhhh!) So then we'd be back to option #1 or #2, only with a subscription tacked on.
How often does UltraEdit update? Do they have a subscription after the free update year expires? Or do you buy a new version if you want an update 14 months later?
How often does UltraEdit update? Do they have a subscription after the free update year expires? Or do you buy a new version if you want an update 14 months later?
I haven't actually bought UltraEdit (but am planning on it; I currently own both EditPadPro 7.1.1 and EmEditor 11.0.5, and neither is really blowing my skirt up), I've just read their upgrade policy and it sounds most fair for both you, the vendor, and me, the customer. You might reread my previous post as I edited it about 5 times as new things popped into my head.
Basically the UltraEdit model is you get all upgrades/updates for 1 year then you are stuck at whatever major version number when your year is up but still get minor updates. So if my current TCC 13 year expired today, I'd still get 13.1 free tomorrow, but would have to pay for version 14 next week.
Basically the UltraEdit model is you get all upgrades/updates for 1 year then you are stuck at whatever major version number when your year is up but still get minor updates. So if my current TCC 13 year expired today, I'd still get 13.1 free tomorrow, but would have to pay for version 14 next week.
I feel this is a tough space because of the maturity of the command line space and the lack of experienced users to appreciate it these days.
I don't like the subscription model for software, only for 'library' type content. My preference is for upgrades whenever there is 1 killer feature that makes me go 'Yes! That's going to make me more productive!'. Again, from the maturity of the command lines, I'm not sure how to accomplish that these days.
/If/ it's generally agreed such killer features are few and far between these days (and I'm not making that claim as generally true)... I think it would actually make sense to go the other direction and provide updates as frequently as possible (no more often than 3 months) for lower costs (like 9.99 upgrades) and cap the accumulated upgrade cost at something like $29.99.
Knowing nothing about the business model, I can only explain my thinking from the consumer side; which is:
- At $40+ I need to see a feature that's going 'make a difference' before I upgrade. In fact I've missed several cycles in the past from this. :(
- At $10 to $20, I only need to be able to say to myself 'yeah, this is better' and perhaps even 'OK, I don't really need these features, but this is a small price to pay for supporting this software niche'. And I'll buy it. Yeah, I may pay out the same $40 or more as a year goes by - especially if I do see incremental value features... But that's how my mind works.
I don't like the subscription model for software, only for 'library' type content. My preference is for upgrades whenever there is 1 killer feature that makes me go 'Yes! That's going to make me more productive!'. Again, from the maturity of the command lines, I'm not sure how to accomplish that these days.
/If/ it's generally agreed such killer features are few and far between these days (and I'm not making that claim as generally true)... I think it would actually make sense to go the other direction and provide updates as frequently as possible (no more often than 3 months) for lower costs (like 9.99 upgrades) and cap the accumulated upgrade cost at something like $29.99.
Knowing nothing about the business model, I can only explain my thinking from the consumer side; which is:
- At $40+ I need to see a feature that's going 'make a difference' before I upgrade. In fact I've missed several cycles in the past from this. :(
- At $10 to $20, I only need to be able to say to myself 'yeah, this is better' and perhaps even 'OK, I don't really need these features, but this is a small price to pay for supporting this software niche'. And I'll buy it. Yeah, I may pay out the same $40 or more as a year goes by - especially if I do see incremental value features... But that's how my mind works.
I think there are still a lot of surprises to be seen with the command line. I think v13 had two new killer features, and I have another one already in the works for v14. I think the harder part is changing the mindset of the users to convince them to actually try something new. I still get the occasional complaint about TCC not supporting full-screen 80x25 consoles any more (though this is actually a Windows change, not TCC)!
The upgrade cost issue is misleading -- if Take Command were a home product, then $49.95 a year for upgrades would be a lot. But the truth is that 80 - 90% of our sales are to businesses, which are not sensitive to pricing at that level. (I've had some customers complain in the past that they couldn't get their companies to buy Take Command because it didn't cost enough - their IT departments literally couldn't buy anything that only cost $99.95. They had to buy it themselves and then hope their company would reimburse them.)
The relatively few home users of Take Command tend to only upgrade once every 3-4 versions, so the net yearly cost is ~$15. (Or they try to wangle their way onto the beta team, so they'll get it free! :) )
The upgrade cost issue is misleading -- if Take Command were a home product, then $49.95 a year for upgrades would be a lot. But the truth is that 80 - 90% of our sales are to businesses, which are not sensitive to pricing at that level. (I've had some customers complain in the past that they couldn't get their companies to buy Take Command because it didn't cost enough - their IT departments literally couldn't buy anything that only cost $99.95. They had to buy it themselves and then hope their company would reimburse them.)
The relatively few home users of Take Command tend to only upgrade once every 3-4 versions, so the net yearly cost is ~$15. (Or they try to wangle their way onto the beta team, so they'll get it free! :) )
D
I have used ultraedit since version 6 or 7. Back then I was able to buy a lifetime upgrade option for a relatively small charge. So I keep my copy current since I already bought it and it's now free for me. But it does not have any new features that I actually use on a regular basis.
But I find myself using gvim more and more. And that's free too, but for a different reason :-)
It's always free for anyone who wants it.
But I find myself using gvim more and more. And that's free too, but for a different reason :-)
It's always free for anyone who wants it.
I would never tell someone they could no longer use software they had paid for. The tricky part is figuring out how to handle bug fix updates for old versions. Most of the subscriptions I have simply say "use the old version you have as long as you want, but you'll never get any new minor updates or bug fixes unless you subscribe." It's not ideal, but it may be the only workable solution.
I've never understood why companies put bug fixes in the same category as new features. If I buy something, I think it should work as intended. I can understand that it is difficult to patch old versions, so it is understandable that I might have to update to a new version to get an old bug fixed. But, any bug fixes to an existing version should be free.
Now, if you start releasing new versions continuously, you've got a problem with this model.
Non-software products generally come with a warranty for a fixed amount of time (years). You could do the same with software: For X years, you'll fix bugs in a version. After that, the customer has to upgrade to a newer version to get bug fixes.
Selling a product like software as is (no bug fixes) is deceptive. Any sane person will be forced to buy the subscription. Or, maybe wait until they find a bug, then pay for the subscription. (TCMD and TCC have few bugs, so a sane person might take a chance.)
There is one product I own (Dew Research's MtxVec) that has a subscription model for upgrades. But, if you let your subscription lapse for too long, you have to pay for the previous year and the coming year to renew it.
Now, if you start releasing new versions continuously, you've got a problem with this model.
Non-software products generally come with a warranty for a fixed amount of time (years). You could do the same with software: For X years, you'll fix bugs in a version. After that, the customer has to upgrade to a newer version to get bug fixes.
Selling a product like software as is (no bug fixes) is deceptive. Any sane person will be forced to buy the subscription. Or, maybe wait until they find a bug, then pay for the subscription. (TCMD and TCC have few bugs, so a sane person might take a chance.)
There is one product I own (Dew Research's MtxVec) that has a subscription model for upgrades. But, if you let your subscription lapse for too long, you have to pay for the previous year and the coming year to renew it.
I just reported a bug in a function (introduced in the first version of TCC, V9) that exists in all TCC versions. Undoubtedly Rex will fix it within days for the current release (V13).
Undoubtedly the same code is used in all versions, hence the corrected source code (and object module) will be available to rebuild older versions. But what is it worth to update the installers for V9, V10, V11 and V12? If I were in Rex' place, due to the obscurity of the bug, I'd probably fix only the current and - maybe - the penultimate versions. For those still using V11 or older, I'd tell: upgrade!
Undoubtedly the same code is used in all versions, hence the corrected source code (and object module) will be available to rebuild older versions. But what is it worth to update the installers for V9, V10, V11 and V12? If I were in Rex' place, due to the obscurity of the bug, I'd probably fix only the current and - maybe - the penultimate versions. For those still using V11 or older, I'd tell: upgrade!
I'm quite happy to pay $50 a year to keep abreast of major upgrades. Whatever upgrade model JP Soft ends up using, it looks like that won't change much. I'm hardly on top of every tweak and feature an upgrade introduces so I don't feel a burning need to be always on the cutting edge. I'm happy with the status quo. I'm not being overcharged, I'm getting a good product that is constantly being updated, Rex is responsive to customer feedback, he appears to be able to stay in business and support a couple of staff and a dog, so the current model looks like it's working well for all parties.