March 5, 2009 By David Aden
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
You may use or reference this story with attribution and a link to