COTS or Custom Implementation?

“Everything comes to us that belongs to us if we create the capacity to receive it.”
Rabindranath Tagore

So, what is it going to be?
Is your OctopOSS going to be built up from Commercial Off The Shelf (COTS) software components or are you going to build it yourself?

In the early days of OSS, CSPs had little choice but to build their own as there were few COTS alternatives. However, these days the OSS COTS market has matured and there are many offerings for each major segment of the market. I should note that not all off the shelf products are “commercial” as such. Pre-existing OSS tools range from open source software (the other O.S.S.) through to the proprietary solutions offered by multinational vendors.

In the past, CSPs often had specific needs that could only be serviced by a custom solution. These days, there are many vendors offering highly flexible solutions that are designed to be used by multiple customers and can be configured for any number of network technologies or services.

I believe that this decision is now a relatively easy one to make for the following reasons:

• Off the shelf software is faster to implement
• It has less risk because it has already been built and refined to customer needs
• Multiple implementations would seem to imply that there is economies of scale (although this may not always be true if significant modification / configuration / customisation is required)
• The majority of mandatory features that you need are likely to already exist
• If you are to focus only on your core competencies, a CSP would stick to providing communications services and a software developer would stick to creating, implementing and supporting the OSS that are designed to support the CSP industry
• There is enough maturity / experience in the OSS market that the vendors now have most of the possible functionality covered to support the vast majority of CSPs
• Significant efforts have been made to support standardisation of OSS products so that vendor modules are now more easily interchangeable
• In-house development was previously made out of necessity whereas there is now a luxury of choice.

There is still definitely a place for custom effort:

• To complement COTS products (eg adaptation or supplementary functionality that interfaces with the COTS products via APIs)
• To provide strategic differentiation
  To meet specialised needs that aren’t supported by current COTS tools