Partager via

The New Platform Play

  • Article

Long time colleague Bruce McGee expressed in email some concerns about Microsoft openness and interop, and general trustworthiness to do the right thing: 

“[Concerning the new job at Microsoft], I'm hoping it's really cool stuff for you and really usable stuff (in a lot of different ways) for guys like me.  Just please try to avoid the things about Microsoft solutions that make me squeamish.  Proprietary single vendor protocols and solutions.  Sometimes I think the cool
and shiny technical stuff is simply a side effect of the real plan,
which is to lock people in to the point where it's difficult and costly to move to anything else that you'll keep a lot of the market, even if you cut back on the cool and shiny stuff.  It's not bad for Microsoft's bottom line, but it isn't as good for mine and it flies in the face of why I'm in this field in the first place.  To enjoy myself.  If I'm going to spend my time doing things I don't like, I can certainly make more money doing it.  Life's too short.”

I’ve received several responses along those lines, but few as simply stated. 

Microsoft and I talked a lot about this before I accepted their offer to work on Windows Live.  I wasn’t interested in becoming a VS lackey or in building interesting stuff that only works in a trivial fraction of the browsers, PCs, or development tools found in the wild.  Fortunately, neither is Microsoft's Windows Live Platform team.

As always with Microsoft, this is a platform play, but this time the platform at stake isn't the client OS or browser or dev tool stack;  it's the architecture and ecosystem of the next generation of rich Internet services that are at stake.  And, perhaps learning from past lessons, Microsoft appears to be putting wheels in motion so that the services available through this ecosystem are not exclusive to Microsoft. 

That's the task of the Windows Live Platform team, my team:  to expose and coordinate service APIs that can be used from virtually any toolset on any platform that supports modern standards.

A lot of this direction came out at MIX06 last month.  Microsoft-watch has a synopsis of the MIX06 keynote by Brian Arbogast (my boss's boss), including data points such as:

Users must be in control of their own data at all times, Arbogast said. Windows Live services should be designed to support any platform, browser, language or device, and Windows Live services should make use of simple, standards-adherent HTTP-based application programming interfaces, he added.

You can also download the slides from Arbogast's MIX06 keynote yourself.

The big question is how to monetize it.  Injecting ads into third party apps that use these services is obviously a bad idea.  Charging for high-volume use of the services is the most likely route IMO.  Microsoft knows that they can't charge high fees at the door because then nobody will even try it.  I’m hoping for something with a free entry point and fees that scale with volume – something that I would be interested in dabbling with on my own hobby websites at a price point appropriate to noncommercial dabbling (free or nearly free). 

Arbogast's MIX06 slide #6, API Philosophy sounds like it will cover the low cost entry point rather well.

To successfully launch and grow an ecosystem, Microsoft knows that it has to attract people who are not in the Microsoft OS camp, nor in the Microsoft tools camp, nor in the IE browser camp.  “Attract” doesn’t mean force them to install Microsoft product, it means getting them interested in using the services infrastructure in whatever context they’re comfortable with.  “People” here means not just developers to write apps that use services in interesting ways, but also users who demand apps that integrate with the services they want to get the experiences and conveniences users want. 

The JavaScript gadgets over on live.com and microsoftgadgets.com run in the major browsers.  The communications protocols to talk to the Live services are all built on simple standards - http and REST.  SOAP is called upon for heavy-lifting scenarios, but REST is much, much simpler to use and covers most of the API use scenarios we need to enable.

Our source code demos for connecting to and using Windows Live services in custom apps will need to show .NET code as well as Win32 code, client-side JavaScript, Windows Vista WPF as well as DHTML, Linux code, python and perl, and so forth.  Hell, I may have to write an MSDos batch file demo just to make a point.  ;>

Comments