Is Microsoft serious?

---

Recently I received a press announcement from Waggener-Edstrom, Microsoft's PR company,
about their latest move in the interoperability space; I reproduce it here in its
entirety for your perusal:

Hi Ted,

Microsoft is announcing another action to promote greater interoperability, opportunity
and choice across the IT industry of developers, partners, customers and competitors. 

Today Microsoft is posting additional documentation of the XAML (eXtensible Application
Markup Language) formats for advanced user experiences, enabling third parties to
access and implement the XAML formats in their own client, server and tool products. 
This documentation is publicly available, for no charge, at http://go.microsoft.com/fwlink/?LinkId=113699 . 

It will assist developers building non-Microsoft clients and servers to read and write
XAML to process advanced user experiences – with lots of animation, rich 2D and 3D
graphic and video. Specifically, non-Microsoft servers can more easily generate XAML
files to be handled, for example, by applications running on Windows client machines. 
In addition, non-Microsoft clients can be written more easily to interpret XAML files. This
action will assist ISVs in creating design tools and file format converters to read
and write XAML to create advanced user experiences.

Microsoft is making this documentation available under the Microsoft Open Specification
Promise (OSP), which will allow developers of all types anywhere in the world to access
and implement the XAML formats in their own client, server or tool products without
having to take a license or pay a fee to Microsoft.

The following quote is attributable to Tom Robertson, general manager, Interoperability
and Standards, Microsoft.

“Microsoft’s posting of the expanded set of XAML format documentation to assist third
parties to access and implement the XAML formats in their own client, server and tool
products will help promote interoperability, opportunity and choice across the IT
community.  Use of the Open Specification Promise assures developers that they
can use any Microsoft patents needed to implement all or part of the XAML formats
for free, anywhere in the world, now and in the future.” 

Please let me know if you have any questions or if I can provide you with any additional
information. 

Best,

N--

This marks the most recent in a slew of efforts by the Borg of the Pacific Northwest
to "promote greater interoperability, opportunity and choice", and I know it's left
a lot of people feeling decidedly skeptical and... well, let's just call it what it
is, paranoid, about the company's plans and ulterior motive behind all these
efforts. After all, this is the company that tried to co-opt Java, put Stacker out
of business, used their monopoly operating system power to crush Novell, used their
monopoly office suite power to crush the Mac, bribe an entire country to vote their
way on the new office-file specifications, and I don't know what all else.

I know, I know, all my blog-readers who work at Microsoft are going nuts right
now, protesting, claiming that this isn't the same company that they work for now,
and so on. Fact is, folks, if you work at Microsoft, you work for a company whose
name is not well-received in many quarters, and while some of it is undeserved...
some of it is. Microsoft has done some pretty stupid things in its history, and if
that reputation doesn't sit well with you now, I can't help but wonder if somewhere
in that great Corporate Heaven, Stac Electronics isn't just jumping up and down, foaming
at the mouth and screaming, "Ha! Serves you right!"

I don't want to use this blog as a chance for everybody who ever got burned by Microsoft
(or thought they got burned by Microsoft, which is much more widespread and
just as much more likely to be in their own minds) to trot out "reap and sow" cliches.
Instead, I want to revisit one of my favorite topics, that of interoperability, and
see exactly what this new shift in Microsoft's attitude towards interoperability really
means.

Let's take these one at a time. Note that I have no "Deep Throat" at Microsoft feeding
me "the Redmondagon Papers"; this is all based on my own conjecture and perspective.

What does releasing the XAML spec really mean?

Honestly, it means that now non-Microsoft platforms can try to create competitors
to Aero and Windows Presentation Foundation, and have the same kind of rich client
experiences that Windows users can enjoy.

Honestly, I expect this to go pretty much nowhere.

Realistically speaking, if a non-Microsoft app server wanted to generate XAML, it
was a simple matter of generating the appropriate XML, tagging it with an appropriate
MIME type in the HTTP header, and serving it up over an HTTP request; I've been giving
this demo at conferences for three or four years now, pretty much since the first
betas of WPF were stable enough to use. This really isn't rocket science.

But more importantly, XAMl has always been misunderstood: it's not a presentation
format, it's an object graph format. XAML simply "wires up" a collection
of objects into a tree, and it's the underlying object model that provides the functionality
or power or presentation or whatever. It's an easier way of writing "Button b = new
Button(...);", nothing more, nothing less. Sure, it would be nice to have some kind
of equivalent for the Swing space, but doing so would tie the corresponding XML (XSML?)
to the Swing APIs, just as WPF XAML is tied to the WPF API.

