Michael: We are big fans of open source software, and we try to be as open source as possible. We are running Apache web servers, and for the API, we run the RESTlet engine on top of Apache. Once you drop below what I call the API presentation layer, it is all dependent on what backend system we are tapping into.

Typically, there are Java JARs that talk using web services to systems on other tiers, and in most cases, those servers are also running Apache. At the database layer, we are still an Oracle shop.

Sean: What’s the plumbing like behind some of the more popular applications that leverage the API?

Michael: The most popular category of apps for us right now is mobile applications, and the majority of those are iPhone apps at the moment. People enjoy adding movies to their queue or researching movie titles on their phones, but no one is streaming movies on any phones. A lot of the applications hit the API directly, like the app built by Pyxis for the BlackBerry. They actually leverage some intermediate servers in some cases, for cached catalog data and what not.

I think the idea there is to cache a lot of information so they don’t pound our API more than they have to, but a lot of client applications do quite well by going directly to our API without any kind of server intermediary.

For application developers, that’s nice. They don’t really have to pay for any operational infrastructure to run their applications, and it’s a pretty cool model to build an app, put it out there without any operational infrastructure, and actually make some money.

Sean: What do you see as the most important areas of innovation for Netflix going forward?

Michael: Of course, we have to be very interested in Netflix member acquisition and retention for our subscription business, but we really want the API to be our source of innovation in user experiences around our service.

We have been in the subscription DVD rental business for a decade, and we are pretty good at helping people discover good DVD and Blu-ray content. You can see that in the Netflix prize where we offered $1 million for anybody to improve our recommendations by 10%, and it took almost three years to get there.

Even though we are pretty good at helping people find good movies and TV episodes on DVD and Blu-ray, we have been offering members the opportunity to watch instantly on their computers and TVs with a Netflix ready device for more than a year , and the dynamics are a little bit different. There is less content, and it is less new-release focused. These titles have less mindshare with the subscribers, so it is a whole new game as far as movie discovery goes.

That’s where we are seeing some of the most interesting innovation around our service using the API. For example, instantwatcher.com actually builds an index of titles that are available to watch instantly and it looks very much like an old Yahoo index page from the ’90s. All the different titles are broken out by category; it’s an experiment we hadn’t done in the website yet.

The Netflix members who use that service love it. We have an application gallery on our website, and instantwatcher.com is consistently one of the top rated applications out there.

So we are able to outsource innovation on our recommendation technologies. Here we successfully outsource the development of a new experience around instant watching discovery, and that’s a great thing.

One of our in-house developers built an external application for the iPhone called Instant Queue Add for Netflix, which is essentially like a remote control for instant watching, so you can bring up a variety of different instant watching titles on your iPhone. When you find something you like, you add it to your instant queue, and it appears on your Netflix-ready device connected to your television set within a matter of couple of seconds. That’s a pretty cool scenario.

Sean: To switch gears a little bit, given that you used to work at Microsoft, what do you think about their moves toward open source? There has clearly been a big sea change around that point, with them contributing IC’s to the Linux kernel, etc..

On the other hand, to be fair, there are some portions of the organization that still feel they are entrenched in a battle with open source, and they articulate it as such on a fairly regular basis.

Michael: For me, the most interesting aspect of that question really gets beyond just open software, and into openness in general. If you look at the number of companies that have succeeded by being open and compare that to the number of companies that have failed by being closed, I think it becomes very clear that open strategies are probably a good thing to do.

Try to name one company that has failed in the last 10 years by taking too open an approach to things, and then think about all the companies you know that have failed or at least struggled because they haven’t been open enough. I think you will find a lot more companies in the latter camp than the former.

In general, at Netflix, as we look at different opportunities and consider how open to be, we don’t necessarily always go open, but if we are fence sitting on a decision, we will tend toward the open path. That’s in keeping with a preference to be guided by opportunity more than fear, I might add, and that’s worked well for us.

Sean: What’s your take on Linux on the desktop or Linux on mobile devices? Obviously there is browser support for the Netflix site and things like that, but do you have people building Linux-specific applications that run on Linux desktops that leverage the API that you know of?

Michael: Probably the best example is a lot of the Netflix ready devices that are out there. When we partner with CE manufacturers that build Netflix ready devices, we hand them a reference implementation of our streaming client in Linux. And a lot of these partners are using Linux for their setup boxes, so in the space where you are not necessarily concerned about running packaged software off the shelf, Linux is a great solution.

I think we get a ton of leverage from the fact that Linux is a predominant platform on CE devices these days, so it eliminates a lot of the porting efforts that would be involved in having to take our Instant Watching client and adapt it to a much wider variety of platforms.

Sean: Notwithstanding the awesome popularity of the iPhone, people want a bigger screen to consume media. Do you think there’s a market for a dedicated, robust device with HD video and rich connectivity to other devices and so forth?

