Re: [CODE4LIB] Buy, Borrow, or Build
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 li...@kcoyle.net wrote: Quoting Frumkin, Jeremy frumk...@u.library.arizona.edu: 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 kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [CODE4LIB] Buy, Borrow, or Build
Quoting Frumkin, Jeremy frumk...@u.library.arizona.edu: 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 kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [CODE4LIB] Buy, Borrow, or Build
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 li...@kcoyle.net wrote: Quoting Frumkin, Jeremy frumk...@u.library.arizona.edu: 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 kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
