Steal Over Buy

[ComponentDesignPatterns | CategoryProtoPattern]

Context

You are determining the requirements for a solution that will contain both pre-built and developed components and frameworks.

A pre-built component exists that might meet requirements, and you need to do analysis in order to understand whether any of the pre-built alternatives meets requirements.

Sometimes the purchased solution is more expensive than the developed one.

Your organization might perhaps have one or more solutions being used currently, and a global in-house-developed standard solution that meets all your requirements is desired.

Problem

How do you decide whether to purchase pre-built components or develop them yourself?

Forces

Solution

Be cautious about acquiring pre-built components. Steal their ideas or steal the source code and use it to leverage your way into a more informed solution that meets requirements not necessarily fully offered by the pre-built alternatives.

Resulting Context

Known Uses

Example

Related Patterns


Any takers? --PhilipEskelin


Interesting point, we recently ran into a case where attaching a VisualBasic data control to one of our data sources meant that the process memory went up to 90MB and down again every time you did anything in design mode --- very slow and tedious. The VJ equivalent did not, so it's fixable. We can't get inside the component, and we don't want to rewrite this standard stuff ourselves. It would be really nice to be able to get in there and see what's going on. --SteveFreeman
EditText of this page (last edited January 20, 1999)
FindPage by browsing or searching

This page mirrored in ComponentDesignPatterns as of April 29, 2006