Writing software costs money. Even Open Source projects have a cost to participants who either give up some of their free time to work on a project that interests them or for companies who pay their staff to work on Open Source projects in order to gain some competitive advantage by also utilizing the work of other people outside their organization.

It is usually interesting to examine different ideas that are in vogue for reducing software costs. In the 1980s, managers at my company (SAIC) seemed preoccupied with Commercial Off The Shelf (COTS) software. This was a response to customers questioning why, for example, they spent a great deal of money paying for custom mapping software instead of buying a commercial package that could be licensed for $20K. In the 1990s, the new mantra was ”software reuse”. Software reuse is a good idea of course, but I would argue that best practice procedures do not call for up front design for software reuse, especially when designing and implementing class libraries for a new project. Really, the problem with up front design for reuse is similar to the problem of over design without iterative staged prototypes: we really need some implementation experience to drive the requirements and design process. It is almost always better to simply pay the price of re-implementing a class library that has proven its usefulness after experience using it.

2.1 Advantages of Open Source and Commercial Software

There is absolutely no question, in my opinion, that organizations can save money by effectively using Open Source software. Strategically, the question for us to ask is how we mix Open Source, COTS software, and custom development. Best practice calls for (usually) using Open Source for infrastructure code. Here are a few common examples:

• Static and dynamic web content - using the Apache web service software, adding a few custom CGI programs for database access, etc.
• Static and dynamic web content for Java developers - using Apache Jakarta Tomcat with standard JDBC database connectivity tools, adding custom JSPs, JavaBeans.
• Small scale enterprise web applications for Java developers - using Tomcat and JBoss, adding custom JSPs, EJBs.
• A new Apple Mac operating system - uses BSD Unix for core functionality, adding Apple’s GUI magic (I am a Mac OS X user, and definitely a little biased).

It is easy to see the common thread here: use free Open Source software for infrastructure, adding value added code where required.

It often makes good sense to buy commercial software and tools. For example, if you live in the ”Microsoft Windows world”, it is hard to beat the .Net framework for easily writing web services. Some commercial applications, like Microsoft Office, are often used effectively as components in custom, vertical application development (i.e., applications targeted to narrow vertical markets).

In all cases, it makes sense to devote some small fraction of a development budget on research of available tools (both Open Source and commercial). Best practices for tool selection use the following criteria:

• Cost - both purchase price and training
• Licensing issues when redistribution is required
• Maturity of tools (e.g., are they ”industrial strength” or research prototypes)
• Prior team experience with tools