Based on Comes vs Microsoft exhibits, we already know that the company from Redmond is most afraid of GNU/Linux. There is no point in denying it and it is always valuable to see what the company says internally. In today's exhibit, Exhibit PX08256 (2001) [PDF], a revealing memo from Gates is shown publicly, probably for the first time at least on the Web.

Our strength comes from the singularity and popularity of the platform. even we can't afford multiple overlapping messages especially when developers are moving to Linux and Java.

An ongoing jihad here is critical.

Our most potent Operating System competitor is Linux and the phenomena around Open Source and free software. The same phenomena fuels competitors to all of our products. The ease of picking up Linux to learn it or to modify some piece of it is very attractive. The academic community, start up companies, foreign governments and many other constituencies are putting their best work into Linux.

We need other creative ideas to allow Windows to match the viral nature of Linux.

Provisioning and monitoring Windows systems needs to be far easier than Linux systems.

The strength of this platform and the innovation around it is the key element in preventing commodization by Linux, our installed base and Network Appliance vendors.

We will continue to charge for email capability which we need to enhance with Gmail capabilities as discussed in the subscription memo, Unclear is whether Workflow or Portal Servers are separate and what access is paid for by having an up-to-date Office license.

The PC has to have all the advantages of being a simple dedicated appliance without giving up the ability to run many applications and support a variety of peripherals and update the system software. Walt Mossberg and our satisfaction data say we haven’t done enough on this.

Appendix: Comes vs. Microsoft - exhibit PX08256, as text

From: Yuval Neeman Sent: Monday, January 08, 2001 5:55 PM To: Yuval Neeman's Direct Reports Subject: FW: Software Agenda

Attachments: SOFTWA~1.DOC

SOFTWA~1.DOC (56KB)

---- Original Message ---- From: Jim Allchin Sent: Monday, January 08, 2001 7:43 AM To: Brian Valentine; Paul Flessner; Mike Nash; Will Poole; Yuval Neeman; Dan Neault Subject: FW: Software Agenda

Please make sure you read this and distribute it to your managers.

Although it isn't completed, it is worth reading, commenting on, and planning for.

jim

---- Original Message ---- From: Bill Gates Sent: Thursday, January 04, 2001 6:22 PM To: Senior Leadership Team Cc: Rick Rashid Subject: Software Agenda

This memo is one of the ones I have discussed doing.

It is not the Roadmap memo.

Rather it is my view of the key issues.

This will be a live document. Some of the points are incomplete as you will see.

We will have some time to discuss where I should focus more attention during the SLT meeting tomorrow.

(1) Plaintiff's Exhibit 8256 Comes V. Microsoft

MS-CC-RN 000000067027 HIGHLY CONFIDENTIAL

-------------(Contents of "SOFTWA~1.DOC" attachment):-------------

Software Agenda For companies like Oracle where they have a single technology and a focus on a single customer set its easier to understand what their priorities are Microsoft is building a much broader platform for a broader set of customers. Our strength comes from the singularity and popularity of the platform. even we can't afford multiple overlapping messages especially when developers are moving to Linux and Java. our platform pieces have to solve major problems for customers and be extremely popular.

This memo is an attempt to draw up the list of areas where progress can make a big difference so that we can focus on these and track our progress.

In addition to improving this memo a complimentary Roadmap memo needs to be created.

Software Distribution We need to be able to go to endusers and corporate customers with a service for keeping their software up to date. For customers I believe this should be included in our low cost subscription offering which you get 3 months of free membership in when you update Windows or get a new copy. The service needs to federate through the corporation so they can control what goes out to their end users. Allowing updating to be federated will help us know how to federate other elements of the system which contain Microsoft URLs or connect to our services (help, crash, dump, IM, custom home page, SIP communications, remote storage...). Federation means giving IT a way of reviewing and controlling what goes out as well as using the infrastructure for their own software distribution. We have many formats and approaches to software distribution today. the question of when "setup" gets done affects distribution. SMS should go away as a separate product as we provide this service as a part of Windows. Windows update needs to move to sending deltas instead of whole files. We need Drizzle features that MARS provides. In many cases we need to move away from DLL replacement to patching using the PPRC technology. Fusion needs to be embraced broadly. Windows Update has to be a lot less intrusive to the user and a lot richer in content. Corporations have to feel a real loss if they are not getting the fixes that only come by belonging to the update service. We need to articulate the vision for software distribution and get ISVs involved as well. OS updates and Driver updates need to share the same infrastructure. Windows needs to pick someone to architect this and make sure it is a central element of our platform. The business benefit of having great software distribution will be huge because it will give corporations a reason for staying up to date with us without viewing every new bit that comes from us as creating gigantic overhead, It will also allow us to up the quality of the products our users experience dramatically. This is the most important reform I list. The Windows group needs to drive the creation of this service for all Windows users and ISVs.

