Aaron Bockover

Last week I gave a talk on Vernacular at MonkeySpace in Boston. As Wednesday concluded, so did my last day at Rdio after nearly two years. In that time I had the pleasure of working with very bright people on creating the best streaming music service available on Mobile, Web, and Desktop.

From the introduction of the Windows Phone app, to the launch of the new Android app, Rdio 2.0 for Web and Desktop, and finally the Android and iOS refresh betas, Rdio has been and will always be close to my heart. I wish everyone at Rdio the best — keep on being excellent!

I originally intended to simply take a few weeks of vacation time after leaving Rdio to focus on Cat Overflow, beer drinking, and cycling (funemployment!), but after spending a long weekend in Florida for a wedding, I find myself headed back to Boston. A simple Monday and Tuesday at home in Raleigh is all I’ve afforded myself in terms of vacation, since today I start at Xamarin!

While I’m determined to actually take some real vacation in the near future, I was enticed to join Xamarin as soon as possible to begin bootstrapping work on an exciting new product. I’m looking forward to working with new and familiar faces!

Perhaps I’ll start blogging again as well, after nearly two years of silence. I certainly owe a follow-up post about Vernacular. For starters, here are slides from my talk last week, cats included. Video of the talk should be up at MonkeySpace soon as well.

• PDF Slides (static cats)
• Keynote Slides (animated cats)

Great news! openSUSE 11.4 was just released, and it’s loaded with goodies! I am of course most excited about the inclusion of Banshee 1.9.3 with full Amazon MP3 store support included out of the box.

Within seconds after the 11.4 installation, I had made my first Amazon MP3 purchase.

In openSUSE, 100% (not 25%) of referral revenue generated by Banshee’s Amazon MP3 support goes directly to the GNOME Foundation. 100%. What are you waiting for? Install openSUSE 11.4 and start buying music – an easy way to help Free Software!

You can even help GNOME by shopping with Amazon through your usual browser. No excuses!

Firstly, this post is a personal one. I am not speaking on behalf of the Banshee community, any corporation, foundation, or my maintainer peers.

Since Banshee will be shipped in the upcoming release of Ubuntu, Canonical has decided it will take 75% of the Amazon MP3 referral revenue that, in the upstream/default codebase and configuration of Banshee, has historically been donated to the GNOME Foundation, a nonprofit organization.

25% will continue to flow to the GNOME Foundation. Of course this change will only affect those running Banshee as distributed by Canonical/Ubuntu. Other builds and distributions are unaffected.

Given that this decision appears to be final, I propose to Canonical my vision of the execution of this revenue sharing from a technical and accounting perspective:

• Let Banshee handle the revenue sharing on the banshee.fm server. Currently, when launching the Amazon MP3 store in Banshee, the user is redirected through a proxy on banshee.fm. This proxy does a few important things:
  • Use IP address geo-location to redirect users to the most appropriate Amazon MP3 store (e.g. amazon.fr, amazon.com, etc).
  • Inject the appropriate Amazon MP3 referral code depending on the store chosen (and in this new case, also depending on whether the user is coming from a Canonical build).
  • Act as a level of indirection in case changes are made on Amazon’s side – if something happens, we can update our server and users remain unaffected as software updates do not need to be pushed.
  • Finally send the user to Amazon MP3.

• With revenue sharing happening through the existing proxy, we can ensure that funds to the GNOME Foundation are delivered through the existing referral codes, and in a timely manner. We will be able to continue to provide public disclosure of referral revenue for GNOME.

  I am very concerned about accountability, and want to ensure that 25% is indeed making it to GNOME in a timely manner, consistent with what we already have in place.

Additionally, as part of Canonical’s decision to donate 25% of Banshee’s Amazon MP3 referral revenue to GNOME, they have also stated that 25% of referral revenue from their own UbuntuOne Music Store and from referral revenue from their builds of Rhythmbox will also be donated to the GNOME Foundation. I applaud them in this choice, especially around U1MS, as this is their own service and investment.

