If Microsoft is serious about Silverlight, it needs to do Linux

Today was a significant event for the UK broadcasting industry: the announcement of YouView, formerly called Project Canvas, which is backed by partners including the BBC, ITV, Channel 4, Channel 5, and BT. It will provide broadcasts over IP, received by a set top box, include a catch-up service, and be capable of interactive features that hook into internet services.

Interesting stuff, though it may end up battling with Google TV. But what are the implications for media streaming services and media players? One is that they will have to run on Linux, which is the official operating system for Project Canvas. Google TV, for that matter, will run Android.

If you look at the YouView specifications, you’ll find that although the operating system is specified, the application player area is more open:

Application Player executables and libraries will be provided by 3rd party software vendors.

What is an application player?

Runtime environment for the execution of applications. Examples are Flash player, MHEG engine, W3C browser

I’d suggest that Adobe will do well out of YouView. Microsoft, on the other hand, will not be able to play in this space unless it delivers Silverlight for Linux, Android, and other open platforms.

Microsoft has a curious history of cross-platform Silverlight announcements. Early on it announced that Moonlight was the official Linux player, though in practice support for Moonlight has been half-hearted. Then when Intel announced the Atom Developer Program  (now AppUp) in September 2009, Microsoft stated that it would provide its own build of Silverlight for Linux, or rather, than Intel would build it with Microsoft’s code. Microsoft’s Brian Goldfarb told me that Microsoft and Intel would work together on bringing Silverlight to devices, while Moonlight would be the choice for desktop Linux.

Since then, the silence has been deafening. I’ve enquired about progress with both Intel and Microsoft, but vague rumours aside, no news. Silverlight is still listed as a future runtime for AppUp:

Microsoft® Silverlight™(future)

Silverlight is a cross-browser, cross-platform and cross-device browser plug-in that helps companies design, develop and deliver applications and experiences on the Web.

In the meantime, Adobe has gone ahead with its AIR runtime, and even if Silverlight eventually appears, has established an early presence on Intel’s netbook platform.

There have been recent rumours about internal battles between the Windows and Developer divisions at Microsoft, and I cannot help wondering if this is another symptom, with the Windows folk fighting against cross-platform Silverlight on the grounds that it could damage the Windows lock-in, while the Developer team tries to make Silverlight the ubiquitous runtime that it needs to be in order to succeed.

From my perspective, the answer is simple. Suppressing Silverlight will do nothing to safeguard Windows, whereas making it truly cross-platform could drive adoption of Microsoft’s server and cloud platform. When Silverlight was launched, just doing Windows and Mac was almost enough, but today the world looks different. If Microsoft is serious about WPF Everywhere, Linux and Android (which is Linux based) support is a necessity.

VN:F [1.9.18_1163]
Rate this post
Rating: 9.7/10 (6 votes cast)
If Microsoft is serious about Silverlight, it needs to do Linux, 9.7 out of 10 based on 6 ratings

Related posts:

  1. Silverlight is released for Windows, promised for Linux
  2. Microsoft brings Silverlight – not Mono – to Linux via Intel
  3. Silverlight on Linux: Moonlight or moonshine?
  4. Mono may implement Silverlight for Linux
  5. Silverlight (and AIR) for MeeGo Linux coming in October?

9 comments to If Microsoft is serious about Silverlight, it needs to do Linux

  • I wonder how a very large company like Microsoft makes a strategic decision like that – especially if they perceive that direct revenue from Silverlight on Linux would be vanishingly small in comparison to the expense. Even deciding to ignore the question is a decision of sorts…

  • Phillip

    Three questions:
    1) Are software developers for embedded devices (what set top boxes basically are), willing to change their tool chain to include Yet Another Tool, when, say, Flash or a GStreamer wrapper will do?

    2) Will these set top boxes be compatible enough to each other, that creating a Silverlight runtime is worth while, and cost effective? If you have to create a specialized variant (even if it’s just another build with other options: That has to be tested, too) for each and every possible iteration of embedded Linux and set top box hardware, the cost can get out of hand.

    3) Will these set top boxes shift enough units to warrant any sort of investment?

    It looks like MS is positioning Silverlight more as a “Flash for the intranet” solution, considering they added COM automation and other Windows specific APIs to Silverlight that are mainly of interest for businesses. For example to cloudify an old VB6 app via COM.

  • tim

    @Philip

    Thanks for the comments.

    It is “only” COM automation that is specific to Windows Silverlight AFAIK. Microsoft does do Silverlight for embedded devices – but only for Windows embedded, unless you count the Symbian port.

    Tim

  • CMD

    Flash, Silverlight and AIR, all are hideous, buggy and bloated, do not want!

  • Phillip

    IIRC, the print API was windows specific, as is hardware access (via DirectX? I don’t remember).

    And Windows embedded is pretty much a Windows kernel (for the good and bad that introduces in a common codebase), which makes the port easier. Otherwise, I don’t think Windows Phone 7 would be Silverlight-enabled.

    But Linux on embedded devices is a very different beast from Linux on servers or the desktop. Not only is the kernel different (obviously), but it can also change the whole userland, tools that another application might depend on to function. The situation is probably very similar, but I guess the Windows API stays fairly consistent (like Java SE, EE, and ME do in relation to each other). With Linux, you don’t have this guarantee: there are several C libraries for example, which require recompilation of anything linking against them.

    In the end, I guess it’ll be a business decision by MSFT, like pretty much everything. But I doubt that Linux in that regard will matter overly much. The popularity of a device using Linux will matter.

  • When Microsoft came to prominence in the 1980′s it was because they provided an operating system (DOS) for a whole range of computers from different suppliers that reduced costs for the suppliers, the application developers and users.

    They built on this success with Windows to the point that most outside the industry didn’t realise that there are alternatives.

    Finally there are new platforms arriving with iPhone/iPad, Android phones and pads, and Microsoft’s Windows based offerings are not competitive there.

    They are behind the game, but do have enormous resources to use catching up. If Microsoft were willing to let go of the Windows revenue stream then putting Silverlight across the current range of platforms could allow them to extend their dominance – but can it be made to pay?

  • Anonymous

    Personally I’d rather see MS put their limited resources into fully building out Silverlight on Windows and Windows Phone, rather than diluting their efforts by trying to support every platform.

    The iPhone success story is the opposite of “cross-platform-ness”. The iPhone does a very good job in its own yard, rather than trying to do a merely-average job in all the neighbor’s yards too.

  • John Doe

    There is an appalling installation of Silverlight, in the form of some junk called “Academic Workshop”, that is being force fed to teachers and students in the Toronto District School Board. Windows only, hence windoze/MS lockin achieved. It’s hideous and buggy. Brainwashing the next generation to use MS junk, and teachers are already illiterate.
    Checkout:
    http://aw.tdsb.on.ca