There are parts of SMS which could get moved to a "PC support" overall package (like software inventory) but that would only make sense if we bought one of the PC support packages to sell as an application.

Quality Microsoft needs to know when users experience crashes or other errors that come from software bugs. Using this feedback loop we will be able to fix problems in our products quickly. Combined with the distribution service described above this will do more to improve our reputation than any new features we will provide.

Both Office (Dr. Watson" and Windows (Bluescreen) have systems for taking system crash information and publishing it to a MicrosoR URL so that we can analyze the crash. Already these systems have uncovered a number of important crashes that our normal systems had never caught. Today we have no way of taking a system that is experiencing problems and being able to remotely patch in code to gather more information. Using the work done in PPRC we can add that capability. Today the crash logging systems aren’t able to involve a third party ISV or PSS or a customers IT group in the process of gathering all the information and solving the problem - these dumps are coming straight to the product group today. The current systems are restricted to dealing only with crash situations - they should be broadened to support general error conditions including having the application call on these services when something is wrong. These crash handling systems need to be changed to work in the unattended server environment.

We need to have at least 100,000 clients and 10,000 servers where we totally support the machines to have a complete profile of problems. As part of our subscription offering being able to log what goes on on these systems, back them up and solve any problems that come up will guide our work. We need to understand the costs and complexities users experience with our systems.

Beyond the "error" feedback loop described above we need an overall focus on quality issues including someone full time who looks at the business, partnership and technical issues that could significantly improve the situation. People like the specialized publications and Intel could play a role in helping us measure what needs to improve. For example a great feature of Whistler is the ability to connect up with someone else in order for them to help support you including letting them take control of your machine. We need to fix the firewall problem that stands in the way of all PC real time scenarios for this feature to see its full use. We need to continue to evolve this capability so that support costs for PCs go down significantly. This feature needs to work for ISVs and IT. Another key element of quality is to make sure that buggy third party code creates less problems for our users. Central to this is code signing and forcing addon code to go through a testing process. Our update service should be able to notify users that a piece of code they have installed has had its certificate revoked. An ongoing jihad here is critical.

Productivity The man-years of work per feature created at Microsoft isn’t good enough. Good architecture that leads to powerful shared infrastructure can help with this but there are dramatic gains that need to be made beyond that. The total number of bugs we are creating and then having to track down slows everything down. Even a 10% improvement would make jobs more interesting, cut costs and allow us to get higher quality more powerful software to market quicker.. Potential advances can come from tools, processes, and source language. The recent move to SourceDepot was a big success and reinforced the importance of great tools. Likewise the Prefix work from PPRC has been extremely beneficial. Still our tools overall are poor. The tools we use internally should be a pure superset of those we offer to the market. Our source codes should be structured XML documents that allow specification and code to be more closely coupled. Part of the PPRC vision is that navigating information related to execution and testing with the source code should be easy. Source codes should be easily accessible online. Part of Simonyi’s vision is that the source language itself should be extensible so that domain specific constructs are simple to create and understand. User interface’ s should be so easy to create that you create them and then document them. Ideas for improvements will come from PPRC, Simonyi’s work, Research in general, Linux development, other outsiders and parts of the product group including some initiatives in David Greenspoon’s area.

I think VS8 should embrace the idea of source code as an XML document with an environment that combines the vision Intentional Programming and PPRC have suggested. This will be a huge advance for our customers as well as for internal productivity.

We need a specific agenda in this area - things we are implementing and things we are exploring. We need regular checkpoints for discussing best practices and new ideas.

Openness Our most potent Operating System competitor is Linux and the phenomena around Open Source and free software. The same phenomena fuels competitors to all of our products. The ease of picking up Linux to learn it or to modify some piece of it is very attractive. The academic community, start up companies, foreign governments and many other constituencies are putting their best work into Linux. Although we cannot make Windows free for commercial use we can do dramatically more to make it accessible including parts of the source code. We can make it flee in restricted areas. One important idea is to be able to source debug any running copy of Windows by connecting up to an Internet hosted symbol table with PPRC technology allowing you to patch the code. This means that you don’t have to get the entire source and learn how to build it to debug and add on to Windows at a source level. Although some parts of the source would have to be made opaque to the general public, some of the source could be there for all people and all of the source could be there for some people. We need other creative ideas to allow Windows to match the viral nature of Linux.

Storage innovation (including caching & replication) The Microsoft file system and related protocols have stood still for almost a decade. During this time HTTPFLJRLsiDAV and Email have become important competitors to the file system. Users are very frustrated that even the most basic property query capability is not available for files. Even inside Windows itself we create special stores for music, fusion, passwords and every new object that needs property based viewing. Office has created a storage system called Sharepoint based on HTTP. MSN created a free "storage" service called MSN communities. Office has had to abstract away from just using our file system APIs because Windows did not connect out to rich enough servers and so Office embraced some form of DAV. IIS is a kind of storage system with its own naming and security and code invocation capabilities. Our customers are finding it easier to install storage appliances than Microsoft servers. Storage systems are being abstracted away from the application servers. Both our servers and CAL revenue are at risk. The best solution is to pursue an architecture that is over a decade old and that is to make the storage system richer - rich enough so that email, music and things like printers, fonts, etc.., are able to be queried and stored without using special applications for each type. This means taking our next generation SQL technology - Yukon and making it the next generation file system.

The new strategy will only work if we get a class of applications that take advantage of the new capabilities of the store system. Capabilities like basic Document management should be intrinsic to our new file system. Serving up bits over HTTP and serving them up over SMB should not be different. The name spaces and ability to invoke code should come together. HTTP listening and HTTP efficiency are key capabilities - one listener and one talker. We need a vision of how storage semantics and systems will evolve. What is our response to huge SAN networks of disk supporting the commodity protocols? Will we make Windows systems easy enough to set up and price attractive for these markets? What kind of high end features are we missing?

I have pushed the Windows NTFS group to think of Sharepoint as a storage system that they should ship and then work to provide something that is integrated and better than NTFS alone or Sharepoint alone. There is a question about Yukon subsets. Whistler+l should probably align all of the various system stores to a subset of Yukon like DireetDB. We also need a compatible subset for PDA devices. Btackcomb is the release that has the Yukon file system active once it is booted and is used to simplify the interaction with all information on the system

The future of storage systems has to be considered in light of the intelligent caching that will be present in the Network and in the client devices. There is no reason that Geo-caching should apply to HTTP information and not to the Windows file system. Our whole Message bus strategy should apply to caching file system information as well as generic messages so that the work we do on tagging, local recomputation, and push]pull are shared. We should be the leader in defining the new protocols for caching cache invalidation and reporting usage of cached information. Our client level caches give us the ability to influence Websites to do things our way.

