🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.next.software
Article #411

Re: Solid Value, Rulers, and Copy Protection (long)

#411
From: Stefan Heck
Date: Tue, 11 Aug 1992 17:34
95 lines
5795 bytes
In article <dillon.0l5x@overload.Berkeley.CA.US> dillon@overload.Berkeley.CA.US (Matthew Dillon) writes:
>
>    This brings up an excellent point... Instead of putting time limits on
>    Demos do something like the above, limit the size of the objects being
>    manipulated and give them relatively generous values instead with all
>    other capabilities enabled.  A 32x32 worksheet is fine for many
>    purposes but not, say, for the accounting department of a business.
>    Ergo, no sales are lost to anyone who would use the product in a
>    meaningful way.  People who do not use the product for anything greater
>    then 32x32 would probably not be able to justify the cost of buying the
>    product anyway, ergo no sales are lost to them either.
>
>    You get several advantages:
>
>    (1) A usable program distributed publically equates to free publicity
>
>    (2) many people can actually use said distributed product for real
>	work, thus increasing the number of positive postings on the net,
>	reviews (more free publicity), and who knows, when they graduate to
>	larger projects they might just decide to *buy* it since they are
>	so used to it.
>
>    (3) Fewer idiot-level technical support calls.  People who use the demo
>	version DO NOT EXPECT TECHNICAL SUPPORT FOR SOMETHING FREE.  They
>	will learn the product on their own time and when it comes time to
>	buy it they will already have a nontrivial amount of
>	experience, hence fewer technical support calls.
>
>					    -Matt
>

Right on! I think this a great idea, both for consumers and for
software companies. Obviously for consumers the equation is right. I
use spreadsheets only to balance my checkbook and drawing programs
only for illustrations for papers (in public clusters on campus).
Right now I both cannot afford the software and I certainly would not
want to pay several hundred dollars to balance my checkbook. I have
however invested time in those programs and if I were to start a large
project or business, I certainly would opt for that program and I
would be willing to pay full price. Until then I need no support,
since I am just playing and if something doesn't work, I either figure
it out or do something else. 

For the corporate side, I think what the key is a change of
perspective: Most customers I've met (those outside the business
community) don't want much support. So perhaps sell a weakened version
of the software without support. Consider it an educational discount.
So you get free advertising, free user testing, and plenty of happy
customers. If distributing publicly is a problem for security or
copyright issues (no doubt there are some unexplored catches here)
then perhaps sell the product REALLY cheap (say barely above
production cost of the copies, without programming costs) in the
"educational version." I bet that this would actually increase sales
rather than lower them, because you'd be making inroads into markets
that don't buy your program normally. Plus think of the long term
effect: If your software is expensive and people pirate it, how big
are the chances they will later go and buy it when they will never get
any added functionality. If people already have a cheap reduced
functionality copy, I would think they would be must more likely to go
out and buy the full copy later when they need more functionality and
most likely also have more money. In some ways this would constitute
an experiement which claim is right: Whether high prices cause
pirating or pirating causes high prices. The key is that most people
(nowadays) get familiar with software when they are in school and have
little purchasing power, while they typically only need to do large
projects later in life. Some examples:

For a word processor, limit the document size length to something like
20 pages. If people want to commit their book or thesis to it, they
probably feel a great enough need to actually buy the full version. Or
if businesses churn out thousands of short letters each day, disable
mail merge or place a per week limit on the number of files created.

For a drawing program, simply limit the number of objects that can be
part of a picture to something like 50.

For fax software, limit the number of faxes per week to five, say. I
know of no one who does not have the money to buy the full version who
sends more faxes than that. Per week simply because there are DAYS
when I send more than one fax.


In any case, I think the real busines case for software vendors is
that you would be giving people a half-way option between not using
your software at all (or pirating it) and buying the full thing. My
business case would be that this would not take away your existing
market, but rather only extending your reach into new markets. Of
course I have no data back this up other than what I see friends
doing, but a simple survey should provide a better context (e.g. would
you buy x spreadsheet for x dollars if it could only support x rows
and columns). This would actually make nice microeconomics problems,
determining the optimum return rate for the company in terms of return
rate per price and functionality.

Stefan Heck
Technical Details
Message-ID: <1992Aug11.173448.3040@leland.Stanford.EDU>
Path: arc1-ca.pugleaf.net!sparky!uunet!stanford.edu!leland.Stanford.EDU!valardin
References: <1992Aug8.190043.321@digifix!uunet.ca> <1992Aug9.181408.1652@dpp> <dillon.0l5x@overload.Berkeley.CA.US>

Show Full Headers
Complete Article Headers
Newsgroups: comp.sys.next.software
Path: arc1-ca.pugleaf.net!sparky!uunet!stanford.edu!leland.Stanford.EDU!valardin
From: valardin@leland.Stanford.EDU (Stefan Heck)
Subject: Re:  Solid Value, Rulers, and Copy Protection (long)
Message-ID: <1992Aug11.173448.3040@leland.Stanford.EDU>
Sender: news@leland.Stanford.EDU (Mr News)
Organization: DSG, Stanford University, CA 94305, USA
References: <1992Aug8.190043.321@digifix!uunet.ca> <1992Aug9.181408.1652@dpp> <dillon.0l5x@overload.Berkeley.CA.US>
Date: Tue, 11 Aug 92 17:34:48 GMT
Lines: 96