Article View: comp.sys.next.software
Article #411Re: Solid Value, Rulers, and Copy Protection (long)
From: Stefan Heck
Date: Tue, 11 Aug 1992 17:34
Date: Tue, 11 Aug 1992 17:34
95 lines
5795 bytes
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!valardinReferences:
<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