Making replication of information is another critical goal for storage reform. One of the key scenarios where the PC shines is in offline use that is not going away. Today the user is forced to manually do the replication of all the information they might want offline. The interface is different for Mail, Directory, WebPages, Files, and Code. For files we have Briefcase and Intellimirror. Windows2000 brought the different replication commands into one place but that reinforced the problem. Our file system should treat caching of information - all information - as one of its native capabilities, We will need a short term plan for replication advances as well as the plan for Blackcomb. We have to make it easy to move between PCs either whether or not a user connects to our services or not.

The new storage system has to rtm as a service in the cloud at very large scale including hooks in Windows to make it easy for subscribers to store data. Even before we get advanced storage we need to provide a rich replication service between all our devices.

Collaboration/Workflow on SQL Strongly related to storage reform is having email show up as an item in system storage. We have already taken the step of combining the Exchange and SQL groups with this goal in mind. Yukon is being influenced by the requirement of hosting the next version of our email server. There is a key question about what different servers we should have on top of Yukon for Knowledge workers. The Windows File Server needs to use Yukon and offer much richer features which subsume Sharepoint. We will continue to charge for email capability which we need to enhance with Gmail capabilities as discussed in the subscription memo, Unclear is whether Workflow or Portal Servers are separate and what access is paid for by having an up-to-date Office license. I believe we should take the Biztalk platform and use it for Office workflow but this requires a visual front end. The technology needs to relate to our Information Agent work.

