Slashdot Mirror

← Back to Stories (view on slashdot.org)

Integrating Open Source In a Large Consulting Firm?

Posted by ryuzaki0 on from the ironing-out-the-details dept.

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

1 of 22 comments (clear)

  1. Don't treat OSS different by Reemi · · Score: 4, Insightful

    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.