October 12, 2006

Squeezebox brings online music into your living room

by Greg DeKoenigsberg


Years ago, we had some great radio stations in Raleigh. One of the greatest was WRDU 106.1. They dominated the airwaves in this town for years; in fact, RDU was consistently voted one of the top rock stations in the country by readers of Rolling Stone magazine. I was one of those readers, and I looked forward to the opportunity to vote for RDU every year. They had top-notch DJs who knew their rock and roll. They were amazing at balancing music I knew and loved with music I didn't yet know, but would come to love.

Last week, WRDU became "The Rooster" -- a Clear Channel codename for "the best country music of yesterday and today, as defined by our algorithms, with no live DJs ever." The best part: it's not even the only station called Rooster Country 106. Clear Channel has another Rooster Country 106: WSTH in Columbus, Georgia. Not to be confused, of course, with Rooster Country 93.3 in Jacksonville, Florida -- which for some reason can be found at roostercountry107.com.

Some people around here are calling it the end of an era. Some people on Wikipedia are claiming that it's a stunt, and that WRDU will be back in a few short months on the other end of the dial. Other people apparently don't care for that interpretation of events, and have re-edited the Wikipedia entry accordingly.

And me? I was disappointed to hear about the format change, and amused to discover that it has evidently spawned a wiki war -- but the reality is that, for me and a lot of people like me, RDU died years ago when Clear Channel came to town. I've been tuned-out of America's radio airwaves ever since.

Just because I stopped listening to the radio, didn't mean that I stopped loving music. It just meant that I had to go about loving it differently.

For me, and for most of my friends, that meant using the internet. Between internet radio and the file sharing revolution, I discovered that I had more opportunities than ever to discover lots of music -- some of which was new, but most of which was just new to me.

These days, the online distribution of music is completely mainstream. Apple is working hard to convince everyone that it's all about iTunes and the iPod. But there's still a lot of room for innovation in online music delivery -- and some of that innovation is happening with the help of open source development.

No login required. Want to see your comments in print? Send a letter to the editor.

Slim Devices produces the Squeezebox and the Transporter, both of which are receiving rave reviews from all over for their seamless integration of online music into the home stereo environment. The magic behind both of these devices: SlimServer, a network music server available under the GPL.

Recently I chatted with Dean Blackketter, the CTO of Slim Devices, about the relationship between Slim Devices and their community.

RHM: Give me a bit of history around the Slimserver. Which came first, the Slimserver or the SliMP3/Squeezebox?

DB: Sean Adams, the founder, built the first SliMP3 units in his garage back in 2001. At that time I was at home, hand-building some network music players based on cheap, commodity PC hardware for myself, friends, and family. I wrote some PHP scripts to drive those things. When I saw Sean's announcement I bought one of the very first units. When I got mine, he emailed me a page of Perl code called "slimp3.pl"--a program that let you browse a folder and play a song.

I figured I'd rewrite the thing in C, but first I had to learn Perl to know how it worked. I bought a copy of Learning Perl and read the thing in one night. I though that it would be fun to try to rewrite slimp3.pl, and so over the next few days I did.

I sent it back to Sean, who was very appreciative, emailed it out to all the other customers (some of which were already making other changes), and sent me a free SliMP3 as a thank you. This went back and forth between me and a few other folks. We eventually started a SourceForge project for the "SliMP3 Server", which eventually became SlimServer.

RHM: So ultimately you abandoned the decision to rewrite in C. Why?

DB: Because I thought it would be fun to learn a little Perl. Later on, though, it turned out that a LOT of people know a little Perl and like to use it to solve their immediate problem or try out their latest idea. Perfect for building a community to help build out SlimServer.

RHM: Was the Slimserver designed from the beginning to be extended by a development community, or did you come to that idea later?

DB: It happened organically. Sean's key insight was that he wasn't going to be able to do much of the software development, so he got people like me involved. In 2002, I joined Slim Devices (employee #2) and could work full-time on the project, helping the community do the interesting work.

RHM: Is there a value to contributing if you don't actually purchase a Slim Device product? In other words, are most of your developers and contributors also customers?

DB: Yes, they are, but there are a substantial number of SlimServer users who haven't bought the product yet. They just want to stream their music to their PCs, using SoftSqueeze or WinAmp or the like. There's utility in the software without the hardware, plus it's a great way to "try before you buy".

RHM: What percentage of the Slimserver code base, by your very rough estimation, was written by employees of Slim Devices?

DB: That's a hard question. Some of those folks started writing stuff before they became employees or contractors here. I'd guess that it's probably half.

RHM: As you've increased your staff, have many people been hired out of the development/user community?

DB: Yes. For example, Dan Sully is now our lead SlimServer developer; he was one of our earliest customers and is a major Perl guru. Richard Titmuss was a customer, wrote SoftSqueeze (a java-based Squeezebox simulator) and is now our lead firmware engineer. And we're hoping to hire more.

RHM: How many of the plug-ins developed by the community have made their way into the product itself, and how are they maintained? By the community? By folks from the company with community help?

DB: We include about 27 plug-ins in the current SlimServer release. Most of those have come from the community and are maintained as a group effort. There are also a number of HTML skins and a lot of core functionality that's originated in the community. The ultimate responsibility for the quality of the product belongs to Slim Devices, but help comes from all over.

RHM: What are the mechanisms for community contribution? Do community developers have CVS/SVN access, or do they just email patches to a list, or what?

DB: Both. The SVN repository is open to the world for reading. We qualify folks before they get write access and there are about a dozen who have that power. Folks who don't have write access post to the forums, set up their own web page and link from our Wiki, attach patches to bugs in our bug system, or just send them to somebody who has access.

RHM: Do you have any specific success stories of work done by community members that has made a huge difference to you?

DB: Sure. One big one is that a customer in Japan really wanted Japanese fonts on his player. He rolled up his sleeves and figured out a way to get a font renderer to work with TrueType fonts very easily. It's something that was on our to-do list for a long time -- but nobody on our internal team needed it like this fellow did. So he went out and solved the problem for himself and made the product better for folks all over the world.

Another example is the AlienBBC plugin. Our customers in the UK really wanted to get access to their favorite BBC stations. They organized themselves and wrote a comprehensive plug-in that does that and a whole lot more. This is one of our most popular plugins and provides access to a huge number of radio stations that we wouldn't have been able to provide otherwise.

RHM: What impact would you say that your development community has had on the success of Slim Devices as a company?

DB: It's not just code that the development community creates that makes a difference. Our discussion forums guide the direction of the hardware and software development. Our wiki and bug system are open to the public and help us document and maintain our products. Our users evangelize our products to the world and help us meet interesting partners for content relationships -- like Pandora.

We wouldn't be here without them.