Comment

01 September 2003

An open book

Available source code can work wonders, but watch out.

By David Braun and Nancy Glenn

Open source software has been such a growing trend over the past few years that it has turned into a buzzword within the information technology industry. In many cases, some confusion has grown as to what it means to say something is open source, and why such software exists.

There are several misconceptions about how to define open source software. Open source is often incorrectly lumped together with open application program interface (API) or open specification software.

Open source software has traditionally meant the uncompiled source code has gone to the general public with an acceptance of some license agreement. Some examples of these are GNU Public License (GPL), Berkeley Software Distribution (BSD), and Lesser GNU Public License (LGPL). These agreements allow you to download the software source code, compile it, modify it, and possibly sell it, as long as you provide a means to retrieve the original source code. Although in many people's minds open source means free, there are some companies now shipping the source code with their purchased products—open source does not mean just free software.

Open API means that sufficient documentation comes with a software package to allow a programmer to use it in other code he or she is writing. Open APIs are common with software libraries where you purchase code intended for use within your developed code.

An example of this is purchasing a collection of graphical interface beans (temperature and pressure gauges, dials and scales) to use in one or more applets that are the user interface to equipment controls. You may not have received the source code for the temperature gauge bean, but you get documentation on how to use the bean, and what interfaces and connections are available with this bean.

Open specification means there is a published document that describes how to build a piece of software. The most common example of a specification is standards development. Once the standard undergoes documentation, you can read it. An open specification is one that is freely available to anyone who wants a copy, without cost or membership requirements. A good example of an open specification is the World Batch Federation XML schema. The organization published the document with a license that allows anyone to read it and use it for development.

Why open source software?

There is no simple answer to why highly talented programmers develop open source software. Those who develop open source software for resale often express a belief in the goodness of sharing source code, as well as lowered costs for their development and an expanded development staff. It has become very common for companies to use the open source process for research and development, allowing the market pressures and interests of the global programming community to guide and power their new development activities without the overhead of hiring a development team. The motivations of programmers writing software they intend to give away for free are often unclear. The core motivations are being recognized as great programmers by their peers, seeing a need for a particular tool, "pizza ware" (getting free pizza), or the challenge of a new idea.

Whatever reasons these programmers have, we as users should support them. In many cases that is exactly what has happened. For example, Apache is a well-known web server that has surpassed many commercial servers in popularity. With this growth in popularity, some businesses are backing the Apache Software Foundation with resources to continue to develop, support, and maintain the software.

Companies that develop software under the open source model gain the benefit of having a mass of talented people working for them for the right to develop and tinker with the source code. A couple of examples of this are the Mozilla project sponsored by Netscape and Netbeans sponsored by Sun Microsystems.

Both of these companies use the open source implementation as the core of their supported product. The benefit to them is they acquire the innovation of new development within a common framework they based their product on. This reduces the cost of developing new features and increases the robustness of the software due to the number of people using the tool and developers fixing the bugs.

On the plant floor

When considering any software package or tool, there are three things to analyze:

1. Cost (initial and ongoing)
2. Integration issues
3. Flexibility and extensibility

Cost: The obvious cost savings when using open source software is in the initial cost and yearly maintenance. Open source software is significantly cheaper than its proprietary cousins, if not free. In the case where a vendor has used free open source software within their product, the cost of the off-the-shelf product may actually be lower for the bundled feature set. If the open source software you are considering is free, you can download it, compile it, and run it. You do not break any laws by doing this. This can be a real advantage if you are prototyping an idea for your information technology (IT) system and do not have significant development budget for capital software purchases.

The potential cost pitfalls of incorporating open source software into your systems come from the fact that you are now using a publicly supported piece of software, with no help desk support, no technical staff to call, and generally no purchasable expert support. You are the support. There may be a news group that has activity or someone willing to help you in times of need, but in general your organization will have to grow and maintain some support heroes. This may seem like a high cost, but if your organization already has internal IT support, you are more than likely going to find a guru already exists somewhere, or can be easily trained. This pitfall is not really any different than that which currently exists if you use internally developed software.

