Requiem for Silverlight

There are some products that appear to have been doomed to circumstance since birth – that despite the most ambitious goals, the grandest intentions, and often the wildest strokes of luck, still manage to end up on the wrong side of public perception. No more prominent example exists in the history of software than Microsoft Silverlight, a textbook case of a platform that was never, for one moment, given the benefit of a doubt.

It did not help that its original title, circa 2006, was “Windows Presentation Foundation / Everywhere” (WPF/E), which sounded like the catch-phrase for a neoconservative protest movement. And it really didn’t help that its producer had attained a reputation for defining the Web by default, building less-than-ideal browsers and technologies and broadcasting them into ubiquitousness by tying them to Windows.

But Microsoft was out of get-out-of-jail-free cards, having worn out its welcome with Web developers with the disaster that was ActiveX. Silverlight was a double-down bet on the idea that if a technology were made accessible enough, and its performance were respectable enough, developers would adopt it because they wanted to, not because they were locked into the decision.

What it is, and what it was

It is a piece of the .NET Framework, the managed code technology upon which a great deal of distributed functionality in the enterprise depends today. (Yes, I understand the implications of the verb “depends” in this context.) Essentially, Silverlight is just enough of WPF to make a distributed application functional, and respectably so, inside or outside of the browser. It does leverage other Microsoft technology, which should never surprise anyone. Although it was programmable from the beginning using JavaScript (which Microsoft stopped calling “JScript” some years back), its principal programming language starting with version 2.0 was C#, Microsoft’s own take on object-oriented C.

Microsoft’s prior behavior mandated that Silverlight (as well as every other tech campaign from the company) should be watched with skepticism and caution. The situation that any developer should work to avoid is one where the best method for solving a problem is only attainable through a single vendor’s product. Imagine if, for example, the best way for an individual to find content, or the most attainable way for content producers to monetize their product, or the most available way to advertise that content, were through a single vendor. Why, the “open Web” would be impossible!

An early demo of a Silverlight app running on Mac OS X, from June 2007 TechEd.

That Silverlight was, to be blunt about it, not really an innovative new method but rather an alternate approach (and arguably a better one, in several respects) to a method addressed by a completely different vendor more than 90% of the time, did not seem to quell the conspiracy theorists. From moment one, Silverlight was pegged as Microsoft’s latest tack toward its old strategy of vendor lock-in – a principle eschewed by Web developers in much the same way Congressmen openly abhor pointless bickering.

Life in the margins

For such a tack to succeed in a market that was seeded against it, Silverlight needed a sign of faith from its executive leadership. It never really got it. CEO Steve Ballmer continually downplayed Silverlight as something that was nice, maybe interesting, but not critical to the company’s strategy. There were times Ballmer publicly demonstrated he knew less about the product than I did. In June 2010, he told an audience that Silverlight does not run on the iPhone, thanks to Apple. This was eight months after Microsoft gave me the first demonstration of Silverlight on iPhone, which its product manager told me was only possible on account of Apple’s direct cooperation and participation. Granted, it was never downloadable through iTunes, but after Ballmer’s little demonstration, you have to ask yourself just whose fault that was.

The problem with adopting openness as your mantra is that you must become open to that to which you’re closed. Silverlight is where, astonishingly, Microsoft succeeded and its detractors miserably failed. Rather than swallow the notion that good ideas can emerge from the “wrong” sources, some accused Moonlight of no less than “actively undermining our freedoms”, of effectively brainwashing users, of orchestrating a real-world “Invasion of the Body Snatchers” with some names you’ll recognize serving as Microsoft’s shovels, rakes, and implements of destruction.

For a few years, Microsoft’s work on Silverlight development was fast and furious, and Moonlight raced to catch up. As a result, there no longer appeared to be a devious conspiracy by Microsoft to inject Silverlight into Linux. Mono, the project to which Moonlight belongs, adopted Windows itself as one of its supported platforms, thereby nullifying the very possibility of vendor lock-in that Silverlight had earlier been accused of enabling. Yet almost immediately, the extent to which Moonlight had not yet caught up with Silverlight was called out as a devious conspiracy by Microsoft to withhold Silverlight from Linux, an effort to engineer a new garden wall for vendor lock-in, where Linux would always be one step behind.

