Subject: Re: a business model
From: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>
Date: Fri, 24 Mar 2006 01:01:56 +0900

>>>>> "Thomas" == Thomas Lord <lord@emf.net> writes:

    >> However, you make some obvious elementary errors (eg, the
    >> comment about "sometimes optimal and sometime not" regarding
    >> the mutual defection outcome in the prisoners' dilemma, unless
    >> you mean K = 0).

    Thomas> In the dilemma matrix, it is ambiguous whether the upper
    Thomas> left or lower right corner is the mutual defection corner.

Well, no.  The upper left can never be an equilibrium; both A and B
(individually) wish to defect (unless K is negative, but that seems
unreasonable).  I'm not sure how you intend to specify the rest of the
game.  (Is the value of the software to A and to B equal?  If not, how
to you arrange to enforce equality of payment?  If payment share is
being decided as a range from 0 to K, analysis becomes quite a bit
harder because of the possibility that the amount the two combined
decide to pay is < K, even if their values are symmetric.  And so on.)
One reasonably simple change is if both A and B are willing to pay
more than K, it becomes a battle of the sexes---and not a prisoners'
dilemma at all---with two equilibria in the lower left and upper right
corners (and a third, pessimal, "mixed strategy" equilibrium).

    Thomas> It depends on externalities and the nature of the
    Thomas> particular software in question.  It *is* one of those two
    Thomas> corners in each specific case and, either way, the
    Thomas> software producer gets screwed if her intention is to make
    Thomas> a profit (which is the point of the analysis).

Seems unlikely, since there are no copies available at all yet.  The
vendor is a monopolist.  AKA the "ransom license" or the
"sourceXchange model" or even (where there's a single customer for
each innovation with value > K plus network externalities to capture)
the "Cygnus solution".

In fact, in the small numbers model you're describing, it is a serious
error to assume the customers can effectively combine against the
innovator in the current legal climate.  The innovator has
intellectual property law in his favor, the customers face potential
antitrust action if they conspire to bargain as a union.  It's not
impossible that they will succeed, but to assume that they will is an
heroic assumption.  I would not buy stock in that assumption.

    >> I believe you're also making more subtle errors.  Specifically,
    >> making assumptions about (near) absence of friction where that
    >> favors your thesis, and retaining friction where it doesn't.
    >> Specifically, I think you dramatically undervalue both the role
    >> of "insurance" in contracts like Red Hat's support contract,
    >> and the cost of management (especially of the "writing reports
    >> at the desk" form).

    Thomas> If you give me a little more to go on there I can reply.
    Thomas> I have a hunch what you mean but I'm not quite sure enough
    Thomas> to risk making noise.

As was pointed out by Mark Flacy when you floated the "GPL violation"
theory on gnu-arch-users, the rhel_us_3.html model is for people who
cannot afford to spend their brains on dealing with support issues
that are routine for somebody.  They'd rather pay, and pay well, to
know that the best available[1] help is on call, freeing up their smart
people to do whatever it is they do best.

You mention "value-based pricing."  Well, that is exactly what this
is,[2] to the extent that it can be measured.  You've suggested elsewhere
that those who want insurance can pay a retainer for the right to
improved quality of service.  Problem is, how big a retainer should
they offer?  Red Hat can't tell them, Red Hat knows nothing about
their business.  They can't guess, they don't want to know about Red
Hat's.  That's why they're talking to Red Hat!  So, what can we tell
somebody so they can make an estimate of risk and costs?  Telling Red
Hat the CPU count is a very plausible statistic.  If you can suggest a
better one, please do so.  But the "CPU count" model will surely eat
the "anybody's-guess retainer" model's lunch.

There's another problem with the retainer model.  If Red Hat enforces
it, it's indistinguishable from extortion.  "You guys are hurting but
you've used up your quota; pay more!"  The "CPU count" model does not
have that problem; it's Red Hat (or their reputation, at least) that
bears the risk of "excess" support calls.  I'm not sure I like the
implications of the retainer model for quality of the underlying
product, either, but I haven't looked at it closely.

Regarding cost of management, anybody who can say "all good
programmers are, in a real sense, good managers" surely has no clue
about what managers do.  "Management" here does not mean
"economizing", as in "personal time management" or The Personal
Software Process [SM].  Management means workers whose role is
facilitating communication to coordinate production.  (It often also
has power structure connotations both for pragmatic reasons and
because the pivotal position of management can be abused to
concentrate power, but that's not part of the definition.)  Good
programmers are often very bad at communication per se, and even worse
at facilitating it.  Such programmers would much rather solve the
problem themselves because they can do it faster and better.  A
manager realizes that that is "no way to run a railroad."

The problem here is arranging that the "free software innovator"
*listen* to the paying customers.  You point out how Canonical's entry
dried up your GNU Arch market; well, if your public utterances are any
sample, you made it plain to them that their perceived needs were the
*wrong goals* for you to devote effort to.  Just as the reigning cabal
has done in any number of successful forks.  In such cases, a large
share (I'm not saying a majority) of users voted with their feet.
Seems like those *wrong goals* were actually *right goals* (or at the
very least "good-enough-for-government-work goals") from the point of
view of a reasonably important market segment, and in cases like
bazaar, XEmacs, and egcs, coherent enough to attract financial
backing.

The real point here (and that of the famous "herding cats" metaphor)
is that the manager is the interface between the client and the
programmer.  She needs to have a foot in both camps, because they're
likely to be speaking different languages (even if both client and
programmer are software professionals!!)  It's possible that you were
quite right, there were better ways to accomplish the user goals that
the forking developers proposed---but it's clear that you failed to
communicate that to those developers and the users they proposed to
support.  That's what management (and marketing) are for.  They can't
be eliminated in favor of an account with Merrill Lynch.




Footnotes: 
[1]  You're "better" of course---but AFAICS you're not available "on
call" to do what you're told.

[2]  And your definition of "guaranteed marginal utility above cost"
is not the one used in economics, and I doubt it's the one used in
industry.  "Value-based pricing" simply means charging more to those
who are willing to pay more.

-- 
Graduate School of Systems and Information Engineering   University of Tsukuba
http://turnbull.sk.tsukuba.ac.jp/        Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
        Economics of Information Communication and Computation Systems
          Experimental Economics, Microeconomic Theory, Game Theory