Did you forget your: Username / Password ?

Microsoft

TechWell

Home

CM Journal Articles

Open Source Strategies

Written by Adam Kolawa

Wednesday, 15 February 2006 05:32

Strategies for Building Applications with Open Source Software

Open source is the current rave in the software industry. It is making great progress because of Linux—an operating system that truly works. People are all a-bustle about open source and are beginning to look for an open source option appropriate to all their application needs. This brings up questions: How can you take advantage of open source when you’re building applications? Are there any dangers involved in using open source?

As often happens, people are taking the extreme route and want to do everything in open source because they don’t need to pay for it. That’s logical thinking. You can’t beat free! But, are there other costs involved besides monetary costs? Certainly open source applications alleviate spending, but shouldn’t there be a balance in all that we do? What is that optimal balance between open source and traditional proprietary software applications? The purpose of this article is to explore both open source and proprietary software, and then uncover strategies for building applications with open source software.

Open Source Versus Proprietary Software

Sometimes a price tag with the word “free” attached to it is more than a good thing—a blessing in disguise. What a deal! Other times, what appears to be good, turns out to be quite problematic. Herein lie the dangers of open source software (OSS). As far as OSS is concerned, it is important to evaluate your needs and determine whether “free” will really be free, or if it is a better option to invest in the stability and support of commercial software.

It is a reasonably wise and safe move to use OSS as a foundation. An infrastructure can be built on top of it. In fact, many companies do this, for example, with network servers and some of the DNS services. Linux serves especially well as a foundation for such low-level utilities. We’ll touch more on this later.

As you move to higher-level utilities, such as mail servers, it becomes much more advantageous to go with commercial software. Why? Stability. Flexibility. You could take the cheap route. But, your operation will not work well, which is why it is highly recommended—and well worth the investment—to purchase commercial software.

The same concept applies to application servers. When you build an application, sure, you can go with open source. But, if you really want the performance scalability of a big application, you need to go with a commercial application server. When it comes to new applications, new languages, or coding in any new form; stick with proprietary software to avoid bugs.

If a line were to be drawn between when you should and when you should not use free software, it would be this: use it for basic server operating systems, network support, and directory services. These are all utilities for which OSS is a safe, wise choice because many IT-related applications are well-used and well-tested. The programs that run on top of these utilities are what you should purchase. Certainly, if you venture into the realm of “free” for your entire infrastructure by use of public domain software, by all means, the option is there and yours for the taking. But, heed this warning: you will be setting yourself up for many headaches!

Maintenance and Support for OSS

Over the years, Linux has become quite stable. Maintenance and support of it is practically a non-issue because so many people know about it. This situation is atypical of open source software. Only when enough people know about it can enough people maintain it. Typically, high-level OSS applications are not well known. Merely segregated groups of people truly know them. Therefore, it is not likely that you will find someone to depend upon to make a fix in the event that something breaks.

Strategies for Building Applications with OSS

Let’s paint a picture. Think of each part of your infrastructure as a separate building block. The bigger the block, the less specialized it is and the more people involved in its development. Take a look at Figure 1. The bottom block—the foundation—is the operating system. Everybody uses it. To some extent, as you build atop the foundation, the programs become more specialized. The next layer consists of more blocks that are slightly smaller, which reflects a lesser interest amongst developers. Each block represents various servers, such as applications servers or network servers. The top layer is made up of even smaller blocks. Each block represents an application and from a development perspective a specific niche.

Figure 1: Infrastructure Built Atop Foundation

The greater number of knowledgeable people, the lesser the risk

The point is that the more people who know an OSS program, the lesser the risk you take in using it. Most likely you have people on your own team who know it and can solve any problems you come across. But, as you build an infrastructure and the programs get more and more specialized and less and less people are interested in developing the application, the higher your risk in using open source. This is when it becomes wise to invest in the support of a commercial company.

The broader the subject, the greater number of knowledgeable people

Another point is that of quality. When any subject is so broad, in this case, an operating system, there are a lot of developers who can work on it and maintain it. But when it becomes specified there are only two or three people who will work on it in their free time. Quality is difficult to obtain. When it comes to open source, high quality can be achieved with programs that are in general use because there’s enough critical mass of people working on it. But high quality cannot be attained for the more specialized programs because public domain does not draw enough people in to work on it and improve it.

The more interest and hours invested, the more refined the product

The public domain has limited power. The power that exists is derived from the investment of time of a conglomerate group of people who work in the industry. Many people must be interested in a program in order that they contribute the hours. The key word here is “many.” Enough hours must be accumulated to develop and refine a product.

How do you determine whether you should use OSS?

The answer might sound contrite, but it’s weighing the power of the open source product. Do you have knowledgeable resources on your team to solve any problems that occur? Is the product popular enough to be a product of high quality? This is where you draw the line. If your answers to the questions are “yes,” go for open source. If the answers are “no,” turn to commercial software.
OSS Applications at Work

Commercial software is not going away. But that does not mean that open source has not had an effect on it. Sooner or later there’s going to be a very good open source operating system for the desktop and devices because there are enough people interested in it. That’s something that is likely to bite into Microsoft—with the exception of the company’s more specialized products. IBM on the other hand isn’t as likely to be affected, since their focus is more on specialized products. That is why IBM supports and does not fight public domain software.

What about the smaller, independent software vendors? How does open source affect them? And what does all this have to do with you? Independent software vendors can actually benefit from OSS. Commercial developers can learn much from the experience of other developers who work on open source. In fact, it’s quite useful to take pieces of public domain software and use them as models. Doing so makes it relatively easy to build products to the market and support them—specialized products that you need.

A couple of great examples of this are two different automated error prevention products. Jtest, which is a powerful static analysis and Unit test tool for Java, actually uses an Eclipse-based GUI, Junit as its testing framework, and some OSS metrics tools. Another example is SOAtest—a tool for testing WebServices on the client and server side. It uses the following OSS resources: Apache Xerces XML parser and SOAP library, Xalan XSLT processor, GNU Regex Expression Library, and DNS Java tools. So all in all, it is safe to say that open source can create great opportunities for commercial vendors—especially the smaller, independent companies.

Conclusion

The fact is that when open source software is well known and in knowledgeable hands, it can be a wise choice—especially for basic server operating systems, network support, and directory services. Leave the more specialized open source programs to commercial companies. They can refine the code and build new in-demand products to market that are reliable and come with support. In short, be wise. Take time to investigate and figure out whether free is really free, or if an investment is the better option.

Dr. Adam Kolawa is cofounder and CEO of Parasoft, a vendor of automated error-prevention software and services based in Monrovia, CA. Dr. Kolawa, who is the coauthor of Bullet-proofing Web Applications (Wiley, 2001), has written and contributed hundreds of commentary pieces and technical articles for publications such as The Wall Street Journal, CIO, Computerworld, Dr. Dobb's Journal, and IEEE Computer. He has also authored numerous scientific papers on physics and parallel processing. He holds a PhD in theoretical physics from the California Institute of Technology.

Set as favorite

Bookmark

Email this