Forgot your password?
typodupeerror
GNU is Not Unix Businesses

Bringing OSS Into a Closed Source Organization? 427

Posted by kdawson
from the teaching-a-stone-to-talk dept.
Piranhaa writes "At the major corporation I work for, there is currently a single person who decides what software to approve and disapprove within the organization. I've noticed that requests from users for open source Windows programs get denied, nearly instantaneously, on a regular basis. Anything from Gimp, to Firefox, even to Vim don't make the cut due to the simple fact that they are open source. Closed source programs from unknown vendors have a much better chance at approval than Firefox does. The whole mentality here is that anybody can change the source of a project, submit it, and you never know what kind of compiled binary you're going to get. I'm a firm believer in open source code, but I also know closed source has its place. So what would be the best way for me to argue, with all the facts, to allow these people to come to their own conclusion that open source is actually good? Would presenting examples of other big companies moving to open source work, and if so what are some good examples? Or can you suggest any other good approaches?"
This discussion has been archived. No new comments can be posted.

Bringing OSS Into a Closed Source Organization?

Comments Filter:
  • Don't bother (Score:5, Insightful)

    by nyet (19118) on Sunday October 19, 2008 @03:58AM (#25429751) Homepage

    Either live with your idiot bosses and stop complaining, or ditch that miserable excuse for an employer.

    • Re:Don't bother (Score:5, Insightful)

      by dfetter (2035) <david@fetter.org> on Sunday October 19, 2008 @04:20AM (#25429835) Homepage Journal

      "Some men, you just cain't reach." http://www.youtube.com/watch?v=1fuDDqU6n4o [youtube.com]
      Since you don't have the option of clubbing this guy, get your interview on and find a job where they're not insane. This won't be the only, or even the biggest, moronic decision these people are making.

      • Re:Don't bother (Score:5, Interesting)

        by SausageOfDoom (930370) on Sunday October 19, 2008 @08:22AM (#25430517)

        Forgive me if I'm being stupid, but this is actually something I worry about. I'm a heavy user of open source, but surely it is true that "anybody can change the source of a project, submit it, and you never know what kind of compiled binary you're going to get" - isn't that kinda the point of open source? And we just hope that someone else notices if the changes are bad?

        I know this sounds like I'm trolling, but I'm not - it's a serious question. How do you know you can trust open source projects? I've always assumed that large projects - particularly linux distros and their package repositories - have some kind of QA and code audit system in place, but how do they work? Are a couple of naughty obsfucated lines really going to get caught?

        Sure, many eyes on the source code and all that, and there would be the same risk from employees at closed source organisations - only difference being it's easier to get to work on an open source project, and if you get caught adding bad code, you don't lose your job.

        This sort of thing is becoming an even bigger problem with the web in general; facebook apps, igoogle gadgets, even things like firefox and jquery plugins - the more I think about it, the more paranoid I become.

        What processes are in place to protect users from malicious code?

        • Re:Don't bother (Score:5, Insightful)

          by Ed Avis (5917) <ed@membled.com> on Sunday October 19, 2008 @08:36AM (#25430557) Homepage

          If you think that anybody can change the source code, then just try it. Get a line or two of your code into Linux, Firefox and Openoffice.

          • Re:Don't bother (Score:5, Insightful)

            by Stormwatch (703920) <rodrigogirao AT hotmail DOT com> on Sunday October 19, 2008 @09:54AM (#25430853) Homepage

            If you think that anybody can change the source code, then just try it. Get a line or two of your code into Linux, Firefox and Openoffice.

            Well, anyone can do a fork. I guess what those people fear is: someone takes the source and makes a near-exact replica of a program, but with some malicious function hidden there. Of course, anyone with a clue would know that Linux companies keep repositories, and they won't let such fakes in. Also, those malicious functions are often present in unadultered closed software.

            • Re:Don't bother (Score:5, Insightful)

              by SausageOfDoom (930370) on Sunday October 19, 2008 @10:51AM (#25431093)

              My point was that it was similar to what security experts have been saying about the TSA - if a terrorist gets caught trying to smuggle a gun onto a plane, the penalty is high, they'll go to prison - there doesn't need to be a 100% success rate for detecting that to be an effective deterrent. However, if they get caught smuggling in a lighter and 500ml of petrol, they just chuck it in a bin and they get to try again - the TSA have to be 100% effective.

              My concern was that it's a similar situation with closed v open source; if someone working for a closed software company puts malicious code into a project and they get caught, they lose their job and face legal action, difficulties finding employment in the future etc. There doesn't need to be 100% detection for it to be an effective deterrent. However, if someone wants to contribute a malicious patch to an open source project, if they get caught they can just set up a new persona and try again - there has to be 100% accuracy in detection of malicious code, and the various C obsfucation contests show that's not an easy task.

              As with anything, it's an issue of trust. As Jesus_666 says below, since only trusted people will have direct write access to the code repository, they'll be ones who have invested a lot of time and effort contributing to the project in the past, and that would hopefully be a high-enough barrier to entry.

              However, I think the danger in the open source community is that we might get complacent; as more people move to use open source software, the incentive and payoff for investing the time to breach the trust barrier of certain projects may reach the point where we shouldn't ignore the threat. Indeed, I worry that that point may already be here.

              And we're not talking about someone breaching the codebase for the kernel, or Firefox or OpenOffice, although the risk for those is still there. I'm more concerned about peripheral projects which have more access than they should, such as google gadgets, or firefox or jquery plugins - get a couple of lines into the right place and you can hijack the browser. I'm sure there are similar weaknesses in other applications.

              I guess what I'm saying is that the risks are real, and I can understand where the OPs manager is coming from. Although clearly extreme and I don't agree with the opinion that no open source project can be trusted, I can't help feeling that we arrogantly dismiss the risk altogether at our peril.

              • Re:Don't bother (Score:4, Insightful)

                by ScrewMaster (602015) * on Sunday October 19, 2008 @11:26AM (#25431341)

                Although clearly extreme and I don't agree with the opinion that no open source project can be trusted, I can't help feeling that we arrogantly dismiss the risk altogether at our peril.

                It's like anything else ... you have to make a risk/benefit analysis. Most people aren't very good at that, especially people that are part of a corporate hierarchy (they'll pick whatever the prevailing winds tell them will preserve their job.) Whether the technology under discussion is nuclear power, vaccinations, or open source software, the reality is that you have to accept some risk. That, or spend your life cowering in a cave. The problems come in when people believe that they can have the benefits of high technology with zero risk. That's just not possible, not at the current state-of-the-art, and will probably never be.

                So, yes, there is a finite possibility that someone will, or already has, compromised a major open source application in some way. People have tried in the past, it's true. But it all comes down to that risk/benefit ratio again. So far as browsers are concerned, if you choose an Internet Explorer, you know that you're at a substantially higher risk of external compromise in spite of the closed source nature of the program. With a Firefox, you have to balance the risk of a possible built-in exploit with the fact that it's otherwise a much more solid product security-wise. Where does the greatest risk lie? Sure, there are other browsers, but as products of the human mind they are also imperfect, so the same rationale applies.

                All you can do is take your pick and hope for the best.

              • Re:Don't bother (Score:5, Insightful)

                by quanticle (843097) on Sunday October 19, 2008 @12:18PM (#25431687) Homepage

                My concern was that it's a similar situation with closed v open source; if someone working for a closed software company puts malicious code into a project and they get caught, they lose their job and face legal action, difficulties finding employment in the future etc. There doesn't need to be 100% detection for it to be an effective deterrent. However, if someone wants to contribute a malicious patch to an open source project, if they get caught they can just set up a new persona and try again - there has to be 100% accuracy in detection of malicious code, and the various C obsfucation contests show that's not an easy task.

                While that point of view is certainly a valid one, it doesn't really seem to fit with my personal experience (your mileage may vary). I've found that all of the major stories I've read about "logic bombs" and other malicious functionality being inserted into programs are about closed source, rather than open source.

                I guess it comes down to motivation. If you've got an interest in an open source program, its likely because you're genuinely interested in helping the program and making it better. Also, you're already a user of the program - why would you want to make it worse for the next guy to use it? Finally, you're not depending on this program to provide you with a paycheck - if your code gets rejected or you get "fired" from the project, the sting isn't as painful as losing a job.

                In contrast, the motivations behind closed source programming are a lot more diverse. If you see your (programming) job as nothing more than a paycheck, if you think your employer sees you as nothing more than a number on a balance sheet, if you never interact with the customers or users of your program, it can be very tempting to put in a logic bomb or virus as a sort of "farewell present" when you get laid off.

              • Re:Don't bother (Score:4, Insightful)

                by sumdumass (711423) on Sunday October 19, 2008 @02:56PM (#25433071) Journal

                My concern was that it's a similar situation with closed v open source; if someone working for a closed software company puts malicious code into a project and they get caught, they lose their job and face legal action, difficulties finding employment in the future etc. There doesn't need to be 100% detection for it to be an effective deterrent. However, if someone wants to contribute a malicious patch to an open source project, if they get caught they can just set up a new persona and try again - there has to be 100% accuracy in detection of malicious code, and the various C obsfucation contests show that's not an easy task.

                I think your ignoring the fact that creating malicious software is illegal for the most part. People who write virus's are actually criminals and often do get caught. If someone were to contribute something like you suggest, they would/could be prosecuted under the same grounds as the author of a virus in many jurisdictions.

                As for C obfuscation, it is near impossible to do so because the code submitted is reviewed before going into the project. Unless the author of the malicious code was the project leader (then your in no different of a situation then with a closed source business), the code will be reviewed by others and they will have to understand it's function. You also have standards that simply wouldn't allow obfuscated code into a project- this is a benefit of being open.

                As with anything, it's an issue of trust. As Jesus_666 says below, since only trusted people will have direct write access to the code repository, they'll be ones who have invested a lot of time and effort contributing to the project in the past, and that would hopefully be a high-enough barrier to entry.

                Even when someone has write access to the repositories, those repositories aren't in the production line. The code contributed to them will still be reviewed before being committed to the active product if for no other reason then stability. But again, if it is a project leader who is doing it, your in a worse situation then with closed source because others can and will look at the code. It might take a while but there are record of who did what that are preserved and the culprit will be caught.

                I guess what I'm saying is that the risks are real, and I can understand where the OPs manager is coming from. Although clearly extreme and I don't agree with the opinion that no open source project can be trusted, I can't help feeling that we arrogantly dismiss the risk altogether at our peril.

                I think your risks are being overstated a little. True some of the less successful projects will be more lax in their security, but then the moral is to just use the larger and more trusted projects or just check out the projects your going to use thoroughly. I personally don't even do MS updates until they are out at least 3 months and I can find out if or how they borked someone else's systems. Of course I have firewalls and adequate virus protection so it isn't like I'm flying blind for three months.

        • Re:Don't bother (Score:5, Informative)

          by Curtman (556920) on Sunday October 19, 2008 @08:39AM (#25430565)

          What processes are in place to protect users from malicious code?

          The same ones that protect us from malicious proprietary software, execept there is many many more people doing it, and it is a hell of a lot easier to do.

        • Re:Don't bother (Score:5, Informative)

          by Jesus_666 (702802) on Sunday October 19, 2008 @09:34AM (#25430779)
          Not everyone gets write access to the repository. If you want your changes to go in you have to write a patch and an explanation of what that patch does and submit that to the appropriate maintainer. The maintainer then reviews the patch and is free to accept pr reject it. Obfuscated code will not make the cut as maintainers want the codebase to be readable so it can be better maintained (unless cryptic code is required for speed purposes, in which case you better explain it in detail). You might try to sneak in a subtle bug and that might work or not, depending on how many people review the patch, how thorough they are and how much testing the new release gets before it hits the web.

          That's really the only way to accept outside patches bcause without this system the code would soon become a convoluted mess full of incompatible code and patches against ancient versions of modules that no longer exist.
        • Re:Don't bother (Score:5, Insightful)

          by EvilRyry (1025309) on Sunday October 19, 2008 @09:52AM (#25430837) Journal

          What's to stop a commercial vendor from putting evil code in? All it takes is one disgruntled employee and some poor review processes (which certainly isn't uncommon in smaller companies).

          As a sibling has mentioned, most open source projects don't just allow everyone to commit changes all willy-nilly. Generally you send patches or pull requests in by email then the maintainers will review your changes. Eventually they might just give you the ability to commit directly (or they'll pull from your repository without extreme scrutiny in the DVCS world) if your code is consistently up to their standards.

        • Re:Don't bother (Score:4, Informative)

          by apoc.famine (621563) <apoc,famine&gmail,com> on Sunday October 19, 2008 @10:08AM (#25430893) Homepage Journal
          Most OSS projects have a handful of rabid developers who really know the code, and heavily scrutinize (or simply reject) anything anyone else submits. Now could *they* put something malicious into the code? Of course. But if a project is your life, submarining it with malicious code is not generally what you're going to do. The rabid developers generally also have a fair bit of ego, and keeping up a good honest project is the best way to keep boosting that ego.

          It's entirely possible that malicious code could be inserted into an OSS project. But it's far more difficult, and far more obvious than in closed-source projects. There, one programmer can make one change, and if the others on the project never look at it too closely, NOBODY will ever see it. The simple fact that someone *could* see your submission to an OSS project keeps out most of the malicious code.
        • by Johnny Loves Linux (1147635) on Sunday October 19, 2008 @11:17AM (#25431265)

          I think the better way to look at the problem is to start with this question:

          "How do you know you can trust *any* software project?"

          Well, how do you do answer that question? There are lots of ways of answering this question
          but the one that stands out for me is this:
          1) Trust, like respect, has to be earned. Has Project "foo" screwed me over in the past?
          Yes or no, no equivocation?
          2) If the answer is Yes, was it an isolated event? Was it an accident? Did the project people repair their mistake quickly, or did they let it linger and left me hanging?

          a) If it was an isolated event, and they stayed on top of it, then yeah, I'll give them a second
          chance.

          b) If it was an isolated event and they left me hanging, screw them, they're out. Next!

          c) If it was not an isolated event, then that's it, they're out permanently. My time is limited and I can't afford to wait for them to reform themselves.

          Now that's *my* criteria for deciding. Your criteria is ... your criteria. Based upon *my* criteria and my *experience* I can say the following:

          1) Most of the Free Software (GPL, MPL, BSD, etc. licensed) that *I* use is excellent --- it does what I want, it's well documented *for me*, it has a good *publicly documented* record of fixing bugs and staying on top of things.

          2) Most of the Proprietary Licensed software that *I* have used has been crap in the sense either it does *not* do what I require, or it's buggy, or it's poorly documented, or it has legal encumbrances that make it problematic to use, etc.

          I want to be very careful here. I am *not* asserting that most Free Software is awesome and most proprietary software is crap. I'm only asserting that the software that *I* have *tried* from those models of software licensing have pretty much been: Free Software == Awesome, and Proprietary == Crap.

          Now *why* is this true? Because I don't use Joe Random Free Software and don't use much Joe Proprietary Software.

          The Free Software has been vetted by my OS of choice: Debian Linux. If it's in Debian's repositories then I'll give the software a shot. If it's not in Debian's repositories I don't want to look at it. I'm not interested in ever having to manually download, configure, make, make install software. I trust Debian as my big ass filter of crapware. If some Debian developer took the time to package some Free Software then it must be good, because Debian's guidelines for getting software into the repository is not for the faint of heart. That and the fact that their bucket brigade of QA ensures that when the software makes it into Debian's stable branch it might be obsolete but it's rock hard stable.

          I don't use much proprietary software today. The only thing that comes to mind is Adobe's flash player. I used Microsoft Windows before Windows 2000 came out and by that point I had given up on them for being flaky once too many times. I used NVidia's kernel module for accelerated 3D graphics, and it was ok for a while, until I got burned once too many times when I upgraded Linux kernels and Nvidia hadn't kept up with Linux. The final straw was when Nvidia declared my hardware as legacy. In the case of Adobe's flash player, it's gotten better I think. The only thing that bothered me about it was its tendency to crash iceweasel, and not work very well with konqueror, and stealing audio (oss sound driver I think). The only reason it's still with me is because of youtube and because I'm waiting for gnash (Free Software) to be stable enough and not
          suck up too much CPU usage.

        • Re: (Score:3, Interesting)

          by h4ck7h3p14n37 (926070)

          I know this sounds like I'm trolling, but I'm not - it's a serious question. How do you know you can trust open source projects? I've always assumed that large projects - particularly linux distros and their package repositories - have some kind of QA and code audit system in place, but how do they work? Are a couple of naughty obsfucated lines really going to get caught?

          I know it's a cliche, but unless you actually audit the code (and don't miss something) you can't really trust it. The best that you can

    • Re:Don't bother (Score:5, Insightful)

      by Kethinov (636034) on Sunday October 19, 2008 @04:54AM (#25429939) Homepage Journal

      I'm inclined to agree.

      The whole mentality here is that anybody can change the source of a project, submit it, and you never know what kind of compiled binary you're going to get.

      If someone important in the IT department at my company said something as grossly fucking stupid as that, then one of two things would happen. I'd either get him fired, or I'd quit and go work for a company that hires qualified people.

    • great advice! (Score:5, Insightful)

      by lysergic.acid (845423) on Sunday October 19, 2008 @05:01AM (#25429975) Homepage

      so either learn to live with the problem, or just run away from it? you must be a real winner.

      most socially/emotionally healthy individuals have a powerful tool at there disposable called "interpersonal communication." by honing your communication skills, you can exchange thoughts and opinions with other people, perhaps even persuading them that FOSS is a viable alternative to proprietary software. but this is generally not a tactic used by people who spend their entire lives as a powerless passive observer.

      assuming you know to speak up for yourself, there are a lot of ways to introduce FOSS to a close source organization.

      1. start small. compile a list of FOSS software that you use at work to help you be more productive. personally, i use WinSCP, PuTTY, MySQL, PHP, YUI Library, etc. i would not be able to do the work required of me without these tools, at least no without paying much more for less efficient results.
      2. document all of the proprietary software your company licenses which could be replaced by FOSS equivalents providing equal or better results--this includes desktop applications and sever software. emphasize the TCO that could be saved.
      3. write a proposal. come up with some small non-vital applications that can be migrated to FOSS without disruptive business operations. for instance, set up an intranet site using FOSS software; perhaps a company wiki running on a LAMP server; or switch all IE browsers to Mozilla Firefox.
      • Re: (Score:3, Insightful)

        by dfetter (2035)

        so either learn to live with the problem, or just run away from it? you must be a real winner.

        Some kinds of disagreement point to problems so fundamental in the higher-ups that it's not worth trying. Visceral rejection of free software is one of these.

        • Addendum: As for your time consuming suggestions I would say it is a waist of time. One might as well just have a suggestion box (which is a euphemism for a garbage can). In my experience people don't get into Management because they are smart or hard working (willing to read and analyze these suggestions). A good Manager will smile and say thanks a lot before ignoring you. A bad Manager will just condescend.

      • Re:great advice! (Score:5, Insightful)

        by unlametheweak (1102159) on Sunday October 19, 2008 @06:13AM (#25430195)

        most socially/emotionally healthy individuals have a powerful tool at there disposable called "interpersonal communication.

        That only works if you are dealing with a socially and emotionally healthy individual that has interpersonal communication skills. I've seen very little of this in Management. In fact if management did have any type of skills in this situation they wouldn't have such unfounded biases towards open source software developers or the products they produce.

      • Re: (Score:3, Funny)

        by genner (694963)

        most socially/emotionally healthy individuals have a powerful tool at there disposable called "interpersonal communication." by honing your communication skills, you can exchange thoughts and opinions with other people,

        Wait, let me write this down.

        Theorically could this "interpersonal communication" be used to communicate with the opposite sex?

      • by fuzzyfuzzyfungus (1223518) on Sunday October 19, 2008 @11:54PM (#25437189) Journal
        You forgot the less ethical; but much more entertaining option: Hack together a horrid little website with whatever tools MS is selling for the purpose these days. On that site, offer for sale binary copies of the OSS software you want to be able to use, with all the names changed to horribly bland suitspeak (PuTTY becomes "Enterprise RemoteConnect Professional", others suffer similarly) with all mention of source code and GPL buried under pages of scary looking boilerplate.

        Then, send a request for some of these applications. The high prices and abusive licencing terms you added to the packages will lull them into a false sense of security, and you'll be all set!

        Please note, I do not actually recommend this.
    • by Anonymous Coward

      Sorry, I'm an outsider to the US, and I keep hearing this thing about the right to bear arms.

      Isn't this the reason you own guns: to defend yourselves from utter tossers in the workplace? What's the point in all this gun ownership, if you can't kill middle-managers?

      • by Kneo24 (688412) on Sunday October 19, 2008 @06:47AM (#25430279) Homepage

        The reason you don't get it is because you don't fully understand. "The right to bear arms" doesn't mean you have the right to hold a gun. It means you have the rights to wield arms of a bear. Unfortunately, they're a little cumbersome, so no one really uses them.

      • by jcr (53032) <.jcr. .at. .mac.com.> on Sunday October 19, 2008 @06:54AM (#25430289) Journal

        Isn't this the reason you own guns: to defend yourselves from utter tossers in the workplace?

        No, we own guns to prevent the government from having a monopoly on deadly force. Governments have different options available to them when the people are armed, than they do when the people are unarmed.

        -jcr

    • by rishistar (662278) on Sunday October 19, 2008 @08:44AM (#25430587) Homepage

      At the major corporation I work for...

      I agree - I think the fact the poster is working for Microsoft is at the root of the problem.

  • by Noksagt (69097) on Sunday October 19, 2008 @04:01AM (#25429761) Homepage

    Some people/companies just want a name to blame if something goes wrong. Rather than requesting the right to install Vim, request the ability to purchase a license for Vim. Many projects have already setup mechanisms to do this or are willing to do so.

    If this doesn't work because:

    A single person who decides what software to approve and disapprove within the organization.

    then go to your manager and also the person or people who decide to how good of a job the "software evaluator" [single person] is doing. Point out a real business need for a particular application: "Vim has XXX feature. It is not available in any other software. If I had this feature, I'd be able to do YYY, which will [save/make] our company $[insert figure here]. Did I mention that it is written by a google employee, and that our competitor, ZZZ is probably going to use it if we don't? Here's a list of other companies that use Vim [insert fortune 100 here]. Can you please make [single person] justify why he is putting us at a competitive disadvantage?" Cost is rarely a concern. So save the fact that it is free as an additional argument that you can make if [single person] suggests some other app.

    If you are passionate enough about your tools, you can always walk--some companies hire talented employees and understand that they will be more productive with their preferred tools. (If you find yourself in such a company, don't spoil it--produce results with your tools, so that the company will be rewarded for this wisdom.)

    If you want to be a dick, point to comparisons of some no-name proprietary program that [single person] approved that turned out to have a security hole and that your app does not suffer this hole and try to pull other tricks to demonstrate that [single person] is incompetent.

    • by Swift Kick (240510) on Sunday October 19, 2008 @04:29AM (#25429869)

      You know, sometimes these guys are above 'your manager'. Way above.

      From what the OP says, it sounds like the person he's referring to is something like a Chief Compliance Officer [wikipedia.org] at his company. If that's the case, tough luck.

      There is a possibility that the reason why open-source software is not approved for use is because it doesn't meet the compliance standards that were put in place, whether because of simpler and easier application support, patching, or just plain liability.

      Open-source software often times as very poor support options. Forums and IRC are not substitutes to a dedicated phone support line that's manned 24/7.

      User all the open-source software you want on your free time, OP. During work hours, play by their rules or find another job.

      • Re: (Score:3, Informative)

        by Noksagt (69097)

        We can speculate about his company's org chart forever. I did state that the poster should go to the boss of whoever is giving him grief. I disagree with your reading of the situation; I take the claim "programs from unknown vendors have a much better chance at approval" at face value. There might be some chance that an unheard of company is making "compliant" software, but I doubt it. Given that there is some mechanism in place to get some software approved, this doesn't really smell like a CCO to me (

      • Re:24/7 support (Score:2, Insightful)

        by zmollusc (763634)

        Honest question here, does the 24/7 support ever solve problems? The only time i ever bothered to complain about a faulty product ( a television set that was under guarantee ) all that happened was i got dicked around for 18 months while it got taken away, brought back, failed again, taken away etc. I assume the job of 'support' is to occupy the customer until they get bored of complaining/die/find a work-around/buy a different product.

      • by tr_x_data (686765) on Sunday October 19, 2008 @05:10AM (#25429999) Homepage

        Open-source software often times as very poor support options. Forums and IRC are not substitutes to a dedicated phone support line that's manned 24/7.

        That is simply wrong. A wide used and successfull OSS Software (CMake, Subversion, Apache, Vim, Eclipse) to name just a few of those we use in our Company (a very Big Company with more than 700K Employees) have excellent support. It comes in forms of Forums, thousand of Google hit's on every problem and of course IRC and Mailinglists.
        As main user or tool responsible person of some of those applications, I never encountered a Problem that I couldn't find quality problem solving information for.
        CSS support via closed ticket systems that aren't even indexed by search engines simply can't provide a similar support in my eyes.

        Open Source Software comes along with "open problem solving" and that is a big advantage over their closed source counter parts.

        • The problem is that large companies are packed full of people with little or no problem solving skills...
          They either don't want to, or are incapable of trying to solve problems themselves, and would rather pay extra for someone else to do it...
          Yes, they're basically not doing their jobs, and yet these blatantly incompetent people end up being paid a lot of money.

          On the other hand, those people who are smart enough to solve problems (and it really isn't that hard) can set up support consultancies and employ people to do what you're doing on behalf of other companies.

          I've seen countless situations where relatively simple problems were unable to be solved internally, and the people who's responsibility it was to fix them just wanted to hand them off to a third party as quickly as possible, and simply didn't have the skill to diagnose what was wrong.
          The issue took a few seconds to diagnose, and a few seconds to fix once someone with the right mindset started looking at it.

      • by mlts (1038732) on Sunday October 19, 2008 @05:13AM (#25430011)

        If a company has a chief compliance officer, they are likely bound under some corporate regulation like Sarbanes-Oxley, HIPAA, or something else. To keep the officers from going to prison, one of the things they need to do is "due diligence".

        This is making sure that every product in a chain is certified by a vendor in some way. For example, operating systems must be FIPS and Common Criteria certified, encryption products must be listed in the US Governments certified AES libraries, and so on.

        Yes, some open source products make this list. SUSE and RedHat Enterprise Linux both have the certificates. However, not many open source solutions do, which is why businesses just go with a Microsoft stack for their applications.

        For example, if a business is running a MS stack, and there is a serious data breach, said business can show their policies in place, show that they have done due diligence by using commercial software everywhere, with certified configurations, they will not have to worry about civil stuff like stockholder lawsuits, or criminal stuff like the SEC coming in with audit papers and handcuffs.

        Unfortunately, should a similar breach happen with a company that has an open source stack, and can't really prove due diligence by showing that every piece of their IT puzzle was certified by someone (usually a US government agency)... well, they are facing a world of civil and criminal liability.

        To be honest, the chance of getting open source software into an environment that has to be so heavily audited and regulated is almost zero. Commercial, closed source software dost cost, but part of the cost is insurance and the ability to blame someone else other than the company or its officers and staff should something bad happen.

        Another legal issue of why businesses choose closed source solutions is patent indemnification. If a software company doesn't have this protection for its customers, should a patent violation occur with the software, not just the software company, but all its customers can wind up being sued for obnoxious amounts of money, and possibly shut down. Again, RedHat is one of the companies that offers this protection for an open source product, but few others do.

        None of this is related in any way to the quality of programming of open source software. Its all security theater, but its what keeps a company in business and its officers out of prison with the regulations in the US.

        • by Anonymous Coward on Sunday October 19, 2008 @09:03AM (#25430667)

          SOx has actually produced almost the opposite reaction, with OSS you can validate the code path, but with CSS you cannot and almost every vendor in existance has explicity information in their EULA that states that they are not responsible for anything basically related to any type of "protection"

      • by AndGodSed (968378) on Sunday October 19, 2008 @05:15AM (#25430017) Homepage Journal

        In my case it is the owner of the company where I work.

        While I cannot speak for the personality of the OP's boss - mine is at least a very decent person.

        So I walk into work and inherit an old Dell Latitude D600 running WinXP.

        A month into the job I trash it and install Linux. I am now the only person in our company using Linux/OSS for everything I need to do.

        I inherited a desktop PC that still runs XP - our control software is written in MS Access so I could not run that on Linux.

        One day my boss remarked in a meeting that "You know you need to be able to run Windows dependent software on your laptop" which is his roundabout way laying down a kind of challenge to me.

        So I set up our proxy server to allow me to SSH in and rdesktop to my desktop when I am on standby. The other tech's needed to make an offline backup of the control DB and then merge it with the "live" DB.

        A week later in another meeting he reminded me to merge the database. "No need, I run the DB live"

        So two months ago I was offered part ownership of the company and promoted to tech manager in the interim.

        Sometime you need to play on the ragged edge for a bit in order to get your point accross.

        I still run Linux on my laptop, and my whole tech team goes for weekly training on Linux with our sister company who is a Linux solutions provider.

      • by Bert64 (520050)

        Most open source products have 24/7 support available if you're willing to pay for it... If you don't want it, you pay nothing and still get to use the app.
        Similarly, most closed source products come with little or no support by default, and you then have to pay even more to get a decent level of support.

        But more importantly, closed source typically gives you one choice for support - the original vendor, third parties don't have sufficient access to the app to provide a proper level of support. Open source

      • by bit01 (644603)

        You're a bigot. Either that or a lying astroturfer. Let me fix that for you:

        Closed-source software often times has very poor support options. Unanswered phone calls and "we'll fix it in the next release in a year's time" are not substitutes for email messages often returned with fixes in hours.

        The reality, not the fiction that you're spouting, is that you can get support for any software, closed or open. Except that with open source you have more competition and more options.

        ---

        Open source software is ev

    • by dwater (72834)

      > Cost is rarely a concern. So save the fact that it is free as an additional argument that you can make if [single person] suggests some other app.

      Was (fiscal) cost mentioned at all here? Sure, all the open source products mentioned also are cost free, but Open Source != Cost Free.

      Also, Open Source doesn't mean anyone can 'just change the code'. You can *fork* the code and change that, but I don't see how you can change the code in, for example, Red Hat Enterprise Linux, to name but one, even though it

  • by QJimbo (779370) on Sunday October 19, 2008 @04:01AM (#25429767)

    The fact is that because open source is open, if someone tries to put some hostile code inside it, it will be seen and stopped there and then. With closed source, if hostile code gets put in, you're relying on a much smaller bunch of people to spot it, and there is always the possibility they will all collude together to put something in.

    With open source, you can evaluate it.

    People use the same argument against wikipedia, "anyone can edit it, therefore it cannot be trusted", but the same counter argument can be applied to that as well.

    • That is simply not true in practice. Most people do not audit the source code of their favourite Linux distribution. Even if they did, there's no guarantee that the code they have installed from the DVD was compiled from the source that they looked at. Contrary to popular opinion in the open source community, most people don't want to compile all their software themselves.

      It's not even as if having availability of source code means you will find all of the hostile code that is in it. Debian managed to d

  • by Antique Geekmeister (740220) on Sunday October 19, 2008 @04:05AM (#25429773)

    Seriously, you need to find the person and find out what their concern is. Is it a maintenance cost? A desire to avoid mixing and merging tools in-house? Are they concerned about who will be responsible, or liable, for problems with open source tools?

    If their concerns aren't justified, and they can't be negotiated with, then they may need to be fired, or you may need to leave in order to get the tools you need. But their concerns are sometimes well founded: I've seen people who need a 99.999% uptime who were absolutely terrified of open source tools, had implemented closed source and very robust tools, but didn't realize that it absolutely prevented new development. That was OK, their requirements were very stable indeed. But it meant that they could not support projects from other parts of the company.

    • Follow the Money (Score:5, Interesting)

      by mdm42 (244204) on Sunday October 19, 2008 @04:16AM (#25429811) Homepage Journal

      Sounds like this person has a deeply vested interest. I would guess that the real problem with open-source software is that it's free (as in "beer"!) so no chance to cash-in by playing favourites.

      Find out where the kickbacks are coming from and blow the whistle.

      • It doesn't take kickbacks. Simply avoiding blame for a new tool failing and being held responsible for approving it can cause someone to be very, very cautious about approving new and unfamiliar tools. Take the example of Firefox: will the website servers be forced away from their favorite Microsoft authoring tools because they violate the HTML and Javascript specs, and Firefox correctly refuses to render the resulting broken debris? Then that's a hidden cost of supporting Firefox.
      • by Alain Williams (2972) <addw@phcomp.co.uk> on Sunday October 19, 2008 @07:00AM (#25430301) Homepage
        The other money aspect is look at how big a budget I control. Using OSS would reduce that, something that he might not like for a variety of reasons:
        • It reduces his status within the organisation
        • maybe he wants to impress the wife/golf_buddies
        • maybe he is looking to a better paying job within/without the organisation; you tend to be better paid if you control larger budgets
  • It likely isn't worth the effort. I really like FOSS myself, but one needs to have some perspective. This isn't getting food to the hungry, or getting some medicine to the poor. If upper management has an irrational hatred of OSS, so be it. Live with it, or resign. Based on what you're saying, the person doesn't seem open to reason -- and there is no point of using open source for non rational reasons.
    • by turgid (580780) on Sunday October 19, 2008 @05:46AM (#25430109) Journal

      I used to work for BNFL (now the Nuclear Decommissioning Authority) and this was exactly their attitude. I tried very hard to explain things and not over-step my authority or sound like I was trying to undermine my superiors but the reply was always patronising, "We'd rather pay for a software license and have support when things go wrong." Note I'm not talking about nuclear safety-related software, merely office and programming tools.

      After a few years, I got sick of the stifling environment and lack of direction and left for a better paid job.

      I went to work for a big US computer company. Things were totally different there.

      After another few years, the office close and I had to get a new job with a smallish British company. They were very open-source friendly although the Director of Software really admired Microsoft. There really was trouble there since as the skill base left due to fascist management, and the Director of Software tightened his grip, things went the other way. I quietly, discretely and politely offered to save the company £1000 that they were going to spend on some backup software for servers that essentially just did a dd of the root disk. I got a flame back telling me to keep my pathetic little minion mouth shut and I resigned like the 16 others before me. Two more resigned during my month's notice.

      I'm much happier at my new place. It's a big company again with lots of rules and process, but their hearts are in the right place - the right tool for the job - and they appreciate ideas from their technical staff.

      The moral of the story is be prepared to move on if the company doesn't suit you. It may take many months to find something new, but it's worth it. Work is a substantial part of your life. That time is too valuable to waste on something that makes you miserable.

  • by TheWanderingHermit (513872) on Sunday October 19, 2008 @04:11AM (#25429785)

    I'm sorry for posting as an AC, but the /. login doesn't seem to be working (no matter what I type in to the captcha, it doesn't let me verify my password!).

    This guy is God as far as software at this company goes. He can do what he wants and unless there's a major catastrophe, his supervisors will let him continue to do so. If what you say is accurate, then he's made up his mind and there is no reason to change it at all.

    You ask for "the best way for [you] to argue..." That's it right there. As long as you argue, you lose. He doesn't want to argue, he wants to be right and that, by definition, is what he is for anything he says at this company. He doesn't want to hear from you, doesn't care, and in any argument, if he so much as listens, he is indulging you.

    True, he's an idiot, but that doesn't matter. He has no reason to change so he won't.

    If you want him to change, remember he's like electricity: He takes the path of least resistance. For him to change or even look into change, then that path has to be made easier than him not even bothering to look.

    When you can make it easier for him to look at FOSS than it is to ignore it, he'll start looking, but not until then -- and likely not even then if he has a grudge against it and doesn't want to admit it.

  • by somanyrobots (1334451) on Sunday October 19, 2008 @04:11AM (#25429787)
    with a hooker and a camera!
  • Find another job (Score:3, Insightful)

    by pmontra (738736) on Sunday October 19, 2008 @04:13AM (#25429795) Homepage
    It sounds like a bad environment for a programmer. I'd leave them with their closed source programs and look for a job in a better company.
  • by Anonymous Coward

    I've worked in several large corporations, and was faced with similar challenges.

    Often times, open source software is not viewed as a serious option because (depending on what software you're looking at) there isn't a singular reliable source of support, and due to legal reasons, a large corporation just cannot afford to take a 'gamble' with open source. You need to pick your battles and pick them well.

    I'm not implying that open-source software is better or worse than commercial software, but the dedicated

    • by Bert64 (520050)

      The idea of a singular source of support is pretty offputting to me...
      A single source of support is a monopoly, they can provide half assed support at premium prices and you have no choice but to suck it up.
      ZenOSS is a good example here, does anyone else provide support for it? Do you think their enterprise support would improve if someone did?
      RedHat is also a good example, many other companies provide a supported Linux distribution, if RedHat provided lousy support they would lose customers very quickly.

  • by bboxman (1342573) on Sunday October 19, 2008 @04:22AM (#25429841)

    While I was working for a former employer, we were engaged in negotiations with a very large company that would act as a distributor (to a certain market) of our products. Said unnamed company in the distribution contract wanted us to sign off that "no open source software products were used in the development process, and that no OSS was present in the product".

    Why?

    Frankly, I understand the concern. If you are a development shop, then if OSS creeps into your product (due to a careless (and thoughtless) developer copy-pasting code, for instance) then the legal ramifications may be grave. Potentially, depending on the license, you are required to disclose the entire source of your product, and provide a usage/distribution license to whomever receives that code -- basically, a single minute action can sign off your rights to your software. your distributors have also violated copyright, and are in similiar hot water (e.g. their efforts in promoting your product are now potentially worthless).

    The result? Some companies are so afraid of this "poison pill", that they simply don't let any OSS in their gates. Does this promote OSS? Maybe. IIRC, I recall that some friends working for the dark side (M$) report that no OSS is allowed there (or in some parts thereof).

    I use OSS extensively. The former company I worked for had a whole heap of OSS in its development process (but not in the developed chip/product). Actuallly, considering that a non-OSS company (Altera) used OSS in its supplied development chain (gcc, for instance) that we were using, there really was no conceivable way that the company I worked for could've signed off on the "no OSS" bit of the contract.

    • As a small addendum, remember those fellows that found OSS in the infamous sony rootkit (by various strings present, IIRC). A week or two later the same guys (or someone else) found OSS in some other commercial software product. IIRC, there was some legal action (from FSF?) following this.

      It used to be, that if you screwed up and placed OSS in your product that the chances of being caught in the act of theft were fairly low. Currently, the chances of being caught (even if your act was inadvertent) ar

    • If you are a development shop, then if OSS creeps into your product (due to a careless (and thoughtless) developer copy-pasting code, for instance) then the legal ramifications may be grave.

      Why do you think this problem is unique to OSS? What if one of your developers has access to a Microsoft source license and starts copying and pasting code from there. Do you think the "legal ramifications" of that action would be more or less serious?

      Compared to using an LGPL library, this could leave you open to huge liabilities.

      If you don't control what your developers are up to, and have frequent, in-depth code reviews, then you're asking for trouble, OSS or not.

      Rich.

    • Re: (Score:3, Insightful)

      by StrawberryFrog (67065)

      "no open source software products were used in the development process, and that no OSS was present in the product".

      I understand that the company may be afraid of being infected by the GPL and their software becoming a zombie or something, but that's a huge overreaction. I use Winmerge [winmerge.org], (which is GPL'd) to compare files "in the development process", but it has no implication on the licence of the final product.

      If I work from an example that's under BSD licence, it has no implication on the licence of the f

    • Re: (Score:2, Informative)

      by morbuz (592480)

      > Frankly, I understand the concern. If you are a development shop, then
      > if OSS creeps into your product (due to a careless (and thoughtless)
      > developer copy-pasting code, for instance) then the legal ramifications
      > may be grave. Potentially, depending on the license, you are required to
      > disclose the entire source of your product,

      Bullshit.

      If OSS "creeps into your product" by mistake, you won't ever have to
      disclose the source code you have written. You just lose the right to
      distribute the pr

  • by AYeomans (322504) <ajv@yeomPASCALans.org.uk minus language> on Sunday October 19, 2008 @04:22AM (#25429843)
    Doubt you will be able to change your control guy's mind with reason, so you have to play politics. Find an example where expensive software was bought instead of OSS and tell his/her boss how much the policy (note not "the person" - bosses can work it out) is costing the company. Of course, if the guy IS the boss or is related to the boss, just find another employer if it's that important to you.
    • by cheros (223479)

      You're absolutely correct. If someone excludes options it means they have their reasons for it, political, imposed policy, vendor goodies or maybe just being nervous to go unchartered waters (in itself not a bad thing as long as it occasionally involved re-evaluation of the underlying decisions).

      Plus, the guy may not have the mental strength or clout to get into a battle he can't win [boycottnovell.com] because companies are presently as little controlled for their abuse and malfeasance as bank and politicians are (and we kno

    • by jimicus (737525)

      I'd argue that in a shrinking economy, being known to your boss as "the one that went over his head" might be detrimental to your career.

      Even if he gets an order from above to take F/OSS seriously with no hint as to what prompted such an order, he's going to wonder what prompted it himself - and "that guy who keeps asking to install Firefox" is going to be #1 in the list of suspects.

  • The whole mentality here is that anybody can change the source of a project, submit it, and you never know what kind of compiled binary you're going to get.

    That's why open source has source. You can examine the source code to see if there are any strange patches. Compile it yourself and then you know what kind of binary you're going to get.

    That's also the big benefit of open source. There are thousands of eyes looking through it for the larger projects. You also get the benefit of customizing the source for your own purposes (and if you don't distribute the end results, you don't need to distribute the source of your changes, either, for the software under

  • 1) Convince his superiors that a particular open source program is the best available for the job. If this works, try with another one, but make sure you point out the open source nature of the program.

    2) Talk to your workmates about open source software that you use, and try to get them to request some of this software to be available to them. For bonus points, try to get them to complain (with email evidence) when software is rejected to the people who evaluate the performance of staff.

    It'll take a long t

  • by ClosedSource (238333) on Sunday October 19, 2008 @04:39AM (#25429895)

    As with any idea you want to sell, you have to pitch it in terms of what the company wants. Most companies aren't going to be motivated by a philosophical argument. You have to ask yourself: If the company started using open source software, would it have a significant postive effect on the bottom line? If not, your unlikely to succeed.

  • by nexu56 (566998) on Sunday October 19, 2008 @04:46AM (#25429917) Homepage
    At my previous job, I heard some really crazy reasons, from non-technical PHBs, for outlawing free software. All kind of nonsense up to and including Russian hackers planting backdoors/trojans in OSS apps.

    In the end, the best way to make these non-technical PHBs see sense was to simply point out all the OSS they were already using, without even knowing it.

    Those HPUX servers? Running Samba shares.

    That F5 SSLVPN network appliance? FreeBSD!

    The most priceless moment was when I discovered the main OSS opponent was an avid Firefox user. He referred to it as "Microsoft Firefox".
  • by iceco2 (703132) <meirmaor@[ ]il.com ['gma' in gap]> on Sunday October 19, 2008 @04:51AM (#25429931)

    In my organization I wrote up a risk analysis for Open source and closed source software,
    detailing the risks in each.
    How does malicious or dangerously buggy code get into each type of project. how do you assess the threat in both types of software:
    What is the review process?
    How big is the project?
    did you compile the software yourself? who did?
    how did you get the software/source code. etc.
    This document was picked up by other people who eventually turned it into company guidelines for OSS adoption.

        Me.

  • This is the kind of moron who gets written up on TheDailyWTF [thedailywtf.com], and derisively laughed at for years to come. Such a person is a liability to the firm, and needs to be dismissed.

    Seriously, after all these years of success and reliability, anyone claiming Open Source software is an organizational threat is simply in the tank for Microsoft. Firefox, a threat? VIM, a threat? While Internet Explorer and MS Word are paragons of safety? The man is provably out of his fscking mind.

    Schwab

  • In my experience, your best bet in these cases is to walk the company's official path for software acquisition.

    If no such path exists, your first step is to convince management to create it. Your common goal is to get the best sollutions for the problems at hand.

    Here is a very usefull link of the dutch government on making FLOSS a viable option for software acquisition:

    --> http://www.ososs.nl/files/acquisition_of_open-source_software_-_text.pdf [ososs.nl]

  • If it is good enough for the Department of Defence then it should be good enough for a any corporation. However, if IBM, Sun, SGI, Hewlett Packard, AOL and Dell are not good enough to convince your bosses, then I don't think anyone will.
  • These folks usually need a near death experience to change their mind. You won't change it. It's only when competitors are closing in, that's when folks like these give up their superiority complex and do what the engineers say. But by then it's already too late.

  • Step 1. Convince him to buy an expensive, complex and impossible to manage closed source program that he will approve, Lotus Notes or anything by SAP comes to mind, preferably for a totally inappropriate purpose.
    Step 2. Maneuver yourself into being next in line for his job.
    Step 3. Encourage end users to complain about the software as much as possible. Plot behind the scenes to make sure his bosses know he is responsible.
    Step 4. Once he is fired, take his job and replace the closed source software with op
  • Shouldn't this have been in Ask Slashdot instead of News?

    • by Briareos (21163) *

      Absolutely.

      There's not even a link in the summary, so even a /. editor should be able to tell a question being asked from news being submitted...

      np: New Order - Elegia (Low-Life Extras)

  • Your open source software blocker is being paid off by the vendors. Maybe not in cash, might be just in dinners, trips to "conferences", or perhaps just in building his ego.

    This is one of the barriers to OS software adoption that is not yet recognized.

  • oh hai (Score:2, Funny)

    by spintriae (958955)

    At the major corporation I work for, there is currently a single person who decides what software to approve and disapprove within the organization.

    Give Mr. Jobs my regards.

  • Address the facts (Score:5, Informative)

    by davide marney (231845) <davide.marney@ne ... g minus math_god> on Sunday October 19, 2008 @05:31AM (#25430061) Journal

    It sounds like his argument against FOSS is fact-based, not political. Address the facts.

    He believes that anyone can change the source of an open source application and recompile it. That is TRUE. He is right to identify that as a vulnerability. The mitigation is to only download binaries from trusted sources and verify them with checksums, or to download the source, inspect it, and recompile.

    His conclusion that applications from proprietary sources are therefore inherently more secure because they cannot be recompiled, however, is INCORRECT. From a security standpoint, using a binary file requires a higher level of trust because it is more opaque. It is far easier to to hide an attack in a binary file precisely because one cannot inspect it as easily as one can a source file.

    The threat order, from most threatening to least, is:

    1. Binary from an untrusted agent, no checksum
    2. Binary from untrusted agent, with checksum
    3. Binary from trusted agent, no checksum
    4. Binary from trusted agent, with checksum
    5. Source code from untrusted agent, with no checksum, scanned for security, recompiled
    6. Source code from trusted agent, with checksum, scanned for security, recompiled with a new checksum.

    The point is, NOTHING should be accepted without verifiable trust. Being able to personally inspect the source code provides an additional level of protection, and is therefore SAFER from a security standpoint.

    For personal use, I trust everything at level 3 and higher (binary from trusted agent, no checksum). That's fairly risky, but acceptable for a single machine. If I were in charge of the corporate desktop, I would elevate to level 4 (binary from trusted agent, with checksum). This is the level that Microsoft products are distributed at, for example. If I really were concerned about the security of an application -- say, if I were in charge of writing voting machine software -- I would insist on elevating all the way to level 6 (source from trusted agent, with checksum, scanned by me and recompiled with a new checksum.)

  • by Bert64 (520050) <bert AT slashdot DOT firenzee DOT com> on Sunday October 19, 2008 @05:37AM (#25430081) Homepage

    The whole mentality here is that anybody can change the source of a project, submit it, and you never know what kind of compiled binary you're going to get.

    What, and all the viruses that can attach themselves to existing binaries clearly have never existed?

    If you have the source code, then you have the opportunity to compile your own binary and be sure what's in it.

  • Don't bother. Go get another job elsewhere.

    Or as someone posted earlier, "Either live with your idiot bosses and stop complaining, or ditch that miserable excuse for an employer."

    We use OSS almost exclusively where I work... the only commercial software we use is Microsoft, and even that we try to avoid as much as possible.. (there's only a very few window's pc's with MS office for example.)

  • by JaredOfEuropa (526365) on Sunday October 19, 2008 @06:13AM (#25430191) Journal
    I have implemented a high-profile system in a large multinational, using open source. I too found it hard to get OSS accepted, but not for the reasons I first expected. Most of the initial arguments were quickly countered.
    - Malware? We were confident enough to see there were sufficient controls around code changes.
    - Support? Easily handled by our existing channels, even for elaborate changes and additions.
    - Quality? Millions of users can't be wrong...

    The one thing we struggled with was: liability. Our own, our manager's, the software approval guy's. The problem is this: what if that bit of open source software contains proprietary code, and the owner of that code suddenly starts asserting his rights? At best, we will be forced to stop use of that software.

    You can argue that this is also a possibility with commercial software, which is true. But with commercial software, the owner of the infringed code will go after the creator of the software. Better yet, we too get to sue his pants off. In the case of open source, they are likely to sue not the creators or distributors of the software, but the people using it. That means us, and the legal eagles don't like that, oh no. Remember the old maxim "No one has ever been fired for buying IBM"... that goes doubly for OSS. OSS exposes you to lawsuits, and when the stuff does hit the fan, the buck stops with you.

    In the end, OSS was allowed in our corporation, provided that it isn't used for mission critical purposes if no commercial drop-in replacement exists. If the software develops issues, there's still no vendor to blame for me, but I can live with that, personally.
    • Re: (Score:3, Insightful)

      by 1u3hr (530656)
      Better yet, we too get to sue his pants off.

      Why is that "better"? Very likely a software developer (anyone smaller than IBM) in that position will declare bankruptcy, or just disappear. You're very unlikely to get a cent back, no matter if you win your case or not.

      Anyway: what if that bit of open source software contains proprietary code, and the owner of that code suddenly starts asserting his rights? At best, we will be forced to stop use of that software.

      No. At best, after a brief hiatus the infri

      • Why is that "better"? Very likely a software developer (anyone smaller than IBM) in that position will declare bankruptcy, or just disappear. You're very unlikely to get a cent back, no matter if you win your case or not.

        It's not about getting our money back or claiming damages, in fact it's unlikely that it would ever come to a lawsuit. But having someone else to blame to the point where you could sue him, means that there is that much less blame to apportion inside the organisation. Cynical? Yes, bu

  • i have noticed is moving more towards open source, I don't know if it is just because we are poor, or that someone can see this light!

    I happen to use many OSS portable apps, like firefox winscp and open office (even thought word is there) but I used to install gimp portable, and no longer have to as someone requested our computer tech guy to install gimp on all the computers!

    So now I can introduce my colleagues to open source software for their simple/mid level image editing and they don't have to stuff aro

  • "The whole mentality here is that anybody can change the source of a project, submit it, and you never know what kind of compiled binary you're going to get."

    If that is their mentality, you have already lost with all arguments.

    You cant try to understand that not everyone can get code to applications, only a trusted onces. Altought, everyone can send patches and new code, but it will _always_ get viewed by at least one truested coder and even can get easily modified someway in the process if the code is not so good already.

    It is as easy to get a malware code to opensource software, as it is to get to closed source software. But you, as client, has better change t

  • My advice is to evaluate the merits of your software shortlist on EQUAL basis. Get your decision makers to agree criteria for the selection of software BEFORE starting your evaluation and then choose the best scientifically. Factor in initial capital spend, running costs, feature-match and roadmap. The best software might not always be OSS although I've found many OSS and quasi OSS to have a very compelling business cases.

    In case you are interested (in various contracts), The following have been the on

  • Not to be trite, but it's quite possible to circumvent this problem provided you can exercise some control over a portion of the budget and you can find someone to "front" OSS software as their own.

    It would work like this: you see a need that could be addressed very well using OSS package X. You also ensure that there is budget to buy software.

    What you do next is to get a software consultancy you trust to take that piece of OSS software, modify it slightly (e.g. a new splash screen) and sell it to your

My idea of roughing it turning the air conditioner too low.

Working...