"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: