Where Open Source Meets Cloud Computing

Open Source and Cloud Computing

Subscribe to Open Source and Cloud Computing: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Open Source and Cloud Computing: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Open Cloud Authors: Elizabeth White, Pat Romanski, Don MacVittie, Anil Rao, Carmen Gonzalez

Related Topics: SOA & WOA Magazine, Open Source Journal, Open Source and Cloud Computing


Thoughts on How to Select Between COTS and Open Source

Organizations continue to wrestle with the COTS vs. Open Source question and continually look for guidance

Organizations continue to wrestle with the COTS vs. Open Source question and continually look for guidance on how to select one vs. the other.  Many organizations make the frequent mistake of basing the decision on the capital investment cost or up front investment with no thought to any other criteria.  While cost is an important factor, there are other areas that organizations should consider as part of their selection process. These include:

1.    Technical
2.    Cultural
3.    Financial

The technical component to the decision is pretty straight forward with only a few minor issues to worry about.  This usually involves an evaluation or trade-study to ensure that the proper feature/functionality exists to support the current requirements, as well as the ability to support the stated enterprise roadmap.  Usually the biggest challenge in this arena is making a determination whether existing functionality in either the COTS or Open-Source product is ‘good enough'.  Experience has shown that at a quick glance, a feature/functionality comparison of COTS and Open-Source products in a specific category will result in nearly identical results, leading somebody to believe that there is really no technical advantage of selecting one vs. the other. 

This is where the ‘gotcha' comes into play. - Organizations have to dig a bit deeper into the details of what truly is supported in both the COTS and Open-Source product to be able to make a good decision.  For example, both products may claim to support a specific industry specification, but on closer inspection one product implements only the required parts of the specification, and the other product implements both the required and optional parts of the specification. This small detail could have big implications down the road, especially if the organization is expecting to leverage items in the ‘optional' part of the specification. Or worse, a product may claim to support a specific specification, but upon deeper examination, it only supports a subset of that specification.

The cultural component of this evaluation is the area that is frequently ignored. As part of the evaluation, an organization should review the composition of both the development team as well as the operational support team and their respective skill sets.  Usually, organizations understand why they would review the development team, but almost always forgot to consider the operational support team.  The driver for this review is pretty simple and it comes down to the particular skill sets of each group.  In general, COTS software tends to have better operational and management tooling available vs. Open Source counterparts. 

So if an operational team were more systems analysts and pure system administrators with little software development background, they would be better served if they were provided tooling that abstracted away some of the more complex details of the system that would be easily understood by a developer.  On the flip side, if the operational team were development minded, there would not be as much concern about the operational and management tooling, knowing that the operations folks would be more comfortable dealing with more complexity.  This is almost always overlooked and potentially a spot for hidden costs, which leads to the third area of focus.

As previously discussed, most organizations tend to look at this analysis based on pure capital investment, i.e. - Is there an upfront license cost? However this is only part of the bigger picture. Organizations need to look at the financial picture from a total-cost perspective, looking at the acquisition and development costs all the way through the operations, maintenance and eventual retirement of the system. In terms of development, the organization should understand the costs associated with using a COTS provided tool vs. an Open Source tool. 

There are situations where tooling will make a significant difference in amount of time required to develop and deploy and this should also be factored into the equation.  In some cases, the COTS tool will provide a significant productivity increase and allow for a quicker time to market. There will be situations where the COTS tool is so cumbersome to install and maintain that an Open Source tool would be the right choice.

The other area already alluded to is the cost for operations and maintenance over the lifecycle of project. Organizations should take into consideration existing IT investments to understand where previous investments can be leveraged and the cost incurred to leverage these systems.  Organizations should ask whether the performance of one or the other allow for a reduced hardware and deployment footprint, which would lead to lower costs.  In short, there is so much more to this evaluation than just the initial upfront capital cost.

As organizations continue to evaluate using COTS or Open Source technology, they have to look past the initial cost of entry to understand the bigger financial picture and overall cost model. It will also be important to dig a little deeper past the typical quick glance to understand the key technical nuances that separate the different offerings. And finally, an organization must understand the skill sets and competencies of both the development and operational teams.  If an organization bases their evaluation on these three areas they will be able to find the answer that is right for them.

More Stories By Chet Hayes

As Director of Government Solutions, Mr. Hayes is responsible for the technical pre-sales delivery strategy and business development for Mark Logic Corporation's Federal Division.

Prior to Mark Logic, My Hayes was the VP of Professional Services for AgilePath Corporation, where he was responsible for client delivery strategy and business development for AgilePath in the Department of Defense (DoD) and the Intelligence Community (IC).

Prior to AgilePath, Mr. Hayes was the Manager, Systems Engineering at BEA Government Systems where he lead the Special Programs SE Team to bring Service-Oriented Architectures (SOA) solutions to the Federal Government.

Mr. Hayes holds a Degree in Computer Science from Brigham Young University.