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

Divide and conquer.

[GodInHell]

It's usually best to focus on a particular tool or use before answering any of those questions.

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

Been there, done that

[Anonymous Coward]

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

Yes, and stay neutral..

[cheros]

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..

Overcoming Initial (Customer) Resistance

[davecb]

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:

1. a CD they could hold in their hand
2. a company who would offer them a support contract, although they rarely would actually take out a contract
3. a printed, bound manual, or, preferably, an O'Reilly book.

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