[
Lists Home |
Date Index |
Thread Index
]
In my part of the world, we don't give a flying fig what a framework vendor
thinks
of our social strata. We're not mocha latte business partners; we manage
risks
on behalf of our customers:
1. Tool costs. Short lifecycle cost risks. That is the risk you describe
and it
is exactly as you say. Because the risk to the developer is short, it is
reasonably
manageable.
2. Content costs. Long lifecycle cost risks. That is the CALS vertical
stack
problem of non-standard formats for long lifecycle data. This is harder
to manage without scaled cooperation and the risk accrues to our customer.
We insist our tool framework vendor help us manage this risk on behalf of
our customers.
That is what XML attempts to solve but the solution
is incomplete given the contextual issues of semantics.
That is the problem open source attempts to solve
by providing a free implementation. What works
better is a well-specified object model. The cost risk
here is the process for creating that. We expect a
tool framework vendor to manage that risk on behalf
of their customers.
The solution in today's environment varies by content type.
The risks for HTML are minimal. For SVG, XSLT, etc. they are
higher. Because of co-dependencies in the pipeline, one
picks a framework to get interoperating object models. So,
it is for any given pipeline, a mixed set of risks and one
attempts to get the right mix (ie, acceptable reliability numbers).
The tool vendor must provide us reliable tools to manage these
costs at a cost that we can, as you say, amortize out reasonably
quickly. That means he has to sell in volume and we have to
sell in the correct tier with the correct mix of content. There
is nothing uppity about that position. Strictly business.
The Hardees CEO got it right: I will pay a little more
and wait a little longer for a demonstrably better burger.
Surprise: it really is one. Try the Combo #3.
<aside>If you use the term 'uppity' where I live, you will
get a civil suit filed against you. Welcome to regional
cultural risks.</aside>
len
From: David Megginson [mailto:david@megginson.com]
AndrewWatt2000@aol.com writes:
> It seems to me that Tim misses an important point that Microsoft,
> and other proprietary vendors **need** what Tim refers to as
> sharecroppers.
They need sharecroppers in general, but they don't need any
sharecropper in particular, especially not the uppity ones who get too
much attention.
I do think that Tim overstated the case, but not in an obvious way. I
wouldn't object to building a software product specifically for a
closed-source platform, but I would do so only if I could reasonably
hope to amortize the development costs over, say, 18 months or less of
sales. Past that point, the risks that Tim describes become more and
more significant.
|
