Selling Open Source software in your company

Is open source software right for your organization? Here's how to realistically compare commercial software to open source software and make the right decision based on requirements and risk. Several resources are listed you can use and adapt for your organization, ultimately resulting in organization policy that will satisfy legal, procurement and IT.

Why consider open source? Who can resist a way to reduce costs while finding ways to address business needs? Low to no-cost options are more important than ever. Some organizations have strict policies against such software, but if you can provide valid data to prove open source provides similar functionality to commercial, off-the-shelf software, you may be able to provide some real value to your organization.

Some of the hot issues to address include trademark, copyright and patent information, and warranties and liabilities defined in these warranties. Typically, warranties and liabilities are a huge key in identifying risks with this type of software because the creator is not liable. Who is? More than likely, you will take the software at face value and if anything goes wrong you accept that risk. Period. But again, if you have done your due diligence, you will be making smart choices about whether the risk is worth it or not.

Before you even consider any type of open source, you need to get some key players on board. If you can't get your legal, procurement and risk management groups behind you, you might as well not even start. One way to do this is to provide them with the facts about the risk involved. Hopefully, this article will give you the tools to do just that.

Choosing your definition

As you tread into the murky waters of open source, make sure you have a good sense of the type of software you are working with because there are numerous versions and you need to make sure those doing the evaluation understand what they are looking at. This in itself is a challenge because there are numerous options. From Open Source to Academic to GNU to shareware to public domain, take your pick. In addition, you need to ensure that you either make guidelines or rules to cover all the categories or, if that's not appropriate, then perhaps tailor the guidelines to the specific types of software you are looking at.

For example, you might use different criteria when it comes to selecting desktop freeware (a PDF writer or security utility, for example) versus enterprise software such as Open Office.

Some possible guidelines to help vet freeware:

1. Check with the security group to see if the product meets their needs and has already been vetted. They will keep a central repository of tools that have already sustained the vetting process.2. Read the End-User Licensing Agreement (EULA) for validity of use. Key things to look for:    a. Redistribution specifics    b. Copyright restrictions    c. Other requirements for use3. You also need to review the software for:    a. Support options (is this community based or can a support contract be purchased?)    b. Patch/update policy    c. Documentation (is it available in case you or your users have questions?)    d. Peer feedback (what does the Internet say about use of the tool?). Good sources to conduct this research are:        i. http://www.finance.gov.au/publications/guide-to-open-source-software/appendix-a-resources.html        ii. http://www.securityfocus.com/vulnerabilities        iii. http://www.google.com

4. If there are no issues that prevent proceeding, then get the security group to do a malicious code review. To get that ball rolling provide:    a. Name of product    b. Website    c. Attestation the EULA has been reviewed and the terms and conditions are acceptable.    d. The results of the research from step 3 above.

5. If the product passes the review, the product will be added to the list and certification notice sent to the staff. If it does not, a notice of denial will be sent to the staff.

Presuming the software will meet your business and technical requirements, it's time to do the actual evaluation. This is the tricky part. Having a set of specific standards the software must meet before the process starts will help ensure that whomever does the legwork will come out with the same results as anyone else. If you allow the criteria to be chosen by the evaluating party, then integrity of the evaluation might be in question. This is difficult enough as it is, so be as specific as possible during this part of the process.

Luckily, much research in this area has been done, including the US Department of Defense, the Australian Government, Athens University and a company called Atos Origins. The process defined here uses a combination of factors from each of these sources.

The software must be tested against a commercial package and scored based on performance. Some tests rely on actual use of the software while others require due diligence. Factors included in this evaluation can include:

• Intrinsic durability    o Maturity         Age         Stability (what is its patch/update process?)         Known problems/Bugs    o Adoption         Popularity (who uses it?), peer feedback         References         Contributing community         Documentation/Books for end-users    o Development leadership         Leading team         Management style    o Activity         Developers, identification, turnover         Activity on bugs         Activity on functionalities         Activity on releases

• Services    o Training availability    o Support    o Consulting

• Quality Assurance    o Does the product have a QA process?    o Tools (as in bug reporting or feature request tools)    o Malicious code review

• Packaging    o Source (how difficult is the software to install?)

• Usability    o Administration- easy/difficult?    o Monitoring- easy/difficult?    o End user interface- easy/difficult?    o Implementation

• Modularity

• By-products    o How can code be modified?    o Extensibility of code?

• License type    o Copyrighted    o Modification of source code    o Roadmap

• Maintainability    o Quality of source code    o Intrinsic complexity    o Technical documentation

• Code mastery    o Direct    o Indirect

These are very tangible criteria that any commercial package should be measured against as well. You can then determine some sort of rating scale and based on how the criteria measure up, and base your selection on how well they score. For example, the rating system could be as simple as:

0 Not present1 Present2 Exceeds expectations

Open source software can be a valuable solution for many types of software in an organization. In times of tightening budgets and ensuring that every process is reviewed for efficiency, now might be a good time to sell open source software to your organization. Whether long-term or short, make sure that you base the decision on a reasonable and appropriate evaluation.

Westphal is an information technology professional of 16 years with specific experience in the area of information security. She is currently employed as the CISO of the Arizona Department of Economic Security. Skilled in troubleshooting and process analysis, specific expertise in security areas includes forensics, operating system and network security, intrusion detection, incident handling, vulnerability analysis and policy development. Westphal has been a CISSP since 2001 and a CISA since 2008. You can reach her at kmwestphal@cox.net.

This story, "Selling Open Source software in your company" was originally published by Network World.

From CIO: 8 Free Online Courses to Grow Your Tech Skills
Join the discussion
Be the first to comment on this article. Our Commenting Policies