There’s no question that open source technology is used widely in financial applications, especially for middle components. However, there was also a discussion about how willing the financial companies are to open source their own technology (where “technology” might include algorithms and research rather than just software).

I don’t believe any company intends to sacrifice a competitive advantage by converting their technology to open source. For that reason, I doubt that we’ll see financial companies releasing algorithms or proprietary research. However, financial companies are involved in open source in a variety of roles. The user role is probably most common today, but a few financial companies have contributed to open source. One example is the Advanced Message Queuing Protocol (AMQP) effort started by JP Morgan and others. This technology benefits financial software (and software from other domains) by provides a programming language-independent and vendor-independent wire protocol for message queues. For this technology to be successful it must be widely used. An open source strategy has a clear advantage here.

Another example is the Open Financial Market Platform (OFMP) which has recently become an Eclipse Foundation project. In this case, I’m not so clear about the benefits to the company contributing the initial code. Maybe someone from the project will comment.

Tim O’Reilly closed the panel with a suggestion that open source developers consider projects that make it easier to capture and process the vast amounts of unstructured data available on the net.

1. Acquire New technology Skills. Is there a programming language or library you’ve been wanting to learn but is considered too leading edge to use in your day job. You could either start an open source project or join an existing project that uses the technology. You’ll learn the technology better by applying it to real problems instead of just reading a book and studying simple examples.
2. Develop Project Management Skills. OK, so you aren’t really interested in being a point-haired project manager. However, when I say “project management” I’m talking about organizational skills that can apply to any type of project — from home improvement to organizing your next vacation. Starting a new open source project will generally provide the most skill improvement in this area, but it’s also possible to learn a lot about project management by supporting existing open source project leaders.
3. Improve Your Leadership Skills. This is similar to project management skills, but not quite the same. Managing a project and leading a project are different. Often, you or a small group people will be the primary keeper of the project vision but you must allow an encourage participation from the entire project team and user community. There will be many potentially difficult decisions about tradeoffs between cool new features, delivery schedules, product quality, and overall product direction. If you successfully build a user community, you’ll find many of these users ask for (or practically demand) features that aren’t consistent with the project vision. These decisions are seldom clearly right or wrong, and you must learn how to make them wisely and be flexible enough to adjust the project direction when a decision doesn’t work out.
4. Develop Discipline In another post I discussed the time management challenges of working on open source software. These challenges and the unforced and voluntary nature of open source work will require you to develop the discipline to maintain focus over a long period of time despite constant interruptions. This ability to focus can be valuable in many other areas of life.
5. Give Something Back.Many people (including myself) enjoy writing open source software because we have benefited so much from other free software that we want to reciprocate. Richard Gabriel writes about this idea in his paper “Mob Software: The Erotic Life of Code“.
   

   To understand what the open source and mob software movements are trying to do, it helps to make a distinction between a commodity economy, to which we are accustomed in a capitalist society, and a gift economy. In a gift economy, gifts are exchanged, forming a bond based on mutual obligation: In the simplest form of gift exchange, when one person gives a gift to another, the receiver becomes obligated to the giver, but not in a purely mercenary way—rather, the recipient becomes very much like a member of the giver’s family where mutual obligations are many, varied, and long lasting. More sophisticated forms involve more than two parties—in fact the cosmos may become involved. A person may give a gift with the realistic expectation that someday a gift of equal or greater use value will be received, or that the recipient will pass on a further gift. Sacrifices and many religious ceremonies are gift-economy based. In an open-source project, the gift of source code is reciprocated by suggestions, bug reports, debugging, hard work, praise, and more source code.

