Open source is well on the way to overturning any lingering not-invented-here attitudes for software components.
In the past it was always easier to write it yourself: it’d do what you want; you’d know it’d work. Compare that with talking to a vendor, having someone from sales visit, doing an evaluation, getting the funding approved… in many cases it’s not worth the hassle.
If you need some software function today, you can google around, figure out which projects have some momentum, check the licensing and try it. That’s great, but the more interesting thing is how open source projects can embody the best practices, or at least a very reliable implementation. In those cases you need a good reason not to be using an open source implementation by default. (Such reasons do exist.)
Talking to Jono the other day made me realize that it’s not so clear-cut. When you add in agile development, how do you balance the trade-off between doing the simplest thing that could possibly work versus the research time to find a framework that might, actually, turn out to be a huge and immediate time-saver. I suspect the answer is to bet on the easy-to-understand (often smaller) frameworks: you get up and running faster so you get the experience of using the thing, and that’s the only time you find out if it’s any good or not.
Related buzz words: cheaper faster better, innovation happens elsewhere, small pieces loosely joined, Occam’s razor.
