The question was "How can an enterprise make the most out of open source involvement without triggering internal issues or risk?"

I think that perspective is poorly chosen. There's risk in contributing code to an open source project -- you might contribute valuable IP in the form of copyrighted material or trade secrets.

However, there's risk in not contributing code -- you have a suboptimal open source product or one that you have to repeatedly patch every time a new mainstream release comes out.

And even if you eschew open source, thinking that you'll avoid the IP risks in contributing code, you have a different sort of risk -- vendor lock-in, application inflexibility, and so on.

No matter which option you choose, there is risk involved. The value a specialist organization like IT brings to the table is that it can use its collective experience and knowledge to identify the path forward that best balances opportunity and risk, knowing that there is no such thing as a risk-free choice.

We do a disservice to open source if we paint it as some kind of perfect Nirvana, where all IT problems go away. They're *different* problems, and if we (meaning the people working with the open source product) do our job well, they're smaller problems (i.e., lower risk).

Contributing code is the right choice for some IT organizations, and those that do must put processes in place to track what's contributed and ensure it does not pose unacceptable IP risk.

When you contribute to an open source project, intellectual property is contributed to a larger community and you lose some control of it. Not all control, because contributing to open source is different from putting something in the public domain. Depending on the license, you might still be able to exercise defensive termination, for example, if someone sues you for patent infringement.

Therefore, if you contribute, know what you are giving away and know, for example, if you have a patent in the area. It also might be good to know if you've previously licensed that patent to someone because they will probably be very interested in your new found love of "free."

Make sure what you are donating is actually yours. If it is not coming from another open source project with the same license, you probably want to have certificates of originality from your developers.

Have a policy for how employees can work with open source projects in their free time. You probably don't want them to contribute your IP that happens to be in their heads to a project that they do in their off hours.

Some businesses do believe that the software they create contains valuable IP, although the truth is in most cases this is not the true – unless of course you are a software vendor!

Its important to recognise that the business IP and software can be separated quite simply – business rules and data are the real business IP, software is a tool that works with the rules and data. The industry I work in is insurance, one of the most commonly used tools is Microsoft Excel. No one (except Microsoft) considers Excel as their IP, the business IP is actually the data and scripts that make up the spreadsheets created in Excel. The software is simply a tool business uses to simplify paper work and manual tasks - helping reduce mistakes and increase productivity.

If you apply this principle to open source in general, then companies have little to fear with regards to contributing to open source projects. Obviously this is a generalisation and each business needs to decide for themselves, however the principle works across most industries, be it graphic design, banking, logistics or insurance - software is a tool and usually not the business IP.

Matthew Tomlinson

Founding Member: OpenQuote
Director: Applied Industrial Logic
Sponsor: OpenSourceInsurance.org

Most open-source projects, and all of the top projects (Linux, Apache, etc.) require contributors to submit code as individuals, not as employees of Company X, Y, or Z. When they do so, they also generally assign copyright, while simultaneously assuming the legal burden that the code they've submitted doesn't infringe someone else's intellectual property. It's possible that a court would look past this to the company employing the developer, but I think the mechanisms in place to protect companies who contribute are quite robust.

But this is probably the wrong question to be asking, anyway. Yes, there's always a risk when contributing to an outside project, but any such risks are heavily outweighed by the following benefits:

1. Open source reduces the risk of IT project failure. Many (most?) IT projects fail. Open source costs less and, where a company is behind the project, support is paid annually. This, coupled with open source's "try before you buy" approach, means that the likelihood and cost of a project failing go way down.
2. Open source reduces the risk of downtime. I talk with large enterprises all the time whose biggest complaint about proprietary software (besides the cost and bloat, of course) is that it's a black box. They have no idea what is going on beneath the covers, so to speak, and so if trouble arises the customer is completely at the mercy of the vendor. This may be fine for non-critical applications, but it's a serious issue for company-critical applications and infrastructure. The employees' ability to understand and, where necessary, modify the code is of huge benefit.
3. The way contracts are written these days, open source may also help to reduce the risk of litigation. If you've read a software license recently, or negotiated one, you know that customers increasingly are leery of any risk associated with running the software nevermind modifying it. The ability to modify the code to remove allegedly infringing code quickly is a great boon to mitigating damages.

Open source is not a legal risk waiting to happen. In my experience, it can be the exact opposite of this. Open source is a great way to reduce risk.

John Powell
CEO, Alfresco Software
http://www.alfresco.com

In my experience (largely in midleware infrastructure around Spring), very few companies are concerned about giving away competitive advantage through contribution to open source infrastructure projects. The benefits of having others to help maintain the code are a clear business driver.

The obstacles are typically the difficulty of getting contributions through legal, which can be immense. Many large companies have legal departments who find it hard to understand why the company would give away any IP without compensation.

If there's any danger, I think it is to the open source projects, unless the granted IP is clean.