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….
With open source it is quite possible that you end up doing all three. Of course, sometimes buy might not be about money, but buying into someone else’s design and philosophy.
However, with open source you can now do part buy and part build to get your unique solution.
And as a software developer I think there are no common problems, and that open source can apply to all unique problems :-) Of course, this is just my perspective.
I am also convinced that Open Source solutions are the way to go for many problems.
I would add a very important fourth option :
SaaS : Software as a Service, but with Open API.
In SaaS, you don’t have access to the code or the software as you are simply “using” it as a Service.
The fact that a SaaS solution is based on Open Source components or not is immaterial for the clients, because they cannot act on the code.
On the other side having Open API is vital in order to “Mashup” this service with other ones, which can be other SaaS or Intranet ones.
Open Source is great for Intranet applications.
There is, perhaps, a new option coming :
Open Source SaaS,
when an organisation may decide to work on a “unique” problem but is willing to share with others which may have the same “unique” problem. By doing so, sharing the development has many advantages in terms of costs reduction and perrenity of the solution.
They will run the “Open Source SaaS” on a shared infrastructure, like the one provided by EC2 by Amazon.
In my view, SaaS and Open Source will be the two main sources of solutions for CIOs ; it’s too early to tell which ones will be dominant in the next five years.
the best solution: Buy opensource and build it
JP – while I agree completely with your statements in this post, I would like to be slightly tangential and state that to drive proprietary companies towards Opensource solutions requires an increased level of awareness for folks within the IT departments. A major part of the problem as we know is defining the problem itself and having a good understanding of what we are trying to solve. Fo instance, does the internal IT department and the vendors understand whether it is a common problem, rare problem, or a unique problem in the first place? Is the solution going to be generic and can be applied to others in the industry? Is it applicable across industry? And so on. To answer these questions folks in the IT departments need not only internal awareness and understanding of their own problem but also need to know what’s going on outside their organization in other places. Sharing of information through industry networks and participation in such communities (including Opensource as you mentioned) becomes very important to obtain and get educated in this information. It requires management commitment and incentives for the staff to participate in these forums. In my work life, over the last few years, I have found there is a gradual decrease of participants from utility companies (including IT department) in industry conferences, workgroups, and even in the standardization processes for a variety of reasons – most common of those are motivated by cost cutting and evaporation of an incentive program for staff to engage in these activities. Most of the participants these days represent vendors or consulting companies. It is interesting to see that this lack of information and external awareness is correlated to loss of power with vendors in seeking solutions or even buying systems and services. By the same token, a few leading utilities leverage tremendous buying power with vendors driving the vendors to innovate and incorporate features and even not paying any premium simply because they could justify that the problems are not unique as being claimed by the vendor. So while it is important to focus on the nature of our solutions, it is equally important to understand the problem. And the role of industry communities, knowledge groups, sharing of information, relationships, and conversations are vitally important at the problem side of the equation as well.
Thanks Jag. Will work on those comments.
I’m already convinced about Open source being an option to be evaluation against the traditional ‘build or buy’ options.
I’d one more item to the list: Online software. It (software as a service isn’t for everyone), but it’s another very useful option.
Paul (link to online software blogpost)
These are good points. Nevertheless, there should be a strong community or a strong company behind the software to be even evaluated by enterprises. Otherwise there is a risk that the open source stuff will turn into the unique stuff (as soon as the open source developer will loose interest). Overall I like the article.
I like the article. Though this is a quite old post, the principle of choosing among Build, Buy, and Opensource is still valid.