Joel Spolsky got something right when he says If it's a core business function -- do it yourself, no matter what.
When code generation technology (think community projects like AppFuse and Grails) are becoming mainstream, comprehensive and open source, some companies will still find reasons not to adopt them for side projects that are non-critical to the core business. Some reasons that I have heard:
* Organizational Knowledge: "we don't have anyone else who knows that open source project if you leave"
* They'll break us: "what if the release a new non-backward compatible version?"
* Optimistic NIH Syndrome: "we have half the features implemented in house already - can't we just build the rest ourselves?"
Now sometimes, these reasons for not adopting a side-technology may be relevant, if we think that the side technology may be a core technology in the future, or if it is a non-mainstream technology.
But I think many seasoned developers make the mistake of thinking "how am I going to build it" rather than "who has built this before" as a first line of thinking, especially for non business-critical projects.
So I'll put a twist on Spolsky and YagNi: -
If it ain't core business, think WASABI - "We always should avoid building it".