brave [little] meme

An interview with Jmarshall, XBMC developer

A few weeks ago I had the opportunity of interviewing djh, one of the Xbox Media Centre’s leading interface designers. The interview received overwhelmingly positive feedback from the XBMC community, and many requests or a follow-up with other sides of the XBMC project.

Today I have the great pleasure of sharing an interview with Jonathan Marshall, president of the XBMC Foundation and one of the project’s lead developers. Jonathan, better known as jmarshall, shared some insights on his experiences  working on the development of XBMC.

—

Q: Tell us a little about your background outside of the XBMC project. 

JM: I’m a Mathematician currently masquerading as a Statistics lecturer.  I’ve lived in New Zealand most of my life, other than a short stint in the UK (Glasgow).  Outside of XBMC I’m busy making a mess (and eventually cleaning it up) whilst renovating our house. 


Q: How did you get started on XBMC? 

JM: I stumbled across it in early 2003 when it was known as XBox Media Player. I bought an xbox in order to run it, found some things I thought could be improved, and did up a couple of patches. I was invited on to the team shortly after, and have been hanging around ever since. 


Q: What do you see as being your key function within the XBMC project? 

JM: I’m president of the XBMC foundation (a non-profit we’re currently setting up to provide direction to the XBMC project) and one of the lead developers on the project. My main focus on the XBMC codebase is the user interface side of things - maintaining and improving the skinning engine, and attempting to improve the experience for the end user, but I dabble in most areas. Recently I’ve been focusing on refactoring and rewriting some of the sections of code that have been neglected for some time, such as the base texture and image classes and the directory caching system. 


Q: Let’s talk a little about XBMC itself. What would you say separates 
it from other media centre and HTPC software?

JM: The biggest thing for me are that it’s completely opensource - both in terms of code release and the development model. This has led to a large, active and enthusiastic community being built up around the project, which pushes the development further than could be achieved with a closed model. The obvious difference with XBMC is it does not attempt to restrict you in any way, whilst still attempting to be as user friendly as possible. The commercial media centre offerings cannot compete with this, and we think we’ve done a better job than the many opensource projects out there on the user friendly side of things - though obviously there’s still a great room for improvement in this respect! 


Q: XBMC’s ad-free and open source nature are arguably two of its most 
appealing traits, but how do you keep the project going financially?

JM: We rely on sponsorship and donations primarily.  For instance, Boxee has contributed the initial costs of running the server that hosts xbmc.org, trac, and associated services, in addition to many other donations to the project, such as covering the expenses of the developers conference last year. We hope that donations from users (to the XBMC foundation) will cover these costs in the future. 


Q: As a project, XBMC never seems to sit still. It has evolved from an 
Xbox hack into one of the most full-featured and customisable media experiences available. What influenced the decision to go multi platform?

JM: As with most major new things that affect the project, the decision to go multi-platform came from a developer fronting up and putting in the work.  Yuval was responsible for the port to linux which was the main departure point from the xbox. I’d done some initial work earlier on porting to win32, and once the linux port was working nicely, Elan Feingold did the initial porting work to OS X. This is the great thing about open source - developers from outside the main team can come along, grab the code, and make changes as they see fit. 


Q: How does the team cope day-to-day with XBMC’s multi platform nature? 

JM: The key is that we try to ensure that any additions to the codebase work across all platforms, assuming that it is feasible to do so. Whilst we don’t reject platform-specific features, we attempt to do everything as generically as we can.  This generally leads to improved code on the whole as the interfaces are thought through further than they may have been for a single platform solution.

An example would be the VDPAU hardware acceleration, which is only available under Linux.  This is impossible to achieve (at least using the same API) on Windows, Xbox or Mac OS X, so instead the code is added in a way that makes as little impact on the other platforms as is possible.  With developers on all platforms, any errors that unintentionally break another platform, or anything that could be done in a more platform-neutral manner is quickly picked up on and fixed. 


Q: Unlike with Plex and Boxee, which have fairly short release cycles, the XBMC community as a whole seems to rely more on self-compiled builds, with official releases often months apart. Why have you chosen this approach?

JM: We’ve chosen a 6 monthly release cycle for official stable builds as a compromise between having a build that is as bug free as we can possibly make it, and having builds that contain the latest and greatest features. We don’t want to release official builds that contain problems if we can avoid it, which means that we must feature freeze for a reasonable length of time prior to release to allow all developers to focus on fixing problems.

We currently feel that a 6 monthly interval is a reasonable compromise between having enough time for developers to focus on new features, whilst also allowing periods 
where all development effort is focused on stability. The unofficial builds from the community help fill this gap for those who prefer to try out the newer features and don’t mind having to deal with a few bugs here and there, and in addition give developers valuable feedback on how new features are coming along, and whether or not there are new problems introduced.

We’re still trying this system out, though, and it may take a little bit to get the timing right - we’ve only had the one official stable release after all, and the next is due in just under 2 months from now. I think we’ve got the timing reasonably right at the moment, given the available resources we have. 


Q: Do you think the project’s reliance on users compiling their own builds of XBMC may turn off potential adopters who don’t have the means or the experience to do so? 

