Bringing OSS Into a Closed Source Organization? 427
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?"
Play the game or go to a higher authority (Score:5, Informative)
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:
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.
Re:Play the game or go to a higher authority (Score:3, Informative)
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 (and if a CCO is making these decisions in a company that is large enough where the poster could not go above him, then he is micromanaging).
It is relatively easy to find commercial support for any major open source packages. Red Hat provides support for cygwin (and that includes vim), for example. If there are no-name companies getting approved, I can guarantee that either the maintainers of the project or a third party will be willing to write a support contract.
Create OSS adoption guidlines (Score:3, Informative)
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.
Re:Play the game or go to a higher authority (Score:5, Informative)
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.
Address the facts (Score:5, Informative)
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:
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.)
It's not about malware, support, or quality... (Score:5, Informative)
- 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:Other concerns: OSS creep into commercial code (Score:4, Informative)
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:Don't bother (Score:5, Informative)
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:Other concerns: OSS creep into commercial code (Score:2, Informative)
> 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 product with the stolen code.
Remove the stolen code and continue with your usual business.
"Poison pill", "viral GPL", etc. is FUD.
Re:Don't bother (Score:5, Informative)
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:4, Informative)
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.
Re:Don't bother (Score:5, Informative)
a commercial software vendor could get sued (or lose credibility among people purchasing it..and lose the business) if there is malicious code in place, so it is in their best interest to make sure it's not there.
Not necessarily. Its pretty standard practice among software companies to put a clause into the license agreement indemnifying them from losses caused by the program. Every closed source program I've purchased has had that clause, either in the click-through EULA or on a slip in the box.
Re:Don't bother (Score:2, Informative)
there has to be 100% accuracy in detection of malicious code, and the various C obsfucation contests show that's not an easy task.
This is where the coding standards of the project come in. The coding styles for most projects will say don't do anything tricky and in order for you code to be accepted into a project's repo, you have to conform to the coding standard. Proving that you are capable of following the coding standard is normally one of the requirements of getting write access to the repo.
The requirements are normally based around making the code easily readable, which includes using braces all the time, no multiple statements per line and following the correct indentation standard. These rules make the type of things done in the C obfuscation contests more or less impossible.