Subject: Re: Paying for development on a services model?
From: "Stephen J. Turnbull" <>
Date: Thu, 11 Oct 2001 14:00:34 +0900

>>>>> "Christian" == Christian Robottom Reis <> writes:

    Christian> I was thinking a bit more about customization,
    Christian> actually, which AFAICS isn't really versioning

Well, you're wrong.  Same base software, different customer, different
price justified not by cost of production but by customer valuation.

    Christian> I mean real development. We have a Point of Sales
    Christian> application. A customer requested multiple currencies;
    Christian> it is being developed; this code goes to the GPL
    Christian> codebase and the company has paid for it. So it's not
    Christian> simply packaging.

Nobody said "versions" had to be identical under the wrapper.  They
rarely are.  In general, the question is "Do you charge a specific,
uniform markup over cost on the customization (eg, X hours * $100/hr),
or do you negotiate according to customer's willingness to pay?"  If
the former, it's a customization service.  If the latter, it's a form
of versioning.

As you present it, it's open-and-shut versioning.  The direct client
pays for it, those who wait until the GPL codebase is released pay
much less for _the same code_.  Just packaging and timing.
Cf. Ghostscript.

The reason I'm insisting on this is that there is a wealth of
literature (start with Shapiro and Varian, _Information Rules_) on
this kind of strategy, both economic analysis and business strategy.
All of it is relevant; there is no reason to rethink the whole thing
just because you've done #define customization versioning.

_All_ code-for-money deals in free software involve versioning,
because those who receive redistributions under the GPL have a
different deal from your paying customers.  (Subject to the rather
slippery distinction between a "customer" for your software and a
"user" of your software.  You could say "non-paying users aren't
customers," but that's not very smart business.  You want to think of
them as potential customers at the very least.)

    Christian> I thought Cygnus was quite successful, but pragmatic
    Christian> about where they wanted to test FSB strategy. I don't
    Christian> think that means that they didn't believe in it, just
    Christian> that they were cautious.

Did I say I think they didn't believe it?  Cygnus did not "test" FSB
strategy, they _lived_ it.  The principals are, uh, quite comfortable,
and I do _not_ think that is an accident unrelated to being an FSB.

I implied they were smart enough to know where it is applicable, and
the point of the Code Fusion example is that they clearly saw areas
where their skills (they thought) could be applied profitably, but not
in an FSB context.

University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
	  Don't ask how you can "do" free software business;
	  ask what your business can "do for" free software.