Début du message réexpédié :
De : Dar Scott d...@swcp.com
Date : 4 mai 2012 21:13:58 HAEC
À : How to use LiveCode use-livecode@lists.runrev.com
Objet : Rép : paying for bug fixes (was Re: [ANN] Installer Maker Plugin
1.7.8)
Répondre à : How to use LiveCode use-livecode@lists.runrev.com
Clearly the way to make customers as confident as possible in how they can
trust in their ISV !
Le 4 mai 2012 à 21:38, Tim Jones a écrit :
On May 4, 2012, at 12:13 PM, Dar Scott wrote:
What would you hope for, look for, in bug fixes when you buy a product? In
particular, if I put
3b - Alter your cost structure to cover the updating of old
versions.
Everyone pays more.
That's a good point. No matter which way you look at it the
user must pay for the maintenance and support of the software
for the developer to stay in buisiness. By limiting the free
update
Here at my place the Igors, minions and henchmen are eager for the darzLab
shingle to hang out and we put some products and freebees in the window. Many
of these will support folks developing in LiveCode. So, this is important to
me.
We here on this list are small small shops and want to
Dar-
Thanks. Good points all. Stuff to think about.
--
-Mark Wieder
mwie...@ahsoftware.net
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
What would you hope for, look for, in bug fixes when you buy a product? In
particular, if I put something into a storefront window and, in some fit of
insanity, you bought one, what would you think is a reasonable bug-fix policy
for your purchase? Or your niece bought one?
Dar
On May 4,
On May 4, 2012, at 12:13 PM, Dar Scott wrote:
What would you hope for, look for, in bug fixes when you buy a product? In
particular, if I put something into a storefront window and, in some fit of
insanity, you bought one, what would you think is a reasonable bug-fix policy
for your
On May 4, 2012, at 1:40 PM, Dar Scott wrote:
Thank you, Tim. This is very clear and attractive.
I do have a question. If Product X is on version 8.8 and a customer is using
1.0.5 (released 11 years ago, just before 2.0.0) and finds a bug, do you fix
the bug? That is, do you create
If I may chime in here, if there is a bug in a prior major revision, and no one
called to say so, and there is no maintenance contract, then I think the end
user should pay for the new major version. You may as a favor, and if you know
what the problem is, do a bug fix and release it, but that
On May 4, 2012, at 2:54 PM, Tim Jones wrote:
I do have a question. If Product X is on version 8.8 and a customer is
using 1.0.5 (released 11 years ago, just before 2.0.0) and finds a bug, do
you fix the bug? That is, do you create version 1.0.6?
That falls WAY outside of expected
Hi, Bob!
Would it meet the intent of what you are saying to essentially close the
bugs-to-be-fixed list for a major release some period of time--say a
month--after the release of the next major release? (With the caveats of may
opt to do so as you say.) Or should that period be in the 3
On May 4, 2012, at 3:02 PM, Dar Scott wrote:
Hi, Bob!
Would it meet the intent of what you are saying to essentially close the
bugs-to-be-fixed list for a major release some period of time--say a
month--after the release of the next major release? (With the caveats of
may opt to do so
It's my experience that if I purchase software within a time period of
something like a month or two before a major release, I get comped the new
version. The period of time is up to you but it's usually something like a
month or two. The reason for this is that developers like to keep their
In this case, we offer a 60 day protection amnesty period - if the user buys
a version and we ship a major upgrade within the 60 days after they purchase,
they get the new version for free.
Probably worth pointing out here that Mark's scheme offers this for 3 months.
So theres some trade
So, I'm eager to learn what those who buy products from each
other in this community expect from others in terms of bug
fixes and upgrades and paying more money.
You don't know how many times Ive mulled over this question. All I can
really say is that it depends on:
1) Does the type of
3b - Alter your cost structure to cover the updating of old versions.
Everyone pays more.
That's a good point. No matter which way you look at it the user must pay for
the maintenance and support of the software for the developer to stay in
buisiness. By limiting the free update period the
16 matches
Mail list logo