Back from Idaho yesterday. Threw out a lot of junk email
today. So it goes.

The more I find out about the home networking and automation
opportunity, the more overwhelmed I feel. Dug up stats
saying that the current build rate for single family new
houses is 1.5M/year, with a median price of $197K. OK, that
works out to $295B/year. (Actually, the $197K is only for
spec homes, about 2/3 of the total, the other 1/3 being
custom-built; I'm guessing the latter are more expensive.)
If you could put a decent $5K system into 10% of the new
house market, and a bare-bones backbone $2.5K system into
another 10%, you're talking $1125M/year. We're talking about
a low margin service business here, but it's still a nice
opportunity. (And the World Domination advocates should
appreciate the strategic value of having free software as
the backbone of every modern house.)

The big problem I see is not the product -- aside from some
software gaps and cost issues that volume could fix, almost
everything is ready now, off the shelf -- but getting the
service and market messages together before the waters gets
too polluted with all the other companies who can smell this
market. (Fortunately, most of these companies are assuming
Microsoft software, so don't expect much from computers.)

Leaves me wondering how does one find compatible
entrepreneurs out there wherever?

Packing tonight, setting out for a long car trip tomorrow,
across the mountains and out to Idaho. I guess it's the
vacation I never got around to taking this year. Hopefully
when I get back I'll know more about how the home
automation business thing shapes up.

Finished reading Donald Rosenberg's Open Source:
The Unauthorized White Papers. It's a useful book,
basically a compendium of open source-related business
activity. Not much earthshaking news, but it seems to
be comprehensive enough. One bone is that while he
has a lot to say about businesses making money off of
open source, he doesn't have much to say about users
saving money (and otherwise leading happier lives) by
using open source software. He also misses the whole
freedom issue, which should be important even to
someone with a fairly narrow business focus because
freedom is the engine that drives economic progress.

Deep breath. Had a fairly long entry underway when X bit
the dust. This doesn't do much for my faith in the legendary
robustness of Linux systems.

Thrashing a lot today, as various things popped into view.
I saw a notice that on
contex.com that the
color prepress products that I had worked eight years on
have been discontinued, that support contracts will not be
renewed, and that the only support contact going forward
will be an ex-employee with no access to the source code.

I find myself with very strong feelings about this, partly
I'm sure because it was a critical and formative period in
my life which left me with very strong emotional ties to
the product, my colleagues, and our customers, but largely
because I always identified with those customers -- who
today are being told by Barco (a competitor who bought
Contex two years ago) to abandon their SGI-based CEPS
systems in favor of Barco's NT-based ones.

The lessons here are the obvious ones: that engineers who
write software property lose it to the whims of the property
owners; and that customers who rent that property in fact
own nothing and have no rights. This is, of course,
something
I learned painfully over many years of doing just that, both
as engineer and as customer.

Other items that popped up:

I read with interest raph's proposal
to use the trust metric to help consumers sift through a
vast distributed archive of MP3 music. One issue here is
that music taste varies wildly; consequently one's view of
who to trust is equally personal, and that is ultimately the
only criteria that matters. I'm unusual in that I make
almost all of my music buying decisions based on printed
reviews. I've done this for a long time, and I buy a lot, so
I've accumulated a lot of data which guides me in whose
recommendations I do or do not trust, and one thing that
I've learned is that no one reviewer is equally good in all
fields. Still, my experience is with named writers,
necessarily
a small set; I wonder whether larger reviewer sets might
start
to become more reliable?

Got mail today saying that sourceforge will be using the
trust metric to allow everyone to rate anyone. This strikes
me as a pointless game -- although I'm sure that anyone
who gets identified will be quite deserving. I suspect that
one problem is that what the metric may turn out to
measure is the topography of the developer community --
basically how closely groups of people work together,
because the larger the population the less we really know
about each other. The same dynamic may be present at
Advogato, but the relative crudeness of the rating scale
should make it less pronounced.

I understand that Sun has some scheme that allows one
to compile Linux drivers and load them into Solaris. Fwiw,
I urged SCO to do this same thing. My proposal was rejected,
because the powers-that-be felt that allowing Linux drivers
to be used in UnixWare would diminish the message that
UDI is really the way to go.

The basketball goal took priority over the resume, but I
finally cleaned up the resume and posted it
here. I meant to hang hypernotes all over it, but was
finding I could write forever on them, and it just gets more
and more scathing and/or pathetic. Some day I'll get around
to those notes; some day I'll call it autobiography, and it
will be funny.

Working on resume. Last one I wrote (approx. 3 years ago)
was
something like 10 pages long, mostly because I felt some
need
to explain the context in which I did all of those strange
things.
I figured that the more people could read and know, the
fewer
dumb questions I'd have to fend, the fewer pointless
interviews,
etc. Of course, no more than 3-5 people actually read the
thing,
but they were entertained, and I did get a job (albeit not
the
one I was looking for). So this time the plan is to
hypertext it:
short summary with links to juicy details. Maybe I'll get it
out
today; or maybe I'll get my new basketball goal set up.

I was reading Andrew Leonard's Salon piece on how IBM wised
up to open source, and saw a link to an old essay by
Richard Gabriel, called
"The
Rise of Worse-Is-Better". Gabriel talks about two
approaches:

The MIT Approach, characterized by the phrase "the right
thing", which aspires to be correct, consistent, and
complete.

The NJ Approach, which favors simplicity over
consistency
and completeness. (A better name for this might be "Simple
uber Alles", or even KISS.)

The core argument is that simple systems are more
accessible,
more adaptable, have better survival characteristics, and
therefore proliferate widely, whereas "right thing" systems
are harder to build and maintain, are more expensive, etc.
This much is pretty straightforward, and plenty of examples
pop to mind. However, the interesting point is the assertion
that people willingly adapt to the simpler systems rather
than waiting for the "right thing" systems to adapt to them.

We see evidence of this all the time, but it's hard to shake
the conviction that "better" must really be better. I used
to
work in the typesetting industry, and one of the things I
worked on there was trying to automate the aesthetic rules
of fine advertising typography -- kerning, hung punctuation,
river avoidance, staggered rags, etc. -- but in the long run
such concerns turned out to be irrelevant. It turned out
that
desktop publishers were so happy just to get their pages
instantly, saving them trekking to the type shop and paying
out a small fortune, that they were willing to forego a lot
of finery.

But the arguments persist, ad infinitum, and they're hard to
settle -- partly because nobody really argues for worse, the
winners of "worse-is-better" just do it.

Last week (Thursday 7 Sept 2000) SCO laid off 190 employees.
I was one of them.

The layoff was in preparation for finalizing the acquisition
by Caldera of SCO's Server Software and Professional
Services
divisions. The layoffs should save the Caldera something
like $5-7M/Q, which given that SCO's non-Tarantella
divisions lost $10M last Q, and that Caldera itself lost
some
$7M in its last Q, isn't enough to make the new combine
whole, but is a start.

The company line is that the people who were laid off were
"redundant", and certainly there was some of that here. But
there may also be some sort of behind-the-scenes battle for
the soul of the new company. Certainly, one reason that SCO
has been losing money all year is that it has faced ever
stiffer competition from Linux, and that they are selling
out
to a Linux company can be viewed as capitulation. However,
the Linux company in question (Caldera) is only generating
$1.2M/Q in revenues, whereas SCO's Server/Services groups
still account for $25M/Q. Even with the layoffs (and I've
heard that Caldera laid people off, too, but not how many),
SCO will still account for 75% or more of the combine's
employees.

What may have made me "redundant" was that I was one of
the few SCO employees working on open source projects --
specifically, the long-promised Linux port of sar (which
also got shelved last week). SCO tended to view such
projects as good will generators, but it's not too hard to
imagine that the SCO managers who drew up the pink
slip lists now see that as an unnecessary luxury since
Caldera already enjoys all the good will it needs.

Or it may have just been a mercy killing: I had long argued
that SCO's proprietary OS business was a dead-end, and
that they had to move aggressively into Linux; that the real
way to build a Linux business is through service, not
proprietary bundling; and that what little value UnixWare
still has is as historical legacy. None of these efforts
amounted to a thing (other than possibly wearing my
welcome out). It's been the most frustrating thing I've
ever attempted to do, and I should be glad to put it
behind me. (Keep telling myself that.)

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser
code is live. It needs further work but already handles most
markup better than the original parser.