However, as partly implied by the Ubuntu News article on the matter, one thing that does concern me is that while this issue was discussed between Canonical and the Banshee maintainers many times, I am not aware of Canonical involving anyone in the actual Ubuntu community. I will be interested to see how we end up handling this matter technically, and what, if anything, Canonical does regarding packaging, patching, and involving the existing Ubuntu packagers and contributors.

Finally, I am excited about the new potential Banshee has in the near future to generate truly significant referral revenue for the GNOME Foundation as we near Banshee 2.0 and its availability on Windows and Mac OS X, where we will fully control its distribution as an upstream.

About 6 years ago I started working for Novell to develop Banshee into much of what it has become today. I’m quite fond its evolution, but perhaps more proud of its community. As is likely obvious, I have not been too technically involved with Banshee over the past year. The last major thing I developed to production was the Amazon MP3 store integration and downloader, which was over the summer of 2010 (and is currently bringing in a respectable amount of revenue to the GNOME foundation!); yet Banshee has kept on growing – at a fantastic and exciting rate. This is all thanks to the numerous people actively and passionately involved in the project.

Over the last two years I found my duties leaning much more towards the Linux distribution side of things at Novell – specifically engineering of SUSE MeeGo this year, and SUSE Moblin the year before. My hands were in pretty much every aspect of the projects, and I found myself working closely with so many great people, many with whom I had not previously worked. This includes talent from both Novell and Intel.

Out of the MeeGo project arose an opportunity for Banshee as well. Working closely with the team at Intel, it became the default and integrated media player not just for our SUSE version, but also for Intel’s reference version of MeeGo for netbooks.

Recently I found myself faced with an opportunity to work with a new set of talented people on something fresh. Today was my last day at Novell, and next week I will be starting at Rdio, where I expect to take Banshee into yet another new direction. I’m excited about the possibilities ahead, but will save my thoughts for another time.

I’ve been a happy Rdio user for quite some time, and have been very inspired by its fresh and unique take on a few aspects of media playback and management. And while there’s much I’d like to do in Banshee that Rdio is already doing, there’s perhaps even more I’d like to see Rdio doing that Banshee does. It will be an exciting time to come, and I’m eager to jump in.

I intend to continue to be involved in Banshee as an application and community. I am looking forward to again spending more time in the project. Similarly, you won’t find me leaving the GNOME and openSUSE communities I’ve grown quite fond of over the years. Apologies for that!

As I write this I am headed to FOSDEM, and I am very much looking forward to seeing so many great people again, and I look forward to the times in the future where we will continue to meet, preferably over copious amounts of beer!

Miguel calls this the new "abock lolcat."
The only problem is that it’s a dog! But this is fine with me…

Unfortunately I will not make it in time for the Friday Beer event.

Friends, in these tough economic times, we’re all expected to go above and beyond the usual call of duty. My very dear friend Miguel regularly executes on this mantra and today was no exception.

This afternoon, he was spotted tending to a toilet emergency. Miguel went above and beyond, demonstrating his fearless leadership and improvisational skills. He has declined to comment on the matter however.

Miguel stopping an overflowing toilet
at the Novell Cambridge office.

We’ve yet to generate any leads in this case of backlog, but we will be setting up an anonymous tip-line. Stay tuned.

Miguel wading through toilet water in his boots
after the overflow was stopped. Bless him.

VP of developer platform & visionary by day, plumber by… day as well.

During Gabriel’s talk at GUADEC, after working with members of the GNOME Foundation board, we were very excited to announce that the Amazon MP3 Store in Banshee would begin using an Amazon Affiliate ID, and that 100% of all revenue generated through this affiliate ID will go to the GNOME Foundation!

This means that any time you purchase MP3s through Banshee’s integrated Amazon MP3 Store, you are helping the GNOME Foundation help others.

