An Introduction to Open Source

This book is about software engineering using the Commons, but we need to introduce how Open Source works. Some readers may have heard about Open Source but may have no idea what Open Source is about beyond the availability of the source code.

Open Source is about considering software as a product of one's effort, much like an author who writes a book, or a musician who composes music. The creator of the software believes in giving away the sources for everybody to look at, manipulate, and experiment with.

The Three Cs

At an O'Reilly keynote address in 2003, Tim O'Reilly, the CEO of O'Reilly, talked about Open Source and its impact on the industry (see www.oreillynet.com/pub/wlg/3468 ). In that talk he mentioned the three Cs of Open Source:

1. Commodization of software

2. User - Customizable systems and architectures

3. >Network-enabled Collaboration

Commodization of Software

Software is quickly becoming a commodity, with Open Source leading the way. Software is plentiful and easily available, which means that the price of software has dropped massively. This does not mean that nobody cares about software, just that people know it is available and plentiful. As a result of commodization, software applications have become plug-compatible and can interact with other pieces of software. People do not question whether or not two pieces of software can interact; it is assumed that they can.

User-Customizable Systems and Architectures

In a traditional software application paradigm, software is programmed against specific interfaces that may not change for years at a time. In an Open Source paradigm, change is constant. The objective is not to sell the software, but to sell the services associated with the software. So, if a customer needs an extra database field for a specific custom solution, that field can be added without much fanfare from the developers of the original software. In contrast, with today's closed source software often that is not the case. In the end what drives the application development cycle in the Open Source module is not the APIs but the data that needs to be manipulated.

Network-Enabled Collaboration

Open Source could have happened only with the advent of Usenet and the Internet. Developers on the Internet collaborate virtually and make things happen. Traditionally, making things happen required setting up meetings, making phone calls, and discussing the situation. The effort required to start an Open Source project when you are using Usenet and e-mail is virtually nil, so the effort required to shift resources to another project is just as low. The result is that Open Source applications constantly shift as determined by the needs of the individual projects and their programmers.

So What Is Apache Server?

Apache Web Server is primarily a HyperText Transfer Protocol (HTTP) server used to serve HTML content. Apache Server is a mutation of the original National Center for Supercomputing Applications (NCSA) Web Server. In the early years of HTTP programming, an HTTP server called the NCSA HTTP server was developed at the NCSA. With time, however, another team created a set of patches to modify the original NCSA sources. The patches improved the NCSA HTTP server and provided extra capabilities. Soon the patches became so numerous that people started referring to the patched server as a "patchy server." At this point the "patchy server" became a new HTTP server called Apache Server. Apache's quality, flexibility, and availability of sources separated it from the rest of the field (it was a novelty that the sources were available). Around the time of Apache's inception, in 1995, Open Source was beginning to be coined as an expression.

As of this writing, Apache has a 62 percent market share of currently running Web servers, but the statistics can be debated. The debate says that in terms of the Secure HTTP (HTTPS) (typically e-commerce) protocol, the statistics are not so lopsided in favor of Apache Web Server. Although this is correct, it is misleading because these types of sites use commercial products, which are based on the Apache source code base.

Apache works for four major reasons:

• It is Open Source : Apache is not owned by anyone; rather, it is the intellectual property of the Apache Software Foundation (ASF). It's available in source code format, so anyone can download the sources, modify them, and distribute the changes in binary or source code format. Apache works because its license scheme is very liberal and allows users to do whatever they please with the sources. The only real restrictions are that you cannot call Apache your own development, and if you release a product using Apache sources you must reference Apache.

• It works very well : Apache works anywhere and at any time. The Internet has introduced the concept of working constantly because the Internet does not rest and information can be requested all the time. Hence, software must work continually. Consider the PC. For all of what it has brought to the industry, it continues to be unstable. Unlike PCs, HTTP applications must always work. Apache fulfilled this requirement and hence has been used extensively at large Internet Service Providers (ISPs).

• It offers third-party support : There is a huge amount of third-party support for Open Source. Literally thousands of third-party modules can do whatever is required. It is possible to write any type of server-side application using third-party support.

• It works : Was this mentioned? The fact that Apache works so well should not be underestimated.

But Is There a "Real" Company?

Many people who want to use a piece of software want to have a company they can complain to when there are problems. No such official support is offered for the Apache Server software. However, there is plenty of free support, and many third-party companiessuch as IBM or HPoffer paid support. The ASF is a non-profit organization and is responsible only for the organizational, legal, and technical support of various projects that improve Apache software. Some of these are listed here:

• Apache HTTPD Server : The Apache HTTP Server is an Open Source-based HTTP server usable on multiple operating systems and environments. From humble beginnings, the Apache HTTP Server has become an Internet Server platform in its own right.

• The Apache XML Project : This project is intended to provide base XML applications based on standards created by known standard bodies. Examples include XML (Xerces) and XSLT (Xalan) processors.

