20 April 2009

Customizability in Applications

One thing that bothers me about software fairly often is the lack of customizability. This is one of the strong appeals of open source software and operating systems, in that they seem to be built with customization in mind. Proprietary software typically has a specific feature set that it is built around and tries to be as consistent as possible so as not to confuse users. This post is about thinking through some of the issues associated with customizability, some ways to handle it, and some software that I think does it right.

There are two big issues I see associated with building customization into software:
  • Time and Cost -- Customizability is really just another feature that you have to build into software, and it's a big one, especially if you don't design with it in mind from the beginning. The problem here is also that for each new feature you add, you also have to add customizability for that feature so the development time has the potential to increase quite rapidly with the more features you add.

  • User Experience Failures -- This is an interesting side effect of customizability. There is the possibility that by allowing customization of certain features of your application, users will be come confused by inconsistencies. This becomes even more of a concern when thinking about the ability to use the software from any computer and expecting it to behave in a similmar manner. If issues like this arise, it can lead to increased support costs.
Regardless of these issues, I believe that customizability is almost always beneficial to software. Some of these benefits include:
  • User Control/Choice -- Users are given control to shape the software to do what they want it to do and little more. This allows the software to appeal to a wider range of users.

  • Avoid Feature Bloat -- Rather than try to handle a majority of user scenarios in your software, including fringe features which may be very valueable to some users but rarely used by the majority, you can allow users to customize the application to include the functionality they actually need. This cuts down on core development time, especially if you crowdsoruce the production of the fringe features to the community itself. Office apps in particular struggle with the 80/20 rule of feature usage, and I think Zoho could do well to mitigate this problem by exploring customizability for their applications.

  • Platform vs Application -- By thinking about customizability, you might find an opportunity to transform your software into an application platform rather than a specific application with specific purposes. This will allow the software a far far larger appeal. Twitter is a great example of programming to a platform instead of an application. They could have easily have gone a different route.
