How to make a decision on open source software Should your next software project be rooted in open source? The timing could be right for trying it out.  Servers, work stations, point-of-sale systems and even PDAs run modified versions of Linux, an operating system that serves as the flagship product for open source. While Linux may be one of the best-known open source products, it’s just one of myriad open-source software tools encompassing everything from simple calculators to enterprise resource planning tools. With so much code and so many programmers involved, corporations find themselves having to ask: Why do these products exist, and are they ready for our use? The answer to the second question is yes. Surveys conducted in November of 2003 and 2004 by the market research company BZ Research show that the open source JBoss Enterprise middleware system, for example, is the most widely deployed Java application server in production environments. Apache’s Web server and its derivative products run more than 60% of the world’s Web servers, and both IBM and Hewlett-Packard receive more than US$1 billion in annual revenues for open source services and support. Open source is not only ready for the enterprise, it’s already running in it. What Is Open Source?But before businesses can understand the benefits of this new model in software development, they need to understand what it is. Open source is not a single product or company. It refers to software that is distributed along with its underlying source code. It comes with a licence that grants free use and distribution of the software package. This gives end users the right to modify the software to fit their specific needs, while protecting the original author’s rights relative to the code. There are various licences for open software, and these licences permit the end user to do everything from customizing the software to selling a commercial derivative of the product (Table 1, on page 10). The licence varies by product, so just as companies must find a product that meets their needs, they must also find a licence that meets their needs. The primary benefits of open source lie, not surprisingly, in its openness. Its being freely available lowers the costs of acquisition, but more importantly, with the right to see and modify the code, companies find themselves in the unique position of being able to tailor their software to the way they run their business. With a proprietary product, the source code access that is needed for customization is usually available only to a provider’s most valued customers, and usually at a high cost. Open source essentially gives every user that most-valued-customer status (Table 2). Open source software has other benefits as well. Because of the "communal" approach it takes, this software tends to evolve quickly and organically. Having so many different programmers working on a particular piece of software creates the effect of a huge programming team. The improvements that they make and share are aggregated into new releases through the efforts of a core team, often only after thorough inspection by the open source community. Proponents also argue that in many ways, open source software is more secure than proprietary. Since so many people see the code itself and can comment on it, they maintain, security flaws are detected more readily. In contrast, only a small team ever sees proprietary software code, leaving potential flaws and security vulnerabilities undetected and uncorrected for years. Open source software has its benefits, but it is not a cure-all. To maximize its open source investment, a company needs to understand, long before implementation, how the software will help. Linux began its rise in enterprise software at an infrastructure level (file servers, Web servers and other basic networking functions), placing it outside the realm of most end users. This allowed for a relatively simple initial integration, because only the most knowledgeable users needed to access the software. Enterprise software, on the other hand, provides its greatest benefit when it is used widely—and effectively. Establishing a new working environment for end users is extremely involved, requiring the collaboration of not only technical staff, but also business administrators and data analysts. While a well-designed product can greatly reduce operating costs, a poorly implemented system can suffer costly issues, ranging from difficulty of use to data integrity problems. Understanding the ProjectTo understand exactly how open source software (or any software, for that matter) can fit its needs, a company must first determine the scope of its software development project. The first step in this process is to evaluate the services available relative to the needs of the users. This is done by developing a comprehensive user-needs analysis (Table 3). This analysis should examine each of the company’s processes that would be affected by the software project. Current processes should be exhaustively documented, as well as analyzed for their efficiency. If there are desired changes in the process, now is the time to investigate and to establish those revised and improved processes. The bottom line in this analysis is to establish what the company wants its new software to accomplish. Far too often, a company is forced to fit its business processes to the strictures and limitations of the software. Instead, the software that is being implemented should support those processes and make them more efficient. This is one area where open source software has an advantage: because of its flexibility, it can be modified to fit a company’s specific needs. Custom development of proprietary software is an alternative to open source, but there are often limitations in how much a proprietary program can be modified. Open source gives a programmer an open canvas. Proprietary customization, on the other hand, may be more like paint-by-the-numbers art, where you may be able to change some colours, but the picture itself has been determined. Scope of WorkThe next step turns the needs analysis into a scope-of work document. It determines how the business processes specified in the needs analysis will be supported and streamlined by the project. The result of this "requirements analysis" will be a full listing of desired user features and design criteria. This step will help gauge the time and costs involved in developing the software, and it provides the company with a design model. With this document in hand, the company is now in the best position to decide exactly which open source software product will offer the best starting point and which fee-free licence is the most appropriate. For instance, if the company is embarking on a database-centric project, it is likely to narrow its choice of open source software products to three of the most pervasive—MySQL, PostgreSQL and Berkeley DB. Each of these products has its own advantages and strengths, and the company’s in-house IT department or its outsourced software developer can determine the best fit. These products do not, at this point, offer quite as much feature richness and robustness as some of the best-known proprietary software products. However, as an Aberdeen Group white paper on open source databases reported in 2004, "They have made significant strides over the last few years and can now offer surprising performance/scalability, manageability and programmer support. In flexibility, their standards-based approach can often make up for their lack of specific features for integration with other parts of a software infrastructure, such as enterprise application integration." The Aberdeen white paper noted that "IT buyers value these open source databases not only for their low licence costs but also as the database for Web-friendly applications that must be created quickly in-house." Gauging the InfrastructureThe next issue to consider is the infrastructure that will be charged with customizing, delivering and supporting the new software application. An IT manager must be prepared ahead of time to determine what skills and services the internal staff can deliver, and what products should come from an external provider. The advantage that the internal staff typically bring to the table is a strong understanding of the infrastructure and process management within the company. These internal people are on hand and already familiar with the end users and their needs. The flip side of these advantages is that the internal staff may have difficulty maintaining updated skill sets, and their responsibilities for supporting existing products can often interrupt a new product development cycle. Outsourcing the open source software development project answers some of these concerns by providing a larger staff dedicated to IT and product development. Outsourcing firms rely on a larger pool of developers to maintain skill sets, and in many cases the higher hourly cost is offset by their value in knowledge transfer. If a company does decide to use an outside firm, it should be sure that the firm has business analysts to guide and assist their developers. Project SuccessThe success of a project hinges on understanding the rules of the business, and being able to deliver a system that implements these rules in a timely fashion. Project timelines can spiral out of control due to mid-process redesign or business rule re-definitions that are frequently required when technical and business leadership roles are not defined at the outset of the project. Also, even with a complete feature set, users may reject the application if it is delivered a year after the promised date. The best advice for project leaders is to define goals and required system design in language that is understood not only by project leaders, but also the programming staff and end users, before development efforts begin. Once the development project is under way, end users should have opportunities to participate at each defined milestone. This allows them to contribute to the end design and provides them with the sense of ownership needed for a successful rollout. This involvement will also make final implementation simpler, because key end users will already understand how the application is supposed to function and how it will apply to them in their jobs. Throughout the development process, regardless of whether the development is being done in-house or by an outside firm, there is no more important task than testing. Each aspect of the software should be tested repeatedly, and as the end of the development process nears, the entire application must be tested to be absolutely sure that there will be no surprise bugs once the rollout occurs. This testing should involve not only commercially available software development testing tools, but it should include a full run-through of the application using data that duplicates the data that will run on the application once it rolls out. Staying ConnectedOnce the open source development project is complete and the application is rolled out, the company must maintain an ongoing connection with the open source community. If the development was done in-house—or if it was outsourced but the relationship with the development firm ends upon the rollout—an in-house IT employee should be designated as the liaison. If the development was outsourced and the relationship with the outsourcer will continue, the developer would be responsible for that aspect. The purpose of this liaison function is to stay connected with the source of the software. If the company installed proprietary software, it would stay connected with the vendor to deal with upgrades, patches and other issues. With the amorphous nature of the open source community, the burden may fall on the company to stay connected for the sake of ongoing support and awareness of ongoing development of the software. Often open source groups use newsletters and email announcements to keep their member bases organized and informed. Some groups, however, prefer to use more real-time discussion methods such as bulletin boards or Internet Relay Chat (IRC) discussion groups. Regardless of the manner of communication, it is a best practice to keep up with the community before, during and especially after the implementation of an open source product. The nature of the open source community is such that it tends to be a very helpful group, so having at least one employee who is attuned to what is going on there, and who builds relationships, will help whenever a need arises to solve a problem. ConclusionGiven a dedicated and carefully designed development process, open source can be a strong foundation for meeting a company’s needs, and it provides a great groundwork for a product that truly fits the way a company does business. Open source products are maturing quickly, and while the majority of early implementations have been in small- to mid-sized businesses, open source is increasingly finding acceptance and success within the ranks of larger businesses. As the Aberdeen Group white paper predicted, by this time in 2006, the market will have reached "a tipping point at which a larger range of vertical applications and line-of-business programmers will find open source databases’ low cost and association with other open source software such as Linux a good reason to include open source databases in their plans. "At that point, open source databases will begin to have a significant impact on the overall database market, on database pricing and on the readiness of the market for an enterprise-scale open source database," the paper said. With the wide availability of support resources and a growing community of developers, this is a good time to begin rethinking future IT strategies, implement software that works more easily with users, and benefit from a large and growing community of programmers and businesses. C. Pitman Baker is president and founder of C. Pitman Baker & Associates Inc. (www.cpbinc.com), a custom software development firm based in Irving, Texas. His company has developed numerous open source applications for companies of all sizes. Christopher Gamble is director of development with Pitman Baker. Reprinted by permission from Business Communications Review (www.bcr.com).