Ted Leung on the air: Open Source, Java, Python, and ...
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".
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
Posted by Julien Couvreur at Mon Mar 7 17:18:14 2005
http://libgmail.sourceforge.net/googlemaps.html
http://stuff.rancidbacon.com/gmaps-standalone/
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
--Phil.
Posted by Phil at Mon Mar 7 18:53:07 2005
Thanks for the pointers to GreaseMonkey and the various proxy pointers. I think that in some cases, this will lead to extensions to web apps, and that's good. I'm all for extensibility, and if there's a reasonablle way to get that in web apps, all the better.
GreaseMonkey is a Firefox only plugin at the moment, which limits its reach. Also, running your own proxy server is also beyond the reach of many users who would be able to handle a traditional plugin/extensibility mechanism.
The other point I would make about GreaseMonkey, at least for now, is that the extensions are ad-hoc, and are likely to suffer from the same problems as other screen scraping type apps: fragility in the face of changes the by the web page provider. Someday web sites might actively encourage GreaseMonkey use, and then they might include extension points for use by GreaseMonkey scripts.
Posted by Ted Leung at Mon Mar 7 21:37:56 2005
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
http://www.redmonk.com/jgovernor/archives/000364.html
Posted by James Governor at Thu Mar 10 02:28:05 2005
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
Yes, the line for the box is important. In for profit development, you're right that where you draw the box determines what people will pay for (and further up the line, your price point). In the free / open source world, drawing the box in the right place is important for getting something adopted.
Posted by Ted Leung at Tue Mar 15 01:06:51 2005
Posted by Paul Prescod at Wed Mar 16 12:45:27 2005
In my case, I want plugins that I as an individual user can "install" into the application that I use. No doubt that the frameworks will allow installation on the server. But that's not really the same as an individual user sitting down and selecting or buying a plugin and having it show up. I suppose that the hosting service could have a policy that would allow something like this, but I doubt that many would. You could imagine Google having a list of approved plugins that you could click into your Gmail, but it's hardly going to be the same as say, Thunderbird extensions
Posted by Ted Leung at Wed Mar 16 23:01:51 2005
Posted by Trackback from Ted Leung on the air at Thu Jun 23 10:47:32 2005
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
![[Valid RSS]](http://www.sauria.com/blog/images/valid-rss.png "Validate my RSS feed"){kind=small}
