Home Messages Index
[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index

Microsoft's Nathan Myhrvold on Vapourware and Freezing Competition (Comes vs. Microsoft Exhibit plex_0411_a)

  • Subject: Microsoft's Nathan Myhrvold on Vapourware and Freezing Competition (Comes vs. Microsoft Exhibit plex_0411_a)
  • From: Roy Schestowitz <newsgroups@xxxxxxxxxxxxxxx>
  • Date: Sun, 21 Jun 2009 23:03:17 +0000
  • Newsgroups: comp.os.linux.advocacy
  • User-agent: KNode/0.10.9
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

PLAINTIFF'S
EXHIBIT
411A
Gordon v. Microsoft

Depo. Ex. 1304


From:         nathan?? Mo* Oct 01 11:42:05 1990
To:           billg, bradsi, jeremybu, **(couldn't read next five names)**
Subject:     SPARC, MIPS & Compaq
Date:         Tue Oct 02 22:57:14 1990

Recent events show that we are in more danger than ever losing the key early
ground to SPARC,
which Puts our long term systems business in serious doubt.  Compaq is
considering SPARK, as well as
friendlier options, and now Olivetti is too.

At present we are paralysed because Compaq is reluctant to take the kind of
role that is required to push
our software and combaat Sun in a reasonable way.  They want to push UNIX
(they'll relent to giving us equal billing, but they will expend major effort
in making UNIX successful), they are considering SPARC, and they are
considering a number of ********* non-SPARC responses.

There is considerable sentiment that we should adopt a strategy of appeasement
toward Compaq.  This means not pushing any other strategy for fear that it
will enrage them and push them to SPARC.  If we succeed in appeasing them,
we'll have their half-hearted support, and if they go with SPARC or a poor
non-SPARC strategy then we lose our system business.

This approach is crazy because there is no recovery plan.  It is motivated by
our fear that without Compaq we won't have a market - the Big Deal syndrome. 
I think that the time has come to start pursuing our own strategic direction

There is no point in pissing Compaq off deliberately, but we should adopt the
following plan:

1. Give our hardware design to MIPS.  They would license it openly, including
licensing the ASICs to the semiconductor partners, and the board design to
OEMs.  MIPS would be the official source - we would not have MS copyrights or
anything else on the stuff.  This is not a deadly secret, it is just that
there is no point in being high profile about it.  Peopel may assume that we
had input because of our software role, but MIPS will be viewed as the source
by most everybody.

Note that our design has a large advantage over things that MIPS has done in
the past (or the DEC design) is that it can be built cheaper, and it allows
you to trivially add any PC style bus or chips (EISA, MCA etc) because one of
our chips mimics the signals of a 486 bus.

2.  The slogan for the hardware design will be "The First Open System".  Today,
the SPARC is open but the design system is NOT open - you need proprietary LSI
logic chips, etc.  This system will be licensed in a similar fashion to the
R4000 + you can buy an Architecture License which lets you manufacture the
present ASICs.  This is actually a very major point, which would be seen as a
big deal in the industry.  The announcement of the platform would play up many
of the points in the Trends in the Microprocessor industry news - that systems
vendors must get involved in making high integration "PC on a chip" solutions
and the ONLY way for them to do so is to be able to license both the CPU and
the rest of the system architecture.  This announcement lets them do this for
the first time.

3. The MIPS camp, like the UNIX world as a whole, is divided between OSF and
AT&T factions.  We will not succeed in unifying this as we once thought, and I
do not believe that we should even try.  If MIPS and/or SCO offer a product -
fine, but it is not a big deal to us and we would NOT expend huge effort to
ram a MIPS UNIX standard down anybody's throat.  Oddly enough it is not a big
deal to the UNIX market players themselves either - they will pursue their
present fractured strategies quite happily.

4.  Concurrent with MIPS pushing this hardware platform to OEMs, we would
deliver the following software message to most relevant OEMS (see below for
list).  The message is:

- - We will have an NT Windows binary application standard for R4000 MIPS with
our byte ordering.  It is our primary RISC strategy, and we will not put it on
SPARC.

- -  The simplest way to get this app level binary standard is that we will have
a system software release of NT Windows for the MIPS reference platform - if
you buy the standard chip set and board design from the various vendors, there
is no adaptation work.

- - We may also provide source code to people that want to adapt to another
system architecture (but still MIPS & same byte order).  This is the message
to DEC, or to anybody that balks at the standard platform. We do NOT care what
the mix is of DEC designs versus our design any more than we care abot ISV
versus MCA versus EISA today.  It is VERY important that people have at least
one easy to build, cheap system that connects to PC busses which is why we are
pulling our design out, but given competition we don't care long term.

- -  We are NOT pushing the MIPS hardware platform per se, but we ARE saying that
we will push a binary standard which consists of the Win 32 API and the R4000
with correct byte order.  The hardware platform is just the easiest way to
build one, and the only open design that anybody has asked us to endorse so
far.

- - Some OEMs will just offer the machine as NT Windows only (PC industry types),
and some will offer NT Windows as a side line to their UNIX workstation
business.  We will not require people to trash UNIX to sign up - we sill
encourage them to position this as adding a new binary standard to their line
up which will give them access to Win 32 applications.  Te message above would
be delivered to OEMs as early as next week (Olivetti needs to hear this) and
we would give it to a fairly long list of OEMs (see below).

5.  Our goal is to shoot for an announcement by the end of this year, or early
next year.  We may want to pull this up in fact.  MIPS should announce their
hardware reference platform independent of us, but either just before or just
after our announcement.  Our message would be:

- - We would formally announce Win 32, and make sure that a portion of the
announcement mentioned x86 as well.

- -  We would announce the creation of the Win 32/MIPS binary standard discussed
in point 4 above.  We would pubically hit on each of the points mentioned
there.

- -  We would get a list of OEMs to come up on stage and announce their support.

- - SDKs would be available in 91 and the product would ship early 92.


- -  The positioning of the machines is as the world's fastest Windows machines. 
We would make a big deal about source compatibility between x86 and MIPS for
OS/2 2.0 server apps and for Win 32 apps.

- -  The tone of the MIPS side would be that RISC offers some unique advantages
for a specialized part of the Windows market where people need very fast
desktop machines.  We would NOT be create any expectation that they would take
over the earth.  We would show our slide that shows 486 fastest for existing
apps and this platform great for new apps, but slow on existing apps.  It is
really a balanced future oriented message.

- -  A major part of the message is that your investment in Windows is safe - we
are going to address 32 bits, and beyond that we will address RISC.  You can
go ahead and ignore Sun and that crap because Windows has all bases covered.

- -  We would also talk about the OS/2 3.0 kernal that is underneath NT Windows,
how it is an industrial strength kernal for servers etc and it will serve
advanced desktops etc.

- -  Our announcement would not include SCO or push any UNIX standard.  We could
say that UNIX addresses a present well defined market that has little if any
overlap with the mainstream Windows desktop market.  It is nice that this
specialized system is available on the same hardware as NT Windows, and for
customers in that market it may be the right choice.  Our simple goal is the
realm of Windows Computing.  Over the next several years it will expand to
include applications that require the performance that the R4000 can deliver,
and we are taking the steps to make sure that is possible.

The purpose of announcing early like this is to freeze the market at the OEM
and ISV level, In this respect it is JUST like the original Windows
announcement.  This time we have a lot better development team, so the time
between announce and ship will be a lot smaller.  Nevertheless we need to get
our message out there.

One might worry that this will help Sun because we will just have vapourware,
that people will stop buying 486 machines, that we will have endorsed RISC but
not delivered.  After thinking about this, I think that this is emphatically
NOT the case:

- -  We answer the charges of "vaporware" by pointing at Windows, (after all, we
are porting it).  Windows is shipping a zillion copies an hour and that isn't
vaporware at all.  Every Win 3 sold and every new Windows app is a nail in
Sun's coffin.  We would go on a PR offensive with exactly that mission.  The
big news is that now that MIPS will have Windows, and gain all of the momentum
that is building - how can Sun survive?  So, Scott, do you really think you
can fight that avalanche?

- -  The "Osborne effect" is not relevant here.  A long term announcement for
MIPS based Windows in 92 will NOT freeze the end user market.  It is just an
endorsement that Windows has a future - it is too far off to hurt immediate
sales, and in fact it will help.  The original Windows announcement did not
hurt Dos sales because people decided to wait for it.  The only time when you
get into an Osborne effect is when you announce something near term that is a
viable alternative.

We certainly do need to follow this announcement with a good demo in 6-8 months
when the SDK ships, but preannouncement is going to give Sun a real problem.

6.  We would embark on the PR campaign mentioned above to reinforce the notion
that Windows was the desktop API for the next 10 years, just as Dos was for
the first 10 years.  Sun and others that covet the desktop would have to beat
Windows - and who can do that?  This should be a real push - analysts, ISVs,
etc.  We would really go on the offensive about how strong Windows is, and how
irrelevant Sun and others are as would be challengers.

7.  One potential sop to IBM would be to announce TWO binary standards for RISC
for Win 32 and OS/2 3.0 - MIPS and RIOS.  I think that the Austin guys would
actually do this, and they would not even be mad about MIPS being the other
one because it hurts SPARC so much.  If we do this, then we would announce
that we will not port to any othe architecture for 3 years (obviously
non-binding) to really rub it in that SPARC is out.  The way to position this
to them is that we've seen Sun building steam and we need to support the MIPS
world as a generic RISC.  Ideally we would do this with a short enough lead
time that they couldn't mess around too long.  All we would do is announce a
long term statement of direction that the technology would be available **
RIOS - this is safe for them, and it makes Sun look bad, so we could probably
make it an easy decision for them.

8.  In the past we've talked about Power PC - a next generation PC spec with
advanced audio and video for both x86 and MIPS.  We would still do this, but
it does not have to be part of the announcement or the base level hardware
that MIPS would push.  We should reserve this as an exclusive club the way
that we originally planned RISC PC, or we could go public with it later on. 
There is no need to make this part of the early announcement.  The system
design that MIPS wouod push has a video daughterboard with a connector so we
could always add the new stuff to these systems if that was important.  Note
that machines would not ship in volume until 92 anyway so we would have until
this spring to finalize the Power PC hardware.

9.  Our stance to Compaq on this is as follows:

- -  We do not tell thm about this until we have had enough intial discussions to
confirm that this direction is viable.  This means getting the framework of an
agreement in place with MIPS on the hardware platform and also getting the
agreement from at least 5 OEMs.  This is NO different than them talking to Sun
without telling us first.  It mainly means that we don't tell them we are
going to do something until we know that it is really possible and will play
out like we think.  This initial activity has to start soon.

- -  We then tell them that there is enough steam building under the MIPS camp,
and uncertainty from Sun's progress that we feel compelled to announce an
application level binary standard for NT Windows as a future product.  This in
No way hurts their plans - UNLESS they are really planning to go with SPARC. 
Since we are not saying that people have to use our system design, they can
come out with their own "superior" Compaq/DEC design at any time

- - Compaq can either sign up and attend the announcement, or not as they see fit
but we should set a stake in the ground and not move ot for them.

- - We can present to them why we think that this is harmless to their present
business, and will not harm current sales.

- -  This is not something rude that we should let them make us feel guilty
about.  They have outlined these alternatives for their actions, two of which
are extremely bad for us, and the remaining one is not very attractive, could
get fucked up and at best puts us on an equal footing with UNIX which is a big
step down the from the present situation.  We are just presenting them with
something which is highly compatible with one of their options.

- -  If Compaq really went with SPARC over this plan, then they were heading
there anyway.  The environment that this plan would create is much more
friendly to them than the SPARC environment.  We are just helping the MIPS
community to come even part way towards where SPARC already is.

10.  The OEMs to contact are basically the same ones listed in previous mail
about uniting the MIPS world:  Olivetti, NEC, HP (a long shot but worth it),
DEC, Bull/Zenith, Siemans/Nixdorf, Nokia, Sony, and finally selected people in
the pure PC camp - Acer, AST etc.  MIPS can throw in a number of big companies
which will endorse but not say much (Amdahl, Tandem...).  In the final weeks
we could consider adding just about anybody else who had reasonable volume. 
the idea here is not be be exclusive - it is to get a reasonably large list of
reasonably credible companies.

____________________

The first comment is likely to be "do you have anything without Compaq and
IBM?".  There are two answers:

First, the goal is NOT to make this machine sell zillions of copies in 1991 -
it probably won't even ship then.  What we need to do is announce a long term
direction for making high end Windows machines - and freeze Sun out of our
OEMs, our ISVs, and from industry perceptions at large.  The idea that
Microsoft will move Windows to MIPS is a very powerful concept that can be
used to put Sun on the defensive.  As mentioned above, we need people to view
every sale of Windows or a Windows app as a vote (and investment) against Sun. 
The OEMs listed above are plenty credible to achieve our goals.

Second, I think that we grossly overestimate Compaq's ability in this area. 
They have a great reputation, but at present their plans are NOT in sync with
ours - they are on a mission to clean up in the workstation market - and all
signs are showing that if any cleaning is done, Sun will mop the floor up with
them.  Perhaps they can win competing against Sun in their own backyard where
everybody else has lost, but I doubt it.  Even if they do succeed, they are
presently off to push UNIX not our stuff.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAko+vDUACgkQU4xAY3RXLo76XwCdH6V0WucysDlYM95MbJSqRKUc
NvYAoKqNska4o//dy8SvP4KTUlyv/nOr
=b+iJ
-----END PGP SIGNATURE-----

[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index