Integrating Open Source In a Large Consulting Firm?

doc6502 asks: "I work for a global IT consulting company. I have the task of investigating a formal role for using Open Source in our company. We use open source applications and tools internally and at client sites, but the implementations are viewed as one-offs by our local offices. As we are beginning to experience an increasing demand for Open Source solutions, we are looking at trying design Open Source solutions for areas like government, business, and education. What we are looking to do is: formalize and consolidate our global Open Source knowledge to accommodate new and existing client requirements; define a review process that will enable us to quickly review Open Source tools, applications, and so forth; and finally, provide a contribution scheme so we can donate code to the Open Source Community. Has anyone gone through this process? If so, what obstacles did you meet and overcome? What was the review and evaluation process you implemented when reviewing OS tools? Did donating code raise internal legal issues?"

Comments

Good Luck

[d3ik]

1. Formalize and consolidate our global Open Source knowledge to accommodate new and existing client requirements

I'd say the first step here is defining how far you want to go. Do you just want to use some Apache Jakarta Commons libraries in some applications or do you want to deploy a full LAMP stack? Also, what is the purpose of adopting OSS products? Philosophical? Just want some free stuff? PR move?

2. Define a review process that will enable us to quickly review Open Source tools, applications, and so forth

This will probably be the most difficult of all. For every operating system, programming language or application there is at least one open source project. The biggest problem you'll face here is bureaucracy. You'll probably setup some type of review board that approves certain applications/libraries/whatever every couple of months before they can be deployed. But what happens if a bug is found, patched, and updated in version control? Can they deploy that modified and unapproved version? If they can't you lose flexibility, if you can you lose the quality control that comes from the approval process. The answer is somewhere in the middle, but these are questions that need to be asked.

3. Provide a contribution scheme so we can donate code to the Open Source Community. IANAL, sorry. I work for a major IT company and I contribute patches to OSS projects. I just do it under my name, so (as far as I've been told by people who do have a law degree) that releases the company from potential liability.


I went through this same process within my group about a year ago. One of the hardest parts was breaking the "it's insecure if people can view the source" arguments from management. The larger the IT firm the more the ideas of "Intellectual Property" and "Security by Obscurity" have been crammed into the heads of people that make decisions. This is how I sold it:

"It's not about communist hippies in Birkenstocks saying everything should be free. Every web application I build needs a database, an application server and a web server. On top of that it needs libraries that do a lot of things common to other projects. It makes no sense for us to take on the burden of developing these from scratch. It is in our best interest to collaborate with others to build stable, portable solutions that can be deployed en mass without exorbitant licensing fees."

No Synergy

[Timesprout]

You failed to use the term synergy once. You are clearly lying about working for a large consultancy group.

Don't treat OSS different

[Reemi]

Just use the same review process you have for commercial tools, don't treat it different.

Let the OSS tool beat the commercial tool in a fair game. You might want to change the rules a bit if your existing review process is assuming a commercial product or excludes getting support from a 3rd party (e.g. Red-Hat, SuSe).

I've been successful in introducing OSS tools into my company by recommending in 50% of the cases a non OSS tool as that one better fitted the task (cost, support, features etc etc). Don't make OSS a goal in itself.

We're supporting (large international company, +10k employees) OSS by contributing code directly to the maintainers and we have even opened our own tool. It is a slow process but we're learning and considering it on a case by case basis. We do not open all our tools, only those that we fill are worth to open. I.e. where we save cost or can gain positive exposure. (Yes, money is our main drive and that is OK for me because it supports my family.)

Find your own way, but don't feel it as a must to contribute code back to OSS. If you feel bad about that, encourage your people to file bug reports. Or donate to some of the projects you're depending on. Think about bandwidth, equipment or donations. Don't be afraid to pay for support.

Good luck, it is a long and slow road you're about to travel.

Easy...

[psykocrime]

Easy, just hire a consultant. Oh, wait...