Course correction

The emergence of Windows Phone, which should have begun Silverlight’s ascendency into ubiquitousness, instead launched its downward spiral.

In January 2010, Microsoft launched a parallel course for its mobile OS strategy, literally issuing a correction to its own statements about a future “Windows Mobile 7,” in a plan to make reporters ask about what Microsoft meant by “the future of mobile” to give it just the right opportunity to answer. Microsoft then demonstrated that Silverlight developers could build WP7 apps using the XAML resource management language they already learned for the PC. This was the first indication that Microsoft was working on a cross-platform development strategy for PC and mobile.

And what is this strategy shift about? The move by Windows 8 to WinRT is an overt, intentional effort by Microsoft, as the company freely admits, to march developers away from Silverlight, and toward an altogether new and untried apps ecosystem. That such an ecosystem was technically feasible with Silverlight was never questioned.

But if technical feasibility were the single benchmark for the viability of all Web technologies, today you would not be reading this single-column blog with a long, long scroll bar through a browser that delivers content from multiple sources using an unsecured, stateless protocol. Put another way, if all it took was to make technologies work well, the Web as we know it now wouldn’t even be here.

Leverage

For Microsoft to remain competitive through the rest of this decade, it must produce a mobile platform that customers want more than any other platform. Right now, it does not. Microsoft’s product development has always, always depended on leverage. It builds new platforms on existing ones. When Microsoft first shifted its Windows Mobile strategy to Windows Phone, it was with the idea that Silverlight might be the link that lets its mobile platform leverage its successful and substantive Windows platform. But that is not enough.

Recently, there has been active speculation that Microsoft may want to converge some elements of its Windows PC and Windows Phone platforms, perhaps just enough to enable certain classes of apps to run on both. This brings up the musical question… Duh! For Windows Phone to make sense as a Windows brand, it needs apps that cross the boundaries of Microsoft’s “four screens” (formerly three). If Windows Phone fails, conceivably Microsoft will fail, entirely. Certainly the many carriers whose faith and support are necessary to make Microsoft’s plan work, would not be satisfied with Silverlight as the leverage point for tying PC to Phone.

The notion that carriers may have nixed this earlier, Silverlight-dependent leverage scheme, as it was presented in late 2009, would explain why Microsoft’s strategy shift was so sudden, so inconsistent with its past and, thus far, so indeterminate with respect to the future. The leverage point must go both ways now; what we see on PC now must borrow more concepts from Phone, in order for the mobile platform to attain the subsidies it needs to be successful. In what many are calling the “post-PC era,” this could be the first instance where carriers are effectively dictating the content of our personal computers.

If that is indeed the case, as I strongly suspect, then there would be no more prominent an indicator that Microsoft no longer dominates computing than the incursion by wireless carriers into its once-sacrosanct PC strategy. That Silverlight should be relegated to a side note on account of a platform leverage strategy, would be a sad and ironic fate for a good technology that, for the duration of its life, was suspected by many of being a platform leverage strategy.

Related Posts

The TweetSentiments.com API is now open to any developer interested in using Twitter for sentiment analysis. Brand monitoring is the most obvious application, but I’m sure a few of you will come up with more creative uses for the API. So far, only three calls are available. More information on how to use the API is available…

Chrome Extension developers that want to add synthesized speech to extensions and Chrome-packaged apps are in luck. Google announced a new Text-to-Speech API for Chrome extensions yesterday, with examples and two sample voices.

According to Google engineer Dominic Mazzoni, a few hacks have enabled text-to-speech already. This involves tricks like…

Have you ever felt like your household appliances are watching your every move and conspiring amongst each other? No? Oh well, I guess that’s just me. It’s exactly what European researchers are hoping to enable though, by building a data sharing service called RoboEarth that automated devices can use to share information between themselves.

When you are writing Web applications it is easy to be terse, obtuse or just plain devoid of reasonable text that conveys what a user is expected to do. Worse, a support page or even the humble README can leave fellow developers wondering what you were thinking or drinking. As with any problem, the solution involves more…