The separation of Office from our servers has held us back in solving problems for knowledge workers. No matter what the organization structure is Office needs server support for rich Document Management, Workflow, Conferencing, C-mail and other knowledge worker scenarios. We should also combine the efforts to have a rich environment for Team source code development with the desire to have a Vignette like high end production tool built on these servers.

Whatever servers we create we will want to operate them as a service for customers signing up to our Office.Net service.

Authentication and Directory We need to move over to SQL as the store for directory and metadirectory as soon as we can. We need to have security ACLs they aren’t dependent on Ids which are tied to the hierarchy chosen for names. Companies should be able to move users around in the hierarchy whenever they want. By using SQL our tools will work with the directory information. We need to articulate the importance of a Metadirectory and take leadership in having connections to all the applications that use directory information. There will be a lot of key schema work that we n~d to do in partnership with other leading companies to make this work. We need A.D. to support public keys and allow for federation with Passport. One of the systems should be renamed to have the same name as the other. Our metadirectory should be usable independent of the OS it is running on for intranet scenarios. The Directory team needs to work with Yukon to get the data model and protocol issues resolved so that the semantics for authentimtion replication can be done without special set up. We need to make sharing of all kinds of information across corporate boundaries easy by federating with Passport. We need to make it easy to authenticate the sender of information the same way. Directory design should not be a fragile and gating item for the deployment of Windows,systems. We need to make sure our authentication system allows for signed code. We need to eliminate vulnerability that the way our admin account passwords are handled creates. Our customers should not have to go to third party solutions. Our certificate architecture should be aligned with our ACL/Directory/PKI work. Customers shouldn’t have to buy add on security products like Entrust. The Windows group needs to drive a roadmap for this big change in how we do Directory.

