Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

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?"
This discussion has been archived. No new comments can be posted.

Integrating Open Source In a Large Consulting Firm?

Comments Filter:
  • Good Luck (Score:5, Informative)

    by d3ik ( 798966 ) on Saturday November 18, 2006 @07:30PM (#16900606)
    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."
    • Re: (Score:3, Informative)

      by liquidpele ( 663430 )
      To add to that last comment....
      First get a good idea of exactly what anyone who matters thinks about open source. Keep it a one way open ended question, just ask them what they know about it and let them ramble. This will let you know a few things:
      1) What they know already
      2) What they don't understand - so you can prepare a good explanation catered to them
      3) What their fears about it are - so you can be sure to address those in the future
      3) Who's against it for no good reason - This is important beca
  • No Synergy (Score:5, Funny)

    by Timesprout ( 579035 ) on Saturday November 18, 2006 @07:46PM (#16900718)
    You failed to use the term synergy once. You are clearly lying about working for a large consultancy group.
    • And its missing the word Leverage... IE... We want to leverage Open Source Solutions in our current homogenious homegrown systems and sell this win-win solution to the black belts in our orginazation.
  • by Reemi ( 142518 ) on Saturday November 18, 2006 @08:09PM (#16900856)
    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... (Score:5, Funny)

    by psykocrime ( 61037 ) <mindcrime.cpphacker@co@uk> on Saturday November 18, 2006 @08:19PM (#16900904) Homepage Journal
    Easy, just hire a consultant. Oh, wait...
  • by GodInHell ( 258915 ) on Sunday November 19, 2006 @03:45AM (#16902744) Homepage
    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

  • Freedom Task Force (Score:3, Informative)

    by replicant108 ( 690832 ) on Sunday November 19, 2006 @03:52AM (#16902762) Journal
    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 [fsfeurope.org]
  • by 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 w
    • by cheros ( 223479 )
      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..
    • 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.

  • 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!
  • by davecb ( 6526 ) * <davec-b@rogers.com> on Sunday November 19, 2006 @11:19AM (#16904514) Homepage Journal

    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

  • by toby ( 759 ) * on Sunday November 19, 2006 @07:34PM (#16908468) Homepage Journal
    Just noticed the publication of Cost Conscious - A practical guide for understanding and calculating the financial benefits of open source for enterprise IT projects [the451group.com], if that helps.

    The 451 Commercial Adoption of Open Source (CAOS) Research Service is an analytical service designed to help enterprise end users, software vendors and investors track and understand the opportunities and threats presented by open source.
  • 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 fi
  • 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?

     
  • The big consultancies get software at very low cost and often have links with major software producers (i.e., shared board members). They are seen as evangelists and act as a major sales channel with corresponding access to products and support. Their clients pay substantially more as end users. However, if you can afford one of the big consultancies, then a few $100K of license fees is a relatively small cost compared to the consulting services

    The use of open source can improve things for the consultanci

egrep patterns are full regular expressions; it uses a fast deterministic algorithm that sometimes needs exponential space. -- unix manuals

Working...