Continue reading »]]> None of the Product directly fit 100% to clients’ requirements. There is always customization required little/more to meet the end goals. Customization means integration/modifications in the underlying product architecture and not at the usability level. A very frequent example is search engine customization/integration with the product which is in use in the company for years or integration with their existing CMS or security model.

So what’s the criteria to decide whether an open source product could be selected and customized or an option to build the system grounds up?

Let me give you a case that I came across recently. One of the clients, using a well known commercial portal product, was looking for open source solution in order to overcome issues it’s facing and of course, also the cost. The options came down to either grounds up solution or using one of the open source portal available in market.

Open source portal looks to be the obvious choice at first thought since building a grounds up *Portal* is not the right path both in terms of cost and time to market. But that’s not always right. Here are few things that we need to analyse before coming to conclusion:

• What are the strengths and weakness of the product?
• Are we making use of the product strength?
• Or are we customizing the products strengths and living with its weaknesses?
• Are required integrations supported by product?
• Is product architecture best of technologies breed to be extended easily?
• Is Product architecture extensible?
• Does the product fall in line with the existing architecture and technologies at clients’ place?

Its not always that the effort and time required to customize an Open source product is less since there are cases where we need to do a Proof of Concept and require a lot of time to understand the existing code base.

So, I think that if we are not going to use a products’ strength and instead customize or integrate them, then it’s better to think again. Grounds up solution will at least not have overhead of that product’s features that are not used and its weaknesses.