[snip]
> It seems to that a lot of people who come out with new
> systems try to include import functions so that they
> can import data from other systems into theirs.
>
> But you know what? The success of the system is hardly
> ever determined by your ability to read other people's
> data. The success is determined by what the system can
> do.
True -- when the system moves into a functional vacuum.
This is not the situation we face. There is plenty of
competition from startups. And some of them look very
good. In fact, some of them are almost ready to ship,
and are IE/NS 5 compatible.
> Now, if it is successful, crowds of users may demand
> import capabilities. If so, it makes sense to deliver
> it. On the other hand, all the effort that goes into
> designing legacy-compatibility *at the outset* (note
> the stress) is time that takes away from the real
> success-proposition: the system functionality.
Let's look at functionality another way. Is it better
to give one million users 99% functionality -- or 300
million users 85% functionality? I would argue that
number two is vastly more useful to spaceship Earth.
> Finally, to explain that stress on "at the outset",
> let me make it clear that future compatibility with
> one's *own* system is an absolute requirement. Oracle
> made it big by protecting people's investment in their
> data, so that old databases were directly usable 90%
> of the time when an upgrade came out. And the other
> 10% of the time, the conversion was totally automated!
That's one of the reasons Oracle made it big. Far more
important, Oracle overpromised hugely, delivered buggy
software, and then desperately brought the code up to spec
before the unhappy customers actually bailed to another
supplier.
> Once people put information into the system, the
> system has to honor that effort. It has to protect
> and preserve that data by whatever means necessary,
> defending it against file corruption, hardware failures,
> and software failures.
>
> But making it interact with old systems? No. That is
> the hallmark of all the "first tier" technologies that
> never go anywhere. In the hardware world, every 4 or
> 5 years a new processor came out, and for the first
> year there was always a few companies selling computers
> with both chips. Those systems always sold like the
> turkeys they were, and in 12 months the only players
> left standing were the ones with systems designed around
> the new chip -- if it was any good.
*Old* systems? HTML 3.2 is the current WWW standard!
As for defying standards, Cringley thus immortalized Grid,
and all the other PC companies that decided to ignore
the IBM 8086 standard: " ... Why be compatible when you can
be better, said the smart guys all the way to bankruptcy
court?"
> There are major new technologies available today that
> we can design the system around. Working to achieve
> legacy-system compatibility (at this early stage) only
> hamstrings the design,
Well, I'm listening. Not going to catch up to you guys
on code. (But Lee doesn't think it's a huge problem?)
siphons away energy that could
> be devoted to increasing functionality,
Well, we're all a bit short on time. I'd like to perfect
bootstrap.org, and the interface, but damn, the schedule
doesn't look promising.
and has only
> dubious value with respect to increasing the system's
> appeal.
That's my bailiwick, Eric. I disagree.
And in 30 years I would rather look back and say "We did it --
and changed the world", than
... "We had the best system." (I coulda been a contenda....)
Can you guys come up with an architecture that accommodates
older email via a workaround "module"? Something -- perhaps
less than perfect -- which allows older email clients to
plug in, but doesn't trash the basic architecture of OHS?
Nicholas
-- ______________________________________________________Nicholas Carroll Email: ncarroll@inreach.com Alternate: ncarroll@iname.com http://www.hastingsresearch.com/white_papers ______________________________________________________
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 17:57:53 PDT