These funds can be used in a number of creative ways that ultimately better Free & Open Source software and its communities.

We look forward to the future around this initiative, and hope that your purchases will help with things like sponsoring participants at conferences, organizing hackfests, and so on.

So what are you waiting for? Go buy some music!

We’re very proud to announce the release of Banshee 1.7.3, which brings some much anticipated WebKit goodness: the Amazon MP3 Store and the Miro Podcast Directory integration. Amazon MP3 downloading is fully supported, separate from the integrated store itself. There are also a handful of other smaller new features and enhancements, and a good deal of bug fixing as well.

Amazon MP3 Store

This new extension provides a source from which users can browse, search, preview, purchase, and download music from the Amazon MP3 store in all countries where it is offered: United States, United Kingdom, France, Germany, Austria, Switzerland, and Japan.

Watch the Banshee Amazon MP3 Store Screencast!

Music that is purchased through the new integrated Amazon MP3 store will automatically begin downloading and importing into the Banshee music library.

When previewing music on the Amazon MP3 store in Banshee, the previews will play through Banshee, showing up in the header, and not through Flash.

Amazon MP3 Downloader

The support for Amazon MP3 is not limited just to the store. If you decide to purchase music through your regular web browser, Amazon MP3 will provide a .amz file, a sort of playlist that indicates how the MP3s can be downloaded.

Banshee now associates itself with these .amz files and will download and import the MP3s referenced in them.

The Amazon MP3 Store and Downloader extensions are entirely separate. This allows you to pick your preferred user experience for purchasing music through Amazon MP3. The Amazon MP3 Store extension can be disabled if desired and the downloader will still work with an external web browser.

Other ways to download .amz files include opening manually with your operating system’s file manager, the Import Media dialog available through the Media → Import menu, or the command line client distributed with Banshee: $ bamz foo.amz. Bamz will download the .amz contents in the current directory, and will not import the MP3s into the Banshee library automatically.

For more information on the Amazon MP3 integration in Banshee 1.7.3, read my previous blog posts on the two separate extensions:

• Amazon MP3 Downloader Support in Banshee
• Amazon MP3 Store in Banshee

Miro Podcast Directory

Building on the same new WebKit integration in Banshee 1.7.3 as the Amazon MP3 Store, a new Miro Podcast Directory extension has been implemented. The source integrates with miroguide.com, allowing users to discover, stream, and subscribe to podcasts in a way never before possible in Banshee.

Much more work for tighter integration with the Miro Podcast Directory will come in future releases.

Bulk Metadata Fixup Extension

A new tool is available from the Tools → Fix Music Metadata menu item that allows for bulk metadata fixing. This feature proposes to merge artists and albums that vary only by case, & vs and, etc.

Other Enhancements

• Visual separators were added in the source view between categories of sources: special (Now Playing, Play Queue), local media, and online services.
• Item counts in the status bar are now culturally formatted (e.g. in en_US show 1,000 instead of 1000).
• Improved downloading and visual refreshing of new cover art.
• Visual tweaks to the grid view album artwork hover effect.
• Developers:new Banshee.WebBrowser API for creating embedded WebKit web browsers and sources. Currently used by the new Amazon MP3 store, Miro Guide, and the Wikipedia context pane.
• Developers:new Hyena.Downloader API for performing downloads and easy HTTP operations: HttpFileDownloader, HttpStringDownloader, etc.
• Distributors:the webkit-sharp dependency was dropped, and instead we now take a dependency directly on libwebkit 1.2.2+ for the new Banshee.WebBrowser API.

More and more I begin to wonder why we generate tarballs at all these days. Is it just because it’s easy – a function of “make distcheck”? There’s certainly value in the actual distcheck process to ensure you have a sane build, but why actually distribute the tarball? What’s the meaningful difference between a tarball and a git tag?