Does releasing the XAML specs mean that now Linux and Mac OS will get WPF features?

They've had them for years, in the guise of the OpenGL APIs, and nobody knew what
to do with them, except maybe for a sliver of folks building games and interesting
"effects". Unless somebody really feels the desire to try and create an adapter layer
to map the WPF Button over to an OpenGL button, I really don't see much point.

This is one of the most dangerous points in the discussion: attempting to build an
adapter to another platform's API is almost always a failed experiment from the day
it's begun, and Microsoft's own attempt to port the MFC APIs over to the Mac OS (back
in the pre-OS X days, circa 1995) were just a miserable, abject failure. Not because
of any lack of intelligence on Microsoft's part, mind you, but because the two operating
systems are just too different. Want to see what I mean? Bring a Mac guy and a Windows
guy into the same room, and ask them each where God intended the menu bar to live.

Then creep, quietly, out of the room, before you get caught in the blood frenzy.

Why does Microsoft suddenly care about interoperability?

This is the crown jewel of the lot: why should this company, so famous for going it
alone on so many issues, suddenly decide that it's important for them to embrace the
other kids on the playground and make nice? Is this back to the "embrace" part of
the "embrace and extend and extinguish" cycle that they're so famous for?

Partly.

To understand the point I am about to make, let's set some context.

(In other words, gather 'round, children, it's story time.)

Truth is, there was a time back there in the '90s when I think Microsoft really thought
they could take over the world. COM was on the ascendancy, and it was a better platform
for building software than anything else out there (at the time), particularly in
the area of building rich media applications (remember when embedding a sound clip
into your email message embedded inside your spreadsheet was all the rage?). The CORBA
initiative was going strong, true, but its great claim to fame was to allow two remote
processes to talk to one another--the rest of the CORBA "push" was in standards that
either never materialized, or else materialized but turned out to be really hard to
build, or use, or deploy, or all of the above. IBM's great competitor--SOM--wasn't
even in beta on anything other than OS/2 (another great IBM product). Then, when DCOM
shipped, it was seen by some as the final nail in the CORBA coffin; Microsoft clearly
was going to "win".

Along came Java.

Java literally took the rug out from underneath the COM platform, almost overnight.
It provided a platform with most of the same benefits as the COM/DCOM platform, but
without having to memorize the QueryInterface rules or knowing what IUnknown was or
how IDispatch was required to work or how static_cast<> and dynamic_cast<>
and QueryInterface were all related. ("Would you, should you, static_cast? Not if
you want your code to last..." Ah, those were heady days.) Suddenly, "mere mortals"
could program on this platform, and feel a strong sense of confidence that their code
would work, over time, regardless of whether they remembered to set references to
null when they were done with them.

At first, Microsoft was "down with it", because in Java they saw a great marriage:
the Java language as the "sweet spot" between C++'s expressive power and VB's layers
of abstraction, running on top of the JVM as a "sweet spot" intermingled with the
COM platform to provide the easiest, most powerful Windows programming environment
yet. Visual J++ was clearly the favored child of the litter.

And then the lawyers got involved, and Sun saw their chance to steal a march on Microsoft,
and maybe break the feared operating system monopolist, and maybe even get a few more
percentage points for Solaris (because, after all, "Write Once, Run Anywhere" meant
that you wouldn't have to run sucky operating systems like Windows and instead could
trade up to real operating systems like Solaris, right? Hey, where'd that
penguin come from, anyway, and why is he eating all our fish?). Sun refused to let
Microsoft's marriage of the JVM (technically the MSVM) and COM take place, and Microsoft,
rather than seek to fight it out, instead decided to cede the battle, and look for
a battleground of their own choosing, instead. Thus was the thing that would become
called ".NET" born.

But this "master plan" would take four or so years to develop, and in the meantime...

... in the meantime, EJB and Servlets and later J2EE and "app servers" and Spring
and all those wonderful things that came with them, they were eating Microsoft's lunch.
Comparing J2EE (even with EJB in the mix!) with the complexities of writing unmanaged
COM code on top of COM+ is simply no comparison--again, the power of the managed platform
simply proved to be too hard to turn away without compelling reason, and the COM/DCOM/COM+
story simply didn't have that compelling reason. Microsoft watched their "inevitable
victory" sail into the sunset without them, just as the Department of Justice came
up to them and shackled them with the first of many, many papers about "anti-competitive
practices".

In many respects, the positions got reversed--Sun inherited a huge share (an unhealthy
dose, in fact) of Microsoft's arrogance, and for a long time there, thought they were
suddenly destiny's child, that Java (meaning Sun, of course) would be the
one to "win", and thus would Sun's assurance of world dominance thus be assured.

Except it didn't play out that way.

Sun found that by embracing standards over implementations, they spent long hours
thrashing out specifications, only to provide instant credibility to other vendors'
products while their own languished. Weblogic stole the EJB early adopter window.
A number of small vendors provided servlet implementations before Tomcat was born...
which, although written by Sun employees, was an open-source project and yielded no
financial benefit. JMS... well, JMS was always the redheaded stepchild of the J2EE
family, at least until vendors like Sonic and Fiorano rescued it for the common Java
programmer. (Those who'd been using IBM MQSeries all the while never really could
see why you'd want to program against JMS APIs instead of IBM's own.) In each and
every case, Sun found their product to be the third or fourth entry into the race,
usually years after the others had started, and as a result....

Meanwhile, back in Redmond....

Microsoft comes to the game with .NET in 2003. (The early betas don't count because
many people openly wonder if Microsoft is really serious about this ".NET" thing in
the first place. After all, remember Microsoft Bob?) And despite .NET's obvious advantage
of being formulated nearly a decade after Java's initial release, thus able to apply
hindsight to fix or improve the obvious blemishes in the Java environment, Microsoft
finds that they're playing catch-up in the all-too-important enterprise space. Microsoft's
tools and products have always been seen as "second-class citizens" to the "big boys"
in the enterprise space, particularly at the ends of the "high scale" continuum, and
the lack of an obvious "app server" in the .NET arena only serves to underscore and
reinforce that opinion among many large firms.

More importantly, Microsoft doesn't ever want to get blindsided by the Java
experience again. They want to make sure that they are never in a position where it
looks like their tools are vastly out-of-date, underfeatured, underpowered, and underused.
They need to remain somewhere near the bleeding edge, but not so close that their
customers are the ones doing the bleeding.

(We pause for the inevitable Vista joke.)

To Microsoft, Java is that near-death experience that pulls many adrenaline (and other)
junkies back from the brink they so callously teetered on before. They need some kind
of forward progress, some kind of advancement in the game, so that their customers
and their would-be customers feel like Microsoft is on top of it at all times.

Result: Somewhere in the 2000-2003 timeframe, Microsoft looks around, sees the landscape,
and realizes it needs to make itself relevant to a largely J2EE-based universe, and
fast.

At first, Microsoft sees a play through the establishment of some standards between
the big vendors, around this new "XML" thing, a largely portable data format, and
so they throw themselves heart and soul into that space. Doing so will allow them
to show existing J2EE-based shops that the power of the .NET platform lies in complementing
the existing infrastructure, not replacing it. (Microsoft is smart enough to realize
that preaching the software equivalent of hellfire-and-brimstone, known as "rip-and-replace",
will not cater well to this congregation.)

(Rubyists could have learned a valuable lesson here, but either weren't paying
attention, didn't realize the value of the lesson, or else just chose not to.)

But this play doesn't turn out the way they expect: the WS-* standards become top-heavy,
and start to resemble the very thing Microsoft sought to smash fifteen years earlier:
CORBA. The number of WS- specifications available through the W3C (and OASIS, and
WS-I and whatever other industry consortiums are formed) is exceeded only by the number
of Cos- specifications available from the OMG. The complexities therein leave many
Java--and .NET--programmers confused, bewildered, and hopelessly lost when trying
to get all but the most simple services to work. Thus does the community turn to alternatives--JSON,
simple sockets, REST, whatever--to try and find something that works, even if it only
addresses a subset of the problems they will eventually face.

Meanwhile...

Open source grows ever more important, and Microsoft-the-company realizes they have
to either kill it or join it. It's hard to kill something that has no body (unlike
their previous competitors), so joining it is the only viable option. Unlike many
other software product companies, however, Microsoft has too large an established
software base to just "flip the switch", and has far too deeply entrenched a corporate
community to take any kind of radical action without a well-thought plan. (Wall Street,
a place few programmers ever bother to consider, much less visit, would not take kindly
to Microsoft essentially giving away their core product without something in its place
to generate revenue, and regardless of how many programmers would like to imagine
a world with a bankrupt Microsoft, this would be bad for business for everybody.)

And thus do we come to the present.

Microsoft needs a play that is Wall Street friendly, programmer friendly, and corporate
friendly. They are slowly flirting more and more deeply with open source, yet still
firmly committed to turning a profit (something a few of these other open-source-based
companies should probably learn to do at some point--just maneuvering to the point
of being bought out by a larger fish, like Oracle, is not really a long-term competitive
strategy, just so you know).

Microsoft wants--arguably, needs--to keep Office relevant in a world where
software isn't always paid for, so they need a play that keeps Office ubiquitous and
out in the forefront of developer mindshare. If they can't get you to buy Office,
then at least let's get you to use tools that keep the Office file formats ubiquitous.
If (and this is a big "if") the Office formats turn out to be technically superior
to their competition, then Microsoft succeeds. If not, they find a new play.

In the short, Microsoft needs an interoperability story, and they need a real interoperability
play, because their reputation is damaged from the many "embrace, extend, extinguish"
plays they've made in the past. The era of a large vendor "winning" is clearly well
behind us (if it was ever, in fact, more than just a marketing VP's wet dream), and
if Microsoft is going to make sure that they're never in a vulnerable come-from-behind
position again, they need to make sure that they can work well with all the other
new technologies out there, whether up-and-coming or well-established or even fading-fast.
They need to have an interoperability story that developers can believe in, which
means some kind of open-source-friendly play, and one that carries serious "street
cred" for actually working.

What's the lesson that I, a developer, take away from this?

If you are a Java developer, get past your old prejudices and accept that
.NET is a viable platform. The Java developer who refuses to learn how to write C#
code on the grounds that "Micro$oft is a company that just puts out crap" or that
"M$FT sux" is going to be a Java developer whose value to the business is reduced
compared to those with less virulent politics. Thanks to tools like VMWare and Virtual
PC, you don't have to give up your Mac or your Linux environment to write .NET code
and prove that you can offer value to those projects that need to talk to .NET. Look
into more than just the WS-* or REST stacks for communication, as well; explore some
of the interoperability options I've been ranting about for four years, a la IKVM,
Jace, Hessian, even CORBA.

If you are a Ruby developer, get over yourself and your "we're more agile
and more powerful" meme. Ruby is a tool, nothing more, and one whose shine is fast
coming off. IT organizations are discovering the myriad problems with the original
Ruby runtime, and are unwilling to risk enterprise apps on a runtime that has zero
monitoring and zero manageability play. Yes, you can certainly do lots of things yourself
to make your Ruby apps more manageable and more monitorable--but that's all time you
have to spend building it, or figuring out how to hook it into the existing IT infrastructure,
and when all that time gets added up, it's not going to look all that different from
a Java or .NET app's timecycle arc. If you don't have an answer to the question, "How
will we make this work with the existing infrastructure we've got?", then you have
a problem, and no amount of chanting "Obi-Dave Thomas-Kenobi, you and dynamic typing
are my only hope" will save you.

If you are a .NET developer, it's high time you accepted that the Java folks
are about five years ahead of you on this "managed code" arc, and that they suffered
through a lot of hard lessons before arriving at the decisions they came to. Don't
be stupid, learn from their mistakes. Why do Java programmers chant "dependency
injection" with holy fervor? Why do Java programmers put so much stress on unit testing?
What has Microsoft not given you with the latest release of Visual Studio
that Java developers think you're an idiot for not demanding in the next release?
Yes, C# has some interesting new features in it that Java-the-language doesn't have...
but why are the Java guys getting all misty-eyed over Groovy? What do they know that
you don't?

If you are a developer outside of these areas, you're swimming in dangerous
waters, because while I'm sure you're not having any problems finding a job, chances
are your next job is going to require you to talk to one of those three environments.
Better have your integration/interoperability story worked out, whether its Phalanger
for the PHP developer who needs to talk to .NET (and damn if PHP script driving a
WinForms app isn't an interesting idea in of itself... and a useful way to bridge
yourself into an entirely new area of employment), or its figuring out how to apply
your mad Haskell skillz to F# or Scala, you need to have a good idea of what those
languages are (and aren't) and how your knowledge of functional concepts can catapult
you to the head of the class the next time a massively-scalable system needs to be
built.

If you are a Microsoft employee, don't blow this. Don't make this into another
"embrace, extend, extinguish" cycle. Accept that your company made some bone-headed
maneuvers in the past, and rather than try to defend them, accept that your reputation
outside of the Redmond Reality-Distortion Bubble is not what it looks like
from the inside. As hard as this will be to do sometimes, just stop and listen to
what others are saying about the company and the paranoia that creeps up every time
Microsoft moves into an area of interest. Take the extra moment to hear the concerns,
not just the words.

And if you are a Google employee, tatoo this on your forehead: Reputation
Matters. The first time anybody at your company does something even remotely "evil",
you will be branded as "the next Microsoft" and all of these problems will be yours
to share and enjoy, as well.

---

Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services.
1-day or multi-day workshops available. Contact
me for details.