Sharad brings out his top five reasons why R&D (product development and related areas) has blossomed slowly. Here are some other reasons I can think of:

Software engineering mindset: The local market for talent is heavily biased towards software engineering. Take the average manager or developer and he will live and breathe software engineering, quality and processes. Nothing wrong with that. But a true product company typically has a computer science core comprised of algorithm savvy programmers. If critical product development is to get outsourced, you need computer scientists. Sadly, the local market has few such people. If you don't believe me, trying interviewing a six year experienced technical lead and ask him what a binary search is.  The candidate would likely take offence, not because the question is too easy, but because he is above it in spite of not knowing the answer. He might even respond that he has left behind algorithms in engineering school.

Multi site, concurrent development expertise: To have product development outsourced across the value spectrum (not just low end work) you need to have multi site concurrent development enabled. The offshore developers need to live and breathe the same code base. Regular services delivery models are good at executing tightly coupled, single site development engagements.

Long gestation period and attrition: To add innovative value to a product requires intimate knowledge of the context, be it code or the domain. It takes time and investment to see the returns come. Most companies are unwilling to spend the time and effort and seek quick results. The high attrition in offshore labor markets only make the case worse.

Seeds of failure and the peak of success: It is commonly accepted that captive centers make sense only with scale accompanying it and when the work is strategic enough. As the product outsourcer's share of the business grows, both qualitatively and quantitatively, the case for outsourcing actually becomes weaker. The seeds of failure lie in the peak of success.

The technology lag factor: Products are not static. They need to evolve constantly in tune with market demands and need to aggressively look at incorporating new technologies to stay on the leading edge. Services companies typically absorb technology with a lag factor. There is a certain amount of derived demand for a skill set that needs to manifest before budgets get released for investment in the skill set. The classic utilization mindset. Makes perfect sense in the services world, but it does not help lead the innovation race.

IP concerns: This is a no brainer. Exposing precious source code to someone over whom you have no direct control is not easy and it is not just about the code. The minute you outsource product development and start sharing schedules you are exposing product release timelines, details about how behind you are on schedule, what features and in and what are out. These can be very sensitive.