When I graduated from the University of Michigan, I decided to start my software engineering career at Microsoft. I accepted a position on a new small team working on what was at the time referred to as either Jolt or WPF/E (Windows Presentation Framework Everywhere). The product was a cross-platform browser plug-in to support rich applications and media streaming. Upon release, it would be called Silverlight.
The first version of Silverlight was very bare bones. It supported embedding a user interface defined in XAML (Extensible Application Markup Language) into a webpage and interacting with those UI elements through the page’s JavaScript. The main goal of that v1 release was media players. At the time, Flash was the dominant way to embed media on a webpage because without plug-ins, browsers did not have a way to support video playback.
From Microsoft’s point-of-view, the point of Silverlight was that competition with Flash. Microsoft wanted to sell their servers for media delivery, but the dominance of Flash for media playback was allowing for Flash Media Server to be the go-to server option for media. In order to support Windows Server sales, Microsoft needed an alternative to Flash so that companies could deliver rich media experiences without establishing a relationship with another server company.
As a side note, when you’re working at a big company, it’s always worthwhile to know why the company is investing in what you’re working on. It won’t always be talked about openly, but figuring it out will help you to understand what outcomes will actually be valued by upper management.
My main contribution to the initial version of Silverlight was its support for Firefox and Safari. I worked on pieces of both the browser interaction through the NPAPI (Netscape Plug-in Application Programming Interface) and our internal platform abstraction layer for system calls on Mac OS. I hadn’t programmed either browser plug-ins or anything for Mac before this point, so my time involved a lot of learning new things as we pushed towards our first release.
The second version of Silverlight, released about a year later, made things much more interesting. The plug-in now included a version of the .NET Framework allowing for programming of Silverlight-powered interfaces with C# rather than JavaScript, and it supported more media features – adaptive streaming and, unfortunately, DRM (Digital Rights Management). That second release is where Silverlight started to pick up bigger customers including NBC and Netflix.
As Silverlight grew, I worked on other pieces of it and picked up more responsibilities. I implemented its networking APIs to give application developers the ability to make HTTP requests using either the browser networking stack, which allowed for cookies and auth to be used from the browser session, or directly through the operating system, which allowed more control but was independent of the browser’s state. I also worked on its support of out-of-browser applications, including support for multiple window Silverlight apps.
It was a lot of fun to get in on a project from nearly its start and see it grow over the years as we shipped 5 major versions. The team working on Silverlight was also great. Unfortunately, it wouldn’t last. While Silverlight was successful in enabling customers to deliver great media experiences using only Microsoft products, shifts in the way people use the internet over those years meant that it had no future.
Two big changes were happening. First, Google launched their Chrome browser and began to push for HTML5. Their search engine business meant that they wanted to both push application development to focus on websites and for those applications to use standard HTML and JavaScript that their search engine could understand. The other big shift was the iPhone. Suddenly people had a capable browser in their pocket that they were using for more and more of their web browsing. Supporting Windows and Mac was no longer a compelling cross-platform story, and Apple had no interest in supporting Silverlight in their phone browser.
Between HTML5 allowing for rich media without any plug-ins and more browsing happening on devices without plug-in support, there was no longer a market for Silverlight. As work on Silverlight 5 wrapped up, Microsoft split the team. A small team would continue to service Silverlight until its inevitable end-of-life, and then the vast majority of the team was moved to either Windows Phone or Windows 8 to work on the application platforms for those two products.
Another lesson from Silverlight is that sometimes even if your product is successful, the market can shift and change its fate. Silverlight didn’t end because we failed to deliver a good product or because we were out-competed by another plug-in. Instead, changes in the broader market brought about the rapid disappearance of browser plug-ins as a whole.
I was on the portion of the team that moved over to Windows Phone, but that is a story for another post.
Scott Boehmer 