Subject: Re: "Reasonable Profits"
From: hecker@netscape.com (Frank Hecker)
Date: Tue, 01 Sep 1998 19:59:44 -0400

Craig Burley wrote:
> Exactly why won't developing an important app and distributing it
> under the usual shrink-wrap/CDROM work, assuming the app is GPL'ed
> (and available over the net), if the app has the usual "don't run
> if a license isn't available" kind of protection typical in lots
> of proprietary software?

Please forgive me if I ignore the technical details for the moment and
focus on what I think you want to achieve:

It appears as if you are trying to duplicate the pricing model of
proprietary software in a libre software environment; i.e., you want the
customer to pay you a certain amount per user or per copy of the
software used (we'll assume those are identical for now).  If the
customer has 100 users they pay you a certain price, if they have 1000
users they pay you tem times that price, and so on.

Then the obvious thing (at least to me) is to forget about license
checks and other technical mechanisms, and simply say to the customer:
"I will provide this software and associated support services to you in
exchange for what I believe is a fair price.  There is no right-to-use
license fee, but I provide this software to customers only if they
purchase support, and that support is priced at $X per user.  You have Y
users, and therefore your price is $X*Y."

Of course, this is not the whole story...

> Think of a major app like a Verilog simulator, which commands a
> high price, and is almost exclusively used by large-scale businesses
> willing to pay a lot for the software *and* the support.

Yes, this is the model I have been thinking of as well: software sold to
businesses willing and able to pay non-trivial amounts to have
productive use of it.

> Sure, they can edit the source code they get to remove the license
> protection, but then they'd lose the support.

You're making an unstated assumption here that you are and can be the
only possible source of support.  (David Welton makes a similar point
about ACT in an unrelated message.)  I don't believe that in a libre
software environment this is enforceable either by technical or
contractual means.

> Same if they grab
> the GPL'ed version.  Right?  Why would they take that chance to save
> .5% of their annual revenues, when the cost might be 50% of their
> revenues due to shipping late and/or buggy silicon?

Well, now you're getting to the real issue, which is how can you
convince the customer to pay what you're asking.  This is a pretty
straightforward selling problem (sketchily outlined):

1. You establish that they have a business problem that needs to be
solved, that the people making a buying decision are aware there is a
problem (seemingly obvious, but many salespeople forget this step :-),
and that you both agree on how much the problem is costing them and a
rough number as to how much they would be willing to pay to solve it.

2. You establish that you can solve this problem, that they agree that
you can solve it, and that they will commit to a yes-no buying decision
based on an offer you will present.

3. You present to them what you believe is a fair price, show them how
and why you consider it a fair price (e.g., based on the business value
of solving the problem) and how you have arrived at that price (e.g.,
based on a per-user pricing model for support and related charges).

4. They agree, and pay you.

Of course, step 4 is the problematic one :-)  Obviously even if they
want to do business with you they're still going to try to negotiate
your price down as far as possible.  If there's no software license fee
(i.e., the customer can acquire and use the software at no cost to them)
and if in the customer's mind others can provide the same thing you are
providing, i.e., support for that software, then you will be
hard-pressed to maintain an actual price (as sold) much above your
actual cost.  (And that's incremental cost at that; the customer won't
care about your having to meet fixed costs like any software development
costs you've incurred.)

But I don't believe all is lost.  I believe you can justify your price
if you can get the customer in a position where they perceive you as
providing something that others cannot.  For example:

* You are the original developer, have the most experience with the
product, and have maintained an overall expertise level and breadth and
depth of knowledge well beyond others providing support for the same
code.

* Your developers are the key developers spearheading development of the
product and are conceded to be the "owners" of the product (under Eric
Raymond's "Homesteading the Noosphere" hypothesis), and thus you have
predominant (or even exclusive) influence over product features and
direction.

* You have unique knowledge of the customer's business or application
area, and perhaps are even universally recognized as an expert in the
field, and are thus best positioned to help them make productive use of
the software in their actual business environment.

All of this is aimed at building the case that the product plus you has
more value than the product by itself or the product plus someone else,
so that you can build that extra value into the final accepted price.

If for whatever reason the customer still persists in refusing to pay
what you consider a fair price, then you can and really should simply
walk away from the deal: either they are not serious prospects (in which
case they won't end up buying anyway) or they perceive another vendor as
better able to meet their needs (in which case they will simply beat you
up on price in order to get a firm quote they can use to beat the other
vendor up on price).  It's a rare product for which there's only one
customer, and you are better off pursuing only customers who are
actually likely to buy from you.

Really none of this is that complicated or earthshaking, and it's
certainly not original to me.  This is standard selling methodology as
taught by outside sales consultants to the sales groups of commercial
software companies, and one of the things covered in such training is
how to justify and maintain your pricing as much as possible.  (I'd be
glad to supply references in case anyone is interested.)

> To get the benefits of GPL'ed software, there'd probably have to
> be some "blessed" way to use the license-less source for development
> and other purposes.

To me this seems to be a attempt to differentiate in your software
license between different types of use.  Such licensing arguably
violates at least the spirit of the provision in the Open Software
Definition about not restricting people from "making use of the program
in a specific field of endeavor".

> The worst-case scenario that is specific to GPL'ing the code seems
> to be, lo and behold, all the customers discover they can edit
> the source code for themselves and find support anywhere they want.

Yes, because then you have price competition among support suppliers, as
I've noted above.

> For the latter, being the best support source is important (which
> is true anyway); for the former, being one of the vendors of a
> product that probably triggers the movement of an entire sub-
> industry to at least recognize Open Source solutions could at
> least make the programmers you hired to do the work happy (since
> they can do the same work even after leaving your company).

This is tying back to the idea I expressed above of differentiating your
firm vs. others in terms of your relative position in the industry and
in relation to the product, even though all firms in theory have access
to the same set of code and skilled people.

Frank
-- 
Frank Hecker          Pre-sales support, Netscape government sales
hecker@netscape.com   http://people.netscape.com/hecker/