Yup. Buy, build, and borrow are pretty good categories.

But sometimes you _think_ you're buying, but you really end up borrowing 
or even building.  Other times, you can know and plan on "borrowing" or 
"building" even when you buy a proprietary vendor product.

And as Ed mentions, another very important point -- it's also possible 
to succesfully plan on "buying" an open source product, when you've got 
a vendor contract from a reliable vendor for it.

Jonathan

Edward M. Corrado wrote:
> Karen,
>
> I would argue that in the cases you described below, one is not simply
> Buying. You are Buying+Building. Unfortunately sometimes decision
> makers may not recognize this, or don't take it into account. I think
> that is something that Jeremy hints at when he says Open Source can be
> a buy. My take away in this regard is that there should be some
> recognition in this document that most things will be a combination of
> at least 2 of the 3 Bs.
>
> Edward
>
>
>
> On Fri, May 7, 2010 at 9:48 AM, Karen Coyle <[log in to unmask]> wrote:
>   
>> Quoting "Frumkin, Jeremy" <[log in to unmask]>:
>>
>>     
>>> In general, a Buy approach is easiest to determine TCO, while a  Build
>>> approach is the most difficult. Generally, there are more  unknowns with a
>>> Build than there are with a Buy. The more unknowns,  the greater risk of
>>> inaccurate cost estimates.
>>>
>>>       
>> I know this is the common wisdom, but I've had experiences where Buy turned
>> out to be much more expensive than expected. If the product is mature and
>> stable and you expect to do almost no customizing, yes, then Buy is
>> predictable. But if you're on the cutting edge, it's a new vendor offering,
>> you expect to customize, then Buy can have all kinds of hidden costs. In the
>> end, Buy can be more expensive than Build because you have to struggle with
>> a product over which you have no control.
>>
>> When pitting Buy v. Borrow v. Build, functionality has to be taken into
>> account. What do you want the software to do? How big is the market for your
>> functionality? (that is, are vendors likely to step up to this plate?) Are
>> vendors already offering this?
>>
>> kc
>>
>> --
>> Karen Coyle
>> [log in to unmask] http://kcoyle.net
>> ph: 1-510-540-7596
>> m: 1-510-435-8234
>> skype: kcoylenet
>>
>>     
>
>