Now, I won’t even touch on the subject of how badly I want to throw autotools in the trash, but we’re so entrenched in its ways, and are comfortable with its quirks that energy is better spent on actual improvements, so for now the distcheck process is here to stay. For now.

So I ask a very serious question, others have asked as well – why publish tarballs? Most users get their packages in binary form from their distribution. Most users who build from source I would argue are using git already, or have git installed on their system, or can easily do so. Providing instructions on cloning/checkout out the tag/building using autogen/autoreconf/etc can be provided easily and clearly.

I migrated Banshee to Linode and consequently from Apache to lighttpd about a month ago. The logs start on June 20, 2010:

    $ grep -E 'banshee-1.+\.tar\.(gz|bz2)' \
        download.banshee.fm.access.log | wc -l
    7066

So in one month, we’ve only had 7066 tarball downloads, and that accounts for any and all released versions of Banshee over the past 5 years. Certainly the bulk of those downloads would be version 1.6.1, since that was the newest available tarball over the last month. 284 of those downloads were version 1.7.3, released less than 24 hours ago. I could generate better statistics, but that’s not the point here. The point is that number is pretty small compared to the reach of the distributions.

I roughly estimate the average size of a Banshee tarball (bzip2) is 3MB. Eliminating tarballs would save us 20GB/mo in bandwidth – and that’s during a quiet time in development when the servers are less active (1.6.1 was released in May). We’ll be seeing a spike I’ll be monitoring around 1.7.3.

So, if we ditched tarballs, how would you be affected? Would you care?

Update: to clarify a few things, you would still build and install like normal. For instance:

$ ./autogen.sh --prefix=$HOME/local --disable-whatever \
    && make && make install

Packagers would however have an additional minor burden. If their package system (e.g. rpm) requires an archive (e.g. can’t build directly from git), then the packager would be responsible for creating an archive. They could either just archive the git clone directory, or actually run their own “make distcheck” from their clone. It would be up to the packager to best integrate the git clone into whatever system they are using.

I woke up at 6 this morning with the urge to investigate writing an Android application. I have been a mostly satisfied user of Android ever since the G1 was first launched. I even switched to T-Mobile to get one from AT&T. The sales person at the time was confused as to why I would switch carriers to get that phone.

Fast forward to this fine morning where I’ll make my first attempt at putting my own pixels on my Android device, now a Nexus One.

Unfortunately, Eclipse in openSUSE seems to be a bit out of date. However, the Android ADT Eclipse Plugin is known to not work on 3.6 anyway, so for now I am just sticking with Eclipse 3.4. Additionally, there does seem to be a packaging issue as well that you’ll need to resolve.

• sudo zypper in eclipse java-1_6_0-sun-devel
• sudo chgrp -Rc users /usr/share/eclipse
• sudo chmod -Rc g+w /usr/share/eclipse

Note that I explicitly select the Sun Java devel package because Eclipse is allegedly faster using this Java implementation. If you prefer not to taint your system with proprietary software, the default-selected java-1_6_0-openjdk-devel should work just fine. The permissions fixing against /usr/share/eclipse is to make sure that Eclipse software updates work properly.

Start Eclipse, and go to Help → Software Updates and then select the Available Software tab and finally Add Site. Add the two following sites:

• download.eclipse.org/releases/ganymede/
• https://dl-ssl.google.com/android/eclipse/

When both sites show up (are no longer “Pending”), check the top-level check box for the Android site to select all Android plugins, then click Install and walk through the installation wizard.

With the installation complete, quit and restart Eclipse. Go to Window → Preferences and choose the Android section. Here you need to set up your SDK. I’m assuming you’ve already installed it.

Now you can go to Window → Android SDK and AVD Manager. Select Available Packages and install the SDKs, documentation, and samples packages that interest you. I’m sticking to the 1.6 SDK I guess for now, since not many people seem to have the 2.2 goodness yet. After you install an SDK, you can then create a virtual device that targets it.

Good luck!