Re: 30 days trial immune to set clock back in time?



<reckoning54@xxxxxxxxx> wrote in message
news:167e211d-3d39-4389-a0d4-fd64dc1d4f8e@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Sep 21, 3:13 pm, "Chronic Philharmonic" <karl.uppi...@xxxxxxxxxxx>
wrote:
<reckonin...@xxxxxxxxx> wrote in message
news:1c4abb0e-8c37-4093-92d9-72fd631d78ad@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Sep 20, 5:56 pm, Roedy Green <see_webs...@xxxxxxxxxxxxxxxxxxxx>
wrote:
[snip]

NO FEEDBACK LOOPS!

What I write in response to Roedy is no skin off your nose.

Oh, I thought this was a discussion group. My bad.

Ridiculous. He's insisting that he should get paid over and over again
for doing a piece of work just once, unlike say a stonemason who has
to lay more bricks to make more money. Furthermore, he's attempting to
destroy other peoples' property, namely, their copies of the software
he authored.

The expiration behavior should be clearly stated in the license or
download
agreement. If you don't like the fact that my software "decays" or "rots"
or
"expires", you're free to opt out and find another vendor.

It's ridiculous. You would perform extra work to make your product
artificially less functional than it otherwise would have been? How
perverse.

Anyone who finds that morally offensive is free to offer an
alternative --
if you prefer that model, then by all means support them with your
business!

That is exactly what I do. I hardly ever pay for software these days,
only for ongoing services such as support. I mainly patronize FOSS
providers such as Mozilla.

Excellent. When my market share begins to decline, or market research
suggests a different approach, I might re-think my business model.

Sure it is. At a banquet, if you eat one of the food items, that item
is unavailable for anyone else to eat, and the operator's costs rise
rapidly in proportion to the amount of food provided. This is
emphatically not the case with software or any other form of data,
particularly not when the distribution is viral rather than from a
central repository.

So what? I can still design my software in a way that limits it's
lifetime.

Sure you can. It's just stupid to do so, and not morally wrong for
someone else to undo your nasty bit of user-hostile programming.

Attempting to defeat the terms of an agreement you evidently must have made
to obtain the software in the first place *is* morally wrong, and may be
legally actionable.

It is a "feature", no different than any other feature

Sure it is. A genuine feature provides added value to the end-user.
What you are discussing not only fails to do so, it actually REMOVES
value for the end-user. That is not a feature; it is a hole where a
feature used to be.

Feature == characteristic. It is a feature. Just one you don't happen to
like. Some users actually appreciate the reminder that they need to renew
their agreement. That is not a hypothetical, that comes from actual customer
feedback. Seriously.

Yep -- in case you somehow hadn't guessed or heard this before, the
fact that a copy of a piece of software does not intrinsically wear
out or break down from age is a feature, not a bug. So is the fact
that information can be reproduced at zero marginal cost, and without
the involvement of the originator of that information.

The software provides a service that has value. The fact that I can
duplicate it and distribute it at near-zero marginal cost has nothing to do
with my business model that reflects a return on my initial investment of
time and effort, and perhaps on-going support.

Here's a suggestion: You should avoid software that contains features you
strongly dislike.

I already do avoid software that contains intentional bugs or
deliberately lacks features.

Totally your choice. That is precisely my point. You are exercising your
right by voting with your dollars.

