Open Company example: SlimDevices
I had another great experience with an Open Company this weekend. I now have another example to add to my lists of companies who truly get it.
I've been a more-or-less happy owner of two SlimDevices' Squeezeboxes for a couple of years. The Squeezebox is a small audio component that can wirelessly access a music library stored on your computer. I use them to stream MP3s to different rooms in my apartment. I chose the Squeezebox because, at the time, it was the only product on the market that was able to stream the same music synchronized to multiple rooms. It's a great solution for whole-house audio, and much easier and cheaper than trying to run wires through the walls.
There are other products on the market now which offer synchronized streaming (in particular, local Santa Barbara company Sonos), but I still think Squeezebox is the right choice. I may go into greater detail about that in a later post. But for now, let me say that I think the Sonos player is brilliantly engineered product with a phenomenal interface. But the price difference is significant. And the Squeezebox has the advantages of openness, as you'll see below.
Yesterday, I was trying to debug a problem where the sound would drop out, but only on certain tracks. The Squeezebox was apparently having a difficult time dealing with AAC files, though I knew they were supposed to be supported. I started by searching the mailing lists. Someone had previously suggested watching the player’s memory buffer (and explained how to do it). With this information, I was able to tell that the player wasn’t receiving data quickly enough — thus the drops. I thought this odd, since AAC files are roughly the same size as MP3 files, and the buffer stayed totally full when playing an MP3.
Then I found the SlimDevices’ wiki (new since my last visit) and looked up AAC. And that told me what the problem was: AAC files were being decoded on the server and then streamed at full size (approximately 10x larger) over the wireless network to the player. No wonder the player couldn’t keep up.
The wiki entry had instructions on how to reconvert the AAC files into MP3s prior to streaming. (I know this is a messy transcoding operation, destined to lose even more quality that the already sub-audiophile-quality AACs, but I just wanted the files to play.) I tried to follow the wiki’s Linux-based instructions for getting the transcoding to work, but I hit a wall. Another search of the mailing list, however, pointed me to the FAQ entry that ultimately solved my problem. Lastly, I added a link to the wiki page pointing to the OSX solution, so that no one else would waste time trying what I had done.
This was another example of nearly perfect customer support. I was able to solve a problem by myself, on the weekend, and without having to spend a single minute on the phone. And it was made possible by SlimDevices’ following the practices of an Open Company: open data, open communication, and open documentation. And I was able to contribute back what I had learned, adding a modicum of value to the whole.
So anyway, having found another company (of which I am a happy customer, not coincidentally) practicing open company virtues, I think it’s useful to compare it against the Open Company Test. Hopefully, the episode I described and the test can show how SlimDevices’ openness benefits both the company and its users.
Open Sourcecode: All of their server source code is open, viewable and hackable by the public. I’m not exactly sure why the client code is closed, but I’m sure they have reasons. No doubt the community has an easier time contributing to the server software than they would have working on the player’s custom hardware.
The open source code has allow the user community a huge number of plugins, hacks, additions, and customization. In one of the best examples, a user has developed a software emulator for the player that allows your computer to act as a Squeezebox and stream music from your SlimServer to any other computer — anywhere on the internet (providing throughput is good enough). This emulator is now included with the offical SlimServer distribution.
Open Data: SlimDevices is proud of their wide support for different audio formats. They are happy to play music in whichever format you happen to have. And they’re happy to let you store it anywhere and in any manner you want.
In addition to making the server opensource, SlimDevices has also made it very pluggable. By stringing together various third-party utilities, the community has been able to expand the list of supported formats. (As we saw with the AAC example above.)
Open Pricing: The Squeezebox is a consumer product, so it’s neither a surpise nor a great triumph that the pricing is easy to find. But there it is.
Open Bugtracking: The community has open access to the bugtracking of all of SlimDevices’ development — even bugs on the closed-source client software. Unfortunately, they’re using Bugzilla instead of some more reasonable and attractive bugtracker. But I suppose that’s a failure of aesthetics rather than of ideals.
Open Feature Voting: Because the community has access to the bugtracker, they are able to suggest new features. However, there does not appear to a formal way to track user votes for a given request. This feels like a draw.
Open Communication / Open Community: Community is, I think, where SlimDevices best demonstrates the value of openness. They have a thorough and active mailing list/forum. And they also have mailing lists for developers that anyone can participate in. And they’ve begun offering a wiki for user contributed documentation (running KWiki, if you’re interested).
Also, SlimDevices hosts a staggering number of user-contributed projects that take advantage of their product. An amazing amount of effort has been devoted to expanding the capabilities of the Squeezebox. There is a truly symbiotic relationship between the company and it’s users.
Open Documentation: The regular user documentation is not fully open — there is no way for a user to directly edit the docs for either the client or the server. However, there is the wiki (mentioned earlier), and users can file bugs against the documentation. So there is an established channel for documentation changes, it’s just a little old-school. I’ll say that they get this one mostly right.
Open Customer Support: Individual support requests are not open to the public, so far as I can find. However, it seems as a great deal of support happens on the mailing lists. And you do have access to everyone’s bugs. So it could be worse, but I think this is one area where SlimDevices could be more open.