Developers in an enterprise need to use the best tools for the job. Increasingly they have found that Open Source projects such as Apache, MySQL, Tomcat, Eclipse, and others are ready for prime time. However, the stack is rarely composed entirely of Open Source. These projects are typically used in conjunction with industry standard, non-Open Source tools such as Oracle, WebLogic, and ClearCase.

Integrating these tools to create a cohesive development environment in a mixed Windows and Linux infrastructure is critical, but is often challenging and time consuming. Operating system vendors like Red Hat and Novell include some applications for common applications like e-mail and Web but not others like the aforementioned servers. The following are considerations that you may have when you're deploying applications on Open Source.

Identifying Which Software Is Good
Do you know which Open Source software is really okay to use? So far, no one has published a comprehensive review guide to Open Source software. However, there are many resources available for comparing Open Source software products. There are databases of Open Source software products such as SourceForge and Freshmeat.net that will list all your options, but they don't limit the playing field at all. For example, let's say you want a database so you go to SourceForge and type in "database." Surprise, you'll get back a list of hundreds of databases. Some are obviously not what you want, like a database for Palm OS, but many will have to be checked out. A search at Freshmeat.net turns up a similar list. The ones we expected to see, PostgreSQL and MySQL, are nowhere near the top of the list. Finding the best projects is often a challenge. Word-of-mouth is useful, but it's also important to take some objective measurements. For example, the number of releases the project has put out in the last year, the average response time, the quality of responses on the project mailing lists, and the number of project committers are all good proxies for overall quality. Several models exist for evaluating overall quality or reliability. Bernard Golden developed the Open Source Maturity Mode (www.navicasoft.com/pages/osmmoverview.html and the Business Readiness Rating (www.openbrr.org/) group put out another model. However, neither one provides a populated database. You have to do the technical evaluation yourself.

Identifying Licenses
So now you've decided on an Open Source software project that meets your technical needs, now you have to make sure you have the right to use it. Myth #1 about Open Source software is that it doesn't have a license. Very little software is actually in the public domain. Myth #2 is that it has just one license. These days most Open Source software is a conglomeration of different tools, all of which have their own license. If you're lucky, the place you downloaded the software from will actually have a section on the licensing that includes the licensing text; otherwise you'll have to dig through the source code for the license. Freshmeat does a good job of displaying the licensing information in the project summary. Worst case, you won't find license information anywhere. In that case, you'll have to e-mail the code's author to find out what license it was released under. Once you've found the license, you'll have to make sure it works for you and that you meet all the terms of the license. For example, if it's GPL, you'll have to make sure that anything you link to it is also licensed under the GPL and that you distribute the source code with the program. (Or at least provide a written offer of the source code.) Watch for unusual clauses - we once found a license that required the user to buy a copy of the author's book for every person on the development team! As another example, if you have to use Oracle with Open Source projects, be sure to read your Oracle license very closely since it contains extremely specific language concerning Open Source.

Identifying Dependencies
Okay, so now you have a project you want to use and you've found its license. That's great, but does your favorite new project depend on any other Open Source projects? It's very common for a project to require one, five, or even 30 other projects to do its job. Some of these projects may come with the one you chose, but it's frequently up to you to find them yourself. There are two key reasons why a project might not include its own dependency: 1.) the pre-requisite is assumed to be universal and so everyone should already have a copy laying around, and 2.) licensing conflicts prevent including the pre-requisite. In either case, you have to make sure you get exactly the right version(s) of the required projects, check out their licenses, look at their dependencies, and so on down the line. IBM includes certain Open Source software, such as Apache, in WebSphere so you should already have the dependencies you need if you're a WebSphere user. OpenLogic's BlueGlue addresses the dependency issue by displaying all dependencies for any Open Source project you select.