Another potential hidden cost in using open source software comes from an expected level of expertise. Although some open source products do not make assumptions about or require programming capabilities from the user (products like Open Office) most open source components assume that you have true programming expertise. Most do not come with configuration wizards or the extra hand holding you may be paying for in proprietary software. Depending on the capabilities of your in-house staff, you may also find the lack of purchasable training or available trainers may slow down development as the staff works through the product learning curve. For most programmers, this is not a significant issue; for those who are new to programming, this could have an impact on the project timeline.

One advantage for manufacturers is you can quickly and cheaply prototype an IT system. The major pitfall to avoid here is keeping the prototype from production until you address all the support issues.

Integration issues: Another big potential for manufacturing IT is that open source tools lend themselves to easier integration than a tool with a proprietary API. Why is it easier? This is a complex question tied to issues of flexibility, code understandability, and response of the user/developer communities.

• Flexibility: The main flexibility advantage is you have access to the source code and can extend it as needed to fit your environment. If a needed link to other systems does not exist, you can build it. If a function is not fully comprehensive for your internal processes, you can edit the function code and make it match your needs. This tends to help reduce the cost of an integration project. The pitfall to avoid here is modification of the core software of the package. You must support this type of modification for each upgrade of the system. This is the same pitfall you would face with upgrades of non–open source tools. The advantage here is that if you participate in the community, you may get your changes integrated into the software product.
• Understandability: Open source software tends to have more comprehensive documentation. In most cases, just as the source code is editable, the documentation is also editable. Many people have read it, had input to it, and made changes. There tends to be more documentation of how the tool actually works. The application also tends to have documentation detailed enough even for someone who wants to work on the source code, and it makes no assumptions about what you do or do not need to know. If you are not a technical user, this can sometimes mean that the documentation is overwhelming or a little harder to navigate.
• User communities: If you have ever waited for a phone or e-mail response back from an application support staff, you know how frustrating and potentially expensive this wait can be. Although a few open source tools have support you can also purchase, most get support from news groups and/or mailing lists for users and developers. Be sure the tool you choose has an active user support community—these groups are often more responsive than phone support, and you can often get fast replies and help in your troubleshooting. Not all tools have an active user community, so check this out. If there is no user community, be sure you have staff who understand the tool and are cross training several people, so you are not stuck when your one guru goes on vacation or leaves the company. If you are using open source software in a twenty-four hour, seven-days-a-week production critical system, be sure you have an excellent disaster recovery plan, as well as access to the Internet anywhere your IT staff might need to troubleshoot this tool. This gives them quick access to the answers they need to get production back on line at 3 a.m.

Flexibility and extensibility: The flexibility of open source software continues to have an impact beyond integration. The obvious advantage here is in cost and time; because you can twiddle the code, you do not have to pay the company or wait for their timeline to make the modifications you need to run your business.

Using open source software in manufacturing systems also gives you the ability to grow the software and the system as your business needs grow and change, rather than replacing the entire system. With careful system design and some forethought, you can build a system with open source tools that allows your business to grow its infrastructure at the rate it needs. The organization does not have to spend $3 million for a full-featured manufacturing execution system when all you really need or want is a tracking system that allows routing. You can implement the minimal solution with tools that allow you to grow the feature set. However, it is also just as easy to use bad software design that blocks system growth, even with open source software. Although open source software is often a good choice for a flexible and extensible system, it does not guarantee one. Flexibility and extensibility over a long period of time are more characteristics of a good design than of any particular software characteristics.

Open source–based software also has an advantage in robustness. With many more people using it and reporting/fixing bugs, open source software that has been around awhile tends to have far fewer open bugs, and the turnaround time for fixes is generally shorter.

There are risks

As with any IT decision, there are some risks to using open source software. You need to consider these carefully and see if your system is a good fit before blindly jumping on the bandwagon. After doing a careful risk analysis, you can make the decision to try open source or to stay with a proprietary solution. You will need to consider all the dimensions of your system, including criticality to the enterprise, uptime requirements, support issues, and security.