We should be able to charge extra [’or Metadirectory and the Federation services that allow the Extranet services to work through Passport.

We should have Office and H,R. Apps vendors work with our MetaDirectory people so that the common scenarios relating to finding out about employees provides a great front end experience. Today trying to find out who works in what part of the org or where they are located or what their backround is far too complex.

Management/Setup Provisioning and monitoring Windows systems needs to be far easier than Linux systems. Our management infrastructure has to use the eventinghogging/filtering APIs that we are defining with the SQL Message bus. The vision of the BIG group where you can describe a set of systems to perform a task and then monitor those systems through an XML document is key here. An abstract description of a servex should allow a service to fully provision the server. Customers respond favorably to the idea of having ASP resources available on demand for peak loading and disaster recovery. BIG and AppCenter and Management to me are really one set of’problems. By using all the SOAP/XML protocols and the Yukon infrastructure we will be able to have an extensible management environment. Windows has to work in a headless environment including reporting crash information over the network to enable the automatic provisioning scenario.

One of the reasons that appliances are so attractive for dedicated functions is that Windows is too hard to setup for specific profiles. Although for high visibility profiles we should have special packages it should be very easy to choose a profile like "Load balancing" or "RAS" and a few parameters and simply ask the server to be setup. We need to merchandise how this approach can be more flexible in terms of staying up to date and providing flexibility than a pure appliance approach, In the past we tried to do setup and monitoring using MMC. MMC wasn’t a model - it was simply a shared display service. The Setup and Management Console capabilities need to be put onto the XML runtime as that gets done so that we get rich viewing and navigation. I don’t know what interim runtime the Management people are trying to use - this should be discussed.

Some level of management needs to ship with Windows and some level can be extra charge. We need a rich framework/schema around the Yukon infrastructure that third parties use to add management capabilities. Tivoli excelled as a framework with third party value added before they actually shipped rich functionality which is a model for what we need to do several parts of management. We should make sure firewall issues don’t make it hard for people to manage their systems across the Internet. We should consider offering Remote management services under the new framework.

Leadership in management will be measurable from customer feedback, revenue, and comparison with other high end vendors. We have invested a lot in this area over the years but our solutions have suffered from having their own infrastructure. Windows cannot be a strong server product without having excellent management.

Presentation reform Our "presentation" layer today consists of a number of disconnected technologies including DirectUser, GDI Plus, DirectX, Trident, PTO, VS Forms, Webforms, Ebook, Office SDM and Forms3. An innovative presentation layer is critical to showing off why local application execution provides a better experience and keeping the PC vibrant versus dumb devices. We want most applications to download to PCs and run there receiving XML data and XML SOAP calls over the Internet. A rich presentation environment that allows forms and UI to be specified and easily edited and allows XML data to bind to each is critical. The lowest level of our Presentation system should present a single driver interface and allow exploitation of new graphics chips. Turner Whirred in Research is pulling together thoughts on what requirements this creates.

A good design for this system will allow us to layer in PDF compatibility including an annotation layer. A good design for this system will allow us to build an animation layer which is competitive - today Flash is playing this roll. Video and Audio will play a major role in upcoming interfaces and they cannot be relegated to just run in a player application. Also screen updating should be done more smoothly using offscreen memory

I want us to be able to construct rich UI easily simply by editing an XML document. I want us to be able to bind to XML data easily using the new forms environment. We have compatibility issues to consider with all of the above systems. Trident will be a piece of the solution as the HTML displayer but it will likely not be at the center of the system.

One important consideration is to make sure that display remoting using our proprietary WTS protocol/Netmeeting (same or different?) continues to work for applications with extensions to support high quality audio and video. There are a lot of compatibility constraints but also a need to innovate in this level of the system. A key question is: Can we make applications look better if they use the new approach?

Its unclear to me how much symmetry we can have with the server based forms model - Webforms. Ideally we want XML payloads to rich clients but developer’s don’t want to think through their forms logic twice and completely duplicate that code. Our strategy is to make standards based HTML look increasingly obsolete and not have to give away the underpinnings of our presentation environment to a standards group. There is an ongoing dialog between Ted Peters and all of the constituent groups to try and come up with a proposal on where we go with this. FIP is potentially a partner for printing related aspects of the new approach.

Applications platform Our applications platform message is quite confused today. Pieces like CLR, WMI, MSMQ, XML runtime, Biztalk, MTS, i-IS, ASP+, Load Balancing, Message bus, SOAP, UDDI and Yukon are not consistent and reinforcing. Basic standards like eventing, logging, and filtering have to be established. The discomaeetion of these products make our message when trying to win back the developers who like JAVA and J2EE very difficult especially when we have the limitation of being only on Windows and those technologies are supported on many platforms by many companies. Although we have waited a long time for the shipment of VS with the URT that doesn’t give us anywhere near a complete consistent platform story.

We have talked about many of these problems but not pulled things together. MSMQ is a bit of an orphan. Our transaction strategy isn’t getting any traction while BEA has established an $800M per year business around that technology. We did a good job on MSMQ and MTS but they couldn’t thrive on their own. Our decision to make Yukon the center of gravity and to connect Yukon to the URT should give us the clear starting point. We may need to be able to package Yukon so that it doesn’t feel like a database if all you want is a Message bus. We may need to create some subset implementations of things like Queuing for size and speed reasons. However the API set should be consistent. We may need to be compatible with some of the J2EE apis.

I think that between Paul, Yuval and Eric’s group with some help from Rick Rashid we should be able to go through another iteration on this (like we did with NGWS) and come up with some clear answers.

The strength of this platform and the innovation around it is the key element in preventing commodization by Linux, our installed base and Network Appliance vendors. We are in the best position to define the distributed application model that allows work to be moved out into the Network. We don’t have enough research our product group people pushing this agenda but we have the best opportunity. This is what it takes to seize leadership in caching, load balancing and protocols, I think between Management/Setup and a vision of how our platform is Distributed we give ourselves a chance to lead in all the Level 7 networking pieces. I almost included this as a separate item but executing on these two technical pieces will give us what we need except for packaging, marketing and sales force.

There is a major packaging question once we get architectural coherence. To what degree should we package or charge for the rich so ealled middleware pieces separately from the rest of the platform? Are there advanced forms of some of these pieces that cost extra? Most of the API set we want supported in the base server with understandable advanced services costing extra.

We are discussing with IBM a joint effort to agree on most of the Application server pieces so that companies have a choice of our two implementations. Although this would be an unexpected partnership I see a lot of advantages for both companies. I think they can help with parts of the architecture. The current view is that we do not share any code between the companies.

We also need to drive Microsoft to use the new platform to prove it out and show it off. Our Services need to use these architectures so that our tools make them easy to extend.

PC Excellence The PC has to have all the advantages of being a simple dedicated appliance without giving up the ability to run many applications and support a variety of peripherals and update the system software. Walt Mossberg and our satisfaction data say we haven’t done enough on this.

One critical issue is boot time. I spend minutes of my life everyday rebooting my system at work and at home It has gotten slower as I have moved to new releases of Windows. Just making a big advance in this area would cause a lot of people to upgrade Windows. The Windows team is focused on making Standby and Hibernate much faster including the BIOS piece that requires OEM work. We need to make sure we improve it even a lot beyond where Whistler will be partly with software advances and partly with hardware. We should have a flavor of Boot that assumes not big changes and uses the same logic and de-hibernating.

WinHEC is the forum where we get to send the message to the hardware vendors about what we are focused on. We need a clear message on power management, removable media, microphones, video decoding, graphics, that makes the PC a moving target.

Data Center Its critical that we be able to handle the most demanding applications - even those that don’t partition naturally across many servers. We need to lead with partitioning technology but also make sure our hardware partners are providing single server systems that match everything SUN is doing - memory bus, I/O speed etc.. We will continue to find software bottlenecks in these scenarios. There are a number of sottware features we still need to match up to Mainframes and Solaris in the Datacenter scenarios. Many of those we can use partners to solve. Key hardware partners are IBM (particularly if they will put x86 support onto their latest chip technology), Intel, AMD, Compaq, HP, Unisys and a number of Japanese vendors. We have put a lot of energy into supporting Itanium and we need to evaluate at some checkpoints how well Itanium will provide what we need.

Reliability and Manageability are also critical to success here but those have already been mentioned. The Data center does bring special requirements to those issues.

Real time communication Part of our vision is that communication in the future will be multi-modal. People will have a screen - either a PC or a PDA type screen - and anytime they are interacting with the screen they can use speech for commands or navigalion or dictation or talking or voice mail. Notifications/email/filtefing. Screen call. Collab. Ozzie-Groove. Multimedia. Capps vision. Screen Call extended - all calls coordinated as speech and data. Milestones.

Asynch Communication Email client. Storage. Gmail. CRM. Information agent. Stored Annotated meetinss. Scheduling, Multimedia. Future of Outlook. A piece of this was already in the subscription memo. Notifications versus IM versus Chat versus Mail.

UI approach/Schema This is the hardest one to write. I need to put a lot of time on this. I have a lot of thinking I need to share on this.

Office code base Development platform. Extensibility. Future of Word. Future of Frontpage. Future of Access. Future of Works. Future of Publisher,

Tablet/Ink Reading/Annotation Meeting/Learning XML runtime (forecasting, management,..) Future of Excel,

Speech platform and Natural Language Over the years we have invested quite a bit in natural language and speech recognition/synthesls. Recently some people have asked when it will really enhance our products and whether there is a customer/developer need that will be huge around this technology. While some parts of the speech stack we could have developed by partners the "API" that says how people allow speech to affect their application is something we need to lead in and own.

As described in our RealTime and PC vision, speech input will be a mainstream part of using a PC. Likewise typing natural language as part of a conversation (type in line) will be the most efficient interface for many things. This means that alI applications including websites will want to be able to describe how to "react" to natural language. For example when you connect to Amazon.Com with a PC or a PDA your commands should help you navigate. Part of Windows/.NET keeping a lead as an applications platform requires us to have the architecture and tools that make it easy for people to language enable all applications. We need to innovate in how these grammars or slot filling or tree diagrams deal with probabilistic input. This includes having the client side and server so,rare that can execute the applications. A degenerate case is where the device is a voice only device. Since Nuance and Speechworks dominate people creating voice only interaction it is natural for them to be strong in websites wanting multimodal interaction. Also IBM, Philips, Lucent and various research labs will like to give away speech technology so our asset needs to Focus on toois and API allowing other speech engines to be used.

Speech interaction will change the way applications are defined and finally bring the idea of social interface back to the fore. I think we can define some scenarios that we need to lead in and track our progress in being the primary platform for language enabled applications.

Summary It very exciting to see how many cool things great software can do. Things that everyone really cares about - Knowledge workers, IT, Developers :and Consumers. G