|
|
|
|
Last week I came across a very interesting article written by David Aden of Government Technology. His article discusses open source software and the misconception that it's always "free". This article raises some very good points that organizations looking into such software should factor into their decision making.
The first point David mentions in the article is that open source applications can require specialized knowledge. Sure, you can slap the install together and get a system up and running, but what happens if you hit a snag? What happens when you need to make a change or add to the existing application? Often times a decision will be made to use something open source or free, and not until later does the organization realize they do not have the knowledge in house to fix the issue or to even make simple changes to the application. Thus, they will have to look at paying a third party vendor to provide the knowledge they lack in house.
The second point he discusses deals with support. Most commercial software vendors provide support for every product they sell. Support for open source applications can be nonexistent, or it can require a third party vendor who provides support for that particular open source application. Depending on the support needed, the cost for such a service could escalate quickly. The communities that exist for some open source applications is very large, and this is where most people look for support in time of need. It's not vendor supported, but often times can be the only place to look for help.
Training is also a concern that David points out in the article as well. Most of his work is in the government area, so for him this was a very important issue. I am of the belief that once you train yourself you should be able to show other people how to navigate the application. The one area that he leaves out that I feel like should be included in this area, is developer training I refer to this as knowledge transfer, which means making sure that developer B can step in and take over if developer A is out or on vacation. Having just one developer that fully understands an application is a huge risk for an organization. Some open source applications have their own unique way of doing things, so all the developers need to understand the inner workings.
David's last point in his article is risk. When selecting an application for a large scale organization, often times different factors are taken into account regarding the health of the company providing the application. With open source projects the same factors do not exists, so other factors must be taken into account. The organization must also plan for the scenario that at some point the open source application may not be kept alive, meaning whomever has been keeping up the application decides they will no longer be offering updates or maintenance to the application. As David points out, when looking at the health of an open source application an organization needs to look at the size of the user community, number of installs, etc...
With all this said, an open source application can still fit the needs of an organization. When making a decision, an organization just needs to keep all topics above in mind when making their choice. It all comes down to needs and the knowledge of your in house developers.


May 3, 2009 at 10:06 PM Open source projects are reserved for individuals who have the patience, the perseverance, the knowledge, and the time to manipulate code to make a custom program do things that may not be available in proprietary software. With these human qualities, an engineer will eventually create a high-quality open source project that behaves well to satisfy a niche.
Sharon Solesbee, CIS, ITN