Simple Object Apology Protocol? Are we, maybe, moving an itsy bitsy bit too fast here?

I just read David Ing's post on Simple Object Apology Protocol.

He's got some interesting ideas there, but some of his conclusions seem to be based on some serious hand-waving.   One excerpt:  

I think the 'mistake' of the Indigo cycle was trying to move a certain way (strong typed contracts and the stack of specs on top that go with them) in advanced of what people were wanting to use at that time. There was a lot of faith that tooling would ease the complexity concerns and it looks like it didn't pan out for enough people.
...
While some areas of software can be truly good new ideas, that should be pushed at people to show them a better way to do something, in the area of 'software talking to software' it seems particularly fraught to do something that isn't being begged for upfront.

Now that is an interesting question: where should a vendor draw the line between supporting "what people really want" versus delivering something innovative that pushes the envelope?  Christiansen's book "The Innovator's Dilemma" has some insight here. A vendor in any industry that only follows the trends is liable to become an endangered species.  On the other hand, it is possible to get out ahead of the market, too.  Answering this question well always results in a delicate balancing act. 

As for the statement "[WCF] looks like it didn't pan out for enough people."  First, it's a pretty fuzzy statement, so it is hard to discuss it concretely.  What does "pan out" mean anyway?  But int he spirit of open discussion we'll assume this means "it's not really being used very often."  Or maybe "it's not being adopted as fast as people thought it might."  Are those statements true?  Honestly, at this point there is no answer to that question.   Actually, I don't even think it is valid to guess at this point.

Let's look at some history.  When it was introduced in February 2002, the .NET Framework was arguably the first broadly-accessible toolkit that could do web services simply. Part of its success came from the utility in Visual Studio 2002.   Since that time, there have been other toolkits and tools made available with perhaps similar ease-of-use.  And, since then, we've seen a steady adoption of .NET and separately, a steady increase (a "democratization") in the use of web services.  We measure these things with worldwide surveys that we conduct repeatedly, over a long period.  So, two things:  It didn't happen suddenly.  And the combination of tools+frameworks made it possible. 

Let's lay those 2 things on top of WCF ("Indigo").  WCF was first made available in December 2006.  Whoa!  Five whole months ago.  And, the release of WCF did not accompany a release of Visual Studio with an additional set of design experiences for WCF apps.  In other words, the tools lag the framework, currently.    Is it time to conclude now that "WCF didn't pan out" ?    Ummmmmmmm..... Obviously that is a matter of opinion.  Mine is that it is a wee bit too early to make that statement.   

For Microsoft, WCF and the model it promotes (contracts, messages, etc) is a fundamental piece of infrastructure. Interop is absolutely better and easier when using WCF.   We'll reserve judgement on whether "it panned out" until we release better tools, and until a few more years have passed.