XPlanner: A Selfish Application


Back in 1997, Brian Foote and Joseph Yoder wrote about The Selfish Class. Their paper was focused on software artifacts, mostly at the class or class library level but I believe the patterns also describe how application usage spreads.

According to Foote and Yoder…​

THE SELFISH CLASS pattern examines how the sociobiological notion that evolving artifacts tend to behave in the interests of their own survival applies to evolving code. The radical shift in perspective that Dawkins proposed was that from the standpoint of a gene, the organism itself was just a convenient vehicle the gene employed to propagate itself. Our perspective is that programmers stand in just this sort of relationship to evolving code artifacts. The [following] six patterns examine specific strategies that code artifacts can employ to attract programmers.

So the memes attract the artifacts and the artifacts attract the programmers? It sounds a bit far fetched. However, I do believe the Selfish Class patterns do have a role to play in how application usage spread.

It’s difficult to know exactly how many teams use XPlanner. There have been 60,000+ downloads on Source Forge (as of June 2005), which is many more than other similar projects whose download statistics are also tracked by Source Forge. Using the number of links on del.icio.us as a rough indicator of interest gives similar results. I’ve been surprised by the rate of adoption of XPlanner over other open source and commercial agile planning tools. I believe these results are related to the Selfish Class patterns. Let’s look at these patterns in the XPlanner context.


Designers are more likely to reuse an object if it is easy to try it out and see how it works. A good initial impression can motivate the designer to spend the additional time to develop a detailed sense of an object’s reuse potential. When the designer can actually see that an object works, he or she develops the confidence that a more detailed exploration will be time well spent. Conversely, if an artifact, such as a class, framework, component, or application, can’t be made to work at all, or requires elaborate preparation in order to work, the designer may become discouraged, and look to other options.

If you substitute 'user' for 'designer' in the quote above, then these statements are also relevant to application adoption. They can apply in at least two different ways. XPlanner is strong in one and weak in the other. XPlanner’s strength is that it’s easy to use once it’s been installed. My original goal was to make it easy enough to use that I’d never have to write a user manual. Even though the XPlanner community has added many features since the original release, we’ve been able to keep it simple enough that users can easily discover how to use it without a manual (who reads the manual anyway?).

Where XPlanner is currently weak is that it can be difficult to install the application. It’s a relatively easy installation for an individual or team with a J2EE servlet container and MySQL already running. Just drop in the JAR file and go. However, it can be difficult for teams with limited Java/J2EE experience. XPlanner needs an installer program.

WORKS OUT OF THE BOX doesn’t mean that difficult tasks are as easy as with more complex tools and associated user interfaces. It’s more about the application should be easy to use, right from the start. More about that later.


Objects that allow a user to control a large volume of complex machinery with a small, simple interface are more likely to flourish than those that don’t. An object with a simple interface relative to its internal complexity may be more likely to WORK OUT OF THE BOX.

There’s a fair amount of complexity inside XPlanner. However, most of this complexity related to security, internationalization, web service interfaces, persistent data access, and so on has little or no impact on the user interface and it’s ease of use. However, under the hood exist the hooks that developers need for integrating XPlanner with other project tools.


Complex interfaces can overwhelm beginning users.

In order to be Flexible and Adaptable, artifacts may provide a variety of Customizable and Tailorable interfaces. The variety and complexity of these interfaces can be confusing and intimidating to users who are unfamiliar with an artifact. These users are precisely the ones an artifact must attract if it is to broaden its mind-share. Artifacts that exhibit high Utility without imposing an up-front learning burden on the programmer have an advantage over those that do not.

An important force here is Time. Given unlimited time, a programmer might elect to learn a complex but powerful artifact as an investment in his or her skills. However, it is now far more likely that such a programmer, faced with the overwhelming array of choices that the marketplace now, will opt for the easier to Comprehend artifact every time.

There are two ways to look at the pattern when applied to XPlanner. From the user interface perspective, the effect is similar to WORKS OUT OF THE BOX. It doesn’t take much time for a new user to start working with an installed XPlanner application. For developers extending XPlanner, the situation isn’t quite so good. The architecture is relatively clean but has become more complex over the years as new features have been added. We’ve attempted to make XPlanner easy to extend by adding various plugin extension points, but there is definitely an opportunity for improvement here.

I’m not sure how much this pattern has influenced XPlanner adoption compared to similar tools.


You want to adapt an artifact to address new requirements while maintaining the artifact's integrity.

This is one of XPlanner strengths compared to most commercial offerings. Without source code or an extremely well designed and documented extension API, it’s difficult to adapt an application. Many installations of XPlanner have been adapted to work with existing tools. The many tests at the unit and system level also make it easier to adapt XPlanner while remaining confident that you haven’t completely broken the application.


In order to survive, an artifact must become widely available.

No matter how good an artifact is, it will have no chance of proliferating if other programmers never see it. In order to survive, an artifact must gain a wide audience. One of the forces that may limit an artifact's Availability is its Cost. A countervailing force is Bankruptcy. With this strategy, there is always the risk of giving away the store.

Therefore, give the artifact away.

The first XPlanner is free, and so is every one after that. This is definitely a big "selling" point for the application. Many of the XPlanner competitors are overpriced, in my opinion. A team is likely to try XPlanner and see how it works for them rather than spend large sums of money on a commercial product. Often, XPlanner does most of what they need. In other words, it provides 80%+ of the functionality of the expensive commercial products at 0% of the cost. That’s a good trade off.


In order to survive, an artifact must become widely available.

No matter how good an artifact is, it will have no chance of proliferating if other programmers never see it. In order to survive, an artifact must gain a wide audience. One way an artifact can become widely Available is to hitch a ride on a popular platform. The way for an artifact to win big is to have its code universally included with every copy of a system that ships. One drawback to this strategy is that the artifact loses its Autonomy. It’s fate becomes tied to that of its platform.

Therefore, strive to become bundled with a popular platform.

Several of XPlanner’s commercial competitors have chosen the .NET platform for their application and I believe this has hurt their adoption. I’m not saying that .NET is not a winning team, but in the context of wide application adoption, especially on the server side, I believe Java (or other cross platform languages like PHP, Ruby, Python, Perl, …​) has an edge. A large number of XPlanner installations run on Linux and .NET applications are a hard sell for that crowd.

I’ve always thought that XPlanner might have had even wider adoption if it had been written in PHP or Ruby on Rails instead of J2EE. A few years (before Rails) I asked the XPlanner community about moving to PHP and there was strong resistance to it. Maybe there were just more Java programmers than PHP programmers on the list at the time. I don’t know, but I thought it was interesting.

The WINNING TEAM effect for XPlanner is more about flexibility in deploying the application across a wide variety of platforms than it is about J2EE per se.

The following list is ordered by how what I believe is the effect of each Selfish Class pattern on XPlanner’s popularity.

  2. WINNING TEAM (cross platform)

I believe the Selfish Class patterns are a great way to evaluate the forces that encourage application adoption, whether the application is open source or commercial.

Leave a Comment