When faced with using open-source software in your company should your first reaction be:

1 )Run in terror.
2) Pick up and cuddle your stuffed Steve Ballmer doll while shouting “No!”
3) Refuse to even consider it
4) Deal with it.

Even if you think open source is the dumbest idea to hit IT since Microsoft Bob, number four is your only real choice.

There was a time when SCO and Microsoft could pull the FUD over some people’s eyes and convince them that using open-source software would be leaving your company open to lawsuits or that the only support you’d ever get for your open-source software would be someone who looked like he’d been playing Jesus in a third-rate road show of Godspell. Those days are long gone.

Do you use Oracle or MySQL software for your database needs? How about SugarCRM for your customer relationship management? Perhaps Compiere for your ERP (enterprise resource planning)? Yes? Congratulations, you’re an open-source user and you didn’t even know it.

Believe it or not, It come as a surprise to some CIOs that they’re already using open-source software. One financial services company CIO discovered to his dismay, according to Sun CEO Jonathan Schwartz that his “no open-source here” company had already downloaded MySQL 1,300 times in the last six months.

Of course, many of you are already using open-source in your corporate IT infrastructure and you’re already well aware of it. According to CIO’s recent survey on open-source use in the enterprise. 53 percent of you were already using open-source applications, and, looking ahead, 10 percent of the rest were planning to do so in the next year. If you throw in the CIOs who are already using open source, but just don’t know it, it’s clear the open source revolution isn’t happening. It’s already happened.

Now, the question is how do you manage it? Specifically, what are the best ways to manage it.

If you look at open-source purely as a source code issue, you come up with one set of best practices. According to a recent report by Palamadia, which sells software and services for tracking open-source code within a customer’s code base, best practices are programmer and code focused.

“Open source is inherently no more risky than commercial software,” said Mark Tolliver, Palamida’s CEO in a statement. “The majority of open source projects provide a patched version to any issue within hours of discovery. Users of open source, however, need a way to quickly and accurately verify what components they are using and associate them with known vulnerabilities so they can retrieve updated versions. Without a mechanism in place to perform this function, organizations put themselves at risk for introducing security vulnerabilities into their code base.”

Palamida goes on to recommend five best practices:

1.Development of open source use policy and implementation of policy enforcement (whether via manual our automated means)
2. Educate and train key stakeholders on open source use, risks, and policy
3. Create a Golden Vault of approved, stable, open source for download
4. Vet incoming open source prior to use (mitigate license and security challenges)
5. Perform periodic code audits to ensure  compliance with other best practices

This is useful advise. It’s also useful for companies that don’t think of themselves as being in any way, shape or from an ISV (independent software vendor). Your company may not sell a line of code, but if it delivers any kind of product, which might include open-source code, you would be well advised to make darn sure that you pay attention to these policies. If not, you might end up like that well-known open-source software provider Verizon Communications.

Verizon!? Yes, Verizon, which illegally used BusyBox, a lightweight set of standard Unix utilities commonly used in embedded systems, by distributing Actiontec MI424WR wireless routers to its FIOS customers. At day’s end, Verizon settled out of court in a lawsuit brought by the SFLC (Software Freedom Law Center) on behalf of BusyBox’s developers. The moral of the story? Don’t assume that you’re not in the software business even when you’d never think of your company in that way.

Let’s say though that your company actually wants to help develop open source. After all, Nokia clearly believes that the best use for their purchase of the Symbian operating system was to immediately open source it http://www.cio.com/article/407963/Nokia_Buys_Rest_of_Symbian_Will_Make_Code_Open_Source). Nokia, the experts agree, is doing this to further strengthen their competitive position.
That said, if your CEO and the board can get their minds around the seemingly paradoxical idea of actively supporting open source development to further the corporation’s goals, how should they go about it?

According to James McGovern, enterprise architect for the insurance and investment giant The Hartford, in an interview with RedMonk analyst Steve O’Grady (http://redmonk.com/sogrady/2006/01/12/open-source-analysis-a-qa-via-james-mcgovern/), the single best practice for companies taking this approach is “deceptively simple: don’t just take, give. The percentage of commercial entities that actually give back to the projects they utilize – whether it’s in the form of code contributions, or other rewards – is low, when compared to the volume of firms that rely on it. But this is shortsighted on their part, for reasons that are not particularly complicated.”

Best open-source practices go well beyond coding though. For one thing, it’s clear that before you can practice open-source best practices, you need to be practicing software inventory management. For example, here’s a slightly adapted list from Computer Associates’ best software inventory management practice list:

1) Conduct an annual, company wide software inventory/audit using an asset management tool so you know what you’ve got — How many licenses? Are you still using this program? Are there programs without proper licenses or support? Are there programs you should dump because they’ve been replaced?

2) Create company wide software standards, including a list of supported/acceptable software, and a policy stating that all software on your systems is company owned and that illegal or potentially dangerous software is forbidden. Lots of luck with getting everyone on board with that one! Still, it’s a policy worth attempting no matter how much people like playing World of Warcraft on company computers.

3) Centralize software procurement processes and obtain programs only from approved software vendors. If possible, establish a software controller function with responsibility for your firm’s software inventory and license agreements.

4) Monitor your software assets and uninstall anything that’s outside of company standards.

All basic stuff right? Of course, right. But, like keeping current backups and making sure system patches up to date, these basics are ignored far too often.

Notice something? None of this is open-source specific. That’s an important point. Open source software management best practices are, in many ways, the same as any corporate software best use practices.

If you keep that firmly in mind, and act accordingly, your company can be just as safe using open-source software as it would be only using software bearing Microsoft’s, or some other proprietary company’s, stamp of approval. Come to think of it, considering how Microsoft breaks the law on a regular basis: Vista capable PCs, Microsoft vs. the European Union, etc., etc. maybe you’re better off with open-source software anyway.