Security is an issue of ever-growing importance today, and you need to be sure that the open source solution has sufficient security to lock down your mission-critical business processes. Critics of open source say security is a problem because a community of developers with unknown intentions distributes the software. But supporters counter that such a community will help find vulnerabilities and bugs and will respond more quickly than private firms to patch holes. The problem with open source code is it accelerates the learning curve of a cyber-terrorist because access to the source code is free and readily available, said Scott Hissam, who leads an open source research and development project at Carnegie Mellon University's Software Engineering Institute.

Although we have touched on the issues of support, it needs to be repeated that one of the biggest risks to using open source tools is there is no direct line of support—there is no support hotline to call in the middle of the night to help get your system up and running. For most of the tools, there is either a message board or some FAQ that can help you. Some businesses will not use open tools in mission-critical systems for this reason, while others feel that even the cost of having trained in-house support was worth the other savings.

If you have a highly mission-critical system, you will want to be more careful in your risk analysis and consider things such as the size of the user community, the size of the developer community, and the activity levels of the community. One of the risks with free open source software is the death of the project—death in the sense that there is not active development or support of the software. The reason this happens is the nature of the open source communities and technology. For example, a FORTRAN-based web server would not be a good choice, because it is not a mainstream project. A better choice would be to look at what others are running and to look at the activity for the project. Note, however, that in today's volatile software and IT environment, even a company producing a commercial off-the-shelf product could fold, be bought out, or make a strategic change in product direction. This is a consideration for any software purchase for a mission-critical system.

Okay, so by now you're thinking, "If there are all these risks, why should I use an open source tool in a mission-critical setting?" Because of the significant cost savings, in a highly critical setting we recommend using open source tools that have become real industry standards—for example, the Apache web server. It has become a commonplace tool with many vendors shipping it, integrating with it, or sponsoring it. You also want to look at the stability of the software, both how long it has been out there and how many interim releases and bug fixes have released in the past year or two. You should expect at least one major release per year. However, too many interim releases are a sign that the software is still in a highly changeable state and could change underneath you.

You also want to consider if there have been no updates in a long time, is the software dead? Does it still do what you want? Is the rest of the world going to leave this software behind?

Ethics

There are a couple of responsibilities you assume when using open source tools. These are not legal or contractual obligations, but ethical responsibilities. Remember the cost and time savings the tool is helping you to achieve, and pay it back for good IT karma.

First, make sure that you have the internal support structure to handle the open source software. This means that you are going to spend time and money allowing staff to train themselves on the tool. It is not fair to your end users or your staff to plan to use a tool that has no purchasable support or training, and expect them to become experts on the system over their lunch hours. If you take this "free time training" approach, your end users will be let down the first time there is a crisis, and your developers will be left feeling like they were failures. Give them the resources they need to make your site a success.

Second, become involved with the community. Too many times, companies use a tool and never feed anything back to the community. This is much like the television and radio viewers who watch PBS or listen to NPR, but never send in a check during the fundraising drives. It does not have to cost you dollars to become an active supporter. Here are several ideas that you can employ:

• When you find a bug, tell the community about it.
• When you find a bug and fix it, tell them.
• Advertise that you use their tool.
• Donate resources to the community (such as hardware, money, bandwidth).

Open source tools are a good fit in the manufacturing setting, even in mission-critical systems, as long as you follow the following rules of thumb:

1. Do a careful risk analysis.

2. Have a good support plan and staff in place.

3. Support the tools and all of their communities.

4. Understand the capabilities or limitations of your developers.

5. Have a good system design to allow for growth and flexibility.

If you have completed all of these steps and choose to incorporate open source software into your enterprise, your company will reap savings. AIT

Behind the byline

David Braun is director of new technology at R&R Visual Systems in Rochester, Ind. Nancy Glenn is system architect/technology lead at Delphi Automotive Systems in Kokomo, Ind.