Installing the Software
There's a lot of installation help on the Web. If you Google "installing Apache" you come up with thousands of hits, the first handful of which are good-quality documentation and tutorials by the Apache Foundation and others. The bad news is that many projects have little or no installation documentation, or the documentation is there but it's obsolete. Expect to spend lots of time searching mailing lists, Googling for answers, and exercising your trial-and-error debugging skills if you're trying to use any but the best-known Open Source projects. This is especially true if you use a lot of commercial software, such as WebLogic, and want to integrate it with Open Source projects. You'll find that the Open Source community, in general, directs its collective efforts to integrating with other Open Source projects hosted by the same parent organization, such as the Apache Software Foundation or Codehaus; heavy support for commercial applications is still somewhat rare.

Managing Configuration Files
Some people consider configuration and integration to be part of installation, but they're really separate steps. Installation involves tasks such as finding and unpacking files, installing and configuring dependent projects, and meeting global pre-requisites (e.g., memory, disk space, OS patch levels, etc.), whereas configuration is making the project work once it's installed. This typically requires activities such as choosing passwords and port numbers, locating driver files, modifying system boot scripts, and editing various property files to make the project ready to go. Once that's all done, you'll probably want your new project to integrate with other projects already on your machine. For example, you'll want your shiny new application server to use your existing database or allow your newfound IDE to build your code. Again, plan to dedicate some serious time on Google and mailing lists to make your system happy.

Running Standard and Custom Tests in the Target Environment
Your brand new system is installed and presumably up and running. Now what? Well, how do you know everything is really working? You don't want to manually check all those configuration files, build scripts, and server test Web pages every time you change the system, do you? The answer we're looking for here is "no." We want the computer to do the work, so we need to find or write some tests to prove we got things right. That way we'll be better able to keep up with changes in the future.

There are two main kinds of tests we want for this job: standard and custom. Standard tests do things like making sure our database is up and running and is correctly responding with test data on the correct port. You can write these tests in many languages and with many tools, but the key is to make them exercise the basics so they keep on working after you tweak your environment. This way you'll always have some bedrock on which to build your custom tests. We create custom tests to prove that our particular use of the Open Source projects works like we expect. For example, one custom test might deploy a J2EE application to our application server and make sure that we can still log in to its Web application and get reasonable results when we click on the "My Account" link. Once we have a set of standard and custom tests in place, it becomes much easier to stress our environment with new Open Source projects and new versions of the existing projects without fearing that we're breaking everything.

Keeping Current with Security Patches and New Versions
You finally have your environment deployed and are happily using it and the next thing you know there's a critical security patch. What do you do? It's important to keep up-to-date in the Open Source world because things change so rapidly. It's not uncommon for Open Source projects to release more than 10 times a year, and that's not counting emergency patches. When you add up the changes to an entire stack, the level of effort required to keep up becomes daunting. As an example, our BlueGlue application provides an easy way to install a complete J2EE stack that includes JBoss, Tomcat, Hibernate, MySQL, Log4j, and two other small projects. The Open Source communities behind these projects made 49 releases in 2005 alone. If you want the latest bug fixes and features, plan to revisit each project in your stack at least four times a year and be sure to keep up with each of their mailing lists on a daily basis to avoid critical security flaws.

Getting Support
There's a lot of grumbling about support in the Open Source world. We think the real problem isn't that there's no support, but that there are too many options around support.

• You can support the software yourself. This is the option many developers choose, especially for small development tools. Usually there are mailing lists, other users, and some documentation to help you out. If the piece of Open Source software is relatively small, this is the option most people take.
• Some Open Source software projects have an obvious vendor backing them. Red Hat and Novell support Linux, MySQL AB supports the MySQL database, and JBoss, Inc. supports JBoss.
• You can buy support from any number of companies or consultants.

OpenLogic
OpenLogic's mission is to make open source-based software development and deployment easier and more efficient through their tool BlueGlue. As open source software has gained popularity, many companies have tried to take advantage of the quality, flexibility, and license-fee savings that open source software offers. There's one caveat: they have to contend with significant integration, maintenance, and support costs in managing their open source infrastructure. OpenLogic and their premier product BlueGlue offer an automated way to install, configure and manage open source software. Whether your organization is in the process of transitioning to open source or facing advanced challenges, OpenLogic can provide the right tools and support to speed and enhance your development and deployment success.