views:

39

answers:

2

Over the last few years, I worked in several product-based organizations; all in the same country, and all with a presence at multiple geographical locations locally, and off-shore.

Each firm had it's own in-house framework for it's products. Where the product was ported to a different language/technology ( windows sdk/vc -> web/java ) a new framework was created along the lines of the original one, which actually makes sense because the original framework probably had a bunch of business logic defined which actually worked.

The good thing about frameworks is that it probably speeds up development on the product. It also reduces cost because new developers can be told exactly what they have to do, and where/whom from to seek reference. Few developers actually ever get around to figuring out the nuts-and-bolts; which also means they can be replaced with less cost to the firm. As a corollary, the core business logic is only known to a select few ( usually those who started the firm ).

Is using an in-house framework to safeguard 'Intellectual Property' a common occurrence globally?

+1  A: 

Companies I worked at, rather replaced their 'in house' frameworks by standard or common open source frameworks.

But, yes, sometimes we define some common libraries/services, which ideally have no dependency on the used frameworks, as Business logic should!

HeDinges
A: 

If someone is sufficiently motivated, then they can figure out your IP. If nothing else, they can steal the object code and decompile it. Your real task should be to figure out who those people are and promote them enough for them to want to keep working for you. I think it's a poor business plan to explicitly set up a situation where your developers are essentially interchangeable, because the skill level of such developers would have to be incredibly low and therefore you're paying for shoddy work and trying desperately to set up a simple and strong enough framework for virtually anyone off the street to be able to use it compentently.

jprete