6. Participate in a Community. Maybe you are more ambitious than just wanting to learn a new technology. You want to contribute somehow to the overall development of a community of programmers and users interested in some specific topic. You have the opportunity on an open source project with a wide range of potential roles include programming, design or documentation.
7. Improve People’s Lives. It can be a great feeling to know that you are making a direct positive impact on people’s lives by providing them with something of value. This feeling is often missing at a day job because it can be unclear who, if anybody, will benefit from the work we do.
8. Have Fun. If you love programming, it can be a lot of fun. Sometimes I think of programming being like solving a puzzle game. You can invest great quantities of time in playing computer games or you can invest that time “playing the software development game” and reap many of the other benefits described in this article.
9. Become Rich and Famous. This is relatively rare, but participation in an open source project can lead to becoming relatively well known with certain circles of people, even if not world famous (which has also happened in a few cases). The software development global community is surprisingly connected. When you start meeting people for the first time who already know you by name because of your open source project, your jaw will drop. Wealth is less likely even than fame, but it does happen. The JBoss Group’s recent acquisition is just one example. However, it’s more likely that your open source experience will lead to increased wealth through higher income or opportunities to start new businesses.
10. Expand Your Social Network. Working on an open source project can be a good way to build social networks with knowledgeable and potentially influential people. Whether you are looking for a job or just wanting to have access to experts when difficult problems arise, this social network can be very valuable.
11. Improve Your “Day Job” Performance It’s easy to see how improved discipline and skills in technology, project management, and leadership will set you apart from the crowd and help you earn a reputation and someone who can get things done. This is a good strategy for increased promotion and compensation opportunities.
12. Improve Your “Market Value”. Even if your current employer doesn’t appreciate the amazing new skills you’ve developed as an open source project developer, other companies will appreciate it. It’s not unusual to receive unsolicited job offers directly related to open source work.

What are some other benefits you’ve experienced from working on open source projects?

As a side note, I’ve had several people request the XPlanner on Rails code. It would be very interesting to have someone pursue that effort.

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.

WORKS OUT OF THE BOX

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.

LOW SURFACE-TO-VOLUME RATIO

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.

GENTLE LEARNING CURVE

“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.

PROGRAMMING-BY-DIFFERENCE

“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.

FIRST ONE’S FREE

“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 it’s 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.

WINNING TEAM

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 it’s 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.

1. FIRST ONE’S FREE
2. WINNING TEAM (cross platform)
3. WORKS OUT-OF-THE-BOX
4. GENTLE LEARNING CURVE
5. PROGRAMMING-BY-DIFFERENCE
6. LOW SURFACE-TO-VOLUME RATIO

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.

“I get up every morning determined to both change the world and to have one hell of a good time. Sometimes, this makes planning the day difficult.” ~ E.B. White

So you are considering starting your own open source software project? If you are doing this project on your spare time, there will be several time risks to consider. One risk is the open source development time multiplier. Sure, you’re a highly productive developer at your job. Then again, most developers typically work 40 or more hours per week. How much time will you be able to invest in your new project?

Let’s say you work 3 hours each for two evenings during the weekdays and another 4 hours on the weekend. That’s 10 programming hours. We’ll assume that you will be consistent in how much time you work on the project. It’s difficult to do with family and friends tempting you to spend time elsewhere. And, besides, finding balance in how we spend our is also important.

In this scenario is will take about 400% more calendar time to implement the same code for your open source project as at work. Given our time multiplier, a task that might take a week to complete during a day job will take about a month on our open source project. This is only an estimate since most people don’t actually program 40 hours week at their day job due to interruptions like meetings, code reviews and design discussions. Interruptions will also occur in your open source development: children, spouses, roommates, happy hours, dinner. It’s sometimes difficult to maintain a high level of enthusiasm when progress feels so slow relative to your normal development pace. At the same time, you must maintain a sustainable pace to avoid problems like burnout or damaged personal relationships. For me, relatively slow and steady progress has worked best although there are times I will expend intense bursts of energy on my side projects for short periods of time.

These are a few possible reasons why so many open source projects never deliver any software.

What can be done about it? Learning time management skills can help (see resources). Agile software development techniques, applied ruthlessly, can also to maintain focus and make the best use of limited time. Implement essential functionality and understand which features will provide the most value to your users. Many projects flounder attempting to implement a grand vision instead of a simple, useful product.

“Guard well your spare moments. They are like uncut diamonds. Discard them and their value will never be known. Improve them and they will become the brightest gems in a useful life.” ~ Ralph Waldo Emerson

Time Management Resources

• Managing your time
• Thirteen Timely Tips for More Effective Personal Time Management
• Time Management Skills