Integrating Open Source In a Large Consulting Firm? 22
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?"
Re: (Score:2, Informative)
Good Luck (Score:5, Informative)
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."
Re: (Score:3, Informative)
No Synergy (Score:5, Funny)
Re: (Score:1)
Don't treat OSS different (Score:4, Insightful)
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... (Score:5, Funny)
Divide and conquer. (Score:3, Interesting)
For instance, the issues and concerns that arise from an OS switch are an order of magnitude more complex than giving open office a try. Both could save a mid-sized 100-200 computer company more than 10k.
If, on the other hand, you're talking about trying to switch to linux based servers running some custom apps.. focus on that issue.. well.. other issues, more problems.
The legal issues change more - if you're supporting a large scale open source project, then your folks have to be comfortable with giving the code up to a community that will want to hack it up, critque it, and feel comfortable going through it and making changes - if you're building your own tools and pushing them out there, you'll have to consider what the cost benefit analysis looks like.. will others come back at your code with improvements and advice, or will it just sit out there, being pulled in for use by competitors and customers alike?
Open Source is a Good Thing (TM), but not every company needs to buy all the way into it now. The best thing you can do for the community is to use the tools you can where the clients and your co-workers will feel comfortable with it and welcome the addition, and then let them watch it work right :). The worst thing that can happen to open source in a fairly insulated tech enviroment is to have open source solutions forced on folks that don't trust it.. they'll see all the glitches and problems that exist in code generally, and attribute it all to "open source crap."
Well, that's my 3 or 4 bits. Good Luck.
-GiH
Freedom Task Force (Score:3, Informative)
Freedom Task Force [fsfeurope.org]
Been there, done that (Score:2, Interesting)
The bottom line w
Yes, and stay neutral.. (Score:3, Interesting)
A client solution is likely to use both proprietary and FOSS components to make it work for *them*. Zealotry on either side has to be dealt with because it benefits nobody..
Re: (Score:1)
Does your client have any 'bespoke' software; i.e. which they wrote themselves, or which they employed the writers of ?
Does your client consider this software to either be sellable, or to give them a competitive advantage by keeping it hidden ?
If there is software which is owned but not an 'asset' in either sense, they may as well 'open' it; donate to the community for others to build on, reuse, and improve.
That's how STAF [sourceforge.net] got there.
Get that Resume Together (Score:1)
Overcoming Initial (Customer) Resistance (Score:3, Interesting)
I used to work in a large international firm based in Germany, developing one of their large-scale business offerings.
Some portions used open source software, notably for interoperability with PCs, and we had to say so in the customer documentation.
Customers (and therefor our managers (;-)) wanted three things:
If they had these three, the level of concern about the kind of software it was fell very rapidly. If we only offered them two of the three, they tended to to be very dubious about the whole deal. You can imagine how that motivated us (;-))
As to support, the customers were very open to our company having a relationship with the software developers, with us reporting bugs and proposing patches. This in turn made our managers see the GPL as part of a quite normal business relationship with the developers, and in some cases had us offering the support for the open source components as part of our own service contract.
--dave
CAOS guide to financial benefits of open source (Score:3, Informative)
Lose your religion, then ask the question again (Score:2)
What open source software SHOULD be is one set of conditions that applies to software you may want to use for other reasons. Decide what to do for technical and business reasons, not ideological ones. If the tool best fits your needs, then figure out if the support and business models fi
Nearly all Large Consultancies (Score:2)
and are unlikly to recommend anything other than SAP or Peoplesoft
to thier clients.
If they recommended something sensible and easy to implement how would
they be able to justify 50 man eons in billing?
Hard Sell... (Score:2)
The use of open source can improve things for the consultanci