Applications, Plugins and Community

15 March 2005

Ted Leung has recently written down some thoughts about applications that are extendable by the user through plugins:

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 exactly the thinking behind my proposal for a plugin architecture for Trac. Trac is meant to be a “minimalistic approach to web-based software project management”. We have been very reluctant to add features that would not be of interest to a large percentage of the user base. Blindly adding seemingly cool features adds bloat to an application – and thereby makes the application harder to use and comprehend for the average user (as well as for the developers).

Plugin-based Architectures

A plugin or extension mechansism helps avoiding bloat, while still allowing use of the product when special requirements are present – without requiring hacking your custom extensions into the original code.

Some systems provide explicit plugin APIs where you can extend the application in a specific direction, like adding filters to Photoshop, or adding support for specific file types to a text editors. Often, such extensions are basically add-ons to an otherwise monolithic application.

Other systems, such as Eclipse, use a plugin system as the very core of their architecture. Basically, the core is just a micro-kernel that manages plugins. This does not automatically result in a well-designed application… But by using the extension system yourself to put together the application (instead of just coding up a “Hello world” plugin), you get a pretty good feeling for what kind of interfaces need to be provided.

For the plugin architecture I propose for the Trac project, I went with the second approach. Indeed, you might find some similarities if you happen to know the Eclipse design and terminology.

Plugins and Community

The extendibility of an application is a very important factor for building an active community around it. Kathy Sierra refers to this effect as the wake of a product:

Does your product or service support plug-ins and add-ons? Does it lend itself to follow-on products, accessories, support and training, etc.? Does it inspire others to be part of your wake?

The only officially sanctioned way whereby Trac currently allows extension by the user are Wiki macros. The interface for Wiki macros isn't exactly great or powerful, but still it has helped to create a vibrant community that is developing macros for others to play with.

If even this rather crude form of extendibility provokes so many to actively participate in the project, what could be achieved if the entire system was written in a way that would encourage extension and customization?


  1. In “about:cmlenz - Plugins in Trac 0.9”, Christopher Lenz says:

    24 August 2005

    We're planning to release a beta of Trac 0.9 any day now. Probably the most important enhancement - in my opinion - is the introduction of the plugin architecture (which I've blogged about before). That's subjective of course; others may …