JM: I don’t think that’s a problem at all, as there are builds made available from the community for most platforms. Windows has at least 3 people making releases for download, Linux has the SVN PPA which is built regularly, and with the refined Mac OS X build process, more frequent build releases there are just around the corner. I think the vast majority of users are not interested in constantly upgrading their software when what they have works perfectly well - they’re quite happy to wait a few months and update to a stable build if they think it’s necessary. 


Q: Despite the long release cycle, XBMC’s feature set continues to evolve at a rapid pace. How do you keep the project from stagnating?

JM: We don’t have to do anything as a team really - the community as a whole is so enthusiastic that it keeps things running along far faster than we could if we were doing all the pushing. I personally find I don’t have enough time to implement even20% of what I’d like to, and I’m sure other developers feel the same way. 


Q: What influences your choice of new features and areas of interest as development continues?

JM: The main thing for a developer is whether or not we’re interested in a particular area ourselves, through use of XBMC in our own systems - nothing motivates morethan an annoyance constantly faced! Given that my main interest is in the user interface, I usually have a very long list of ideas and features that I’d like to work on - all focused on making things easier for the end user (and thus me!)  Often many of these things rely on making underlying changes to the code before the end goal can be worked on, so can often take a long time to get to, but I always prefer a correct solution over a quick solution wherever possible. 


Q: What about customisation, what is the relationship between the developers and the skinning community? How do the needs of those designing interfaces for XBMC influence the core team’s development efforts?

JM: We have a great relationship with the skinning community, and I am constantly amazed at the ingenuity and skill that they display in coming up with some of the ideas - often times things that were not considered possible are done through innovated use of the skinning engine. As I’m the lead developer on that side of things, I’m usually the main point of contact for skinners looking for new things or asking about how to best achieve some particular function, and I’m always happy to entertain changes that make things easier for them, or allow them to do something new.  Much of the skinning engine has come about through back and forth discussion among the team and skinners, and we support them in any way we can, whether it’s through providing a forum, answering questions, commenting on suggestions, or adding features. 


Q: Let’s talk a little about the other products which the XBMC project has originated. What’s your take on XBMC’s spinoffs, Plex and Boxee? 

JM: The one great thing about open source software is that third parties can take the source code and develop it in different directions than the original developers might have done so.  I think both Plex and Boxee have done this in different ways.  Certainly we don’t have the infrastructure or financial backing to be able to do what Boxee have done - creating a version of XBMC with a focus on social networking - I think they’ve done some cool stuff.

One thing that is a disappointment with both Plex and Boxee is that they’ve gone to a closed development model and have closed off parts of the source code. Both have had to be reminded (several times) of their requirements under the license, and both only release the sources after a binary release has been made.  They’ve also closed off significant parts of their new features - the Plex Media Server is closed source, as are the flash and silverlight players that Boxee have.  While they are entitled to do so, it is in my opinion contrary to the open source ideals on which XBMC has been based, and, to be honest, I see no advantage to their users in having code hidden away. 


Q: Does the XBMC team as a whole maintain a relationship with the Plex and Boxee teams?

JM: We have a good relationship with Boxee in particular, yes.  We have two developers on the team that work for Boxee, and we’re kept abreast of changes that they make that XBMC could benefit from.  Boxee have been of great assistance to the project in terms of the financial sponsorship they’ve given - they very much understand that without XBMC they wouldn’t exist!  We don’t have a relationship with the Plex guys at all as a team, though I am in contact with Elan from time to time, and enjoyed meeting Isaac when I was in San Francisco on a recent holiday.  We take very little sourcecode back from either party on the whole, though - most of the changes that they make go into the extensions that they have, much of which is closed source. 


Q: Why do you think Boxee has been getting so much press lately as compared to XBMC or even Plex?

JM: They pay a guy to do PR would be my guess, plus they’re an ”opensource” company, which is always helpful in getting a bit of free press. 


Q: How, if at all, is XBMC influenced by the feature and design choices adopted by those other products?

JM: Obviously any similar software product gives ideas - we’ve taken many ideas and features from other products in the past, and will continue to do so in the future.  Many times we’ve already thought of a feature or design choice but just haven’t had time to implement it properly! 


Q: Getting back to XBMC itself, do you have a vision as to where the project might be in a year’s time?

JM: I think our next release will have well over a million downloads. I think that with the release of nVidia’s ION platform, XBMC on linux (either live or under ubuntu) with hardware acceleration of video decoding will be the platform of choice for many - a small, lower power box that will play all HD material. 

The main focus for me is making things easier for the new user. Currently there’s many things that a new user is confused about, and things that they should not have to concern themselves with.  Some of XBMCs most powerful features, such as the video library, are beyond the reach of the new user unless they read the manual carefully and ensure they set things up correctly.  It’s my goal to make using XBMC as simple as possible, whilst still allowing our existing “advanced” users the flexibility that they are accustomed to.  This is no easy task, but in my opinion is essential for the long-term benefit of the project. 


Q: Any hints as to when the next major release will be, and what it may bring? 

JM: Next release is April, probably towards the end of the month. Major new features are hardware video decoding on nVidia chips under linux, and smoother video playback for all platforms.  As usual, there’ll be a myriad of other new features, along with improvements in stability. 


Q: Thanks so much for taking the time to talk to us. Is there anything you’d like to say to our readers?

JM: If you’re an XBMC user, thanks for being part of this awesome community.  If not, what are you waiting for?  Pop over to xbmc.org and check it out.