Michael: These are personal opinions, but for me it’s a no brainer. If you like consuming media today on iPhone, a bigger screen could allow for a much better experience, especially for video. Media on a tablet-sized device would be a very interesting thing, especially when you consider the discovery of content as well.

Imagine an experience like Windows’ media center, where you’ve got really rich box art, and you can stroll through galleries and things like that. I think that being able to do that with touch on a tablet-sized device would be a killer media discovery and consumption experience.

Sean: What do you think about the connection between Linux and Windows on those types of devices? Every dollar matters. I own a Kindle DX, and I love it, but I can totally imagine the fact that nobody wants to drop 400 bucks on it. It runs Linux for good reasons one of which is that it helps to keep the cost down at least a little.

Michael: Linux is definitely up to the task, and I think “I can’t get software to do that problem on Linux” is much less of a problem for that type of device, at least with the type of apps we build.

Imagine once you have an HTML 5.0 browser and it finally solves native video support within the HTML model. If they can find a way to get DRM in there, that would be our ideal video client platform. Netflix could then do pretty much anything in a browser that we’re doing on these Netflix-ready devices without any software download, and that’s huge.

Again, we’re a consumer science kind of company. We like to update our website every two weeks to run new tests and get real-world user feedback on our services. Imagine if we could do that around these new video services. That would be a huge boon to us.

From a customer’s perspective, imagine the rich types of applications they could get on that kind of platform, without any client software installation.

Sean: So, does the potential movement toward Linux on the desktop really devolve into just what more you can do in a browser? As the browser becomes more and more powerful, will we do this whole reduction process that we always do in tech, where a system gets complex and supports a bazillion use cases but then it gets too heavy and topples over like a pile of Jenga blocks?

At that point, we usually build something smaller that targets the core of what people are using at that moment. If so, it isn’t so much about Linux on the desktop any more, but rather just how much I can do in the browser. It just becomes an issue of what’s the OS that happens to be supporting your browser.

Michael: I would say that, in the long term, it becomes all about the browser. You may not get there all the way with HTML 5.0, but I think it’s worth noting that there are a lot of applications, including relatively complex, streaming clients, that could run in that type of environment once you layer on the video support and the DRM support.

I think you’re going to see a lot of applications that can live in that world. If so, the operating system starts to become less relevant, since it’s really just the runtime for that browser.

Sean: What are some things you’re hoping browsers support in the future, beyond what you’ve already mentioned? You were saying before that you could deliver a client-side experience to them, update and refresh it whenever you want, push new options, and the consumer wouldn’t feel like they’ve installed anything.

So, what are you thinking of and wishing for from a browser usability and features perspective over the next few years?

Michael: HTML 5.0 nails a lot of it. The canvas support is huge for animated transitions and things like that, instead of going to something like Flash or Silverlight and requiring a plug in. The full support for async communications and that kind of Ajax is awesome, but let’s face it, it’s an elegant hack that’s been there for years.

So, having real async support and things like web sockets are really nice to have, to make an application perform very robustly. Then, they’re trying to crack the nut of native video support. And there’s the big debate right now between Ogg Theora and H.264. So, once that’s worked out, or they have a model where both can be supported readily, that’s a big boon.

For us, being a subscription business with premium content, we also need to have DRM. That hasn’t quite been addressed yet, or even talked much about, probably because a lot of the services on the web are ad supported, and digital rights management isn’t a primary concern for them.

I think once all those things are in place, we have a shot at delivering a pure web-delivered client with no install.

Sean: I want to be sensitive to the time here, so is there anything you’d like to add as a closing note?

Michael: One thing I’ve been thinking about lately is that Netflix wants to remain a small, nimble company. We see ourselves as a big start up and we obsess about things like talent density. The API programming helped us out with that, and we’ve got third-party developers building applications under their own brands.

We also work with major partners to create Netflix-branded applications, and that cooperative model works well for us, working with that partner to get the engineering done. In some cases, though, we want to do a branded application, but we don’t have an engaged external partner lined up to do it. In cases like that, I wonder if there’s an open source approach to building a Netflix application on a platform where we don’t have an engaged partner.

I can’t help wondering if there’s an opportunity there, especially since there’s so much passion around the service in the technology community. I think there are a lot of engineers that are looking to scratch an itch, like wanting Netflix on a platform where it doesn’t yet exist.

We already give them the API, but how can we give them the guidance and engage with them in such a way that they can create a Netflix-branded application that meets all of our quality considerations? I think that’s an interesting question going forward. That might be a new type of program we will be able to do on top of the API in the future.

Sean: I want to thank you for taking the time to participate in this interview. There’s always something else you could be doing besides being interviewed, so I appreciate you taking the time.

Michael: I enjoyed it. Thanks.

Sean: Goodbye.