Subject: Re: Free software businesses
From: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>
Date: Fri, 16 Jun 2006 22:48:53 +0900

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

    Thomas> No.  I'm charging per seat actually used.  After N seats,
    Thomas> though, the rest are gratis.  This is a side effect of
    Thomas> free software licensing.

No, it's not.  That's my point.  Payment schedules are payment
schedules; they're independent of whether the license is free or not.

    Thomas> We can avoid it by making N==1,000,000.  Or we can exploit
    Thomas> it, looking for the sweet spot, so that our bulk license
    Thomas> fee discounting is more attractive than our proprietary
    Thomas> competitor's.

Any payment schedule you can design for a free license can also be
used with a proprietary license; that's absolutely certain.  (My claim
above is that the converse is true as well.)  Thus you can only price
more attractively if you have a feature or cost advantage over your
proprietary rival.

That's where free software has to come in, but as far as I can see the
claim is that some products and some dev teams are better than others,
and free software or not doesn't have much to do with it.

    Thomas> No, we're being told to avoid it because Mr. H-W is busy
    Thomas> running his own company.  He cares about the functionality
    Thomas> of what we're offering, he cares about the reliability of
    Thomas> our firm in making the offer, he cares about quality, he
    Thomas> cares about future upgrades, and he cares about price.

    Thomas> You could go in and burble about "We develop this with the
    Thomas> help of an active community around the world using open
    Thomas> source practices!"  If his reaction isn't "So?  Why are
    Thomas> you telling me this?" it might be "Yikes... you mean your
    Thomas> development team isn't part of your budget and might just
    Thomas> spontaneously evaporate?"  Why bring it up?

If his reaction is going to be "Yikes", and you don't tell him about
what he considers a reliability problem ... suppose he finds out from
somewhere else?  That could go either way, so let's not talk about why
somebody who's never listened to Jerry Garcia might be afraid of the
Electric Kool-Aid Acid Test.

Let's talk about somebody who's walked the walk and knows the spiel
would tell us he doesn't want to hear about "many eyes", "community
loyalty", "bug fixes while you wait", "no vendor lock-in", and all
those other pretty visions that drinking the Kool-Aid gives you.

    Thomas> (Conversely, our competitor might make the the competing
    Thomas> claim "We run a CMM 4 shop to develop this!"  If his
    Thomas> reaction isn't "So? Why are you telling me this?" it might
    Thomas> be "Yikes ... you must have a lot of overhead.")

Then he doesn't understand CMM, does he?  Not to mention he doesn't
understand business---the CMM 4 shop's overhead is their problem, not
his.  Again, for the first approximation let's not *start* with spin
control.

    Thomas> "Here are the features.  Here is evidence of quality.

Er ... how do you demonstrate quality without talking about process,
at least about your testing process?


-- 
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