If my profit and market share diminishes as a result, I will be forced to
change it (it's the free market at work here).

And I'll be right there to tell you "I told you so".

No need. It is abundantly clear that the market might require me to take a
different approach. It happens all the time. I expect to respond to customer
input.

(P.S. judging by your behavior it looks like maybe you're a sockpuppet
of the thread's OP. Are you?)

Not at all. They can speak for themselves if they feel the need.

Software copies are inherently free; software development is not. It
is best not to confuse the two.

Spam is free.

Irrelevant comments in Usenet posts are also apparently free.

If there were a cost associated with it, spam would die out overnight.

There is a cost associated with spam, but it's incurred by the
recipient. The economics of spam closely resembles the economics of
air pollution, water pollution, and various other environmental no-
nos.

The economics of spam is also utterly irrelevant to the present
discussion.

The same near-zero duplication and distribution model applies here, and that
is what I was referring to.

The way to achieve that is to create an escrow account that people can
pay money into; if a target amount is reached, the money is used to
develop the software, which then becomes available to everyone. Those
who paid get it sooner than if they hadn't, and may be given extras
(such as signed gold-plated CDs or whatever). If the target looks like
it will never be reached, the money is returned to the investors with
whatever interest it had earned and the software doesn't get made.

That is *your* preferred embodiment.

That is *the* fairest way to robustly do what was described, and it's
not that dissimilar from the industry-standard way to fund R&D and
startups in, well, pretty much every other industry on earth.

I don't think you can objectively prove that it is *the* fairest way. There
is more than one way to skin a cat. I realize skinning cats is irrelevant to
this discussion too, and I retract that statement.

Choose the vendors that embrace it.

Already do, it and other business models that don't involve artificial
scarcity or infringements of my property rights.

If enough people do that, the other models will die a natural death in
the
free market.

That process has already begun. Hence my recommendation to the OP.

A century ago, I'd have been noticing Stanley steamers and very early-
model Fords putt-putting on the streets in small but growing numbers,
put two and two together, and advised people not to invest heavily in
buggy whip futures.

For exactly the same reasons as I made my recent recommendation to the
OP here.

You are at liberty to vote with your dollars every day of your life.

Of course.

Say, is it just my imagination, or are several people here laboring
under the misapprehension that I advocated something other than the OP
choosing, of his or her own volition, a different and less user-
hostile business model?

No, and in fact, I probably would not implement that kind of feature for my
own projects, but the company I work for does, and I can see their reasons.
I don't see it as a black-and-white issue.

This is precisely how a lot of R&D is done -- investors chip in and a
product is developed. Only the scheme described above is much less
risky for the investors, assuming the escrow account is managed by a
trusted party such as a respected and accredited bank.

If that is true, then people will gravitate to it naturally, and you will
eventually get what you want.

See above -- but it's not about what I want, it's about what is best
for the OP. Entering the buggy whip market while Ford is busy erecting
its second, larger assembly plant simply is not wise, and I decided to
point that out when I heard someone announcing their intentions to do
so.

Perhaps it was your phraseology that raised the hair on the back of my neck.
Rather than attacking the solution, simply pointing out that your escrow
model might be another solution to consider (along with a discussion of
possible advantages and disadvantages -- and I suspect there are some) might
have resulted in a more amicable discussion.

If not, then you will have to put up with a
model you don't like, but one that the majority of vendors and customers
prefer.

No, customers do not, as a rule, prefer their products to be less
useful than they otherwise might be, and especially prefer their
products not to have been deliberately sabotaged. Remember the
infamous exploding Pinto and other backfirings of "value engineering"
in the automotive industry, culminating in the domestic manufacturers
eventually losing enormous chunks of market share to Japanese
manufacturers?

Again, you are reading hostility into a mutual relationship. As long as both
parties enter into an agreement voluntarily, I see nothing wrong with any
approach. Nobody is being fooled, and everyone knows the terms of the
agreement. The software doesn't have to quit working without warning, or
cause any damage to user data. Now, that would be hostile, and I would not
support such an approach.



.

Relevant Pages

  • Re: 30 days trial immune to set clock back in time?
    ... When my market share begins to decline, ... I might re-think my business model. ... feature used to be. ... The smart customer, of course, goes to your main competitor to buy ...
    (comp.lang.java.programmer)
  • Re: So long Raining Data. Hello TigerLogic Corporation.
    ... MARKET under that term is where the point was being made. ... only customer base, the only community from which my company currently ... We have to take that feature all the way from ...
    (comp.databases.pick)
  • Re: 30 days trial immune to set clock back in time?
    ... to lay more bricks to make more money. ... A genuine feature provides added value to the end-user. ... change it (it's the free market at work here). ... Spam is free. ...
    (comp.lang.java.programmer)
  • Re: The Zune Is Great For Everyone!
    ... John Slade wrote: ... successful without that feature. ... market practices that include FUD. ... music on the iPod is "stolen"" would apply to the Zune too, ...
    (comp.sys.mac.advocacy)
  • Re: Spam test
    ... >> Go to online gambling sites ... > Also thanks to html web bugs, just opening all spam you receive while ... Outlook 2003 will have this feature. ... Flaws in the way Microsoft's mail program automatically renders HTML ...
    (comp.security.misc)