Ted Leung on the air
Ted Leung on the air: Open Source, Java, Python, and ...
Mon, 07 Mar 2005
Power laws and plugins

In the tradition of applying power laws to everything in sight...

Let's say that you want to build an application that has a potentially broad market. How do you decide what features should be included? I bet that the graph of application features versus users of a feature follows something shaped like a power law curve. At the "short head", you have all the "basic features", which all people are likely to use, which makes them uncontroversial and therefore in the product. In the "long tail", you have features that each are of interest to some small constituency. If you can't decide which of these constituencies you will support, you either include no features from the tail, or you try to include all of them.

Now you can see why applications that support some kind of plugin or extension architecture are important. The ability to extend allows you to build a base product with the feature set for the head. The extension mechanism(s) allow you or a third party to develop functionality for some constituency in the tail.

This is highly appealing to people like me, who find themselves perpetually in the tail. It explains why I like extensible applications like Emacs, Firefox, and Eclipse. I can build, or persuade someone else to build, or collaborate with them to build, functionality that is of interest to only a small community of people. I think that this is also one of the distinguishing points between rich client applications and web applications. Most web apps, like GMail, are building the feature set for the head. That's just good business and engineering sense. But since only Google can extend GMail, there's no way for someone like me, in the tail, to get the functionality that I really need in order to be productive. Now in different application domains I'll be in different places in the distribution. For e-mail, I'm in the tail. For mapping and driving directions, I'm in the head. This reflects my normal usage -- I use a mix of rich client-apps and web applications, and the split often falls along these lines.

So, web and non extensible rich-client apps for the "short head" and extensible rich-client apps for the "long tail".

[00:12] | [computers/programming] | # | TB | F | G | 11 Comments | Other blogs commenting on this post
You might want to consider reading this piece about Greasemonkey which talks about ways of empowering extensions to web apps.

Might be a way to get that "long tail" in the browser after all.
Posted by Gareth Simpson at Mon Mar 7 01:49:53 2005

I would repeat the GreaseMonkey comment and add the following:



I've also been looking for an excuse to send the following URL your way (since it's at least vaguely geographically relevant), so I'll take this as it: :-)

Google Maps of Recent Seattle 911 Incidents

Posted by Phil at Mon Mar 7 18:53:07 2005

Hey Ted,

The first I had heard of greasemonkey was from reading the comments here.  I agree that it's not a good long term extension mechanism.  Using the HTML meant for your eyeballs as an interface to a web app is just not good.

Having said that, I wanted to try out greasemonkey.  I have a Netflix subscription but I like to browse IMDb for movies.  I've always wanted a way to get from a movie name in IMDb to a Netflix search results page in one click.

In a couple hours, I managed to create a greasemonkey script that does what I want: 
IMDb + Netflix script.  I got lucky because IMDb uses a REST like URL for each movie.  The script puts a "(Netflix)" link next to each movie link on IMDb.

I don't think Amazon would be all that jazzed about my script helping Netflix subscribers.  Also, I'm not sure I would want to support a lot of people using it unless IMDb promises to never change their HTML output. :)
Posted by Ed Hager at Tue Mar 8 12:10:14 2005

I've been thinking about this lately in relation to weblogging tools. 

One of the questions, for someone(s) who want to make a software application for a big potential market, is "are you drawing the box in the right place?"  What I mean is, there are a huge number of potential features for any given product.  So how big do you draw the box, and what are the "right" components to put in it?

Way, way back in the late 80's, business applications came in all kinds of configurations -- but today, most large company "run your business" suites come with three things: an accounting package, a hr/payroll package, and a manufacturing/inventory package.  The extras, are, well, extras.  But that turned out to be the right "box."

What happens today is that we have no real knowledge on what the right size of the box is, and often, it gets set simply by developer fatigue.

To get back to weblogging tools, is there any good reason why a weblog package shouldn't have decent support for media types other than text?

Seen in this way, Flickr, audioblogging tools like Odeo, and videoblogging/moblogging tools are really failures of imagination or endurance by the developers of weblog tools.  And these failures have created market opportunities for others.  Interestingly, these "extras" seem to be things that people are willing to pay for, while most makers of weblog tools languish in the free to going out of business spectrum.  So maybe they drew the box too small.  The box has to be big enough so that it can contain stuff that people are willing to pay for.
Posted by
Lisa Williams at Mon Mar 14 18:14:28 2005

You can subscribe to an RSS feed of the comments for this blog: RSS Feed for comments

Add a comment here:

You can use some HTML tags in the comment text:
To insert a URI, just type it -- no need to write an anchor tag.
Allowable html tags are: <a href>, <em>, <i>, <b>, <blockquote>, <br/>, <p>, <code>, <pre>, <cite>, <sub> and <sup>.

You can also use some Wiki style:
URI => [uri title]
<em> => _emphasized text_
<b> => *bold text*
Ordered list => consecutive lines starting spaces and an asterisk





Remember my info?

twl JPG


Ted Leung FOAF Explorer

I work at the Open Source Applications Foundation (OSAF).
The opinions expressed here are entirely my own, not those of my employer.

Creative Commons License
This work is licensed under a Creative Commons License.

Now available!
Professional XML Development with Apache Tools : Xerces, Xalan, FOP, Cocoon, Axis, Xindice
Technorati Profile
PGP Key Fingerprint
My del.icio.us Bookmarks
My Flickr Photos

RSS 2.0 xml GIF
Comments (RSS 2.0) xml GIF
Atom 0.3 feed
Feedburner'ed RSS feed

< March 2005 >
   1 2 3 4 5
6 7 8 9101112


Macintosh Tips and Tricks

Blogs nearby
geourl PNG

/ (1567)
  books/ (33)
  computers/ (62)
    hardware/ (15)
    internet/ (58)
      mail/ (11)
      microcontent/ (58)
      weblogs/ (174)
        pyblosxom/ (36)
      www/ (25)
    open_source/ (145)
      asf/ (53)
      osaf/ (32)
        chandler/ (35)
        cosmo/ (1)
    operating_systems/ (16)
      linux/ (9)
        debian/ (15)
        ubuntu/ (2)
      macosx/ (101)
        tips/ (25)
      windows_xp/ (4)
    programming/ (156)
      clr/ (1)
      dotnet/ (13)
      java/ (71)
        eclipse/ (22)
      lisp/ (34)
      python/ (86)
      smalltalk/ (4)
      xml/ (18)
    research/ (1)
    security/ (4)
    wireless/ (1)
  culture/ (10)
    film/ (8)
    music/ (6)
  education/ (13)
  family/ (17)
  gadgets/ (24)
  misc/ (47)
  people/ (18)
  photography/ (25)
    pictures/ (12)
  places/ (3)
    us/ (0)
      wa/ (2)
        bainbridge_island/ (17)
        seattle/ (13)
  skating/ (6)
  society/ (20)

[Valid RSS]

del.icio.us linkblog



Listed on BlogShares

Locations of visitors to this page
Where are visitors to this page?

pyblosxom GIF