"Open source" has come a long way and with the new administration adopting the open source content management system Drupal to power the recovery.gov Web site, open source's visibility will likely get another big boost. Speaking from the standpoint of a developer, the number of tools, utilities and programs available under open source licensing continues to be very exciting. But it is also true that confusions still persist about what it is and, in particular, about its costs. "Open source" and "free" are not synonymous -- though there is a relationship between the two terms.
As with any engineering product, using software requires more than just having access to the application. To take a more concrete example, let's consider the task of building a bridge over a stream -- it involves more than just having a crew pull up to the river and start building. The environmental impact, the needs and concerns of the surrounding community, how to make a connection to the electric grid and even connecting to the existing roads are all factors that need to be taken into account. And that all occurs before the bridge is built. Once construction is done, it requires ongoing maintenance, inspection, repairs and a means of controlling the traffic on it.
But let's get a bit more precise about the analogy. Before the bridge is built, someone needs to have done the engineering work to figure out how the bridge is put together, the size of the beams, etc. A fabrication operation then makes the beams and other pieces needed to do the construction. If the bridge is small, it might be assembled in a shop and transported to the target site. If it is larger, then the fabricated pieces will shipped to the site and assembled in place.
Open source projects are similar: the architectural work has been done and has been made available for general use. Many of the pieces have been fabricated and often those pieces have been assembled and the "bridge" is just waiting to be transported to the installation location.
And while that means a lot of work has already been done and made available without cost, it doesn't mean that the new bridge will be "free." The fact that a general blueprint exists is nice but it may need some tweaking to make it fit for the specific use. This requires a resource that can read and update blueprints. When working on open source projects, you can't necessarily depend on a vendor to supply that resource -- you may have to supply it yourself.
To keep things in perspective, the following is a quick list of the items that commonly need to be taken into account when deciding on open-source software alternatives:
Many open source software applications, like commercial software, require configuration which can require expert-level knowledge. For example, the Apache Web server requires administration which is primarily done by editing one or more configuration files. Configuring Apache is not difficult but if your staff doesn't have existing expertise in it, then the total cost of ownership will need to include either hiring experts or getting staff up to speed.
By contrast, Microsoft's Web server also requires a great deal of customization but is all done through a graphical user interface. Both require expertise. This issue also shows itself when selecting an application that requires ongoing configuration or changes as part of routine use. For example, many open-source content management systems exist and are quite popular. But, when evaluating options, it is important to look into the technologies on which they are built. For example, if your staff's expertise is in .NET or ColdFusion, the no-cost price license for a PHP-based system may be appealing until you need to get something changed and find that
the skills don't exist within your organization to make it happen.
It is safe to assume that any software will require support at some time or another. Commercial software vendors usually provide support for their products. With open source, support options can be less clear. Some open source projects have spawned companies which specialize in providing support but if a company doesn't exist to specifically support a specific open source application, it is important to factor in the true support costs.
Large open source projects often have large communities of users who work to answer questions and address issues. But, in most cases, interacting with the community is most efficient when someone with technical knowledge is asking the questions. So, when making decisions about how to handle support, your planning should include having someone on staff or under contract who understands the product and who can, as needed, interact intelligently with the online community.
Particularly for government agencies, training is an important issue to consider when selecting software. Again, training on open source software is often available from traditional training companies -- at least for popular or large open source applications. But for smaller applications, no formal training may be available. This problem can be compounded by the tendency for some open source applications to focus more on functionality and performance than on user interface. For technologists, the functionality and performance is key and the user interface is something that can be adjusted or "lived with." But for end-users, the user interface is the application.
The intelligence and usability of the navigation, the quantity and quality of online help and access to solid training materials or classes can have a greater impact on application adoption than the application's features. As with support, open source projects often have online training and frequently there are community members who dedicate themselves to helping with documentation and training. But, the safest route for an agency is to have on staff someone with technical knowledge of the application and an ability to train others to fill in the training gaps when needed.
With commercial software products, it is possible to examine the financial health of a company to make a determination about whether the company might be around in five years. With open source, the same evaluation needs to be done but there's often no company to examine, just an online community that is supporting and developing the application. The size and activity of that community may be part of the evaluation, the number of installations of the software may figure into it and the general media buzz about it can also be a factor. The point is the evaluation of viability and longevity is at least as important to do for open source software as for commercial, but the ways to evaluate the software are different.
None of this is to say that commercial software should necessarily be preferred over open source. Open source software provides great possibilities and in some cases is the preferred solution. But it does mean that agencies shouldn't make the mistake of equating "open source" with "free." Total cost of ownership" may be less with open source in the long run, but it is not "free" and each case needs to be evaluated against the business purpose, the availability of ancillary services and the level of in-house expertise available with lots of emphasis on what in-house skills are available.
"Open source" in its strictest sense refers to the availability of the original work done by an application's developers. But, there are other aspects of what "open source" means in terms of application licensing. Applications are written by developers in a language that is readable by humans. It may require
specialized knowledge to read, but it is readable. In order for the application to actually run on a machine, it must be turned into a language that is understandable to the machine. The process by which the human-understandable form is translated into the computer-understandable form is called "compiling." Once the program has been compiled, it will run on a computer but is no longer readable by humans.
Most of the desk top applications we're familiar with such as Word, Excel, etc. are only available in compiled form -- Microsoft does not make the uncompiled version available. By contrast, open source software does include the uncompiled form so anyone can make additions or changes to it and compile it themselves. But, according to the Open Source Initiative, "open source" refers to more than just the handling of the application's code -- it also relates to the terms covering the way the application is distributed. Full details are available on the OSI site but the general concept is that open source software must remain open source and freely available to anyone for any purpose. If it is used as the basis for other products, those derivative products must, in their turn, abide by the open source distribution rules. This could have implications for agencies that use open source software as the basis for their own application development projects. In most cases, it will not be a problem but certain is an issue that needs to be considered.
So, though "open source" strictly speaking refers to the widespread availability of original developer work-product, it has come to mean much more as regards the ownership of software and the restrictions (or mandated lack of restrictions) on its distribution.