• Jakarta : Jakarta is the home for the ASF server-side Java projects.

• Commons : This group is dedicated to managing a number of components shared by various teams . Many of the projects outlined in this book are part of this group .

• Web Services : Within the Web Services group are a number of Web service- related projects: SOAP, the Axis toolkit (discussed later in this book), and XML Remote Procedure Call (XMLRPC).

• Ant : This project is dedicated to maintaining and developing the Ant build utility.

• Perl : The Apache/Perl integration project brings together the full power of the Perl programming language and the Apache HTTP Server. Using mod_perl, which is an Apache HTTPD Server extension, you can write Apache modules entirely in Perl. In addition, the persistent interpreter embedded in the server avoids the overhead of starting an external interpreter and the penalty of Perl startup time.

• PHP : PHP is a server-side, cross-platform, HTML embedded scripting language that uses the Apache HTTP Server.

The ASF and the projects that it supports or collaborates with are all OSS projects. The ASF supports other groups not discussed here. If you want to investigate the various groups, visit www.apache.org .

How You Can Interact with Open Source

In classical terms, when somebody mentions Open Source and using it, the thinking is that any development using Open Source must be Open Source as well. That is a fallacy. There are two ways to interact with Open Source: as a provider and as a consumer. As a provider of Open Source, the developer creates software that will be used by other people. That aspect of Open Source is beyond the scope of this book. This book focuses on the consumer aspect of Open Source, just like anybody would use an API from another software vendor.

Using OSS Programs As Components

The Open Source components focused on in this book are from the Commons. However, you should not stop there; you should be actively looking and trying out new components. Only by being aware of what is available can you best solve your software problems. Following are a number of steps to take when you're experimenting with different Open Source components:

Visit source code sites every day : Regularly visit sites that feature OSS so that you can be aware of what packages are available. Two good source code sites are www. freshmeat .net and www. sourceforge .net . If you have a problem, you can often find its solution in a different package. For example, if you need HTTP client code, then that code may be found in an HTTP proxy server. An HTTP proxy server might be acceptable because a proxy requires an HTTP client; hence, the code might exist and be well written.

Learn to use search engines : Searching the Internet is a learned skill. Only by practicing can you find what you need. For example, use Google ( www.google.com ) to find help with generic topics. When you get your search results, look for words that are used repeatedly and then execute a new search based on those found words.

Download software that looks interesting : You can get new ideas by downloading and looking at interesting software. Doing so allows you to think laterally and look at problems in a different context.

For a specific problem, download multiple packages : When you're investigating a solution to a particular problem, always download multiple packages. This is important because often the first or most common OSS program may not solve your problem.

Unzip and compile the downloaded packages : When you find a package that you consider a solution to a problem you're having, the first step when you're evaluating the package is to compile it. If it does not compile and you cannot fix the problem in under five minutes, downgrade the usability of the package. A good OSS package always compiles within five minutes out of the box. Once the package compiles, run the demos and downgrade the package if the demos do not automatically execute successfully.

Compile the package as a static library within your application : The purpose of this step is to integrate the OSS program with your sources. At this point you can see if there are any compile problems. Typical examples of problems are redefinition of standard data types and conflicting error-handling schemes. The biggest problem with OSS is that every OSS package has its own error-handling scheme. If compilation fails, downgrade the usability of the OSS program.

Compile the package as a shared library without your application : As with the previous step, the purpose of this step is to see if there are any compile-time problems. In addition, note that in each of these steps, the OSS program was not called or utilized. If compilation fails, downgrade the usability of the OSS program.

Make a single isolated use of the package : In a part of your program, create a function or class and make a simple call. The purpose of this step is to see if there are any runtime errors such as data misalignment or error-handling problems. If there are any problems, downgrade the OSS program.

Attempt to read the source code : In this step you're looking to see if the code is understandable. Experience will show you that legible source code is easier to debug, maintain, and extend than illegible code. Hard-to-read or hard-to-manage code makes your programming life much more difficult. Hard-to-read code downgrades the usability of the OSS program.

See what support is given : Consider the support options of the OSS programs. Good OSS programs like Apache have mailing lists, books, and corporate support. The number of extensions is also important. Extensions of the program provide sample programs, test the program, and show that there is actual interest. The more support there is, the more usable the OSS program is.

Back up your project : This is the last step of no return with respect to your program. Beyond this step you will actually be integrating the OSS program into your sources. By performing regular backups of the project, you will be able to roll back to the original versions of your sources.

Integrate the OSS program into your sources . This is the last major step of integrating the OSS program into your sources. At this point, you can expect a high level of success as far as making the OSS program work for you.

Follow the package : At this point, the OSS program is part of your sources. Hence it is very important that you follow the mailing lists, report bugs , and contribute changes. Only in this way can you ensure that you know how to fix problems when they arise and use the OSS program efficiently .