So says Spolsky, in a rant about both unwanted mega-architectures, and the way big companies snaffle up all the best coders.
Is he right? Well, I attended the Hailstorm PDC in 2001 and I still have the book that we were given: .NET My Services specification. There are definitely parallels, not least in the marketing pitch (from page 3):
.NET My Services will enable the end user to gain access to key information and receive alerts about important events anywhere, on any device, at any time. This technology will put users in total control of their data and make them more productive.
Swap “.NET My Services” for “Live Mesh” and you wouldn’t know the difference.
But is it really the same? Spolsky deliberately intermingles several points in his piece. He says it is the same stuff reheated. One implication is that because Hailstorm failed, Live Mesh will fail. Another point is that Live Mesh is based on synchronization, which he says is not a killer feature. A third point is that the thing is too large and overbearing; it is not based on what anyone wants.
Before going further, I think we should ask ourselves why Hailstorm failed. Let’s look at what some of the people involved think. We should look at this post by Mark Lucovsky, chief software architect for Hailstorm and now at Google, who says:
I believe that there are systems out there today that are based in large part on a similar set of core concepts. My feeling is that the various RSS/Atom based systems share these core concepts and are therefore very similar, and more importantly, that a vibrant, open and accessible, developer friendly eco-system is forming around these systems.
Joshua Allen, an engineer still at Microsoft, disagrees:
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 …. the “principles” Mark’s blog post cites are actually principles of the technologies Hailstorm aimed to replace.
but as Allen shows in the latter part of his post, the technology was incidental to the main reasons Hailstorm failed:
- 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.
- Hailstorm was to be based on proprietary, patented schemas developed by a single entity (Microsoft).
- 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.
Hailstorm’s technology was SOAP plus Passport authentication. There were some technical issues. I recall that Passport in those days was suspect. Some smart people worked out that it was not as secure as it should be, and there was a general feeling that it was OK for logging into Hotmail but not something you would want to use for online banking. As for SOAP, it gets a bad rap these days but it can work. That said, these problems were merely incidental compared to the political aspect. Hailstorm failed for lack of industry partners and public trust.
Right, so is Live Mesh any different? It could be. Let me quickly lay out a few differences.
- Live Mesh is built on XML feeds, not SOAP messaging. I think that is a better place to start.
- Synchronization is a big feature of Mesh, that wasn’t in Hailstorm. I don’t agree with Spolsky; I think this is a killer feature, if it works right.
- Live Mesh is an application platform, whereas Hailstorm was not. Mesh plus Silverlight strikes me as appealing.
Still, even if the technology is better, what about the trust aspect? Will Mesh fail for the same reasons?
It is too soon to say. We do not yet know the whole story. In principle, it could be different. Mesh is currently Passport (now Live ID) only. Will it be easy to use alternative authentication providers? If the company listens to its own Kim Cameron, you would think so.
Currently Mesh cloud data resides only on Microsoft’s servers, though it can also apparently do peer-to-peer synch. Will we be able to run Mesh entirely from our own servers? That is not yet known. What about one user having multiple meshs, say one for work, one personal, and one for some other role? Again, I’m not sure if this is possible. If there is only One True Mesh and it lives on Live.com, then some Hailstorm spectres will rise again.
Finally, the world has changed in the last 7 years. Google is feared today in the way that Microsoft was feared in 2001: the entity that wants to have all our information. But Google has softened us up to be more accepting of something like Live Mesh or even Hailstorm. Google already has our search history, perhaps our email, perhaps our online documents, perhaps an index of our local documents. Google already runs on many desktops; Google Checkout has our credit card details. What boundary can Live Mesh cross, that Google has not already crossed?
Hailstorm revisited is an easy jibe, but I’m keeping an open mind.
Agreed 100%; I reacted to his comments about sync not being mainstream: http://twitter.com/allenjs/statuses/801281831. There are still some challenges to the cloud platform, and Joel made some good points, but I think you are spot-on.
The current build handles peer-to-peer sync quite oddly (though Ori’s version at Web 2.0 did things differently, so I suspect things will change). At the moment you can only sync peer-to-peer if you have the same folder on the Mesh desktop – so you can’t sync anything bigger than the 5GB Mesh Desktop space limit…