The Challenge Open Source Presents to CIOs, Part II: The Solution

“The important thing is to plan a strategy, to set guidelines on where and when open source products are to be used. IT shops are scrambling to set open source policies, but almost no one has implemented one with any teeth.”–Mark Driver, Gartner Group

In last week’s posting, I discussed the challenge open source presents to CIOs. In it, I analyzed an interaction between Sun CEO Jonathan Schwartz and an unnamed CIO, who professed that no open source was used in her organization and then was surprised when Schwartz noted that 1300 downloads of MySQL had gone into the organization in the previous six months.

I went on to describe the risks this kind of invisible open source use presents. The most obvious — and the one usually focused on — is the legal risk: if you don’t know you’re using open source, how do you know whether you’re complying with its license obligations? However, as I said, this is actually a smaller risk compared to the operational risk of having unknown software components inside the company’s infrastructure: how do you offer SLAs, ensure proper support coverage, and develop appropriate employee skills when you don’t even know what you’re running?

I often hear from people that they don’t understand why open source should be handled any differently than any other IP. Put another way, this question might be phrased, what about open source causes it to be different than proprietary software? After all, both proprietary and open source software are both copyrighted intellectual property distributed under a license, so they must be the same, right?

The reason open source requires implementing a new set of processes reflects the fact that existing processes are configured around the practices and assumptions of proprietary software, which are not present due to the unique licensing and availability of open source.

Consider the usual flow of obtaining proprietary software:

• Software engineer recognizes need for new software component
• Software engineer consults with manager
• Manager builds business case
• Manager consults with finance, legal, and procurement
• Manager obtains budget
• Procurement creates RFP
• Company obtains software
• Engineer implements solution

As you can see, there are many steps and many organizations involved in this process. While the process can require an extended period to execute, it provides the opportunity for the entire organization to become aware that new software is going to enter the company’s infrastructure. In other words, this process ensures no surprises, because all affected parties are involved.

By contrast, consider the usual flow of obtaining open source software:

• Software engineer recognizes need for new software component
• Engineer downloads open source component
• Engineer implements solution

The ease of downloading open source addresses one of the major complaints about IT: everything takes too long. Using open source enables IT organizations to be far more nimble and creative. Unfortunately, if you compare this process with the proprietary-focused process, you can see what it lacks: the opportunity for other important groups to become aware that this new software is going to enter the company’s infrastructure. That is to say, open source decisions never enter the established process because no permission, and, crucially, no budget is required to obtain it. Since the established processes are typically triggered by the budget process, open source use is essentially invisible to the organization.

Clearly, as the quote from Gartner VP Mark Driver indicates, IT organizations have to put policies in place to move open source use from invisible to visible so that they can be sure they have addressed the risks associated with open source (and, I might add, to also ensure they can achieve the many benefits that open source offers).

I would go even further than that. Unless policies are tied into organizational processes, it’s difficult to impossible to know whether the policies are being observed. The critical thing is to marry policy with process and integrate open source management into overall IT processes. Only then can you be sure that the organization is using open source appropriately. Of course, as the quote concludes, hardly any IT organization has got open source governance in place.

It might seem daunting to try and figure out how to move forward with implementing open source governance. Where to start? How to know if you’ve identified all the open source currently running in your infrastructure? How to ensure you’re complying with open source license conditions? Well, one way to start is to do some Internet searching on the topic. If that seems too … random, let me offer another way to learn. I’ve written a whitepaper outlining how to move from ad hoc open source use to a full integration of open source use within existing IT processes. If you send me an email at bgolden (at) navicasoft.com, I’ll be glad to forward a copy to you.

No matter how you decide to find out more about open source governance, it’s critical you do so — and soon. Otherwise, you run the risk of being in the shoes of the CIO described in Schwartz’s anecdote: unaware of what software you’re responsible for, and potentially liable for serious hurt.