[Date Prev][Date Next] [Thread Prev][Thread Next]
[Date Index] [Thread Index] [New search]

Re: Word vs. FrameMaker Information



At 10:25 AM -0800 10/12/98, Marcus Carr wrote:
>>Microsoft's attempt (described below by Marcus) to corrupt XML is quite
>>similar to its attempt (now defeated) to corrupt Java. Both attempts were
>>for the same purpose: Perpetuating the Microsoft monopoly at the expense of
>>the end-user and developer communities.
>
>That may well be a reasonable assumption. I try to first assume that
>organisation's motives are less devious than they may look, but (with my
>limited understanding) it certainly is pretty hard to take that stance on
>the Java issue.

If you doubt the sinister and calculated motives of Microsoft, take a look
at this extract from a Microsoft memo that has gained some notoriety on the
net under the name of "The Halloween Paper".  It points out how MS even
intends to attack the efforts of Open Source Software (OSS) developers,
like those who have created Linux, Apache, etc. and seems to want to shut
them down.  The bombshell is right at the beginning in the second sentence.
If this sparks your interest, I can point you to all of the related
writings on our User Group web site.  These documents are quite intriguing
for anyone who is interested in OSS and/or the MS attempt at world
domination.  Write for directions.

- web

****** extract begins ******

Blunting OSS attacks

Generally, Microsoft wins by attacking the core weaknesses of OSS projects.

De-commoditize protocols & applications

* OSS projects have been able to gain a foothold in many server
applications because of the wide utility of highly commoditized, simple
protocols. By extending these protocols and developing new protocols, we
can deny OSS projects entry into the market.

* David Stutz makes a very good point: in competing with Microsoft's level
of desktop integration, "commodity protocols actually become the means of
integration" for OSS projects. There is a large amount of IQ being expended
in various IETF working groups which are quickly creating the architectural
model for integration for these OSS projects.

Some examples of Microsoft initiatives which are extending commodity
protocols include:

* DNS integration with Directory. Leveraging the Directory Service to add
value to DNS via dynamic updates, security, authentication

* HTTP-DAV. DAV is complex and the protocol spec provides an infinite level
of implementation complexity for various applications (e.g. the design for
Exchange over DAV is good but certainly not the single obvious design).
Apache will be hard pressed to pick and choose the correct first areas of
DAV to implement.

* Structured storage. Changes the rules of the game in the file serving
space (a key Linux/Apache application). Creates a compelling client-side
advantage which can be extended to the server as well.

* MSMQ for Distributed Applications. MSMQ is a great example of a
distributed technology where most of the value is in the services and
implementation and NOT in the wire protocol. The same is true for MTS, DTC,
and COM+.

Make Integration Compelling -- Especially on the server

The rise of specialty servers is a particularly potent and dire long term
threat that directly affects our revenue streams. One of the keys to
combating this threat is to create integrative scenarios that are valuable
on the server platform. David Stutz points out:

* The bottom line here is whoever has the best network-oriented integration
technologies and processes will win the commodity server business. There is
a convergence of embedded systems, mobile connectivity, and pervasive
networking protocols that will make the number of servers (especially
"specialist servers"??) explode. The general-purpose commodity client is a
good business to be in - will it be dwarfed by the special-purpose
commodity server business?

* System Management. Systems management functionality potentially touches
all aspects of a product / platform. Consequently, it is not something
which is easily grafted onto an existing codebase in a componentized
manner. It must be designed from the start or be the result of a conscious
re-evaluation of all components in a given project.

* Ease of Use. Like management, this often must be designed from the ground
up and consequently incurs large development management cost. OSS projects
will consistently have problems matching this feature area

* Solve Scenarios. ZAW, dial up networking, wizards, etc.

* Client Integration. How can we leverage the client base to provide
similar integration requirements on our servers? For example, MSMQ, as a
piece of middleware, requires closely synchronized client and server
codebases.

* Middleware control is critical. Obviously, as servers and their protocols
risk commoditization higher order functionality is necessary to preserve
margins in the server OS business.

Organizational Credibility

* Release / Service pack process. By consolidating and managing the arduous
task of keeping up with the latest fixes, Microsoft provides a key customer
advantage over basic OSS processes.

* Long-Term Commitments. Via tools such as enterprise agreements, long term
research, executive keynotes, etc., Microsoft is able to commit to a long
term vision and create a greater sense of long term order than an OSS
process.



** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **