Better Living through Software

For some reason I never saw this MarkL post on Hailstorm when he posted a year and a half ago.

Wow.  It’s amazing to me that 5 years later, there is still such a huge disconnect between the way the Hailstorm/Win32 people write history, and the way the rest of us saw it.  Thank God (and Eric Bina) that we have a web where anyone can correct the record and preclude skewed accounts of history from becoming de-facto.

Mark goes to great lengths to challenge the notion that Hailstorm was a failure.  To do this, he explains that “others are successfuly shipping the essence of hailstorm”.  The first commenter to his post says, “RSS+Script+OWA seems a lot like Hailstorm”, and Mark replies “Interesting that you noticed the same similarities as I did”.

I am picking my jaw up off the floor.  All of these technologies predate Hailstorm by a long shot.  There is a reason they succeeded where Hailstorm failed.  It’s because Hailstorm failed to adopt their essence; not because they adopted Hailstorm’s essence.

Many of the people who started up the Hailstorm team were former Win32 and OS people with very little knowledge of the web and prior art.  So it’s understandable if they had that opinion.  In fact, I remember one interview with a pre-Hailstorm team (I got the job) where I was told “RSS is a load of crap, it will never amount to anything.”  ASP 1.0 classic was the first application server to popularize REST programming, but we were already happily abandoning that by the time Hailstorm came about.  We were moving toward VB-style callbacks in the web app server, and Hailstorm was more about porting Tibco to the web than about REST.  (And the idea that the web was based on REST is another piece of revisionist history).

I’m not criticizing the Hailstorm team for being ignorant of web architecture and prior art.  After all, anyone with expertise in web architecture was working for dot-coms at that point, and there weren’t many web people at the company.  When BillG did his “Universal Canvas” thing, a lot of people with “other” skills were jazzed up and wanted to contribute.  The Hailstorm team was formed; and eventually it bacame a magnet for the web people who hadn’t jumped ship.  Most of the IE team moved over, most of the OWA team, and the MCIS people.  Eventually, there were a lot of people with web architecture expertise on the team, but it was still led by people trained in OS platform thinking.

So, considering that the “principles” Mark’s blog post cites are actually principles of the technologies Hailstorm aimed to replace; what exactly was unique about Hailstorm?

1. Hailstorm intended to be a complete, comprehensive set of APIs and services ala Win32.  Everything — state management, identity, payments, provisioning, transactions — was to be handled by Hailstorm.
2. Hailstorm was to be based on proprietary, patented schemas developed by a single entity (Microsoft).  Sure, other service providers could plug into the ecosystem, if they wanted to take a subordinate role, and give up control of their own destiny.  It was the same as being a TAPI or MAPI provider, only harder.  Pretty gutsy, considering we didn’t even have a developer base to entice platform providers.
3. All your data belonged to Microsoft.  ISVs could build on top of the platform (after jumping through all sorts of licensing hoops), but we controlled all the access.  If we want to charge for alerts, we charge for alerts.  If we want to charge a fee for payment clearing, we charge a fee.  Once an ISV wrote on top of Hailstorm, they were locked in to our platform.  Unless we licensed a third party to implement the platform as well, kind of like if we licensed Apple to implement Win32.

Let’s contrast that with the web that outlasted Hailstorm.  Today I can spin up a site using PHP or ASP.NET as I prefer.  I can use some simple JavaScript to syndicate RSS content to the site.  I can sell things via Amazon affiliates through the magic of JavaScript and iframes.  I can add Paypal payments effortlessly, using JavaScript (yes, this was possible when Hailsorm was conceived).  I can stick adsense on my content pages.  I can mashup gadgets from various sources.  No vendor lock-in.  Almost no API lock-in.  No crazy schemas.  No SOAP clients to install.  No need to fire up Visual Studio.  It’s the opposite of Win32.

Of course, MarkL points out that some demos worked without installing SOAP stacks, and could use a “crude XML parser”.  I’m having visions of Mark Pilgrim and his RegExp parser for XML (and ignore the DTD attacks and VML hacks).  There is a reason JSON is getting popular again (Whee!  IronPython on .NET!!)  Again, not to criticize, but we were kind of naive back then, and a couple of demos don’t prove anything.  Sorry.

As Tren Griffin says, moats like the Win32 platform tend to work only once or twice.  Then people have “seen that movie” and they steer clear the second time around.  Even if you explain to them that Win32 was “for your own good”, they seem to have an irrational aversion to platform lock-in.  The web has shown a remarkable recalcitrance to being locked in anyone’s trunk.  The new war is about all the things Ray Ozzie talks about; it’s not Win32 OS Platform wars v2.

In fact, I am sure MarkL has already learned those lessons, and is unlikely making the same mistakes at Google.  And it’s understandable if the Win32 soldiers see RSS+Scripting+OWA as “implementing the essence of Hailstorm”.  But those of us who saw a different side of the history have an obligation to weigh in and provide a more complete picture “for the children”.

This entry was posted on Wednesday, September 20th, 2006 at 7:36 pm and is filed under Life at Microsoft, signifyin. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.