build or buy?

I was IMing with a friend in the Dominican Republic tonight. He mentioned how great it is with the open source community to be able to get various products to solve problems.

“In the good ol’ days,” I jokingly opined, “you had to buy everything.”

“Or write it yourself,” he added.

“Key is to know what to spend time and resources on for a given project,” I noted.

Which brings me to a story. Years back, maybe late 80s, early 90s, I did a lot of real-time work on PC programs (in addition to real-time apps on supercomputers). The client I was moonlighting for needed a millisecond resolution timer to record time between image display and test subject making a keystroke. All to support Dr. John D’s research into human responses to visual stimuli.

So, I found some great assembly code that I could write to diddle with the 8250 Timer Chip (if my memory serves me correctly — and if it does, that is scary). Got everything working perfectly, shipped the application, grad students ran all sorts of tests using the software. Perfect.

About two weeks after releasing my application, I spotted a commercially available millisecond resolution timer package from Ryle Design (again, IIRC). Something like $49. I bought it immediately.

I couldn’t rip out my custom code fast enough and put in this new package. After all, unlike my timer code, this package:

  • Was supported
  • Had documentation
  • Had more features (useful ones too)
  • Would get the benefit if many users forcing improvements, bug fixes
  • Would have future enhancements
  • Was code I didn’t have to maintain!

Think about this the next time you choose to build versus buy — or in today’s modern computing landscape — use open source…