How Perl Powers the Squeezebox
Slim Devices made their name in 2001 with the SLIMP3, a networked MP3 and Internet radio player. The SLIMP3 won a five-out-of-five mouse rating in Macworld magazine, and was featured in GQ magazine and on TechTV’s The Screen Savers. This year, they’re trying to repeat the success with Squeezebox, an 802.11-enabled version.
The interesting thing about the SLIMP3 and the Squeezebox from our point of view, though, is that the server which drives the player is written in Perl, and developers are allowed – in fact, encouraged – to hack on it and make the devices do interesting things. A developer community has sprung up around the SLIMP3, and some interesting third-party hacks have been produced.
We caught up with Dean Blackketter from Slim Devices, who took some time out from moving Squeezeboxes to answer a few of our questions.
perl.com: What made you decide, first of all, to write the server code in Perl?
Dean: Sean [Adams, Slim Devices founder] wrote the very first version of the software in Perl because he was able to get it up and running quickly. When I first encountered Sean and SLIMP3, I was a little afraid of Perl, having been primarily a C and C++ programmer, mostly because when I tried to read it, I got confused by idiomatic usage.
I first decided to rewrite the thing in C, but I couldn’t really get started until I could read the existing code. So I bought a copy of Learning Perl and read it in two evenings. Halfway through the first chapter something clicked and I said, “That’s so cool!” Then, about every 10 pages after I’d repeat, “That’s so cool!” again, but a little louder. By the end, I was sold. At that point I dug in and started making the software better.
What features of Perl were particularly helpful when you were writing the SlimServer?
The greatest feature of Perl, for us, is that so many people know it. Since our software is open source, we benefit from as many users as possible being able to read and improve our code base. Anybody who’s thrown together a little Perl CGI or script is a potential contributor to our software.
Second, the ability for us to offer our software on a wide array of platforms (Mac OS X, Windows 98/ME/NT/2000/XP, BSD, Linux, Solaris) and also be deployed on server appliances makes it possible for us to get our product running as broadly as possible.
Third, even though our product’s primary feature is playing back audio, the bulk of the software really is processing text. Our built-in HTTP server, command-line interface, device-user interface, and even music meta-information is all text-based, and Perl is nearly the perfect language for this.
What issues did you have to face when considering how to distribute a Perl-based consumer application, and how did you approach them?
Distributing a Perl application on the traditional Unix-like platforms (BSD, Solaris, Linux) is easy. Things got a bit harder on Mac OS X, since command-line solutions aren’t acceptable to Mac users. Initially, I wrote a simple graphical application (in AppleScript!) that acted as a launcher for our server software, but this was really not good enough for Mac users. One of our Open Source contributors, Dave Nanian, came to the rescue and built us a System Preferences pane and installer application that work as they should on a Mac.
Windows is the hardest platform for us to support. Luckily we had another Open Source contributor, Sam Saffron, who decided that building a shell application for the server software would be a great way to learn MFC, and he contributed a nice little app for this. Another contributor, Chris Eastwood, put together an installer for us. But it was the fine folks at ActiveState with their Perl Dev Kit that really made it possible for us to release on Windows with their PerlApp (for making Perl-based .exe files) and PerlSvc (for making Perl-based Windows Services).
Even with all this help, Perl on Windows is different enough in subtle ways to make it a real pain to maintain. Maybe if we had more hardcore in-house Windows experience things would be easier, but it’s a struggle.
For consumer devices like the SLIMP3, the manufacturer has a choice between open and hackable, and “sealed box.” You guys went for the hackable approach, GPLing the code and setting up developers’ forums. What was the rationale behind that?
When I got into this, the total of my Open Source experience was running a Linux server in my basement. Sean initially released the SLIMP3 software under the GPL, which made it possible for me to help out. I quickly realized that our customers have a lot of talent and energy that they are willing to contribute to make the product better. We’re lucky to have a business model where we can make money on the hardware and give the software away. When our customers contribute, they make their own SLIMP3s (and now Squeezeboxes) more valuable to themselves and make the new units we sell to new customers more valuable as well. Everybody wins.
How did you go about building a developer community behind the SlimServer project?
I like to think that the community built itself. We provided a forum (our discussion lists) and Sean and I participate on a daily basis; acting on the requests, suggestions, bug reports, and patches that people post. We’re spending more effort lately setting up our own list server and CVS system, as we had problems with our previous forums (Yahoo Groups and SourceForge, respectively), but these will give us a little more control of our virtual spaces.
How do you decide which developer extensions to keep as third-party projects and which to integrate?
If a contribution will make the product better for a substantial portion of our customers and won’t make the product worse for any of them, then, generally speaking, it’s included. Submitted features that make the software harder or less intuitive to use, require obscure or platform-specific software or hardware to be installed, generally don’t make it in. Contributions that are useful to a large fraction of our customers and don’t diminish the product’s ability to play back music, make it in.
I act as final arbiter and (hopefully) benevolent dictator, and the community has been really supportive of this.
Finally, we notice that you’ve decided to donate 10 percent of your profits to the EFF. What’s the motivation behind this?
Digital freedoms are important to the folks at Slim Devices, both personally and at a corporate level. We’ve been frustrated by not being able to offer our customers the ability to play the music that they’ve bought due to digital rights management systems and onerous licensing fees for various patents. The EFF shares our goal to free our customers’ music.
Something wrong with this article? Help us out by opening an issue or pull request on GitHub