There are a few different ways to implement cutomizability in an application:
  • Plug-in Architectures -- Probably the best way I can think of to make your application very customizable is to build the base application that captures the most important or most used functionality, but build it in a way that allows people to build plug-ins that can be easily added on top of the application. This allows the application to take advantage of the crowdsourcing mentioned earlier, especially if you make the plug-ins easy to create. There are a number of examples of this being implemented well including Mozilla Firefox, Lotus Symphony (built on the Eclipse Framework), and Wordpress. Google does a similar thing for Gmail, but as far as I know these are still developed by Google Engineers. I have yet to see a hosted web-app that allows user contributed plug-ins. If anybody knows of one please let me know.

  • Configuration Settings -- Most apps have some form of "preferences" page or configuration settings that you can tweak. Unfortunately these rarely go far enough to allow true customizability of an application. The other problem is that these configuration settings are rarely able to be synched across computers, which means each time you change a setting for an application, you need to change that setting on other computers you use that app on as well. This is also a problem for plug-ins, but Mozilla has an interesting solution to the problem they are developing called Weave (It's still in developmet, but you can host your own instance of it if you want to play with it).

  • Personas -- Similar to configuration settings, it is sometimes useful for people to aggregate particular settings into profiles or personas. For instance, I might want a certain configuration of a word processing application when I am writing a professional memo versus when I am writing poetry. It would be useful to be able to switch between personas with the click of a button. Once again Firefox comes through here with Profiles, but that is not the most useful solution in many applications as it requires you to restart the application

  • APIs and SDKs -- I'll only touch on this one, but the ultimate in customizability is to open up some of your functionality and data through web services or some other programming interface so other developers can actually build other applications on top of your core. This is the final step to becomming a true platform and there are many examples of this being done well, including Twitter and Eclipse.
All in all I think customizability is typically worth the effort and users appreciate it more and more, especially as it becomes more mainstream. That being said, not everybody agrees with me. Apple is probably the poster child for anti-customizability. They like to control every aspect of the user experience and make sure that their software/hardware has a consistent feel throughout. While there are some benefits to this method, in my opinion it is more annoying than anything, because if you don't like the way Apple does it, you can't really change much. Even when they allow developers to write apps for their hardware, they like to control as much as possible how those applications function and are distributed (read: the iPhone Apps dev process sucks)

07 April 2009

My Ideal Music Distribution Model Part II: The Solution

In my previous post I outlined some of the problems with current music solutions in the digital age. In this post I will detail my vision for how I think things should work.

To begin with, I am going to make the following assumptions:
  1. People will pay for music but have a limited budget for it
  2. People want to be able to own their music, and do what they want with it (e.g.. no DRM, no network connectivity required, etc)
My solution also attempts to meet the following goals:
  1. Get artists as much of a cut of the proceeds as possible (i.e. fuck labels for the most part)
  2. Allow people to choose how their money gets distributed
  3. Keep it affordable yet sustainable (tough to find numbers for this one)
The Details
The general framework for accomplishing these goals is to offer a music subscription service similar to Microsoft's Zune Pass or Napster, but without all the bullshit and DRM. It would have the following general features.
  • For a monthly fee you can stream/download as much music as you want
  • Your account is accessible from anywhere with a connection (any computer)
  • No 'net connection is necessary to actually listen to your downloaded music
  • Music is DRM free and sharable/transferable/etc to any device
  • Music you have downloaded is still available on your devices after your subscription ends
None of the above presents any really new ideas, but the interesting part of the scheme is in how the money is handled. I will go into this in some detail below.

Distribution of $$$
The big thing I would like to see is to let people dictate how their money gets distributed. This is important for two reasons. First, it lets people actually understand that they are supporting artists allowing them to make more music. Second, it shows people that their money is not going to some middle man, it is actually going to pay for the value the are getting out of the system.

There could be different options available for where your monthly fee actually goes. A few that come to mind off the top of my head are listed below.
  • Audioscrobbler style -- This is really where my idea originally stemmed from. In this model, your money would be distributed based on what artists you listen to in a given month. So lets say 35% of the songs you listen to in that month are by Murder by Death. 35% of your individual contribution would then go to Murder by Death for that month. Sites like Last.fm already have the infrastructure in place to track what you play and log it to your personal profile. It would not be a stretch to extend this and monetize it.

  • Socialist style -- In this model your money would get distributed based on the artists who needed it most. There are a number of ways you could determine need, but an easy way to do it would be based on popularity. A user could apportion their subscription fee to the 10 least popular artists they listened to the past month or something. The idea here is that the user is then helping support artists he/she likes so that they are able to keep making music and delivering value to the user.

  • Choose your own adventure -- Why not let users just choose which artists the money goes to specifically? Let Sarah give 50% of her subscription fee (minus the service cut) to Rob Costlow if she wants. If Sarah really likes Rob's music that much then she can decide to spend her money that way.
It is very important with the above distribution schemes that users be given a choice in what to use. I think the audioscrobbler method would make a good default, but if you tried to force people to use the socialist system or something, it would raise an outcry from many other users/artists in the community. Giving users the choice makes the most people content.

As far as the distribution of the money is concerned, Goal 1 is to let artists keep as much of it as possible. Obviously the service itself would need to take a cut, but this can be mitigated in a few different ways.
  • BitTorrent -- BitTorrent could be used to legally distribute and share the music where possible to help cut down on server and bandwidth costs for the service. However it could not be used exclusively, since many artists would not be popular enough to have seeders willing to share. Basically when a user requests to download a song, the service should check the BitTorrent ratio first, then fall back to an actual server if the ratio is insufficient. Alternatively you could have a set of servers dedicated to being BitTorrent seeds and used as a backup for when the number of seeders is too low.

  • Advertising -- The service itself could make money through advertising on the website you use to browse/download songs. This could be further enhanced by providing profile and social tools for people to use based around the music (see Last.fm again) to get people to go to the site for reasons other than just search & download.

  • Peripheral products -- Artists could also be given the opportunity to sell other items through the site, such as concert tickets, limited edition vinyl, shirts, etc directly to fans. This would also help supplement artist income and could possibly drive revenue for the service.

  • Bulk passes -- Offer people the opportunity to pay for a half or full year at a slightly discounted price. This money could then be invested and paid out to artists monthly based on the chosen scheme, with the interest from the investment going to the service provider.
Ideally the combination of these would increase revenue and reduce costs far enough that a maximal amount of the proceeds could be distributed directly to the artists.

How much would it cost?
I don't have the answer to this one offhand, I think it would take a decent amount of research to find a price-point that would most likely be profitable to both the service and artists. One option might be to experiment with a "pay what you want" scheme, although that might be too risky without setting a minimum price as well (say $10?). However by setting a minimum price I have the feeling that it would entice people to pay just the minimum.

Summary
The general theory behind all of this is that music has value and people will pay for it. Artists should be receiving most, if not all of this compensation since they are the ones providing the value. Paying for individual songs/albums is no longer a feasible model in today's world, but people should still have a way to make sure their favorite artists are getting paid and supported. I believe this model has the potential to do that, even in a world where people can download music for free (albeit illegally).

Just a final note, I think user feedback would be very important in this system. Showing people a results sheet of exactly how much of their money is going to which artists could increase buy-in and participation.

In the next post I will explore the feasibility of implementing this, who stands in the best position to do it, and possibly speculate some more on the current state of the industry.

06 April 2009

My Ideal Music Distribution Model Part I: Background Info

There has been a lot of talk over the last few years about how the music industry as we know it is dying. Awesome. I'm glad. People also like to speculate on where things are headed. Some think iTunes is the future, others think that music will soon be free and become simply a marketing tool for merch/performances. I honestly don't have a clue how the whole drama is going to play out, but in the next series of posts, I am going to describe my ideal music distribution and pricing model.

My basic assumption here is that people are willing to pay for music. Recorded music does have a value and people recognize this. The problem with most of the current and traditional models for monetizing music is that people are unable to afford the amount of music they would like to own. In a nutshell, the value per song of recorded music has dropped significantly, but I don't believe that the aggregate value of music to an individual has dropped at all. It might even have increased.

To put it another way, before P2P file sharing, the medium and distribution of music limited the amount of music a single person was able to access and own. Labels could easily control the price of music because it was a physical good just like any other. There was a certain limit to the amount of music you could put on one disc. With the advent of the Internet and digital music, people all of a sudden were no longer restrained by the physical product. Music libraries increased exponentially. With this new ability, it no longer made sense to limit yourself to the 10-15 songs you could get on one CD for $15. Instead you could have thousands of songs at your fingertips. The problem was that these thousands of songs didn't have a price on them, they were free.

I tried to find some statistics on the average size of a music collection over time, but my brief searching turned up no results. Just to speculate though:

Year# SongsCost ($1/song)
2000600 (~40-50 albums)
$600
20098000 (~40GB)$8000

As you are probably aware, 40GB is a modest amount for a music collection these days (I assumed 5MB/Song). Let's assume this is one person. From 2000-2009, that person would have had to spend ~$68/month ($816/yr) on music at the old prices. Few people I know are willing to do this. If it took that person 4 years to get the original 600 songs, that would only be $12.50/month. My assumption is that people on average probably find enough value from music to allocate that much of their budget for music.

So this brings us back to the original problem. The quantity of and access to music has changed drastically, but the pricing models really haven't allowed people to pay for the value they see from it.

Most current solutions to music in the digital age fall far short of understanding and correcting this problem. I'll just canvas a few of them below.

  1. Apple iTunes. Apple was sort of the first big player to step up and try to monetize digital downloads. They have until recently charged around $0.98 per song, but have now moved to a variable pricing scheme where songs can cost $0.69, $0.99, or $1.29 based on popularity. Some people are not too happy with this, for reasons I don't really agree with. I just think it's still too expensive to be a proper solution and some of their music still has DRM on it, which is just absurd. They have sold 6 billion songs through iTunes as of January 2009. Here is the best part, though. The artist cut on each song is probably around 10% if they are on a major label. Does that seem messed up to anyone else?

  2. Amazon.com. I'm not really sure when amazon started selling mp3s, and I'm too lazy to look it up right now, but it doesn't really matter. Amazon's prices vary some, but typically songs are priced at $0.99 each from what I've seen. Still too expensive, but at least there is no DRM.

  3. Microsoft Zune Marketplace. Microsoft offers mp3 purchases at around $0.98/song through their zune marketplace, but they also offer a Zune Pass for $14.99/month. The Zune Pass allows you to listen to (mostly) unlimited music from the Zune Marketplace as long as you keep your subscription going. You also get 10 free downloads per month. The huge downside here is that it's basically just paying for on-demand radio... You don't get to keep the songs after you cancel your subscription and you are limited to 6 devices total even while your subscription is going. Napster does something similar. (watch out for the annoying lady if you click that).

  4. Amie Street. Amie Street is a really cool site that does actual variable pricing based on demand. Songs start free or cheap and can rise to $0.98/song based on popularity. This is a cool little model, and probably close to the best thing out there right now, especially since artists get 70% of the proceeds from each song.

  5. Magnatune. Magnatune is a Berkely based little site that lets you choose what you pay to download an album/song. 50% of whatever you decide goes directly to the artist. They also refuse to work with major labels (I don't blame them). 50% seems a little low to me, but the choose what you pay scheme is interesting. I'm curious to see how that works out.
Some of these services seem to be on the right track, but others miss the point completely. In the next post on this topic I will lay out how I think this whole thing should work and then possibly follow up with the feasibility of implementing it. I would love to hear what other people think as well as I go through this process so please comment if you have an opinion.