Slashdot Mirror
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?"
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."
You failed to use the term synergy once. You are clearly lying about working for a large consultancy group.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
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, just hire a consultant. Oh, wait...
// TODO: Insert Cool Sig
That's what the new ICT Minister of Thailand says, reversing about five years of pro-open source government there. (See my jounal and sig for translations of the articles).
Put identity in the browser.
Comment removed based on user account deletion
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
If you're based in Europe, it might be useful to make contact with the Free Software Foundation Europe's "Freedom Task Force". The FTF have been specifically set up to help businesses deal with the legal issues surrounding free software.
Freedom Task Force
I have worked for what called itself "a global IT consulting company", and until recently they were ACTIVELY not interested in Open Source. Reason: they had ample investment in MS tools and skills, and even internal IT was fighting like mad to keep FOSS away because they were worried about their jobs (it appears hard to change away from VB). They even spend a fortune on a CMS which I could have done for 10% of what they spent (with Joomla) and still have enough left for a cracking party..
:-).
The bottom line was simply that they were making a Godawful amount of money from flogging MS stuff because it needs so much maintenance, and because they kept telling the clients that FOSS was not good enough (notice the conflict of interest here). Stability and good structure wasn't in their interest at all, and you also note the stiff ignoring of the clients' interest here (which is not atypical, btw, it's called "the big picture", being the argument that makes most senior staff think their corporate ethics policy is just another marketing tool - think Enron or Andersons here for examples of where that eventually leads).
Of course, even board level clients eventually emerged from the FUD fog they're normally surrounded with and start asking rather pointed questions about budgets, at which point said consultancy has to cook up an answer. It's IMHO the best indicator that Linux has finally 'made' it, helped by the latest MS alliance/absorb attempt of Novell.
Given the time lag between FOSS being a viable proposition (which was approx 3 years ago) and your current question I would suggest your company has just gone through the same cycle.
There are a number of aspects you need to take care of before you can offer any FOSS consulting:
(1) Skillset. Unless your own coders are familiar with FOSS coding tools and languages they will not deliver quality. There is a learning cycle required to 'undo' the MS hive mind mentality and use the 'Lego block' approach FOSS uses to assemble the right tool/code for the job.
(2) Platform. The most effective use of FOSS code is on a FOSS platform, but Linux/Unix is VASTLY different from how Windows works (despite conceptually borrowing heavily). Getting familiar with how a real multi-user system works also takes time, and the platform toolkit will probably give you the steepest leaning curve. AFAIK the key difference is that the UNIX roots of a Linux platform has lots of little tools you assemble together to build a solution, vs the MS way of 'one tool does it all' as long as you can control it. This means learning about lots of different little programs, and there is not ONE way to make something happen (the good news here is that it gives you flexibility and backup options
(3) Approach. It takes some thinking about how you can use the Open Source world. If you + clients just see it as a source of cheap code you're losing one of the primary benefits: collaboration and its cousin: integration. However, that aspect in itself is scary for the average exec after years and years of MS and consulting FUD that FOSS is bad and dangerous (yes, consultancies have done their fair share of FUD distribution to protect their own interests). It takes time to understand and absorb that mindset - don't underestimate that challenge, but 'getting it' is crucial.
(4) Legal. As a consultancy you're most likely going to straddle the two worlds to integrate and migrate facilities. There are a range of legal gotchas (mostly from the proprietary side) that you'll have to look out for. The Open side is here safer than the 'closed' side, be careful not to taint your developments because that can hit you years later.
(5) Marketing. You'll have to interface with the 'current' world and the somewhat amorphous/nebulous FOSS community. That takes skills too, and unless you've been involved with FOSS for a while I would suggest you tread VERY carefully for the first year or so. Get used to the culture, because you can seriously shoot
Be careful because you're heading into a conflict zone. FOSS does NOT have all the answers, and is not THE solution, ditto for anything proprietary. It is part of a solution set.
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..
Insert
Combine these three things: 1) "I work for a global IT consulting company." 2) "I have the task of investigating" with the unstated 3) "I am on the bench and un-billable" Bye!
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
davecb@spamcop.net
IDA Open Source Migration Guidelines (PDF) EnglishPDF[828 Kb]
you had me at #!
Open Source shouldn't be capitalised. It shouldn't be used to categorise software. It shouldn't be a philosophy, an ideology, a theology, an attitude, or a way of life. Nor should it be a deciding factor in chosing software.
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 fit your needs as well.
As soon as you start talking about Open Source as a separate entity, you're evangelising. Consider this comment:
"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"
Now get rid of Open Source in there:
"What we are looking to do is: formalize and consolidate our global knowledge to accommodate new and existing client requirements; define a review process that will enable us to quickly review tools, applications, and so forth"
It's just as clear, just as concise, but doesn't pretend that "Open Source" is something magic and different from ALL OTHER TOOLS out there!
Get over open source as a special category, and just use the tools you need. Contribute if you can. Quit believing that it's special.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
The article submitter should consider the case if he was asked to "formalize and consolidate our global Closed Source knowledge to accommodate new and existing client requirements" and you'll realize just how confused these global consultancies are.
My guess is that he's Accenture/Avenade and that Microsoft(a close partner on many accenture projects) themselves put them up to this project and structured it in a way that was sure to fail.
have standardised on powerpoint as thier development platform.
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?
Old COBOL programmers never die. They just code in C.
The use of open source can improve things for the consultancies, after all, they can build up a substantially better service to their clients. At the same time, it is sometimes useful for a consultancy to be able to blame the vendor (in much the same way that a CIO can blame the consultancy when things go wrong).
See my journal, I write things there