Software packages come in two varieties, a paid license, commercial off the shelf software, (COTS) or a free license, open source software (OSS). While both versions offered similar functions and design, the user interface in many cases can be identical, there is always an underlying risk in implementing and using open source software, especially for in business.
In taking on this risk there are several factors to think about prior to implementing any OSS package. I’ve listed five to think about below and provided some additional items to think about for each. Feel free to send your thoughts to us at firstname.lastname@example.org.
A significant issue surrounding the use of open source software is licensing. Often times in the lengthy acceptance terms the license forbids the commercial use. This eliminates pretty much any use outside of the home, or school. When a company chooses to proceed, there is an inherent risk that the license holder could bring legal action for the improper use of the software. Any revenue earned could be at stake here. One method of risk avoidance here is to consider deploying software now commonly available as freely licensed open source software (FLOSS). This licensing method typically allows for free distribution and has a minimal amount of language in its license.
Outside of staff experts, forums, and Google, a company runs the risk of not having a core business application function in required ways. Known defects may not be addressed in a timely manner, and new releases may be slow to market. In some cases, this could require costly workarounds, or abandoning the software altogether. Choosing an industry specific well-known application is usually the best option here. Go to the forums and see how active they are. Look at the participants, do they seem to offer a long history of participation? If so, it is highly likely that documentation and code reviews are solid.
- Cost versus Value
Open source software is often free or very inexpensive. In order to keep costs down, software development companies will cut corners such as documentation, interoperability, and as mentioned above, support. In many cases documentation is left to the forums to create. This means that you may be relying on information that is out of date, or incorrect. It also means that your support personnel may be spending extra time reverse engineering functionality to make it work within your organization. Again, back on the forums, look at the activity. You will want to see current activity, up to date FAQs, and the responses to new users should be positive.
One of the top risks of open source is that its code is open, allowing for a high level of exploitation. Proprietary software, on the other hand, has established teams who’s only job is to identify and eliminate any level of security risk in their systems. When applying user generated customizations or patches, a company needs to be highly selective as you are opening a significant door into your systems depending on setup and configuration. Keeping the customizations minimal and only applying patches or upgrades provided by the development company is the best way to mitigate some risk.
In many cases, software companies will simply determine that the current release is the last. Either is has become cumbersome to support a commercial and open version, is too expensive or maybe the open source is eating into the sale of the commercial version. In any event, a company might have a significant investment in the open source package and they are now frozen out of new releases without further, significant investment. To address this issue, you need to ask how functional is the current release. If you have a long history between upgrades this may be a non-issue. Also, consider the costs to convert to a paid version if available. Can your files, databases, and other related artifacts be converted or upgraded? A yes answer here will further reduce dependency, even if it requires some startup costs.
As businesses begin to have more options available to them, additional considerations need to be made when selecting a software package. Many of these open source packages can become replacements for their off the shelf counterparts with some careful assessment, and risk mitigation.