Forgot your password?
typodupeerror
Businesses Open Source

How To Approve the Use of Open Source On the Job 123

Posted by Unknown Lamer
from the who-can-we-sue dept.
New submitter Czech37 (918252) writes "If you work in an organization that isn't focused on development, where computer systems are used to support other core business functions, getting management buy-in for the use of open source can be tricky. Here's how an academic librarian negotiated with his management to get them to give open source software a try, and the four phrases he recommends you avoid using." "Open Source," "Free [Software]," "Contribute," and "Development" appear to scare managers away.
This discussion has been archived. No new comments can be posted.

How To Approve the Use of Open Source On the Job

Comments Filter:
  • by Opportunist (166417) on Monday May 12, 2014 @07:02PM (#46984901)

    Old saying. Nobody ever got fired for buying IBM. Nobody ever got fired for buying Microsoft. Nobody ever got fired for buying SAP. It's a simple cover-your-ass game.

    Managers, unless they have a very special bond with the company (like, say, they built it from the ground up) don't give a shit about the company. They care about their ass. And when the question is whether to blow a million of company money for software they don't know jack about but has a big name behind it, or to save the company a million bucks using software they don't know jack about but has no name to it, they blow them money.

    Because they needn't explain why they did it. It's IBM/MS/SAP, how should he have imagined that it's no good?

    • Re: (Score:3, Insightful)

      by icebike (68054)

      Unless you can find a written policy forbidding it, just do it.

      Its easier to get forgiveness than permission.

      Chances are you won't find any policy, unless you work for a big bureaucratic compartmentalized organization. Even then, in the absence of a written prohibition, cost savings can sell the day as long as you provide a support contract. (Some how bean counters become blind to expenditures on support contracts that never ever get exercised).

      • Getting forgiveness is only available from C-Level on. Below, they just kick your ass out on the street.

        • Re: (Score:1, Informative)

          by Anonymous Coward

          Getting forgiveness is only available from C-Level on. Below, they just kick your ass out on the street.

          In real life; almost never. You are going to have to check your own company carefully. Likely this will only happen in a really big company where you already had an explicit warning about open source. Make sure you read through all your IT policies. If there is an explicit one against open source in some way, then always act ignorant ask your manager before breaking it. "Hey, there's this really neat package Gimp which will let me make that special photo we need. It will save me thousands over buying P

      • Its easier to get forgiveness than permission.

        Not always. Not everywhere.

        My first instinct when a geek summons up a Slashdot meme to make his case is to do precisely the opposite of what he suggests.

      • by u38cg (607297)
        Very much this. Once something is done and working, getting retrospective permission is typically a lot easier. Your industry may vary.
      • Unless you can find a written policy forbidding it, just do it.

        This is why you never give people admin rights. They'll randomly install shit and when something breaks, go to someone else and let them spend (potentially) hours of their time trying to figure out what went wrong.

        If you think randomly installing shit is fine, I think it's fine to just reimage your machine without bothering to see if your stuff is backed up.

        When you're at work, it's not your equipment. It's the company's and yes,
    • by roc97007 (608802)

      ...Oracle...

      • Oh, plenty of people have been fired for buying Oracle. Their enterprise apps are a bad joke.

        The joke's on the poor sap dumb enough to buy them.

        • by roc97007 (608802)

          Their enterprise apps are a bad joke.

          ...and always have been, to some degree. Yet people still believe that the way not to get fired is to specify Oracle.

        • Re: (Score:3, Insightful)

          Oh, plenty of people have been fired for buying Oracle.

          Yeally?

          Their enterprise apps are a bad joke.

          Yes, but they're such an *expensive* bad joke that it is too embarressing to too many important people to write off the cost, so usually, the system is kept and forced to work and declared a success.

          If you fuck up a $100k contract, you'll be fired. If you fuck up a $10,000,000, people will work very hard to find a way to make it not look like a fuckup, especially if they've been involved in any way at all.

          • by roc97007 (608802)

            > Yes, but they're such an *expensive* bad joke that it is too embarressing to too many important people to write off the cost, so usually, the system is kept and forced to work and declared a success.

            > If you fuck up a $100k contract, you'll be fired. If you fuck up a $10,000,000, people will work very hard to find a way to make it not look like a fuckup, especially if they've been involved in any way at all.

            This. Generally true, I think, of any ridiculously expensive fuckup. What generally happens

    • Very true. It's not a reason FOSS will not work in your organisation, but it is an issue that needs to be addressed. If something goes bad, who is accountable? Make sure it is not the manager signing off on it. Companies like RedHat do not just exist to package and provide support on Linux installations, they also exist as a "blame buffer". Start with a low risk project that will not have huge repercussions if it fails, be honest about both short and long term risks in using FOSS, and address these ris
      • Yeah, and I find it really funny that people think that way about Open Source. Who has managed to pin blame on a software company in any meaningful way? Who gets support that is guaranteed better than community support without paying for it? You can usually find consultants for any important OS software.

        • That's not even a requirement. I was puzzled by the same when I asked my first boss (back in the early 90s) why no chance to try Linux for some of our lesser important systems. His answer was, in all sincerity, "but who do we sue if it goes wrong?" I was sitting there as puzzled as you are, thinking "You want to sue MS over their crappy OS? Good fucking luck, idiot!"

          Later I learned that this isn't even the point. The point is that you COULD sue them. You won't, of course, but you have someone to shift the b

  • by raydobbs (99133) on Monday May 12, 2014 @07:05PM (#46984925) Homepage Journal

    In small businesses - often the best foot in the door for open source software is a pet project, something you can do transparently to design something to show management about the advantage of the software has over more traditionally licensed fare. Being able to speak the language of IT management helps - Cost of Ownership, Return on Investment, being able to present facts based on license costs is also helpful - management listens to dollars and sense, followed by legality.

    Of course, if your business deals with large vendors who have a stake in keeping things locked to Microsoft, Oracle, IBM or HP - you are fighting a steeply uphill battle.

  • by bhlowe (1803290)
    Avoid terms with negative connotations, such as "GPL" and use the more acceptable term, BSD. As a hiring software developer, I know of what I speak.
    • Re:GPL (Score:4, Insightful)

      by arth1 (260657) on Monday May 12, 2014 @10:46PM (#46986439) Homepage Journal

      .Avoid terms with negative connotations, such as "GPL" and use the more acceptable term, BSD. As a hiring software developer, I know of what I speak.

      That wouldn't work with my old boss, who would take any unfamiliar word and enter it in Google, and then hit the "Images" link for screenshots or easy to understand slides.
      Suggesting BSD would then be career suicide.

      The best way I know of suggesting free (as in breasts) software is to present it with the pricing for someone who sells support. If you can buy the support through the hardware vendor,all the better.
      Which is one reason why there are so many IBM / Red Hat systems out there.

  • by MindPrison (864299) on Monday May 12, 2014 @07:07PM (#46984943) Journal
    When I tried this with bigger companies, it was H*** on earth to try them to embrace Open Source. One of the business managers simply doesn't understand the concept of a free lunch.

    However, with every SMALL company I ever worked for, introducing Open Source software...was a blessing from above to them, it's free, it's cheap...and the programmers are enthusiastic idealistic & proud of their work, so bugs gets fixed faster and new features are introduced frequently as opposed to the commercial bug ridden bloatware where companies are afraid to admit ANY wrong doings as they're afraid of liabilities and such.

    I've been using Blender (3d Software) for over 10 years now, making a living of it, and all the commercial alternatives are slowly fading away with their fanboys. Long live Open Source, it really is true freedom.
    • by gewalker (57809)

      Well, if free is the problem, you can always cut a big check and send it me when you adopt such software. Of course I will channel all such funds received into furthering the benefit of mankind (or at least 1 man). I will even gladly give you a receipt for your "purchase"

    • by drolli (522659) on Monday May 12, 2014 @08:39PM (#46985581) Journal

      i have been working in two of theand really big companies (both > 100k employees), one Japanese, one german.

        in the Japanese company there was no strategy regarding software and "whatever works" was fine, which included open source.

      the German company had the strategy to explicitly manage the obligations from open source. effectively the rules were:
      Apache style, bsd style licenses and LGPL where white listed
      GPL 3 was blacklisted
      GPL needed special consideration (so kind of blacklisted)

      • Considering that those licenses all cover distribution I don't see the difference for an in company product. Especially since the difference between GPL and GPL 3 deals with preventing locked bootloaders. Now if you're doing embedded development or selling software, it's a completely different story. I don't agree with it, but I can see why companies want complete control of their products.

      • by tlhIngan (30335)

        the German company had the strategy to explicitly manage the obligations from open source. effectively the rules were:
        Apache style, bsd style licenses and LGPL where white listed
        GPL 3 was blacklisted
        GPL needed special consideration (so kind of blacklisted)

        A company I worked for had the exact same policy. Though it was a bit more formalized in that if you want to use a not-previously-approved piece of software (commercial or open-source), the license and justification must be sent to Legal in order to vet it

        • by drolli (522659)

          inadverted creation of obligations:

          -the matlab compiler signs code for execution. no GPL3 is compatible with it (even if they never mention the term "DRM" in the manual).

          -what happens if a part of your software sits in controllers owned by your customer (for whom you develop) which logs data as a service offered to his customers? as long as you own the controller they dont need to pass the code on, but at whuch point should that happen?

          -assume that you develop software to be delivered to a daughter company.

    • by davydagger (2566757) on Monday May 12, 2014 @10:21PM (#46986273)

      There IS no such thing as a free lunch.

      Free as in speech, not as in beer.

      There are many advantages to Free software, such as Freedom, being the microsoft doesn't have leverage over you. If your a large enough corp, you can write whatever features MS will never give you, or pay red hat to make them for you.

    • Until a data issue means you have to ship a database backup or large data file to the developer to reproduce and fix the issue, and you have no company to make a data confidentiality agreement with. Or the main developer is outside the company, because international law is a bitch.

      Want to fix it yourself? Now you've signed up for internal maintenance unless you can get it accepted upstream. And without a repro, and bad data to test with, the need for the fix is not obvious.

      As always, your circumstances wi

      • and you have no company to make a data confidentiality agreement with

        Why can't you execute a data confidentiality agreement directly with the main developer as an individual contractor?

        And without a repro, and bad data to test with, the need for the fix is not obvious.

        If a patch is made with the intent to correct misbehavior, this implies that a cause of the misbehavior has been found. And once a cause is found, it shouldn't be too hard to generate fictitious data that likewise trigger the misbehavior.

        • by tlhIngan (30335)

          and you have no company to make a data confidentiality agreement with

          Why can't you execute a data confidentiality agreement directly with the main developer as an individual contractor?

          And what if the developer says no? There may be many reasons for it - including legal obligations elsewhere (day job, say) that may prevent said developer from "commercializing" their work or even accepting money for the task.

          Or even a non-compete, if you happen to be with a competitor of whom the developer works for (you pro

    • Re: (Score:1, Insightful)

      by Anonymous Coward

      When I tried this with bigger companies, it was H*** on earth to try them to embrace Open Source. One of the business managers simply doesn't understand the concept of a free lunch.

      There is no free lunch. There's just economies of scale, and sometimes a free ride.

      It's like hitch hiking. If someone stops and picks you up, and is going the same way, you might get a free ride, otherwise it's "cash, ass or grass". If someone's already made some OSS that does exactly what you need, you get a free ride, otherwise you still have to put the work in or pay someone else, to turn it from what it is, to what you need. Sometimes that's a short walk, and sometimes it's a year long trek.

      I've been on

      • There is no free lunch.

        Except that every fork produced has a free Lunch Replication System built in nowadays.

  • by roc97007 (608802) on Monday May 12, 2014 @07:26PM (#46985099) Journal

    It seems like the best bet is to not raise the question in the first place. Management doesn't need to know that Apache is free, for instance. And there are commercial and free versions of Nagios, Tripwire, Sendmail, and so forth. We have over half of our prod servers running Red Hat, for which we buy maintenance, but in the lab we run CentOS. The Open Source community realizes that companies have a compulsion to spend money, and there are companies that will sell you free software (think about that phrase for a minute...) to satisfy this requirement.

  • So in other words, put Open Source on the table just like any other software. Don't try to differentiate it as "Open Source", because if you do, decisions makers and stakeholders will wonder why you're putting extra effort into justifying it.

    Put it up with a support contract and necessary consultants just like any other piece of software and you'll get approval.

    • Agreed. I take a dim view of managers that demand I "sell them" on what I think is the right choice.

      It's their job to make decisions wisely, not my job to force what I consider wise decisions down their throat. I try to be honest about the pros and cons. If the choice lies within my authority, I try to make the best choice. If it's within their authority, then I hope they make the best choice. If they don't, that's their problem.

      I guess this response must reek of someone who has little patience for fool

    • Don't try to differentiate it as "Open Source", because if you do, decisions makers and stakeholders will wonder why you're putting extra effort into justifying it.

      Well, why put the extra effort into justifying it, then? What's the real answer? Is it because I have been brainwashed to like it, and must turn everything into OSS just because it's so awesome?

      • by Dynedain (141758)

        Consider the scenario:

        Product A has technical features X,Y,Z
        Product B has technical features X and Y (not Z).... but it's OSS!

        Most decision makers will then ask, what's OSS? And when you get into the weeds of explaining nuanced differences in licensing, they'll quickly decide that the features outweigh the license benefits.

  • Generalize much? (Score:4, Interesting)

    by mi (197448) <slashdot-2012@virtual-estates.net> on Monday May 12, 2014 @08:53PM (#46985673) Homepage

    "Open Source," "Free [Software]," "Contribute," and "Development" appear to scare managers away.

    Not where I'm working (a giant company). On the contrary, we are rather suspicious of commercial solutions — because their costs tend to run up pretty quickly (we have a large user-base) and their license terms often enough turn out to be rather enslaving (Oracle is particularly scary in this regard, from what little I've overheard from the company lawyers).

    Sure enough, free software has its rough edges, but so does the commercial kind. And we have enough bright people to fix the problems (bugs or missing features) in the open-sourced packages, whereas with the proprietary stuff you are usually at the mercy of the vendor. We still use some commercial programs, but, when choosing a software solution, the program being proprietary is a negative, rather than a positive factor.

    I wish, it remained possible to get the source for the commercial packages as well, but with modern attitudes towards theft of intellectual property as well as the wide-spread propensity to use the terms "free" and "open source" interchangeably, this is not an option...

    • 3 Fortune 150 companies, and we always had someone who could get a support ticket opened to major vendor. I had to push a bit to find the contact, since this information is usually kept close to the chest.

      Basic vendor rules are:
      1) Be running the latest version
      2) Be ready to upgrade to the next patch in order to have your bug fixed
      3) All of the other patches, improvements, and bugs will be in the next version

      These can be very limiting, and I would prefer to have the source even if all I do is submit a diff.

    • by thegarbz (1787294)

      Of course it's generalised. Why? Because that's what people do, we generalise.

      Why is a cheap Chinese product automatically assumed to be worse quality than an expensive USA made product?
      Why are cheap games automatically assumed to be garbage compared to $80 titles?

      Now given that inherent bias that fuels the many generalisations on cost, why should a free word processor be anywhere near as good as MS Word? It can't be, otherwise it would cost as much as MS Word right? People don't give away something for not

  • My experience (Score:1, Insightful)

    by Anonymous Coward

    In my experience, showing a side-by-side demonstration of performance followed by the price will get your foot in the door. From then on, deliver and keep foot out of mouth. The low cost of setting up a demonstration of FLOSS makes this fairly simple with no need for a line-item on any budget.

    For instance, in one school, I discovered the paid ILS was not working two years after it had been bought. The supplier just didn't bother to fix the problems. I installed KOHA in 15 minutes and showed it to the librar

  • by petes_PoV (912422) on Monday May 12, 2014 @09:26PM (#46985901)
    While reading the article I instantly recognised the situation the guy was describing. However, I believe he has misinterpreted the concerns of his employers.

    Most managers who have had any dealings with a software rollout know two things:

    First is that they won't actually get what they think they have specified
    Second is that there will be problems (see point #1), overruns, differences between what's required and what's delivered and that getting the software functional is only a small part of the job. The rest is integration, training the users, supporting the thing for 5+++ years, implementing upgrades and bug-fixes

    These managers also know that once a project has been signed off, the money has, just that moment, been spent. Companies don't think of money, they think of budgets - so once you have gone through the approvals process and got your budget and your go-ahead the project is effectively a sunk cost, but one that has not yet delivered anything. As a consequence the manager in charge of the project will be deemed to have failed if he/she needs to go back and ask for more, in order to deliver the project.

    So, in their minds they want insurance - and indemnity - above all else. Even above cost savings. They want to know that in return for $<megabucks> that when things start to go wrong, their commercial relationship with "the vendor" entitles them to get support, advice, expertise, fixes, customisations, training, documentation and upgrades. Those will all form part of the cost-case and whoever approves the case will expect, maybe even require, that those items are included and form part of the contract. As they know that there will be the need to call upon those services. If all they get for using "free" software is a pile of code, then that is usually the smallest part of the project and often the least expensive, too. The real cost, over the project lifetime comes with all the extras and services they get from their vendor - but which "free" software is very poor at providing, and absolutely does not guarantee.

    If you go to get approval for a project of any significant size, not having included those items will mark you out as, at best, a newby and at worse: completely unsuitable to be managing a project. It's like if you buy a car. The cost of the vehicle is only one aspect. The cost of servicing, fuel, taxes and depreciation are major factors that should be included in the plan. That they aren't is just an indication of how poorly most people approach a major purchase - and why they'd never make a project manager.

  • by hessian (467078) on Tuesday May 13, 2014 @01:31AM (#46987121) Homepage Journal

    "No support contract."

    Thus what they see is the possibility of problems that take days or weeks to resolve, while getting told STFU NEWB on some mailing list.

    That's the experience many clients have had with FreeBSD, for example.

    • MOD PARENT UP! (Score:3, Insightful)

      by Brett Buck (811747)

      Particularly the STFU NEWB part. This is exactly the reputation open source software has.

      • Re: (Score:3, Insightful)

        by bool2 (1782642)

        Except often it goes like this:

        NEWB: I have . How do I solve it?
        List doesn't reply within 10 minutes.
        NEWB: Look, I have to have this fixed by Monday. How do I solve it? If you don't solve it for me then I have to move to .
        List doesn't reply within 10 minutes. NEWB gets angry
        NEWB: Its such a simple issue. I can't belive nobody can solve it. (Oh the irony). Bump bump bump.
        List: STFU NEWB.

        Don't expect support-contract-like behaviour from a list - remember they're volunteers, there's no "SLA" and they do

        • by petes_PoV (912422)

          Some simple steps for success ...

          I agree. Most lists and forums take a dim view of repeated questions, ones that are "obvious" and ones that the small minority of helpful posters feel are irrelevant. As you say, there is no guaranteed response time - if you get any response at all - and no guarantee that the responses you do receive will be correct or even on-topic.

          Those are why people pay for support. Those are the factors that companies value and the time (equates very closely to money) taken to both supply the requested information, tr

        • Re:MOD PARENT UP! (Score:4, Insightful)

          by Shados (741919) on Tuesday May 13, 2014 @05:42AM (#46987755)

          You're absolutely right. However on a lot of high profile projects, that won't get you anywhere.

          I remember a while back I was using a very high profile/popular data access library which shall remain nameless.

          I found a fairly breaking bug in a semi-common scenarios. I poke at the mailing list, not asking for it to be fixed, but simply if it was a known issue, as again, it was a fairly common case, and I could pin point the exact snippet of code in the source where the issue was (but, being unfamiliar with the code base, couldn't easily fix it myself).

          Instead of a simple "yes or no", I was more or less told to write a failing unit test or shut it, in not so nice words.

          So I write the unit test, after taking several hours to find the exact guidance on how to write it (making a test for a database access framework that stays within the realm of unit test and not integration test differs wildly from project to project), I do so, submit it...all around half a day of work.

          In the meantime, I patched up something on my end that worked (but it was a hack, so I couldn't really submit a patch) in a few minutes.

          2 _years_ later, I see in my email that my bug report just got rejected because of a small mistake in my unit test (that still didn't change the main code path it was testing), and to this day the bug is still present, and whenever this is raised in on Stack Overflow or whatever, people just say its a scenario that isn't supported, even though you can see in the code that it should be, and its just a naive sort order mistake when looping through some array.

          I wish it was an isolated case, but it basically is always like that unless you're inside the project's "clique" or you happen to find a bug that is particularly interesting to fix. Yes, they're just volunteers, but if they don't want their project to be of world class interest, then don't promote it as such.

          TL&DR: Big projects with a lot of marketing pushes saying they're great for real production use, then don't support it as such, are far too common.

        • Well, that's about right, however, that's also the problem. In a professional setting, you expect support, and not just "when and if we feel like it". NEWB in this case may not have ever even heard of a message board or listserv. Someone says "support is here", he goes there, no one answers.

          NEWB doesn't know or care about the theory of open software, building relationships with the list members, doing research on the code base, etc. He found a problem and wants it fixed, and wants som

        • by hessian (467078)

          Don't expect support-contract-like behaviour from a list - remember they're volunteers, there's no "SLA" and they don't work for you.

          Ah, the old "bad behavior exists, therefore your example must be of the bad behavior"!

          No.

          I've (repeatedly) seen people go on to these lists, ask a polite question, and receive STFU NEWB or analogue response very quickly.

          Generally, the more difficult the question the more likely it is to receive this response.

          Ever wonder why Stack Overflow is so popular? Volunteers there get im

      • Particularly the STFU NEWB part. This is exactly the reputation open source software has.

        It's kind of understandable though. What if you went poking the Windows Kernel Team with questions like "how do I get this printer to work"? They would say "we don't have the time to help with that". Then you would contact a Microsoft support engineer and his response would instead be "I'm happy to help you, let's get started".

        In open source world, commercial distros like Red Hat do have proper customer support in place, but various random open source projects do not have that kind of support options. You c

  • Project leaders usually come to me with a vague and changeable list of requirements, a very short turnaround time, and no budget for anything other than wages.

    - Writing from scratch takes too long, plus the requirements change too late in the game
    - Buying off-the-shelf means squeezing blood out of someones stones, and is not customisable
    - Evaluating several open source solutions and taking the best, then modifying as needed hits the sweet spot

    The only time I really needed to put a strong case forward
  • 'academic librarian doesn't know how to proofread or use spell-check'

He keeps differentiating, flying off on a tangent.

Working...