The New CIO’s Open Source Decision



decision.gif To open source, or not to open source? That is the question that CIOs have been asking themselves for the better part of a decade. And while the argument for open source grows stronger every day, especially at the enterprise level, questions still remain. Being the new CIO doesn’t help either. You just never know what political minefield awaits you.

The other day I found myself sitting quasi-comfortably in an interview for a CIO position. This particular organization had a technology environment that wasn’t necessarily all that complex, but it was deemed mission critical to their operations. At one point in the interview, the CEO asked me the following question:

What are your views on open source versus proprietary/COTS (Commercial-Off-The-Shelf) software?

There it was, laid out before me like the proverbial holy grail of interview questions. I felt much like Olympic snowboarder Lindsey Jacobellis probably felt as she was on the final portion of her gold-turned-silver medal run in the snowboard cross event. All I had to do was coast to the finish line – don’t showboat, or get too fancy – just stay the course, and the treasure would be mine. This is one of those questions that as technology professionals, you have unknowingly rehearsed so many times at networking events and break room conversations that it can rattle off the answer about as fast as you can pour your next cup o’ joe.

Generally speaking, before an interview, I will have researched the company, its technology, and its principals to the fullest extent allowed to me by the major search engines, my personal business networks, and other “valued” resources on the net (such as searching the major job boards to try to find some hiring profiles for their technologists – a great way to begin gathering intelligence about their business model and system architectures). Unfortunately, I had very little information on this firm’s technology platform, so my canned (but well thought out) answer to his question would have to suffice. There would be no tailoring and positioning this time around.

On the one hand, if you respond with something along the lines of “open source is great; I love it; it is the best thing since 32-bit registers”, you run the risk of isolating yourself if the organization has not embraced the open source movement. On the other hand, if you respond with “open source is folly, give me Microsoft or give me death”, you run the risk of being labeled something completely different, and again, isolating yourself. So, you have to straddle the fence, but you try to do so as intelligently as possible.

I also am very careful not to tread into the political side of the open-source debate. I view things primarily through the business-benefit prism. I could care less about people who use open-source solutions solely because they “hate Microsoft”, “want Bill Gates to slide under a moving milk truck”, or “believe that software should be free”. The “I hate the system” spiel is so 1967.

The following is a longer, more structured version of what I served up as my answer to that interview question, but the general tenets remain:

Implementing a solution grounded in open-source code is not something to tread into lightly, although it can provide certain benefits. However, the extent to which those benefits reach depends upon a wealth of criteria:

1. First and foremost, the obvious business prism questions. What business problem does an open-source tool solve? What inherent business benefits am I going to obtain by using it?

2. New system or existing? Are we talking about building a new system from the ground up with very few constraints, or are we talking about an existing system that is mired with them?

3. What is the company culture, at both the technology and management levels? Will the company’s culture support open-source?

4. Do you have the right skillsets in house, and the right mentality for open source? In other words, will there be a learning curve on the implementation side, or is this going to be a no-brainer for your staff?

5. What are the integration points with your customers (internal and external), vendors, partners, etc.?

6. What are the cost ramifications? What is the total cost of ownership of these systems? True, open-source software is generally freely available, but there could be hidden costs. This goes back to all of the questions above. For example, if you don’t have the skills to implement the solution in house, then there would inherently be some form of training cost, followed by opportunity cost. Or, perhaps services fees to a systems integrator.

7. On the other hand, in organizations where the company culture, the skillsets of the IT staff, and the business requirements are in line, open-source can represent a tremendous reduction in cost/COGS (cost-of-goods-sold) and development timeframes.

Satisfied with my answer, I looked at the CEO, patiently awaiting his response, or perhaps a followup question. Instead, he responded with:

Well, you should know that we are a .NET/C# shop, and that isn’t about to change.

Um, okay, if you say so, partner.

Suffice it to say, he probably wasn’t thrilled with my answer, because in the end, it did leave the door open for open-source as a viable solution. I immediately responded with “but I’m not necessarily endorsing open-source as a panacea to solve all of your technology/business problems”, but I don’t think it did any good.

This particular fellow turned out not to be what I would call an “enlightened” CEO, at least as it pertains to the strategic deployment of technology.

An “enlightened” executive realizes that sometimes, in order to be agile within the marketplace, solutions need to shift. The landscape for technology changes each day – there is no such thing as a “long-term” solution anymore. Every solution we put into place has a half-life associated with it. You just hope that you make the right decisions that will lead to slightly longer half-lifes than those of your competition.

What say you? Share your thoughts on the open-source decision by using the comment form below! No registration is necessary, but all comments are moderated to prevent spam.



  1. Wow, any CEO who insists a business practice or technology “isn’t going to change” must not be thinking beyond the end of the week. I believe in your inaugural podcast you said that the tenure of CEOs was shrinking down to 3 – 5 years… maybe that’s the kind of change he is more concerned about.

  2. Actually, it was the tenure of CFOs, not CEOs, but your point remains!


Leave a Comment

Your email address will not be published. Required fields are marked *