Build versus Buy versus Opensource

There’s a saying in the US that goes “unless you’re lead dog, the view never changes”. For some reason, between flights, my reading material contained that phrase twice, and it’s not something I would naturally come across in Europe. And it set me thinking.

In the old days, the guys who ran Management Services Divisions just had to build everything, there wasn’t a software industry around. Then the guys changed, and they ran Data Processing Departments, and there was a burgeoning software industry. Soon they called themselves IT Directors, and in time there was a well established software industry.

So, in the days before we had high-faluting titles like Chief Information Officer, there were two alternatives. Build. Or Buy. Now, with the advent of opensource, we have three choices: Build, Buy or Opensource.

The question is, how do we decide? And this is where the “unless you’re lead dog…” phrase comes in handy. It’s all about perspective, and the value of having a different perspective on things. When a difference in perspective matters. When different perspectives are more about illusion than about reality, and therefore dangerous. How to figure out which is which.

And the way I think of it is this:

For common problems use Opensource.
For rare problems use Buy.
For unique problems use Build.

An “internal” IT department (or whatever it gets called nowadays) should concentrate the bulk of its resources on solving problems that are unique to the enterprise that pays them. A smaller number of people within the department should concentrate on buying (and thereby paying a premium for) rare solutions to rare problems. And the entire department should work on opensource principles, participating in the community for problems that affect the community.

You see, the primary reason why “proprietary” companies get upset with things like opensource is because they’re fighting a losing battle. They want us to pay a premium for the solutions to our common problems, because that’s their business model. The trouble is, the opensource movement is bigger and more effective in solving common problems, that is what Linus’s Law is obliquely about. And this creates an artificial tension. With only one winner.

Build unique solutions to unique problems. Buy rare solutions to rare problems. And participate in the opensource community to solve communal problems. Esther Dyson used to sign off her e-mails with “Always Make New Mistakes”. And I think that’s the sort of principle that should drive the internal IT department.

So what I’m saying is, figure out where you’re lead dog. Use your unique perspective to solve your unique problems. Don’t waste your time and effort solving problems where you don’t have a unique perspective. Maybe this way we can all stop building solutions that look like the rear of a lead dog….